Non booting BBC/B Issue 7 - Continuous beep

[Sniffer]

More info:

So, with the inverter fitted I pressed BREAK, typed MODE 6 and typed in the simple memory test prog, as below. Typed characters appear correctly in mode 6.

Code: Select all

5 MODE 0
10 ?&4000=0
20 A=?&4000
30 IF A=0 THEN GOTO 20
40 PRINT A

This produced nothing but the cursor at the top of the screen. The same when changing to &8000.
Changing 0 to 255 and &4000 to &6000 produced the cursor half way down the screen with the screen corrupted.

[1024MAK]

Default start-up is in MODE 7, the teletext mode. So if there is one or more defective RAM chips, the resulting bit errors will result in the wrong character being displayed.

If you know what should be shown (compare to a normal start-up screen), you can use the table of teletext characters in the manual to work out which bit(s) are wrong.

The other modes are bit-mapped, so the top part of the screen may display correctly, but part, or the rest may not.

Mark

[DutchAcorn]

Mode 0 should give you uncorrupted characters for the top part of the screen.

[Sniffer]

Default start-up is in MODE 7, the teletext mode. So if there is one or more defective RAM chips, the resulting bit errors will result in the wrong character being displayed.

If you know what should be shown (compare to a normal start-up screen), you can use the table of teletext characters in the manual to work out which bit(s) are wrong.

The other modes are bit-mapped, so the top part of the screen may display correctly, but part, or the rest may not.

Mode 0 should give you uncorrupted characters for the top part of the screen.

Thanks for the info guys. I'm now awaiting some ICs and sockets. I've removed IC33 in anticipation. Hopefully tomorrow.

I'm assuming that once I get the beeeeb sorted, I'm gonna need some ram. As mentioned further up the thread, I have some HM48168P-7 chips which seem pin compatible with the installed ram. Anybody know if these would be ok? I can just try when sockets are in I suppose.

[BigEd]

That musical keyboard symptom is new to me. Perhaps the sound chip is being accessed when it shouldn't be. And, with the continuous beep, is not being accessed when it should be.

[1024MAK]

The sound chip (IC18, 76489) is connected to the ‘slow bus’ from the system VIA (IC3) and controlled by the /WE signal (pin 5 on IC18). This control signal also comes from IC3, but via IC32 (74LS259).

As you have already swapped the VIA, it may be either IC32 (74LS259) is faulty, something is shorting to the sound chip’s /WE signal, or the sound chip (IC18) itself is faulty (accepting data regardless of the control input).

By the way, what test gear do you have / have available/ can borrow or pinch?

Mark

[Sniffer]

By the way, what test gear do you have / have available/ can borrow or pinch?

Well I have a Fluke (179) and a logic probe which I can use confidently, I have a Siglent SDS 1052DL which I'm not so proficient with. In fact, I'm not proficient at all with it, but I would like to be

[1024MAK]

Yay!

Some hints and links to guides on using an oscilloscope are here and here

You can either use your logic probe or your ‘scope to trace signals.

The logic probe is good for quick checks/tests to see if you have an out of specification logic level, or to check for activity (normally good) or a ‘stuck’ low / ‘stuck’ high signal.

In a 6502 system like the Beeb, everything to do with the CPU or the display circuitry is tied to a fixed clock (16MHz). This is divided down and a 2MHz signal is used to clock the CPU (except when accessing 1MHz I/O devices, but that’s another story for another day). Every thing the 6502 does is tied to this clock. So it is useful to connect channel 1 to this signal. The 2MHzE is available at IC37 (74LS04) pin 10. Then select the appropriate controls to set the synchronisation to this channel.

Connect the other probe to the signal you are interested in investigating. This way you are more likely to be able to see something useful rather than a blur of an unsynchronised waveform that the ‘scope can’t lock onto (as most computer signals are not simple repetitive waveforms that are ‘scope friendly on their own).

Mark

[Sniffer]

Yay!

Some hints and links to guides on using an oscilloscope are here and here

You can either use your logic probe or your ‘scope to trace signals.

Ok, thanks for the info. If tomorrow I get the bits I'm waiting for I'll start having a play with the probe.

[Sniffer]

