• Please review our updated Terms and Rules here

Graphics card synchronization issue.

Hugo Holden

Veteran Member
Joined
Dec 23, 2015
Messages
4,647
Location
Australia
I am working with a Matrox ALT 512 graphics card to make a light pen project. I have figured out how to write to the card with programs and image files etc. I figured it wouldn't be much use with the light pen, unless I could save the file that was in the Matrox Ram. So for the first time I attempted to interrogate the ports of the card and save the video bit. This is where an interesting anomaly cropped up, but it might be something that is plainly obvious to an experienced graphics card programmer:

The 512 manual says:

"Reading from port 0 will execute a refresh memory read cycle. The video bit addresses by content of of X,Y and the plane register is read at DO. (data line output 0 in pin 95 of the card).

Elsewhere it remarks: Synchronization of the TV scan and the CPU read-write and clear is done by flip flops A8 and A9. (checked and appear to be working)

This sort of suggested that there is a form of synchronization at least to acquire and write data to the card, so the CPU does it at the right time. Also it occurred to me that the reads would have to avoid the times when the RAMs were being refreshed. It is obvious that outside the H and V blanking times the RAM data is stable, as it appears on the Monitor's image.

However, a short loop in BASIC, with the X and Y registers programmed for an ON pixel location:

10 PRINT INP(0);
20 GOTO 10
30 END

when run prints correctly 255, most of the time, however prints at intervals the occasional value of 254 which is incorrect.

Going over the card with the scope, I could not find any defect and the synchronization circuit appears to be working, I think, except for this:

The scope analysis shows that the CPU does attempt to do a read at times within the H an V blanking periods. The CPU timing and the card's video generator timing are of course not phase locked in any way and are crawling with respect to each other. I think what is happening is the CPU is attempting to acquire data from the video RAM at a moment were they are being refreshed, hence occasionally corrupting the acquired video bit value.

It suggests that the software should be written to check the H and or V blanking flags (there is a register for those) and not attempt to read the video bit inside the blanking time. Would that kind of thing be standard practice for reading a video card's memory, or is it not supposed to matter and be handled at the hardware level ?

(In other words I'm not sure if the card might have a hardware issue or not)
 
I found the answer and it was the most difficult hardware issue I have had to sort out on my SOL yet.

I'll explain what was wrong and of course when the answer is known it all seems so darn obvious. I'm still trying to decide if it was a nightmare or a learning experience.

I drew out all of the sub-circuits on the Matrox ALT-512 card that were responsible for latching and outputting the pixel data bit.

I noticed that the latch they used to latch that bit was a 74LS75, a somewhat odd-ball latch which when not latched, passes the input data directly to its output. That had me wondering if it might have been better off with a 74LS74 as the latch, but that was a false lead.

In any case, the way the circuit works is that when the port decoder is activated for a read from the card, with a combination of the SINP , PDBIN and the correct address, the synchronizer flip flop sends a signal (low) via PRDY to stall the CPU (and hold everything stable) until the pixel bit value has latched and is stable, before this wait state is released and then a tristate buffer puts the latched pixel bit value on the data line D0. In addition, the tristate buffer that puts the "0" on the the PRDY line simply has its input grounded. It can only pass a low to the PRDY line to the SOL, never a high.

However, I noticed with the scope that the CPU's address lines were still active during the time that the CPU was supposed to be in a wait state according the the Matrox card. It was then I discovered that the Matrox card, set up as it was, could never work properly in a SOL, for a port read operation, because....

It turns out in the SOL, they have a PRDY driver circuit, another tristate driving the PRDY line, but this time the tristate input (U71, pin 12) is being driven by a flip flop(U70) , to ensure one wait state during cycles of either input, output or a memory reference is made in the SOL. The tristate output (U71 pin 11) here was fighting at times the tristate buffer on the Matrox card, preventing the Matrox card from stalling the CPU.

The tristate in the sol (U71) can not only pull the PRDY line low, it can push it high too because the input to it is from the flip flop (U70) can be high or low at times. When it was doing that and the tristate on the Matrox card was trying to pull the line low, it reached an intermediate value, not quite logic low at times, so the CPU ignored the wait state from the Matrox card.

I realized that ideally, with more that two devices attempting to use PRDY to generate wait states, it would have been better if they were OR'd together and only had the ability to pull the PRDY line low.

Looking at the SOL-20 schematic, I found there was another input functionally the same as PRDY, the XRDY line essentially OR'd with PRDY, not used it appears (although some cards might use it).

So to solve the problem of the resource conflict with the Matrox card and the PRDY line in the SOL, I simply modified to Matrox card to output its wait state on pin 3 of its S-100 connector (XRDY) rather than PRDY (pin 72) and the problem is solved. Perfect pixel data reads now. Phew !
 
Back
Top