IOMD development / issues

I just tried the !boot, it failed to complete (RO 4 ROM) with a callaswi error.

When I tried to run the softload after issuing a desktop command, it complained about the c library.

Would I be right in thinking that the boot is expecting things to be present in ROM (clib?) that aren’t on RO4?

And the softloads requires them too?

Yes, RISC OS 5 has a copy of the SharedCLibrary in ROM. There’s actually a copy of the module inside the softload app that Tom posted, try manually loading that before running the tool itself.

Sorry, forgot about that. At VCF both !Boot directories were present (with one of them renamed) and I renamed them before softloading/resetting. Bit of a pain, but I’m sure someone can come up with some magic to run a different !Boot depending on which OS is running.

BTW Jess, you have email. Assuming I’ve got your address right.

I put something like that on the wish list.

No email yet. Look at the webmaster link at the bottom of the following site:

http://cockettsbeds.co.uk

Hello All

Just tried the new IMOD ROM on my Omega unfortunately it just stiff’s it with a blank screen. I would suggest some priority is given to getting it working on the Omega as the Super IO chip is the same as the Iyonix so theirs a good chance the Iyonix hardware drivers will also work. This would hopefully fix some of the bugs and with luck finally get USB support working! I will try and help out as much as possible but my time is limited.

I also have a RiscStation which I will try it on when I have a moment

Want to lend an Omega?

Seriously though, while Microdigital claimed it looked like an IOMD machine, I’d take that with a hefty pinch of salt. Omega will likely need a seperate port.

And I’m not convinced with the small number of Omegas around that it’s a priority.

As an Omega owner (hey, I just collect those rare RISC OS-running machines!), I would say that the Omega should get “some priority” as soon as we have a RISC OS 5 that works reliably on emulators, Risc PCs, A7000s and A9s.

The big problems wrt the Omega are the fact that the hardware is very unreliable (mine never worked reliably with a network card inside), only very few were actually sold, and only very few of those few are in the hand of developers that would be capable of delivering a RISC OS 5 port. I am not one of them, btw.

I would agree there are higher priories and a special ROM image will be needed. I would disagree the actual IMOD emulation is the main problem I have found few currant problems with it. The only 2 that seem to cause problems is it appears from some perspectives to be an ARM7500 type processor but with a StrongARM core and the legacy mode support doesn’t really work.

The general flakiness of the Omega seems to be caused by the PCI interface and associated modules. In order to make the PCI interface work they have had to bodge it to RO4 in a less than ideal way. They have also created a dedicated PCI IRQ handler which doesn’t cope very well with multiple device interrupts. But if the PCI driver can be replaced by the Iyonix one this hopefully will fix this. I will attempt to find a bit of time to look at this soon.

Just thought I’d mention that with the latest RPCEmu sources from mercurial, and Tom’s development ROM image, RPCEmu will successfully run the ROOL boot sequence from HostFS (as long as you remember to put the hostfs poduleroms in the poduleroms folder and ’*configure filesystem hostfs’!)

Now to see if I can use it to do ROM builds…

Now to see if I can use it to do ROM builds…

It worked, although it was a bit slow. If the docs I read about the recompiler are correct (that the StrongARM cache flush instructions cause the dynarec cache to be flushed) then I think the main problem is that that particular approach doesn’t work too well with taskwindows. On a 2GHz-ish dual core+hyperthreaded Atom running Linux, during the initial stages of the build where it was running lots of tools in quick succession I was only getting around 13-15 MIPS. But later on when some BASIC programs were running it jumped up to 80 MIPS - presumably because all the code was in ROM/RMA and therefore not being affected by the flushing of the application space each time the taskwindow went to sleep. Or possibly it was just where code was being shuffled around inside the wimpslot a lot as srcbuild and amu ran each sub-tool.

I’m trying to turn this into a fully automated system for setting up a disc image+build tree, launching RPCEmu, and killing the emulator once the build is complete. This first test was just with me starting the build manually once RPCEmu had booted, so when I try again tonight I’ll try making it patch the !Boot sequence to run the build from the command line. That should hopefully speed things up a bit.

I too can build RPCEmu (on OS X in this case, without Francis D’s extra integration patches, but it works nontheless) from recent sources and use HostFS to get going.

• Build RPCEmu on your favourite OS
• Install HostFS as Jeremy mentions
• Create a directory ‘hostfs’ next to RPCEmu, ‘roms’, ‘poduleroms’ etc.
• Download the self-extracting “HardDisc4.util” image from the ROOL site
• Start RPCEmu and configure the filesystem as described above
• Open the HostFS root, set the “HardDisc4/util” file’s filetype to “Utility” and run it
• Move the contents of the unpacked “HardDisc4” directory into the HostFS root
• Quit and restart RPCEmu

That did the trick for me. I used an InfoZip build for further Zip archive access to get other things going, since 32-bit SparkFS is only currently available in an archive which only SparkFS itself can read – oops!

This thread is perhaps passing by with little fanfare, but it’s actually a major milestone. Thanks to the efforts of ROOL and RPCEmu community members, there is now for the first time a 100% legal and entirely free of charge way to run RISC OS under emulation on Linux, Windows and Mac OS X. That’s great! :-D

Congratulations to everyone involved – this is indeed an important milestone. I’ll be trying this out later in the week, and if it all works I’m sure it’ll become the primary way I use RISC OS. Many thanks.

Andrew: Have you made any headway with setting up the ROOL web server to do autobuilds using RPCEmu? Because that’s obviously where I’m heading with my experiments last night (not only for ROOL’s use, but also so I have a more convenient way of doing local builds en-masse to check that I haven’t broken anything).

