Iyonix HDDs 120GB Mounting in an Emulator

I would like to give my Iyonix a new home and go down the emulation route. The Iyonix has a pair of 120GB hard discs which I would ideally like to mount in an emulator after imaging. I guessed that this may be possible via RPCEmu but my subsequent understanding, after reading the documentation, is that this won’t be possible.

I’m running Ubuntu Pro 22.04 and have mounted a test 1 GB flash drive image in Linux (preserving the RISC OS type suffixes). I’ve also used Disk Image Manager which also worked well and is a very impressive piece of software. I’m happy with these options in that I potentially have at least one way of accessing the 120 GB discs from the Linux side, a positive first step.

There’s information on prefixing 512 of zero bytes to the disc image and fixing it up for mounting in emulators which I’ve followed but none of the images I tried worked on the 1 GB flash drive image and they refused to mount in Arculator 2.0 and RPCEmu (me doing something silly me thinks). I feel that ultimately 120 GB image size will perhaps be too large to mount in any Acorn emulator anyhow. Does anyone know if mounting large 120 GB discs is possible in any Acorn emulators please?

You can mount an HD image within RISC OS using HDFFS

You can mount an HD image within RISC OS using HDFFS

HDFFS can mount an image beyond the RISC OS 4-GiB-per-File limit? How does it achieve that?

HDFFS can mount an image beyond the RISC OS 4-GiB-per-File limit?

Unfortunately not, FileCore and filesystem limits still apply.

It should be dead easy to get a HDD image that is usable with RPCEmu from Linux.

As you say, there’s a bug/oddity with RPCEmu’s harddisc access with the 512 byte offset. It’s not too complicated to create such an image.

You want to get the data off the 120GB disc as soon as possible so that it’s preserved, rather than accessing it directly. Here’s how to do it…

This is terminal commands, so open up a terminal. You may need to do these operations as root, in which case use `sudo -s` to get yourself a root shell. You will need to plug the disc in and then identify which device is it – usually this will be visible if you use ‘dmesg’ to list the messages from the kernel after plugging it in. This will produce a message something like this:

[    2.331629]  sdc: unknown partition table
[    2.333903] sd 2:0:2:0: [sdc] Attached SCSI disk

… somewhere in the output near the end. That’s most likely the disc you want. You’ll need a disc to copy it to, but 120GB is small these days, so you’ve probably got enough space lying around anyhow. In this case, the device name is sdc.

What you’re wanting to do is to copy the disc to an image. If you want to create a copy of the disc which has 512 bytes of 0s at the front there’s a very simple way to do it with the dd command. Work out where you’re putting the output image – I’d suggest somewhere in your home directory, like /home/<username>/Documents/IyonixDisc.hdf, or if you’re sharing the system with others, somewhere like /var/lib/rpcemu-disks/IyonixDisc.hdf.

You want to run…

dd bs=512 seek=1 if=/dev/(device-name) of=(output-image-name)

And wait. It’ll take a while.

If you’re already imaged the disc to a file on your linux system, then instead of using /dev/(device-name) you just use the raw image file that you created.

Once you’re done, you’ll need to make the output image accessible by the user that’s using the image if you were using the root shell, so something like:

chown dlamda (output-image-name)

Then, in RPCEmu you tell it where your disc image is, and save the configuration. It’ll either ask you to reboot or it’ll do it for you – I cannot remember which. Once you’ve done that, you should have disc image that is accessible in the emulator.

The command uses bs to give the ‘block size’ that we will be operating on – 512 bytes – and the seek causes the output to seek forwards to 512 bytes into the output file. The if is the ‘input file’, and the of is the ‘output file’.

If you wanted to copy the disc for preservation, not as a RPCEmu disc image, just you can omit the seek=1 from the dd command.

Thankyou for your encouraging words. I am thinking about your post now. I did the dd 0 byte 512 created a file the ran cat to put my image in front of the zero bytes. Will contknue to read your post now. Jon I had already tried HDDFS prior to this very early on with no luck sorry. Thinking about it though if an image file is essentially an iso. I could use !cdfaker to mount the iso in riscos?

Thinking about it though if an image file is essentially an iso. I could use !cdfaker to mount the iso in riscos?

Yes

Thinking about it though if an image file is essentially an iso.

An image file might be an ISO – and ISO being a file containing ISO9660 formatted information – but the thing you have copied from a harddisc does not contain ISO9660 formatted information. You cannot mount a harddisc through the CD system. If you had a harddisc image on a CD, it would not be recognised by RISC OS. So, no this will not work in this case.

Just mount the hard disc in Linux as ADFS, copy the data off into a dir under your RPCEmu.

You don’t say whether or not the Iyonix is still working. If it is and you have the time available, you could try what I have done on a smaller scale.

