Re: [Rpcemu] RPCEmu and corruption of file in !Boot

Theoretically, what you've done should work. Can't see if you've mentioned that you tried this same trick on the older laptop successfully or not.

If it were me, I'd start with a fresh !Boot, but bring all the rest of the hard disc across from the other install, just to rule that out.

In my install, I've also put AnyMode in the Choices.Boot.PreDesk folder, and set the screen resolution in Configure, so no need for any Obey files to run it - this is, however, on RISC OS 5.23.

Cheers,

Gerald.

From the MacBook Air of Gerald Holdsworth
www.geraldholdsworth.co.uk
www.hollypops.co.uk

> On 2 Jan 2016, at 00:21, Matthew Phillips <spam2011m@yahoo.co.uk> wrote:
>
> I have been setting up RPCEmu on a newly-acquired machine running Linux Mint
> 17.2 Rafaela (x86_64). I compiled RPCEmu from source downloaded a few days
> ago, and brought across the 4.02 ROMs, hd4.hdf, CMOS and hostfs from an older
> laptop where these were running successfully. I got networking set up, and
> everything was looking good till I tried to tackle the monitor configuration.
>
> I decided that rather than messing about creating a 1280 x 800 MDF to suit
> the laptop screen, I would use the AnyMode module, so I downloaded tthat and
> created an Obey file to load it and set the mode:
>
> RMEnsure AnyMode 0.00 RMLoad ADFS::HardDisc4.$.Utilities.AnyMode.AnyMode
> WimpMode X1280 Y800 C32k
>
> I tested it and it worked nicely.
>
> I then double-clicked !Boot, and opened the section of configuration to run
> things at boot, and dragged the new Obey file from the Filer window to here,
> and clicked Set. Various problems occurred after this, not least being
> unable to complete the boot sequence next time I restarted the emulator.
> After some investigation I have found that it's reproducible to a large
> extent.
>
> This is what happens:
>
> On clicking Set it takes ages to save the new Desktop boot file to
> !Boot.Choices.Boot (the Set button stays depressed and the machine
> single-tasks) but eventually it comes back to multitasking. If I go looking
> in !Boot.Choices.Boot then I find that the new line to run the Obey file has
> appeared in the Desktop file but the Desktop file sometimes has filetype Data
> instead of Desktop, and the file is about a megabyte long (exactly how long
> varies when I try to reproduce). A few lines further on from the new line it
> switches to garbage that looks like it has come from elsewhere on the hard
> disc. For example, some bits look like the !RunImage of an application I
> wrote (I recognise the function names) and another bit looks like some sort
> of NetSurf log.
>
> My first thought was that perhaps the hard disc image I was starting with was
> corrupted somehow. I have checked the hard disc image with *checkmap and
> with DiscKnight before and after adding the extra item to be Run on boot, and
> they report all is well. After moving the Desktop file to DesktopBad to
> allow rebooting to take place, the hard disc image is still reported as fine.
>
> This suggests to me that some part of the configure application is not
> functioning correctly under emulation for some reason.
>
> (If the corrupted !Boot.Choices.Boot.Desktop file is moved out of the way,
> then double-clicking !Boot then clicking Boot then Run crashes the emulator
> entirely (it just exits). I've not tested on a RISC OS 4 machine but on RISC
> OS 5 in this circumstance I get an unhelpful error, so it's not very clever
> about that file not being present. Putting a blank Desktop file of type
> Desktop in place cures this problem, but I am surprised at the emulator
> quitting like that.)
>
> Trying the same process with RISC OS Select 3i4 (on a different hd4.hdf) does
> not have the long pause at the point of clicking Set on the "Run at startup"
> dialogue. You can click Set there and then immediately click Set on teh
> "Boot sequence" dialogue. But then the next dialogue, a signle tasking
> "Message from Boot Setup", which warns that changes will only take effect
> from the next boot, hangs around for ages and does not seem to respond to a
> click on "OK" at all. Eventually I get it to click. But aside from this
> peculiarity the Desktop boot file gets written correctly.
>
> Do you think this indicates a problem with the emulation that warrants
> further investigation? In which case can I provide any logs that would help?
> Or would it be better for me just to start from scratch with a blank hard
> disc image and set up a new boot sequence, rather than trying to use one
> copied from an installation on another machine?
>
> --
> Matthew Phillips
> Durham
>
> _______________________________________________
> Rpcemu mailing list
> Rpcemu@riscos.info
> http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

_______________________________________________
Rpcemu mailing list
Rpcemu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu