IOMD ROM issues

I did a fake IDEFS for ArcEm that did similar to Steffen’s suggestion: very lightweight module that used some magic SWIs to read and write blocks through the host. It was a lot quicker than the ADFS implementation. Never got around to finishing it/providing filer icons, etc. The issue here is that Peter (quite rightly) is more interested in making sure RPCemu is as bug-free as possible, rather than providing OS-specific hacks around troublesome areas.

I can confirm booting does in fact work with HostFS, and has done since the code was added in February 2006 (by me).

I have frequently used it with RISC OS 3.6, 4.02, and 4.39, but have never tried it with any of the RISC OS Open releases.

Unfortunately I am not in a position to test it right now, but if it does not work with RISC OS 5.16 then perhaps there is a previously unstudied bug in either HostFS or RISC OS 5.16 (or both?).

I’ve uploaded new ROMs. Enjoy!

A note on running an autobuild process on RPCemu – this is something ROOL would like to do, but for a number of reasons, I’d want to reboot it between each build to ensure that they are absolutely clean (and various minor memory leaks in the build process don’t cause problems).

Just to let you know, and before anyone spends too much time on it … It’s proven too difficult to get 5.17 running with a boot sequence over hostFS due to some of the known bugs in HostFS (being looked at atm), so people would be best to hold off until a new release of RPCEmu [1]

[1] Or until ADFS appears in ROOL ROM (and then there’s probably LBA issues to fix)

It’s proven too difficult to get 5.17 running with a boot sequence

Did you manage to get it running at all…? On Spoon 0.8.6/OS X, all I managed to get was a data abort loop as soon as 517 booted into the Desktop. It only seemed to work with SA110 emulation too – most other CPU models either failed POST or caused a data abort at ROM init (didn’t do an exhaustive check – maybe a 7500 variant might have reached the desktop, but it sat in an abort loop just the same after that).

On Spoon 0.8.6/OS X, all I managed to get was a data abort loop as soon as 517 booted into the Desktop. It only seemed to work with SA110 emulation too – most other CPU models either failed POST or caused a data abort at ROM init

Hmm, that doesn’t bode well. For reference, I was doing my testing with the Spoon 0.8.6 interpreter on Windows. The only thing that seemed to cause difficulty was the StrongARM emulation, which would typically get stuck somewhere and never reach the stage of printing out “RISC OS”.

Are you sure it’s not something silly like corrupt CMOS RAM settings causing a load of modules to be unplugged?

If needed I’ll check with the downloadable ROM tonight – perhaps there’s a file that I forgot to check in.

Did you manage to get it running at all…? On Spoon 0.8.6/OS X, all I managed to get was a data abort loop as soon as 517 booted into the Desktop.

You need to remember to disable ‘follow host mouse’ or ‘mousehack’ [1]

[1] Name depends on platform … at least until I change it.

Hi everyone.

I was an avid RISC OS user years ago (maybe someone will remember my name!) and I’ve been checking these forums daily and getting quite excited by the developments :)

Over lunch, I had a quick play with RPCEmu (Spoon) with the latest IOMD ROM and I’ve got the boot sequence working from HostFS. It only boots correctly with the CPU emulation set to StrongARM. Any combination of RAM and/or VRAM seems fine.

I had to remove SoftSCSI from PreDesk and also comment out all the commands from !Run in PreDesk.Configure. Otherwise RPCEmu would hang or the screen would become corrupt and hang, before booting in to the desktop.

When first running RPCEmu, it never boots. I have to reset RPCEmu from File->Reset. I’m currently testing this on Windows 7×64, for what it’s worth. Will try under Linux when I’m home later on tonight. Also if you try to restart RISC OS via Ctrl+Shift+F12, it hangs after pressing Restart (desktop disappears but nothing happens after that).

Edit: Also noticed that when changing the screen resolution from Boot, after pressing the Try button RISC OS locks up. The Pinboard settings window is too long for the default screen resolution so you only see the Try button and have to press Enter to “hit” the OK button.

No idea if these are RISC OS issues or RPCEmu issues.

Great progress though! I’ll try to help out where I can. I do have an old RiscPC 700 at home too, which still works. I’d love to be able to compile the IOMD ROM from CVS but I understand you can only do this from within RISC OS using the Norcroft compiler?

The hang if you try restarting using Ctrl-Shift-F12/Ctrl-Break/etc. would be a RISC OS issue – we need to implement HAL_Reset.

I’m not sure why it would lock up when you try changing screen resolution though; it wouldn’t surprise me if that was a RISC OS bug as well, since I can’t remember testing it.

I’d love to be able to compile the IOMD ROM from CVS but I understand you can only do this from within RISC OS using the Norcroft compiler?

Correct – although if you’re technically minded enough and have plenty of determination you could try helping Peter Naulls out with his quest of cross-compiling RISC OS on Linux using GCC. Or you could buy a copy of Norcroft from ROOL, I’m sure they wouldn’t mind ;)

Another 5 minutes playing about with the latest IOMD ROM and RPCEmu and you don’t need to delete SoftSCSI from PreDesk and you don’t need to comment out all the commands from !Run in PreDesk.Configure either, only the last line.

