RPCEmu - Adding Imaged HDD, Computer Concepts CompressFS.

[ScurvyGeek]

Hello all,

Apologies for compressing two question into one.

Firstly, I've imaged a 10.2GB IDE HDD from a StrongArm RiscPC on my Mac. I've used dd as follows:

sudo dd if=/dev/disk7 of=mydisk.hdf bs=512

Which has created the image (correctly I believe). I've then packed the first 512bytes using a Windows utility called "chk" before renaming to hd4.hdf in the data folder in RPCEmu. Sadly, it sees the disk as unformatted.

My second question, semi-related, is that I've been recovering files from floppy disks that are in the Computer Concepts Compress FS (D96) format. How do I solve the chicken / egg dilemma of getting !Spark, !CompressFS et al into the emulator via HostFS without MacOS mangling them?

TIA!

[geraldholdsworth]

To transfer applications via a host OS, you'll need to zip them in RISC OS, transfer the zip file, then unzip in the emulator.

Your hard drive issue - you could try and open it in Disc Image Manager. That will only tell you if it is in a format that RPCEmu likes.

[ScurvyGeek]

Thanks Gerald.

My issue with apps is something of a catch-22. How do I get something that reads ZIP files into the emu via HostFS without zipping them first… if you catch my drift.

Will research Disk Image Manager now.

[ScurvyGeek]

Hi Gerald, your Disk Image Manager app (very cool, btw) didn't recognise the format, so I'm trying again. Worst comes to the worst I'll use WinDiskImager that others appear to have utilised with success.

-Austin.

[paintings]

My issue with apps is something of a catch-22. How do I get something that reads ZIP files into the emu via HostFS without zipping them first… if you catch my drift.

Grab the self-extracting version of SparkFS from https://www.riscosopen.org/content/downloads/common

In RISC OS, set the filetype to "Utility", then double-click on the file. This will give you a read-only copy of the SparkFS application, which can then be used to unpack other ZIP files.

[geraldholdsworth]

Hi Gerald, your Disk Image Manager app (very cool, btw) didn't recognise the format, so I'm trying again. Worst comes to the worst I'll use WinDiskImager that others appear to have utilised with success.

I would usually, in these cases, look at the image through a hex editor (I just happen to have written one of those too) to see how it is laid out. This will then confirm to me, in the first instance, that something has actually been written.

[ScurvyGeek]

Hi Gerald, your Disk Image Manager app (very cool, btw) didn't recognise the format, so I'm trying again. Worst comes to the worst I'll use WinDiskImager that others appear to have utilised with success.

I would usually, in these cases, look at the image through a hex editor (I just happen to have written one of those too) to see how it is laid out. This will then confirm to me, in the first instance, that something has actually been written.

Thank you again, for your assistance. I've loaded it in your hex editor (see picture) and despite a section of 000's at the front, and a lot of blank space at the end there's *something* there.

Still won't load in your image editor nor RPCEmu though.

[geraldholdsworth]

Interesting section should be at 0xC00 and 0xD00...although, if you've put in 512 bytes of zeros this will now be at 0xE00 and 0xF00. Essentially, this is the ADFS new map header - tells ADFS where to find everything else.

EDIT: You can always send me the image and I'll look through it to spot where there might be an issue...or even if it is a valid ADFS image. You might have grabbed all the track and sector IDs that image files don't have (but are present in HxC files...if I remember correctly).

[ScurvyGeek]

Thanks Gerald,

I've sent you a PM.

-Austin.

[ScurvyGeek]

Interesting section should be at 0xC00 and 0xD00...although, if you've put in 512 bytes of zeros this will now be at 0xE00 and 0xF00. Essentially, this is the ADFS new map header - tells ADFS where to find everything else.

EDIT: You can always send me the image and I'll look through it to spot where there might be an issue...or even if it is a valid ADFS image. You might have grabbed all the track and sector IDs that image files don't have (but are present in HxC files...if I remember correctly).

I've re-imaged the disk.

C00 can be seen in the image:

D00 is straight zeros.

-Austin.

[geraldholdsworth]

Sorry, should've been more specific - the section from 0xC00 to 0xDFF:

This in an example hdf file which has the 512 byte header, hence why it is 0xE00 to 0xFFF. The one you've sent is currently downloading - gonna be another 20 minutes, apparently.

[geraldholdsworth]

Taking a few attempts to download it. I've managed to download the start of the file so I can look at the disc record, which looks valid. I've just calculated where the map (and hence, the root) should be but that is beyond what I've downloaded, so bear with...

[helpful]

What versions of RISC OS are you using on the RiscPC and RPCEmu? Assume you've matched them?

[geraldholdsworth]

OK - have it.

I calculated, and Disc Image Manager came up with the same result, that the map should be at offset 0x31118000...but it is just blank.

I'll get File Dump to see if it can find a 'Hugo', 'Nick' or 'SBPr' directory signature. Could take a while, considering the size of the file.

