Haven't We Been Here Before? Cifer RAM Shenanigans

You'd think that after showing the Cifer some love it would appreciate not being in a skip and show a bit of gratitude. Sadly, it didn't for a couple of reasons. First, the RAM failed again. Second, it is not a corporeal being no matter how much I try to anthropomorphise it (but I know he's mocking me).

Garbage! Argh!

This is absolutely the same type of fault it had when it first arrived and, also more recently, when I tried to get him back up and running after he'd been lying on his side with his guts hanging out for about six months...

So, back into the depths. I removed the bottom cover, then the 68K board, the graphics board and the auxiliary board to reveal the main 'motherboard'. Thinking that it could be one of the other boards that had a RAM problem, I tried switching it on with just the main board installed but I still got the garbage on screen. This means that it is absolutely one (or more) of the eight RAM chips on this board. Darnit.

The offending RAM on the bottom right. Not an MT chip
in sight though.

Out came the homemade RAM tester and every chip was tested. You can imagine how annoyed I was that every chip tested OK. Does this mean there's something else that has gone wrong? I hope not..

Digging through my Box'o'Bits(R), I found a couple of spare RAM chips that were not MT (I still don't know where they came from - some rotten *** sold them to me I think) with the idea to replace one chip at a time to see if all of those chips really were working.

With the 'new' chip in hand I replaced the first chip. No change. So I took the first chip and used it to replace the second. No change. Then I took the second chip and replaced the third and...

It's alive! (Again - but for how long?)

..that was it! The third chip I took out was faulty. Just to be sure I marked it and re-installed it and, sure enough, the garbage returned. Why the RAM tester did not highlight this chip as faulty I don't know. I thought I might have to go back and re-write the tester 'c' program that was installed on the Arduino clone that is the heart of the DRAM tester. The original version of the program is now, sadly, lost to a hard disk failure many years ago but I do have the code it was based on (or more accurately 'shamelessly copied from'). The big disadvantage of my tester, other than it seems to think a faulty chip is OK, is that it's really, really slow. It typically takes about 50 seconds to check one chip. Multiply that up and even testing a relatively small number of DRAMs can take some considerable time. 

While wondering if there was any way to improve the code that I technically no longer had, I stumbled across a YouTube video on a channel called 'Trevor Makes'. In this video he described exactly the issue that I had with the RAM from the Cifer i.e. my quick and dirty tester showed it as OK but, once installed, it was clearly faulty. His version of the DRAM tester takes a different approach and uses the 'March C-' algorithm to quickly check a DRAM.

I don't pretend to understand much about the March C- algorithm. A quick Google just highlighted the most basic of explanations - which comes down to "it's fast" - and a lot of technical documentation with odd notation that is clearly logic based. Suffice it to say that it's fast, and it carries out tests that cover all fault conditions on the chip (as per Trevor's video - code on his github page).

Anyway, I decided to re-configure my current DRAM tester as it was clearly giving false positive results - could it also be giving false negatives? (Foreshadowing...ooooh!)

I shan't bore you with the details of re-wiring a circuit board. It's not a great spectator sport but, suffice it to say, I did it and I double checked it. Then I triple checked it. All connections were as per the diagram on the github page so all that was left to do was to reprogram the Nano clone that formed the brains of the outfit. And that was a where things went a bit wonky.

Programming an Arduino of whatever vintage/provenance can be done using the official Arduino software and this was what I had previously used with my DIY tester. This particular project though, is built using Platformio with Visual Studio Code. I'm reasonably familiar with VSC but I'd never used it for programming any type of embedded system before. Fortunately, Trevor Makes has a video for that too and, after a little bit of head scratching (I had to change the default platform to 'oldnano'), I managed to get the code compiled and on to the tester.

First test, I put the faulty chip into the socket and plugged it in. Red LED lit almost instantly. OK so far. Then I put a known working DRAM chip into the tester (the MT4264 - don't judge me). The red LED lit almost instantly. Oh. That was unexpected. So then I went and got my small collection of working DRAMs. Every single one came up as faulty almost instantly. Something was not right.

I decided to check the address lines that were being used on the DRAM and I immediately found the problem. The lines A0 and A1, which connected to the D0(RX0) and D1(TX1) on the Nano, were both being held high. All the other address lines were showing the expected typical activity. So why are these two lines being held high? The answer was in the primary purpose of the pins i.e. RX0 and TX1. These pins are connected to the Nano's UART and, to use them for any other purpose than serial connections, requires that the serial device is disabled in the code. I am not an expert in programming C++ or Arduino, rather I am an enthusiastic amateur, so I have no idea if the switching off of the serial device was included in Trevor Makes' code.  I knew I could at least try adding the code that Google's AI helpfully suggested, which would definitely switch the serial off in the 'initialisation' part of the code. And this, I duly did.

Additional lines of code circled red.

Another build cycle with the revised code was completed and after uploading the update firmware to the nano, I put the working MT RAM chip into the socket and switched the tester on. The first thing I saw is that all four LEDs on the Nano board itself lit up. This matched Trevor Makes' video which I took as a good sign. And then after a second or so the green LED lit up. Yes! This DRAM is, according to this new code, working. 

The light is green, the trap is clean.

I set about testing the latest dead DRAM from the Cifer. Bear in mind that the old version of the tester said that this chip was fine and dandy but if it was in the Cifer, it would not boot. Within a second, the tester told me what I already knew. This DRAM was dead - the red LED lit up. Excellent. I tested all of my remaining known working DRAMs and they all came up green so I could fairly confident that this is now working as expected.

This version of the tester has a couple of major advantages over the old version. First, it's fast. It really is. A 4164 1 bit 64k RAM is tested in just over a second, while a 41256 1 bit 256k RAM takes about 4 seconds and it's intelligent enough to know which type is inserted (4164 or 41256). Secondly, there are two distinct modes that this test can use. There's the standard test mode which I'd been using up to that point, but there's also a timing test. By switching one of the Nano pins to ground, the firmware copies a checkerboard pattern into the chip and then cycles round, reading the data back in a loop. With a strategically connected two channel oscilloscope it's possible to calculate the access speed of the RAM - handy to check if second hand chips have been 'altered' to make them seem better than they actually are.

Just on a hunch, I pulled out a big batch of 'failed' Hitachi RAM from the 68K board in the Cifer. Out of 15 alleged failed chips, 13 chips tested OK. I need to validate this somehow and it might end up with my taking a couple of the apparently working chips and throwing them into the Cifer to see if they really are OK. 

13no DRAM chips tested OK. Hmmm.

But now, with a vastly improved DRAM tester, I can go and check every RAM chip that is in the Cifer. RAM appears on the main board, the auxiliary board and the graphics board, and so there's plenty to go at. 

While I was at it, I 3D printed a new version of the rather basic case. My latest filament is Amiga beige but it'll do. I also added an 'on/off' switch since I also decided to add a fixed USB cable to drive the tester. Very handy. The power switch is the one at the bottom and the 'mode' switch is at the top. These were the only switches I could find in my Box'o'Bits(R) but they work fine.

"New case, who 'dis?"

Interestingly, I checked the 8 RAM chips on the Cifer graphics board (Tetronix 4010 emulation) and, would you believe it, one of the chips tested faulty. The auxiliary board has 32 RAM chips so that will have to wait until I have a little more spare time. 

Last act of defiance - adding an MT RAM chip
back IN to a vintage computer. Sue me.

So many RAM chips, so little time...

And there you go. I'm very pleased with the updated DRAM tester and even more pleased I didn't throw away all those chips that the old tester claimed were faulty. Nice.

DARK IN HERE, ISN'T IT? - Death, The Light Fantastic

Darnit. I thought that quote was 'Quiet in here....' but there you go. I've been quite quiet recently, mostly because this thing called 'real life' has the audacity to get in the way of generating high quality, vintage computer related, web published articles. As Crashed Jr (an avid gamer) once said, "I went outside once. The graphics were amazing but the game-play was shit." A regular modern day philosopher (and I know he shamelessly pinched that from somewhere on the internet).

Anyway, what's happening? A few updates:

Torch Triple X

I received several more replacement chips to try swapping on the OMTI disk controller board but to no avail. I've said before that I don't like throwing parts at a problem but this one is so annoying I couldn't stop myself. Sadly, the new parts - a Z8 Romless microcontroller and a floppy drive controller chip made no difference. 

You can see which chips I have replaced or managed to test off the board from the pic below. There's not a lot left to try other than the two PLCC socketed OMTI chips. If they're faulty, then the board is completely toast. 

Green - chip replaced
Orange - chip removed and tested OK

Just in case that it was actually the floppy drive causing the issues I also tried hooking up a Gotek to the OMTI board, but no joy. The unit sits there with no interaction shown on the OLED display at all. Nothing, nada, nil, zip, zilch etc, although with a real drive I have noticed that the floppy drive light does pulse almost imperceptibly and regularly so perhaps all is not lost.

To try and analyse the SCSI activity the most excellent Adrian at Binary Dinosaurs lent me a 16 channel logic analyser as he too has a Torch Triple X. I have certainly learnt a lot about SCSI in general while poking away at some of the trace files I have pulled off but I have not yet managed to get the one SCSI decoder that is available (which takes the analyser output and translates it in to more readily readable SCSI commands) to work - yet.

There was a another glimmer of hope recently when I realised that the BlueSCSI that is currently working fine with the TripleX also supports floppy drive images i.e. it can pretend to be a floppy controller on the SCSI bus. However, the issue we have with the Torch is that it expects the hard disk to be on SCSI ID 0, LUN 0 i.e. the first sub-address on SCSI address 0. But then it also expects the floppy drive to be on SCSI ID 0, LUN 2. 

Gratuitous floppy shot.

The current BlueSCSI software favours only LUN 0 on each SCSI ID although it is possible to 'force' the filenames of the disk images to be the LUNs. But, as described by the BlueSCSI chaps on BlueSky, it's a bit of a hack. Changing a simple parameter in the .ini file activates the option as well as another parameter for an option to use 'quirks' related specifically to OMTI disk controllers. But sadly, at the moment, this is not working and no matter the various configurations I've tried, the key disk remains resolutely unseen. 

That's not the end of the BlueSCSI floppy though as another chap popped up on the VCF forums who also has a Torch Triple X (or at least the motherboard for one). He is looking at the code for BlueSCSI v2 - avaialble on github - to see if he can update/modify/patch the current code to specifically cater for the Torch. If I had the knowledge and capability I would be pitching in with this but, given my limited exposure to coding in anything but BASIC or Python, I'd just be peering over everyone's shoulder asking "What's that bit do?".

Cifer

Ah, the Cifer. After repairing another broken logic chip on the keyboard and another failed RAM chip, everything seemed to be back to normal. But, guess what. In the spirit of vintage hardware keeping everyone on their toes, it's failed again. 

Working. Now, not working. :(

It basically keeps munching through RAM chips. I had it running CP/M and left it on for a while as I was doing something else. When I came back to it, the screen had locked up but was still displaying everything normally. So I switched it off and back on (ha, the more things change, the more they stay the same) and rather disappointingly, the display appeared blank. Closer inspection showed that it was on, but very faint and showing garbage. Yep, another RAM fault. 

Suspicious power supply. Are you responsible for killing
all my RAM chips? Well? Speak up!

I do have suspicions about the power supply. It's the only thing I can think of that would keep blowing up the RAM although I do still need to work out exactly which chip is affected. If it's in the same position as the last one then I might drag all the boards out to check for unexpected shorts etc. I have been considering a Meanwell supply to replace original but I'm not sure if that's feasible although the current supply is a very similar form factor. We shall see..

Christmas (very seasonal..)

Not necessarily retro but an interesting project fell into my lap around Christmas. For 'reasons' I ended up with two rolls of remote controlled LEDs (from Menkind). Now, being a bit of a tinkerer there was no way I was just going to let them live happy lives with their built in controller and IR remote. One roll would be sacrificed to the great gods of tinkering. 

First things first, what sort of LEDs do they use?

Hmmm. Are these WS2811/WS2812 LEDs I see before me?

Dunno. They're too bloody small but they 
look like they could be.

A small section was cut off for experimentation purposes. One Raspberry Pi and three dupont connecting wires later and:

Ohh! Pretty!

Looks like we have a successful test. :)

For a long time I've always wanted to have a go at the DIY Christmas decoration that was highlighted by the RasPi guys several years ago. Fortunately, the article for that is still up here. In fact, it was 10 years ago! Holy cow. 

Anyway, here's some pictures of me setting it up:

Designing the scrolly message.

First few strips mounted.

Original wire connections - but later changed!

All strips mounted, awaiting wire connections.

The board was a piece of hardboard, about A3 size, from Hobbycraft. I cut the LEDs into strips of 12 LEDs and mounted 8 strips (so 12x8). My handy staple gun fired staples that just straddled the rubbery LED strip making it really easy to fix to the board, along with the adhesive on the back.

Initially, I tried to use some offcut mains cable to join the stretches of LEDs but the wires were too stiff so that hour or so I spent soldering them onto alternate ends of the strips was a bit of wasted time. But no matter, I found some thinner core wire that was much more appropriate and easier to handle. 

For power I used the end of a broken micro-USB cable i.e. I chopped the knackered end off and then wired up the +5v and ground to the end of the first LED strip. I also attached a second connection to the ground so I could plug in to the ground pin on the RasPi GPIO. As I'm using a relatively short section of LEDs (no more than 96) I can get away with connecting the ground but there would not be enough to power the LEDs from the Pi. So by attaching the USB plug I can either use a chunky power bank or simple USB charger plug.

With power and ground connected I just needed to connect up the data pin. I basically copied the original article so I'll let you go and read the details over there.

Once it was all connected up and power applied I ran the AdaFruit LED test program and....

Rainbow!

Rainbow! But with the colours slightly changed!

...it just worked! Nice!

So then I shamelessly blagged the code from the original article and loaded up the included test .png. I did have to make a couple of tweaks to the code to match exactly the LEDs I had. For some reason, my LEDs did not like the RGB order in the code, which meant the colours were all wrong. But it was an easy fix in the code and only took a couple of minutes of pondering to work out what was wrong.

And the results are:

This would definitely benefit from some sort of diffuser in front of the LEDs. If I can be bothered before this Christmas (only 298 days to go!), I might even 3D print something to put each LED in it's own compartment to make it even clearer. We shall see.

Sadly, it looks like the LEDs I used are no longer available if you fancy a go at doing this yourself. But there are later versions with 2m strips for £10 and I think they use SMD5050 LEDs (mine were two 5m reels for £12 each with WS2812 LEDs) which might work. YMMV. All the details of the project are in the original article. But some handy hints I found with this LED strip:

1) The clear rubber needs to be removed from the contacts before you can solder to them. They need to be clean so make sure you get it all off.

2) On the subject of contacts, make sure when you cut the strips, cut in the middle of the contacts that appear between the LEDs! It doesn't matter too much if it's not exactly in the middle but you could end up with one strip that's dead easy to solder wires to, and one that isn't. Ask me how I know.

3) The board I used was this one from Hobbycraft.

