FDX 80 Column Fault - Video Question . . .

[Dave]

Hi Folks,

The 80 Column board on one of my FDXs is faulty and I was hoping that someone could help diagnose the problem please?

As you may know, Peter Ketzschmar was able to provide us with a copy of a very early schematic for what became the FDX 80 column board.
http://www.primrosebank.net/computers/m ... .htm#80Col

While I have been trying to understand how the board works, I have redrawn it in KiCad to make it more legible, the original schematic was pretty good, but some of the text is a bit unclear, so my schematic may have some inaccuracies in it. I have also made a couple of minor changes based on "reverse engineering" of my boards and added a few comments for my own benefit (which may, or may not, be correct.

OK - the problem . . . .

The output from the card has the foreground colour frozen at blue, all of the characters are working as expected and the background colours are correct. I have swapped over the Character and Attribute RAMs so I think that the fault is due to a problem in the Attribute setting circuitry.

Looking at the schematic, I think that the most likely problem is the 74LS374 in board position 5D (UD5 on my schematic), Unfortunately, most of the ICs, including this one, are not socketed, so I will need to unsolder it from the board to replace it. Before I do so, I'd appreciate some feedback on the problem and, if I am likely to be mistaken, other suggestions on where the fault may lie.

I am a bit lost on how the characters and attributes get combined to generate the video signals. As I read it, the CRTC reads the appropriate character out of the Alpha (7A) and Graphics (9A) ROMs and saves it to the Character RAM (9C). The attribute to write is saved to the Attribute RAM (7C).

All of the wizzadry to generate he display is very much a mystery to me, but the biggest question that I have is on how the combined character and attribute information get to the display. The attribute write word is connected to the 74LS273 (8D) and works its way through to the output. I can't see how the actual character get to the output? Can any one explain this please?

regards
Dave

[1024MAK]

The MC6845P (UA4) does not read or write screen data as such. It provides timing, address and row signals.

The character RAM (UC9) is only 2k bytes. It only stores the ASCII codes for the characters currently on the screen.

When a character is required to be displayed, the circuit has to use the ASCII code from the character RAM to work out the actual scan data that will be displayed. This information is stored in the selected ROM (UA7 or UA9). The data from the selected ROM is 8 horizontal bits that make up one line of a character row. This goes to UA6 which converts the 8 bit byte to digital monochrome video data (called VCNTL) in the form of a serial data stream (which is what a CRT display requires). This serial data then goes to multiplexer UE7 (pin 1, the select input), which selects inputs I0 or I1 depending on if the select input is high or low). The relevant output pin then follows the selected input pin. Think of UE7 as a linked group of four change-over switches. For a colour screen, the effect is to switch between the foreground and background colours.

The inputs I0a, I1a etc contain the colour or attribute data for the character that is currently being built up on screen.

I hope this helps

Mark

[1024MAK]

Dave, for fault finding this problem, well, it's a job for Mr oscilloscope. Do you have a good one (25MHz or higher dual channel) ?

Mark

[Dave]

Hi Mark,

thanks a lot for the info - it does help, I just need to read it through a few times for it to sink in

Mr Oscilloscope is tapping his feet 100,000,000 times per second awaiting instructions

regards
Dave

[Martin A]

Have you tried writing a byte to the video attribute memory and then reading it back, to confirm the right value gets into video memory I the first place ?

[Dave]

Hi Martin,

no - I haven't tried that, that sounds like a good thing to try.

I just need to work out how to do it first

regards
Dave

[Martin A]

Something like

Code: Select all

10 OUT 51,63
20 OUT 50,65
30 OUT 49,224
40 FOR X=0 TO 255
50 OUT 48,X
60 NEXT
70 OUT 49,0
80 FOR X=0 TO 255
90 OUT (48),X
100 PRINT INP(51)
110 NEXT

Tested on re-memorizor, as unlike some folk I don't have 157 FDX's

The first 6 lines push 256 white on white A's on to the 80 col screen, quite where they appear depends on the scrolling that's been done.
With the background stuck on Blue, you'll see a white A on the blue background.

The last 5 lines just read back the attribute byte.

[Dave]

Hi Martin,

thanks a lot - I'll give it a go and report back.

( Not quite 157 yet - but I'm working on it )

regards
Dave

[Dave]

Hi Martin,

results as shown - perhaps you meant a blue A on a white background? (It is the foreground attribute that seems to be playing up.)

The Attribute reads all read "6" for the higher numbers (>20), so the code changed as shown to fit the frist 20 reads on the screen. You won't see much from the very poor quality colour photo, but the photo from the mono screen shows the results better - dodgy test after X=7

regards
Dave

[Martin A]

That IS interesting, as the read back on my re-memorizor based setup is the 63 that's put into the attribute port on line 10.

Which suggests you might be wanting to look at the write to attribute ram side, rather than the video output ?