When is a Torch not a Torch? When it's an emulator....

The old hardware of the Torch Triple X is proving to be a little bit bothersome (it's a right old pain the rear) and I've made little progress in fixing the motherboard issues. I won't give up but it's taking longer than I ever thought it would.

It was making feel a bit despondent to be honest, but then, on the VCF forums, a most excellent chap disclosed that he'd written an emulator for the Torch, based on the Motorola 68000 emulator called Musashi. What. The. Heck. 

 

The first screenshot!

 

Holy [CENSORED]! Obviously I started to ask some questions. This first version apparently had some memory issues with the MMU, but what a start! 

Eventually these issues were resolved and the next screenshot provided was just stunning.

**Speechless**

This was running the regular hard disk image from bitsavers (on which my own physical Torch adventures are based!) and shows everything I would expect on the screen. Just. Wow. But then....

Networking. Oh. My. Goodness.

Needless to say, this was awesome work. But, you should know me by now. I wanted more. Fortunately, the working code was uploaded to the forums and the original author basically said 'knock yourself out' when I asked if I could start fiddling with it.

From this point on, I should point out that I am not proficient in 'C'. I know a reasonable amount of Python and I'm familiar with general programming principals (I am a child of the 8-bit era after all) but the C syntax is a bit odd to my Pythonic eyes, but not horrendously so. The main point I want to get across is that you are not going to see a 'tour de force' of programming skills and some things I do may make experienced guys out there cringe. I just want to make it work.  

First things first, the colours. I found the bit in the code that set the palette. It should be set from hardware (I think) but the code has fallback if the palette isn't set up. Since the initial version of the emulator was clearly using the fallback colours, it was a simple case of identifying the correct values for a more pleasing set of colours to replace the current pale blue/white palette. 

Colours. So many colours. Well, four anyway..

Normal(ish) colours for OpenTop

That made things look a bit more like home. :)

Nice.

 

It's worth noting that I spent quite a bit of time trying to make the emulator just use the colours that the system does without using the fallback colours. This proved to be far more difficult that I imagined. No matter what I tried, the palette will not use the 'real' Torch colours. I suspect that there is some hardware trickery going on on the real motherboard to make the colour updates as the Caretaker boots up. It's not a big thing since the colours I've put into the fallback do look quite reasonable but it is mildly annoying. 

Next thing, the aspect ratio. The display was squashed vertically and needed to be increased. Fortunately, this was a relatively simple tweak to the SDL window settings and then we were pixel perfect.

  

Running fullscreen on my laptop. Oh, yeah.

Next, the keydisk. This disk has a very annoying format that changes at the end and adds an extra track to extend the available space. This space stores the unit serial number and acts as the 'key' to unlocking the system. With the emulator set up as it was originally, the keydisk had to be present for every boot. This is not a major issue but it bugged me that it didn't try and store it somewhere so that if the keydisk wasn't specified in the startup parameters then it still startup correctly. Also, for the emulator, the keydisk image needs to be in .IMD format to ensure that the right part could be accessed for the serial number. But .IMD images can't be mounted on Torch Unix - something similar happens at startup in the 'real' hardware. The Gotek can read the .IMD image and boot the machine but then it cannot mount it in Unix once booted.

Looking at the code I could see that when the emulator reads the keydisk it takes the relevant piece of the special last track and copies it into the memory location of the real time clock. On the real Torch the RTC chip has a tiny amount of volatile RAM which is used to store this key number. By putting it there early on in the emulator startup, the WERMA startup programme (vaguely similar to a BIOS) doesn't complain when it compares the memory contents against the key disk. If it wasn't there then the message 'New battery fitted' would appear at every boot which would be a little bit annoying.

Anyway, rather than have the keydisk attached every time, I decided that when the Torch starts it will check for the keydisk number in a tiny binary file. If the number isn't there then it would carry on and do the 'copy and check' from the keydisk but would also create the tiny binary file 'torch_serial.bin'. Simple and effective. This also means that, in theory, the key disk image would not be required any more as the 'torch_serial.bin' file could be provided with the emulator. But that would be cheating. :)

 

I made this!

And it all works rather well.

 

Terminal output - found the keydisk and saved the serial number

After I'd done this I realised that, really, all I'd done was move the reading of the keydisk to a simple binary file but it feels easier not having to basically have the keydisk image there every time.  And if you really blur your eyes you can pretend that the 'torch_serial.bin' is actually stored in the RTC RAM. (You still need the keydisk to make networking work - but I'm getting ahead of myself.)

 

No need for the key disk on this boot. :)

 