Merry Christmas!

Xbox Controller (Again)

Repaired Crashed Jr's Xbox controller AGAIN. That boy (also known as 'the cable slayer') could break a cast iron skillet..

Once again the joysticks in the unit failed and, once again, I had the joy of stripping it down and taking the old joysticks out. I've done it so many times now, it only takes about half an hour and that's including making sure that the damaged traces from previous repairs, don't get dislodged.

Someone's been in here before. 
Oh, yes. It was me...

Bodge wire to fix a previously damaged
trace - these things sink a lot of heat!

No bodges, but more super hot fun.

Normal service will be resumed soon! I hope...

"Thou shalt get side tracked by bulls*** every go**am time." - The Ghoul, Fallout

While waiting for a couple of logic chips and a Z8 microprocessor to arrive from everyone's favourite auction site to try in the errant OMTI board, I thought I would spend some of the limited spare time I get to install a gotek in the Cifer.

My thinking on this was that the hard disk is still not working and the floppy drive has been 'pinched' for the Torch (for now). If nothing else, it would be cool to have a gotek loading up CP/M on the Cifer and would give me an excuse to play with my 3D printer to create a black front plate that matches the current floppy drive bezel.

First things first.

It's been a while since I had the Cifer switched on and I have been guilty of pilfering some RAM from its non-functional 68000 expansion board. Well, to be honest, I've nicked all of it. I suspect I may have to do a bit of a bulk buy if I can find any large lots of RAM lurking online. 

