ROM images and Virtual Acorn

I know that this site supports open software (so do I) and therefore is more geared towards RPCemu, but seeing as that is pretty much a work in progress, with some serious limitations in Windows, and Virtual Acorn seems far more robust, can anyone help with getting the IOMD version of RISC OS from here working on Virtual Acorn? It does not seem to succeed in starting up when I have tried it.

Many thanks,
Michael

Can you give any information as to where/how it fails? I’d be happy to try and fix it (as I’m sure a number of other people would), but I don’t have a copy of Virtual Acorn to test with.

Maybe I should try having a go with Red Squirrel, since I don’t think it works in that either.

VirtualRPC only works with ROM Images that have been encoded in some way to work with it. As such it’d require support from VirtualAcorn to either release the encoding algorythm, or encode them themselves.

Would that apply to the soft load version as well? I recall trying that but it also failed. The soft load version of RO6 does work ‘out of the box’.

Red Squirrel, since I don’t think it works in that either

VA forum, which looks as if it now leads back to you, Michael.

or encode them themselves

So VA would repackage the RO5 ROM, pay a licence to CTL (and presumably a licence to ROL too, considering their historical arrangement)?

The soft load version shouldn’t require the ROM to be encoded, as far as I know.

Although I did fix a couple of bugs in the ROOL softload tool recently, it’s possible that the slightly dodgy way the tool operates means that it doesn’t work on all emulators (I’m not sure if it’s ever been tried on RPCEmu). The code disables the MMU in one instruction and branches to the new ROM in the next, but doesn’t make sure that the logical & physical addresses of the MMU disable code match up. It relies purely on the instruction pipeline/instruction cache not being disrupted while the two instructions execute, otherwise it would end up executing random code/data/nothingness in place of the branch instruction. This seems to work OK for real machines (and AFAIK is the way Acorn originally wrote the tool), but it could easily cause problems for emulators.

It should be possible to rewrite the tool so that it behaves in a safer manner, but it might be a bit tricky to write a fool-proof algorithm.

Apropos of nothing, I’d like to see an open source virtual host as part of ROOL’s code base.

That is to say, not an emulator of any particular hardware configuration (as they all are at the moment), but a virtual machine target in its own right with no inherited limitations.

Although I did fix a couple of bugs in the ROOL softload tool recently, it’s possible that the slightly dodgy way the tool operates means that it doesn’t work on all emulators (I’m not sure if it’s ever been tried on RPCEmu).

It has and works fine. RPCemu will keep the existing MMU page lookup active until a page boundary is crossed, so it should always fetch the second instruction (though it’s usually prefetched in some form anyway).

Progress (of a sort):

I took the softload version of RISC OS 517 and put the ROM into the RISC OS 6 softload directory. It needed to be Squashed first. The machine booted successfully but there was no hard disc and no graphics other than a basic 800×600. It does not seem to work with more than 32M RAM either.

That is to say, not an emulator of any particular hardware configuration (as they all are at the moment), but a virtual machine target in its own right with no inherited limitations.

Gxemul may be worth a look. In addition to emulating various bits of real hardware (including various ARMs), it also has some very simple ‘test’ hardware devices: IRQ controller, clock, framebuffer, console, etc. If the ARM emulation is complete enough, then it should be pretty easy to knock up a HAL for it. See http://gxemul.sourceforge.net/

It also has some useful debugging features.

I took the softload version of RISC OS 517 and put the ROM into the RISC OS 6 softload directory. It needed to be Squashed first. The machine booted successfully but there was no hard disc and no graphics other than a basic 800×600. It does not seem to work with more than 32M RAM either.

No hard disc: I’m assuming Virtual Acorn usually uses HostFS (or similar)? If so then chances are that isn’t working because the virtual HostFS podule isn’t 32bit compatible. On the other hand, if you’re using a hard disc image then I’m not sure what the problem would be, since it works fine on a real RiscPC & RPCEmu (although I believe RPCEmu did need a couple of fixes to its IDE code in order for it to work under RISC OS 5?)

Graphics: Without an MDF being loaded by the boot sequence, you’ll be limited to just the old pre-RiscPC numbered screen modes.

