Now I have an even older one - PET 4032

It was my birthday a little while ago. To celebrate, Mrs Crashed arranged for us to go to the National Museum of Computing at Bletchley Park. But not just to visit the awesome museum. The NMOC were actually holding their 'Retro Electro Jumble Sale' and I had to be there. 

The sale itself consisted of a large room with lots of glorious (but unwanted) retro computers in various states of repair on and underneath several tables. I hadn't really gone with the intention to get anything specific but after looking at a couple of Atari ST's (a bit too new) I was drawn to the PETs that had been strategically placed under the tables. Some had a their price tags marked as being reduced from £50 - a bargain in itself - to £30 but then realised the reduction was because the motherboards had been removed.

But then Mrs Crashed found one that had its motherboard and it all looked intact. We lifted it onto a handy trolley nearby and then checked the description and cost for this specific unit. Cost £50, condition - rusty. And it also had a label on saying 'Screen garbled. OK inside.'

 

I frequently feel the same...

This was the one for me. And I also managed to grab a period correct cassette drive too, price £3.

Presenting- Rusty!

After the discounts from our entry tickets I realised I had managed to bag a CBM PET from around 1979 for less than £50. It certainly didn't matter that it wasn't working as that was the point of buying it. A project for my birthday. 😁

And then the work started..

The PET is very easy to work on thanks to the ability to lift the top of the unit up and prop it open, just like a car bonnet. Nice. A quick inspection revealed that the inside while 'OK' was rather dirty (and not nice). I also spotted the infamous 'white' sockets in use on the DRAM, ROMs and the CPU which are well known to be a source of issues with this type of computer.

Open wide...

The power supply is the slightly terrifying arrangement of mahoosive transformer and giant green capacitor on the left. I don't know if there are any magic smoke bomb Rifa capacitors involved here. If so then they are well hidden. I decided to just go for it. First switch on attempt gave a screen full of garbage, as expected:

No surprises (sounds like a great title for a song..)

This is good as it shows that the CRT is OK - white which was a surprise, I was expecting green - and the video generation circuitry is working OK. The brightness control at the back of the CRT also worked as expected.

But then, within a couple of hours, the screen was black when I turned it on. Interesting. I went around the back and tweaked the brightness of the CRT to maximum and saw a single thing line across the centre of the screen. So that meant the vertical deflection had collapsed. Awesome. 

Fortunately, with the schematics available from zimmers.net I managed to track down the fault to a 74LS107 which feeds the 'vert_drive' signal. With a new chip in place, the screen was back to being garbled, but at least it was visible (IC death count : 1).

74LS107 at H8 was dead

One thing I should point out about this unit is that it is a 4032 i.e. a slightly newer model of PET with 32kb of RAM and, obviously, a much better keyboard. The motherboard matches the schematic of the 'dynamic' system board which means it's the second(ish) type of motherboard that Commodore came up with. It doesn't have a speaker so there is no sound at all on this PET, and it doesn't have the CRTC chip which means that this machine is strictly 40 columns only.

Checking out the rear..

Motherboard with ROMs & CPU removed
(and a little bit cleaner)

Anyway, while checking the various clock signals that should be on the board, I found a dodgy looking one from pin 13 of the 74LS164 at H3 on the board, and touching it with the scope probe filled the screen with the character 'h'. I had some 74LS164s so I replaced it and that restored the expected clock signal (IC death count : 2).

And then I realised that the CPU was not outputting anything from its own clock signals. The 6502 CPU has two clocks phi1 and phi2. After ordering a couple of replacements (you can never have too many chips) I started to wish that I didn't have to wait but I didn't have any machines with a 6502. Having been a speccy guy in the 80's, most things I had were Z80 based. But then I remembered I had been given an Acorn Electron a year or so ago. And sure enough, the 6502 in the Electron was socketed. Replacing the 6502 restored phi1 and phi2 to the expected signals (IC death count : 3).

Correct clock signal from the borrowed 6502. Yay!