Ah. Not only missing the RAM the 68K board is also
missing the err... MC68000. Oops.

It's been spread across various machines (including the Torch) with the result that the Cifer has been left open, sat on its side with the innards hanging out. What could possibly go wrong?

It's like a vintage computer horror film...

So today, I found the various screws I had and, after tidying up the boards and cables, affixed the base plate and turned the Cifer main unit back onto its feet. After plugging it in and switching it on, imagine my slight sadness that it appeared the unit was dead. The fan started up OK but it's an AC fan connected directly across the mains voltage so it's always going to work. But nothing appeared on the CRT. Darnit.

I reached for the reset switch and, fortunately, the CRT sprang into life but showed a garbled screen of incomprehensible garbage. Double darnit. 

Artists impression - this is an old pic but you get the idea..

Side Track 1

Immediately, I suspected the display RAM which just so happens to be on the largest board inside the Cifer, buried deep inside. Off came the base plate, out came the 68K board and the 4010 graphic emulation board, until finally, I got down to the display board. There's a gaggle of eight RAM chips in the bottom right corner and it was one of these that I had replaced the first time I worked on this machine. My RAM tester is in a very different condition now, having been 're-factored' onto a prototype board which is firmly fixed into a 3D printed case, rather than just a bare bread board, but it still works as advertised.

