Max no of male sheep with Emulator

With ref to the RiscPc having two ram slots excepting 256Mb cards -was this ever tested in a real machine.

It seems VRPC DL will except two 256Mb in the txt file – but will not work in practice.

[Edit]

I surpose it would be interesting to see what the spec was – laid out for the original RPC :-)

Acorn Application Note 259 http://chrisacorns.computinghistory.org.uk/docs/Acorn/AN/259.pdf suggests 128MB per slot.

[Edit: Just looked at the 7500FE DRAM interface and that’s definitely limited to total 256MB DRAM, 64KB per bank (could be two per physical slot). Indeed there’s only 256MB available for DRAM in the physical address map.]

As Stuart says, the RiscPC can only have a maximum of 256Mb, so 128MB per slot.

How did the Kinetic card Ram get added to the mix?

suggests 128MB per slot

Quoting the RiscPC TRM:

To realise the maximum configuration requires two 128 MB SIMMs. However, at the time of writing, the maximum size of memory SIMM commercially available is 32 MB and to provide more than this requires use of address bit Ra[11]. At present, DRAM suppliers have not yet agreed on which pin should carry this signal. As a result, Ra[11] is connected to pin 29 as this is currently one of the N/C pins as defined by the JEDEC specification and indeed, some suppliers use this pin for Ra[11] on their nonsquare DRAM. arrays. If when larger modules are available Jedec have approved a standard placement for Ra[11] which is not pin 29 it will be necessary to remove the zero ohm resistor in series with RA[11] and reconnect it to the correct N/C pin.

To complicate things a little:

How did the Kinetic card Ram get added to the mix?

The Kinetic had it’s own memory bus which was clocked much faster (66MHz) than the bog standard RiscPC bus (16MHz).
It was able to also access system memory (akin to how the x86 does it) so it can make use of that, albeit slower, memory as well.
The main problem is that since the Kinetic memory was separate from the system IOMD, podules were not able to DMA into it and had to fall back to the older slower transfer method.

So, you got a smoking hot processor and memory at the cost of slaughtering disc accesses…

How did the Kinetic card Ram get added to the mix?

The Kinetic had its own memory bus, so yes with a Kinetic installed you can reach 512MB of total RAM on a RiscPC. I did it once for the heck of it and it works.

However, do you need it? No. Nothing on RISC OS 4.39 or 6 will ever need that amount of RAM and Rick is absolutely correct, you’ll end up having 256MB of “Fast RAM” and 256MB of “Slow RAM”. Why would you need that for?

Even if you wish to run a ton of Apps, that would endup slowing the system a lot (especially if you’re running Apps that are not cooperative MT “friendly”).

Not to mention that having that amount of total RAM may also cause some troubles to some apps.

On the emulation thought, we already can push RPCEmu video RAM to 8MB (which is 4 times the amount of video memory a RiscPC could have), having extra RAM for the system may have some minor benefit.

we already can push RPCEmu video RAM to 8MB

That’s because the VIDC2’s main screen size limits are physical timing and hardware, neither of which apply on an emulator; so by pushing the VRAM to larger sizes it is possible to have screen modes and depths more in keeping with what’s expected these days.

The monitor I’m currently using is a generic 1280×1024 LCD. In 16M colours, that’s 5MiB.
FullHD (1920×1080) is just shy of 8MiB in 16M colours.

Remember, in 1995 typical screen resolutions were 640×480 and 800×600, and cutting edge people used 1024×768. LCD monitors outsold CRTs for the first time in 2003, all of which ought to give an idea of “typical” display technology and why Acorn felt that 2MiB was enough VRAM… at least until the RiscPC was replaced with the next bit of kit… though to be honest, with a 16MHz memory bus speed it was not fast. The A540 and newer ARM3 machines were running the memory at 12MHz (original ARM2 machines did it at 8MHz), so it was already running at about half the speed of the original ARM610 processor, and it just got worse from there. I guess the smaller application sizes on RISC OS and the use of DMA from IDE/SCSI cards helped to mask over some of the inherent slowness.

Anyway, the video capabilities of the RiscPC were not bad for when it was released. These days, well, these days one expects better, which is why the emulators allow 8MiB.
It’s even enough to allow double buffering in HD720…just. ;-)

Remember, in 1995 typical screen resolutions were 640×480 and 800×600,

