Stop breaking down already! *Sheesh.*

After the debacle with the full height MFM hard disk and the exploding power supply (see here), I decided to come at the Cifer from the other end. In other words, I decided to see if I could use the BlueSCSI v2 to create a hard disk for the Cifer, even if that meant only using CP/M rather than the version of Unix that is hiding on the physical unit.

Working Cifer following PSU repair.
Yay!

There are a few obstacles to overcome with this. Firstly, the IEEE bus seems determined to just not work. It's almost as if the cable is not even connected to anything (foreshadowing)... I have had the bus responding to stuff previously, but it only ever seemed to work if the winchester disk boards were disconnected but the 68k auxiliary processor board left in.

But a quick test showed that, as it stood, the IEEE488 bus remained resolutely dead, no matter what boards were or weren't connected. Darnit.

I decided to trace the cables and make sure that there were no issues. To cut a very long diagnostic activity short, guess what? The IEEE488 cable that should've been connected to the disk processor board, wasn't. Doh.

After re-connecting it and trying again, the bus showed the first signs of life i.e. on startup, I could request it try to boot from a winchester disc (w10 through w17 although I think only w10 and w11 are actually implemented). It wouldn't find a drive though, but it was a start.

So, next I considered if the Xebec 1410 controller was faulty. This is required for the MFM drives since they have no real control electronics installed. I removed it and put a blank HD00.img file on to my BlueSCSI v2 and connected that up instead of the controller. The IEEE488 expects a SASI drive but given that SASI was the pre-cursor to SCSI they are fairly compatible (I hope).

And now when I select 'w10' there is a brief flash on the BlueSCSI. But the system hangs and requires a hard restart. Not great, but a tiny step forward.

Next thing is to try and accurately create a blank disk image that is already formatted for this particular version of CP/M. This absolutely requires an OS that can do useful things rather than the AI laden, advert infested thing that corporations insist on using, so I headed over to my Linux install. Creating a blank image is fairly simple with the command:

dd if=/dev/zero of=blankdisk.img bs=512 count=40960

This creates a blank 20Mb image. But that's just a series of zeros in a file and the Cifer expects to find a formatted disk filesystem. 

So then I did a bit more research and discovered the cpmtools package in Linux. This handy set of stuff lets you format a blank file into a blank filesystem for CP/M using any one of the many, many (many) formats. Then, once it's formatted you can even copy files to it and list those files in the filesystem. 

All this is great stuff and I created a couple of filesystems to try on the Cifer and see if I could get any different results out of the IEEE488 bus. And it was during the testing of these filesystems that disaster struck. Again. AARGHHH!

You have GOT to be kidding me.

This happened during one of the boots I did. One second the display was fine, the next it wasn't. What. The. Heck.

My first thing was to remove all the other boards other than the main processor board. Out came the 68k auxiliary processor, graphics board, IEEE488 SASI adaptor and the disc processor boards. This leaves the Cifer is about as bare a state as can be while still be usable, albeit a bit crippled without any disk capability. This would also show if the fault was on one of the other boards. Alas, there was no difference so the fault was definitely on the processor board. Double darnit.

Next, I thought that this could be a RAM problem. There are 8no 4164 DRAMs on the board. But they all checked out OK with my DRAM tester. There are also five static RAM chips on the board too. I didn't have any way to test these but I swapped them around and looked to see if the fault changed in any way. It didn't. Triple darnit.

Out came the schematics. Looking at the general arrangement of the chips I made a short list of the chips that I thought might be causing the issues. This list was constructed by looking at the data and control lines around the display circuitry and looking for anything that might cause problems if it failed. The list included a pair of 74LS244s, a pair of 74LS374s, a trio of 74LS158s, a 74LS32 at location ML94 and an 74LS04 at location M72.

I had a couple of options to test the chips. Or at least I thought I did. I bought a cheap chip tester a while ago but it has several limitations - mostly that it doesn't actually support that many chips. Of the batch I wanted to check it would only test the 158s, the 04 and the 32. So I brought out the big guns. I have an EEPROM programmer unit, model number T48. The software for this also has a very handy 'logic chip test' function which DOES support everything I need.

Logic test to the rescue!

Unfortunately, none of my selected targets proved to be faulty. Now, if you've seen any pictures of the processor board (one might appear below), then you'll know that they have a lot of chips. No fancy ULAs in this machine, oh no. Proper old school logic in this machine through and through. But most importantly, everything is in a socket (phew!).

Processor Board - lots'o'chips

So, I removed the board completely from the machine leaving it empty of PCBs and I took it to a safe location and removed and tested every logic chip, starting at one side and working my way methodically towards the other. 

No boards in 'ere mate.

And guess what I found... 

A faulty 74S32 - a quad, 2 input OR gate. It was at position ML71 which is (as you might expect) right next to ML72 which was one of my original targets, specifically the 74LS04 at ML72. Three of the OR gates in the 74S32 were permanently set high.

I did a bit of hunting through the schematics and found three locations where the chip was used. It looks like it handles memory size (2kb or 4kb), along with specific signals /BNK and FLASH. Given that the display has a number of lines that are rhythmically flashing, this could be a good sign that replacing this chip might solve the problem. Also, there's a CLK signal going through it too.

Memory control

Flash! A-aaa!

Tick-tock. I spy a clock (signal)

The faulty chip is actually a 74S32 rather than 74LS32. In general it means that the chip is quicker handling the signals. In reality, I don't think there's anything that critical for timing in this machine so I can probably get away with a 74LS32. I don't actually have any in stock, but as luck would have it, there are several scattered across the other boards, so I pinched one from the 68000 auxiliary processor board.

After a bit of a to-do getting the board re-installed (there's more cables than you think and they need to be in the correct order) I was ready for the switch-on....

Yay! It's alive (again)!

So, another repair. I need to order some 74LS32 and 74S32 chips so I can replace the one I pinched and have some spares. But at least it still lives.

Now, if it could please stop dying on me that would be great, thanks.