The sound chip (IC18, 76489) is connected to the ‘slow bus’ from the system VIA (IC3) and controlled by the /WE signal (pin 5 on IC18). This control signal also comes from IC3, but via IC32 (74LS259).

Ok, got IC 33 back in, still the same situation.

So, in an attempt to check sound, got my (cheapo) probe on IC32 and IC18;
IC32
1->Low, 2->Low, 3->Low, 4->High, 5->Low, 6->Low, 7->Low, 8->Low, 9->Low, 10->Low, 11->Low, 12->Low, 13->High, 14->Pulsing, 15->High, 16->High

IC18
1->Low, 2->Low, 3->Low, 4->Low, 5->High, 6->Low, 7->Nothing, 8->Low, 9->Nothing, 10->High, 11->High, 12->High, 13->High, 14->High**, 15->High, 16->High

**Whilst pin 14 on IC18 indicates high, there was no tone accompanying the led on my probe and I don't know what the means. Never had no tone AND an led indication.

So, I'll take a look at the schematics and see if I can get a clue

[Sniffer]

A little more info.

As mentioned, on startup, the keyboard is unresponsive until break is pressed. It was in this condition that the readings with the logic probe in my previous post were taken.

If I press break and get a responsive keyboard, the readings change slightly. Here are the differences with a responsive keyboard after pressing break;
IC32
1->High, 2->High, 4->Low, 7->High
Pins 3 & 7 pulse on keypresses.

IC18
3->High, 5->Low, 7->High, 10->Low, 11->Low, 12->Low, 13->Low, 15->Low
Pins 1, 2, 3 ,10, 11, 12, 13 & 15 pulse on keypresses.
The change to High on pin 7 is accompanied by a rather gritty tone on the probe as opposed the normal fixed tone for the other pins.

I don't have a replacement for either of these two ICs as yet.

[Sniffer]

Apologies for bombarding you with all this info but it helps me remember what I've done

Anyway, with a good system, testing IC32 I get;

1->High, 2->High, 3->Low, 4->High, 5->High, 6->High, 7->High, 8->Low, 9->Low, 10->High, 11->Low, 12->High, 13->High, 14->Pulsing, 15->High, 16->High

Which is markedly different and implies to me a faulty 74LS259N.

[Kazzie]

That's a very useful set of measurements. I'm afraid I don't have the time to dig through them this evening, but I'll be back to take a look at them tomorrow (if somebody else doesn't beat me to it).

[Kazzie]

Righty-o then...

The 74ls259 (as used by the Beeb for IC32) gives eight one-bit latches that are addressed individually. Here's a pinout:

74ls259 pinout.JPG (9.56 KiB) Viewed 2112 times

The Beeb holds /CLEAR high (inactive), so only the /GATE on pin 14 is relevant. When /GATE is pulled low, the logic value at D (pin 13) is transferred and latched into one of the Q outputs Q0 to Q7 (as selected by the three select bits S0 to S2).

Before pressing break
The fact that pin 14 is pulsing is good, as that means IC31 is working*. So for your first set of measurements, it seems that the system is stuck in the following state:

• S0-S2 (pins 1-3) all low, selecting output Q0 (pin 4). Input D (pin 13) is high, and so is pin 4

So IC32 seems to be doing just what it is being asked to do by the VIA. Q0 is used to control the (active-low) /WRITE-ENABLE input of the 76489 sound chip, so IC32 is effectively being told repeatedly to keep the sound chip doing what it's already doing, and not write new data into it. (The other outputs, Q1-7, are holding whatever value they were latched at previously in the boot sequence.)

The question that comes to mind is why is the machine stuck telling the same thing over and over to the sound chip?

As for IC18, pin 5 (/WE) matches pin 4 on IC32 just fine. Pin 14 is the input for the 4MHz clock, so the high clock rate might have something to do with your probe's unusual behaviour there. (See if pin 6 of IC6 behaves the same: that's the source of the 4MHz clock.)

