IOMD development / issues

I’m not sure offhand which would be easiest. But the configure plugins are just simple C programs, so neither option is going to be particularly difficult.

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)

Nobody seems to have noticed

https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/SystemRes/Configure2/PlugIns/SndSetupVIDC/

which is already a fully functional version of the SndSetup plugin for IOMD/VIDC machines. The only hitch I can see is that its installation location in the boot sequence – in RO400Hook – which was designed to ensure it was used in preference to the HAL version on pre-HAL machines – rather assumes that IOMD machines aren’t running OS 5.

Perhaps the simplest thing to do is to restructure them so the RunImages and resources for both are installed in the same directory, and a cunning !Run file works out which one to run for the present hardware.

Is the IOMD ROM on http://www.riscosopen.org/content/downloads/other-zipfiles up to date, or is it only the ROMs linked earlier in this thread that we should be using?

Also, is anything mentioned on http://www.marutan.net/rpcemuspoon/ro5.html still relevant with the latest IOMD ROM?

Perhaps the simplest thing to do is to restructure them so the RunImages and resources for both are installed in the same directory, and a cunning !Run file works out which one to run for the present hardware.

IIRC the SoundControl module only exists to provide a frontend to the mixer device (which the IOMD build lacks), so the easiest way of doing that might be to not have SoundControl in the ROM image and make the sound setup !Run file do a simple RMEnsure to decide which version to use.

Is the IOMD ROM on http://www.riscosopen.org/content/downloads/other-zipfiles up to date, or is it only the ROMs linked earlier in this thread that we should be using?

It’s just the ROMs that Tom has been linking to which work with all the new stuff. He needs to hurry up and get his code into CVS :)

Also, is anything mentioned on http://www.marutan.net/rpcemuspoon/ro5.html still relevant with the latest IOMD ROM?

All the issues mentioned in the “limitations” section have now been fixed (as long as you’re building RPCEmu from the latest source and using Tom’s development ROM images). “Required configuration” is obsolete too, since the ROM should work with pretty much any configuration you can throw at it. The only bit that may be relevant is the mouse type setup, since I’m fairly certain the ROM still defaults to USB (that’s something that is fixable quite easily, IIRC - for IOMD builds just make the kernel check what IOMD version is present and use the appropriate mouse type when setting the defaults). However the mouse type setup does need expanding to include the correct mouse type to use for RiscPC’s – RiscPC’s should be mouse type 0 (IIRC), A7000’s should be mouse type 3.

Don’t think you need to reconfigure the mouse type anymore. I think the only ‘limitation’ that still applies is the lack of CD-ROM support. Given that RPCemu has a fairly major bug in CD emulation somewhere, I’ve not really looked at this yet.

Anyway, new ROM here. Only new bits are sound fixes and the presence of a (useless) SoundControl. I’m only uploading this as I noticed ROUGOL are demoing RO5 on Monday, so I figured having the most up to date build would be good.

Don’t think you need to reconfigure the mouse type anymore. I think the only ‘limitation’ that still applies is the lack of CD-ROM support. Given that RPCemu has a fairly major bug in CD emulation somewhere, I’ve not really looked at this yet.

The CD modules seemed to work fine for me when I tried one of your earlier ROM images on my RiscPC. So unless you’ve broken something since then, it should only be the RPCEmu bug(s) that need fixing.

Thanks for the ROM update Tom. I can’t remember where in the country you are, but you would of course be very welcome at ROUGOL on Monday to help with the demo!

Does this ROM work with RPCemu 0.8.6 or only with the latest sources?

I live in Nottingham, so London’s a bit far for me, especially on such short notice.

The ROM only works with the latest sources. There’s a minor fix you’ll need to make if you want to use IDE - if you’re sticking with HostFS you don’t need to bother – but in ide.c, in the writeide function, the lines

case 0x1F7: /* Command register */
ide.command=val;

need changing to

case 0x1F7: /* Command register */
ide_irq_lower();
ide.command=val;