Next up, I wanted to mount a regular floppy image in the emulator. This was partly the reason why I didn't want to have to include the key disk every time at startup, but in the end it turned out not to really make any difference.

Anyway, the Torch uses either the OMTI SCSI board to support both hard disks and floppy drives or a special 'MANTA' board to handle only floppy disks. For the purposes of the emulator, and trying to mount a Unix floppy specifically, we stuck with the OMTI configuration. This meant that the code for the floppy was basically a variation of the existing code to handle the actual SCSI hard disk. As such, it was reasonably straightforward to add another option (--unix-floppy) to point the emulator at a Unix floppy disk image. 

For the actual floppy images I initially struggled. But eventually I found that it was actually quite straightforward to create a blank floppy disk image like this..

In Linux, create a blank file of the correct size by running :

            dd if=/dev/zero of=floppyblank.img bs=1024 count=720

Then copy the image into the directory/folder with the Torch emulator. Include it in the startup parameters with:

            --unix-floppy floppyblank.img

Then, when the emulator has started, open the Torch terminal and su to be root. Then run the following:

            format /dev/fdsk/0

This is specific to the hard disk image I have so your mileage may vary if you use a different disk image. If so, just have a look in /dev/ and see what floppy disk devices might be there. Interestingly I struggled to use the /dev/floppy device which is also present, with Unix complaining "Can't determine controller type". But the /dev/fdsk/0 device returned no error on the format command.

Then, just make a filesystem on the newly formatted block device with:

            mkfs /dev/fdsk/0 1440

Finally, mount the image so it can be seen by the system and written to:

            mount /dev/fdsk/0 /mnt/flop

Obviously, my disk image has a directory called 'flop' in 'mnt'. Yours might be different.

The key concept here is that the filename for the disk image persists through the emulator session i.e. the image could be mounted in Torch Unix as described above, files written to it, unmounted in Torch Unix and then replaced with a different disk image PROVIDING it has the same filename. (It sounded a lot simpler in my head when I started writing that..)

To ensure correct operation of the floppy image, it's necessary to run 'sync' in 'tsh' and then 'umount /mnt/flop' which cleanly disconnects the disk image from the system and allows the copying of it to different locations.  

I did spend quite a lot of time trying to sort out why I couldn't have more than one floppy drive. The disk image I'm using has two nodes for SCSI floppy drives, /dev/fdsk/0 and /dev/fdsk/1. On the real hardware, the '0' was equivalent to the floppy image on the BlueSCSI and the '1' was the Gotek. But with the original code, whichever image I mounted appeared in both. It turned out that the original code was only considering the LUN for each SCSI ID. It was a simple(!) matter of looking at the whole byte of information relating to the SCSI ID. So we ended up with the following mapping:

        SCSI ID 0 - LUN 0 -> Hard disk

        SCSI ID 0 - LUN 2 -> Floppy drive (unix) equivalent to BlueSCSI floppy image

        SCSI ID 1 - LUN 2 -> Floppy drive (unix/keydisk) equivalent to Gotek floppy image

So mounting /dev/fdsk/0 now always mounts the image specified in --unix-floppy while mounting /dev/fdsk/1 mounts the image specified in --keydisk. For ease, I'll probably stick to just using the /dev/fdsk/0 node unless I need to copy files from one floppy to another.

That's 'proper' floppy disks sorted. Next thing. The terminal.

The terminal program on Torch Unix is 'sh'. Not 'bash' or 'csh' or anything modern like that. No siree. This is 1980s style computing i.e. a bit hard and slightly inconvenient. And the 'sh' terminal is just that. I realise it does come from c.1984 but having been using bash for the last twenty years or so, taking a step backwards is a step too far. If that makes sense...

Anyway, a couple of things that are missing from 'sh' are very annoying. These are command history on the cursor keys and auto filename completion on tab. I'll be upfront, I did not manage to get the tab key working (yet). But read on for the command history.

Rather than try re-write and compile a stripped down 'bash' (or similar) I decided to try and do something else, which would be a bit simpler. I would write a wrapper that would pass commands to 'sh' but which would store previously entered text i.e. commands and paste that history into the command line when the up/down arrow keys are pressed.  

The code itself runs and calls 'sh'. It's only 229 lines long and, I have to be honest, I wrote it so long ago (with copious amounts of duck-duck-go searching, stack-exchange browsing and swearing at errors) that I don't remember how I worked out what the heck to do. Documentation appears to be a mythical thing to past me. Perhaps I would make a great agile developer after all.. 