Remember Rick, the RiscPC internal bus is 16 bit, not 32. So the RiscPC wasn’t at all a great machine when it came out. The podule bus is 32bit, not the internal bus where internal HD, NIC, Audio etc. are connected.

The RiscPC also had a DMA that wasn’t particoularly good.

The great thing about the RiscPC was the 2nd CPU slot, however not particoularly useful with RISC OS, so we only used it for the PCCard (and bus contention on the RPC mobo was well, oh dear!). Better than nothing sure, but the bandwidth limitations made it worst than having a PC card on a Podule with its memory local and used at full bandwidth.

I am not a big fan of the RiscPC (well clearly lol), Acorn could have done so much better there! And the engineers they had surely could, but I suspect that the source of many issues with the RiscPC were because of the weird ARM610. It’s probably possible that the RiscPC would have been a much better system if the ARM710 would have come earlier and would have been used instead of the ARM610, but that is just my opinion.

In 1995 PCs had full 32 bit internal buses and the ISA slots were bridged (when still available on the cheaper modethboards). The 486DX killed any Acorn’s dream of speed and when the PCI bus became popular and cheaper it was game over.

Ref max memory – Not a netsurf user then :-)

Just wondering if a ‘cunning’ plan could be conceived to double the max ram too 500Mb with the Rpc emulators.

VRPc DL doesn’t seem limited to 8Mb screen memory.

Remember, in 1995 typical screen resolutions were 640×480 and 800×600, and cutting edge people used 1024×768.

The Risc PC was meant to do 1600×1200 out of the box, which would have been cutting edge. However, days before launch the first batch were found to have unstable video output at that resolution so the documentation was quickly revised back down to 1280×1024. Which may have been higher than some people were using, but nothing special.

Luckily being an commercial customer (back when RISC OS was used in serious industry), I was able to test every machine coming through and hand pick the ones with stable displays to use at work for development and at home for… more development.

Just wondering if a ‘cunning’ plan could be conceived to double the max ram too 500Mb with the Rpc emulators.

Adding Kinetic support is possible. Just not really worth the effort, it ‘only’ doubles the RAM to 512MB, which is just the next hard limit.

All this to run a poor web-browser in RISC OS at a 5th of the speed of a browser on the host machine’s native OS.

Adding Kinetic support is possible. Just not really worth the effort, it ‘only’ doubles the RAM to 512MB, which is just the next hard limit.

I thought the major selling point of the Kinetic was the higher memory access speed, which isn’t relevant in the emulator – so, as you say not really worth the effort.

To realise the maximum configuration requires two 128 MB SIMMs. However, at the time of writing, the maximum size of memory SIMM commercially available is 32 MB and to provide more than this requires use of address bit Ra¹¹. At present, DRAM suppliers have not yet agreed on which pin should carry this signal. As a result, Ra¹¹ is connected to pin 29 as this is currently one of the N/C pins as defined by the JEDEC specification and indeed, some suppliers use this pin for Ra¹¹ on their nonsquare DRAM. arrays. If when larger modules are available Jedec have approved a standard placement for Ra¹¹ which is not pin 29 it will be necessary to remove the zero ohm resistor in series with RA¹¹ and reconnect it to the correct N/C pin.

Dear reader, we can reveal this story has a happy ending. Pin 29 is used as Ra¹¹ in the JEDEC pinout, so Acorn guessed right.

So, you got a smoking hot processor and memory at the cost of slaughtering disc accesses…

It’s a bit disappointing Castle didn’t put a basic IDE interface on the Kinetic card, which would have at least made that go faster. Or even a connector to which I/O modules could have been attached (a bit like the netslot cards), if there was room.

There seems to have been updates to RPC motherboard – would it have been possible to do major updates to RAM speed etc?

The two things that I can think of is that the sound was put on the board in a later (Mk3?) version. And maybe they did something with “that one capacitor”. ;)

The BBC Micro went through, as far as I recall, seven board designs but it didn’t fundamentally change how it worked.

The problem with tweaking the memory bus speed is that a lot of the system timing is interdependent. Sure, you might be able to fiddle the crystal to get 20% faster timing on the memory bus, but then your video syncs are running 20% faster and your monitor isn’t interested. Or you scramble your harddiscs because you’re throwing data at the interface too quickly and it gets muddled.