After pressing break
The select lines of pin 1 and 2 are now high (pin 3 unchanged), meaning that the VIA is controlling latch Q3 (pin 7). This goes to the keyboard, and is the /KB ENABLE line. It makes sense for the system to want to be changing this value repeatedly, every time it checks for a keypress.
You said pin 8 is now high: that's surprising, as pin 8 should be ground! Did you make an error, perhaps? (Are you sure of the other pin numbers?)
Pin 4 being low is wrong: it's connected to the /WE of the sound chip (IC18). When this pin is low, the sound chip (IC18) interprets the values on the slow data bus (pins 1-3, 10-15) as being instructions for generating sound. The /WE line should be high when the VIA is communicating with the keyboard, but because it isn't, the control signals being sent to the keyboard are being tuned into sound.

In summary
IC31 is probably fine, and IC32 seems to be obeying instructions from the system (before pressing break). The measurements after pressing break need double-checking before I could say whether it's faulty or not. In the case that it's working fine, I'm having a think of what could cause the machine to boot after pressing break (as compared to a cold boot), and give incorrect instructions to IC32 along the way.

*There could be some timing issues, but they're unlikely

[Sniffer]

You said pin 8 is now high: that's surprising, as pin 8 should be ground! Did you make an error, perhaps? (Are you sure of the other pin numbers?)

Great info, thank you very much. I need to read over it a few times I think, but I just want to correct myself. You were obviously correct about pin 8 after pressing BREAK, it is pin 7 that goes high, not pin 8. Pin 8 (gnd) remains low. Sorry about that. All other pin info is correct.

[Kazzie]

You said pin 8 is now high: that's surprising, as pin 8 should be ground! Did you make an error, perhaps? (Are you sure of the other pin numbers?)

Great info, thank you very much. I need to read over it a few times I think, but I just want to correct myself. You were obviously correct about pin 8 after pressing BREAK, it is pin 7 that goes high, not pin 8. Pin 8 (gnd) remains low. Sorry about that. All other pin info is correct.

Thanks. Pin 7 going high makes much more sense.

As I understand it, when turned on, your Beeb makes the "usual" loudBeeb endlessly when powered on, and after pressing break, it produces a different beep that warbles as you use the keyboard. Could you confirm for me how the Caps and Shift LEDs behave when you turn the machine on, and then after pressing break? Also, is there any difference if you press Control+break instead of break? I'm trying to relate this behaviour to the code that the Beeb executes when it boots, to try and understand how it could generate your first set of readings.

[Sniffer]

Could you confirm for me how the Caps and Shift LEDs behave when you turn the machine on, and then after pressing break? Also, is there any difference if you press Control+break instead of break?

Sure. On initial power on, no key press response, 'CAPS LOCK', 'SHIFT LOCK' on. On pressing break, no change in led situation but key presses respond.

CTRL BREAK is not accepted at the keyboard and the 'CAPS LOCK' & 'SHIFT LOCK' status remains on.

[BigEd]

About the tuneful keypresses: is the tone always the same for each key, and does it differ between keys? Are there groups of keys which give the same tone?

[Sniffer]

About the tuneful keypresses: is the tone always the same for each key, and does it differ between keys? Are there groups of keys which give the same tone?

I can't see any real pattern other than as well as making a sound of it's own, each key press further distorts the continuous tone that's ongoing.

[BigEd]

Thanks - maybe this will be a clue!

[Kazzie]

Thanks - maybe this will be a clue!

From the measurements of IC32 (74ls259) after pressing break, it's seems to be because the /WE line of the sound chip is left low, instead of being raised high again. The result is that the sound chip is reading instructions in off the slow data bus all the time, even when the data is intended for the keyboard.

[BigEd]

Ah, I see you were well ahead already.

[Sniffer]

I replaced IC32 this morning and had a bit of weirdness then some success. Having replaced the ic, switching on left me in a worse position. I had the continuous beeeeeep and no display. Powered off and then back on, same situation! Did the same for a third time and hey presto, beep, beep and a 16K BBC/B.

No idea why the first two power ups failed but subsequent power ups have all been successful. Fingers crossed. Thanks to everybody for all the help on this so far.

Now I need to sort out the ram problem. I think DutchAcorn suggested IC 62 as the culprit there. I'll run the memory test prog and see if I can confirm. I only currently have HM48168P-7 ram so don't know if that would be ok.

[Sniffer]

