Date : Sun, 14 Aug 2011 16:49:46 +0100 (WET-DST)
From : BBCMICRO@... (Peter Coghlan)
Subject: Advice on restoring a dead Beeb?
>
>> I thought there was always a VDU7 beep at power on as this is part of
>> the "BBC Computer 32K" string being displayed?
>
>I meant optional as in the sense of it not being a *required* part of
>the reset sequence (resetting after power-up without holding Ctrl, for
>instance).
>
Perhaps Chris could clarify on whether by "reset" he means powering up
or pressing break?
>
>I wonder if there is *any* possibility of a power-up that omits the
>second beep? Auto-boot for example?
>
>
>Thought: Does your keyboard have any links made in the location (usually
>bottom right near the end of the space bar). Maybe it is hanging waiting
>for a disc drive to spin up? [though there ought to be something
>on-screen...]
>
I don't want to go fitting keyboard links right now but I've just
tried holding down shift and powering on. This results in the following:
"BBC Computer 32K", the VDU7 beep and "Acorn DFS" followed by a hang
while the machine attempts to access a floppy drive that is not
connected.
(If the keyboard link in question is made, I think holding down shift
while powering on or pressing break will reverse its effect.)
Hopefully Chris will get back to us and say what is on the screen as
this might help a lot to nail down the problem.
>
>If it is a mask programmed ROM type HN613128 and (C)Acorn, it is 99%
>going to be MOS 1.2.
>
I don't think we have been told what is written on it, nor whether it
is definately a ROM and not an EPROM.
>
>> everything is connected in parallel to the data bus, almost anything
>> could be the source of the problem, whether it is accessed or not.
>
>Take the CPU chip out, you'll see the difference.
>
The problem is that if something is loading the data bus more than it
should, taking out or changing anything can affect the symptoms while
not necessarily being responsible for the problem.
I had a faulty beeb which semi-randomly experienced screen corruption,
later hanging as it warmed up and eventually, hanging at power up.
Removing various non-essentials appeared to clear the symptoms for a while
casting suspicion on the items removed but the symptoms quickly returned.
At the same time, it was random enough that it was very difficult to be
sure which actions affected the problem and which did not.
After a lot of grief, I found the problem was due to a faulty 74LS139
(IC30) which was not driving one of the paged ROM select lines high
properly. Over time, it drifted low and the ROM in question became
partially selected all the time, causing a conflict on the data bus.
(I further confused the issue by sticking an oscilloscope probe into
pin 20 on the ROM socket, causing damage to the socket pin and making
it fail to make contact when I put the ROM back in the socket, causing
the fault to appear not to have been fixed after I replaced the 74LS139...)
>
>By the time we turn on the keyboard LED, we've zeroed and counted
>memory. It isn't a random behaviour, the LED is set from an addressable
>latch, which ought to default to "all off" at power up.
>
The addressable latch might default to "all off" or it might not. I don't
know much about it and I don't have a data sheet for it. Its reset pin is
held high. Maybe that is enough to make it reset at power on, maybe not.
Chris seems to suggest the keyboard LEDs are not behaving entirely
consistently so I think it's best not to assume too much from them.
My point from the above repair story is that despite our best attempts
to take a logical approach to finding the problem, sometimes the problem
is more devious than we give it credit for and we should not assume
any part is fault free without good, hard evidence.
>
>Yes, I believe that was for development when MOS zero-point-zero was in
>a bunch of 8K EPROMs.
>
>Not entirely certain why this option would be continued into production
>hardware. I guess it is one of the many little quirks of the BBC (like
>why didn't composite video output colour in the first place?).
>
I've no idea why the ROM option continued to be offered in later issues
of the model B. However, I believe the reason colour was not offered by
default on the composite video output is because the composite video
output was intended for a high resolution, high quality monochrome
monitor, the colour encoder in the beeb is a little cheap and cheerful
and the inclusion of its output with the monocrome signal can cause
significant reduction in quality on a decent monochrome monitor due
to unwanted patterning. I do think it would have been nicer to provide
a PCB mounting switch or at least a pair of jumper pins instead of
a pair of solder pads to enable colour output though.
>
>It might be useful to grab a copy of the annotated MOS disassembly from:
> http://bbc.nvg.org/doc/OS-disasm.zip
>
Yes indeed but I would like to know what is on the screen and have
some clarification on some other points like what exactly the keyboard
LEDs are doing before putting too much effort into figuring out exactly
how far we are getting into the OS.
>
>It is a shame the original poster "reseated" the various things. I'd
>have thought powering up first would have been a good idea, and only
>mess around inside if it is non-functional.
>[caveat: well, the very first thing is to give it a gentle shake while
>rotating it to check nothing got in, and nothing (video ULA heatsink?)
>has fallen off]
>
Yes. On the other hand, it was a good move to check the power supply
voltages were correct. Some classic computer enthusiasts even advocate
disconnecting the power supply and checking it connected to a dummy
load only before attempting to power on the logic. This is in case the
voltages are high and would damage the electronics. However, I have
never come across this problem in the case of the beeb and beebs are
neither particularly rare nor valuable so I would not normally suggest
going to that much trouble to test a beeb power supply.
Regards,
Peter Coghlan.