IOMD ROM issues

“Random”? I found out why the infinite aborts were happening and posted why that was. Random or not, the emulator certainly works a whole lot better with my patch included.

Andrew posted that compiling RPCEmu on a Mac is a pain. It is. I offered to put together a package for Allegro. He accepted, and – lo! – I delivered said package, together with an Xcode build that Andrew was also interested in. Francis’s OS X binary hardly helps when people want to try and get 32-bit RISC OS 5 running on the emulator, so providing an Xcode build was an attempt to aid in the process of producing an IOMD build, which, from reading this thread, seems to interest quite a few people. It doesn’t interest me in the slightest, but I thought I’d offer to help out anyway, as it’s something I’ve worked on in the past.

To be quite frank, I don’t think I’ll bother offering any assistance in the future, or contributing any more changes to the OS X port (which I got up and running in the first place, I might add). My downloads will be available for one week, after which I will be deleting them.

My time here has been brief, but I wish ROOL the best of luck with RISC OS 5. It’s by far the most interesting thing to happen to RISC OS in a long time. I feel rather slighted by Peter Howkins’ post, so I think I’ll find something else to do with my time, and leave him to his precious emulator.

I was trying to explain, rather bluntly perhaps, that a XCode project already existed, though it appears isn’t well known off the RPCEmu mailing list.

http://fe4e.ath.cx/hg/rpcemu-spoon-fjd/file/cd0cfce49ff5/src

And that it’s the one that’s been used to build the 0.8.6 binary on the site.

I am very grateful for the mouse follow issue that you tracked down this afternoon, and committed a patch for it this evening.

http://home.marutan.net/hg/rpcemu/rev/e05ab2bfbfd2

He accepted, and – lo! – I delivered said package, together with an Xcode build that Andrew was also interested in

Very handy it is too, thanks.

Please don’t be put off if people seem (in Peter’s own words) a little blunt sometimes. Quite a few of the developers posting here have known each other either in person or online for a long time, so perhaps we sometimes forget we’re not on quite so familiar terms with other forum members and might accidentally cut the diplomacy a bit on the short side from time to time! I’m sure there was no insult intended and certainly at ROOL we’re always delighted to see anyone get involved with any contributions, so thanks again.

Yes, there’s a few developers who are perfectly nice when I’ve met them in real life, but come across as a bit sharp online. So don’t be put off by the personae that are projected, they aren’t necessarily real.

(I was reading the other day of a WW2 attack that didn’t happen because the cipher decoding slightly changed the tone, causing the Admiral to be insulted and change the course of the battle. So this is nothing new)

Unfortunately the technology does not yet exist to provide tone of voice in these forums!

I’ve just reread Peter’s post and I still don’t see any sort of slight in it. Just information about an existing OSX porting effort, so you could hopefully pool your resources. I suggest you reread it to, with the thought in mind that Peter was trying to be helpful and save you some work!

Other than a tendency to sarcasm, Peter is “perfectly nice” :-)

In case useful (reading this thread, maybe just confirmation of what others have found):

Tried to get RPCEmu Interpreter (Spoon 0.8.6 from the Windows Installer) to work on Windows XP. Copied the 5.17 ROM into the Roms folder, and the contents of unzipped HardDisc4 to the HOSTFS folder. Running the Interpreter gets me to the supervisor prompt. Typing *desktop with mouse following enabled produces the endless loop others have seen: ‘Internal Error: Abort on Instruction Fetch at EC117FF4’. If Mouse Capture is ticked instead, I get to the desktop OK, but the mouse is inactive – the pointer just sits in the middle of the screen and won’t move. Pressing F12 brings up the command prompt, and pressing RETURN takes me back to the desktop.

It doesn’t seem to matter which processor I select: 7500, 7500FE get me straight to the supervisor, but StrongARM needs an extra reset. Selecting the 810 doesn’t get me anywhere.

Happy to test out new builds on Windows to try and get this working.

If Mouse Capture is ticked instead, I get to the desktop OK, but the mouse is inactive – the pointer just sits in the middle of the screen and won’t move.

If you’d read the thread more closely (or the RISC OS 5 page on the RPCemu site) then you’d have known that you need to properly configure the mouse type ;)

