Torch Triple X - Part 11 - The Highs and Lows (and Highs) of Retro Computing

Last time I managed to get the Torch Triple X system to boot an image that did not require the key disk. Yay! The only problem is that, although Unix starts and I can log in to it and run things, there isn't a proper GUI running. It's just a terminal window.

But there was another disk image available on Bitsavers that had been dumped from another machine and I started to wonder if there was any way to get this other one to boot on my Torch.

I hatched a cunning plan. What if I copied the image on to my BlueSCSI but called it HD50.hda which would make it SCSI ID 5 alongside the working boot image? Then, I could mount that in the Torch disk tool and have a closer look at it. And I did. And it worked perfectly. Although there was nothing interesting in the partition information (it looked almost the same as the other image), I decided to try the 'Reinstall Caretaker' option on it. This, in my simple brain, would re-install caretaker as per my version of the ROM and include - if I'm lucky - my keydisk information. Then, assuming it all worked, all I would need to do is get the keydisk working again and it should boot on my machine. 

Well, the reinstall caretaker option didn't generate any errors so I assumed it worked OK. (Note from future me - I'm not sure this step was necessary as I had another go later and as long as the keydisk image was in the Gotek it just worked.)

Next was making sure I was using the right keydisk image on the Gotek. The keydisk is a primitive (and somewhat annoying) method of ensuring that the Torch is using an authorised version of its ROM and system. If the system loses its settings because of a failed battery (for example) then the key disk is required before the system will boot again.

I've captured images of the keydisk for my machine using the most excellent Greaseweazle from Kier Fraser. Several different images in fact, to make sure I don't lose this vital part of the computer and the image that actually works is already firmly ensconced on my Gotek. So, after renaming the hard disk image to HD00.hda I started to boot. 

And, oh. My. Goodness. It booted. But not only did it boot, this image actually has a working GUI which is known as OpenTop. 

It's a GUI. Crikey!

And it booted straight into it with no login required (phew!). Now that was unexpected.

We'll come back to the software because between the last post about the Torch and this one, I've also been busy with a few hardware bits and bobs.

First, the key disk. Clearly I've got the key disk working but one of the problems is that because I'm not using the original power supply which had a battery on it (grrrr!), every time I turn the Torch off the information about the key disk is lost and it needs to reload it again. This isn't that much of an issue, but it could become annoying when I finally work out how to access the floppy drive within the OS as I currently have the Gotek with a USB stick and the key disk is the image that is always currently selected. 

So I decided to fit a battery to make sure that the battery backed up RAM keeps its settings. This requires putting a voltage across the correct lines on the power supply connector that would be there all the time the machine is off. And the easiest way to do this is with three 'AA' batteries that provide 4.5v (ish). This is just enough to keep the BBRAM happy and I just so happened to have a battery holder that would do the job. The only issue with this is that when the Torch is switched on, it will try and charge the batteries which, for non-rechargeable batteries, is a one way ticket to magic smoke (or worse). This is the same issue when any of my Amiga using readers would have replaced an A500+ battery with a button cell. The simple answer is a diode in series which will stop the charging from happening. 

Now, those of you familiar with electronics will know that to push electrons through a diode means that you get a little bit of a voltage drop, typically 0.6v. This puts the output of my batteries at 3.9v. There are two reasons why I'm OK with this. Firstly, it works. Second, when AA batteries are new they tend to put out a little bit more than 1.5v, sometimes as high as 1.7v. Now 1.7 x 4 = 6.8v. Minus the 0.6 for the diode and you get 6.2v which is worryingly high for what I want it to do. So, using only three AAs means a maximum of circa 5.1v which becomes 4.5v after the diode. Obviously, this goes down to around 3.9v if the AAs are spitting out a more realistic 1.5v but, even at that low value, it's enough to drive the few bytes of RAM in the relevant chip when the machine is off. (Anyone who disagrees - let me know in the comments.)

3D printed battery as I only had a four cell
holder!

Another use for solder braid. The 3D printed
battery needs a pass through or no circuit!

The holder has a standard connector (like
a 9v battery) for easy removal. Yay!

With that sorted, I wondered if I could make the changing of hard disk images a bit easier. I had already had a go at designing a custom bracket for the Gotek (and I was very pleased with the results) but I started to think I could add a slot for the SD card used by the BlueSCSI. My first idea was to mount the BlueSCSI above the Gotek but it got really complicated to work out if I could support both in an open box shape but while still allowing enough room to squeeze the Gotek in. 

Hmmm. What else? If only I could extend the SD card slot on the BlueSCSI so it sat above the Gotek but still keep the BlueSCSI mounted where the hard disk had been originally. And, of course, there are plenty of SD card extenders on the market so I acquired a couple to see how they would work. One thing I found immediately is that if you try using one in a laptop, it does not work correctly. This seems to be because the laptop finds something plugged into the slot i.e. the extender bit, but then when putting the SD card in the other end it can't automatically detect anything has happened. 

Fortunately, the BlueSCSI will only have the SD card removed while the machine is off and then reinserted before switch-on. Provided an SD card is there at switch-on, it works fine, even on my Linux laptop.

