BBC B+ 128K: Fault after warming up.

[stephen_usher]

I've a BBC B+ 128K which when started from cold will run OK for about 30 seconds and then starts to get memory errors. Within a few minutes it won't get through the boot process properly and then the Mode 7 characters on screen scramble.

I've uploaded a couple of videos to YouTube...

Coolish... https://youtu.be/UWS_OcaYFwo
After a few minutes... https://youtu.be/iwNjTq8tOxA

At one point I was able to run a program, a simple count and print, which often got its values corrupted before crashing out usually with no such line on the goto statement.

I've reseated all the ROMS, which are the only socketed chips. None of the chips seem to be getting particularly warm.

I've tried a different power supply and keyboard and there're no changes to the symptoms.

It looks like noise on the data bus.

Any ideas?

[DutchAcorn]

It looks like an issue with the memory addressing. If it is really heat related you can use cooler spray to cool the memory (/addressing related) chips while the computer is on and see where it has effect.

You can also use a can of compressed air spray for this if you use the can upside down.

Btw it can also be the 6502, I have had a few 6502 heat related faults in the past.

[Hopper]

Btw it can also be the 6502, I have had a few 6502 heat related faults in the past.

Defo not going to be a fault with a 6502 processor in a B+ ! No Sir.

[pelago]

Defo not going to be a fault with a 6502 processor in a B+ ! No Sir.

I'm interested in this issue too. Sorry if I'm being dense, but are you being sarcastic?

[Kazzie]

Defo not going to be a fault with a 6502 processor in a B+ ! No Sir.

I'm interested in this issue too. Sorry if I'm being dense, but are you being sarcastic?

He's referencing the fact that the B+ uses a 6512 processor, as opposed to a 6502.

[Kazzie]

I've a BBC B+ 128K which when started from cold will run OK for about 30 seconds and then starts to get memory errors. Within a few minutes it won't get through the boot process properly and then the Mode 7 characters on screen scramble.

I've uploaded a couple of videos to YouTube...

Coolish... https://youtu.be/UWS_OcaYFwo
After a few minutes... https://youtu.be/iwNjTq8tOxA

At one point I was able to run a program, a simple count and print, which often got its values corrupted before crashing out usually with no such line on the goto statement.

I've reseated all the ROMS, which are the only socketed chips. None of the chips seem to be getting particularly warm.

I've tried a different power supply and keyboard and there're no changes to the symptoms.

It looks like noise on the data bus.

Any ideas?

The B+ is fun to debug, with so many chips soldered in.

Do you see any difference in the onset of problems if you leave the case open, as opposed to closed? This would indicate a chip that's susceptible to failing when warm.

On a regular B, I'd suggest removing the System VIA to disable the keyboard (IC3 in a B, IC20 in a B+), but desoldering a 40-pin chip isn't something to do on a whim. But looking at the B+'s diagram, I see that the System VIA has its own dedicated reset circuit on pin 34, using a diode, resistor, and capacitor (D2, R17, and C3).

C3 pulls the reset pin to ground at first, but then the diode and resistor pull the line up to 5V shortly afterward. If you were to fit a low-value resistor in parallel to C3 (say 1k~10k) that would effectively bypass the capacitor and force the reset line low, so the System VIA would be in a constant reset state while the rest of the system boots. If you still see spurious characters being "typed" in, then it's not the fault of the keyboard or VIA.

[DutchAcorn]

My B+ had a shorted C3 when I first got it, but it would not boot with that short.

viewtopic.php?f=3&t=9375&p=113519#p166250

[Kazzie]

My B+ had a shorted C3 when I first got it, but it would not boot with that short.

viewtopic.php?f=3&t=9375&p=113519#p166250

Ah, right. That rather shorts that idea, then.

[1024MAK]

If a chip that has become heat sensitive is suspected, it’s worthwhile getting some freezer spray.

When the symptoms appear, try cooling any chips that you think may be suspects with the freezer spray (try not to spray anything else).

Mark

[stephen_usher]

Freeze spray ordered from RS so should arrive tomorrow. However, the machine, along with a BBC B and Master 128K are going for a little holiday tomorrow evening as someone wants to use them as props in a video so I'll have to do more research when they get back.

[pelago]

However, the machine, along with a BBC B and Master 128K are going for a little holiday tomorrow evening as someone wants to use them as props in a video

That's me!

[daveejhitchins]

However, the machine, along with a BBC B and Master 128K are going for a little holiday tomorrow evening as someone wants to use them as props in a video

That's me!

Oh, come on . . . You can't leave it with a "That's me!" - Details, man - details (Please )

Dave H

[stephen_usher]

Unfortunately I still don't have the freeze spray. RS and the courier say that it was delivered to work last Thursday, as a separate package to the other things I ordered, but the receptionist says that there was only one package she signed for.

Anyway, I've re-ordered but the replacement won't get shipped until the 14th... Maybe I can play at the weekend?

[stephen_usher]

I got an oscilloscope today so I've been having a look at the B+ using that.

On the 6512 D5, D6 and D7 often show this trace as the processor crashes...

That doesn't look a lot like valid data to me. (When the processor halts all the address and data lines go to ~0V.)

[hoglet]

What happens to the SYNC (6512 pin 7) signal when it crashes? I assume this is staying low.

[stephen_usher]

Yes, but very noisey (low voltage). The power supply 5V rail is clean, so it can't be that.

