IOMD ROM issues

I think having a fully working free emulation system is absolutely crucial to having any kind of future for RISC OS.

The RPCEmu web site cites several problems with the RISC OS 5.15 IOMD ROM. I don’t think anything has changed so far e.g. with RISC OS 5.16. The issues mentioned are:

1. Does not support IDE harddiscs or CDROM.
2. Only works on A7000 machines.
3. Only supports 8MB RAM and 0MB VRAM.
4. Hardware scrolling does not work, leading to graphical glitches. eg. F12 to get to a command prompt.
5. Resets CMOS RAM (configuration) on machine reset.

I think 3, 4 and 5 are particularly important.

Has anything been done about these problems? How far up ROOL’s priority list are the IOMD ROM issues?

Has anything been done about these problems?

Not that I know of.

How far up ROOL’s priority list are the IOMD ROM issues?

I can’t find any reference to it, but I’m fairly certain that ROOL said that the IOMD ROM would be their main priority once the OMAP3 port settles down. Of course things can cause priorities to change (e.g. the appearance of the Iyonix RTC bug), and I don’t think any of them have really had much time to do any ROOL-related work recently, so it’s hard to say when they’ll get round to it.

With regards to the problems you’ve raised – I think issues 3, 4 and 5 will actually be quite easy to solve – perhaps even solvable in a day. Say “pretty please” and I might even try it myself!

Pretty please!

Seriously, getting access to the latest ROOL OS on RPCEmu would be great. I’d like to do some more work on the BASIC Apps in due course, and although this is perfectly possible on my VRPC/RO4.02 setup, it would obviously be preferable to at least be able to test changes on RO 5.x.

This also depends on how RPCEmu on Windows is going, of course. AFAIK, it’s some way behind the Linux version at the moment, but that may have changed.

Pretty please!

Solving those would be really great. :)

Chris: As far as I know, the only difference is that the Windows version currently has no networking support.

DRAM+VRAM detection is now working (or at least, it seems to work under RPCemu). But if the latest version of RPCemu spoon edition is anything to go by, the mouse only works if you use a 7500 or 7500FE CPU - which means you won’t be allowed to have any VRAM. Not sure if the mouse problem is RISC OS or RPCemu that’s at fault.

Yay, progress!

I asked flibble (one of the RPCEmu developers) about the mouse problem. He said that the reason it only works with 7500 and 7500FE CPUs is because the processor selector in RPCEmu is used to decide which hardware to emulate (e.g. A7000 or RiscPC). The A7000 used PS/2 for the mouse and the RiscPC used Quadrature for the mouse. The problem is that the ROOL ROM currently lacks Quadrature mouse support.

Hardware scrolling works now. Looks like it was inadvertently broken just over 7 years ago when a new DAG # was added to HAL_Video_SetDAG/GraphicsV_SetDMAAddress, for use by the NVidia module. The IOMD HAL code wasn’t checking for unexpected parameter values, and so was ending up programming VEND to the nonsense value of VINIT-(DMA fetch size).

Of course, I would have found the problem several hours ago if I’d thought to check for API changes! (or even noticed that there was one extra piece of code calling SetDMAAddress than there should have been)

Good news on the scrolling. :)

Do you know if the Quadrature mouse thing is a component that ROOL have yet to release, or if it’s just not present in the ROM or broken?

Do you know if the Quadrature mouse thing is a component that ROOL have yet to release, or if it’s just not present in the ROM or broken?

It turns out it’s already in the ROM image – you just need to use *configure mousetype 0 to select quadrature instead of PS2 (which is what mouse type 3 was)

Ah, cool, so it works with StrongARM emulation and 2MB VRAM, once you set mouse type to 0?

Not quite – it seems to be a bit touch-and-go getting it to boot using StrongARM emulation (with both the interpreter and recompiler). 610/710 seems to work fine though.

CMOS RAM should now be working too – just be aware that if you delete the RPCemu cmos.ram file, RISC OS doesn’t seem to detect that the default contents (all zeroes?) is invalid, so you’ll end up with funny settings. And the bootup keyboard scan code isn’t implemented, so there’s no way of resetting to the correct values by holding R/Delete/etc.

Hi Jeffrey, Can I ask about a recent change you made.

http://www.riscosopen.org/viewer/revisions/logs?ident=1265072215-163370.html