After a couple of days of adding to the bracket design - which consisted of several test prints of the new section to check the fit, I was ready to try a full print. And I just went for it and did it on the highest quality. About 18 hours later I had a new bracket, ready for the SD card extender. While I was at it I also created a bracket for the BlueSCSI. Once I work out how to do it, I will probably upload these to Thingiverse (for the worlds smallest audience!).

Test prints - small sections made things a lot quicker
to print and try out, especially the SD card fit.

Only 18 hours to go...

I replaced the previous bracket and the new one looks AWESOME! The first font I picked in TinkerCAD (where I did the 3D modelling) was a match for the actual Torch Computers font too. I added a last minute mod by drilling a hole next to the slot and fitted a 2.5mm red LED which connects back to the BlueSCSI so you can see hard disk access too. Yay!

Not the greatest picture but SD card at the top,
Gotek USB stick and OLED screen underneath.

Gotek and SD card bracket to the right, BlueSCSI bracket
to the left. Note the SD card extension cable.

By this point I was ready to get the whole thing buttoned back up, or at least put the top back on and make it look a bit nicer. And this is where things started to go a bit wrong...

First, the power cables are all scrunched up in the back as they come off the motherboard and disk devices and are fed through the slot where the original power cables would have been plugged in. With my arrangement there are many smaller cables to squeeze through, making it difficult to get the centre and top sections of the case on properly.

While poking and prodding something, unbeknown to me, had gone wrong. After booting a couple of times it went into low resolution rather than the normal high resolution. Hmmm. More poking and prodding. And then, disaster.

It refused to boot. On closer examination I could see that LED on the Limpet board was only flashing four times instead of the regular eight. This, I think, means that the RAM test on startup is failing. Removing and re-inserting the board made no difference. This was Not Good (R).

After all of the wins that lead to the triumphal boot into OpenTop, it looked like I had basically broken it. And to say I was 'gutted' doesn't quite do the feeling justice. This thing is super rare and, as far as I know, there aren't really many that are actually working (batteries in power supplies etc). So to think that somehow I snatched defeat from the jaws of victory was beyond galling.

(Actual footage.)

Anyway, I decided to see if there was anything I could do to fix what seemed to be a broken Limpet board. I have to be clear that it's not just a case of removing the Limpet and running on 1Mb of RAM. The Limpet contains a couple of additional PAL chips that replace the original PAL chip that is removed and replaced by one of the Limpet connectors when it gets installed. And I don't have this original PAL chip so if I can't make the Limpet board work then it's game over. 

First, test the bus driver chips. These were fairly standard 74F245s ('F' meaning 'Fast' so the standard 'LS' won't do here). None of the chips on the board are socketed so they all had to be desoldered, sockets installed and then re-inserted. This also meant I had to remove the de-coupling capacitors that had been soldered directly to the power pins on the chips. As I was adding sockets, this meant putting them on the bottom of the board instead of the top but other than that, this was fairly straightforward. 

Socketing in progress..

Some new old stock 74F245s

Capacitors to the back, please..

Sadly, the driver chips were all OK (along with the support logic chips too). 

Then I decided to test all of the DRAM data, address and control lines to check if a trace had broken. But these all proved to be OK.

Next, I checked the actual DRAM chips. I wondered if one had completely failed resulting in any chips beyond it on the bus not being able to be seen. But again, they all came up as working correctly.

Finally, my great punt, I removed the two connectors that extend from the bottom of the board and which fit into two chip sockets (20 pin) on the main motherboard. I really hate this connection method as the pins were no thicker than standard turned pins but were much longer, and I had had issues with one pin on one of them before so I just decided to replace them. To do this, I got a big pack of turned pin, 20-pin IC sockets and stacked them together to the same height as the board required. Then on the underside of the Limpet, I soldered some turned pins I had leftover from a previous project. These fitted into the two sockets perfectly and, although the height was a fraction lower than the original connectors, everything seemed to fit together fine.

And the result was....

...still no boot. After many frustrating hours of fiddling, lifting, gently pressing chips, adjusting pins etc, still no boot. 

Then I got cross. Given that the issue arose while I was prodding stuff, I pressed the Limpet board down, hard (and I mean hard) and switched it on. 

And it booted. As if nothing bad had ever happened. Whhhaaatttt??

I'm still not 100% sure what had happened but I think it's fair to say that there was some 'mechanical' issue that my gentle caring hands were never going to fix. Brute strength and ignorance seems to have saved the day (this method is obviously NOT recommended).

And, not only did it boot, it now boots in the higher resolution and it has done ever since.

So after about four weeks of despair, I found myself back where I started, trying to get the Torch Triple X looking good. Here's the result.

This time, accompanied by Ziggy*

*When Ziggy has batteries, pressing his head results in him shouting 'Tickle!' at an excessive volume, followed by him moving around in circles in a very unnerving way. Ziggy does not currently have batteries.

Next time, we shall explore the OpenTop GUI (spoiler: it won't take long..).