Red Squirrel Support

Is it possible to change the emulation detection code so RO5 works on Red Squirrel?

Suggested code change:

LDRB    r4, [r5, #IOMD_VERSION]
TEQ     r4, #0   ; RPCEmu has version ID of zero
TEQNE   r4, #&9c ; Red Squirrel has version ID of 9C
MOVEQ   pc, lr

And while we’re about it, rename the “RPCEmu” forum to “Emulators” or something more suitable?

Do you know what IOMD_VERSION is reported by real hardware? (A7000, A7000+, RiscPC)

The ARM7500/7500FE datasheets don’t indicate what version number is returned there, and I daren’t touch my RiscPC at the moment in case I disrupt the beagleboard which is busy trying to track down the TickerV corruption.

A7000+: 1
RPC: 3

Yep, that looks about right. It looks like RPCEmu used to return correct values (3 for RiscPC & A7000, 1 for A7000+) but was then changed to return zero so that RISC OS 5 could detect it. So I can’t imagine there being any problems with us skipping the test for a version of &9c.

Looks like &9c applies to VRPC as well.

If the model is set to [VRAM = 0] the older versions of RO5.19 (19Jun2012) makes full use video ram (upto 32Mb).
Later versions and RO5.21 still let the screen memory slider to go up max value – but screens res is now very restricted.
What changed?

That was probably when the VIDC bandwidth limit handling was moved into the video driver instead of being handled by the *command.

If we can safely detect emulators by looking at IOMD_VERSION, I guess there’s no real reason why we can’t remove the bandwidth limit for them.

Excellent news, I’ll test on the emulators I have once it’s submitted.

If we can safely detect emulators by looking at IOMD_VERSION, I guess there’s no real reason why we can’t remove the bandwidth limit for them.

No, that would be truly terrible. The VIDC20 driver gets the amount of VRAM using a legal OS SWI and adapts the allowed modes appropriately (modulo the maximum VRAM/clock that a real VIDC20 would permit). This in turn is autodetected by probing the memory space that would have VRAM in it on a real Risc PC – not some backdoor check of an unimplemented emulator register.

I just looked at the POST source and immediately spotted the problem. TEQNE r4, #&9c ; Red Squirrel has version ID of 9C

No, you’ve not spotted the problem at all – the problem is that the emulator isn’t emulating the timing of VIDC (with respect to IOMD) correctly. That’s an emulator fault, not a cause to jump round things in RISC OS.

Looks like &9c applies to VRPC as well.

That’s because VRPC is the commercial development of the RedSquirrel source, isn’t it?

It looks like RPCEmu used to return correct values (3 for RiscPC & A7000, 1 for A7000+) but was then changed to return zero so that RISC OS 5 could detect it.

Other way round, it used to be incorrectly reporting 0, and we used that as temporary skip (I added) for RPCEmu. When RPCEmu then tried to improve their emulation of IOMD (by getting the version register right) the horribleness has now been enshrined in stone requiring them to change it back just so RISC OS 5 will boot. I discussed the options here but it looks like nobbling the version register (again) was easiest.

Rather than fritter developer time bodging RISC OS, can Jon/Colin (who seem to be the only 2 people in the world using the 13 year old abandoned RedSquirrel emulator) go and fix the emulators – either to emulate the chipset properly, or improve RPCEmu so it does whatever you’re clinging onto the furry version for.

I’ll test on the emulators I have once it’s submitted.

…and I’ll be poised to revert the change minutes later.

Given what Sprow has said – and given the surely tiny number still using RedSquirrel, wouldn’t it be easier to apply a one word patch to get RedSquirrel to return a recognised ID?

Ah, I’d falsely assumed that since we were making concessions for emulators that it was OK to make concessions for emulators.

If that’s not the case, then I’m all for removing the RPCEmu hack and forcing them to fix their emulation.

Are you surgesting disasmbling the exe files and trying to find out how they work!!
If getting RSq and VRPC working working with RO5.21 with large screens modes is of no interest….

bq No, you’ve not spotted the problem at all – the problem is that the emulator isn’t emulating the timing of VIDC (with respect to IOMD) correctly. That’s an emulator fault, not a cause to jump round things in RISC OS.

In that case, the check should be removed from RISCOS completely. I don’t understand why there’s a concession and a specific forum group for RPCEmu when other emulators exist and exhibit exactly the same behaviour. For the sake of a single instruction to bypass the POST I really don’t understand the stance here.

That’s because VRPC is the commercial development of the RedSquirrel source, isn’t it?

Correct, it’s the same codebase.

Rather than fritter developer time bodging RISC OS, can Jon/Colin (who seem to be the only 2 people in the world using the 13 year old abandoned RedSquirrel emulator) go and fix the emulators – either to emulate the chipset properly, or improve RPCEmu so it does whatever you’re clinging onto the furry version for.

It’s hardly frittering developer time by adding one instruction. RPCEmu has major flaws with it’s MMU emulation which I reported to the devs over a year ago, Red Squirrel doesn’t have these problem, so it’s currently the only emulator devs can use for RO5 IOMD where an accurate MMU is required.

…and I’ll be poised to revert the change minutes later.

How childish.

There may be an alternative here, revert the RO5 POST model to a more traditional style (RO3, RO4)

Old model

1) POST fails
2) Set screen border to red
3) Flash out fault codes on floppy drive light
4) Carry on and try and boot regardless (the important bit)