When I compiled it I renamed it be called 'tsh' (Torch sh - see what I did there?). I added an icon to the desktop - a feat in itself with the OpenTop system - and I run that instead of the regular terminal icon. I haven't figured out how to swap the icon from the default 'tool' icon yet, but I will. 😁 And I can definitely tell you what this code does. 

In a nutshell, it adds a command history on the 'sh' terminal. It also allows for switching to root using the new command 'tsu' which redirects the 'su' command through 'tsh'. (You can use 'su' in the 'tsh' terminal if you really want to but it runs the command normally and the ability to press the up arrow for the last command is lost as the 'tsu' version runs through 'tsh'.) And it is surprising how just making that addition suddenly makes the Torch terminal infinitely more pleasant to use. 

 

The OpenDesk desktop with tsh running.

 

There are still limitations to it though. There are only 10 stored lines so if you want to go beyond that then you're out of luck. When a history line is displayed it can't be modified other than by deleting a portion of it from the end i.e. if the command was 'mv verylongfilename1.txt short1.txt' you can't use the left and right arrow keys to move through the text to change the first filename, you'd need to delete the second filename and keep deleting until you reached the character you wanted to change. This isn't really a major issue, and I as keep gushing about, just having the last command available by pressing the up arrow is a massive improvement.

Next thing, the bootup sequence. This is sort of related to the colour palette thing. What should happen when the system boots is that the screen is solid cyan for a few seconds during a memory check. Then it switches to dark blue with cyan text and the caretaker version is shown. Finally, the palette switches to the four regular colours of OpenTop. (There are normally another couple of colour switches during bootup but we'll ignore those for now.)

Before I got my hands on it, the emulator ran so quickly that all of these steps are effectively missed. Occasionally, the Torch logo might appear for a split second. This wouldn't be an issue but there are a couple of key things that happen during the boot. A 'Stop' icon appears. This is broadly similar to pressing 'F10' or 'Del' when a PC boots to interrupt it and allow some action to be taken, typically entering the BIOS settings. On the Torch, clicking the 'Stop' icon gives access to three main options:

 

Some interesting icon designs there..

• O/S allows the user to specify which kernel to boot, usually 'unix'
• Key allows the user to open the key disk and access more utilities
• Go allows the use to continue the boot process

Clicking on 'KEY' gives these even more interesting icons:

Icons. Icons. Icons.

The most important utility here is the 'Disk Toolkit'. It allows for the partitioning of hard disks as well as given more information on the installed drives (or drive images in this case). It works as-is which is something of a miracle in itself. The only thing is that moving the mouse causes all sorts of random garbage to appear in the utility's command line. No mouse here so the SDL support does cause a minor foible. Don't touch that mouse!

 

Disc utility startup screen

 

Partition information 

(note garbage at the option cursor from the mouse!)

 

To keep booting, it's just a case of pressing the floppy disk 'boot' icon. 

One last thing. What time is it? 😁

Given that the emulator runs on a host of some description, it made sense to try and set the clock based on the what time the host says it is. There is one major problem with this. Although the time and date aren't an issue, the Torch OS is not Win2K compliant. As a result, it does not know any year past 1999. As a compromise, we take the time then the date (including year) and simply subtract 28 years so that the days are correct. For this emulator, this is OK.

And it works. Sort of...

 

Code snippet for clock sync from host OS

 

Firstly, the timekeeping is a bit erratic to say the least. I haven't got the clicks quite tuned in correctly just yet so the clock runs fast from the second the emulator boots.

Second, on Windows the time is correct, but on Linux, for some reason, the time is always one hour ahead. 

 

Time, time, time. It's actually 11:32pm. 😆

That'll do for now. (Is that not enough? Are you not entertained?)

Next time, if I can work out what the heck I'm doing, I set up a github page for this and try use git to maintain the code. It may not go well.... 

Clinging on like a Limpet (Board) - Torch Triple X Part 14

The Torch Triple X was working. Then it wasn't. Then it was. Then it wasn't again. 

I've been having some issues with the Torch. This has been a persistent problem for a little while (Future Paul here - looking back it's been an intermittent issue for two years or so!!) and I'm not really sure why. Every so often there is no boot and I get left staring at a pale blue screen. 

Sometimes it gets a bit further and I end up at the dark blue screen with 'CARETAKER1.3' at the top but then it stops with an error trap.

Trap.

Another, older trap.

Sometimes it will get to the Torch logo and I get an error trap. 

Well that's not right...

Sometimes it will start to load OpenTop and then freeze.

Don't panic! Too late..

You get the picture. Reliability is (R)Not Good.