It can be done, there’s a document about it on Theo’s site, but it’s “delicate”.
And, honestly, probably not worth the bother when a Pi (that mightn’t cost that much more than a handful of timing crystals) can run so many rings around the RiscPC it would look like Saturn…

And, honestly, probably not worth the bother when a Pi (that mightn’t cost that much more than a handful of timing crystals) can run so many rings around the RiscPC it would look like Saturn…

Never looked at the dimensions of a Titanium board, but that might fit nicely in an RPC chassis…

Never looked at the dimensions of a Titanium board, but that might fit nicely in an RPC chassis…

Always thought it might be an interesting project to come up with an IO board that would fit into the back of a RPC or A7000 case (with an HDMI socket where the VGA port was, USB ports where the parallel and serial were, a gigabit LAN port etc), and attach a Pi Zero to it. That way you could have the whole retro experience.

The Risc PC was meant to do 1600×1200 out of the box, which would have been cutting edge.

Unfortunately, that was not the case (at least not in 1994 anymore). The rest of the world already had much better RAMDACs (e.g. Matrox Millenium IIRC) and also 4 MiB of VRAM. Even with the originally envisaged 160 MHz pixel clock the VIDC20 should be able to operate, together with the 2 MiB VRAM limit this would have resulted in 1600×1200 in a meagre 16 colours and around 60 Hz at most. I mean, the only true colour resolution with max VRAM on the RPC was 800×600 – laughable. There was a reason why the ViewFinder was considered the best productivity upgrade (together with the StrongARM) in the RPCs history. At least by me.

The combination of 486DX (good IPC and FP always included), VLB and a short time after that PCI and higher-clocked Pentium CPUs along with serious 2nd level cache sizes meant that the 30 MHz ARM610/40 MHz ARM710 with severely underpowered EASI/DEBI extension possibilities and slow FPM RAM with undersized L1 caches and no L2 caches could only score with RISC OS being a better OS than Windows 3.1. Windows 95 changed that, and the battle was finally lost. Application-wise, the battle was probably already lost at the beginning of the 90s.

The Risc PC with the right VIDC did 1600×1200 in 256 not 16 colours. Also 1152×986 in 32K colours, but as you said only 800×600 in 16M colours. The original ViewFinder allowed 1600×1200 in the full 16M colours and later could also do 2048×1536 in 16M colours.

Contemporary PC’s were 1024×768 in 32K colours and 1280 × 1024 in 256 colours. 32K/16M colours on that generation of graphics card under Windows was slow and often unsupported by many applications. While the paper specs of RISC OS may have been exceeding, every application was capable of using the best resolutions and colour depths available, which is often forgotten.

Later on I had work PC’s which were capable of the same output as ViewFinder but companies wouldn’t cough up for the monitors, so my RISC OS systems were better up until I got a laptop dock which could drive a couple of 2560×1440p monitors – and the Iyonix still could drive one of those at full resolution and colour depth. The Raspberry Pi 4 can drive two 4K monitors, although at the moment only one when running RISC OS.

Unfortunately, that was not the case (at least not in 1994 anymore).

I was referring to what typical people bought and used in those days. There were, of course, better solutions if you had the money. Just like today, you could buy something like an AMD Radeon Pro W6800 but that’s not exactly a standard issue on any store bought PC…

But, yes, in the early to mid 90s we leapt from lowly 186s and ISA cards running DOS … Windows 95 on early Pentium class machines with PCI. The megahertz values of processors seemed to move faster than the ability of companies to make motherboards for them. Accordingly, everything else leapt at the same time. No longer would a 40MB harddisc break the bank, indeed 40MB was laughably small. My W95 box came with something weird like 980MB and the price wasn’t scary. Since RISC OS was small, I recycled old IDE drives when people upgraded to bigger ones. The memory in my RiscPC came from a Pentium box that damn near burnt itself out when the CPU fan failed – it was unreliable in my PC but since the RiscPC is treacle slow in comparison, it worked fine there.
And, of course, video. We rapidly went from 256 colour VGA to higher resolutions and many more colours. Since by then (1997) AGP slots started to be a thing, one was no longer limited by the (often rather mundane) onboard graphics or what would work in a PCI slot.