OK, so it's not the most exciting 3D printed
case on the planet

First chip, faulty. 

Oh, no.

Second chip....

Fully working. As was the third, fourth and, in fact, the rest of them. I went back to double check the first chip failure to confirm it wasn't just a dirty contact on the tester's ZIF socket. It still failed and I actually checked it another three or four times just to be certain. I did have one RAM chip left on the 68000 board but, ironically, it's a Sanyo chip which was harvested from an Amiga RAM expansion several years ago. But it tested OK (even it it's technically the wrong RAM size - the pin out is compatible but it won't use the top bit) so I installed it onto the board.

And...success! The display appeared exactly as it should with a line of options at the bottom of the screen and a friendly flashing cursor on the top left.

Phew! Normal service resumed...

At this point I cobbled up the necessary cable to connect the gotek into the system, The current floppy drive and the gotek both use 34 pins but the physical drive uses the edge-connector style connector and the gotek uses 34 pins. After a false start I realised that the floppy cable in the Cifer is quite long and extends deep into the case before appearing at one of the external connectors on the back. This meant it wouldn't be easy to just use any old floppy cable so I decided to put an IDC connector on the existing cable far along enough to reach the rear of the gotek when installed, but far enough away from the existing plug that they can co-exist.

And so, once this was done (which involved two pairs of pliers, at least one piece of pinched skin and several colourful words) I was ready to get the unit back together and plug in the gotek. I also didn't quite get it far away from the existing plug, but that's a problem for another day.