I’ve recently got my head around LanMan98 and have successfully transferred files to both Windows and Linux installations of RPCEmu, directly into the hostfs directory. I wouldn’t like to transfer a disc full of data in one go so I’d do it incrementally starting with the most important data first. Possibly, some of the data on the second drive is a backup for the first so you could leave that alone.

The big advantage of this method is that all the 3-character extensions would be added automatically.

The big disadvantage would be the time taken, however there are other important things which can be accomplished while you’re waiting; tea/coffee, food, sleep, exercise, dating, marriage, raising a family…

I’ve no idea how long it would take to transfer all your data. No doubt, neither of the drives is filled to capacity but I’m sure it would work in the end.

I hope I’ve not missed something obvious about your situation. If I have, and this suggestion is a non-starter, please ignore what I’ve said (my wife does so all the time); I won’t be offended.

The big advantage of this method is that all the 3-character extensions would be added automatically.

Provided that the file with the mappings is complete and up-to-date. (I wish I could remember what it’s called…)

Thanks Gerph, I had a bit of an only Fools and Horses, Trigg’s moment at 1 am this morning. I’m now saying “Oh yeaaah…cheers Dave”. Just for the h*ll of it though I tested it out anyway with lots of versions of !cdfaker and direct mounting of the CD to image. That was fun but anyway…

I didn’t go into much detail because I didn’t want to confuse the thread, can 120gb images be mounted in any Acorn emulator. There’s two layers to this can the emulator do it, i.e. real hardware and can the OS. So I have to choose wisely with the hardware that’s been emulated and the OS, so thought I’d throw it out there to the real experts before I spent too much time on it.

Definitely Stuart, I have two ways to mount a test image 1GB (because that’s easier to experiment with than a 120GB image file) ADFS and Disk Image Manager I’ll probably end up using one of those to drag and drop into HostFS. Possibly have to use ADFS as Disk Image Manager, that I looked at, copies out an extra checksum and information file with each file copy but haven’t spent too long looking into that. I have my own BASH scripts written which will do the checking for me. Not particularly happy to rely on one piece of technology ADFS mounting in Linux when we are talking about thousands and thousands of files on two full 120GB discs.

LanMan98, yup bought a copy from CJE Micros I think just for this. It was interesting to see that different amounts of files were copied when compared to Omniclient/LanManFS. LanMan98 captured more files.

Last time I looked into this Linux refused to take an image at all. I kept it simple using the built in GUI tools, “Disks”. It should because it doesn’t care about the disc format, it’s copying byte by byte, but it refused to even mount the discs reporting an error I think. I gave that up and got the fastest machine at the time which was a Raspberry 3 Model B+ with RO and left it copying the files for several days. Thinking about upgrading my USB 1.0 adapter to a 2.0 adapter though lol! That should solve potential power issue causing a mount fail if there is one, and give me another adapter to fall back to, you know more options. A direct copy failed many times until I’d matched exactly the formatting, trying lots of versions of !HForm. I have this problem now if I format a flash drive I think after 5-24, I have to match an older version of !HForm with a particular OS. It’s an easy test to do, format the flash drive copy some stuff to it, does it fall over? If not take it to another machine and copy some files over it, does the machine lock up? I’m not going to go into too much detail here but suffice to say I thought I’d had a play with cluster sizes on the media I was copying to (just to test out speed of copying if it made a difference) and the only way to stop the copy from falling over was to match exactly what I was copying from and copying to. So, 4 SD cards, two with fat32 format (which ?worked?, machine didn’t die, but do I trust it? Doesn’t it write meta data for the file extensions into a spare area, corruption anyone, when used with different OSes?) and two with ADFS for each hard disc. That got me four copies. How good those copies were, I don’t know I couldn’t checksum it for whatever reason (this is a very long time ago), I just ran a count. The discs enjoyed their work out and I think it did the mechanics of the drive some good, running more silently than before.

Now I have a click of death on one disc. They say that’s a disc fail issue, but in my experience it can also be power related. Great buy another power supply. Been there done that couldn’t even source a spare PSU that worked to put in a cupboard somewhere. For a scenario, well, exactly like this one. To check the PSU you copy files and run a count, you’ll get differences if the PSU isn’t up to it. I think I sent sent this useful diagnosis/testing information to the supplier at the time. Thinking about it though I did get a PSU from a computer shop and it just worked, probably because they had a really old model with an fdd connector! Hopefully emulation is the better route for me rather than trying to maintain a load of old hardware. Yes I do have new hardware too, pinebook, mini.m, pitop1 (thanks to Rick M clipboard fix and shutdown running of scripts) and pitop2 and a lot of developer boards but not a PI 4. I want to keep those but not the really old stuff.

