(Obligatory Letterkenney reference now complete)
So it’s a long weekend, and thanks for some confluence of leave, for me it was a four day weekend. Such a nice thing occasionally.
Friday I spent mostly working on general chores, but in the evening I thought I’d finally drag out a project to start looking at. Now I know some of this will be my repair skills getting slowly better and better, but I think there was also some luck because, spoiler alert, things went better than I could have imagined.
Microbee 128K
First on the bench was the ‘bee, which has been vexing me for over a month now. It was not showing any signal on the screen.
Having exhausted what could reasonably be tested based on symptoms, and having applied many weird and wonderful fixes, I decided to “get back to basics” and start from one end of the system and work back. I chose to start at the Z80 CPU, and to check all the pins for activity, just to see “what I could see”.
The schematics for this were incredibly useful, insomuch as they laid out all the important signals, and their pin number in a consistent way.
First up, I had to use my “Core Lifter” boards to raise the Core (Ie top board with RAM, ROM and some controllers) up from the Main board (where the CPU and main I/O chipset lives, plus the keyboard)
Setting up the oscilloscope, I started probing down all the “special” pins initially. All the “special” pins are inverted, so active low. Quickly I noticed that while most were held high, or were oscillating, one was being held low, NMI. The Non Maskable Interrupt
OK. that’s not right. That means the machine is being constantly interrupted. It would never get anything done. (NMI is supposed to be pulsed so the CPU knows to go and look for what caused the interrupt.)
Interestingly, I had a suspicion something like this was happening. I thought it might have been the RESET line, but NMI, with hindsight, made more sense.
On the schematics, I traced the NMI line from the CPU across to pin 17 on the connector between boards. Not a problem. I can still see it being held low on the corresponding pin on the core board, so we seem to be getting somewhere.
I removed the “Lifer” boards so I was more easily able to get to the Core board and started following the signals back.
Following the signal on the schematic led me to pin 6 on IC49, a 74HC14 inverter. At the other end of the inverter, I could see the signal was high, so that IC must have been fine (HINT: FORESHADOWING!) so I moved behind that. R12 looked OK and was a weak pullup anyway. IC 41 was a 74LS08 AND gate emitting a high signal. Coming into it was a high signal on pin 5 and a “low” signal on pin 4.
That doesn’t look right. If only one of the pins is high, it should be emitting a low signal.
I get out the desoldering gun (I recently got a new handpiece for this and it makes SUCH a difference!) and quickly had the chip out and straight into my tester where… it passed!
D’oh! Maybe this was one of those cases where the tester isn’t testing properly? I drop in a socket and plonk it back on the board and keep probing around. Something is niggling my backbrain and I can’t work out what it is. I check pins on the next IC back from IC 41, which is another inverter on IC49. I can see a strong low coming into it but… the signal coming out feeding into the AND gate doesn’t look right. It’s riding up way above ground up around 1.5v which is well into the “undefined” area for logic of this type. Maybe here is my problem? I pop it out and whack it in the tester and that inverter fails the test. Whoah. Could this be it?
It was late by this point so I had to wait until the morning before whisking out to the local electronics shop for a replacement. Thankfully they had the component in stock, which was nice.
Getting it home I plugged in the new chip and powered up the ‘bee. Still no signal. D’oh!
I checked the NMI line and it was now behaving itself. I could see activity all over the place on the board… I thought I better eliminate the obvious and tried a different Microbee… which also had no signal. Double D’oh! Fiddling with the video cable and I could see a BASIC prompt picture. Plug in the 128K ‘bee again and I can suddenly see the white block cursor. Excitedly I plugged in the Gotek drive emulator with the right USB stick, powered it up and… IT BOOTED! I was so happy I let out a whoop.
(I also fixed the stupid video cable once and for all. It had got twisted, which had bent a connector, shorting the video signal.)
I did a quick happy dance, and then spent half an hour playing various Microbee games. Finally I screwed the case back on and started contemplating my next thing to fix.
How about something much harder and more vexing?
Acorn Archimedes A440
So I set myself a real challenge this time. This system had been broken for closer to six months at this point, but now I was much more confident about using my oscilloscope and thought it was time to get back “at” it.
On the bench it went and I reviewed where I was up to. It had a repeatable problem where the drive would never be properly seen. It would proclaim “Drive Empty” whether it was a real floppy disk drive or a Gotek drive emulator.
A lot of people on the StarDot forums thought it had to be IC29, A 74HC574 logic chip (It’s a flipflop. It’s been so long since I did logic at Uni I can’t even remember what that means any more. I should go and do some research) that didn’t seem to be getting the right signal on its select line (pin 11).
Before I went down that path, I wanted to test my 1772 Disc controller chip in a “known good” computer, so I stripped down my BBC Master, socketed the 1772 in there and tested the chip from the Archimedes, which, of course, promptly passed all the tests. OK, one issue down.
After confirming I was actually using the scope right, I confirmed that, no, the select line was never being triggered. I looked up the schematic some more and pin 11 on IC 29 conveniently connects to pin 11 on IC31, which is a 74HC138. It’s a demultiplexer. It takes 3 binary pins and, depending on the values, selects one of 8 output pins. One of those pins is what’s connecting to IC 29.
So looking at IC 31 under the scope, I can see lots and lots of activity on the three input pins, so some of those output pins should be doing something and… nope. Nothing. Not a cracker. Could this be another easy fix once I knew the real culprit? Quick! Back to Jaycar to grab a couple of 74HC138s.
Plugging one in and powering up the Archimedes, I access the Gotek drive, which promptly lights up and starts reading. Whoop! More happy dances! I go and give my long-suffering wife a big sloppy kiss, before re-assembling the Archimedes.
The rest of the day is spent resetting the Archimedes back up. I have added back in the HDD Podule and even installed and tested a joystick adapter that plugs into the printer port. (I had built this ages ago and it was while trying to test it that I discovered the problems with the Floppy drives.)
Several games of Pacmania followed. (The Archimedes port is simply a stunning version. Possibly the best port I know of. Fast and buttery smooth)
I’ve also used Arculator (An emulator of Archimedes computers) as a bridge to allow me to write software to “blank” ADF floppy files for use with the Gotek.
Currently I have the Amiga 1000 on the bench. Let’s see if we can get that working too?
Leave a Reply