Additional 34 pin connector

And then I realised I hadn't plugged in the keyboard. Obviously, I plugged it in and started the Cifer up again.

Side Track 2

BEEEP BEEEP BEEEEEEP

Oh, dear.

Garbage in, garbage out.
But I've seen this happen before..

The keyboard was spouting tonnes of garbage onto the screen. Disconnecting the keyboard stopped the garbage so, there's something wrong with the keyboard now. 

Triple darnit.

The keyboard has a bunch of standard logic chips and a few other passive components so I did what any enthusiastic amateur would do. Throw parts at it! First, I tried changing the chips that I'd previously replaced which were in sockets. This made no difference. So then I started removing and then testing the remaining chips starting from the end with attached curly cable. And when I reached to CD4040, my tester declared the chip was "BAD". Ah-ha! I had a couple of these in the box 'o bits so, after fitting a socket (actually two small sockets as I'd run out of the actual size required) and pushing a new chip home, I tried again.

The keyboard board. Another earlier pic prior to 
the original repair attempt

CD4040 at IC8 - now socketed

And...

Success!! The keyboard was behaving itself and I could type as previously and, more importantly, I could press 'F6' followed by the 'Disc' key to trigger the OS load function. 

Back on Track

So now I have a gotek, a cable with the right connector and a computer waiting for an operating system disk. This brings us all the way back to getting an appropriate disk image on to the gotek. With the excellent greaseweazle, it's easy to 'rip' an image from an existing disk - assuming you have a working floppy drive of course.

Fortunately, I have one working 5 1/4 floppy drive (from the Cifer itself) and a bucketload of disks to rip. But first, I need to make sure that I can actually get the correct format. The Cifer has a slightly odd disk format which includes Track Skew and Sector Skew attributes. When data on the disk is written or read, once one track has completed writing or reading, the heads then move to the next track. The movement of the heads takes a finite amount of time so the skew ensures that, in the time it takes to reach the end of one track and move the head to the next, the start of the next track (or first sector) arrives under the head at the point the head reaches that track. That is, the data is skewed from one track to the next by the angle the disk would advance in the time the head needed to step from one track to the next. (See here.)

Similarly, the sector skew value does the basically the same but on a sector level rather than a track level. The upshot of all this is (allegedly) more efficient and faster read/write access to the disks.

Photo of a screenshot of a photo (!) of the Cifer disk format

All this is very important when we want to 'rip' a disk and create an image to use on the gotek. 

Back to greaseweazle. The first thing to do is hook up the greaseweazle with the floppy drive and check it works. The large units like the 5 1/4 inch unit I have here, mean that I need to use an external power supply to do the job. They need +12v so a USB cable isn't going to cut it here.

Next, with the greaseweazle software installed and a disk inserted, we issue the command:

gw --drive 2 seek 70

This makes the head move to track 70 (other tracks are available) and is a good verification that the greaseweazle can see the drive and communicate with it.

Next, we capture a raw .scp file which is a single file that captures the actual flux variations in the magnetic coating on the disk itself. They tend to be quite large but are the best way to ensure a good 'master' copy of a disk.

gw --drive 2 read myTestFloppy.scp

Typical greaseweazle output when reading a disk
(This is from a linux powered PC but is the same for Win)

Once it's done, I tend to load the image into the most excellent HxC floppy disk emulator software so that I can see a representation of the actual disk. Example below!

HxC Floppy Emulator - This is when things go well!

Now comes the slightly tricky bit. We need to convert the .scp file into something a bit more friendly for the gotek. This could be done by specifying all of the needed parameters at the gw command line but that would be really cumbersome. Fortunately, gw has several 'built in' disk formats and also allows you to define your own. For the Cifer, the disk format is like this:

# prefix: cifer.

disk dsdd

    cyls = 80

    heads = 2

    tracks * ibm.mfm

        secs = 10

        bps = 512

        rate = 250

        cskew = 2

        hskew = 4

    end

end

So the 'prefix' bit is the name of the format i.e. cifer. Then the 'dsdd' is the format of the disk needed. All of the other bits are the parameters passed to gw so we don't have to enter them ourselves. This includes an 'ibm.mfm' option since it does use that particular encoding. So the conversion line for the file looks something like this:

gw convert --format=cifer.dsdd cifercpm1.scp testimage1.img

Nice and simple. :)