I put this down to the Limpet board. This has been a thorn in the side ever since I managed to break off one of the pins on one of the stupid connectors it uses. I repaired it but that was, I think, the start of all the issues. I have tried multiple things since then to improve the connectors. I've replace the sockets for both of them on the motherboard, I've installed a totally different connector type, I've used multiple turned pin sockets stacked to act as a more stable riser etc etc.

Original Limpet board.

Stupid riser connectors..

After looking at the issue I decided to do something drastic. The original Limpet board is in a bit of a sorry state having had RAM sockets installed, then removed, then re-installed (all to try and solve this bloody fault) so I thought, why not just make a new Limpet board? It's double sided, relatively small and relatively (!) simple. Surely this is the sort of thing one of the PCB manufacturers could make?

Many, many trace repairs...

So that's what I did.

First, I had to create a schematic for the Limpet in Kicad. I have used it before to recreate the schematics of the Torch itself but when I did those I was a bit ham-fisted with the symbols and I wasn't too bothered about getting everything nice and resolved for PCB manufacture. 

I had to do it properly this time.

Fortunately, the majority of what I needed to do was fairly standard and I was already au-fait with a lot of the functions in Ki-cad. All of the chips were standard and in the regular library of symbols, except for the RAM. I had to take a previously defined chip and change it into one of the 'ancient' 505256 DRAM chips. This was a bit finnicky but once I'd done it, it worked - which is a good job as the RAM accounts for most chips on this thing!

