Max no of male sheep with Emulator

I seem to remember that it was sort of discouraged to write 26/32bit anostic code at the release of the RPc.

Would be interesting if some of the old Acorn staff could write what they saw as the way ahead.

[Edit]
When could the ‘C’ compiler spit out 32bit code?

When could the ‘C’ compiler spit out 32bit code?

The Castle era compiler sort of could because the Iyonix is a 32 bit machine. But code emitted using it failed on the Beagle; a recompile with a newer (DDE/ROOL era) compiler fixed this.

I think, to be honest, a lot of the issues were down to changes in the underlying architecture. What broke a lot of GCC stuff was the removal of SWP which was used in some library code. What broke a lot of Norcroft stuff was the removal of rotated loads, etc etc etc.

Oh, and what broke some DDE stuff was clearing all of the processor mode bits when switching mode because the high bit there used to select 26/32 bit, then it pretty much did nothing as there was only 32 bit, then it became a way to downgrade from 64 bit to 32 bit, but clearing the bit isn’t a valid way to bounce back up to 64 bit so it would fault.

The x86 has a messy, horrible, and inefficient architecture. But on the other hand, TurboC++ and XTree Gold (both ancient DOS programs) are quite happy to run on my P4 box. I think the break finally came with x86-64 and UEFI.

ARM, on the other hand, has been pretty much aimed at embedded devices for which the OS and software is either specifically targeted, or is compiled on the fly (like Google’s Play store apps). So there’s less need to keep the ABI consistent and compatible with the old days.
Unfortunately given the lack of habit of “building from source” like Linux, RISC OS and it’s applications did tend to suffer from architecture changes.

Especially now, we’re sitting on a huge pile of assembler that can’t simply be rebuilt with a different compiler to run on 64 bit hardware; while the likes of Android and Linux could be.

Not quite true: Acorn C Release 5 did support generation of 32-bit APCS. 1994, it’s even documented.

Yup, just compiled a PipeDream 3 module with that and the appropriate flags, output looks OK.

That more or less the time of the RPc being announced.

They seemed to have money for the PC slot and development of PC card.

A podule card would have done – for ones wanting Windows.

[Edit]

Would have a 32bit only processor been cheaper back then?

C Release 5 did support generation of 32-bit APCS. 1994

My bad. I thought release 5 was a bit later than that.

It seemed to create issues with code that I compiled, which led to the code not working (I started making a 32 bit clean DeskLib way back when).

They seemed to have money for the PC slot and development of PC card.

The PC slot was just part of the OpenBus (was that what it was called? I forget…) architecture. I believe, with arbitration logic, you could whack another ARM in there instead. But, well, the regular processor cards didn’t have that logic and RISC OS wouldn’t know what to do with the other ARM anyway.

As for the PC card, wasn’t it pretty much Aleph1 behind that?

A podule card would have done – for ones wanting Windows.

No, it really wouldn’t. No direct access to memory, 8MHz I/O speed tops, it would have sucked.

I have in my pile of random junk an 80386 card. Which is basically a PC on a podule. It has its own ports, and more tellingly, it’s own memory (4MB I think). Because you just couldn’t punt that down the podule bus at any useful sort of speed. Flat out it can do 8MHz synchronous and, what, 16 bit? That’s a bit of a bottleneck that would absolutely slaughter any hope of getting useful performance.

Remember, podule based storage (IDE, SCSI, etc) only need to shove data when accessing the media. A processor needs it continuously, and at a far greater speed than harddiscs of the time.

It seemed to create issues with code that I compiled

We didn’t use it at all because it required the updated SCL that would only work on RISC OS 3 up, so I can’t comment on the quality of code it emitted. Loads of our customers still had RISC OS 2 systems in 1994, with no budget to upgrade.

But as for the original topic, it would seem unlikely that anyone will put effort into updating RPCEmu to support Kinetic-like memory maps. Buy a Pi.

Buy a Pi.

;)

I think sometime along the way we’re going to have to have a think about emulation options as a way of keeping RISC OS alive.

While RPCEmu (and VRPC) are good, they’re emulations of ancient machines and that carries various limitations. Not to mention a lot of work by the host to pretend to be something else. All things to look at…

So, yeah, I can’t exactly see any actual use case for a Kinetic emulation, it’s not as if the speed would double or anything.

Loads of our customers still had RISC OS 2 systems in 1994

Oh my!

RISC OS 2 was so simple compared tu 3. Sort of the stepping stone between Arthur and the one they got mostly right. ;)

