Display Problems

discuss both original and modern hardware for the bbc micro/electron
Post Reply
User avatar
hilldweller
Posts: 4
Joined: Fri May 16, 2008 12:35 pm
Location: Belper, UK
Contact:

Display Problems

Post by hilldweller »

Balls.

Having just connected my donated BBC-B, there seems to be an odd display problem: The characters seem to be slightly garbled in the default mode, if I change to another mode then the characters are ok but there are other random strange things happening (like ghosting of the image).

I suspect a video output problem, as all my BASIC commands are executed even though the output may not match what I type.

Instead of the usual BLERP BLEEP! when switched on, the beeb does more of a BL-BLEEP BLEEP! And this is the screen I'm presented with:

Code: Select all

BBC Goiputer 32K

Ackrj DFS
                                      $$   $$
BASIC
                                          $$
>$

                               $$
Now, bearing in mind this has been in a shed for a couple of years I'm wondering if it's just a dry joint on one of the chips.

Anyone have any suggestions where I might start to resolder (or bend the main board!)?

Thanks

J.
User avatar
sorvad
Posts: 2180
Joined: Wed Aug 24, 2005 1:13 pm
Location: Back of beyond
Contact:

Post by sorvad »

Troubleshooting the board can be an art form in itself. There is a guide for repairers out there somewhere, stating what items to check for certain faults.

From what your saying it looks like an issue with the teletext display circuitry. So that's a start area (the main chip itself for a start). If your still struggling there are users on the mailing list (who don't frequent this forum) who are more hardware based than software. Might be worth dropping a post that way. Certainly the issue of mode 7 displays showing this sort of error has been discussed previously.
User avatar
Winston
Posts: 47
Joined: Tue Apr 01, 2008 3:24 pm
Location: Devil's Island, Hell
Contact:

Post by Winston »

Memory could also be a problem, especially if you get other strange things happening in different modes.

It might be worth lashing up a simple memory test program that outputs its results via the serial port.
User avatar
MartinB
Posts: 5362
Joined: Mon Mar 31, 2008 10:04 pm
Location: Obscurity
Contact:

Post by MartinB »

I know there are 1001 different memory testers out there but here's one I wrote for quick first-look testing when there's obvious display symptoms. It tests the whole of user ram from &E00 to &7FFF and by running it from a low (normally illegal) PAGE of &900, it will work fine on tape and disc systems. By using &55 and &AA as the test patterns it will find stuck bits and cross-talk errors and because it creates a visual mode-specific 'test pattern' it also shows cross-chip addressing faults and display circuitry anomalies.

Type it in and save it as per any normal BASIC program. To use, press <Break>, set any screen mode with MODEn <cr>, set PAGE=&900 <cr> and CHAIN"MTEST" <cr> (or whatever name you've saved it under.) The given screen should be completely black during the test apart from the 'twinkling' activity marker in the top left corner until the screen memory for the selected Mode is tested. Then, a pattern will slowly fill the screen from top left to bottom right and there should be no visual deviations from this progressive fill. The pattern will vary according to Mode but will always be constant for that Mode. In the case of Mode7, there will (should) be nothing until the last few seconds when the screen will fill with 'U's. For some modes, you will see that your monitor gets a good resolution and EHT test too! The complete test takes about two minutes.

If a location fails, the program will simply stop and print the hex memory location where the error occurred. If all locations pass, you will just finsh with 'OK'. This type of program specifically tests the CPU<>Memory chain and if it passes but you see random characters, holes or pattern shifts then this points the finger at the display circuitry and thus halves the diagnostic process.

10CLS:VDU23;8202;0;0;0;
20M%=&E00:X%=&8000:E%=FALSE
30I%=1:A%=&AA:V%=&55:S%=42:C%=13
40REPEAT
50?M%=A%:IF?M%<>A% E%=TRUE
60?M%=V%:IF?M%<>V% E%=TRUE
70PRINTCHR$((M%ANDI%)+S%);CHR$(C%);:M%=M%+I%
80UNTIL M%=X% OR E%
90IFE% PRINT~M%-1;ELSEPRINT"OK";


Don't forget though, after saving, use as follows :

MODEn <cr>
PAGE=&900 <cr>
CH."MTEST" <cr>


Good luck!

Martin
Last edited by MartinB on Mon Jul 11, 2011 9:33 pm, edited 1 time in total.
User avatar
hilldweller
Posts: 4
Joined: Fri May 16, 2008 12:35 pm
Location: Belper, UK
Contact:

Post by hilldweller »

Wow I wasn't expecting all that!

Thanks guys, Martin I'll try your program as soon as I get time to set the thing up again :)
User avatar
Winston
Posts: 47
Joined: Tue Apr 01, 2008 3:24 pm
Location: Devil's Island, Hell
Contact:

Post by Winston »

There's all sorts of odd faults you can get with memory (I wrote a ROM based tester for the 48k Speccy). I don't remember offhand how the BBC Micro's memory is organized (presumably 4 bit chips, it's unusual to see 8 bit DRAMs in 80s personal computers). The 48K Spectrum uses 1 bit chips (later models 4 bit) which are arranged such that each memory address selects 8 chips, each chip providing one bit of each byte.