RAM: Not sure what’s going wrong here, the ROM should be using the same RAM detection routine as RISC OS 3.5/.6/.7. Of course my real RiscPC only has 32(+2)MB, so it might be that there’s a bug somewhere which RPCEmu isn’t revealing.

Gxemul may be worth a look. In addition to emulating various bits of real hardware (including various ARMs),

Looks like that supports an IOP80321 target, so it shouldn’t be too hard to get a modified Iyonix HAL running on it. However I’m a bit concerned about the fact that all of their targets seem to be using the old legacy interface. Plus it doesn’t look like it’s been performance optimised yet (they’ve got some kind of bytecode which they translate instructions to, but no full-blown JIT)

I took the softload version of RISC OS 517 and put the ROM into the RISC OS 6 softload directory. It needed to be Squashed first. The machine booted successfully but there was no hard disc and no graphics other than a basic 800×600. It does not seem to work with more than 32M RAM either.

No hard disc: I’m assuming Virtual Acorn usually uses HostFS (or similar)? If so then chances are that isn’t working because the virtual HostFS podule isn’t 32bit compatible. On the other hand, if you’re using a hard disc image then I’m not sure what the problem would be, since it works fine on a real RiscPC & RPCEmu (although I believe RPCEmu did need a couple of fixes to its IDE code in order for it to work under RISC OS 5?)

ADFS doesn’t find a hard disc image because the IDE emulation in Virtual Acorn doesn’t respond to the software reset that is used to detect IDE devices. It would work with AutoDetectIDE set to FALSE. But to avoid a special ROM image for Virtual Acorn I have written a little plugin that corrects this behaviour. The plugin also modifies the IDENTIFY PACKET DEVICE command to make Virtual Acorn respond correctly.

With a little modification in the HAL code the error with more than 32M RAM can be corrected. Another modification is needed to work correctly with podules. At the moment ‘Tungsten’ is the only HAL machine where IRQ 8 and IRQ 13 can be shared by more than one podule.

I would like to have the confirmation of another Virtual Acorn user that it really works before I submit the changes to ROOL. If anybody wants to try it, I will be happy to send the plugin and a modified ROM image and give support to set it up.

What version of module ‘HostFS’ do you normally use?
Have you requested a 32bit version from Virtual Acorn?

What version of module ‘HostFS’ do you normally use?

The ‘HostFS’ module I have is
HostFS 0.62 (01 May 2004) © Graeme Barnes
and it is not 32bit compliant.

Have you requested a 32bit version from Virtual Acorn?

In a posting in the Virtual Acorn forum I said that 32bit versions of the modules would be needed to help RISC OS 5 work as good as possible. But I don’t think there is any interest from Virtual Acorn side to support RISC OS 5.

There seems to be two modules ie a filer mod and HostFS.
It seems there are different versions of HostFS – not one standard version.
It would be interesting – if the various versions could be listed.
ie module no and date.
Would someone on the Virtual Acorn forum like to ask if 32bitting of the modules – would be ok?

Hello Andreas,

I would like to have the confirmation of another Virtual Acorn user that it really works before I submit the changes to ROOL. If anybody wants to try it, I will be happy to send the plugin and a modified ROM image and give support to set it up.

If you still looking for someone I would like to test it. You could reach me at MatthiasF at gmx dot net

I would be happy to test it too!
My Email address is: rob at robheaton dot co dot uk

James Peacock’s post piqued my interest, so I downloaded the gxemul emulator. I noted that the documentation had a reference to Iyonix emulation, saying it was incomplete. So, I set the emulator up for ARM4/SA110 (cats board), created a disk image, and installed NetBSD. I’m typing this into the links text mode browser running on the gxemul_emulated machine, which is itself running on FreeBSD11, from a USB stick plugged into a notebook with no hard drive. So, until I get my real hardware, I’m playing around a bit …

The emulation is for a SA110 StrongARM 1999 vintage, still the gxemul may be of interest to others on this forum. At least I can vouch for its working on at least one platform :-)

I took a closer look at the gxemul documentation. The author made mention of the Iyonix emulation, and I interpreted his notes to mean he wasn’t sure of the ROM layout. He mentioned that most OS ROMs don’t work with the emulator. Apparently, a kernel image is normally supplied.