So, I still have some noise through the speaker. Very faint background noise on key press and a louder hissing noise in tandem with floppy drive usage.

Anyway, I ran the memory tester (listing at viewtopic.php?f=3&t=14809) with and without the LS04 inverter and in both cases it came back with no failures!!! Very odd as it wont boot at all with S25 North.

Editing to say that when in MODE 0, the memory test does fail at &4000 but does not report any faulty ICs.

[Kazzie]

Hi,

Glad to hear that your Beeb's looking more and more healthy!

With regard to the memory test, memory chips can fail in all sorts of unusual ways, not all of which will be picked up by any particular type-in test.

My Beeb's [url=viewtopic.php?f=3&t=13899&p=183106#p183175=RAM fault[/url] was an issue with the chip's addressing circuit, meaning that writing to address &4000 overwrote &4200 as well. Writing and reading back from any individual address would work, but other locations would get trampled in the meantime.

As well as using the likes of Mode 0 to test things bit-by-bit, If you can see a consistent pattern of errors in the characters that Mode 7 gives at boot, (e.g. bit 2 always high, so characters that should have bit 2 low are replaced) then I'd say that's enough evidence to get the soldering iron out. Do you have an image of how it looks after your recent repairs?

(I don't recognise the HM48168P-7 RAM chip, and can't find anything on it by that part number.)

As for the remaining sound, it's normal for there to be a little bit of noise from a Beeb's speaker during operation: this originates after the IC18 sound chip, near the op-amps of IC17 and IC19 iirc. There is a small modification that can be done to eliminate this noise (at the expense of losing the analog audio input on the 1MHz bus connector) along the lines of fitting an extra resistor to the board, but it's not something I've done myself. I find the subtle change of tone when my Beeb is busy/idle as a useful audio indicator of what it's doing.

[Sniffer]

Glad to hear that your Beeb's looking more and more healthy!

Thank you.

With regard to the memory test, memory chips can fail in all sorts of unusual ways, not all of which will be picked up by any particular type-in test.

I guess you're right on that.

As well as using the likes of Mode 0 to test things bit-by-bit, If you can see a consistent pattern of errors in the characters that Mode 7 gives at boot, (e.g. bit 2 always high, so characters that should have bit 2 low are replaced) then I'd say that's enough evidence to get the soldering iron out. Do you have an image of how it looks after your recent repairs?]

Well the pattern was bit 2 always wrong, i.e. a C for an A, an O for an M, an R for a P etc, so it looked as DutchAcorn suggested like IC62. So, I've pulled that and put in a socket.

I put in a HM48168P-7, switched on and bingo, a working 32K BBC/B. Great stuff.

Thanks to all for helping.

I guess I can live with the small interference from the speaker, though I would like to be rid of it.

[leenew]

Well done
viewtopic.php?f=3&t=6383&p=61457 may help you with your noisy beeb...

Lee

[Sniffer]

Well done
viewtopic.php?f=3&t=6383&p=61457 may help you with your noisy beeb...

Is that topic pertinent to Bs as well as the Master?

[leenew]

Sorry!
Try these: http://www.sprow.co.uk/bbc/doctor.htm#bzzzt
viewtopic.php?f=3&t=9796&p=115986&hilit ... zz#p115986

Lee

[matt_w15]

I realise that this is an old thread, but I thought this may help.....
I have an issue7 B (with econet) that had a continuous tone on power up. Things I tried (before the solution for my particular PCB fault)....none of which made any difference....
Checked the PSU voltages, all good.
Pulled all plugable IC's and cleaned the pins.
S25 jumper to 16k
Replaced/swapped....
IC2 (HD46505SP)
IC1 (6502)
IC69 (R652P)
IC3 (R6522)
IC100/1 (Roms)
Swapped keyboard.

The problem was....(drum roll).... IC51(HN613128PB04), 16K ROM.
Initially I thought it may just be corrosion on the pins as it had really bad oxidation (very dull Grey). But a swap from another working beeb confirmed the problem
Just to save anyone hunting for ages, IC51 is located at the end of the ROM bank (to the left).
I guess I can read a working unit and program a blank eprom to replace it? I guess I will find out
I hope this helps someone!

Regards

Matt