This was all before I even posted on the VCF forums about the issues I had which should give an idea of the body count (of dead ICs) at the end of this project.

Anyway, by this point I now had the screen displaying this:

Still garbled but different..

Changing the CPU had changed the garbage on screen and the result was a little bit more like what would be expected at a normal PET cold start. What would normally happen is that there would be a blast of garbage on the screen followed by the screen clearing and being replaced with a basic prompt. This is obviously not happening yet.

I also managed to check the DRAM by the simple method of taking a ZX Spectrum, which uses the same DRAM for the lower RAM, and desoldering all its lower RAM, soldering in sockets and swapping the PET RAM into it, one bank at a time. It seemed a good idea when I started but at least the speccy now has sockets for the lower RAM.. No faulty chips were found but, unfortunately, I had an incident where I replaced one of the DRAM chips in the PET the wrong way around. This was 'Not Good' (R) and caused an immediate burny electronic smell. It also killed the chip. (IC death count : 4) Fortunately, I had another DRAM that was a larger memory size but could be modified to fit - which I did.

But still no change. The next thing to try was the video RAM. The guys on the VCF forums had indicated that the video RAM was an almost certain failure. The two MOS 2114 SRAMs are notorious for failing (as a lot of MOS chips are) so two more modern replacements were ordered. Then I ordered another pair, but a different manufacturer, just to be sure and have some spares. 

At this point I was introduced to the idea of using the PET Tester ROM by the most awesome Daver2 over at the VCF forums. This is a small program that sits on a 2716 EPROM and so it can be swapped with the edit ROM (which is also only 2kb). It runs a very simple program at start-up, first to test the low page memory before moving on to more advanced tests including video RAM and DRAM tests. I actually had to order a 2716 as the only one I had was as dead as a doornail and no amount of UV exposure in the phone sanitiser would cure it. (Not counted in the death total as it was already dead.)

When the new EPROM arrived, I copied the PET Test ROM to it and swapped out the edit ROM. I was disappointed to see no real change. After a few hours of poking I found a 74LS244 at position C3 with an address line stuck high. This meant that no code could properly run from the test ROM and so it needed replacement. Fortunately, this was one of the chips that I have plenty of so it was no big deal to replace, other than the slight hassle of de-soldering it from the board and installing a socket (IC death count : 5).

Still no joy, and the screen just kept displaying the same pattern of garbage on screen. But then one pair of the video RAM chips arrived and so I replaced the 2114s. 

2114s - they were not socketed originally

This was a partial success (IC death count : 7). The PET Test now started with its initial check - YAY! - but instead of progressing, it sat with only the first character on screen changing rapidly, as if it was cycling through a massive list of values - BOO!. This was not right and I wondered if this was still an issue with the video RAM since the test it got stuck on was the video RAM test. Basically, it writes certain values to the video RAM and then reads them back. If they all match then the test ROM moves to the next test. But as the chips were new it seemed odd that this would be the case.

First signs of life but stuck here...

While I was probing around I accidentally slipped and shorted a couple of data pins together and suddenly saw that the test ROM had moved on to the next tests. It ended up on the DRAM tests although there was an issue with the text. According to Dave I'd basically crashed the initial test and by some miracle the code in the ROM continued. It did allow me to quickly check the keyboard - a series of numbers are displayed by the test ROM which change when keys are pressed. From this I could see that only the 'W' was a bit iffy and this also meant that the 6520 controlling the keyboard was OK (foreshadowing...).

Tests working but only because I crashed the first test....

I've got how many 'k' of RAM?
Looks like I broke it...

It also allowed me to check that the ROMs were 'OK' via their checksums. I downloaded the equivalent ROMs and put the binary file into a hex editor and calculated the checksum of those and they all matched. Nice. Of course, it's not really easy to check the Edit ROM but I did put it in one of the two spare ROM slots and the reported checksum initially matched but it was not to last - but I'm getting ahead of myself.

So, if the first test isn't getting through, this suggested a problem with the video RAM (still). With no video RAM the PET should display a fine checkerboard pattern. Well, mine did but it wasn't exactly stable..

