Tynemouth Software: BBC Micro Issue 3 Model B Repair

Continuing my look through the series of BBC Computers from Acorn, we have the big brother of last week's BBC Model A, the BBC Model B. The one in the picture below is not the one we are repairing today (I couldn't find the 'before' photo of that), but you can see it's got most of the chips and connectors that were missing in the model A, a full compliment of RAM and the normal arrangement of ROMs. This is essentially the same machine as the model A, but with more of the board populated.

The first thing to say is that apart from those early machines with the black linear power supplies, all the BBCs up to the B+ have the same power supply, and as these are all getting on for nearly 40 years old, they are all suffering the same problem. That is the Rifa brand X class mains filter capacitors. These things dry up over time and have a tendency to go bang shortly after being powered on for the first time after 30 years in the loft.

There are more details in a previous blog post on BBC Micro Power supply repair, but I will just show a few photos from this one, as it must have put on quite a show when it went.

You can just see the X class capacitor in front of the transistor on the heatsink.

I've not seen one this graphic before, lovely splatter pattern on the transistor.

There are two X class capacitors, a 100nF and a 10nF. The smaller 10nF capacitor here is cracked if you look closely. So far it remains intact, but it is ready to go at any time. Do not trust them, they will eventually go. They all go in the end, get them changed before you even plug it in. Do not wait until the Grim Rifa visits your BBC (do you see what I did there?)

I don't normally need to remove the common mode choke, but in this case, the capacitor was wedged in place where it had exploded.

Ooh, Nasty!

That's those two replaced with modern X2 class capacitors (X2 is a higher voltage rating that the original X class ones), and the transistor cleared up, but whatever came out of the caps seems to have corroded the can.

I usually replace C9 as well, as this has can cause problems with the power supply starting up. These units are a pain to take apart, so may as well change that at the same time for a good quality 105°C rated low ESR one.

With the PSU back together, it's safe to plug in the board. This one is doing the usual black screen, constant tone and not booting. The reset pulse was there, the clock was there, but the NMI line was stuck low. This will stop the CPU doing anything useful. I had thought it might have been caused by faulty 6522 VIAs (forgetting they were wired to IRQ rather than NMI).

To test this, I removed those and it was still stuck low (since they don't use the NMI pin - doh!). As with machines like that, the board under the chips is often cleaner than the exposed areas, but I noticed the section under the disk drive controller was clear, even though that had been empty when I started. (this is a photo of a different board, the ones from the actual board were clear to the eye, but the photos didn't come out very well. This is a much dirtier board, so you can see the clean space under the 40 pin sockets, and the dust around and under the 28 pin sockets to the left).

It appears that someone has removed a disk drive controller upgrade in the not too distant past. But it hasn't been full removed, there are still some chips in sockets that would have been part of the upgrade. I think the NMI is being held low as part of this, the interrupt pin on the disk controller is floating now that the chip (or more likely a 1770 board) has been removed.

IC27 controls the NMI line, it is a quad 2 input NAND gate with open collector outputs, two of the gates drive the NMI, one from the disk controller, one from the econet, with the outputs in parallel as they are also open collector, and a pullup resistor to pull it high when nothing is pulling it low. I checked the chip, and all the outputs were low, even those with some inputs low, so it was faulty and I installed a replacement. Running with floating inputs may be the cause of it's failure, or it may have failed earlier. It's other outputs form part of the disk controller, so that wouldn't have been working, so may be why it was removed?

With the replacement fitted, there was still a problem. Checking the schematic, link S9 should be fitted when there is no disk controller installed. This pulls the input of the gate high, so it shouldn't trigger NMI. However, it looks like there was a mistake on the early boards that wasn't fixed until issue 4. Rather than pulling the input to the NAND gate low (which would make the output high as desired), it is connected to 5V, so actually activates the gate and pulls NMI on all the time.

There are instructions in the service manual which gives an option to cut the track and wire this to a different ground point, but for simplicity, I decided to just lift the output pin, so it would never pull NMI low. It was now progressing. The first beep stopped, but the screen didn't show anything and the second beep didn't come.