New model (I beleive similar to the NCOS style)

1) POST fails
2) Stop

It may be that the old model is more usful for real Risc PC hardware, regardless of the emulator question.

There may be an alternative here, revert the RO5 POST model to a more traditional style (RO3, RO4)

Old model
1) POST fails
2) Set screen border to red
3) Flash out fault codes on floppy drive light
4) Carry on and try and boot regardless (the important bit)

Much as I use RPCEmu for such things as experimenting with the DDE and working on old code updates as a learning exercise I would say that IF the code is reverted to that model for convenience of use on emulators then surely any stage 4 "carry on and try and boot regardless should surely have a nice BIG message saying the emulation is incorrect hanging around for 20-30 seconds before carrying on.¹

Then the users can pester the emulator authors to provide the right feature so that the message goes away permanently.

Now that’s what I call the middle way, make it work but tell people what’s wrong and allow it to work without the warning if the emulator is fixed.
Presumably VRPC could be fixed too. OK that last bit is a touch unlikely.

¹ I like helpful error messages

Having reviewed this thread:

Current code:

[ {TRUE}
  LDRB    r4, [r5, #IOMD_VERSION]
  MOVS    r4, r4                  ; RPCEmu has version ID of zero
  MOVEQ   pc, lr                  ; Skip tests if running emulated
]

The proposed code appears to add a single word to allow the second emulation test to work.

I support this modification.

I originally thought that the proposal was to skip some of the tests if running on an emulator, but now I can see that RISC OS already does this. Why is it such a hardship to support another emulator? Or, to look at it another way, what makes RPCEmu special? ;-)

As to whether or not it should be done – the answer is simple. Somebody should build an IOMD version with the modification in place. Does RISC OS 5 then work on RedSquirrel? If so, there’s your answer.

RPCEmu has major flaws with it’s MMU emulation

Just out of interest, what flaws? The MMU works sufficiently that RISC OS runs… or is that the problem, it only implements what RISC OS needs?

Or, to look at it another way, what makes RPCEmu special? ;-)

It actually has active maintainers?

I originally thought that the proposal was to skip some of the tests if running on an emulator, but now I can see that RISC OS already does this. Why is it such a hardship to support another emulator? Or, to look at it another way, what makes RPCEmu special? ;-)

My point exactly, there’s already a precedent set for RPCEmu so there’s no reason to exclude other emulators.

RPCEmu should not receive special treatment either within RISCOS or on this forum. The “RPCEmu” forum needs to change to something that covers all emulators running RISCOS.

Just out of interest, what flaws? The MMU works sufficiently that RISC OS runs… or is that the problem, it only implements what RISC OS needs?

The MMU doesn’t implement memory security. eg. !&F0=0 from BASIC will work under RPCEmu, but should throw an exception, IIRC it doesn’t check L2PT when memory is accessed.

“surely any stage 4 “carry on and try and boot regardless should surely have a nice BIG message saying the emulation is incorrect hanging around for 20-30 seconds before carrying on.”

Unfortunately it can’t be an ‘RPCEmu’ specific message, as it is also would be displayed on real hardware that is starting to fail. Making the POST actually display what the errors are to the user on screen may be a useful addition (assuming enough of the earlier tests for Memory etc have passed).

In summary, here’s why I suggested changing the general POST behaviour

1) For real RPC users, they get the traditional behaviour rather than an unhelpful stop on all POST failures? (including CMOS checksum failure?)
2( ROOL get to get rid of the RPCEmu ‘hack’ in the code to bypass the POST if a IOMD version is 0
3) RPCEmu gets to get rid of the ROOL ‘hack’ of having to return IOMD versions of 0, instead of the correct values.
4) Redsquirrel works with RO5 (Virtual Acorn won’t unless you also encrypt the RO5 ROM image in a manner that VA likes)
5) RPCEmu gets to use RO5 as a testbed for VIDC timing changes (actually fixing the underlying emulation issue ¹) without overly annoying the users in the mean time (people aren’t practically bothered by the POST failures on RO3/4/6)

“Or, to look at it another way, what makes RPCEmu special?”

Erm, ROOL wanted it to work with RO5, so they could sell the combo? :) (which is why this is a RPCEmu forum, not an ‘emulators’ forum, it’s because ROOL sell a copy of RPCEmu with RO5 and this is the first line of support for that product)

“Just out of interest, what flaws? The MMU works sufficiently that RISC OS runs… or is that the problem, it only implements what RISC OS needs?”