While W95 was severely bugged and rather crap, it was pretty much the writing on the wall. You could see what direction Microsoft was going, and it was a massive improvement over Windows 3.1×. Clearly the next iteration would be better.

And it was.

I wonder how much Acorn’s demise in 1998 had to do with looking at any W98 box and realising that it was utterly game over. I mean, the Phoebe spec was not impressive compared to its contemporaries (I savage Phoebe here), especially given how long it took to get part of the hardware working correctly.

Suffice to say, as the eight bit era was drawing to a close and the 16 bit era was underway, Acorn’s 32 bit machine offered a lot of potential and the world’s fastest interpreted BASIC.
A decade later, the rest of the world hadn’t just caught up, they tore past leaving nothing but a smoke trail.
I think Acorn just wasn’t big enough or rich enough to have any hope of keeping up.

I think it might be also worth noting that Microsoft don’t make computers, they let others do it in a sort of symbiotic relationship that kept x86 on the map (for better or worse…).

Apple, on the other hand, went from 68000 in the classic Mac (with it’s dinky monochrome screen) to PowerPC in the original iMac (the G3 etc) to x86 in the next generation, and now switching to their own home grown ARM64 processors.

So, clearly there’s potential in ARM processors. But since Acorn seemed to be stuck with running RISC OS in 26 bit mode (something even ARM had given up on by then), they just weren’t adventurous enough.
As I note with my Phoebe comparison, the base spec of the machine probably isn’t that different to a tricked out (Viewfinder plus Kinetic) RiscPC.

they just weren’t adventurous enough

Which considering how adventurous the original ARM chip was in its day, is a bit sad. But you’re absolutely right, of course.

they just weren’t adventurous enough

Do you not mean “didn’t have enough resources”?

It’s obvious from hindsight what a shoestring most of RISC OS was done on, and by the mid-early 1990s the impression is that Acorn simply didn’t have the capability to fund or carry out that kind of development. The fact that the RiscPC came out with RISC OS 3.5, which was basically “3.1 + the bits needed by the hardware + any bling that could be done on the cheap” is indicative of where things were going, and what folk such as Chris Cox have said since backs that view up. Since the A5000, they were basically in “survival mode” as far as development budgets were concerned.

I suspect that the calculation went along the lines of “we could make the RiscPC 32-bit, but then we couldn’t do the bling… and if we don’t do the bling, it will be a hard sell to get users to fork out for some new hardware which runs RISC OS 3.1, breaks all of their existing software, and is essential for our cashflow”.

I did say…

Acorn just wasn’t big enough or rich enough

;)

But, yeah, the mentality that gave us the likes of the Apple II and the BBC Micro (basically a few geniuses) doesn’t really scale to the new era when entire corporations were the competition, with coffee budgets larger than the little guy’s entire turnover.

Needs money.
Well, that’s not new.

we could make the RiscPC 32-bit, but then we couldn’t do the bling

Oh, I don’t know. They did make some sort of Java runtime that was demonstrated at one of the shows and put on a Clan CD…that was promptly forgotten about.

Oh, I don’t know.

Read in context, you’ll see that I noted that we did get (some) bling, very possibly at the expense of 32-bit.

They did make some sort of Java runtime that was demonstrated at one of the shows and put on a Clan CD…

That was a few years later than the RiscPC’s development, though.

Anyway, I thought most of that era’s development was effectively being paid for by other contracts. Something (STBs?) needed Java, so Java was developed to a point, thrown out as a bone to the Clan members on the CD…

…that was promptly forgotten about.

…then forgotten, because the focus of the project that was really driving the work shifted, was lost, or whatever.

As I recall Chris Cox telling it, the whole point of the Clan (and of Chris Cox’s role at the helm) was to find ways to make stuff from unrelated work look interesting to the “enthusiast” market, so that they would keep on supporting the platform even though there was basically no money left to develop things directly for that market.

Wasn’t even StrongARM support for the RiscPC touch-and-go, and done by one (IIRC¹) engineer?

¹ I was going to say that it’s so much easier now that we can go back and watch recordings of meetings on YouTube. However, it turns out that Chris was recorded when he spoke to WROCC, and you can find the videos at https://www.wrocc.org.uk/meetings/2019/chris-cox – it’s late as I type this, though, so I’m afraid that for now I’ll stick to my memory of what he said.