hd4 not mounting

Hi all.
Been looking through the documentation for RPCemu, followed the instructions and no luck in mounting the hd4 image (tried various disk images). I’m running windows 7, sp1. Any help would be appreciated.

According to the website, IDE gets disabled by the emulator when using RO5 because of a data loss bug. You can use HostFS though… download the self-extracting HardDisc4 image, put it in RPCemu’s HostFS folder, set type to Utility, run it and move the contents of the HardDisc4 folder that appears to the top level. Then press F12 and enter the following:

configure filesystem hostfs
configure boot

and reset the emulator.

Thanks for your responce. Just was hoped it was something I was doing wrong!

Bump… Sprow, do you know what’s happening here? I don’t see anything in either the RPCEmu source code about disabling IDE support. From the ADFS module, it looks like ADFS is built without hard drive support (there’s no *Configure IDEDiscs available). But presumably it works in a real RPC, else people wouldn’t be able to use their hard drive?

(This is with IOMD ROM downloaded today, RPCEmu 0.8.9)

I’m no Sprow, but…

From the ADFS module, it looks like ADFS is built without hard drive support (there’s no *Configure IDEDiscs available).

There’s no *Configure IDEDiscs because the RISC OS 5 version of ADFS auto detects the drives.

But presumably it works in a real RPC, else people wouldn’t be able to use their hard drive?

Yes, hard discs work fine on a real RPC. With some of Sprow’s recent changes floppies should now work too.

If IDE support isn’t disabled in the RPCEmu sources, perhaps it’s that RPCEmu doesn’t support the drive detection method? Although whenever I’ve seen the RPCEmu developers talk about it I’m fairly certain they’ve always said IDE support was disabled due to bugs (whether they turn out to be RPCEmu bugs or RISC OS bugs).

Hard discs work fine on a real RPC. With some of Sprow’s recent changes floppies should now work too.

What he said! This is with A7000/A7000+/Risc PC so if it’s not happy in an emulator it’s more likely the emulator isn’t as faithful as it could be. For example ADFS now uses the verify op with the controller (1990 ish era) but in RPCEmu that quits with an unknown floppy operation. I took a brief look at “fdc.c” and it looks like a lot of it was empirically derived rather than a full emulation from a datasheet.

I too heard the “data lost” rumor and assumed it was an emulator thing, since the real McCoy doesn’t have this problem. But if there’s no magic in RPCEmu then I’m not sure of the origin of the rumor! One for the RPCEmu mailing list?

I can’t answer for why IDE drives don’t show up at all, this is something that’s changed since the last time I looked at RO5/RPCemu.

The ‘data lost’ bug in current versions of RPCemu is real, however the description is not quite accurate. The present code will/should give intermittent errors when accessing IDE discs under RO5, fixing this bug will give data corruption under 3.x/4.x so the fix isn’t implemented.

I did send a patch which fixed this issue, along with some other IDE issues, back in February but it hasn’t been used for whatever reason.

Hi Tom, can you resend the Feb IDE fix please, I think it’s gotten lost somewhere. I’ve a May fix about cdrom ID but nothing from Feb.

I sent the fix last night, can you confirm you’ve received it?

Incidentally, with a modified RPCemu 0.8.9 and RO 5.19, I’ve confirmed that with this patch the IDE drives do now show up.

Yep I received it, but due to the size of the diff and the amount of changes from pcem to rpcemu required it’s not likely to be integrated quickly.

" The present code will/should give intermittent errors when accessing IDE discs under RO5, fixing this bug will give data corruption under 3.x/4.x so the fix isn’t implemented."

Would it be so unacceptable to have a RO5-only version of RPCEmu? After all, RO5 is the latest version of the OS; it is still under development (unlike all earlier versions); it is 32-bit and therefore runs measurably faster under emulation than its 26-bit predecessors. These are powerful arguments IMO in favour of the fullest possible emulation of what is in fact the flagship OS version. A suitable version numbering convention identifying the required OS (0.8.9/5, for example) and a read-me-first text prohibiting use with RO3/4 would hopefully be sufficient to prevent accidental misuse.

It would be unacceptable, as there’s no reason why the same version shouldn’t run both RO3/4 and RO5.

The thing is, RPCEmu is intended to emulate a RiscPC.

If you’re emulating a specific machine, it should behave bug-for-bug exactly like that specific machine. (Meaning, if something acts differently from the real machine, that is a bug in the emulator, EVEN IF IT FIXES A BUG THAT THE REAL MACHINE HAS.)

That said, there is an argument for making an emulator that isn’t RiscPC-specific for running RISC OS, to take advantage of modern developments. (Or, make an RPCEmu fork that maintains some compatibility with a RiscPC for running some legacy software that is used to, for instance, the behavior of the VIDC20, but has modern enhancements.)

@Peter Howkins

The marutan.net web site is throwing up 403 errors (at least from where I’m sitting, and people don’t normally block the NHS)

> download the self-extracting HardDisc4 image, put it in RPCemu’s HostFS folder, set type to Utility, run it and move the contents of the HardDisc4 folder that appears to the top level. Then press F12 and enter the following:

> configure filesystem hostfs
> configure boot

> and reset the emulator.

I seem to be having the same problem. It seems to be caused by !Scrap’s !RunImage file.

Is it supposed to contain several zero bytes or has it become corrupted?

Is it supposed to contain several zero bytes or has it become corrupted?

It is corrupt.