This eliminates errors on RO5, but causes corruption on RO4, so it’s not an ideal fix.

Another fix that might be useful – in ArmDynarec.c, in execarm() (round about line 784), the code

if (codeblockpc[hash]==PC)
{
        templ=codeblocknum[hash];
        gen_func=(void *)(&rcodeblock[templ][BLOCKSTART]);
        gen_func();
        if (armirq&0x40) armregs[15]+=4;
        if ((armregs[cpsr]&mmask)!=mode) updatemode(armregs[cpsr]&mmask);
}

needs changing to

if (codeblockpc[hash]==PC)
{
        templ=codeblocknum[hash];
        gen_func=(void *)(&rcodeblock[templ][BLOCKSTART]);
        gen_func();
        if (armirq&0x40) armregs[15]+=4;
        if (mode&16) armregs[15]&=~3;
        if ((armregs[cpsr]&mmask)!=mode) updatemode(armregs[cpsr]&mmask);
}

This will let you use the dynamic recompiler in RO5 without occasional crashes, and run at StrongARM-esque speeds (unless you’re on an Atom).

Oh, and if anyone can inform me as how to post code here without it looking terrible would be much appreciated thanks.

Oh, and if anyone can inform me as how to post code here without it looking terrible would be much appreciated thanks.

Plain old HTML <pre> tags should work. Or at least they seem to work OK on the wiki: https://www.riscosopen.org/wiki/documentation/pages/HAL+Device+descriptor

foo = &bar;
bar = *foo;
// wibble
pants = !pants<<42;

That’s much better, thanks!

Hi all.

I haven’t been following this thread, since – judgning from the subject line – I thought it was about the RiscPC, which I don’t have (anymore), but I didn’t realise it could be relevant for a RiscPC emulator!

I’ve just downloaded RPCEmu and the latest IOMD ROM, and it works fine on my laptop. :) This is a milestone towards a fully working, free RISC OS system on Windows, Linux and Mac, and I just wanted to thank everybody involved for the great work that have been done (and is being done) for this.

I know that producing a free RISC OS-based emulator was one of the goals of ROOL, in addition to producing a system that could run on other native ARM hardware (like the BeagleBoard), I just thought that this (the emulator project) was way into the future…

Well, it seems that the future arrived sooner than I thought, just like the case with being able to run RISC OS on other ARM hardware… :)

I know there’s a lot left to be do to get a reasonably working emulator for RISC OS 5 (such as working IDE support), but the result so far is very exciting, and the shared source/open source nature of it all is very promising…

Regards,

Terje

I think my autobuilder script is fully working now. I just need to do a couple more tests tonight, to see what happens if RPCEmu is run without an X server, then I should be able to send it to ROOL and see what they make of it.

Tom: Have you considered adding a ‘kill switch’ to the emulator? I.e. a SWI to let the emulated machine kill the emulator, similar to the one that was in ArcEm. It could hook into OS_Reset and OS_ReadSysInfo 8 so that RISC OS is able to take advantage of it automatically. Although I’m not sure how easy/clean it would be to provide support for this without adding custom code to the IOMD HAL.

Random thought… RiscStation has an ATX power supply and can do soft-powerdown. Perhaps it might be worth duplicating that in RPCEmu and implementing it in the HAL, so that if the IOMD port will ever run on RiscStation soft-powerdown will also work?

I had a poke around the documentation here:

http://www.simtec.co.uk/products/EB7500ATX/resources.html

and I can’t seem to see how it does it. But perhaps I’m missing something (maybe since I have no idea how ATX powerdown works on PCs)

The Mico does the same, and hopefully Tom should have a real one by now.

I’d guess on the RiscStation the powerdown is controlled via the power management unit. The Mico power is presumably in one of the FPGAs somewhere, I’ll have to delve into a ROS 4.03 disassembly to find out where though.

Sadly RO5 doesn’t work at all on the Mico yet – it programs a video mode that is neither TV nor SVGA compatible, then hangs. The presence of IDEFS in podule 7 might not help, as I doubt that’s 32-bit compatible. But I don’t think it’s getting anywhere near that far. It’s possible that the physical memory map is different to other IOMD machines – Microdigital didn’t document the Mico anywhere from what I can see. Lot of guesswork required!

At the London club meeting they had to remove the ide podule before RO 5 would work on their RPC.

For reference, select did work on the Mico, but the networking wouldn’t on it.

Would trying the supplied 4.03 on the emulator tell you anything?

Since at the present, podules are all likely to be 26 bit only, would it be best to stop RO 5 trying to use the modules in them at all?

Since at the present, podules are all likely to be 26 bit only, would it be best to stop RO 5 trying to use the modules in them at all?

It wont touch them as is. For modules, they must have bit 0 of the module extra flags word set (which they wouldn’t). For podule loaders, they must have the “32OK” signature.

Either way, encountering a 26 bit podule wont stop boot.

In the Omega the powerdown is controlled thus:

Because Risc OS 4.03 does not generate a Shutdown confirm dialog following the SWI “TaskManager_Shutdown”, Omega starts a shutdown sequence from the power button interrupt by issueing a ctrl-shift-F12 (only within the desktop). If the Service Call “Service_ShutDownComplete” is sent out, then the power will be turned off immediately.

I expect the Mico is the same.

Regards Ian K

“At the London club meeting they had to remove the ide podule before RO 5 would work on their RPC.”

For info it wasn’t the IDE podule, it was a USB podule (though I can’t remember if it was the simtec one or the castle one), that might well have been new enough to have had 32bit neutral code (though obviously not working) in the ROM.

Before I dive into debugging RO5 on the Mico, has anyone successfully softloaded any of the above ROM images on an A7000+? I’d like to check this is actually a Mico problem and not just an ARM7500 problem.

Also, did MD ever release any documentation on the Mico? I suspect not, but it’s always worth asking…

Did anyone get back to you on this?

I have got an A7000+, but it is only running 3.7

I could set it up over the weekend if needed.

It occurred to me that the simplest way to test it would be from a CD, which led me to thinking that, for testing, a live RISC OS 5 CD would be quite useful.

Memphis3 could be used for scrap. I think RO can cope with being on a read only medium.

I think the biggest problem would be making the softload run the !boot on the CD

That would be very helpful, thanks.

I’d like to try out RPCEMu on my (new!) Mac, and hopefully transfer all my RISC OS use to it. A couple of quick questions:

- I can’t see any updates to the ROOL IOMD softload relating to RPCEMu – should I still be using the Softloads linked to in this thread by Tom?

- Is the OS X Binary download at http://www.marutan.net/rpcemuspoon/#downloads the most capable version? If not, can someone let me know where I can get hold of the source, and if there are any instructions on how to build it (for stupid people)?

Apologies if this is repeating earlier queries – www.risco.info and the mailing lists seems to be down at the moment, and I’m not sure if the information at marutan.net is up-to-date. Assuming I can get RPCEmu to work, I’d be very happy to help out with improving the documentation, etc., online.

should I still be using the Softloads linked to in this thread by Tom?

Yes.

Is the OS X Binary download at http://www.marutan.net/rpcemuspoon/#downloads the most capable version?

No. You’ll need to build it from source.

To get the source, you can either download an archive from the mercurial web interface (see the bz2, zip & gz links at the top of the page), or install mercurial and clone the tree. Then you need to find the right compile instructions for OS X… I’m guessing there’s an XCode project floating around somewhere? If not, the Unix/Linux instructions might do. If in doubt, search the mailing list!

Also bear in mind that the—enable-debug configure option turns off optimisation, so I wouldn’t advise using it unless something is actually wrong (I think the version I initially used to test my autobuilder was compiled like that, hence the less than great performance. After I recompiled the code to produce the console-only version things seemed to be faster)