Each disk format has its own defs file that is stored (in Windows at least) in the greaseweazle-1.xx-win64\greaseweazle-1.xx\lib\greaseweazle\data folder. Earlier versions had a single giant diskdefs.cfg file but the version I've been using (1.20) uses the one file per format arrangement.

So, now I have an .img file containing CP/M. The question is, does it actually work? Let's find out.

The gotek was connected to the data cable and a suitably modified power cable (mod is reversible). I powered the Cifer on and could see that the display on the drive lit up. Using the two buttons on the front I made sure that the correct disk image was selected and then pressed 'F6' to select 'CIF' mode, and then the 'Disc' button followed by the enter key. 

All set up and ready to go.

And......

Ah. I think you'll find that it works. :D

That. Is. Freakin'. AWESOME!

Playing with CP/M

That worked an absolute treat! So now I can go and look at taking images of all the Cifer disks that I have in my boxes. And of course I also managed to get the 3D printer out to put it in a proper 5 1/4 in type enclosure. 

I think that I will put the gotek in the Cifer itself using the fancy 3D printed bracket, and extend the cable out so that I can plug in the physical drive unit if I need to. Oh, and I wondered if both drives would work on the one cable. Yes. Yes they do. Setting the gotek to DS0 and the TEAC drive to DS1, they behave impeccably (no pictures sadly) as drive A and drive B. And not a twist of a cable in sight IBM.

