RISC OS 2 8mb compatibility

[steve3000]

For various reasons (mainly testing, games, etc), I'm building a multi-boot RISC OS system, including RISC OS 2.00. I'd like to get this working on an old Archimedes fitted with 8mb RAM, but hitting a problem.

RISC OS 3 works fine with 8mb, RISC OS 2.01 also does, and Arthur 1.2 works fine also (but only uses 4mb). However RISC OS 2.00 identifies 8mb, but crashes on entering the desktop.

I need RISC OS 2.00 since version 2.01 implements various changes to VIDC/sound which I want to avoid when testing...

So has anyone looked into why RO2.00 crashes with 8mb? And possibly found a solution?

Otherwise I'll plan to go through the startup code and try to locate the MEMC set up, to remove 8mb/2nd MEMC detection, which should get it running at 4mb at least.

[IanS]

I pressume Arthur has no idea about the extra memory and doesn't even check/look for it.
Sounds like support for detecting >4MB was added to RO2, but not fully tested. I only remember >4MB with my A540 which came with 2.01 (quickly upgraded to RO3).
Were there 3rd party 4MB upgrades in the era of RO2, did they come with any support software/modules to work on RO2?

[cmj6502]

The A540 could have 16MB, and that came with RO2. I have a feeling it was maybe 2.01 to support the extra memory, but not 100% sure.

[IanS]

The A540 could have 16MB, and that came with RO2. I have a feeling it was maybe 2.01 to support the extra memory, but not 100% sure.

My A540 came factory fitted with 2.01 (on EPROM, with dot matrix printed labels)

[geraldholdsworth]

Could you fire up Arculator, configure it for RO2 and 8MB and see if it sees it?

[geraldholdsworth]

Well...I just did just that and it doesn't like >4MB on RO2.

[richw]

Can you extract WindowManager from 2.01 and soft-load it (pre-desktop)?

I have a vague recollection that the changes to support 8MB were in the Wimp. Maybe.

[steve3000]

Thanks all, I've hacked away at RO2.00 and built a new version which ignores 8mb

Have only tested on emulation so far, but it boots fine to the desktop with only 4mb showing, even if 8mb+ enabled.

ROM attached here, along with brief details of hack.

[steve3000]

Can you extract WindowManager from 2.01 and soft-load it (pre-desktop)?

I have a vague recollection that the changes to support 8MB were in the Wimp. Maybe.

Great idea as definitely seems WIMP is the problem. But I only need for a few tests, so for now, I'll live with 4mb

[steve3000]

Have only tested on emulation so far, but it boots fine to the desktop with only 4mb showing, even if 8mb+ enabled.

...and just to confirm, the 4mb limited patch works fine on real hardware

[steve3000]

Can you extract WindowManager from 2.01 and soft-load it (pre-desktop)?

I have a vague recollection that the changes to support 8MB were in the Wimp. Maybe.

Great idea as definitely seems WIMP is the problem. But I only need for a few tests, so for now, I'll live with 4mb

Ok, I couldn't resist trying richw's idea out. So I dumped WindowManager v2.05 from RISC OS 2.01, and tried to soft load from Supervisor prompt on 8mb RISC OS 2.00, but it pops up an "Illegal header field in module" error!

And, after investigating, it's quite right.

The finalisation offset at &08 in the module header has bit 31 set. Very strange, as I can't see anything in the RO3 PRMs about this - presumably a flag for something?

Anyway, after removing this bit 31 from the header field, I could load WindowManager 2.05 on RISC OS 2.00 machine, replacing the ROM version 2.00...and then Desktop works without crashing, with 8mb present!

[sirbod]

tried to soft load from Supervisor prompt on 8mb RISC OS 2.00, but it pops up an "Illegal header field in module" error!

And, after investigating, it's quite right.

There are a couple of undocumented features with bit 31 set in the Start, Initialise and Finalise Modules header fields:

Bit 31 in Initialise indicates the Module is Squeezed and needs decompressing first
Bit 31 in Finalise indicates the Module can't be *RMCleared
Bits 31..28 in Start means it's a B instruction, not an offset

[richw]

Wow. I am slightly surprised it worked, but good result.

Of all the daft nonsense to remember! I think it was mentioned in the RISC User review of the A540, almost in passing (probably Acorn trying to keep a lid on expectations for more revisions of RISC OS).

[steve3000]

There are a couple of undocumented features with bit 31 set in the Start, Initialise and Finalise Modules header fields:

Bit 31 in Initialise indicates the Module is Squeezed and needs decompressing first
Bit 31 in Finalise indicates the Module can't be *RMCleared
Bits 31..28 in Start means it's a B instruction, not an offset

Ah, that's useful to know. Only the B instruction for Start, appears in RO3 PRMs.

Well now we know that RO2.01 supports the bit 31 in finalise...