I..Can..Almost..Touch..It.. - Torch Triple X - Part 9

And then I grabbed it firmly with both hands...

Ever since Part 8 of this series, I've been trying to get the Torch to accept the keydisk that would, in theory, lead to the system booting from the hard disk or BlueSCSI with a hard disk image. And it has steadfastly refused to do so.

What happens is that the system starts as expected:

Pale blue screen (red LED on the limpet board flashes as the RAM is checked too).

Pale blue.

A happy 'whooop' followed by a dark blue screen with the Caretaker version shown at the top

Someone to take care of me..

The hard disk starts loading and then...

"Gimme the key disk."

A demand to insert the keydisk, despite the keydisk already being in the drive. The drive stays silent and nothing happens. Initially, I had thought that some input from the keyboard would be required but no combination of key presses or button bashing would stir the drive into life. And this is where I've been stuck for over eight months.

My suspicion was that the OMTI board has a fault somewhere. I have tested every chip that I can, replaced those that I have stock of and checked the board for shorts or broken traces. So the only option I had left was to find another board. But these boards are the very definition of 'unobtanium'. 

** Sad face **

BUT..

Thanks to the most awesome Adrian at Binary Dinosaurs, I now have another OMTI 5200 disk controller board (on loan).

A brace of OMTIs Faulty on the right, working on the left. :)

First thing to try was to see if the OMTI would start when set as SCSI ID 0. My board would immediately come up with an error trap as soon as the memory test was done. And... success! Nothing happened except it said it couldn't find the drive - which is actually different to anything seen before. A good sign I think.

Oooh! Working as SCSI ID 0! Looks positive!

Next, it was time to try an actual floppy drive and, for the first attempt, I decided to use the drive that came with the Torch originally, which is the one I replaced the heads on. After re-wiring everything for power and data I put the super important and irreplaceable keydisk into the drive. Sadly, it didn't boot but most importantly, when the system reached the point of asking for the disk it actually tried to access the floppy drive. And then it reported 'Invalid key disc 7'. Woah! Progress. Sort of.

What's that you say? Invalid keydisk? You mean you actually looked for it?!