When I wrote the tester for that, my 0xAA/0x55 test wasn't really that, it was a 0xFF/0x00 test (since that would set an alternate pattern of 1 and 0 in each DRAM). That alone wasn't enough, I discovered - I had faulty machines which would pass a rotating bit test, an inversion test (which is the 0x55/0xAA style test) with flying colours. Some RAM had odd addressing failures that would only be detected by a random memory fill. That test was done by using a pseudo random number generator to fill memory, then restarting the PRNG with the same seed and comparing it to what was in memory. You also get 'bit fade' errors too on some machines; the testing answer to that was to wait a long time and see if anything changed!
User avatar
MartinB
Posts: 5362
Joined: Mon Mar 31, 2008 10:04 pm
Location: Obscurity
Contact:

Post by MartinB »

Yes, it's a thorny area when there's perhaps a fault in the very memory the machine needs to run a program to find the fault! You are of course absolutely right in everything you say but there's something of a paradox here in that the very best, 100% effective memory test program would probably need a fully serviceable machine to run :?

Experience on the Beeb has taught me to try to assess the symptoms and what fuctionality is still available and then to bespoke the memory test to that scenario. I'm assuming hilldweller (sorry, don't know your name!) doesn't have another Beeb or other means to handle ssd programs etc. and so something is needed which can perhaps, if necessary, be cautiously typed in (semi-blind) and turned into a useable test. Since the symptoms seem to suggest display problems, I'm expecting the test to pass but that he will see some manifestation of display 'hiccups'. Since the program produces a fixed display pattern, refresh bit fades or corruptions will show visually as will many other similar access problems. If the problem is more fundamental then the program itself may not run but this would at least lead to the next logical steps in the diagnosis. As suggested, if the only display issues are seen in Mode7 then the causes are dramatically narrowed.

Oh, and.... I notice a little typo in the program. I was lazy and typed it in rather than importing from a working copy and I see that I've missed a -1 from after the M% in line 90. Should read ..PRINT~M%-1.. Not major but wthout this, any faulty location will be reported as one location too high.
And that's after I said in another thread that "I don't do bugs." :oops:

Anyway, all this keeps us off the streets I suppose........ :)

Martin
Last edited by MartinB on Sat Nov 07, 2015 5:21 pm, edited 1 time in total.
User avatar
Winston
Posts: 47
Joined: Tue Apr 01, 2008 3:24 pm
Location: Devil's Island, Hell
Contact:

Post by Winston »

Yes, memory tests from a faulty machine are a thorny issue :-)

This is why I made a ROM board for the Spectrum to do the job - it doesn't rely on RAM at all during the memory tests (doesn't even use the stack). All the board needs is a working CPU to produce some sort of result.

The same could be done (probably more easily) on a BBC, dropping an EPROM into the ROM socket where the MOS lives and run some hardware tests - so long as the data and address bus aren't fouled you could do a reasonable test of all the hardware.

(One of my future intented projects is a sideways flash board for the BBC micro, in circuit programmable, naturally. Using surface mount components, the PCB will probably be barely larger than an EPROM, but will have 128k of flash!)
User avatar
1024MAK
Posts: 10544
Joined: Mon Apr 18, 2011 5:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Display Problems

Post by 1024MAK »

Cross reference to other thread >>> http://stardot.org.uk/forums/viewtopic. ... 305#p49142
Post Reply

Return to “8-bit acorn hardware”