Once my system was working OK I was planning on sending it to you guys to use on the server, but if you’ve already got a system that’s almost ready to go then I obviously don’t need to worry too much about trying to make mine tidy/100% reliable.

...I used an InfoZip build for further Zip archive access to get other things going, since 32-bit SparkFS is only currently available in an archive which only SparkFS itself can read – oops!

I was using InfoZip too for ages but did in the end find a way to get 32-bit SparkFS running. ISTR it involved installing an update on top of the free 26-bit version.

Have you made any headway with setting up the ROOL web server to do autobuilds using RPCEmu?

Nope. Not done anything on the web site end and Steve, who’d be doing the build server side of it, has been moving house.

It worked, although it was a bit slow. If the docs I read about the recompiler are correct (that the StrongARM cache flush instructions cause the dynarec cache to be flushed) then I think the main problem is that that particular approach doesn’t work too well with taskwindows. On a 2GHz-ish dual core+hyperthreaded Atom running Linux, during the initial stages of the build where it was running lots of tools in quick succession I was only getting around 13-15 MIPS.

More likely the hard disc emulation is the big problem here – stalling the emulator while waiting for IO isn’t great for performance. The Atom doesn’t really help either, it’s quite a bad platform for RPCemu.

Having said that, on an elderly Athlon I can compile RISC OS at a reasonable speed. Which is just as well as it’s my only RISC OS machine!

More likely the hard disc emulation is the big problem here

Yes, perhaps you’re right – running the build single-tasking didn’t result in any noticeable performance boost.

The Atom doesn’t really help either, it’s quite a bad platform for RPCemu.

True, but it’s a lot quieter and less power hungry than my elderly Athlon :) My Windows PC would probably do a much better job, so I’ll probably just use that whenever I need a build in a hurry.

I’ve uploaded a new ROM here. This version has sound in, but needs testing on real hardware. On RPCemu (through the various issues with sound emulation) Maestro failed to work, but the system beep and DigitalCD seemed fine.

I have a feeling that the sound buffers are still at the old 26-bit address (around 0×1F6000) so that will need to be changed.

I’m planning to look at serial next, but as RPCemu has no emulation of that whatsoever I may be limited in what I can do.

Excellent – I’ll try and remember to give this a go tonight.

I’m planning to look at serial next, but as RPCemu has no emulation of that whatsoever I may be limited in what I can do.

Getting parallel/serial port support in RPCemu (with the ports appearing as real devices on the host PC) would be fantastic. Although I can understand that that might be a bit of a diversion if your main aim at the moment is to just get the IOMD ROM working :)

Keep up the good work!

Sound half works on real hardware, pretty much as you describe:

• wavesynth-beep + stringlib-soft seem to work as expected (didn’t try any of the others)
• Maestro fails to make any noise (after eventually getting it to start playing – I’m sure that the RISC OS 3.1 version can’t have been this cantankerous, there must be some bugs in the ROOL version somewhere)
• Something I forgot to test with the previous ROM you posted – floppy drives don’t seem to work. *Status shows that a floppy drive is configured, but there’s no iconbar icon
• I don’t seem to have any 32bit-safe music players on my RiscPC, and the combination of no network/USB/floppy means I can’t be bothered rebooting messing around copying all the relevant files from my Iyonix. But if DigitalCD worked fine under emulation then it’s fairly safe to say that 16bit sound is working properly.
• SoundDMA complains about missing message tokens if you try getting help on its * commands
• Using the ROOL disc image, the sound setup plugin complains about soundcontrol being absent
• After running the softloadable version from the ROOL site Maestro was still silent, and the sound setup plugin instead complains that “Mixer not found”. I believe it looks for the sound mixer HAL device, which I guess you haven’t written. But I don’t think Maestro should even touch the mixer, so absence of a mixer shouldn’t stop it from working.

It looks like something’s stopping SoundScheduler from working, which would explain why Maestro is failing. *qsound 1 355 100 10 1 should produce a nice beep, but it doesn’t. The value Sound_Control returns in R4 suggests that the scheduler is registered, and it looks like the code is getting called (judging by the nice abort on instruction fetch I get when replacing the handler with 0×4), so presumably it’s a problem within SoundScheduler itself.

Ah – forgot to export one of the changed sound headers (needed a change to be 32-bit compatible). Maestro now works.

Floppy drives don’t work as I haven’t updated the code yet. There seem to be quite a lot of changes in ADFS to get Iyonix floppies to work.

SoundControl is now in (sort of), but sound config still complains about ‘Mixer not found’. Not sure where to go here – IOMD machines don’t have any kind of mixer so I’m not sure there’s much point providing support for one.

On a different note, I’ve got round to benchmarking under RO5. RPCemu seems to like 32-bit mode, Dhrystone was around 30% faster than under RO4. Not bad!

SoundControl is now in (sort of), but sound config still complains about ‘Mixer not found’. Not sure where to go here – IOMD machines don’t have any kind of mixer so I’m not sure there’s much point providing support for one.

Good point. We’d probably want the IOMD ROM to support machines that lack 16bit sound hardware, so it would make sense if we just modified the sound setup plugin to revert to its old set of options (volume, beep sound, 16bit toggle, loud/quiet toggle) if no mixer device is present.

if we just modified the sound setup plugin to revert to its old set of options (volume, beep sound, 16bit toggle, loud/quiet toggle) if no mixer device is present.

I assume you mean greying out the unavailable functions rather than re-instating the panel from 3.5 (providing that is less work to do, of course)