IOMD development / issues

I’ve been doing some development of the IOMD branch (nothing in CVS yet!) and have got to the point where I need to ask questions, and possibly show stuff off. So far :

• The ‘double-reset’ needed under RPCemu has been fixed-ish. What happens is RISC OS enables keyboard interrupts but doesn’t install a handler, so when the power-on reset character comes through it never acknowledges the interrupt and gets stuck. My fix was to prevent keyboard interrupts being initially enabled in the HAL, but this might break power-on CMOS clearing?

• Detection has been added for extended VRAM on RPCemu, though this needs testing to make sure it doesn’t cause problems on real hardware.

• The jump table in HAL.IOMD.s.Video is broken – it doesn’t have the offset for the ROM, so all jumps point into zero page. I’ve fudged this for now, but a proper fix would be better.

• I’ve written basic HAL ATA support, though again I don’t know if it works on real hardware.

• I’ve got ADFS to work, along with the ATA support. Not sure how ROOL want this handled, though – there are several code paths that won’t assemble (presumably they’ve not been tried for years) and I’ve had to comment out a few lines in various ADFS files. This doesn’t seem to affect functionality in the slightest. The only non-conditional part that’s changed is the ‘TwinIDE’ variable, as RiscPC/A7000 only have one controller. Or maybe I should leave it in and it might work on RiscStation/Mico?

The upshot is a somewhat useable system on RPCemu, as pictured here.

Sounds good! When I had a spare evening I was intending to take a look at that list of issues that Peter posted, but obviously that hasn’t quite happened yet. Sounds like you’ve managed to work through most of them yourself.

My fix was to prevent keyboard interrupts being initially enabled in the HAL, but this might break power-on CMOS clearing?

Unless you’ve written some code to handle that yourself, it looks like the IOMD HAL doesn’t support scanning the keyboard at boot. Perhaps that’s why the problem occurs in the first place, since the ROM currently doesn’t do any interaction with the keyboard during kernel initialisation.

The jump table in HAL.IOMD.s.Video is broken – it doesn’t have the offset for the ROM, so all jumps point into zero page. I’ve fudged this for now, but a proper fix would be better.

Interesting, I would have thought that objasm would have relocated those values. But then again I’m not an expert on objasm’s syntax.

I believe the preferred method for doing jump tables now is to use ADD - i.e. ADD pc,pc,r4,LSL #2, then replace each table entry with a branch instruction. That way it’ll be fully position independent.

I don’t suppose you’ve looked at the potential brokenness of HAL_CleanerSpace? AIUI it needs to return a pointer to memory that’s never used in order for StrongARM cache maintenance to function correctly, but at the moment it returns a pointer to the start of physical RAM, which will certainly get used during ROM initialisation.

I’d offer to help with testing on real hardware, but before that can happen I think we need to update the softload tool to cope with RiscPC’s and/or the IOMD HAL to cope with softloading. Plus we’d really need the UART drivers adding to the HAL so we can get a debug terminal working.

About ADFS and ATA support: IIRC the “TwinIDE” stuff was developed for the original Risc PC/the Medusa prototype. Again IIRC, it featured two IDE controllers. Or maybe it was meant for Phoebe?

Anyway, both RiscStation and Mico (and Omega) use their own IDE implementation (RiscStation use the same as Simtec IDE and UniPod, Mico and Omega use the same as the APDL IDE podules ideA and Blitz) and consequently don’t use ADFS for harddisc stuff. Not sure about floppy support.

I don’t suppose you’ve looked at the potential brokenness of HAL_CleanerSpace?

Haven’t looked at it yet, as it’s not broken anything – even with RPCemu in StrongARM mode. Will put it on my todo list though.

I’d offer to help with testing on real hardware, but before that can happen I think we need to update the softload tool to cope with RiscPC’s and/or the IOMD HAL to cope with softloading.

I thought softload was working? Was ROOL’s demo on an A7000 ages ago done with ROMs then?

Anyway, both RiscStation and Mico (and Omega) use their own IDE implementation (RiscStation use the same as Simtec IDE and UniPod, Mico and Omega use the same as the APDL IDE podules ideA and Blitz) and consequently don’t use ADFS for harddisc stuff.

Interesting. I don’t have access to either, but photos of the mainboards don’t seem to show anything other than a SuperIO chip, and I’d therefore have expected to find the second IDE channel at ports 170-177 like on a PC.

I thought softload was working? Was ROOL’s demo on an A7000 ages ago done with ROMs then?

No idea, actually. Looking at the HAL it looks like it might work OK (and IIRC Acorn/Castle did RiscPC softloads in the past), so maybe it does work. Maybe I should just try it and see what happens!

Just had a play – the softloader needs a slight fix before it will work. In s.startnew, under the ‘doneflush’ label, the code :