Here's the 3D printed bracket in all its glory! 

Naked(ish) gotek

Next time, I lose hours of my life trying to make the Torch TripleX boot..

"And on the 381st day, he rose again (almost)..." - Torch Triple X - Part 8

There's a saying which can be abbreviated as 'KISS', or 'keep it simple stupid'. The argument is obviously, if you keep something simple, it's more likely to be successful. So, from that, you might be getting the feeling that I've found something stupidly simple to do with the Triple X. And you would be correct.

One of the main things that has bugged me about this machine is why, when using a perfectly good ATX power supply, there was only 4 volts on the 5 volt rail. Was it a short on the board? Could it be a faulty chip leaking current to ground? In the efforts to try and find out I:

• de-soldered every capacitor and checked every one (some were out of spec to be fair)
• de-soldered every chip and tested each one (also added sockets to every chip)
• spent hours tracing the tracks to see if there was a broken or damaged track somewhere causing problems
• bought a spare DMA controller chip (MC68450) 
• attempted to buy an MMU (MC68451) but found they are the proverbial rocking horse sh*t
• dismantled, cleaned and re-assembled the power supply plug that plugs into the motherboard
• swapped the 68010 into an Amiga A500 to check it worked (it did)
• checked every DRAM chip on the motherboard and Limpet expansion board (twice)
• read up on the DMA controller and MMU to see if I could work out if any signals were missing or going astray

Well, guess what dear reader. It was none of those things. Tonight, while contemplating what to do next, I had the Torch switched on and, on this boot, I had fairly dark lines running down the screen. 

Ah, the usual garbage on screen.

I happened to move the cable from the ATX power supply and I saw that the lines almost all disappeared. I fiddled a bit more with the cable and the unit went off. Could this be the source of the problem?

My cable setup was a bit convoluted. I had the ATX power supply with standard Molex plugs. This plugged into a Molex socket with fly leads which where then connected to the actual Torch power cable via 'choc-blocks'. The point at which I could affect the display was at the purchased Molex socket... So I removed it from the setup and cut off one of the Molex plugs from the ATX PSU so that the red, yellow and black wires went straight into the connector blocks.