*configure mousetype 3 for ARM7500/7500FE

*configure mousetype 0 for other CPU types

This is probably another thing to fix in the IOMD build – the kernel/mouse driver modules should be able to decide for themselves what the default mouse type should be (currently it defaults to USB).

Oh. Yes. :blushes:

Now got a working mouse – thanks. Will have a further explore and see how I get on.

To the developers: are bug reports welcome on the mailing list? Or are you aware of the main issues?

Chris,

If you’ve got an emulator bug the best place to report them is the RPCEmu mailing list [1]. For bugs in the IOMD ROM image, then here (ROOL) is the best place. If you’re not sure which, take your best guess and someone will hopefully (politely) direct you to the other place if need be.

Re. Your issues.

‘Internal Error: Abort on Instruction Fetch at EC117FF4’

Yep that’s the Mouse following. This has been resolved by Tim Coltman’s patch and should be released in 0.8.7

Always starting in supervisor

Now that CMOS RAM is working, you should be able to type

*configure language (rom number of the desktop module)

and this’ll make it boot to the desktop on subsequent boots.

The issue with mousetype, Jeffrey mentioned above.

[1] http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

How can RPCEmu (Mac OS) be built from the Spoon sources?

If I do:

hg clone http - home.marutan.net/hg/rpcemu

(The ” – ” is to avoid the forum auto-linking the above and breaking the text! Should read like a normal URL).

...then I just seem to get the Spoon 0.8.6 sources. Fixes like the CPSR change in the arm.c “mousehack” code are listed in the public repository revision history, but aren’t actually present in the repository clone pulled down by “hg”. If I specifically ask for the latest revision (”-r 522” on the end of the command) I seem to be ignored and again, crusty old source which doesn’t include the changes listed in recent changesets is supplied. Huh?!

If I download the .gz archive given by the hg web view frontend, I seem to get up to date source but it isn’t complete – for example, all the Mac build stuff is missing and if I try to merge the two by copying the new partial sources from the .gz archive over the top of the older stuff pulled via “hg” then the result is a nasty broken mess that won’t build.

The official “Spoon” page still lists 0.8.6 as the latest download.

As it stands I can see no way to make the IOMD ROM work, since the Mac build forces on mouse following and both the source and binary downloads available all seem to have the old broken 26-bit mouse code present.

I really don’t understand why the “hg” command is pulling down old sources while the web front end gives me something else entirely (which is apparently incomplete). I know Mercurial is relatively obscure but really, what on Earth is it doing? I’ve tried reading the quick start guide but I’m none the wiser…

TIA.

The following works correctly for me (modulo anti-forum-auto-formatting):

hg clone http – home.marutan.net/hg/rpcemu/trunk rpcemu

Thanks John and – doh! This is because I’ve actually being inadvertently pulling from two different repositories and my first post about it was incorrect. The variant with Mac OS build components is from http://fe4e.ath.cx/hg/rpcemu-spoon-fjd/ – Francis Devereux’s branch. That’s clearly not the same thing as the main source tree and doesn’t have the newer patches applied.

I guess if I want a Mac version of the latest source I’ll have to either do it myself or ask Francis if he’s able to update his tree. Sorry for the false alarm.

OK, well, I decided to diff the RPCEmu “vanilla” 0.8.6 sources (revision 477) with the current head of Francis’ modified version. I then applied these changes to the head of the official RPCEmu Spoon sources, which turned out to be relatively straightforward with only a couple of areas needing more attention. Updating the XCode project to include a few new files results in a working RPCEmu Mac OS X build.

It’s not quite right. Despite applying patches to load paths for all sorts of external resources (e.g. HD images, CMOS RAM) the new build still seems to try and read things from an unexpected location (alongside the application, ignoring GUI configuration settings). RISC OS 3.71 boots but it doesn’t seem to find my HD4 image, so it’s not very useful. The worst aspect is the mouse pointer – regardless of configured mouse type the pointer is stuck at the top right of the emulator window and won’t move.

