BBC Micro Model B 32K - Help !

[Cyprus66]

I'm grateful for any help in resolving a fault with my vintage BBC Model B computer.

I recently purchased an untested BBC Micro on eBay, hoping to relive the nostalgic days when my father bought one for me in the mid-1980s. I remember saving up around £150, and he kindly paid the rest. It was a big deal for us at the time.

After giving it a good clean—removing the usual dust and paper debris—and having the power supply recapped, I powered it on and was greeted with the familiar “beep-burp” sound. That was a great sign! I quickly hooked it up to my TV via the composite output and was pleased to see the boot screen appear.

However, I noticed something odd: all the characters were in lowercase. I suspect this could be a memory-related issue, but I’m unsure how to go about diagnosing it or what the root cause might be.

Could anyone please shed some light on what steps I should take to troubleshoot and hopefully repair it?

[TonyDuell]

Will it execute commands if you type them in (don't worry -- yet -- that it displays in lower case, but do make sure the CAPS LOCK is on)? If it will, try MODE 0 <return> and see how it displays things now.

The point is that the BBC micro uses Mode 7 at power-on. This is the only mode to use the teletext character generator IC, the other modes are essentially bitmapped graphics modes with the characters generated in software. So if Mode 7 malfunctions and he others are fine, it suggests a problem with the teletext character generator circuitry -- the SAA5050 and associated logic.

[Cyprus66]

In Mode 7, I tried toggling Caps Lock as suggested, but the characters still appear in lower case. However, when I switch to other modes , I can use upper case, although I notice vertical lines appearing on the screen — I’ve attached a few screenshots showing this.

I moved the S25 link on the motherboard to force the machine to use only 16K of RAM (effectively swapping to the other DRAM bank). On reboot in Mode 7, everything looks normal, though of course I'm now limited to using Modes 3 to 7 due to the reduced memory. BASIC programs still run fine in these modes.

Given that switching to the other memory bank resolves the Mode 7 character issue, does this still point to a fault in the Teletext character generator circuitry (SAA5050 and related logic)? Or is it more likely that the original DRAM bank (Bank 0) has a fault that's corrupting screen memory or character handling?

Any advice or thoughts appreciated!

[TonyDuell]

This soulds like a DRAM error in the upper bank of memory. The vertical lines in modes other than 7 suggest this too.

In mode 7, the screen memory stores the ASCII code of the character to be displayed, so if bit 5 is stuck high, everything will appear in lower case. In the other modes the screen memory stores the dot patterns of the characters, so the suck bit corresponds to the vertical lines in foreground colour.

My guess would be that one of the 4816 RAMs has failed. I think the appropriate one is IC58 on the circuit diagram I've looked at but this might depend on the 'issue number'

[Dave Moll]

Incidentally, do other characters appear correctly? The lower case syndrome implies to me that the bit that differentiates between case is stuck at one setting - which will also affect other characters. I'm away from home at present, so can't look up details.

Could the problem in other modes indicate corruption of display memory?

[julie_m]

I can see from the MODE 1 picture (fully bitmapped, using memory from &3000 - &7FFF) that there is a bit or two sticking "on" in the upper 16KB of RAM (&4000 - &7FFF). From the weirdness in MODE 7 (character mapped, so using only &7C00 - &7FFF) the stuck bit must be bit 5 (&20, which is set in lower-case characters and most punctuation marks and cleared in upper-case characters).

Note the Beeb's slightly unusual three-way multiplexing of the DRAM addresses! The memory is accessed alternately by the CPU and one or other display subsystem (hi-res or Teletext). If the display corruption is present in both hi-res and Teletext modes, that exonerates the multiplexing and points towards a bad RAM chip.

Try

MODE 1
PRINT ?&3FFF,?&4000

Which will switch to (bit-mapped, existing in memory spanning the good and bad areas) MODE 1 and display the values in locations &3FFF (top of good memory) and &4000 (bottom of bad memory). (The ? operator reads or writes a byte in memory; it's Acorn's replacement for PEEK and POKE. Hex numbers need an "and" prefix, and digits that are letters have to be in capitals.) I think you will see 0 and 32. Try other addresses. If you try writing in values with something like

?&3000=255

you will be able to set and clear pixels on screen (screen memory in this mode is &3000 - &7FFF).

[ortek_service]

I've not seen this issue before on the many Beeb's I've used / got. But partial (D)RAM failure in the screen-memory area does seem most-likely (Although the single-rail 4816 DRAM's in the Beeb are usually very-reliable compared to the more often encountered 3-rail 4116;s).