Please excuse my noobyness. From the forum entries, it’s plain that the average member here is a low level developer, or at least quite knowledgeable. I’m looking for some information about the HAL on RiscOS.

The past few days have made me somewhat comfortable with the GxEmul emulator. Thinking it would be nice to fix its Iyonix emulation, I meandered through a few HAL documents. I think I have the general playing field fixed somewhat correctly in my mind, with the HAL up front, and the kernel image and modules following its padded image space. GXemul executes with no problem up to 0×000003e8, and it then hangs in a loop between there and 0×0000067c, doing some I2C stuff.

I looked at the assembly in TOP.s and BOOT.s, trying to figure out what it was doing as it hung. Note that my last serious assembler work was thirty years ago :-) Oh well. I don’t want to waste anyone’s time here, but could someone point me to a very specific walk-through document for the HAL? I’ve seen the overview stuff, but it’d be nice to see a little more detail. Any links for me?

Edit: for asm, “low level” = “good”

Have you seen the wiki docs on the HAL? That’s about the best documentation that’s available, but it mainly focuses on the APIs rather than implementation details. Unfortunately there isn’t any documentation about how individual HALs are implemented. The best reference for that is just to read the HAL source code :-)

However, I do know a fair bit about the Iyonix HAL, so here’s a rough breakdown:

• The first 8KB of the HAL is separate from the rest. This is because it lives in a protected region of the flash memory. It also contains some recovery code so that if a corrupt ROM image is detected, you’re able to download and flash a replacement one via the serial port.
• Execution starts in s.Top
• initialise_rom, initialise_iic and initialise_ram will be called to set up the basic hardware. initialise_ram is in s.RAM, and uses IIC to talk to the memory sticks and determine their parameters – so that’s one place where the emulator could be getting stuck.
• After RAM is initialised, it will be cleared using the AAU. So if the AAU isn’t emulated then it’s possible it’s getting stuck there (or it might crash later on during the kernel initialisation, as the kernel will be expecting the HAL to have cleared RAM)
• The ROM image will then be copied to RAM, and execution will switch to the RAM copy. I’m guessing the emulator can’t have reached this far, otherwise you’ll be seeing it hang at a completely different address.
• The ROM checksum is checked during the copy operation; if the check fails it’ll enter the flash recovery code. If GxEmul emulates the serial port you should be able to spot if that ever happens (it’ll start printing out a message asking for a new ROM – see s.FlashProg)
• If everything is OK then it’ll branch to rom_checkedout_ok in s.Boot (which will be located outside the 8K protected region).
• From there it’ll pass execution control onto the kernel by calling RISCOS_Start. The kernel will enable the MMU and start allocating memory for things, so if something went wrong with the RAM detection then you can expect it to fail during that stage.
• During kernel initialisation (after the MMU is enabled), HAL_Init (located in s.Boot) will get called and the HAL will initialise the rest of the hardware.
• After that the kernel will enable interrupts and start running the 100Hz timer. With the help of the HAL it’ll also do a keyboard scan to check for any special keys – this will need OHCI emulation to work properly, and might get stuck if it’s not working.
• At some point the kernel will also try using IIC to talk to the CMOS RAM, and the HAL will probe IIC for the RTC chip. But those devices aren’t mandatory – so as long as the IIC emulation is capable of returning a “no acknowledge” result the OS shouldn’t get stuck anywhere.
• After that the kernel will start initialising all the modules. As most of the interesting stuff (audio, video, USB) is PCI connected the modules should fail gracefully if the hardware isn’t found. But without video emulation you’ll be a bit stuck working out whether the OS booted OK :)

If you’re able to build your own ROM image you could enable some of the debug options. The two most important options being the Debug option in hdr.80321 and DebugTerminal in castle.RiscOS.Sources.Kernel.hdr.Options. With both of those enabled you should be able to use the serial port to follow the ROM initialisation progress, and to interact with the command line should the OS get that far.

Gulp

Excellent! If you don’t hear from me for a few months, you’ll know what happened! As it turns out, the advantage of being semi-retired is that you get to pick your own projects! Thanks much …