[Rpcemu] RPCemu v0.8.8 (compared to v0.8.3) on Mac OS - Take Two

Al Webb al.webb at ausi.com
Thu Oct 7 09:45:26 PDT 2010


Thanks very much for your feedback Francis. And thanks re note of log file location, I must have skipped that line when reading through that readme file originally.
I believe you are correct that my previous 0.8.3 build was an interpreter version although it's over a year ago now and I was new to both Mac OS and RPCemu at that time so I just tried to follow the instructions.
I've carried out some tests now of the issues I raised the other day, comparing the results across the following 4 v0.8.8 setups:
"ARM610Compiled" represents the build+questions in my previous email;
"SA110Compiled" is using that same v0.8.8 build but with StrongArm processor selected;
"ARM610Interpreted" uses the build 'rpcemu-spoon-fjd-2010-09-27-interpreter' you kindly emailed, with 610 processor selected; and
"SA110Interpreted" uses that same 'rpcemu-spoon-fjd-2010-09-27-interpreter' build but with StrongArm selected.

Q1) RAM.
The situation as originally queried occurs in all 4 scenarios. Have I got the wrong end of the stick with the question I'm asking here or is something awry please?

Q2) Command Line shortcut.
Using F12 alone for me instigates the Mac OS shortcut to open the Mac OS dashboard (not something I've yet tried to amend), and Cmd+F12 has no effect - in all 4 scenarios. In the same way that F15 is additionally mapped to break, could F13 or F14 say be used for an alternative shortcut to the command line?

Q3) Hanging upon boot.
"ARM610Compiled" - problem occurs as per original email;
"SA110Compiled" - seems ok!
"ARM610Interpreted" - seems ok (I tried numerous times using Break, shift break, re-opening rpcemu.app, and changing an rpcemu.app preference);
"SA110Interpreted" - seems ok.
This suggests the boot hanging problem is caused only by the combination of the ARM610 option and compiler build then?

Q4)(i) Random instruction fetch errors.
Frustratingly (for me) all 4 setups, including the original one I emailed about, now seem relatively stable. Perhaps a few Mac OS re-boots since then and/or avoiding trying the old v0.8.3 build have helped. I will let you know and re-test if they start again. I still get random errors running BASIC programs incidentally but that's for another thread.

(ii) RPCemu v0.8.3.
I avoided testing this alongside these other tests until the end when "SA110Interpreted" was the most recently used version. Version 0.8.3, via Terminal, then reported the same "Bus error" as reported previously. Not something I'm worried about though - more for information.

Q5) !Alarm Set command.
I'm sure I'm not imagining this used to work under v0.8.3 but if anyone recognises the commands changed since RISC OS 3.11 (and to what), please could you let me know? The issue occurs under all 4 setups tested here.

Speed: The Compiled version operates significantly faster than the Interpreted version rpcemu-spoon-fjd-2010-09-27-interpreter, I'd say (based on BASIC FOR:NEXT loops) by a factor of around 4. This is roughly the same difference from the v0.8.3 build of mine.
Within each, I couldn't notice any difference using ARM610 versus SA110 processors.

Almost all of my RISC OS applications are from RISC OS 3.11 (or RISC OS 2.0!) so I knew I would face a number of applications failing. So far most seem ok or throw up the same error whether under ARM610 or SA110 so I will persist with the latter for now, noting what you said about it being better tested.

Any thoughts from anyone on the outstanding questions above would be appreciated.

Thanks & Regards,

--- francis at devrx.org wrote:

From: Francis Devereux <francis at devrx.org>
To: al.webb at ausi.com
Cc:  <rpcemu at riscos.info>
Subject: Re: [Rpcemu] RPCemu v0.8.8 (compared to v0.8.3) on Mac OS - Take Two
Date: Sat, 2 Oct 2010 18:06:04 +0100

On 30 Sep 2010, at 14:55, Al Webb wrote:

> Oh dear, my email itself seems to have caused some problems, apologies. Certainly no bad manners intended, and of course I had no idea that any mailing list would have problems with it. Would a note on expected format on www.riscos.info/cgi-bin/mailman/listinfo/rpcemu reduce the chances of other v.rare-mailgroup-submitters making a similar mistake perhaps?? [For info, it was written in TextEdit on a Mac which I forget doesn't save in plain text format as standard, then pasted into this web-based email from a Windows PC that composes messages by default as rich text]. Something learned anyway and sorry for any inconvenience caused. I have tried to change my email settings so hopefully the below arrives successfully this time. I look forward to your thoughts on my queries,
> Kind Regards,
> Al
> ------
> Hi,
> Having installed v0.8.8 for Mac OS last night (using FrancisD’s rpcemu-spoon-0.8.8-fjd2-bin.zip), I encountered a number of problems booting into RISC OS that I hadn't experienced with my build of v0.8.3 (that I’d built a year or so ago using instructions at http://www.riscos.info/index.php/RPCEmu_Mac_Guide). I hope I've now worked past most of them but..

Since you say that my build of 0.8.8 is much faster than your build of 0.8.3, it sounds like your build of 0.8.3 is an interpreter version (as opposed to dynamic recompiler, which you get when you add -DDYNAREC to CFLAGS).  I've done an interpreter build so that we can test this theory - grab it from http://www.devrx.org/software/rpcemu/rpcemu-spoon-fjd-2010-09-27-interpreter.zip and let me know whether it's more stable than the normal 0.8.8 dynarec build.

> Q1) I think they all related to inconsistent RAM allocation and I wonder if there still may be a problem here? I've now checked that the following all match up:
> rpc.cfg mem_size = 128;
> RPCemu Preferences menu selection = 128MB;
> RISC OS !Boot - Discs - RAM disc enabled, 128.0 MB.
> However, on start-up there is no RAM disc on the icon bar and looking in Task display, RAM disc size shows 0K. Is that correct?
> Although I can't now compare with v0.8.3 (please see Q4.ii below), I believe something may have changed as a program that I regularly run as the first thing after start-up contains the line "RMKill RAMFS" and this now fails with "Module RAMFS not found".
> Q2) Command+F12 no longer seems to open the Command line under the icon bar? The shortcut to open a Task window still works but is there an alternative now for this other route to the command line?