Now, I’ve not used RISC OS for years and years so I’m very rusty but the last line is: /<predesk>

Is that a typo (the forward slash)? The boot sequence is from the HardDisk4 zip.

I was hoping that reinstating the VIDC lines would fix the Screen resolution change crash/screen corruption/mouse getting stuck in a non-existent error box issue but unfortunately not.

Once again, I’d love to help Peter on his cross-compiling quest but my programming skills probably aren’t at the required level to add any value.

Now that the IOMD ROM is more usable than it was in RPCEmu, I’ll start brushing up on all things RISC OS (such as the Boot sequence) and see where I can help (if at all!).

Cheers.

You need to remember to disable ‘follow host mouse’ or ‘mousehack’

Setting mouse_following = 0 in rpc.cfg has no effect; as soon as RPCEmu 0.8.6/OS X runs it forces the setting back to 1 and saves the configuration file. In desperation I made said file read-only but the change is still effected internally. If this really does have to be disabled for RISC OS 5.17 to work, then RPCEmu needs to change.

The only thing that seemed to cause difficulty was the StrongARM emulation, which would typically get stuck somewhere and never reach the stage of printing out “RISC OS”.

Ironically this worked last night, but today, it seems to do just what you say if cpu_type = SA110. Changing this to ARM7500 lets the system boot but then it aborts as previously described.

Are you sure it’s not something silly like corrupt CMOS RAM settings causing a load of modules to be unplugged?

I deleted cmos.ram first. It gets recreated and has non-zero contents by the time RISC OS has booted. It doesn’t seem to make any difference to the behaviour in the Desktop.

Is that a typo (the forward slash)?

No; it’s short for the Run command.

Thanks Andrew! In that case, the problem is actually in Boot:Choices.Boot.PreDesk.Configure.Monitor. Commenting out the LoadModeFile line fixes it and everything boots as expected.

Andrew, are you running a version of RPCEmu with dynamic recompilation enabled? Can you try without?

When I tested last night under Linux, RISC OS 5.17 was doing all sorts of strange things with dynamic recompilation enabled. For example, the pinboard background image is corrupted, trying to run !Boot results in a “No room for this DIM” error, programs in Apps abort.

Without dynarec enabled it works fine. I’ve got networking going etc. but Netsurf is unusable because of the performance impact of having dynarec off.

Running RPCEmu with ROS5.17 under Windows with dynamic recompilation enabled is fine. No errors, boots cleanly.

I’ll take this up on the RPCEmu mailing list, as it appears to be an RPCEmu inconsistency rather than a RISC OS problem, unless someone else disagrees?

I have to admit, I’m seeing the same as Andrew on RPCemu Spoon for Linux with (built with dynrec off). I had already got RISC OS 4 working fine, with a small hard disc image that simply booted a !Boot on HostFS and the whole of my disc image was there. Clearly, that step won’t work in our IOMD build yet.

Using that setup but with the new IOMD ROM, I found it boots to the command line, then manually running !Boot on HostFS seemed to work – it boots into the desktop but then gets stuck in an infinite loop of (I think) prefetch aborts.

Annoyingly, I can’t give you the details because now I’ve been fiddling with it and got a different behaviour; the thing boots to a command line but running HostFS !Boot simply results in no output other than a Data Abort at &12A5C – I’ll have to debug my boot sequence now to see what’s doing that.

If I just do a *desktop, I get into the desktop without the endless errors, but it’s a 640×256x1bpp screenmode. Presumably the result of me having removed the CMOS file and then the boot sequence not having loaded and no MDF being present.

If I wasn’t so damn busy, I’d be investigating better than this.

Interesting aside: the sense of caps lock is the opposite way around in the emulator to my laptop. That’s a bit odd.

Linux srevill-laptop 2.6.28-17-generic #58-Ubuntu SMP Tue Dec 1 18:57:07 UTC 2009 i686 GNU/Linux Ubuntu 9.04

OK - I spent a further 60 seconds investigating.

With mouse_following=1…

Setting CPU to SA110 for me results in the emulator just sitting there without outputting the startup banner on the screen (e.g. the “RISC OS” text).

Setting CPU to ARM7500FE results in booting to the command line OK. Going into the desktop results in endless aborts on instruction fetch at &EC117FF4.

With mouse_following=0…

CPU of SA110 still behaves the same as above.

CPU of ARM7500FS goes into the desktop and doesn’t get stuck in an error loop but it’s in the 1bpp mode I previously described. Opening HostFS, then looking inside !Boot then double-clicking on !Resources causes RPCemu to crash.

So the system I have right now is unusable.

Andrew, are you running a version of RPCEmu with dynamic recompilation enabled? Can you try without?

AFAICT there is no such option on the OS X port of Spoon; 0.8.6 has it forced on. Building RPCEmu on OS X is such a major pain that it’s not something I’m all that interested in spending much time on, especially when the IOMD ROM is causing others trouble and is known to be incomplete. If the OS X GUI version is being built in an XCode project with dependencies included internally then this would be an excellent way to distribute the source for OS X users, but I’ve not found any such bundle so far.