That's not really a checkerboard, is it?

I put a switch on IC F1 (74LS108) between pins 6 and 7 (the TV_SEL) line. This effectively isolated the bus from the display meaning that the we could (in theory) track down where the noise was coming from in the display. With the switch open there was what looked like a random pattern of characters spiralling up the screen but with it closed the display was rock solid. Then followed a few days of measuring lots of signals, with the switch on and with the switch off, find another signal, measure with switch on and with switch off etc. 

This is what it should look like with no video RAM!

During all this I replaced one of the 74LS157s which I think was the one at F3. Either way, the display suddenly became much more like the expected fine checkerboard pattern but it still wasn't stable. (IC death count : 8)

Better, but not quite there..

At some point I also replaced the 74LS373 at G3. (IC death count : 9).

And then, for no apparent reason, the display became rock solid with or without the switch closed. As Dave put it, there's a metal mouse loose somewhere... The only thing I can think is that in my handling and additional cleaning of different parts of the board had I removed something I wasn't aware of causing a possible short? Either that or the Retro Computing Gods decided to give me a break?

Whatever. The display was now working. I replaced the VRAM and turned it back on and, sure enough, the PET Test ROM ran exactly as expected. 

I decided to go for broke and put the Edit ROM back in and promptly found out that it had failed completely. (IC death count : 10). 

Hmm. That's still not quite right is it.. Dead ROM

So I reprogrammed the PET Test ROM to be the Edit ROM and reinstalled it. All I got was a black screen. Hmmm. I removed the 6522 but no change. So I removed the 6520 from C6 and I saw this...:

..And nearly fell of my chair. 

But all is not right. Where's the cursor? The 6520 at C7 should give the cursor but it's missing.

I thought that the sockets for the gaggle of 40 pin chips - including the 6520s - might be causing problems and confusing things, since tapping the top of the 6522 caused some garbage on the screen. Fortunately, I had quite a few dual wipe 40 pin sockets in the box o' bits' so that was no problem.

White sockets looking a bit bendy

White sockets begone!

And that did absolutely nothing except stop the garbage on screen when I tapped the 6522. From that I have to assume that one or more of those three chips is faulty. The chips in question are the two 6520 PIAs which control various input/output stuff such as the IEEE488 interface and the keyboard, and the 6522 VIA which controls various other input/output stuff including timers and IRQ things.

I decided to go all out again and just order replacements for all three. If I'd ordered just one 6520 (say) and then found out it was the 6522 I'd have had to order and wait again, so it made sense. They aren't that expensive and the 6520s have a modern equivalent of 6821. I actually ended up with a ceramic 6522, one 6520 and one 6821.

But while I was waiting I wondered if I could use a different EPROM in place of the Edit ROM as I only had one 2716 ROM and I didn't want to have to keep reprogramming it between PET Test and the Edit ROM. The thing is that the actual ROM is pin compatible with the 2716 but I only have 27c128 or 27c256 EPROMs to play with. The 2716 is 2kb while the 27c128 is 16kb and the 27c256 is 32kb. But that's not the biggest problem. The 27c128/256 have more pins than the 2716 and I can't just cut them off.

Typical 2716 EPROM
(This one is OKI and is also dead)

So I built an adaptor board instead. 😊

First attempt!

The adaptor basically swaps a couple of pins that are different between the 2716 and 27c128/256 and either puts the extra connections to ground or ties them to 5v depending on what they are.

I have to tell you now that the first version did not work. At all.

Fortunately, Dave on the VCF forums came to the rescue and told me that I'd connected pin 21 of the ROM socket, which is a permanent 5v, to pin 22 of the 27c256 which is /OE or 'Output Enable'. Since /OE is 'active low' me tying it to 5v very effectively disabled the chip since /OE would never go low. Doh!

A quick re-wire later, where I also found another non-working connection, and I was ready to try again. And this time, it worked! More or less..