LDR r4,LDRPCInst ;check if 1st instruction of the form LDR PC, [PC, +/-#x] TEQ r4, r3, LSR #16

needs changing to

LDR r4,LDRPCInst ;check if 1st instruction of the form LDR PC, [PC, +/-#x] TEQ r4, r3, LSR #12

Seems fine after that.

Sounds very good news!

The jump table in HAL.IOMD.s.Video is broken

I think the problem is that the link command in the makefile is missing -base 0xFC000000. Without this, the linker sets absolute addresses as though the binary was based at &8000.

I’ve got ADFS to work, along with the ATA support. Not sure how ROOL want this handled, though – there are several code paths that won’t assemble

We’re probably going to have to live with there being a separate build variant of ADFS for IOMD machines, mainly because the floppy support is so radically different (FIQ based rather than DMA based). The way to do this is specify an argument to the makefile – and the way to do that as part of a ROM build is to edit the Components file (BuildSys.Components.ROOL.IOMD32), using a -options switch.

IIRC the “TwinIDE” stuff was developed for the original Risc PC/the Medusa prototype. Again IIRC, it featured two IDE controllers. Or maybe it was meant for Phoebe?

More likely you’re thinking of the SWI that lets you set an alternative IDE controller address – that’s not the same thing at all. TwinIDE was indeed the switch introduced during Phoebe development, since Phoebe was to support two IDE controllers (and thus 4 ATA/ATAPI devices). The switch was also used to support the twin IDE controllers in Iyonix.

I thought softload was working? Was ROOL’s demo on an A7000 ages ago done with ROMs then?

No, and the IOMD HAL wouldn’t work from ROM at the moment due to lack of any code to initialise the RAM controller. I used the SoftLoad tool for that; SoftLoad was originally written for the Risc PC, and was originally used in-house at Acorn before later being distributed with RISC OS 3.8. It’s possible the work Adrian did to allow it to do softloads on the Iyonix has broken it for the Risc PC.

No, and the IOMD HAL wouldn’t work from ROM at the moment due to lack of any code to initialise the RAM controller.

Are you sure? It looks like everything’s there already (remember that I copied over the RAM/VRAM detection code a few months ago)

Also, about the HAL_CleanerSpace stuff: It looks like the pre-HAL kernel used ROM bank 1 (physical address &01000000) – see Kernel.s.ARM600 lines 1936 & 3420.

I’ll try and give this a go tomorrow on my StrongARM and see what happens (plus check in Tom’s softload fix)

RISC OS 4.39 (28 Apr 2004) 96MB

[Kinetic text]
RISC OS Adjust 1i2

RISC OS ADFS

Would you like to softload the new OS (y/N)?
(booting will continue in 10 seconds)

Yes - softloading..
Softload version 1.13
Error: Message token C72 no found (error number &AC2)

• Using RISCOS Ltd’s 439Boot/zip
• Followed merge instructions contained in the IOMD softload
• Manually made an additional copy of !Softload as the sequence couldn’t find it¹
• Manually copied CLib into System.Modules as the sequence couldn’t find it

¹ I can post exact details at some future date

I’ve checked in the fix for the softload tool. But I’ve had no luck getting a ROOL IOMD ROM to boot (on a vanilla StrongARM with RO 3.70). I’ve been able to use the tool with a RO 3.70 ROM image I’ve got, and with the ’.rom.’ option, so the problem must be in the IOMD ROMs somewhere. No video signal and no response to caps lock/etc. I’ve tried an old ROM from before I added the RAM detection code (that’s a lie – I don’t have a ROM that old), a new ROM with the HAL_CleanerSpace fix, and one with the HAL_CleanerSpace fix plus (hopefully) keyboard IRQs disabled. It’s a shame I don’t have any old ROMs (pre February) to test it with – it would be good to try one to see if any of my changes broke it. Getting the right code from CVS could be tricky!

Error: Message token C72 no found (error number &AC2)

Not sure what could be causing that – the softload tool doesn’t use any messages! The only thing I can think of is that it’s a ‘file not found’ error, since it looks like the softload tool only looks for ROM images in <boot$dir>.softload, but the downloadable archives seem to leave the ROM images in PreDesk.!!SoftLoad. But on the other hand, nobody’s complained about it being broken on their Iyonix.

Also I think a Kinetic RiscPC is the least likely to work at the moment – ROOL’s source tree lacks the code needed to support the Kinetic (although I’m not sure whether any/much would be needed to support softloads)

I found that I had to hardcode the path in Loader to make it work. Hopefully I’ll be able to test it on hardware at the VCF this weekend.

...’file not found’ error, since it looks like the softload tool only looks for ROM images in <boot>.softload, but the downloadable archives seem to leave the ROM images in PreDesk.!!SoftLoad…

Maybe it’s this, although I already placed a copy in the location it seemed to be looking for. I could also try ensuring both !Softload and !!Softload are available, in case it’s that.

Also I think a Kinetic RiscPC is the least likely to work at the moment…

OK - I could try reverting to ARM610 and RO3.5 (and old HDD without long filenames)... or do you think that’d be too old?

It’s a shame I don’t have any old ROMs (pre February) to test it with – it would be good to try one to see if any of my changes broke it. Getting the right code from CVS could be tricky!

I’m afraid I can’t remember the exact date, but this should be pre February

http://opal.spod.org/peter/ROM515.tar.gz

OK – I could try reverting to ARM610 and RO3.5 (and old HDD without long filenames)... or do you think that’d be too old?

No, an ARM610 should be fine (assuming the ROM boots!)

It would only be pre-RiscPC Archimedes machines that RISC OS 5 won’t run on (because they lack support for the 32bit processor modes)

I’m afraid I can’t remember the exact date, but this should be pre February

http://opal.spod.org/˜peter/ROM515.tar.gz

Cheers, I’ll give that one a try when I get home. The ROM has a modification date of April ‘09, so it should be plenty old enough!

(finally managed to format the URL in a way it won’t screw it up!)

Is RISC OS 5 32 bit only? (As opposed to 32 bit neutral or able to be compiled in 26 bit)

The kernel is 32bit only. But most of the modules can be compiled to be 26/32bit neutral, which is why you can still softload BASIC or the Wimp on RISC OS 3/4 machines. I’m not sure how compatible the softloads are with pre-RiscPC machines though; I doubt ROOL have any intention to support hardware that old, except possibly with the C tools.

No luck with that ROM image, Peter. I also tried removing my UniPod just in case. Looks like I’m in the clear, at least ;)

I’ve certainly softloaded an older IOMD ROM build from the ROOL site on my RPC to see what state it was in. It booted to the desktop, and the obvious issues were no ATA support and no hw scrolling. Don’t recall exactly what version of the softloader I used, and my RPC isn’t set up currently, but I can look into this if nobody else solves this soon.

I’ve uploaded the ROM + Softload that was running at Acorn World last weekend here. This works on a StrongARM RiscPC and on the most recent RPCemu from Mercurial (either as ROM or softload), albeit with a slight IDE emulation fix, but doesn’t seem to work on any version of VirtualAcorn or Redsquirrel I’ve been able to try.

Due to my endless incompetence, you’ll need to check + modify the path in Loader as it’s hardcoded.

OK, I’ll give this a go on my RiscPC when I get home.

Also for all my tests I’ve been running the softload tool manually from the command line after the computer has run the full boot sequence and reached the desktop – so that might explain why softloads have been failing for me (But if that was the problem I would have expected it to fail for all softloads, not just RO 5 ones)

That ROM image works much better, Tom. Using the copy of the softload tool I built myself, with my UniPod in, it halts with an abort on data transfer at &2000010c (IIRC) before it’s able to print the amount of RAM. And at that point the keyboard isn’t initialised, so until we get some serial debugging I’ve got no way of knowing what the problem is (presumably one of the modules on the UniPod!)

With the UniPod removed, it boots fine (disregarding the abort caused by my 3.7 boot sequence). RAM/VRAM detection works, as do both ADFS and CDFS.

I look forward to seeing your changes hit CVS!

I tried it on a Risc PC with a removable hard drive. It complained about lacking clib. (I had previously copied the iyonix cd boot to the drive, obviosly it is missing too much.) What !boot is actually needed? Could the softload be made stand alone?

Also I found several Matrix NCs and a Mico, are these likely to be supported for this port? (And would any of the NCs be of use to developers, or the Mico for that matter?)

The !Boot in the self-extracting hard disc image on this very site will work.

The port should work on the Matrix NCs and the Mico, but the lack of IDE hardware in the former and the different IDE hardware in the latter means it won’t be very useful. Support could be added for both, but I think at this stage focusing on RiscPC and A7000 is probably a better plan.

Having said that, if you were offering the Mico I wouldn’t mind having a look…

The Mico does need a good home, and helping with the development of RO 5 sounds pretty good to me. Obviously I’ll need to check it still works OK.

Where abouts are you?

Do you have hardware skills as well as software? (As in assembling machines.) It is recased in a different tower. The nice thing is like the Iyonix, it is ATX and can be housed in most PC cases.

I was assuming the NCs could be useful, because they boot off a network, if the build machine put the build into a suitable share, you could just turn it on and see if it works. I think I have about 5 of them (and a Bush internet TV too.)

I’ll try the !Boot when I am homne.