I'm Blue, da ba dee dabba da-ee - Torch Triple X - Part 6

Time for a bit of a break from the Torch's motherboard. 

During my escapades with this computer I ended up plugging in the hard disk and floppy disk 'layer' as well as the motherboard just to check if it needed to have connection to a drive to boot (who knows with stuff this old!). Sadly, it didn't make a difference but it did show me that the hard disk actually started up and did not sound like a howling banshee. I'm looking at you, Cifer.

The main drive is a similar style to the Cifer drive and uses a stepper motor rather than coils to control the heads, as was the standard at the time. It spins up and makes some happy chirping noises. This is all a great sign but without the main computer up and running what can I do?

Hard disk, rear and centre. 
(Pic from last year before power supply shenanigans)

*BlueSCSI2 has entered the chat* (as the kids might say)

The latest iteration of the amazing BlueSCSI project now has a fantastic function called 'initiator mode'. Now, I have not been a huge follower of this project but this new feature caught my eye as it said that it could read disks even without the host computer being available. Interesting...

And by coincidence, RMC happened to mention the BlueSCSI board and how to get them from the chaps at Flamelily IT. So an order went in and a couple of days later a parcel dropped through the door.

I went for the kit version that included a configured Pi Pico which is about £14 cheaper than a fully built unit. You could order a kit without a Pico too and save another £8. Anyway, building the unit was really straightforward and basically consisted of soldering on the right angle 50 pin SCSI connector, the power connector (like a floppy drive connector) and some pin headers. It genuinely took me less than half an hour to solder everything in. If I had any complaints it was that there is literally no documentation provided with the kit but given the limited soldering needed to build it I suppose that's not a major problem.

BlueSCSI raring to go..

Documentation to use the thing is available from the BlueSCSI github and it's also linked to from the Flamelily website.

First things first, to read a disk image I need an SD card (full size). Fortunately I have an 8Gb microSD and a gazillion adaptors to convert it to full size. This card needs to have a small file on it to tell the board to go into 'initiator' mode. 

Next task. Get the jumpers in the right place. The unit in the Torch uses a standard SCSI 50 pin connector so it was as simple as plug it in to the BlueSCSI, insert the SD card, swap a couple of jumpers, apply power to the drive and the BlueSCSI and... 

...nothing.

Ooops. In my haste I had missed one of the headers on the board that had to be set for 'initiator' mode. Install the header and stick a jumper on.

Target the initiator! Or something...

Initiate! Initiate!

Take 2.

The drive spun up and the Pico light began to flash, slowly at first but then it started to flash quickly and I could hear the drive heads moving. Nice! After a few minutes the flashing on the Pico went back to being slow and there was no more activity from the drive so I powered it all down.

Now, to see if there was anything viable on the card. First I looked at the log file and I could see that the drive responded to a query from the board on ID 7. Then a long list of data copying, sector by sector. Then, to my surprise, the drive also reported it had data on ID 0 and so the BlueSCSI copied that data too. I suspected that they were actually the same and it does seem to be a bit of a bug as per Adrian's Digital Basement video (released as I wrote this - spooky).

The upshot of this is that there are two .hda files on the SD card, each just over 40mb. This is great news as it means that we now have something we could possibly archive from the drive. To verify this I went and loaded one of the images into a hex editor and, sure enough, data is clearly visible.

But then I hit a snag. I decided to try and look at the files by mounting it in Linux. It did not work. It still does not work after several days of trying. I can only assume that there is something odd about the filesystem that modern systems don't like, even though the captured file is correctly identified as a 46Mb image with filesystem FAT16. Never mind. I do at least have the .hda files that should, in theory, be useable on a BlueSCSI in HDD mode once I get this thing up and running..

But wait, I have another full size SCSI drive. Perhaps I could get an image from this one too. Let's plug it in and see shall we?

Oh dear. Of course I knew it was dead before I took the lid off otherwise I would have just killed the drive myself. But it was gone. I dismantled it to see if I could find the damaged platter. The photo is just one of several that were damaged and is the only one I could get an anywhere OK photo of. For some reason trying to take pictures of highly polished surfaces is surprisingly hard!

Ring of death.

And now, back to the motherboard... (next time).

Blue.

Socket to 'em! - Torch Triple X - Part 5

At the end of the last installment I had managed to order a spare DMA controller for not too much from eBay. Well, it arrived and I very carefully installed it in place of the existing chip and...

DMA! DMA! DMA!

...no difference. The unit stops at the blue screen, the 68010 fails to start properly and the error beeps for 'main CPU timeout' still ring out from the monitor after 20 seconds or so.

Darnit.

And it was about this point where my replacement ATX power supply started to make worrying buzzing noises. After unplugging it as quickly as possible (and following a quick change of underwear) I put it to one side and decided to come back to it later. Fortunately, I still had my bench supply and I had received a suggestion to use said supply, current limited to about 2 amps to see if I could work out if there were any shorts on the board.

To cut a long story short, the supply went straight into current limit mode and the voltage across the board was exactly the same in every location at around 2.3v. As an experiment I tried to see what current the board would actually be pulling if the voltage on the 5v rail was actually 5v. It draws over 4amps. That's 20 watts for a relatively small bunch of chips. The technical manual suggests that the supply would be drawing a minimum of 2amps but 4amps is worrying.

That's a lot o' amps..

