Pre-RISC PC machines

Not sure if this should be in here or in Porting, but anyway…

I’m aware that the starting point for RO now is a RiscPC or A7000, but seeing as we’ve got the sources… any chance of a “final” version for pre-RPC hardware?

I’m not thinking any major changes, but it would be really nice to have things like the nested window manager, 3D window tools, hi-res sprites etc in ROM, so one doesn’t have to soft-load them on a 4MB machine.

Ideally things like the Internet/mbuf module and Toolbox could be included in the ROM as well, space permitting. If this means moving some of the ROM apps back to disk then so be it (I’d suggest that Edit stays in ROM though for rescue purposes!).

And this might be a pipe dream, but it would also be really nice to have a more recent Filecore module on an A5000; one that supports disks bigger than 512MB. Not so worried about long filenames or >77 files/directory on a system this old. I’m just thinking it would be really nice to be able to stick a new set of ROMs in the A5000 (let’s call it RISC OS 3.4 for argument’s sake) and have all the updated modules available without using up 60% of memory in the RMA, and be able to plug, say, a 4GB CF card into an adapter and use all of its capacity.

Thoughts, anyone?

Look this may seem hard and as a life time user i think it’s time to bin the old stuff and get behind supporting future development.
So to this end i ask the question, “why after all of these years are we still hanging on to this old outdated hardware, when you can get a Pi and run the latest OS for less that it would cost for a 4Gb CF card and adapter to upgrade an obsolete machine.”
Sometimes it’s time to say this computer has had a good life but I need to move on.
Its time to stand up and be counted if you want to continue using RiscOS support the future development don’t live in the past.

I already have a Pi. ;-)

It’d just be nice to not consign the old “retro” kit to landfill. After all, there’s all sorts of upgrades etc for the Commodore 64. And the early Amigas.

Ok, I fully appreciate there’s not a huge amount of useful work you can do with a 4MB A5000, but from the “retro” point of view it would be nice to flash a ROM image which had all the updated modules etc in it and use it for retro stuff.

(I say this as someone who’s well and truly gone to the dark side – I’m writing this on a laptop with an AMD E-series CPU, 8GB RAM and Windows 7. Although I am using Firefox, not the abomination that is IE.)

Building a full ROM for Arc machines would be a bit tricky – for most components the history in CVS only goes as far back as RISC OS 3.5. For the hardware drivers and all of the ancillary modules (wimp, filecore, etc.) this is probably OK, as a lot of them are designed to be softloadable and so even the latest versions of the modules will often have 3.1-compatible code paths. But the big thing you’d be missing would be a pristine copy of the RISC OS 3.1 kernel. So you’d have to start with the RISC OS 3.5 kernel and then go through disabling features or (hopefully) re-enabling old code paths until you get one which has the same feature set as the RISC OS 3.1 kernel (i.e. only supports ARM2/ARM3, uses MEMC as the MMU, no OS_DynamicArea, etc.)

Of course you could go down the approach of avoiding building a new kernel at all – it’s relatively easy to take a ROM and break it apart into its constituent modules. So you could take a standard RISC OS 3.1 ROM, break it apart, replace everything except the kernel with new versions, and then put it together again.

Doing so you would get the worst of all worlds:

- Reduced compatibility with other RISC OS 3.1 stuff that you would normally want on an A5000 rather than a Pi – likely including breaking a load of games.
- Slower performance (more modern code does introduce features which would be sluggish on the A5000 – even textured window backgrounds and anti-aliased fonts in the desktop hurt IIRC from Wimp 3.98.
- Memory constraints would worsen meaning once you’ve got to the desktop you can’t actually do anything.

- It would be a nightmare to get there – there are still lots of assembler modules which in the 32-bitting process are likely to have become Arm 600 minimum.

Bear in mind that no active work is done now to support the hardware, and more peripheral modules will assume RISC OS 3.5+ features (like dynamic areas).

Unfortunately, if you want the retro look, the smarter move is to get a dead A5000 (rare things I suspect as most will survive the nuclear holocaust), and then figure out how to replace the motherboard with a Pi rather than replace the OS. Or enjoy the A5000 for what it is the last of that generation of Acorn machines (with the RPC being the start of the subsequent generation).

From what I remember, textured window backgrounds and outline fonts didn’t particularly hurt performance on a pre-RPC machine, as long as you set a decent sized font cache. I for one pretty much always loaded the “unofficial” Window Manager that “leaked” (the non-nested one that did outline fonts and textures).

There was a build of 3.98 (nested WIMP) for RO3.1 machines, which didn’t take any more memory than the leaked one. When that went on general release I just swapped some modules over in the Econet/ShareFS boot sequence (I’m just remembering the nightmare I had to get that properly configured, it involved making an Absolute file containing all the updated modules in the correct order using something called ModApp or similar, booting from NetFS, copying the Absolute file along with an Obey file to the RAM disk, running the Obey file which would load the modules then continue to boot from ShareFS.)

I don’t think UtilityModule would need replacing. I like the idea of breaking apart a 3.11 ROM image and rebuilding it, replacing things like WIMP 3.11 with WIMP 3.98, dropping the Sprites22 file into ResourceFS in place of the low-res one (along with the 3D window tools), and if there’s room, squeezing Internet 5.04 into the ROM image.

Clearly the F+ filecore isn’t going to work on an A5000, but is it likely that the Filecore from RO3.6 (>512MB disks) can be hacked to make it run on 3.1? 512MB CF cards are getting a bit hard to come by now, and it seems a waste to put anything bigger in an A5000 when it won’t use any more than the first 512MB.

This is purely a “can it be done” question, just to make that clear!

I see two steps:
1/ use a modern Boot sequence and search why it doesn’t work on ROS 3.11.
2/ replace components with modern 26/32 bit versions.

The good point is that the part you’ll adapt will be very useful to update a PreRiscPC or a RiscPC, while staying in 26bit mode. A good point for portability.

The elephants in the room is memory, chips & money!
Pre RISC OS 3.5 machines have a 4MB maximum (Excluding the A540, R260 etc) so the OS can’t be soft loaded.
2 chips RISC OS computers (A3020, A3010 & A4000) could use ROMS like the RISC PC RO5.20 ROMS (£30+VAT+P&P)
But A5000, A3000 & all Archimedes 4 chip RISC OS computers would need need expensive EPROMS or Flash on a sledge, again expensive.
I wouldn’t have thought the volume of sales would justify the necessary investment.
Next question is who would organise and pay the upfront costs of the project. I would have not thought it worth diverting ROOL personnel to it.

Next question is who would organise and pay the upfront costs of the project.

Could always throw it to Kickstarter? Stranger things have raised cash. ;-)