Actually creating the schematic took a lot of hours. The first bit was fairly straightforward. Plonk all the components  on to the Ki-cad sheet and put then roughly were they are on the board. Then I took the original board and removed all of the components on it so I could see all the traces.  I was left with the bare PCB. I did notice that once all the components were removed the board has a massive bend in it. This could be why it was, or appeared to be, so unreliable.. With the bare PCB I could visually follow the tracks across the board and use my multimeter ('..in continuity." - StezStix) to verify I'd followed it correctly. 

Then it was a simple case of joining up the pins from the various components as per the tracks on the old board. This resulted in a slightly untidy schematic. After many hours of tweaking and fiddling it finally started to look reasonable. 

Pah. Simple.

I should note that this board also had four bodge wires on it that came from the factory which I also had to take into account when creating the schematic. This was fine for adding to the schematic, but it did raise one question. Should I try and 100% recreate the board as it was, or should I just do it to get a working board? Hmmm. 

Anyway, with the schematic now done it was time to start work on the PCB. This was also relatively straightforward. When you switch to PCB mode from the schematic, Ki-cad automatically dumps all of the components onto the board with all the pins linked as per the schematic but only conceptually. The fun part of this was starting to actually route traces between the components.

To start this I drew out the boundary of the board so that I could then approximately place the components where they would need to go. Then, before I even started drawing in the traces, I measured as closely as I could the positions of the connectors. These are key because there is a limited footprint for the board to fit, and all the connectors had to be in the right place or they wouldn't all er... connect.

All present and (more or less) correct.

So, finally, I managed to start routing the traces. And this took a LOT of hours. The DRAM bit was fairly easy as a lot of the pins connected through to the equivalent pins on chips further up or down the board. There were some very tricky bits too, partly due to space constraints but there was also one instance around the Limpet's LED, where my brain just wouldn't brain properly and it took me far longer than I care to recall to get the tracks correct.. 

And then, once I had done one side full of tracks, I got to flip the view and do the same again for the other side. By this point I had also decided I just wanted a working board, so I incorporated the four bodge wires into the design.

Finally, after nearly two weeks worth of spare time, I had a finished schematic and PCB layout. I printed it out at 100% scale so I could compare it to the original Limpet board. And realised one of the connectors was in the wrong place. Gah!

Top and bottom layers switched on.
Routing is fun...

And, of course, moving the connector altered a lot of the previously carefully routed traces.. Double Gah!

Take 2. This time, the connectors were all aligned with the original board. Phew!

Next step. Pick a PCB manufacturer. I went for JLCPCB as they actually seemed to be significantly cheaper (cheapskate) and had fewer issues with customs charges etc.

Their website was pretty good and considering I was a complete beginner at this I found it pretty straightforward to use. I had exported my design as 'gerber' files as exported from Ki-cad and I uploaded these to the website. A price was given - minimum order quantity of 5 boards - and then the files started processing to check for any 'gotchas'. 

Back Side Gerber

Font Side Gerber

After a few minutes the site came back with some potential pitfalls e.g. pads very close to tracks that could merge during manufacture. None of these looked significant (foreshadowing) so I accepted them and continued to the next step. Confirming the order and paying. I went for the regular shipping since this was only £8 or so. Word on the internet was that this would also avoid potentially overzealous charges from other 'carriers'...

Then it was just a case of sitting back and waiting. I ordered them on 18th May and they arrived on 29th May. So only 11 days, all the way from Singapore. Nice.

New boards left and middle, original right.

The quality of these new boards is astonishing for the price. I paid $8.90 for the five boards and $12.77 in shipping and customs charges making a total of $21.67 which ended up being £16. That's just over £3 per board. I could not even begin to buy the stuff I might need to make a board the old fashioned way for that price. Amazing.

But the big question is, would it work? Before I even started putting components on I did a quick check between ground and Vcc. And guess what. There was a short. A full on, 100% straight short between gnd and Vcc. What. The. Heck.

Well, you remember that warning that JLCPCBs website had highlighted about tracks being very close to pads? Yep. That's exactly what it was. For capacitor C45, the ground track was supposed to go to the first leg of the cap and then bend around underneath the cap and carry on its merry way. Unfortunately, it was too close to the other pad of the cap and so was attached to both sides of the same cap. Worse, the other side of the board at that point had Vcc, hence the short.

A quick 'update' with a craft knife removed the link. (I ended up soldering the required cap directly to the bottom of the board rather than risk trying to use the now sliced pad.)

Minor engineering fix...

Now it was time to install the components. I had bought some new capacitors and some new sockets to fit to the shiny new board. I did re-use a few original components i.e. the two tantalum caps but only because I didn't have any, and the LED as it looked a better quality than the ones I had.. 

Line 'em up.

Socket to 'em.

Lookin' good.

Several more hours involving a soldering iron later, I had the answer as to whether it would work.

No.

Darnit.

Break out the oscilloscope.

I started by focussing on all the links between the RAM. First up the RAS and CAS lines. These all showed a nice and strong repeating pulse, exactly as would be expected. All of the data lines also checked out, or at least they were all at the same value but not really showing any activity. Then I went to the write enable pins.

Oh. 

Bugger.

They were different across the columns of RAM chips but they should all be linked together. What has happened here? I'll tell you what happened. I forgot to add a PCB track to each of the rows of RAM that connected the /WE signals together and that also connected them to the rest of the board. 

DOH.

Fortunately, a simple bodge wire fixed this and gave me the chance to use my recently purchased solder mask and UV light kit to glue it down. You'll also notice from the picture that there are a few capacitors soldered to the bottom. There were only supposed to be two which, as per the original board, were not included. On the original these had been soldered across the legs of the chips on the top (very neatly) but since I added sockets I put them on the bottom (not quite so neatly). It makes no difference really but makes it easier to swap chips quickly.

Ooop, Another engineering fix...

Does it work now?

No. I just get the pale blue screen. Darnit (again).

But after a bit of fettling I managed to get to the dark blue caretaker screen. And then it kept going! All the way to the 'insert key disk' screen - which was because I'd forgotten to plug the SCSI cable back in. 

I did this but when I re-started it, it got stuck at the pale blue screen again. Hmm. Some more fiddling and try again. And this time it got to the Torch logo and crashed. By this point I had realised that there was something wedged under the board, and given the weird nature of the faults both now and previously, I began to wonder..is there some sort of mechanical fault causing the problems?

I wedged a red handled tool under the right hand side of the board and placed a weight on it (my old HP laptop). Then I turned it on. And it booted past the pale blue screen. And it booted past the dark blue screen. And it booted past the torch logo and the box telling me I'd fitted a new battery. In fact, it booted all the way up to the point where it complains about not being shutdown properly (the more things change the more they stay the same..). I carefully maneuvered the mouse and clicked 'X' to clear the window. 

And it kept booting all the way to OpenTop. Yay!

Most importantly, this confirmed two things. First, and most important, the Limpet board recreation works perfectly. Second, and far more problematic, this confirmed that the issues I have been having are almost certainly on the motherboard. *Activate Conflicting Feelings*

A bend in the road...
(I can't look at this any more!)

So, now what?

Well, the issue is clearly mechanical. This must mean that a connection or connections i.e. a trace or plated through hole(s) are broken but are re-connecting when the board has that worrying bend applied.

But the question remains, now what?

At this point, if this was an Amiga A500 or C64 I'd be looking for a different motherboard i.e. just replace it. The broken board would then become a parts board for stripping components for future repairs. But this is just not feasible with the Torch. I know only one other person with a Torch Triple X (excluding any museums out there). They're not exactly what you'd call common.

The options I have are:

1. Do nothing. It was a good run. I managed to get it to work but just call it a day.
2. Find where the breaks are and try and fix them.

Of course, it's option 2 all the way. :)

More next time!

Coming up....

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.