[stephen_usher]

I've been using my 'scope on the memory, on IC64, IC65, IC66 and IC67 DRAMS both Din and Dout have quite a marked saw-tooth 2MHz noise, unlike IC68, IC69, IC70 and IC71.

[stephen_usher]

Looking at the circuit diagram and tracing back the data lines from the RAM they only go to a couple of 74LS chips, one is a set of buffers to the processor memory data lines and the other is a set of flip-flops to interface the Teletext chip, and the video processor.

All the signals the other side of the 74LS chips are clean and they have no clock input which suggests that the 2MHz saw-tooth noise is coming from the video processor.

Of course, the question to be asked now are:

(a) Is the ~2V/2MHz noise likely to be causing the memory corruption and system instability?
(b) Is this noise potentially generated by the vidproc normal?
(c) Is the vidproc generating the noise and if so does that mean that it's faulty?

I'm guessing that this is the same video processor as used in the older BBC Model B, is this correct? If so then I can use a Model B as a reference.

[1024MAK]

Write data to the DRAM only comes from the CPU.

The DRAMs (and other RAM, ROM/EPROM and IO devices) provide read data to the CPU and to the video system (videoproc/teletext chip).

When neither a read or a write is being performed, the data bus is undriven, so any voltage left on the data lines due to residual stray capacitance will decay slowly compared to an activity driven signal.

Note for simplicity of describing the operation, I have not detailed the various buffers etc.

Mark

[1024MAK]

BBC B+ main RAM

IC49 (74LS245) transceiver connects the DRAM and the CPU (IC42). Which direction (read/write) depends on the R/W signal on pin 1 and enable /G being low (pin 19).

IC54 (74LS273) copies (reads) the data from the DRAM to the teletext chip IC59, SAA5050).

The videoproc IC53 also reads the data from the DRAM.

The DRAM chips (IC55, 56, 60, 61, 64, 65, 66 & 67) are controlled by /RAS, /CAS and /W.

/RAS and /CAS are used to strobe the row and column address into the DRAM (two lots of 8 bits of address making a total of 16 bits). Only after both row and column addresses been entered will the DRAM output data (assuming /W is high). A write to the DRAM takes place instead of a read if /W is low. For more/full details see the 4164 DRAM datasheet.

Mark

[stephen_usher]

At last I obtained a freezer spray!

The results are converse to what I would have expected. Basically things get worse if cooled.

Specifically, if I cool the 74LS245N (IC49) then the machine stops working at all until I raise the temperature of the chip. It has no effect on the next door 74LS245.

Given that IC49 is a bi-directional buffer between the CPU data bus and the RAM/Video bus this could cause data corruption if it was going dodgy and would explain the fact that the screen interference stops as soon as the CPU halts.

[1024MAK]

If the symptoms change when you cool a chip, change it!

The equivalent to IC49 in a BBC B often causes problems, especially when the machine warms up.

Silicon semiconductor devices should be good over the 0oC to 100oC range (note this is the temperature of the silicon die, not that of the plastic or ceramic package).

With a defective chip, logic goes out the window! So although sometimes cooling it when it is warm will restore normal-ish operation, it is not the case for some faults.

The other technique is to wait for the board to cool down, then blast any suspect chips with a hairdryer set to maximum heat. But it is difficult to localise the area that gets hot to single chips. If you have a soldering station with a hot gun, it is a bit easier.

Mark

[stephen_usher]

IC49 has now been replaced but the fault persists, though the system is slightly more stable.

From the video corruption I'm wondering if the CPU is writing during the period that the video circuitry is trying to read memory and hence you're getting merged and corrupted data.

I'm guessing that the control line for this comes from IC49's pin 19 which is generated by IC48, a 74LS10. This in turn is controlled by IC40 (74LS20) and the 2MHz clock.

[stephen_usher]

Hmm... Should the video processor pin 3 (CS) always be high?

Could the ULA be partly dead?

[1024MAK]

Pin 3 will only go low when the address decoding circuit for the relevant I/O address on the CPU address lines is present. The rest of the time it is high which is the inactive state.

Remember the Videoproc is a slave device to the CPU in that it is a write only I/O device.

Mark

[stephen_usher]

Something seems to be not generating the signal to prevent the CPU accessing the memory at the same time as the video sub-system.

The voltage on IC40 pin 8 and hence IC48 pin 12 never ever change. IC40 pin 10 goes up and down, pin 9 is always high.

[1024MAK]

IC40 pin 8 should be low unless the CPU is trying to access the main RAM or the Videoproc.

IC48 pin 12 will be high. It will go low if the CPU is trying to access the main RAM or the Videoproc.

Mark

[1024MAK]

IC40 pin 10 is CPU address line A15. It goes low when the CPU tries to access main RAM for any address 0x000 to 0x7FFF.

IC40 pin 9 is /VIDPROC. It is normally high and only goes low when the CPU tries to write settings to the Videoproc.

Mark

[1024MAK]

Can you test IC40 pins 8, 9, 10, 12 and 13 please. If you have a two channel ‘scope (or even better if you have a four channel ‘scope) test each input (pins 9, 10, 12 and 13) while monitoring the output (pin 8 ) with another channel.

Mark

[stephen_usher]

Pin 8 is always high, as are 9, 10 and 13. Pin 12 has pulses.

Oh, and I've noticed that the video processor is getting pretty warm. (It's a VC2069)