To possibly help others:

To mount ADFS, I used Ubuntu, created an image file and ran the following command:
sudo mount -t adfs -o loop,uid=1000,gid=1000,ftsuffix=1 hd4.img /media/mnt

Create the mnt directory as sudo.

This just worked. I also tried Disk Image Manager on this site: https://www.geraldholdsworth.co.uk/. Excellent, only crashed once in a new bit he’s just written so ran better under Wine for me.

Gerph’s tip about permissions is probably where I went wrong at this stage regarding fixing up the image:
http://www.riscos.info/pipermail/rpcemu/2011-March/001261.html

I used Jeffrey Lee’s zip he put on iconbar for this bit (I used WINE before I was confident enough at first to compile my first C program on Linux the first */ caused me some issues! So is the tip for C programming here: Ignore later errors in C just look for the first occurrence, oh line 1 comment should that be there?). Both produced exactly the same output in terms of the final fixed up image. The C program does the fixing up for RPCEmu.

I need to revisit this one as I couldn’t mount a test 1gig flash drive image in any emulator that I tried. I was thinking size was the issue or the version of !HForm I used or the version of the OS. At that point I contacted this forum.

Retried HDFFS this morning and am getting not enough memory messages when double clicking the image file (I think I worked out the correct file type). I increased the size in the next slot..

Sorry for the rushed reply, I should be studying for an MS Azure exam, but it’s so boring. Unnecessarily unmounting img files in a place where they have no business been mounted in the first place is much more interesting. Wish me luck for next week’s exam. Thanks for all your help.

Thankfully haven’t had to take a MS exam since 1996. All the best.

I’ve kept a Pentium III linux system with internal PATA support for years for such occasions, which is why I tinkered with the ADFS driver. Might help someone in the future.

An alternative approach of hooking a drive up to a USB caddy, then connecting it to RPCEmu- I don’t know.

Also, you may want to consider the consequences of selling your Iyonix and its hard disc to an inquisitive mind. ;)

Good luck with your exam!

Sorry for the rushed reply, I should be studying for an MS Azure exam, but it’s so boring.

and, since it’s a constant beta development, whatever the documentation says is correct today will be out of date before the end of the month and possibly sooner.

If the Iyonix drive/s were fitted with a adaptor – could it / they be fitted in a Ti?

When my Iyo died, I used an IDE to USB adaptor box of tricks to copy both discs on a RPi3 to my NAS using LanMan, and to a SATA SSD with a USB to SATA adaptor. Subsequently I used the SSD with my RPi3 until I got a Titanium, then I copied the SSD using USB to the Titanium SSD. Full copies can take a while, but that was not a problem.

I managed to get valid image files from my two Iyonix discs. FYI: The reason why I couldn’t get Linux to read the discs with my vintage IDE adapter last time I tried this exercise is that the power adapter was so old it wasn’t providing enough power to the discs (so I plugged disc being imaged into Iyonix PSU) but also the IDE connector was smaller than the connector on the discs and it wasn’t keyed! I did manage to get one image though the old IDE adapter and bought a brand new IDE adapter and reimaged the disc and compared the checksum. So I had validated the new IDE adapter was working by comparing the image file outputted from the new IDE adapter to the old IDE adapter. Both image files were identical.

A couple of fun issues. Plugging the old IDE adapter into a USB 2.0 hub made the image take 1 day and 8 hours estimated time! Plugging directly into the USB 2.0 port on computer brought that down to 1 1/2 hours to 2 hours. But like I said I was then able to get an image of the Iyonix discs with the old IDE adapter and the checksums matched the image made on a new IDE adapter which took half an hour over USB 3.0. BTW: For anyone else doing this, don’t bother copying files to another disc with RO it’s too slow, lots of small files to copy and no way to validate copies easily. Over network is too slow if you have lots of data and again validation is too hard. The destination discs have to use the same version of !HDForm or RO or both, something I think may have changed after RO 5.24 so for copies to work in my experience you have to carefully match how source disc was created to destination? Anyways…

I’ve created a disc image file which I’ve then written to an m.2 drive which I had here in a box. The two drives nvme (also spare in a box) and m.2 sata are 128 GB and my Iyonix discs were 120 GB. So I had a bit of free space on the end of the ssd drives to write the images. These were correctly readable on another RO machine using USB to SSD adapters.

Because I’d check summed the Iyonix discs and these checksums matched the checksums of the image files I thought it would be a good idea to also check what was written to the SSDs. Appreciating that this last step is not strictly needed I was thinking it would be a good belt and braces check anyway.

Because the SSDs are different sizes to the Iyonix discs a full disc checksum on the SSDs will never match that from the Iyonix discs.

