The old hardware of the Torch Triple X is proving to be a little bit bothersome (it's a right old pain the rear) and I've made little progress in fixing the motherboard issues. I won't give up but it's taking longer than I ever thought it would.
It was making feel a bit despondent to be honest, but then, on the VCF forums, a most excellent chap disclosed that he'd written an emulator for the Torch, based on the Motorola 68000 emulator called Musashi. What. The. Heck.
 |
| The first screenshot! |
Holy [CENSORED]! Obviously I started to ask some questions. This first version apparently had some memory issues with the MMU, but what a start!
Eventually these issues were resolved and the next screenshot provided was just stunning.
 |
| **Speechless** |
This was running the regular hard disk image from bitsavers (on which my own physical Torch adventures are based!) and shows everything I would expect on the screen. Just. Wow. But then....
 |
| Networking. Oh. My. Goodness. |
Needless to say, this was awesome work. But, you should know me by now. I wanted more. Fortunately, the working code was uploaded to the forums and the original author basically said 'knock yourself out' when I asked if I could start fiddling with it.
From this point on, I should point out that I am not proficient in 'C'. I know a reasonable amount of Python and I'm familiar with general programming principals (I am a child of the 8-bit era after all) but the C syntax is a bit odd to my Pythonic eyes, but not horrendously so. The main point I want to get across is that you are not going to see a 'tour de force' of programming skills and some things I do may make experienced guys out there cringe. I just want to make it work.
First things first, the colours. I found the bit in the code that set the palette. It should be set from hardware (I think) but the code has fallback if the palette isn't set up. Since the initial version of the emulator was clearly using the fallback colours, it was a simple case of identifying the correct values for a more pleasing set of colours to replace the current pale blue/white palette.
 |
| Colours. So many colours. Well, four anyway.. |
 |
| Normal(ish) colours for OpenTop |
That made things look a bit more like home. :)
 |
| Nice. |
It's worth noting that I spent quite a bit of time trying to make the emulator just use the colours that the system does without using the fallback colours. This proved to be far more difficult that I imagined. No matter what I tried, the palette will not use the 'real' Torch colours. I suspect that there is some hardware trickery going on on the real motherboard to make the colour updates as the Caretaker boots up. It's not a big thing since the colours I've put into the fallback do look quite reasonable but it is mildly annoying.
Next thing, the aspect ratio. The display was squashed vertically and needed to be increased. Fortunately, this was a relatively simple tweak to the SDL window settings and then we were pixel perfect.
 |
| Running fullscreen on my laptop. Oh, yeah. |
Next, the keydisk. This disk has a very annoying format that changes at the end and adds an extra track to extend the available space. This space stores the unit serial number and acts as the 'key' to unlocking the system. With the emulator set up as it was originally, the keydisk had to be present for every boot. This is not a major issue but it bugged me that it didn't try and store it somewhere so that if the keydisk wasn't specified in the startup parameters then it still startup correctly. Also, for the emulator, the keydisk image needs to be in .IMD format to ensure that the right part could be accessed for the serial number. But .IMD images can't be mounted on Torch Unix - something similar happens at startup in the 'real' hardware. The Gotek can read the .IMD image and boot the machine but then it cannot mount it in Unix once booted.
Looking at the code I could see that when the emulator reads the keydisk it takes the relevant piece of the special last track and copies it into the memory location of the real time clock. On the real Torch the RTC chip has a tiny amount of volatile RAM which is used to store this key number. By putting it there early on in the emulator startup, the WERMA startup programme (vaguely similar to a BIOS) doesn't complain when it compares the memory contents against the key disk. If it wasn't there then the message 'New battery fitted' would appear at every boot which would be a little bit annoying.
Anyway, rather than have the keydisk attached every time, I decided that when the Torch starts it will check for the keydisk number in a tiny binary file. If the number isn't there then it would carry on and do the 'copy and check' from the keydisk but would also create the tiny binary file 'torch_serial.bin'. Simple and effective. This also means that, in theory, the key disk image would not be required any more as the 'torch_serial.bin' file could be provided with the emulator. But that would be cheating. :)
 |
| I made this! |
And it all works rather well.
 |
