Before we start todays epic, well written and informative blog*, here's a quick video which I took a few days ago.
*your mileage may vary
As you can see, not only does the Torch boot up but it can mount other disk partitions and, rather excellently, play games! This is eerily reminiscent of one of the first games I played on the ZX Spectrum way back in 1985 which was a simple bat & ball breakout style game which I think was written in Sinclair Basic. Anyway, I'm rubbish at games.
More interesting was that I could actually mount the other partitions on the disk through a bit of trial and error. The /dev folder contains a list of 'devices' that the disk image would have access to, but there are more there than are actually in use. To work out which ones are available was simple case of creating a folder in the 'root' folder and then attempt to mount each of the devices to that folder as a mountpoint. For example:
#mount /dev/disk0b /root/hd0
If the 'diskxx' was valid then there was no response in the terminal and I could go and 'ls' the hd0 folder. A lot of the diskxx came up as 'unable to mount diskxx' (or similar) which means that the device exists in the /dev folder but isn't actually related to any valid disk partition.
From all this I managed to mount (and then umount) all of valid partitions. There were two that seemed to just contain basic unix installs, but there were also two that, while similar, contained a 'games' folder, hence the video.
With all this I started to wonder if I could mount these disk images in a more modern unix like operating system i.e. Linux. This would make it much easier to read through the config files and potentially update them (**foreshadowing**) to get the system booting fully. But how do I do that?
To be honest, I had tried before with zero success. Every time I would try to mount the image I would just get a long winded error about 'incorrect fs, bad superblock blah blah I'm not doing it so nyar' or similar.
Anyway. I decided to try again but this time I did a bit of research. It soon transpired that I am an idiot. I should have realised that I could not just mount the whole disk image, rather I had to mount the partitions. But to do this, I need to know where the partitions start. And this is where the Torch disk utility comes in.
When the Torch boots there is an icon of a hand with the word 'STOP' underneath it. Clicking this during the boot process brings up a few more icons, one of which is the 'Disk Toolkit'.
![]() |
Torch menu - Boot, Disk Utility or Password? |
![]() |
"Here be dragons!" |
After a friendly warning that you really need to read the flippin' manual and a couple more confirmation screens (which disk to select being the main one - default is SCSI 0 LUN 0 which is fine), a rather utilitarian menu appears.
![]() |
"What option(s) do I have?" |
From here I need option 5 - Partition hard disk. What this does is give lots of options of how to handle the existing partitions but more importantly, it tells me where on the disk the partitions are located.
![]() |
Location, location, location. |
The photo above shows that this particular disk image has four partitions:
Partition 0 - size 247 kilobytes, start address 4
Partition 1 - size 10000 kilobytes, start address 498
Partition 2 - size 5153 kilobytes, start address 20498
Partition 3 - size 31500 kilobytes, start address 30804
To mount them in Linux is now fairly simple. Take the SD card with the image and plug it into a handy laptop running some version of Linux. Head to a terminal and type the following:
#> sudo mount -o ro,loop,noload,offset=2048 mydisk.img /mnt/mymountfolder
where 'mydisk.img' is the name of the disk image and /mnt/mymountfolder/ is the folder to mount the partition to.
The offset value is the most important parameter here. It tells the system where the start of the partition is. To calculate the offset, take the start address and multiply by the sector size which in this case is 512kb. So 4x512 makes 2048.
If successful then there is no feedback from the mount command but the folder /mnt/mymountfolder will now contain the files on that partition.
A couple of caveats. More modern Linux versions may not have UFS active by default. I found I needed to start this on one of my Linux installs with 'modprobe ufs'. UFS is the legacy unix filesystem and, again, some modern linux systems i.e. the ones that try to be as user friendly as possible, may not support writing to UFS. I found my Mint install couldn't write but my ArchLinux laptop had no problems and didn't actually even need the modprobe.
It remains to be seen whether having read/write access to any of the disk images will end up being useful. I am hoping that I will be able to decipher the startup sequence on some of the other disk images and work out how to get the full GUI running.
Anyway, in other news I have managed to source a reasonably priced replacement IC for my OMTI controller card. It arrived all the way from Germany (thanks Deutsche post!). I'd previously worked out that it was this specific chip thanks to a quick chip swapping session with the working OMTI on loan from binarydinosaurs.co.uk and, as luck would have it, it was the second chip I swapped that proved to be the faulty one.
![]() |
Please work, please work, please work.... |
After removing the offending faulty chip from my OMTI board I very carefully inserted the new (old) chip and pushed it home into the PLCC socket. This was rather more stressful than I had imagined as the socket was surprisingly tight. I took this as a good sign.
![]() |
OMTI5200, now with new(old) chip. |
But does it now work? After carefully dismantling all the cables around the 'on loan' board I even more carefully plugged it all back in. I also checked the SCSI ID was correct at ID 1 for the floppy. And then, I switched it all on...
![]() |
Success! |
Yay! It worked! I now have a fully working OMTI5200 board so I can finally return binary dinosaur's board. Wa-hoo!
Next time, some more disk image antics and I try working out how to access a floppy drive.