Linux does not recognise the ADFS portion of the disc which is helpful in that it won’t automatically mount the SSD in the disc management tool and potentially alter the disc affecting the checksum. The bad news is that I can’t simply checksum the ADFS bit of the disc or write the ADFS portion back out to an image file to checksum that, again from the disc management tool.

So I had to run the following commands on freshly reimaged SSDs with zero bytes written to the whole device (and therefore the extra space at the end) before laying down the Iyonix images (not plugged into RiscOS so no chance of SSDs been changed prior to the following):

Run on Iyonix disc:
blockdev —getsize64 /dev/sde

Which may report the following, which I put in the count parameter in the following command next:
128035676160

Run on SSD disc:
sudo dd if=/dev/sdf bs=512 count=128035676160 | md5sum

Still the checksums from the Iyonix disc don’t match the checksum of the SSD. What am I doing wrong here please? Is there any foreseeable issues I might have with having zero bytes in last few megabytes after the Iyonix disc image laid down on larger SSDs with Risc-OS?

Hope that makes sense, thanks.

p.s I passed my Azure exam that week. I was lucky, high percentage pass mark but also had to do a few CompTIAs to provide a bit more stimulation. I was lucky with those exams as well.

Still the checksums from the Iyonix disc don’t match the checksum of the SSD. What am I doing wrong here please?

One possible issue is that the ADFS portion of the SSD isn’t a partition in the usual sense of the word – it occupies all of the space at the beginning of the SSD, including the MBR. A “real” Iyonix disc may never have been near a real partitioning tool so could have any amount of crud in the MBR, but when you use Linux to copy this to another SSD Linux may “helpfully” not copy this obviously-incorrect MBR while faithfully copying the rest of the image. Hence the data is all present but the checksum is wrong.

Thanks Stuart. I didn’t explain the procedure I followed fully. I used the Disks application and chose the “Create Disk Image” option which should behind the scenes use the dd command which should in turn clone the entire disc? When I restore the Iyonix disc image file to SSD I was hoping that Disk’s “Restore Disk” option would only lay down the Iyonix disc image file to SSD and not an MBR too which I haven’t asked it to do. If I wanted Linux to lay down it’s own MBR I wouldn’t lay down zero bytes across the whole ssd before laying down the Iyonix disc image file on the ssd. I’d format the disc, create a 120gb partition and then restore the Iyonix disc image into that partition. I don’t think my ssds would work on Risc-OS if I did that like my unchecksummed cloned ssds do but that would certainly be an interesting experiment. To be honest I didn’t even know that Risc-OS didn’t have an MBR. I think it’s got a partition table in middle of disc but that’s beyond my level of technical know how I’m afraid.

Sorry not partition table in middle of disc whatever the table is called that describes the discs contents lol

As an aside, I’ve been pondering how I could support imaging large HD with Partition Manager and support mounting them under HDFFS.

I could split them up into 2GB chunks when dumping them and modify HDFFS to support an HD across multiple files. It might get a bit unwieldy with the number of files, but as a last resort might be usable.

Jon I was thinking about some form of automation ideally in RO because that might be of use to suppliers/users anyone who is doing any sort of tech refresh. Or just wants a fast one time archive backup. But, as you know RO has a file size limit so an image file on an RO won’t work. I never saw how Elesars imaging tool for RO worked so dunno. I think it may involve a network…things start to get more complicated for end user. If I’m integrating RO with Linux there’s no point really in automating. I was also thinking of chunking. I will have another go with !hdffs and take a look.

You could split the checksuming up over chunks of the disc, to see where the differences are – I’d bet either the beginning or the end.

Note that FileCore does have a cycle ID, so if it’s mounted by RISC OS the disc boot block will change, invalidating any checksum of the start of the image.

Stuart and David. You’ve given me a few ideas thanks for your input. If I’m right, the bit at the end will be very much causing the check sum differences. Fingers crossed, but got to do a few things over next day or two but will come back to this and repost my findings. For right now I’ll mount the two image files which are exactly the same as the original Iyonix HDDs and checksum every file and mount the SSDs and do the same. By mount I mean using Linux’s ADFS. That should verify the SSDs are good and be a enough to put my mind at ease. Ideally I think a procedure for imaging and checksumming the image files and rewrite to any other media albeit larger than the original HDDs or the same size and checksumming that would be more useful. In terms of opening the images and SSDs in Linux ADFS I have already written a BASH script to check the contents or every file. That’ll certainly test out ADFS on Linux, so is a very useful test if I’m later to access my files via emulation. Would anyone mind if I created a WIKI page on here, if I can resolve this issue? Stuart have you created WIKI pages, if so would you mind pointing me in the right direction please?