EDIT: The file extension should be '.hdf' for RPCEmu...Disc Image Manager doesn't care about that bit. One thing I haven't actually tried is replicating your problem with RPCEmu

[geraldholdsworth]

OK - the disc record held at location 0xDC0 should be repeated at location 0x0131118000 (half way through the image, roughly), and again a few sectors later. However, I did a complete search of the entire 10GB (for the first 8 bytes of the disc record) and it does not appear again anywhere. This suggests that your imaging tool only imaged a certain amount of the disc before just padding out the length of it with zeros. So, yes, it is not a valid image. Where it gave up, I am uncertain. In addition (and not sure why) but the reported disc size (in the disc record) is 0x0262500000 bytes whereas the file size of the image is reported to be 0x0262862400 - they should be identical (but not essential that they are, I don't think).

[ScurvyGeek]

What versions of RISC OS are you using on the RiscPC and RPCEmu? Assume you've matched them?

That's a bit tricky, as the RIscPC isn't mine so I don't know. I'm using 3.6 ROMS and *think* that the hard drive might be 3.7 but can't be sure.

-Austin.

[ScurvyGeek]

OK - the disc record held at location 0xDC0 should be repeated at location 0x0131118000 (half way through the image, roughly), and again a few sectors later. However, I did a complete search of the entire 10GB (for the first 8 bytes of the disc record) and it does not appear again anywhere. This suggests that your imaging tool only imaged a certain amount of the disc before just padding out the length of it with zeros. So, yes, it is not a valid image. Where it gave up, I am uncertain. In addition (and not sure why) but the reported disc size (in the disc record) is 0x0262500000 bytes whereas the file size of the image is reported to be 0x0262862400 - they should be identical (but not essential that they are, I don't think).

Thank you for going to such great trouble over this Gerald. I've never known dd do anything other than faithfully read each bit of a disk. Perhaps the USB --> PATA adapter is at fault here?

I tried Win 32 Disk Imager as is mentioned elsewhere on this site and across the 'net but I couldn't get it to detect the disk. I did find something called "HDD RAW Copy Tool 1.10" which read it, and produced a .img file of the requisite 10.25GB. Would this be a better bet do you think, and could I just change the extension to .hdf?

-Austin.

[geraldholdsworth]

Would this be a better bet do you think, and could I just change the extension to .hdf?

Only one way to find out!

[geraldholdsworth]

What versions of RISC OS are you using on the RiscPC and RPCEmu? Assume you've matched them?

That's a bit tricky, as the RIscPC isn't mine so I don't know. I'm using 3.6 ROMS and *think* that the hard drive might be 3.7 but can't be sure.

The format looks like a '+' variety (i.e. E+ or F+)...was that not 3.7?

[SarahWalker]

+ variants are RO 4 and later.

[ScurvyGeek]

Thanks everyone.

Trying to learn fast here, so apologies if I'm misinterpreting your sage advice...

So does it appear that the disk image is in an ADFS F+ format, which is why it's not readable by Gerald's Disk Image Manager, and also why my RISCOS 3.6 RPCEmu won't read them?

I'll try again with a RISCOS4+ setup, can anyone point me as to whether I still need to add the padding on the front of the image, and (if such exists) point me to a MacOS utility that I could use to perform this?

-Austin.

[geraldholdsworth]

Disc Image Manager will read + (aka 'Big') formatted images. But, yes, you'll need RISC OS 4 in RPCEmu (thank you Sarah - I can never remember when what was introduced).
However, your image (the one you sent to me) is invalid and can't be read by anything - although there is data there that can be recovered. But there is no allocation map (aka free space map), root directory or full disc record (only the partial). If you've successfully reimaged it, you can check with a hex dump utility to ensure you have that disc record at location 0x131118000 (well, 0x131118004, as you'll have 4 bytes of the zone header here).

+ (Big) formats introduced long filenames, but also, and more importantly, introduced another 4 bytes in which to store the disc size in. Previously, it was limited to 4 bytes (so max, in theory, would be 0xFFFFFFFF bytes, or 4GB, long, but is now, in theory, 0xFFFFFFFFFFFFFFFF bytes long).

[iainfm]

Hello all,

Apologies for compressing two question into one.

Firstly, I've imaged a 10.2GB IDE HDD from a StrongArm RiscPC on my Mac. I've used dd as follows:

sudo dd if=/dev/disk7 of=mydisk.hdf bs=512

Which has created the image (correctly I believe). I've then packed the first 512bytes using a Windows utility called "chk" before renaming to hd4.hdf in the data folder in RPCEmu. Sadly, it sees the disk as unformatted.

My second question, semi-related, is that I've been recovering files from floppy disks that are in the Computer Concepts Compress FS (D96) format. How do I solve the chicken / egg dilemma of getting !Spark, !CompressFS et al into the emulator via HostFS without MacOS mangling them?

TIA!

Hi, how is the RPC HD connected to the mac? I presume it's some kind of USB/firewire/whatever macs have?

I had problems reading a PATA drive from an A5000 on a laptop with a USB adapter. I don't think they understand CHS addressing and my drive didn't support LBA (or something). In the end I duplicated the hard disk onto a CF card in the A5000, then imaged that. Details here.

For your chicken and egg dilemma, the usual way is to install the self-extracting version of SparkPlug, and from there you can unzip the other tools you need (eg SparkFS). Details here.

[ScurvyGeek]

Thanks again everyone for the continued assistance, I thought I'd post back with an update.

So I've elected to work around the problem since I didn't seem to be getting anywhere with my current approach, and I'm pleased to report some success.

Since dd'ing the disk (connected via a USB --> PATA adapter to my Mac) didn't seem to be bearing any fruit, I elected for a two pronged attack.

1) Set up an Ubuntu machine to dd the disk, in case there's something related to the BSD-based dd that OS X employ causing problems.
2) Set up a Raspberry Pi with RISC OS Pi and react connect the disk.

Approach 1 had the same result - image wouldn't load in Disc Image Manager, wouldn't work in RPCEmu either with or without adding the padded data. I parked the resultant image for a test later on.

I had some fun getting RISC OS Pi going, not least because the only Pi I could lay my hands on was employed as a 2nd Processor Emulator for my 8 bit Acorns. Anyway, I managed to get it up and running and the drive mounted straight away. I copied the contents to a series of compressed folders which I moved over to RPCEmu using HostFS. I then created a hd4.hdf by using !HForm to make a 13GB image file. Finally, I extracted all of the compressed folders on to the now-happy Drive 4. This worked beautifully for about 3 boots of the emulator, and now I get "Error when reading ADFS::HardDisc4.$ - Broken directory" when accessing it. Ah well, this emulator seems intent to fight me all the way! I got a copy of the free (check only) version of DiskKnight running and sure enough it reported issues with the root directory. Annoyingly though, I can only buy the full version by using PlingStore which does run on my 3.7 system but there's no functioning networking. Any ideas??

Finally - back to the dd image that neither Disc Image Manager nor RPCEmu can make use of. dd has *never* let me down before so I felt obliged to check that it wasn't doing so here. I used dd to copy the image I'd captured onto a completely different disk - a 2.5" SATA one - and connected this up to my Raspberry Pi. It mounted straight up, an exact replica of the 10.2GB PATA unit.

So I don't know what - if anything - this tells us.

If anyone can resolve my corrupted hd4.hdf I'd be much obliged. Took me some 3 hours to get it made and the data copied on!

-Austin.

[acorndave]

David Ruck the author of Disk Knight is a very helpful chappy. drop him an email

discknight@armclub.org.uk

And I'm sure he'll sort you out with regards to purchasing a fully copy if Pling Store is no good to you

[ScurvyGeek]

David Ruck the author of Disk Knight is a very helpful chappy. drop him an email

discknight@armclub.org.uk

And I'm sure he'll sort you out with regards to purchasing a fully copy if Pling Store is no good to you

Thanks Dave, doing so now.

-Austin.

[davidb]

I've only skimmed this thread, so apologies if this is old advice.

Does the disk image need to be modified slightly for RPCEmu as described in this stardot thread and in the ROOL forum? (The byte modifications, not the 512 byte header.)

[geraldholdsworth]

If anyone can resolve my corrupted hd4.hdf I'd be much obliged. Took me some 3 hours to get it made and the data copied on!

Sounds like you're making progress, which is good news.

Disc Image Manager can attempt to repair broken directories in images. Plus it won't modify the original, so if it all goes pear shaped, you still have your original (unless you save over it, of course).

[ScurvyGeek]

If anyone can resolve my corrupted hd4.hdf I'd be much obliged. Took me some 3 hours to get it made and the data copied on!

Sounds like you're making progress, which is good news.

Disc Image Manager can attempt to repair broken directories in images. Plus it won't modify the original, so if it all goes pear shaped, you still have your original (unless you save over it, of course).

That's the thing Gerald - it won't open it. Is it too big? Is it related to the version of MacOS I'm using? The CPU Architecture?

I created a new image - smaller - 1GB in size. Used it for a few bits and bobs, when I quit RPCEmu, it damages it. This, at least, will open in Disc Image Manager (only image I've had any success with). It displays that the root directory is broken, but seemingly can't fix it.

-Austin.

[helpful]

I copied the contents to a series of compressed folders which I moved over to RPCEmu using HostFS. I then created a hd4.hdf by using !HForm to make a 13GB image file. Finally, I extracted all of the compressed folders on to the now-happy Drive 4.

Is there a particular reason why you moved them to an hd image? If you've got all the files in HostFS then leave them there! I can't think of any benefit to using an hd image unless you have some really fussy software that will only run from ADFS.

BTW, still lacking info on what version of RPCEmu you are using, which version of RISC OS for these later attempts (really need 4.x), what version of MacOS, what machine (x86 or ARM)??? More info the better!

Bryan.