| Terminal output - found the keydisk and saved the serial number |
After I'd done this I realised that, really, all I'd done was move the reading of the keydisk to a simple binary file but it feels easier not having to basically have the keydisk image there every time. And if you really blur your eyes you can pretend that the 'torch_serial.bin' is actually stored in the RTC RAM. (You still need the keydisk to make networking work - but I'm getting ahead of myself.)
 |
| No need for the key disk on this boot. :) |
Next up, I wanted to mount a regular floppy image in the emulator. This was partly the reason why I didn't want to have to include the key disk every time at startup, but in the end it turned out not to really make any difference.
Anyway, the Torch uses either the OMTI SCSI board to support both hard disks and floppy drives or a special 'MANTA' board to handle only floppy disks. For the purposes of the emulator, and trying to mount a Unix floppy specifically, we stuck with the OMTI configuration. This meant that the code for the floppy was basically a variation of the existing code to handle the actual SCSI hard disk. As such, it was reasonably straightforward to add another option (--unix-floppy) to point the emulator at a Unix floppy disk image.
For the actual floppy images I initially struggled. But eventually I found that it was actually quite straightforward to create a blank floppy disk image like this..
In Linux, create a blank file of the correct size by running :
dd if=/dev/zero of=floppyblank.img bs=1024 count=720
Then copy the image into the directory/folder with the Torch emulator. Include it in the startup parameters with:
--unix-floppy floppyblank.img
Then, when the emulator has started, open the Torch terminal and su to be root. Then run the following:
format /dev/fdsk/0
This is specific to the hard disk image I have so your mileage may vary if you use a different disk image. If so, just have a look in /dev/ and see what floppy disk devices might be there. Interestingly I struggled to use the /dev/floppy device which is also present, with Unix complaining "Can't determine controller type". But the /dev/fdsk/0 device returned no error on the format command.
Then, just make a filesystem on the newly formatted block device with:
mkfs /dev/fdsk/0 1440
Finally, mount the image so it can be seen by the system and written to:
mount /dev/fdsk/0 /mnt/flop
Obviously, my disk image has a directory called 'flop' in 'mnt'. Yours might be different.
The key concept here is that the filename for the disk image persists through the emulator session i.e. the image could be mounted in Torch Unix as described above, files written to it, unmounted in Torch Unix and then replaced with a different disk image PROVIDING it has the same filename. (It sounded a lot simpler in my head when I started writing that..)
To ensure correct operation of the floppy image, it's necessary to run 'sync' in 'tsh' and then 'umount /mnt/flop' which cleanly disconnects the disk image from the system and allows the copying of it to different locations.
I did spend quite a lot of time trying to sort out why I couldn't have more than one floppy drive. The disk image I'm using has two nodes for SCSI floppy drives, /dev/fdsk/0 and /dev/fdsk/1. On the real hardware, the '0' was equivalent to the floppy image on the BlueSCSI and the '1' was the Gotek. But with the original code, whichever image I mounted appeared in both. It turned out that the original code was only considering the LUN for each SCSI ID. It was a simple(!) matter of looking at the whole byte of information relating to the SCSI ID. So we ended up with the following mapping:
SCSI ID 0 - LUN 0 -> Hard disk
SCSI ID 0 - LUN 2 -> Floppy drive (unix) equivalent to BlueSCSI floppy image
SCSI ID 1 - LUN 2 -> Floppy drive (unix/keydisk) equivalent to Gotek floppy image
So mounting /dev/fdsk/0 now always mounts the image specified in --unix-floppy while mounting /dev/fdsk/1 mounts the image specified in --keydisk. For ease, I'll probably stick to just using the /dev/fdsk/0 node unless I need to copy files from one floppy to another.
That's 'proper' floppy disks sorted. Next thing. The terminal.
The terminal program on Torch Unix is 'sh'. Not 'bash' or 'csh' or anything modern like that. No siree. This is 1980s style computing i.e. a bit hard and slightly inconvenient. And the 'sh' terminal is just that. I realise it does come from c.1984 but having been using bash for the last twenty years or so, taking a step backwards is a step too far. If that makes sense...
Anyway, a couple of things that are missing from 'sh' are very annoying. These are command history on the cursor keys and auto filename completion on tab. I'll be upfront, I did not manage to get the tab key working (yet). But read on for the command history.
Rather than try re-write and compile a stripped down 'bash' (or similar) I decided to try and do something else, which would be a bit simpler. I would write a wrapper that would pass commands to 'sh' but which would store previously entered text i.e. commands and paste that history into the command line when the up/down arrow keys are pressed.
The code itself runs and calls 'sh'. It's only 229 lines long and, I have to be honest, I wrote it so long ago (with copious amounts of duck-duck-go searching, stack-exchange browsing and swearing at errors) that I don't remember how I worked out what the heck to do. Documentation appears to be a mythical thing to past me. Perhaps I would make a great agile developer after all..
When I compiled it I renamed it be called 'tsh' (Torch sh - see what I did there?). I added an icon to the desktop - a feat in itself with the OpenTop system - and I run that instead of the regular terminal icon. I haven't figured out how to swap the icon from the default 'tool' icon yet, but I will. 😁 And I can definitely tell you what this code does.
In a nutshell, it adds a command history on the 'sh' terminal. It also allows for switching to root using the new command 'tsu' which redirects the 'su' command through 'tsh'. (You can use 'su' in the 'tsh' terminal if you really want to but it runs the command normally and the ability to press the up arrow for the last command is lost as the 'tsu' version runs through 'tsh'.) And it is surprising how just making that addition suddenly makes the Torch terminal infinitely more pleasant to use.
 |