As the Beeb does seem to basically function, program-wise, then it should be quite simple to type in a small BASIC program loop to go through the memory and test it - Assuming you don't have a Diagnostic utility program on (EP)ROM / Disk etc.
Changing to MODE 7 and then just setting all bits low (Byte=0) and then high (Byte=255) in each Byte location of the area from just above 'PAGE' (to not corrupt the program), to the top of RAM (&7FFF)
- The display will get corrupted a bit during test, but program could clear the screen afterwards before reporting success / failure at end end .

[julie_m]

PAGE (normally at &1900 on a disc system, &E00 on a tape system and on a Master) is the beginning of the BASIC program; TOP is the end. Variables mostly build up above TOP, but A% to Z% have their own special place where they mostly persist.

[ortek_service]

I'd forgotten about 'TOP', but you'd still need to allow for variables above that unless using the special A-Z% ones.
Or maybe use 'LOMEM' & 'HIMEM', as detailed here: https://beebwiki.mdfs.net/Extra_memory_for_BASIC_programs

IIRC, if the press Ctrl + T +<Break> (Or maybe type *TAPE), then you can kind of deactivate any DFS/NFS and do 'PAGE=&E00', to allow more of the memory to be tested more-easily from BASIC.
Although, if really keen you could write some machine code with BASIC's built-in assembler, and pinch a bit of normally reserved space below PAGE to locate the assembly-code and run it from (so no longer need BASIC program, although then would make assembly-code more complex to output messages to OS calls). Although ideally this would be stored to some added Sideways-RAM, allowing all of the RAM to be tested (Maybe apart from the CPU stack & zero-page, without some care in coding to avoid that).

It's rare to see any of the DRAM IC's socketed in Beebs - And only the upper 16K in those that were originally a Model A. But if any are, then could try swapping them around a bit, to see if fault changes.

[Cyprus66]

@ Julie M , thank you for the pragmatic approach , it looks like a Bad RAM chip , having tried the code:
MODE 1
PRINT ?&3FFF,?&4000" , outputs 0 and 32.

In addition I tried writing in values with :

?&4000=255
?&7FFF =255

this set pixels on screen between the range where there is a bit or two sticking "on" in the upper 16KB of RAM (&4000 - &7FFF)., known as Bank 1 on the BBC Micro Model B.

My Beeb's motherboard is: Issue 4, PCB 203-000 (1982), and all my DRAM ICs are HM4816AP-11.

From what I understand, Bank 1 uses IC53 to IC60, with each chip handling one data bit per byte. Based on the resources I’ve read, if I’m seeing one or two stuck bits in the &4000–&7FFF range, then the fault likely lies in one or more of IC53 (D0) to IC60 (D7) — depending on which bits are stuck.

If the stuck bit is bit 5, then the likely suspect is IC58.

Looks like I need to source some replacement DRAMs — either HM4816AP-11 or HM4816AP-7 should be fine, as I understand both are compatible?

[ortek_service]

Good to hear you have found a possible cause of this issue.
Although it may still be a good idea to do a more-thorough RAM-test, just in case there's any other faulty memory-locations lurking in other IC's