Within those restrictions, the IOMD HAL works equally well/badly. As David Ramsden mentions (see page 2) it seems to need resetting from the File menu before it’ll boot and e.g. SYS “OS_Reset” causes the emulated machine to hang, needing it to be “hardware reset” from the File menu again. This may well be a ROM issue rather than an emulator issue. The mouse pointer is still stuck at the top left of the window and there’s no ADFS of course. Task windows open under !Edit and Filer_Run launches ROM apps without complaint. “Filer_OpenDir HostFS::$” causes the entire emulator application to crash (note the double colon, which HostFS doesn’t use), though “Filer_OpenDir HostFS:$” is OK and I can run things from there within the constraints of no mouse, although ironically, a !CreateSEC-based archive fails to complete its extraction operations, aborting part-way through.

Not sure quite how to tackle the issues it has (e.g. mouse pointer) or how to feed back the source changes – except for perhaps adding a few ”#if defined RPCEMU_MACOSX” around some changes which aren’t thus wrapped but do seem to be Mac OS specific, the changes are generally clean. Some of them simply tidy up dodgy and/or duplicated code and would improve the quality of the code base overall.

Since the whole lot took me less than an hour to diff and reapply from scratch by hand with no familiarity of the code base at all, I’m not sure why it’s 2 months in and there’s no merged single set of sources available – it doesn’t seem that anything clashes and doesn’t seem to require much effort to merge things. Perhaps Francis is keeping them separate deliberately? Peter – any thoughts about why there are these two repositories rather than just one?

it seems to need resetting from the File menu before it’ll boot

AFAIK nobody’s looked into that yet to determine the cause of the failure. In my experience it only fails when StrongARM emulation is used – and I do know that the HAL has some dubious support for StrongARM at the moment (specifically, the handling of the cache cleaning area). I’m not sure whether that would affect RPCemu though.

SYS “OS_Reset” causes the emulated machine to hang

HAL issue – HAL_Reset hasn’t been implemented.

although ironically, a !CreateSEC-based archive fails to complete its extraction operations, aborting part-way through.

Assuming you’re using the latest autobuilt ROM, this will be due to the ROM using a version of the Squash module that uses LDRH/STRH. I “fixed” this in CVS a few days ago so that it uses an older version of the module – a bit hacky, but it will do until one of us finds the time to rewrite the unreleasable source file(s)!

Andrew: The “official” RPCemu repository looks to be a commit-fest to change things like giving it a pretty icon, renaming HostFS to EmuFS, and other purely cosmetic things. RPCemu Spoon seems to be more about having code review, and actually fixing and cleaning up the turgid code. I’ve always used Spoon and shunned “official” for just that reason.

I’ve always used Spoon and shunned “official” for just that reason.

By “official” I meant the Spoon repository at marutan.net. The OS X build additions are kept in another tree at fe4e.ath.cx. I’ve only been working with these two repositories. The OS X build addition tree at ath.cx is out of date, so I updated it (but in a ‘dumb’ fashion based on diff and may have missed extra things in the newer martuan.net sources which should also have been patched). I’m interested in finding out why these two trees exist – surely, it should all just be merged onto the marutan.net branch so Francis’ work can be used by a wider audience and future merges are not required.

Assuming you’re using the latest autobuilt ROM, this will be due to the ROM using a version of the Squash module

Ah, of course. ISTR you posted a link to a fixed ROM in the forum somewhere but couldn’t find it, proceeded on the assumption that I must have downloaded that fixed version, then got a crash indicating the contrary but forgot all about the Squash issue in the process :-)

Not a link to a ROM image, just a link to a suitable, confirmed softloadable version of Squash from CVS (although I’m not sure if there’s any way to force the CVS viewer to treat it as a binary download and not a text file!)

I’m interested in finding out why these two trees exist – surely, it should all just be merged onto the marutan.net branch so Francis’ work can be used by a wider audience and future merges are not required.

There’s a few reasons why it’s currently separate.

1) It’s a distributed version control system, so they can be separate without much penalty. In fact when developing a large patch (such as a platform port) having a local repository is very useful. If you imagine each repository as a branch rather than a different codebase, that would better explain it.

2) It’s not merged yet, it’s on the list of things to be checked and merged in, but pesky things like real life only grant so many hours in a day.

pesky things like real life

Wossat? ;)

OK, so good to know there’s no philosophical / project issue here, it’s more a question of “insufficient hours in the day”.