“s/NVRAM – Changed the NVRAM setting from ‘MaybeIIC’ to just ‘IIC’, as a workaround for RPCemu’s apparently buggy support for IIC probing (plus we know the address of the RTC/CMOS chip anyway – no need for the kernel to probe for it)”

What is the command sent for probing? and what are you expecting as a reply? Also, have you tried it on real hardware to confirm that’s what it should be doing?

I’d rather fix RPCEmu than have additional hacks in the ROOL rom :)

It looks like there are two methods used for probing – the “original” method (which I think may have been introduced for the Stork) sends an IIC write command with 0 bytes of data (i.e. it just sends the chip address and the read/write bit). If the chip exists then it should acknowledge the request without actually doing anything to its internal state.

However due to problems with the IOP, by default the HAL kernel uses a different method – to attempt to read one byte from the target device. For EEPROM-type devices that need to be told which register to read/write from, this would presumably end up reading from a random register in the chip, since it doesn’t involve telling the chip which register to read from.

The bit where RISC OS does this is the DummyAccess routine near the bottom of i2cutils.s. In the case of RPCemu, it seemed like the first dummy read it tried (to a 2K EEPROM chip) was succeeding. I can’t actually remember if I was trying the IOP method or the ‘old’ method at the time that I spotted the failure (I suspect the IOP method), but AFAIK RISC OS 3.X doesn’t probe for IIC devices at all, so it’s possible that RPCemu hasn’t had to deal with either case in the past.

Also, since you’re here – RPCemu’s emulation of the IOMD VIDCR register is wrong – reads always return “vidcr | 0×50”. This is correct (ish) for 7500/7500FE, but incorrect for RiscPC’s. Bits 0-4 should be the DMA fetch size (I’m not 100% certain of this – but they’re definitely related to the fetch size – you’d have to wait until I get home if you want me to check), and bit 6 controls ‘DRAM mode’ for if you want the video controller to use DRAM instead of VRAM. The correct behaviour of the register, AIUI, is for all bits to be writeable on RiscPC’s, and for only bits 7 and 5 to be writeable on 7500/7500FE (with the remaining bits being forced to 0×50, which is the configuration RISC OS programs for when a RiscPC has no VRAM - DRAM mode enabled, 16 byte DMA fetch size). Writeable bits should be zero on reset.

For this info I was going by the various bits I’d gleaned from the OS source, and the 7500 TRM/manual that was supplied on AUCD 1 (I suspect there are other sources of info around, but I remembered I had that one to hand). Also I’m fairly certain some of the other registers (VIDINIT, VIDEND, etc.) weren’t returning values when I was reading them under RPCemu, which is contrary to the spec.

I was going to contact you (or another RPCemu dev) about these issues tonight, but I guess you got here first :)

Also – this may just be a bug in RISC OS - but RISC OS 5 doesn’t seem to identify RPCemu’s 7500 emulation as being a 7500 CPU. Instead of printing out the CPU type it just prints out nothing, because it doesn’t recognise it. Everything else (except 810, which I didn’t try) seems to work fine though.

Not quite – it seems to be a bit touch-and-go getting it to boot using StrongARM emulation (with both the interpreter and recompiler)

Any idea why?

CMOS RAM should now be working too

Excellent! Does RISC OS now boot straight into the desktop, or do you still have to do the “configure mousetype n” and “desktop” commands?

I’ll try it once ROOL update the RISC OS 5.17 downloads. :)

IIRC the StrongARM doesn’t have any proper cache cleaning mechanism, so RISC OS sacrifices a section of RAM to use for cache cleaning. At the moment (assuming RISC OS pays attention to what the HAL says), this section is at the start of physical RAM - which is also where some important data is stored during the pre-MMU stage, and is also where screen memory will be once the MMU is enabled. So it could be that which is breaking it. If it’s not that, then I’m not sure what it is ;)

Excellent! Does RISC OS now boot straight into the desktop, or do you still have to do the “configure mousetype n” and “desktop” commands?

There should be a *configure option to set the boot filing system – if you set that to the FS number of hostfs then I believe you should be able to get it to boot using a real boot sequence (e.g. the ROOL one)

I just looked at the IOMD ROM wiki page and it says “doesn’t have networking support”. Is that still the case? The RPCEmu page doesn’t mention that issue.

The ROM image has the internet stack, but no network drivers (that I can see). I’m not even sure if the source code for the podule/RiscPC NIC drivers has been released. And there’s no serial/parallel port support at the moment, so you can’t network through that either.