Permissions issues are not always accurate, sometimes cached when incorrectly when they’re used in a JIT block, it is on the list of things to look at, after tidying up the load/store instructions first. Address Exceptions and vector exceptions aren’t implemented yet. TLB needs a nice rewrite. (this is a bit of a bad summary as it’s normally my brother that looks at this bit).

1] Which I’ve not really investigated that much into why, the ‘fudge the IOMD version back to 0’ hack went into RPCEmu as I ran out of time to look before the next release was due.

“My point exactly, there’s already a precedent set for RPCEmu so there’s no reason to exclude other emulators.”

And it’s a terrible precedent, instead of adding another hack for another emulator, remove both and have the regular code carry on, like RO that shipped on thousands of machines.

what makes RPCEmu special?

Its lovely developers of course :-)

Does RISC OS 5 then work on RedSquirrel? If so, there’s your answer.

Hmm…

I downloaded the current IOMD nightly and patched +&1BCC to be MOV PC,R14 (so it will always drop out of self test). I then tried running it as a part of my normal boot. When that “failed”, I then tried running it with a simple Obey file that sets a few paths and then calls the softload directly.

Result? The activity indicator shows that something is happening, but all I see is a blank screen. As far as I’m aware, there is no trace facility in RedSquirrel so I can’t see what is being executed.

The console report shows this happening as RISC OS 5 initialises:

IOC WriteByte 0x1f4, 0x0
DS set frequency 6/1us, 166666Hz
DS set real freq 48us, 20833Hz
IOC ReadByte 0x48
IOC ReadByte 0x4c
IOC ReadByte 0x58
IOC ReadByte 0x5c
IOC ReadByte 0x7c
IOC ReadByte 0x88
IOC ReadByte 0x90
IOC ReadByte 0xb0
IOC ReadByte 0xb4
IOC ReadByte 0xb8
IOC ReadByte 0xbc
IOC ReadByte 0xc0
IOC ReadByte 0xd8
IOC ReadByte 0xdc
IOC ReadByte 0xfc
IOC ReadByte 0x100
IOC ReadByte 0x104
...SNIP 415 LINES OF THIS!...
IOC ReadByte 0xf98
IOC ReadByte 0xf9c
IOC ReadByte 0xfb8
IOC ReadByte 0xfbc
IOC ReadByte 0xfcc
IOC ReadByte 0xfe4
IOC ReadByte 0xfec
IOC ReadByte 0xffc

After that, blank screen. Nothing else happens if left for three minutes.

In the interests of fairness, I threw the modified ROM image at RPCEmu v0.8.9. It booted normally.

Is there something else I need to do to get RISC OS 5 to work on RedSquirrel?

Is there something else I need to do to get RISC OS 5 to work on RedSquirrel?

You need to reset your CMOS, see my post on to how to bypass the POST

4) Redsquirrel works with RO5 (Virtual Acorn won’t unless you also encrypt the RO5 ROM image in a manner that VA likes)

From the info posted previously by Colin that appears to amount to compressing it using an LZW algorithm and tacking a set of bytes onto the start of the resultant file.
Comment based on the means of turning RO6 into a normal image amounts to stripping off 20 bytes¹ from the start and then decompressing the remnant.

¹ As I recall. Feel free to shoot if I got the number wrong.

And it’s a terrible precedent, instead of adding another hack for another emulator, remove both and have the regular code carry on, like RO that shipped on thousands of machines.

This sounds sensible, the fact RO5 hangs on a POST failure seems to me to be a serious flaw in the OS which needs addressing.

From the info posted previously by Colin that appears to amount to compressing it using an LZW algorithm and tacking a set of bytes onto the start of the resultant file.

I’ve got RO5 running under VirtualRPC-SE without doing this.

And it’s a terrible precedent, instead of adding another hack for another emulator, remove both and have the regular code carry on, like RO that shipped on thousands of machines.

Ah, but the problem is that RISC OS will go from working on an emulator to working only on real hardware. I NOPed out the check to see what happens. RPCEmu has been “contemplating” for about five minutes now. ;-)

Thank you both for explaining the MMU issues.

As for the precedent – I would suggest that at this time it shouldn’t hurt to add RedSquirrel to one of the recognised emulators if (and only if):

1. It doesn’t have unintended side effects (such as skipping the POST on real hardware)
2. That’s all that is necessary to get it working (i.e. I have done something wrong in my test and RISC OS 5 should have started…)
   If it affects real hardware, or if that is only the start of “tweaks” necessary to get it running on a really really old emulator – then it’s a non-starter really.

Why?

Simple. We don’t exactly have a lot of emulators capable of running RISC OS 5. In fact, RedSquirrel (maybe) and RPCEmu are pretty much it. VRPC may be a contender but it seems to obfuscate itself for the sake of it.

Why?

Choice. If one instruction provides a choice, it seems churlish¹ not to. But this is assuming that this one small change is all that is necessary.

¹ Churlish, as city folk should know, is on the Circle line between Weston Mannering and Mornington Crescent…