It terms of suitable replacements, the Beeb is a little unusual in that the 2MHz 6502 and the Video area interleaved in accessing the DRAM's.
- So this needs to be twice as fast as would be required for access by just one of these systems.
I would have thought 120ns (-12) would have been OK, and maybe 150ns (-15) or even 200ns (-20). But if they originally used -11 (110ns? which is unusual, so 2nd character may be a letter and they are actually -1 for 100ns?) then it may be safest to use the same or faster eg 100ns (-10) or 70ns (-70) etc, as there are suggestions that 100ns or faster is required.

And and xx4816 or other pinout-compatible equivalent single rail 16k x 1bit DRAM IC should be OK, with the right speed.
- Although it seems Hitachi were the main manufacturer of 4816's.

In case you haven't seen them, there are some discussions about Beeb RAM faults & DRAM IC's here: https://stardot.org.uk/forums/viewtopic.php?t=21251

And here (where there are mentions of people who are selling suitable 4816 IC's): https://stardot.org.uk/forums/viewtopic.php?t=27018

[Cyprus66]

Thanks for the links!
I've managed to order a batch of HM4816AP-7 DRAM chips via eBay, along with enough 16-pin DIL sockets to replace a full 16KB bank if needed.

For this specific issue, I’ll just be targeting IC58, as it looks like bit 5 is stuck in the upper 16KB RAM (&4000–&7FFF), which maps to Bank 1 on my Issue 4 BBC Micro (PCB 203-000).

Now I just need to plan the replacement.

It’s been quite a few years since I last worked on DRAM repairs, so I'd really appreciate any advice on desoldering and removing the faulty IC, and soldering in the socket and new DRAM.

I’ve got the following tools ready:

Temperature-controlled soldering iron
Desoldering pump
Solder sucker
Flux
antistatic mat
etc..

My main concern is avoiding damage to the motherboard tracks or pads, especially given the age of the Beeb.

Any best practices, gotchas, or tips to make the process safer and smoother would be very welcome!

[SiriusHardware]

If this is not something you do very often, don't try to get the suspect IC out in one piece, especially on a double sided PCB such as this with solder pads and tracks on both sides because you will run the risk of overheating or pulling off tracks or pads which, once damaged, are never the same again even if you can effect a working repair.

If your main concern is to preserve the PCB and do as little damage to it as possible then our usual advice is to snip the suspect IC's pins off as close to the chip body as possible and then for each of the now free standing pins, one at a time, melt the solder and lift the pin out from the top side of the PCB with fine pointed tweezers.

Once you've extracted all of the pins individually, the through-holes will still be full of solder which you then clear using a soldering iron and a hand desoldering pump or ideally an electric pump assisted desoldering iron.

With all of the holes clear, fit a socket and fit the replacement IC.

[TonyDuell]

Originally Posted by SiriusHardware

Once you've extracted all of the pins individually, the through-holes will still be full of solder which you then clear using a soldering iron and a hand desoldering pump or ideally an electric pump assisted desoldering iron.

If you are using a separate soldering iron and solder sucker (as I do) then I've found it best to hold the board vertically, melt the solder with the iron on the non-component side and apply the sucker to the component side. The holes will come clear.

If a hole doesn't clear, melt a little solder into it (as if you were soldering to the board) then try again.

[Cyprus66]

@SiriusHardware and @TonyDuell – thank you both for the informative advice, which I’ll definitely be putting to good use!

I’ve decided to go with the "chip butchering" method first ? to reduce the risk of damaging the PCB, especially since this isn’t something I don't do very often.

[ortek_service]

In order to minimise potential damage to the board, sometimes desolder-braid is better to use than a desolder pump (especially if this has a tendency to 'recoil' and jump a bit which the suddenly movement can sometimes damage pads & fine tracks - with not solder-resisted sides / older PCB's seemingly more-delicate than most current (usually fully solder-resisted) ones from China etc.)

But it is best to use as small a width of desolder-braid as possible (Often size '00', as I guess they'd already made a size 1 then 0).
The better desolder braid (eg 'Soder Wick' or Multicore-Loctite) tends to already come with good flux in it (Unlike old stuff, in particular the Red RS reels). But if you do have some good liquid flux designed for use on PCB's, then adding a bit of that often helps to avoid the braid sticking to pads. And also may avoid having to add fresh solder, just to get some flux on joints.

The Beeb's PCB is normally fairly good quality for PCB's back then, So I've not normally had too many problems removing IC's / Sockets intact. Although occasionally the odd via / track has got damaged, but it's often possible to make a fairly neat repair that's not very noticeable, using very fine solid-core wire (aka wire-wrap / 'bodge'-wire) through the via / wrapped around the pin of a socket and the wire then following the original route of the track (sometimes using green-coloured insulated wire, to match the resist). This tends to look much better than an insulated wire-link of a different colour that just loops a bit going to a more-distant point, not following original track routing.

[SiriusHardware]

I’ve decided to go with the "chip butchering" method first

It's always going to seem like a negative move to destroy a 40-year old chip which might not be faulty but the trade-off is, spend a few pounds on a replacement IC rather than having to replace a more or less irreplaceable PCB. It's a no-brainer.

It sounds to me like you have reasonable grounds to suspect that that particular IC really is faulty.

[Cyprus66]

Finally found some time today to tackle the RAM fault on my BBC Micro (Issue 4, PCB 203-000).

Following earlier advice, I carefully removed the motherboard and set it up on my workbench. I took my time with the process — cut out the suspected faulty DRAM (IC58), desoldered the remaining legs, cleared the PCB holes, and fitted a known-good 70ns replacement into a 16-pin DIL socket.

After reassembling the Beeb and powering it up, I’m happy to report that the lowercase character issue is now resolved — so that particular fault is fixed!

While I was inside, I also took the opportunity to modify the S39 link by bridging it to combine the luminance and chrominance signals. This gives me a colour composite video output from the BNC socket, which I’ve connected to a composite-to-HDMI converter, outputting nicely to a Dell LCD monitor. I tested it using a small BASIC program to cycle through all 16 colours in Mode 2, and it worked very well.

However, during further testing I noticed a new issue:

In Modes 4 and 6, there are random white dots that fluctuate about once a second — possibly sparkle noise?
In Mode 3, I’m seeing faint raster-like lines.
Other modes seem mostly okay, but these symptoms are clearly video-related.
I’ve checked the power supply rails: +5V, -5V, and +12V are all within tolerance.

After a bit of deep-dive prompting with ChatGPT and reviewing some technical resources, the suggestion is that I may now have a faulty DRAM at bit 0 in Video RAM, which on my Issue 4 board corresponds to IC55. It seems that bit 0 is intermittently flipping between 0 and 1 — possibly unstable or noisy.

So before I dive into another 1–2 hour DRAM swap — does anyone have any further insight?
Could this still be DRAM, or might something else be introducing noise into bit 0 of video memory?
Has anyone seen this kind of intermittent sparkle or raster artefact before, particularly tied to a specific DRAM bit?
Any suggestions or confirmation would be hugely appreciated before I commit to replacing IC55 next.

[Mark1960]

I wouldn’t expect dram to cause raster lines. It sounds more like the output level is not correctly matched to the hdmi adapter which could also explain the random dots.

[SiriusHardware]

Yes, rule out the possibility that the HDMI conversion process is producing artefacts which are not actually present on the composite signal coming out of the machine.

Most TVs still have a composite / AV input on the side panel although it tends to be a 4-pole 3.5mm jack, into which you have to plug a lead which breaks the connections out into 3 RCA / Phono sockets. A slightly older TV will still have yellow, red and white RCA / Phono 'AV' inputs, the yellow socket being the composite video input, red and white being the audio inputs.

Also, the majority of TVs still have analogue tuners built in, so try connecting the modulator output to a suitable TV via an RF lead and tuning it in - admittedly that is the poorest (quality) connection of all but it should show you whether these glitches are, or are not, really there.

Timbucus had a similar problem with his Softy 2 going into an LCD flatscreen, graphical artefacts which were not there when the unit was connected to a CRT analogue TV.