With a ROM/RAM board installed, I was able to get it to boot. Mode 7 looked clear, but changing to mode 0 showed some RAM faults.

The ROM/RAM board was providing the CPU with it's own RAM for zero page and stack etc., so it could boot, but the onboard RAM was still being used to drive the display. This is quite handy for finding RAM faults, as it would normally not be able to boot. But with the ROM/RAM board running, any faults in the top 20K or so of RAM that the bitmapped mode 0 uses will be visible. There is a line about quarter of the way down the screen where it switches from the lower 16K to the upper 16K, so you often see a clear transition from good RAM to bad or vice versa.

You can make a little widget that plugs into the pins for jumper S25. This normally selects 16K or 32K mode, but by inverting the signal from the top pad and feeding it to the middle, you end up swapping the RAM banks around, which is quite handy in those situations. For reference, the bottom pin of S25 is ground, so that lines up nicely with pins 5,6 and 7 of a 74LS04, and just needs a wire from pin 14 to any convenient 5V pickup point. The other pins are bent up out of the way.

Here, both halves were reading bad. Checking with the scope confirmed that bit 7 was the problem. There are two chips on bit 7, IC60 and IC68, one on each bank. Swapping around the banks pointed to IC60 being the problem, as it's output was about 2V (always a bad sign) when enabled. Replacing that got us a clear mode 0 screen, but it didn't last long.

I typed in a simple RAM test program that should detect problems. That ran, but didn't detect any errors. It's difficult to describe, but it was testing writing a value to address A and then reading it back. That normally picks up errors. But what was happening here was writing to address A was also causing the value at address B to change.

Here the white block is progressing across the screen writing 0xFF to each byte. I have stopped it at the point where it has started to affect RAM further down the screen.

Through a bit of trial and error, I found the point this started, and modified the program to just write to a short section of RAM, and then test the rest to see which bits were not zero. That came out with 128 as the bad value, so it was bit 7 again, but this time the other chip on D7, IC68.

With both chips replaced, the system was booting and I was able to remove the ROM/RAM board and get it back to a fully working system.

There was no disk controller installed, so an ideal opportunity to fit one of the new SD2BBC SD card drives from The Future Was 8 bit. There are many SD card drive options for the BBC micro, most of which stem back to MMBeeb, which was a very simple implementation with a few components to connect a MMC card to the user port. The MMC card was an SPI controlled memory card that SD is sort of backwardly compatible with. SD adds more and more high speeds modes and is less and less concerned with this backward compatibility, particularly with micro SD cards, which is why we stick with full size SD cards where possible.

The design has been refined over the years by many people, this is my take on the idea, using experience from the SD2IEC drives that TFW8b produces. The design of the power circuitry and interface to the SD card comes from that. There is a level shifter to buffer the signals to protect the BBC user port, and to ensure the SD card gets the right voltages.

That is housed in a variation of the SD2IEC case, no buttons are required, just LEDs for power and activity which are visible through the lid. You can sit it beside the BBC, or tuck it underneath the case.

All that is required inside the machine is a ROM fitted to one of the spare ROM sockets. There are a few options available to drive a user port SD card, I'm using Smart SPI by Duikkie, which is the version that will be shipping with the SD2BBC.

That machine now boots up as normal, and you can access the first disk in the BEEB,MMB archive on the SD card. Normal DFS commands can be used, *. and so on, or use shift+break if you have a bootable disk image selected.

There are various archives available online preloaded with most of the BBC software catalogue, complete with a neat menu, so all you have to do is shift+break, browse to you title of choice and it will run.

Loading is quite fast, a few brief flashes of the red LED and you're away. As usual, I go straight to Repton.

(the above screenshots are black and white as I get a better picture from the monochrome monitor output, when the colour signal is added, it's all a bit fuzzy)

The final thing to fix was the 'ash tray', the section of the keyboard that was designed to take the expansion cartridges for the speech system that hardly ever got installed. More often than not, these get pushed through.