The Risc PC with the right VIDC did 1600×1200 in 256 not 16 colours

You are of course entirely correct. I got confused between the three hard limits of the Risc PC’s graphics subsystem (pixel clock, amount of VRAM, available VRAM bandwidth), and the problem with “1600×1200” was not the colour depth (although 1994 mid-end VLB cards like e.g. the Elsa Winner or something S3 based or Weitek based or ATI Mach64 based could do 1600×1200 in high colour because of 4 MiB VRAM), but the max pixel clock, which resulted in a much too low refresh rate for modern CRTs back then. For old CRTs, 60 Hz was enough, for some monochrome screens even 50 Hz, but nearly everything built after 1992 really needed 70 Hz+ for flicker-free graphics.

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.

Not my experience at all. My 1994 PC – much cheaper than the Risc PC – had a 4 MiB VRAM VLB card and worked just fine in any resolution that my 17" monitor could chew under Windows 3.11. No known problems with any applications I ran. The analogue output quality was much superior to my Risc PC (which had its motherboard swapped two times before video output was of acceptable quality). And the card already had 2D acceleration which helped a lot (although the VLB was very speedy in itself, much much higher performance than back in the ISA days where you actually desperately needed those rectangle copies and off-screen bitmap caching driver magic techniques, i.e. all the tricks ViewFinder did later). Those cards also started to have video acceleration features, e.g. colour space conversion and video overlays, which was very helpful back in the days. Of course irrelevant to RISC OS which was still stuck in the dead end called “Acorn Replay”, where you needed an insanely expensive podule to decode a meagre MPEG1 VCD data stream for anything approaching a “standard video codec”. Yes, I am ignoring MovieFS here.

Basically, the Risc PC had the video spec of a 1992 VLB ATI Mach32. Not too bad, but certainly not earth-shattering and in no way “cutting edge”. There was much better stuff much cheaper in PC world in 1994. Let down by Windows 3.x’s general crappiness of course, but that’s another story.

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.

All except those that did direct screen access and were kind of surprised when there was something different than a maximum of 1 byte per pixel. Which were quite a few. History repeated later with the colour component ordering disaster in RISC OS – well-behaved applications worked, but far from all. And not forgetting the resolutions that RISC OS could not produce properly because the width in pixels was not divisable by 8. Or was it 4? Yeah, 1366×768 was the problematic one, aka “HD ready”, which would have been good for some LCD TVs I wanted to connect to the BeagleBoard. There went the idea of a pixel-perfect display.

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.

I remember when my boss bought a bunch of different 21" LCDs capable of natively displaying 1600×1200 around 2001 to replace our fine-but-big Nokia 19" CRT Trinitrons (could do 1600×1200 quite nicely) – the big problem was that DVI could usually only do 1280×1024, so we needed LCDs that were happy with the VGA output of Dell laptops and docking stations. We finally settled on a FSC which provided extremely crisp display, which also worked fine with the IYONIX developer prototype in late 2002. And with the ViewFinder – don’t remember when that one was released, but I bought the 1st generation right when it was announced.

So again, for me it was better-and-earlier-and-cheaper in PC world.

The Raspberry Pi 4 can drive two 4K monitors, although at the moment only one when running RISC OS.

I don’t exactly know the date of that AMD-with-Radeon gizmo that still sits next to me (AMD Fusion A8 whatever) which is very old and slow in PC terms, but it might predate the RPi4 by nearly a decade and easily can do two digital outputs with 4K resolution.

I was referring to what typical people bought and used in those days.

I very specifically answered Druck’s claim of being “cutting edge”. It makes little sense to discuss “typical” things, because those are different for everyone. Suffice to say that the usual 1994 PC that my friends and me bought had proper 17" CRTs and VLB graphics cards with typically 4 MiB VRAM. Oh, and there was that one guy with a NeXT…now that was even more expensive than the machine from a die-hard OS/2 enthusiast which of course needed at least 8 MiB of RAM and an IBM 8514/A graphics card because all the others had lousy OS/2 drivers.

There were, of course, better solutions if you had the money.

Everything in PC world was a lot cheaper than a Risc PC, so the Acorn enthusiast needed to be rich anyway. And the gap widened all the time. The PC I bought around the time the StrongARM was available already had a 350 MHz P-II which was much much faster than a StrongARM even when only talking about Integer performance. It had a nice big L2 cache and a Diamond Viper AGP graphics card which had one of the first NVidia 3D accelerator chips. RAM bandwidth and of course everything I/O related was so much faster than the Risc PC (and the Phoebe which was really completely underpowered compared to the competition). So in less than a decade, Acorn hardware went from “most CPU bang per buck” to “just too slow and far too expensive”. And that is even ignoring the software problem, which was much worse.

