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

Francis Devereux francis at devrx.org
Sat Oct 2 10:06:04 PDT 2010


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 = 172.31.0.1

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).

Francis

> 
> 
> 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
> _______________________________________________
> Rpcemu mailing list
> Rpcemu at riscos.info
> http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
> 




More information about the Rpcemu mailing list