(I say this as someone who’s well and truly gone to the dark side

I don’t see it as sides. I see it as what works on what. I won’t get my animé playing on anything running RISC OS, so I use something else¹ to play video. I’m also writing this on a PC because with reasonably recent standards support, it offers a better overall ‘experience’ than NetSurf.
However the monitor on the right is displaying RISC OS and… dammit… compile fail. Oh, idiot-programmer error (missed a ‘#’).

not the abomination that is IE.

Still using XP, plan to continue until either it or the netbook runs out of steam, then over to a Linux distro (whichever one can run OvationPro, probably).
I dropped IE as soon as Microsoft announced that the new one (IE8? 9?) was not going to run on XP. That, plus lots of time spent tweaking my blog’s markup before I realised that IE (in so-called compliance mode) was just a little off from everything else… I solved the problem quite easily. I simply no longer check&test with IE. I swapped IE for NetSurf, seemed a reasonable exchange.

¹ It should say something that a Pi with RaspBMC handles 720P just fine, while the PC…doesn’t always.

XP will run IE up to version 8. This laptop has updated itself to IE 11. (The laptop came with Win8 pre-installed, let’s just say that didn’t even get to the first boot.)

The Pi with XBMC will also handle 1080p with bitstream passthrough on the audio, have got mine running into a 51" plasma telly with 7.1 surround etc. But anyway, waaaay off topic (as always happens round these parts).

I’m well aware that softloading into an RO3.1 machine won’t happen, unless you happen to have an A540 (or an 8MB A5000). Could probably test it on VirtualA5000 though. I take the point about the ROMs, although are EEPROMs (as opposed to EPROMs) pin-compatible with the type of ROMs used? (Would have to heave them out of the machine to update of course, but I’m only anticipating that this be done once.)

I’m wondering whether it’s worth having a play around with creating a ROM image that just contains some of the freely available updated modules, then trying it on VirtualA5000. If it works… well, why not make it available for anyone with a suitable EPROM programmer?

There’s another reason why backporting RISC OS to pre-ARM6 machines would be a problem: dynamic areas and logical address space (or the lack thereof). Only the bottom 32 MB of the address space was remappable (the next 32 MB was directly mapped to the physical address space and any access beyond 64 MB resulted in an address exception – remember those?)

Half of that remappable 32 MB was allocated to the application slot – necessary because machines could have up to 16 MB of RAM and you might quite reasonably want to be able to allocate the majority to an application. The remaining 16 MB is already subdivided amongst the system dynamic areas, and there’s just no space left at all for user dynamic areas. Unfortunately there’s a lot of software out there that checks if the OS version is greater than 3.1 and uses it own dynamic area if so (otherwise dropping back to using the RMA).

Ironically, we’re rapidly approaching the same situation again, where the amount of physical RAM in machines is approaching the size of the logical address space – it’s just happening at 4 GB (2^32) rather than 32 MB (2^25). For the same reason, having lots of dynamic areas is a bad thing, and we should be trying to wean ourselves off them as much as possible. The next jump in logical address space size, to 48 bits (256 TB!) is not going to be an easy one for RISC OS due to the need to switch to the AArch64 instruction set, so I expect the pressure to avoid dynamic areas is going to be with us for some time to come…

So backporting is out, fair enough, that’s what I thought.

But what are the chances of building a new ROM image using softloaded versions of newer modules (eg WindowManager) and running things like Internet from ROM, at least partially, so that a 4MB machine remains useable when you’ve got it hanging off an Ethernet network? There may not even be any actual coding required to do this, as all the modules already exist in soft-load form anyway.

(This laptop is running an AMD64 chip with the x86_64 instruction set – just as well as it has 8GB RAM…)

I think if enough people are interested, then something could happen. There are similar things in the BBC Micro community. Have a look at the stuff in the StarDot forums, for example. Problem is, I think the Acorn 8-bit world was significantly larger than the 32-bit one, so there is less interested, and even less people around who also have the technical ability.

A newer ROM (essentially with all the official soft-load bits built-in) would be handy, as it would make 4MB machines much more useful.

That was pretty much my idea behind the suggestion, get all the softload stuff running from ROM.

Of course, if a RO3.6 Filecore could somehow be made to work on a pre-RPC system that would be even better.

A friend was telling me this morning that someone (Farnell perhaps) will supply pre-programmed PROMs at a reasonable price (I do mean PROM, as in a one-time programmable device). He couldn’t remember 100% but seemed to recall that in sufficient quantity (ie more than a couple of dozen) they’d program them at no extra cost. If this is to be a “final” edition of RO for pre-RPC systems then I’m sure a PROM would be fine, it would certainly keep the costs down.

Same idea here: https://www.riscosopen.org/forum/forums/2/topics/2519

Make ROS 5 modules, applications and boot sequence working on old systems. Then it will be possible to make a tweaked ROM with old kernel and new modules (for small memory systems, for example, or to speed up emulators).

There might be some merit in burning ROMs with old modules replaced with new. But I think the ROM size is limited (to 2MB?) by lack of address pins. There are the ‘5th column’ ROM slots on A4 and A5000, but modules on these are RAM-loaded on boot – so they don’t save RAM. It would be possible to compress code into the 2MB ROMs, but again you’d have to use RAM to execute from. However there’s 4MB of address space reserved for ROMs, so an extra address line might be borrowed from somewhere. I think there are some 5V DIP 1Mbitx8 flash chips about that might do the trick (PROMs aren’t necessarily cheaper these days).

It might be possible to kick out some modules that are less cared for these days – Econet, ROM apps, maybe import Internet modules instead.

Kick out the ROM apps? Heresy!

Leave Edit in ROM. If for no other reason than that you can get a system back up and running no matter how royally screwed the boot sequence is. The rest of the apps can go on disk, given the amount of RMA that would be freed up. And is there any need to have Configure in ROM, for example? Even when Acorn put the apps back into ROM in 3.6, Configure remained on disc.

Econet doesn’t take up much space. Leave that in, as I’ve been known to boot machines over AUN/NetFS (at least the initial boot until I can get ShareFS to initialise with a nicer hostname than the Unique ID).

Most of the problem with a pre-RPC system is that all the ROM versions of modules are out of date. So rather than soft-loading Wimp 3.98 (to replace 3.11) it could be in ROM, along with the hi-res tools and icons. If we’re short of space, drop Draw, Paint etc to disk.

I remember the address line problem with the original Archimedes series – when you upgraded those from RO2 to RO3 you had to fit the RO3 ROMs on a carrier board which tapped some extra address lines from somewhere. RO2 was 512K, if I remember correctly, which means that RO3 had 4 times the space. I’m sure a lot of the support for portables could be dumped too; how many working A4s are left? (And by “working” I mean with a battery that functions.)

I remember the address line problem with the original Archimedes series – when you upgraded those from RO2 to RO3 you had to fit the RO3 ROMs on a carrier board which tapped some extra address lines from somewhere.

The problem wasn’t that they needed extra address lines, they were all there! But not on the correct pins. When Acorn designed the Arc 310/440 the pin assignments for 32pin PROMS/ROMS hadn’t been agreed and they guessed wrong.
RISC OS 2 was 28pin. RISC OS 3 32pin.

RO2 was 512K, if I remember correctly, which means that RO3 had 4 times the space. I’m sure a lot of the support for portables could be dumped too; how many working A4s are left? (And by “working” I mean with a battery that functions.)

The main Batteries are not the problem, we have batteries with new cells in them in stock and can still replace the cells if need be.
What is the problem with almost all the A4’s we know that have died, is that the CMOS battery has leaked and damaged the motherboard. It is a small battery but it still can do fatal damage:-(

Fair enough. Does the A4 have the 5th column ROM like the A5000? The Portable modules could presumably be put into this.

Obviously this would be softloaded into RMA at power-up, but they’d take up a lot less space than the window manager etc.

I do like the idea of getting an extra address line from somewhere so we can have 4MB of ROM in an A5000 though.

(Off topic: I’ve spent the last day trying to figure out how to bodge an extra RAM chip into the cartridge port of my 1980s synthesizer. I think I’ve figured it out, and better still I can use an NVRAM chip with an internal lithium battery.)

Fair enough. Does the A4 have the 5th column ROM like the A5000? The Portable modules could presumably be put into this.

I believe Acorn had the same idea as you; Chris’s Acorns implies that all the A4-specific stuff was in an extension ROM, and (presumably) stock RISC OS 3.10 ROMs were used for the OS.

I thought the Portable and BatteryManager modules were in the main ROM, but just didn’t initialise if they weren’t in a portable machine?

The A4 has a 28pin EPROM plugged into a 32pin socket.
The main ROMS are the same as in A3020 etc
Acorn RISC OS 3.10 30th April 92
2 ROM set:
0296,061-01
0296,062-01
A4, A3010, A3020 & A4000