As there is no sign of this application on any disk I had to type it in myself which was (C)Not Fun. After correcting several typos that resulted in compile errors I reached a point I could not get past. The compiler was throwing an error that the file libw.a was of an unknown type. Hmm. This was a bit annoying.
 |
| Do you know the magic number? |
It turns out that the 'magic number' is a Unix way of identifying the type of file, and it appears in the first few bytes of a file. Unfortunately, this file was saying it was type '000000' which the compiler/linker really did not like. This specific file, having the .a suffix, is actually an archive file. So I tried the Unix command 'ar -t libw.a' and it told me that the file was not a valid archive. Hmmm.
Fortunately, I have access to several different disk images, including the original SysV floppy images. This gave me the chance to recover an earlier (or non-corrupted) version of the file. Or at least it would have if not for the support for the specific filesystems on the disks involved being removed from the kernel.
Tangent incoming.
I have a new laptop. It is the first new (personal) laptop I have had in twelve years. So I installed Pop OS on it for decent Linux Nvidia graphics support so I can play No Man's Sky. The latest version of Pop OS comes with v7 of the kernel. Or 7.0.11 to be exact. The last version to support SysV filesystems was 6.14. Snap to me having to install a rather old kernel and then figure out how to get to the Pop OS boot menu. Fortunately, this wasn't too strenuous and didn't actually take too long given the power of my new laptop. Did I mention I have a new laptop? 😁
With my new (old) kernel installed, I could finally go and mount some disk images. I started with the Torch 'test system' disk image - available on bitsavers - but found that this did not actually contain the file. I assume because it's actually part of the development suite which includes the errr... includes which wouldn't be on a 'test' machine. So then I tried the other available image from bitsavers but this turned out to be exactly the same file I had in my image.
Finally, I turned to the SysV disk images I had. These are not formatted like normal floppy disks and this did cause some confusion to begin with. I had completely forgotten that these are archive disks (a lot of archive stuff in Unix isn't there?) and to access them required the use of the 'cpio' command. This command makes me shudder as I successfully destroyed my Linux Mint install on my old laptop a few months ago (not my new one - did I mention I have a new laptop?) by copying all the Unix files to their exact same locations in the Linux file structure. That was an unpleasant few hours sorting out that mess... So this time I made sure I was in a specific folder and used the command:
cpio -idmv --no-absolute-filenames < ../SysVDisk1.imgThe important safety bit here was the '--no-absolute-filenames' which kept everything in the directory where we were located. Phew. And after about the third disk, I found the file I was looking for.
So with a new version of libw.a in hand would the code compile?
No.
I began to think that the version of libw.a on the Torch was actually not going to work at all. I had a look at the first few bytes of the libw.a file and a known good different file called libc.a. Very interesting was that the libc.a file had the following as the first few bytes:
21 3c 61 72 63 68 3e 0a
! < a r c h > \n
But the newly copied libw.a file had:
0000 5757 726c 6173 2e6f
W W r l a s . oBy now I was convinced that this file was not going to work. And it never would have. The file itself did contain the correct *.o files but they were referenced in a different way than the Torch was accepting. How this ended up like this I have no idea. But I needed that libw.a so I wrote a small python script to pull out the files to save them individually on a Linux machine (my new laptop - did I mention that?). Then I would copy them over to the Torch and re-insert them into a valid Torch archive file using the Torch terminal. Easy.
(At this point I should say that this next section took me the best part of three days of spare time and a day of a weekend to sort out.)
Here's the handy python script I knocked up (or a screenshot of some of it anyway):
 |
| A professional developer I am not... |
This successfully gave me the *.o files I needed which I duly copied over to the Torch. A quick 'ar r libw.a *.o' later and I would have a shiny new libw.a file.
And did I have a nice shiny version of libw.a, ready to insert into my /lib directory?
No.
I got this instead:
 |
| No space? NO SPACE?? |
And so, finally, I get to the point of this blog entry. How do I make more room on the Torch emulators disks?
The current layout of the disk is:
Partition 0 - 202Kb (that's KILOBYTES as in 1024 bytes multiplied by 202 - I'll die on this hill)
Partition 1 - 10Mb (/ i.e. boot partition)
Partition 2 - 5Mb (not really sure what this one is...)
Partition 3 - 26Mb (/usr)
 |
| Original disk image partitions |
At the time (c.1985) this probably seemed to be an enormous amount of storage. But in 2026, this is far too small, especially since this disk image appears to not be a 'clean' install and with me adding loads of stuff to it. There is just no more room left. So, the question is, can I make the partitions bigger, say at least twice as big?
Possibly.
First things first. The emulator supports a single hard disk image. I need to update the emulator to support a second hard disk. This wasn't as hard as it might sound since it just required the addition of another copy of the existing hard disk code but tweaked to change the SCSI ID, along with a new command line option to mount it at startup.
Initially I went for SCSI ID 4 since this is way above the values of the original hardware. SCSI ID 0 LUN 0 is for the main hard disk with LUN 1 as the 'BlueSCSI' floppy drive and the Gotek is SCSI ID 1 LUN 1 so SCSI ID 4 seemed fair for a second hard disk image to keep it well away from any of the existing addresses.
Except, no.
Caretaker actually seemed OK with SCSI ID 4. Unix, not so much. Because it's not a value expected by the Torch version of Unix I actually needed to create new nodes for SCSI ID 4. And this was a complete disaster. Whatever I did, any attempt to access the hard disk partitions through Unix resulted in a hard crash. After a few hours I gave up. So I went back and tried SCSI ID 1 with LUN 0 for the second image.
And this just worked. More or less. I could run the emulator and enter the Caretaker disk manager program which appeared to give me to access SCSI ID 1. It also gave me a set of default values for the partitions on SCSI ID 1, except there was a problem. The 'size(K) left' value was -13000Kb. Ah. Well that's not right.
 |
| Minus 13Mb? That's probably not correct... |
After some head scratching I realised that if I turned off the 'partition alignment flag' for the partitions that had it set, then the disk space was shown correctly. So I left it switched off on those partitions.
Next problem. If I changed the size of the partitions that were not the last one then this would require the moving of some data (even though the image is technically empty). But this result in a crash 100% of the time when the partition information was written back to the drive.
 |
| Crash! Ah-aaaa! |
To get around this I had to set the partition sizes to zero. Then, as I added the new partitions with the increased sizes this meant that no data was 'moved' and the new partitions were just saved without issue. And these were the new sizes:
 |
| That's a bit more roomy... |
So now the root partition has 20Mb and /usr now has 53Mb. But it's not done yet. This was just creating the partitions on a disk image attached to SCSI ID 1 LUN 0. I still have to create the filesystems and copy across the relevant system files.
I'm jumping ahead a little bit here, but for partition 0, this just requires the re-installation of Caretaker. This is simply an option in the main menu of the disk utility that automatically loads the required boot files onto partition 0. To make sure that there were no crashes, I reinstalled caretaker then immediately rebooted. This seemed to work and there were no error. Back to the regular bits of the disk...
In the Torch I needed to identify the correct device nodes in the /dev directory. Simply put, these nodes are the interface points for the hard disk. Fortunately, this was fairly straighforward. In /dev there is another directory called 'dsk'. Inside this are a series of existing nodes but the ones we're interested in are 1s0, 1s1, 1s2 and 1s3. The numbers correspond to the SCSI ID and the partition number.
Interestingly, the 1s0 etc refer to SCSI ID 1 LUN 0 but the LUN is not included in the node, almost as if it is just implied. But it IS included for SCSI ID 1 LUN 1 as 11s0. Old computers are weird. Anyway, the final digit is definitely the partition number.
To make a filesystem, I executed the 'mkfs' command on each partition (substituting in the correct node and block amount):
mkfs /dev/dsk/1s1 xxxxx (where xxxxx is the number of blocks required)
The upshot of all this is that the disk image should now be ready to receive files. To check I'd got this correct, I created directory part1, part2, part3 in the working Torch disk image. Then I mounted each part of the drive with:
mount /dev/dsk/1s3 /mnt/part3
And there were no complaints. This was a good sign as it suggested the filesystem had been mounted correctly. Even better was that I could write files to part1 and part3 and read them back, even after a reboot. I'm fairly sure that part2 is actually some sort of swap space (feel free to correct me in the comments).
With these all now in place, it was time to do what I'd been dreading. I needed to copy all the files over from each of the drives, starting with / and /usr. I had thought that this might be easier on Linux, but having mounted both image files, and after trying to copy the files across, it became very obvious that the modern Linux world does not enjoy trying to read and write ancient disk structures. So I went back to the Torch.
And I should've done that first. It took less than ten minutes to copy the files across for both / and /usr and there were not complaints, no stumbles, no errors. So, the big question. Would the new image actually boot?
 |
| VICTORY! |
 |
| It's SO BIG! |
That's 20Mb for / and 53Mb for /usr (I assume that partition 1 which is 8Mb is actually some sort of swap space).
And now I have the room, does my typed in program actually work now?
No.
I did get a new libw.a file that I had but despite it being so carefully crafted, it was missing its index. Whatever that means. It meant that the compile failed. Again. After all that work I was pretty despondent but then I did another 'ls' on the lib directory. Staring me in the face was a file called 'libW.a'. I began to wonder if this was actually what I needed so I went for broke and renamed it to 'libw.a' - Linux is case sensitive for filenames - and tried compiling again.
Did it work?
Oh, yes. I had rather mixed emotions at this point. On the one hand I'd spent three days trying to get files out of an archive that the Torch apparently doesn't support (even though it's on the freakin' SysV disk) when I could have just renamed an existing file, but on the other hand, I've now got a big one. Disk image that is.
 |
| Ooo, he's a character. |
Next time, time (you'll see).
If you'd like to follow - or even contribute to - this thing, see the github page at:
Disk images are available from bitsavers:
Caretaker may or may not be included somewhere or not in this thread (VCF forum membership required):
