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... 

Chairman of the (key)board.. - Torch Triple X Part 7

I still can't get the Torch motherboard to boot. While I was poking around the motherboard and looking over the schematics, I saw that the service processor for the board - a 6303R which is a variation of the Motorola 6803, itself a later variation of the original Motorola 6800 - had a couple of pins connected directly to the keyboard connector. These were Tx and Rx. Hmmm. I wonder...

I dragged the keyboard out of the box that it's been sat in for the last year or so and plugged it in to the keyboard port. Curiously, this uses a version of the UK telephone socket as a connector. Odd but functional. 

Probin', probin', probin'.
Keep probin', probin' probin'.

With the Torch switched on and pumping out its sad 'Beep Beeeep Beeeep Beeeep' to indicate a processor timeout, I started to probe the keyboard pins using my oscilloscope. I was very pleased to see that pressing a key on the keyboard generated a signal. It also generated a signal when I lifted of the key. Nice. This means that the keys are working. After spending ten minutes carefully running over every key I am pretty confident that every key on the Torch keyboard is working fine. 

Press...

...and release.

It's not a mechanical keyboard but the build quality is excellent and it feels like it would be much better to type on than some of its contemporaries (looking at you Amiga A500 Mitsumi and Samsung keyboards). Not a patch on the IBM Model M but not bad.

Yep. It's a keyboard.

So, what now? Well, after taking a break from this machine I've come back to it and started to go back over everything I looked at previously.  So far:

1) The board is drawing a lot of current. Nearly 5amps! Some chips get quite warm but nothing gets burning hot. I've checked all of the ceramic and tantalum capacitors and, while some were out of spec (and so replaced), none were shorted. It's possible I suppose that there is some damage that I haven't found on the traces. 

2) Touching one of the connections on the power lead causes the computer to turn off - or at least the screen goes black. Without working drives or any other indicators it's difficult to know what else might be happening. I'm assuming that the offending cable must be coupled to pin 4 of the service processor that, with the original power supply, would be held low for a couple of seconds to shutdown the machine.

3) With nothing connected at switch on, there is a tiny quiet 'beep' with a pale blue screen. After about 30 seconds the fault beeps start - short, long, long, long - which repeat until the unit is switched off. Previously I had lines running down the screen followed by garbage filling about the top 1/4 of the screen. This is, apparently, the 6303R loading a program called 'SIMON' which then copies another program (called ERMA) into video RAM which should then be run by the main processor to start loading the hard disk OS. But this is the point where my machine apparently stops.

4) I have tested the 68010 in an Amiga A500 and it works fine. I also bought a second DMA controller from eBay which made no difference. The main concern on the three main processor type chips is the MMU. It's a Motorola 68451 MMU and is, to put it bluntly, rarer than rocking horse shit. If it's the MMU that's stopping the boot process then I'm slightly screwed. Partly because I don't have a spare to check if the original is faulty but mostly because I don't have a spare to replace it if the original is actually faulty.

DMA Controller - It controls...er...DMA.

The three stooges. CPU to the right, MMU in the
middle and DMA controller to the left.

With all that in mind, I have started to look at the Caretaker ROM. There are, apparently, a couple of versions out there. Mine has 1.3 but there is a version 1.2. I might try to get hold of that and find a spare EPROM to write it to. Couldn't hurt.. 

Caretaker ROM with 6303R just up and to the left.

Other than that, I am really out of ideas. While the schematics I re-drew are useful, they aren't really giving me too many clues as to how the machine actually works. The technical manual has some useful snippets but, sadly, isn't actually that technical. 

On the plus side, that tiny Sony monitor with the Trinitron tube is still running like a trooper and I'm fairly certain I could make up a cable for my Amiga to run on it. I haven't dared plug in the bigger monitor yet though.. Maybe tomorrow.