Next thing to try was the capacitors. There are no electrolytic caps on this board but there are about eight tantalums which could fail as short circuit. Perhaps one had failed and was causing a short to ground and the excessive current draw. But after removing them from the board they all checked OK. So then, in a slight fit of frustration (not the last) I removed EVERY 100nf bypass capacitor and checked them all. And there's eleventy billion of the little buggers. I found a bunch of about 20 or so that came out as 70-80nf instead of 100nf. These are clearly out of spec and I will replace them but they're not so far out as to cause any problems. 

Should be 100nf.

Woah! Should be 100nf..

Crikey! Should be 100nf!

Can you guess what? 
Should be 100nf...

Faulty. The lot of you!

After replacing all eleventy billion of the caps and new ones to replace the faulty ones, the result was...

No difference.

Darnit. Again.

Looking over the schematics, and thinking about the various buses in the system it's obvious that the QBUS is working as we are clearly running code from the EPROM. Based on the 'garbage' that used to appear on the screen, the video RAM also seems to be working correctly as this is where the code is loaded before the startup of the 68010. With this in mind I listed out the chips that touch the PBUS and decided to de-solder them so I could test them away from the board - this also means I could install some sockets.

There were a fair few chips in that list. Some of them I could test using my el-cheapo IC tester (but more on that later) but a big proportion were 74LS244, 245 and 373s. These aren't supported by the tester so I had to think of another way to test them.

Enter the Amiga A500+ motherboard! This uses the 74LS244 and LS373 in the data path for its RAM. They are usually the chips that take the brunt of the leaking battery on the A500+ (excluding Gary - poor Gary), and so the A500+ board I have already has them in sockets. It was a simple case of swapping one chip in at a time and checking that the A500+ board booted and didn't generate a green screen. So after a half hour of chip swapping I ended up with a pile of working 74LS244s and 74LS373s.

Ah, the Amiga. 
(Ignore the sockets - I ran out of 20pin ones...)

Next, the 74LS245s. These were a bit more involved and needed me to build a test circuit on a breadboard. Using 8 LEDs, 8 resistors and a bunch of link wires, it was possible to send 8 bits across the chip in either direction based on the level of the DIR pin and check the results using the LEDs as indicators. The upshot was a small pile of fully working 74LS245s.

We're running out of possible suspects on this board...so in the next fit of frustration I de-soldered pretty much EVERY chip from the board.

I thought I had found a problem on the board when a 74LS148 came out as 'BAD' on the chip tester. There is only one of these on the board and its an '8 to 3 priority encoder' which takes eight inputs and turns it into a 3 bit binary output based on the most significant bit on the 8 bit input. The three outputs connect to the IPL0, IPL1 and IPL2 control lines on the 68010. If I have understood correctly, the combination of these lines determines the type of interrupt received by the CPU. My theory was that the faulty chip was causing a non-maskable interrupt that the CPU could not reconcile with a system device causing the CPU timeout. So I ordered some new 74LS148s.

The first thing I did when they arrived was check them on the chip tester. Every one (there were four) came out as 'BAD'.

Oh, no it isn't!

Darnit.

This was annoying for two main reasons. Firstly, I know that the chances of all of the new chips being faulty is slim. This means that this is another case of the chip tester not being accurate. Secondly, the original 74LS148 is probably not faulty either which blows my (rather good I thought) theory out of the water (and I paid for chips I didn't need).. 

The upside of all this though, is that pretty much every chip now has a socket. This will make it much easier to change chips but does introduce a small liability of poor contacts in the sockets. And the hassle of putting them all back into the board again....

So. Many. Sockets.

So. Many. Chips.

After carefully putting every chip back where it should be (foreshadowing), I tried to start it up again. And this time, it was worse. The garbage was back on screen but was not like the previous type. This garbage scrolled down the screen and stopped. No other sign of life. 

So I embarked on a marathon of chip re-seating. Fortunately, using my epic new schematics, I managed to track the problem down to the timer chip. A firm re-seating was all that was needed. The situation improved in that the garbage was as I'd seen before i.e. a series of straight lines moving down from top to bottom followed by a smaller descending rectangle of 'different' garbage. I wasn't happy though as I wasn't getting the beeps out of the monitor to indicate that the CPU had timed out.

Hmmm.

I knew that the audio came from pin 9 on the service processor so it was time for the oscilloscope. And would you believe it..

Bip, Beep, Beep, Be...

So the sound isn't working now even though the service processor is sending out the correct signal. Not a huge problem as long as I know the service processor is still kicking up a fuss about the 68010 not starting up.

But I was still puzzled why I was getting the garbage on screen. Tracing through the video palette schematics I noticed that two chips U26 and U27 should have been a 74F257 and 74F253 respectively but, somehow, they'd been mixed up and actually had a 74LS257 and 74LS253. Interesting.. I swapped U26 and the amount of garbage was reduced. So I swapped out U27 and the garbage was gone! Yay!

But was the board still generating the expected error?

Oh yes. 

I have a habit of uploading the worlds most ridiculous videos. The first 'blip' is the 'beep' it should make when it's turned on. Then, after about twenty seconds or so, the main error beep starts and is 'short long long long', the code for main CPU timeout.

So that means, after all that effort of desoldering and testing almost every IC on the board, buying some chips I probably didn't need, soldering more sockets than any sane person ever should and carefully re-inserting all those chips, I'm basically back to where I was when I started looking at this.

One thing I haven't considered, and which I really should have by now, is if any of the traces on this board have been damaged either by the leaking battery acid from the power supply, or by my removing the chips from the board. I feel a massive spreadsheet coming on..