| The OpenDesk desktop with tsh running. |
There are still limitations to it though. There are only 10 stored lines so if you want to go beyond that then you're out of luck. When a history line is displayed it can't be modified other than by deleting a portion of it from the end i.e. if the command was 'mv verylongfilename1.txt short1.txt' you can't use the left and right arrow keys to move through the text to change the first filename, you'd need to delete the second filename and keep deleting until you reached the character you wanted to change. This isn't really a major issue, and I as keep gushing about, just having the last command available by pressing the up arrow is a massive improvement.
Next thing, the bootup sequence. This is sort of related to the colour palette thing. What should happen when the system boots is that the screen is solid cyan for a few seconds during a memory check. Then it switches to dark blue with cyan text and the caretaker version is shown. Finally, the palette switches to the four regular colours of OpenTop. (There are normally another couple of colour switches during bootup but we'll ignore those for now.)
Before I got my hands on it, the emulator ran so quickly that all of these steps are effectively missed. Occasionally, the Torch logo might appear for a split second. This wouldn't be an issue but there are a couple of key things that happen during the boot. A 'Stop' icon appears. This is broadly similar to pressing 'F10' or 'Del' when a PC boots to interrupt it and allow some action to be taken, typically entering the BIOS settings. On the Torch, clicking the 'Stop' icon gives access to three main options:
 |
| Some interesting icon designs there.. |
- O/S allows the user to specify which kernel to boot, usually 'unix'
- Key allows the user to open the key disk and access more utilities
- Go allows the use to continue the boot process
Clicking on 'KEY' gives these even more interesting icons:
 |
| Icons. Icons. Icons. |
The most important utility here is the 'Disk Toolkit'. It allows for the partitioning of hard disks as well as given more information on the installed drives (or drive images in this case). It works as-is which is something of a miracle in itself. The only thing is that moving the mouse causes all sorts of random garbage to appear in the utility's command line. No mouse here so the SDL support does cause a minor foible. Don't touch that mouse!
 |
| Disc utility startup screen |
 |
Partition information (note garbage at the option cursor from the mouse!) |
To keep booting, it's just a case of pressing the floppy disk 'boot' icon.
One last thing. What time is it? 😁Given that the emulator runs on a host of some description, it made sense to try and set the clock based on the what time the host says it is. There is one major problem with this. Although the time and date aren't an issue, the Torch OS is not Win2K compliant. As a result, it does not know any year past 1999. As a compromise, we take the time then the date (including year) and simply subtract 28 years so that the days are correct. For this emulator, this is OK.
And it works. Sort of...
 |
| Code snippet for clock sync from host OS |
Firstly, the timekeeping is a bit erratic to say the least. I haven't got the clicks quite tuned in correctly just yet so the clock runs fast from the second the emulator boots.
Second, on Windows the time is correct, but on Linux, for some reason, the time is always one hour ahead.
 |
| Time, time, time. It's actually 11:32pm. 😆 |
That'll do for now. (Is that not enough? Are you not entertained?)
Next time, if I can work out what the heck I'm doing, I set up a github page for this and try use git to maintain the code. It may not go well....
No comments:
Post a Comment