People using RISC OS 5.17 in RPCemu might find it handy to use the command *con.lang.10 If they find themselves stuck with the supervisor prompt. For some reason this was set to 11 on my setup, not sure why as desktop is no.10 in both 4.02 and 5.17.(4.02 still started correctly though!)

Also trying the softload tool with 5.17 on my real RPC (strongarm @279MHz 41MB os 4.02) results in this error: Internal error: abort on data transfer at &000085F0

Postmortem requested 85e8 in function ROM_physaddr Arg2: 0×0000bfd4 49108 → [0×0000bff8 0×0000c010 0×0000c013 0×0000c016] Arg1: 0×00000006 6 8c8c in function main 2293b10 in unknown procedure 8ff0 in anonymous function

I wonder if this is related to the failure to boot from a cold start in RPCemu? Now I’m trying to remember where I stashed my ARM710 card!

With regard to XCode and RPCEmu (on OS X), it might be worth getting on touch with Francis Devereux via the RPCEmu mailing list. Both he and I were working on some improvements to RPCEmu under OS X; whilst I’ve lost interest, the last I heard, he was still working on various changes, including a proper OS X interface, and we independently ended up creating XCode projects to make working on the code easier. I’ve still got mine, though it’s a good 10 months old now – Francis’s may be more up-to-date. Mine didn’t include Allegro (required to run RPCEmu), as I was quite happy to compile and install that manually (as I wasn’t making that many changes to it).

Allegro 4.4 includes the facility to make an XCode project for building that – it may be possible to combine this and my RPCEmu XCode stuff to come up with something suitable. I’ll have a play and see if I can come up with anything in the next few days.

Sounds good. I’d far rather have a proper XCode build than faff around with the various nasty porting mechanisms (Fink, MacPorts, whatever). Ideally Allegro would install itself as a real OS X framework and RPCEmu could go from there. ISTR some issues with Allegro versions too.

I’ve managed to work out why RPCEmu 0.8.6 gives the endless aborts on instruction fetch at &EC117FF4 when mouse following is turned on, as described by Steve above. In the “execarm” function in “arm.c”, there is the following code:

else if (mousehack && templ==0x1C)
{
    getosmouse();
    armregs[15]&=~VFLAG;
}

I commented out the line starting with “armregs”, recompiled and mouse following now works properly. Whilst I am far from expert on such things, isn’t R15 purely the program counter on RISC OS 5, with status flags stored separately? There are similar lines elsewhere, which I haven’t touched.

I have created a diff patch to fix this particular instance, which can be downloaded and applied with “patch -p0 < arm.c.diff” from within the RPCEmu “src” directory:

http://files.me.com/timothy.coltman/ogmqtn

On the Mac front, I am not far off having a working installer for Allegro 4.4.0.1 (OS X 10.5 and above, Intel only), and the Xcode stuff is pretty much done. All being well, there should be something to download tomorrow night, or Saturday at the latest.

RISC OS 5 runs in 32-bit ARM mode as opposed to older versions of RISC OS which operate in the (no longer supported in modern ARM chips) 26 bit mode. In the old mode, the main processor flags were indeed held at the top of R15 (the Program Counter, or PC register). Nowadays, the flags are in the CPSR - a completely different register altogether and the PC is exclusively used to hold an address.

So all of those bits of code are almost certainly broken and need to be modified to be 32-bit safe by making them adjust the CPSR when in 32 bit mode. Mind you, I’ve not looked at the RPCemu sources so I’m just speculating…

This is a reminder, if people have bug reports or patches for RPCEmu, it’s much better to report them on the RPCEmu mailing list. They’re more likely to get noticed and fixed that way.

As promised, I have created some downloads for OS X.

First, a Allegro 4.4.0.1 installer (1.2MB). Simply double-click on the installer within the ZIP file and proceed from there. It installs one file in /usr/local/lib and a number of frameworks in /Library/Frameworks (principally, Allegro.framework):

http://files.me.com/timothy.coltman/3peybi

Second, a ZIP (220K) that contains the files you need to compile RPCEmu in Xcode and to run it as an application bundle:

http://files.me.com/timothy.coltman/vq5o9g

Unzip this and copy its content into your “src” folder within RPCEmu. You can then double-click on the Xcode project to load it in. It should, in theory, build without problem and you will end up with an application within the “src” directory. Where it resides depends on the build you select, for the “Development” build it would be “build/Development/RPCEmu.app”. You will need to run the application from the same location as the “roms” directory and “cmos.ram” files (e.g. the parent of “src”).

Erm, to all those working on random changes to the Mac OS X port. You might want to get in contact with Francis Devereux, or at least base changes on his Mac OS X repository http://fe4e.ath.cx/hg/rpcemu-spoon-fjd/ [1], a spoon edition synced version with a decent GUI and Xcode project.

The 0.8.6 Mac OS X binary is available from

http://www.marutan.net/rpcemuspoon/#downloads

[1] On the queue of things to merge into the main Spoon repository.