I did not expect this to make any difference, but when I switched on the PSU I saw immediately that the red LED on the Limpet board flashed. I had never seen it do that before. And then, after about five seconds or so, the pale blue screen changed to dark blue with the text 'Caretaker 1.3' shown at the top.

The best thing I've seen on a screen for a long time...

Oh. My. Gosh.

And then, after another few seconds, two more lines appeared with the message 'SCSI Controller 0 not present' and 'Please insert the key disk'.

No SCSI controller - not surprised as it's not plugged in!

Oh. MY. GOSH.

Trembling, I reached for the Torch ring that contained the hard disk and floppy drive. After some more power connection shenanigans I turned the machine back on....

....and the hard disk died. Or more accurately, it didn't really spin up. This was a bit of a disappointing surprise. I re-checked all the cables and tried again. This time, the drive managed to spin up, but then, as I brushed the power cable, it span down. Did I have ANOTHER dodgy connection? Yes, yes I did. This time is was the plug on the hard disk itself. It was tarnished with a slight hint of green, presumably from the battery vomit. I took the drastic step of desoldering the plug so I could clean it properly - which I did - and then I re-installed it.

Back on the bench, I had just the hard disk connected up to the disk controller board and main Torch unit -  balanced a little bit precariously - and switched on.

Is this a GUI I see before me?

OH. MY. GOSH.

The hard disk works. Or at least it works enough to read the static RAM and realise it's missing the required security information. 

And then, to cap it all, I decided to plug the keyboard and mouse in to see if the mouse would move the pointer. And it most certainly does. All I need to do now is get the floppy drive plugged back in and try the security disk. It'll almost certainly lose any settings it picks up when it gets switched off (and then demand the security disk again) until I can rig something up with batteries to stop that happening.

A slightly precarious setup.

And then I hit a snag. In my haste to get the floppy drive connected to the Torch I connected the data cable to J2 on the disk controller, instead of J7. I didn't notice this at first but when I booted up again, with a 'sacrificial' disk in the drive, just to check everything would work, nothing happened. It was only after about five or six boot attempts I realised my mistake.

Cable plugged into J7 which is correct this time...

The sequence of events went like this. After another failed boot I wondered if there was an issue with the floppy drive itself. So out came the Greaseweazle and, after a few minutes of fiddling I found that reading disks was not working properly. Specifically, the bottom head was reporting much lower flux levels than the top. Looking at the track analyser in the floppy disk emulator confirmed my worst fears. The bottom head is not working at all.

Top looks fine (left), bottom not so much (right)

So then I went back to the controller board and checked the connections and, would you believe it, I'd plugged the floppy drive into one of the control connectors for the MFM hard disks. Now this should not have really had any negative affect on anything, but it looks like, thanks to my impatience, it may have damaged the floppy drive. Of course, it may be coincidence and the head just went bad, but as a great man once said, "There's no such thing as a coincidence.".

Fortunately, I have another floppy drive available from the venerable Cifer. It's a much simpler drive but it should (I hope) do the job. 

To the rescue! Sort of!

*Narrators voice* "But it did not do the job."

Sadly, no matter how I configured the drive (I had fiddled with the drive selection jumpers before and the manuals are particularly bad at saying what the drive number should be!) I just got the same results. Grey screen, icon demanding the key disk.

So I am now in the position where it looks like the motherboard is working OK, the Limpet board RAM is working OK, the keyboard and mouse are working OK and the hard disk is working OK (hence the grey screen demanding the key disk), but I cannot make the floppy drive read the key disk. The objectively terrible manuals don't really say whether the floppy drive should access disks automatically or if there should be some 'secret handshake' on the keyboard to kick things off. It's almost implied it's automatic, but not explicit.

I'm off to do some thinking...

PS I decided to try and get the BlueSCSI working as I have disk images from the Torch. After a bit of fettling I got this:

Well, that's not right.

Fortunately, a quick rename of the image file on the SD card and things went a little more smoothly. It just appears to work. So now the Torch can tell me to insert the key disk even faster...