Command+F12 is now mapped to break.  F12 by itself should open a command prompt (this doesn't work for me with my external PS/2 keyboard connected via a PS/2->USB adapter, but it works on my MacBook Pro's built in keyboard and my external Apple USB keyboard).

> Q3) Roughly every 2 out of 3 times I open RPCemu, the boot sequence stops very early with an hourglass after the first 3 lines of text (that show the processor and "Acorn ADFS"). I can't find a rpclog file saved anywhere to send you though? If I wait long enough, an error does appear as follows: "Error: Unable to create files in "ADFS::IDEDisc4.$.!BOOT.Resources.!Scrap.ScrapDirs", error returned is "Disc error 23 at :4/0000000007FE0000" (Error number &6)". I have since verified the hd4 'drive' is "ok", and I can't see any permission restrictions on the folder referred to. Moving the pointer out of the window quickly enough as it boots MAY assist to bypass the error but that seems a bit random. Any ideas?

See readme-macox.txt (in rpcemu-spoon-0.8.8-fjd2-bin.zip) for details of file locations, including the location of rpclog.txt.

> Q4) I found RPCemu spoon edition v0.8.3 very reliable after a year of regular use (bar some problems with my own self-written but previously-stable (under-RISC-OS-3.11) BASIC programs) but:
> (i) I am getting regular instruction fetch errors now under v0.8.8 with no particular pattern as yet (e.g. upon opening a dir that next time opens fine) such as "Application may have gone wrong. Click continue to try to resume or Quit to stop Application." Describe = "Internal error: abort on instruction fetch at &00012AB0"; and
> (ii) now I can't seem to open v0.8.3 any more. Hopefully I won't need to but is this to be expected? I was never able to open v0.8.3 from the rpcemu unix executable, but it was ALWAYS successful running from Terminal. Now from Terminal it fails with a "Bus error" followed by "Rpcemu quit unexpectedly". I have saved the Apple problem report details should it be worth forwarding? The RPCemu unix executable does run to display the desktop but on clicking on IDEDisc4 or the RAM disc, it gives the error "Disc not understood - has it been formatted?" [and creates a new blank hd4.hdf file in a different folder]. I think this was the problem a year ago and why I always used Terminal thereafter.
> Q5) A command "Set Alarm$Options ..." for configuring the !Alarm application which worked fine under RPCemu v0.8.3 seems to have stopped working?
> Can you help / advise with these please?
> Specification and other info should it be helpful: 
> - I’m running Mac OS 10.6.4 on an Intel iMac 9.1.
> - RISC OS 4.02 ROM’s.
> - To set up v0.8.8 I created a new folder with the unzipped 0.8.8-fjd2, along with copies of hd4.hdf, roms folder, hostfs folder, rpc.cfg and cmos.ram, and set this folder to be the data directory.
> - With both v0.8.3 and v0.8.8 I get a duplicate HostFS on the icon bar, but both open fine and point to the same folder.
> - I found a very strange issue when testing v0.8.8 last night whereby a RISC OS text file which one of my BASIC programs spools (one line of text) to, contained over 800Mb of random data, but amongst which were references to a load of filenames I have on Mac OS. Hopefully this is a one-off but I’m intrigued how this could have happened? 
> - Contents of rpc.cfg file:-
> network_type = off
> mouse_following = 1
> cdrom_type = 0
> cdrom_enabled = 1
> blit_optimisation = 0
> refresh_rate = 60
> stretch_mode = 0
> sound_enabled = 1
> vram_size = 2
> cpu_type = ARM610
> mem_size = 128
> ipaddress =

Try changing the CPU type to SA110 (assuming your RISC OS apps are StrongARM compatible), I think that the StrongARM dynarec emulation is better tested than the ARM610 dynarec emulation (I could be wrong there though, hopefully someone will correct me if so).


> The build of version 0.8.8 is considerably faster than v0.8.3 incidentally! Thank you for everyone's ongoing work and time on this project.
> Thanks & Regards,
> Al Webb

AUSI.COM at http://ausi.com - the BEST FREE EMAIL

HOLIDAYS & FUN -- AUSITRAVEL at http://ausitravel.com

More information about the Rpcemu mailing list