Date   : Fri, 03 Jun 2011 16:38:00 +0100 (WET-DST)
From   : BBCMICRO@... (Peter Coghlan)
Subject: Model B with video corruption

>
>Pulling the Serial ULA (and ADC, 68B54) finally got rid of most of the screen
> corruption. Except sometimes it comes back as bad as it ever was.
>

The fact that it is not completely cleared means the cause is elsewhere.
The change in behaviour is likely due to different loading on the data bus.

>
>Also discovered the UserVIA is dead, after swapping it for the system one.
>

Don't be surprised if it is found to work after all when the main problem
is cleared up.


>> Does the machine respond to commands?
>
>Yes, except rarely hangs.
>

Then it can be used to help diagnose itself. You can examine values in memory
and check the effect of changing memory.

>
>Vidproc is getting hot though, not a good sign.
>

There are at least two different types of vidproc and at least one of them
routinely runs hot (and is often fitted with a heatsink). I wouldn't worry
about this.

>
>I don't think its the memory itself, noise is rather odd to say the least.
>http://s1092.photobucket.com/albums/i405/station240/bad%20B%20video/
>View from 1 to 5.jpg and that is the order the noise appears in.
>Of note is this is a 20k screen mode, and the top potion is never corrupted.
>By my calculations this is &3000-&3FFF. Something screwy going on with the
addressing.
>

The model B has eight memory chips for 0-&3FFF and another eight for &4000-&7FFF
(one for each bit in each case). There could be a problem with one or more of
the upper set. If you change jumper S25 to the 16K setting, this may cause a
change in the behaviour. I'm not sure which set of chips becomes active in 16K
mode. I vaguely recall that leaving the jumper out altogether may cause the
other 16K to be used? Maybe someone else can comment?

Assuming the pictures relate to mode 0, they suggest one or more bits are
stuck on for varying ranges of addresses. Try:

MODE 0 : VDU 28, 0, 4, 79, 0 : FOR I% = &4000 TO &7FFF : PRINT ~?I%; : NEXT

This sets a text window in the first 4 lines of the screen (to avoid the
corruption) and prints the contents of memory from &4000 to &7FFF in it.

You should get all zeros. If it is not all zeros, there should be an obvious
pattern pointing to the bits in error. 

>
>Also of note, despite the removal of IC15 74LS273, which disconnects the
>teletext chip from the databus, mode 7 isn't dead but rather a mass of noise.
>

The teletext chip may be serialising random junk due to having its inputs
floating. If you plug IC15 back in and check what characters are displayed in
mode 7 when the screen is supposed to be clear, this may give a hint as to
which bit or bits are having problems.

>
>Some sort of faint staticy noise from the speaker.
>

Sounds like the normal background mush on a beeb. Nothing to worry about.

Regards,
Peter Coghlan.