Just to try and tempt some people into doing some work on the IOMD ROM (since you’re all so enthusiatic about it!), the comments in the components file suggest that the main problem with most of the missing modules is that they need to be able to look up the IOMD address at runtime instead of assuming it’s at its pre-HAL location. These are fairly easy changes to make if you’ve got a decent knowledge of assembler. The only thorny issue is deciding how to deal with modules that have changed a bit since RISC OS 3.X (e.g. ADFS) – for which you just need to prod ROOL a bit for their thoughts on how they want the issue handling (i.e. whether to use a build switch to force it to use IOMD code, or whether to add/revise the HAL interface so that the same module can be used on both IOMD and Iyonix)

The ROM image has the internet stack, but no network drivers (that I can see). I’m not even sure if the source code for the podule/RiscPC NIC drivers has been released.

OK. I mentioned it to flibble and he says it might work on RPCEmu. Its networking works by faking a network driver, although it might not be 32-bit clean.

There should be a *configure option to set the boot filing system – if you set that to the FS number of hostfs then I believe you should be able to get it to boot using a real boot sequence (e.g. the ROOL one)

Actually you can just use the FS name, however booting isn’t supported with HostFS. There are two ways around this…

1. Create a small hard disc image with an obey file called !Boot in the root dir with the following contents:

*HostFS:!boot

And then use the hard disc to boot. I assume that there is no hard disc driver available for the IOMD/HAL yet, so this option isn’t much use.

2. Start off the Desktop, Press SHIFT+CTRL+F12 to shutdown, then once you get the final window press SHIFT+CTRL+F12 to exit to a blank screen, then again type:

*HostFS:!boot

Booting is supported with EmuFS but AIUI this is only available with the ‘original classic’ RPCEmu not Spoon. I did briefly try to use the original RPCEmu, but I found a couple of ROOL modules would cause problems with it namely TaskWindow and the new FontManager.

So the best thing to do is to port EmuFS to RPCEmu Spoon.

OK. I mentioned it to flibble and he says it might work on RPCEmu. Its networking works by faking a network driver, although it might not be 32-bit clean.

The EterRPCEm module has its 32-bit flag set, so it should be 32-bit clean.

IOMD 2010-02-03

Looks like the ROM download has been updated. I’ll test it this evening. :)

Edit: Ah, only the source archive is up-to-date.

however booting isn’t supported with HostFS.

Hmm, that’s a shame. If HostFS supported booting then ROOL could have started making use of RPCemu + the IOMD ROM for running the autobuilder; i.e. actually run it on the server hosting the site, so they can keep all the archives up to date without worrying about using too much bandwidth.

Of course, they could still make use of it now if they left the emulator running all the time and had RISC OS periodically check for new source code, but that probably isn’t as reliable or convenient a solution as if the emulator could be configured and launched automatically.

As a stopgap replacement for ADFS hard drives it may be possible to use ZIDEFS . It’s quite simple – just uses PIO, not even interrupts. A small bit of patching will change the IO base address, or else RPCEmu could emulate the basics of the ICS IDE podule (indeed, ISTR there’s already some code to do this).

The ZIDEFS web page states that it isn’t 32bit compatible. Fixing ADFS to work with the IOMD ROM would probably be the better option.

Wouldn’t it be better to just implement a simple filecore fs which directly accesses a filecore image made available via the native side of RPCEmu? Surely going through a non-perfect IOMD emulation first and fighting ADFS’ niggles is a lot more work?

I don’t think that would be any better than fixing ADFS, nor necessarily any easier.

Updating ADFS to work with the IOMD ROM image is inevitable; if one of us doesn’t do it then ROOL eventually will. And until someone asks ROOL what their preference is (i.e. a patched up old version of ADFS or a HAL backend for the new version), and then checks to see how much work that is, we can’t be certain that any stopgap solutions would be quicker or easier than just simply fixing ADFS. And although RPCemu’s IOMD emulation may not be perfect, if it’s good enough for ADFS on RISC OS 3/4/6 then it should also be good enough for RISC OS 5.

The only thing I can think of that would be a sensible stopgap would be to update HostFS to allow its use as a boot device. I’m assuming this is a trivial change to make (otherwise I wouldn’t be suggesting it), but I’m not familiar enough with the implementation of filing systems under RISC OS to say for certain.