Interestingly, the keyboard came up as all 'ff' instead of '00' with the 27c256. I'd copied the PET Test ROM across the chip 16 times to ensure that it was consistent, the original PET Test only being 2kb. I'm not sure whether there may still be a slightly 'off' connection somewhere that might cause this. It also seems to cause a weird issue when the RAM test runs through. But don't let that distract us, not just yet.

Because the postman had been! Yay! In the bags were the 6522 from Devon, and a 6520 and 6821 all the way from Germany (bizarrely cheaper and quicker than ordering from the UK). 

First up, put the 6520 into location C7. And we got...

...a working PET! With a flashing cursor and everything! There was still a slight glitch on the video but Dave confirmed that the 6522 handled a signal that, if not present, would cause that. So I inserted the ceramic 6522 and tried again. Same result but without the glitch. Nice! And finally, I added the 6821 into location C6 and tried again. Same result again. This is starting to look like a working PET! It also means that both original 6520s and the 6522 are dead. (IC death count : 13).

Some little BASIC bits and bobs:

HELLORLD! as made famous by Usagi Electric

Can't have a Commodore running without the random 
maze Basic program. :)

But is it really working 100%?

Not quite. If I want to add one of the modern SD card adaptors then I need the IEEE488 port to be working. There is a BASIC program that can be entered which works by poking values into certain locations, and then peeking at the values of nearby locations. The values in these second locations would show if the IEEE488 parts were working. And this was the result:

Darnit. Bits 0 to 3 and bit 7 are faulty.

That's annoying. There are three MC3446 chips that control all the IEEE488 comms and this shows that at least two are faulty. A very nice man on the VCF forums suggested a supplier for the chips that seemed to be a good bit cheaper than eBay so I gave them a go. And after a couple of days, two MC3446s popped through the door in a jiffy bag.

By this time I'd already put the three 3446 chips into sockets so it was a piece of cake to swap the old ones out and put the new ones in. (IC death count : 15) Looking at the schematic I worked out which pair were impacted and which one was still working and swapped them over. And the result was:

Yay! No more bit errors!
(or other errors!)

But what about the cassette deck, I hear you cry? Well, that just needed a new belt, only because the old one was stretched, and thankfully had not turned to goo.

Belt up young man!

I also cleaned the read and write heads along with the capstone and pinch-roller. And it just worked, 100%. I managed to type in the IEEE program and then save it back to a cassette tape multiple times. Very simple and easy. Nice!

One last thing to do (well two actually). Clean the hideous keyboard and clean the case. I won't actually do much more to the case than that to be fair. The rust is part of the computer's history and it's not actually that bad, certainly most rust spots appear to be surface only.

But the keyboard. Oh, my, goodness. The keyboard. It's easy enough to remove, just a bunch of screws and a connector for the cable. And it's a good job because it was filthy. Absolutely hideous.

Keyboard connector on the motherboard

Connector at the keyboard end

Filthy keyboard (oversized belly for scale)

Fully dismantled and ready for a bloom' good wash

Cleaning keyboards is not a fun task. It's easy to forget how many keys are on a keyboard, even one from 1979(ish) before the general layout we know today had become established. But it must be done!

Commence rebuild!

Rebuild complete - what a difference a couple of hours
of extreme cleaning, careful drying and reassembly makes

When I managed to test the keyboard previously the only key that seemed to give any grief was the 'W' key. So I paid special attention to the circuit board and plunger at this location. Once it was re-installed in the PET the 'W' worked perfectly. Nice.

Stand by for action!

I still need to clean the case properly but I won't be doing anything with the rust as such. It's part of the history of the machine and it adds a certain 'rustic' charm (try the fish, I'm here til Thursday!).

There you go. A Commodore PET for under £50 (plus about £25 quid in new parts). There were a total of 15 chips that had died in the PET, although I think that the 6520 in C7 was working originally but died at some point during the investigation and testing. Here's a picture of most of the dead ICs:

We salute our fallen heros.

If you want to see more of the technical help given to me by the VCF guys take a look at the thread here.

 

Torch Triple X - Part X (that's 10 in roman numerals you know.)

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.

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.