Just for interest – could different faster Ram in the memory sticks be used in the RPc?

Just for interest – could different faster Ram in the memory sticks be used in the RPc?

Sounds like trying to use a trailer on a Bugatti Veyron, pretty pointless, as there’s probably no decent place to mount the trailer hitch and the whole setup can only go as fast as the slowest component anyway.

and to bring the slow bus speed fully into frame:

The car plus trailer has to drive only on sub-urban roads in Wales (20mph limit)

Re-reading some old posts – someone here added PS2 memory adapters to a RPC getting 4*128 it seemed to work – how does this memory get mapped in?

With ref to RiscPc main memory – how do x2 adapters work?

Note – can one delete a extra post?

I was using one PS/2 SIMM memory adpter with two 128MB PS/2 SIMM in the first Risc PC memory bank and one 128MB SIMM in the second bank (was not enough space inside for a second adapter ;-))
The adapter combines both SIMM into one and the OS can handle this 256MB (+128MB) without problems. For the RISC PC it was allowed to using different memory sizes per bank.

Thanks – I had tried to find this info again – does this infer that the real Risc PC can handle 512Mb of Ram?

From the RISC PC TRM: “The total (physical) memory map is 512MBytes, as only 29 address bits from the ARM are connected to IOMD.”

The lower half (256MB) of which is occupied by ROM, VRAM, podules and expansion cards.

The top half (256MB) is allocated to DRAM, max. 128MB per slot, 64MB per bank. It can’t just magic up another address line.

Raik – how much memory did the OS say it had – and did you run a prog to see if the memory was valid?

The RISC OS 5 HAL knows that the maximum amount of DRAM controllable by IOMD on the RISC PC is 256MB.

It can only be more (512MB) if it is a Kinetic.

I think Acorn promised to throw in the Risc PC for free if you spent £18,000+ on 256MB of memory back in 1994.

I only managed to stump up £680 to take to have mine delivered with 16MB instead of 8MB.

Ha ha. Ours was also a 16MB (ARM610), bought for Fireworkz Pro and newfangled sprite format development. Someone gave me a 64MB SIMM many many moons ago; that’s what it runs to this day.

I have vague memories of speccing a 1GB quad Pentium Pro Citrix system for client in ca. 1996? that was £30k for the memory. [Edit: And bought a comparable one 2nd hand in 2003 to do some multiprocessor testing with PCI cards I was working on for … £65.]

My RiscPC eventually had 32MB installed.

Funny story. A bloke, not great on the hygiene, big on the smoking, managed to rapidly get his shiny new Pentium machine into a state where the processor fan failed. This eventually cooked the processor and the memory above it.

New machine, but being a cheap bastard he recycled as much as he could from the old one. Only, it would freeze every time it warmed up.

Turns out that the memory module failed when it was stressed. So he begrudgingly got a replacement and tossed the old in the bin.
Which I recovered.
Worked fine in the RiscPC, because the lethargic bus speed and lack of heat (most of the internal heat was from the x86 when it was running, or the harddisc) meant that the memory module wasn’t stressed, like, at all.

This might be interesting/scary reading: https://jcmit.net/memoryprice.htm

A bloke, not great on the hygiene, big on the smoking, managed to rapidly get his shiny new Pentium machine into a state where the processor fan failed.

ICL kit, back of reception link to other main site in town. Kept cutting out, so yours truly had to investigate what the supplier engineer didn’t do.¹
Remove a layer of fluff deep enough to insulate your loft and vacuum out the remnants, and it worked absolutely fine for another 5 years until it was scrapped.

¹ There’s a recurring theme here as I’ve spent much of the intervening decades figuring out what the suppliers haven’t done right, or want to do wrong.

Raik – how much memory did the OS say it had – and did you run a prog to see if the memory was valid?

RISC OS 4.39 with real ROMs.
On startup 386MB (384RAM + 2MB VRAM).
I have not check if the memory is valid with a program but I used the biggest possible RamDisc. I mean 256MB. It was the “temp working place” for the IRLAM24i16 for recording an other operations.
Is there a tool to check the memory? Take time but I can check in the winter time ;-) I gabe not use the RISC PC for years only any start ups …