Then it was time to try the floppy drive from the Cifer. This is still a standard 5 1/4 inch floppy drive but with a simpler mechanism. I changed the ID of the drive to '2' (I'd already established any floppy drive needs to be ID 2) and plugged it it. And I got exactly the same as for the Epson floppy drive with the error 'Invalid key disc 7'.

GAH!

I had had an idea that I should be able to use a Gotek to handle the keydisk so I reached for the unit that had been in the Cifer and copied the floppy disk image files on to its USB memory stick. Another re-wiring session and I was ready to go. The advantage of the Gotek is that I have a small OLED display on the front and so I can see the track that is being accessed changing as the system accesses different parts of the disk. But there is a problem. The Gotek has jumpers to select unit ID 0 or 1 but not ID 2. Hmmm.

A bit of digging lead me to a website with a helpful diagram of the pinout of the Shuggart disk standard.

Floppy connections - I'm only into the bit at the top (Image from richardloxley.com)

This showed that pin 14 on the floppy connector, when grounded, would trigger unit ID 2 (or Drive C on the diagram). So I soldered a wire to pin 14 and, as luck would have it, there was a small pin connector on the other end which I connected to the ground pin of the 'Motor On' jumper. 

Wire soldered to pin 14 then connected to the ground side of the MO pin. Hey Presto! ID2!

This mod worked perfectly, and when the system started and got to the point of the keydisk check, I could see the different tracks being accessed. Sadly, I got an error box again. This time it said 'Invalid key disc 9'. Darnit. 

So, back to basics. I wondered if the key disk wasn't being recognised because I actually had the wrong disk image on the BlueSCSI. So, I tried two things. First, I created a blank image of about 50Mb and tried that, the idea being that the serial number wouldn't be on a blank image so maybe I would get to the point where it demanded an OS i.e. the floppies for Unix. But no, with the Cifer floppy drive re-installed, I still got 'Key disc error 7'.

Second, I tried re-dumping the hard disk using the excellent 'initiator mode' on the BlueSCSI. This requires two jumpers to be set on the board and the bluescsi.ini file to include 'Initiatiormode=1'. With fresh new disk image in hand, I tried again but, again, got the same error, 'Key disc error 7'. 

Then I wondered if the key disk was starting to have issues so I tried capturing it again using the (also awesome) Greaseweazle. I was surprised to see that the whole disk appeared red. Not just a couple of bad tracks, the whole disk was red as if there was nothing on it. And the I saw it... The arm that loads the heads has stopped working properly and was very effectively holding the top head away from the disk. Without the pressure from the top head, the bottom head was making no contact either, hence the apparent failure to read it. I tried again, this time I physically held the bar down while it read the disk. And it read perfectly!

Now I began to wonder what would happen if I turned the Torch on while holding the faulty arm in the floppy drive away from the head. So I tried it, and guess what...

It only went and bloody well booted!!

YYYAAAAASSSS!!!!!

I may have said several choice words at this point. The picture is genuinely the first time that this machine has booted in the 21st century. But I can't stand there holding faulty floppy drive mechanisms every time I want to boot. I must get the Gotek working properly. 

Now, I won't bore you with my efforts to try and get the system to boot with a Gotek for the key disk. Suffice it to say that I tried converting the newly captured .scp file to multiple disk image formats. And guess what... none of them worked. I tried them all and I even managed to get a custom definition into the Greaseweazle config specifically for the Torch but, no dice.

The only one that I hadn't tried was the default 'HFE' format that the HXC floppy emulator will happily export and import. So my final attempt, using the last (anywhere near relevant) file format was using the key disk in HFE format.

And that bloomin' well worked immediately! Aaarrrghhh!!!

But this is great news as it means that I don't have to have the bulky floppy drive in use when I first turn the Torch on, I can just use the Gotek. Nice!

Gotek display

So. Now what?

Well, the keydisk has been put back into storage and locked away. There are multiple copies of the keydisk image across a few of my devices so I should not lose it now, no matter what. If I feel inclined soon I might just try and create a new floppy from the HFE image. Maybe.

And why don't we see what the Torch does when it's finished booting up? 

Oh.

Not much.

No icons on screen. The kernel window has some useful information but once it's closed there's nothing else there. Right clicking doesn't do anything (this was 1985 for goodness sake - no context menus here..) and there's no menu at the top. Very odd.

So, I suspect that this machine is either not booting correctly, or is actually doing something in the background like a good 1980's workstation. If it's not finishing booting correctly it could be because it's not a fan of the BlueSCSI but I doubt that as it has worked flawlessly so far. Hmmm.

I have another Torch disk image that I genuinely cannot remember where it came from. It has the word 'portable' in the filename which will become important later. So, I copied it over to the BlueSCSI and tried again. Almost straight away I got a 'Icon file corrupted' error. I clicked the little box and it disappeared but the immediately re-appeared and I clicked it again. This wasn't looking good. But then, just like before, it just booted!

This time, underneath the Kernel window, a terminal had opened up and was waiting for a login. So I chose the most logical name for a Unix user - 'root'. And it let me in with no password! Awesome!

It's a Unix system! I know this!

There's still a lot of stuff to do. Here's my list:

• It sometimes boots in low res with a dark grey screen and sometimes in hi-res with a white screen - possible memory issue?
• The main image I dumped boots but no icons appear and there's no apparent way to do anything - may need to reinstall Unix. Eek.
• I tried re-formatting the drive image using the disk utility on the keydisk and re-installing but the formatted image does not work as expected - possible BlueSCSI foibles? Or dodgy disk handling program?
• Tried reinstalling Unix 'over the top' of the existing image and the initial boot disk image runs but then data gets copied to it and it runs out of space before it can continue - why would it do that?
• Even the portable image that ends up at terminal window still has no icons. Why is that?

In the meantime I solved the 'icon file corrupted error' on the 'portable' image but I did this by 'reinstalling Caretaker' from the key disk. This clears the error but has the side effect of tying the image to the keydisk which then makes it not so portable...(sorry Nigel.)

I also managed to work out the fault on my original OMTI board. By means of a simple chip swap session, the second chip I tried turned out to be faulty. It's the 20506-2 which is the memory buffer/controller for the board. There may or may not be a replacement chip on the way from a far away land.. 

What a last few days! Special thanks to Adrian (binarydinosaurs.co.uk) for all his help and especially for trusting me with his working OMTI 5200 controller. I could not have done this without his help. Check out his website!

More Torch shenanigans next time.