• Please review our updated Terms and Rules here
  • Exhibitor application for VCF West 2022 is now open! If you are interested in exhibiting, please fill out the form here.

Resolution to the most frustrating TRS-80 CRT Swap...

ardsleytank

Experienced Member
Joined
Nov 15, 2015
Messages
277
Location
Tennessee
Well, following the advice I got from some of the members here, I put a resistor inline with pin 2 of the CRT in my Model III.

No dice.

So, the other option was pin 3, which goes to pin E802 on the video board. Couldn't find a 12 ohm resistor, so I tried a 10ohm. Made no difference.

So, I thought, "What the heck, if it's gonna work it will, and it can't hurt anything!", and I put a 100ohm resistor in, and hey presto!, I got a result.

A little too dark though, so I found some other resistors, a 67 ohm--a little too bright, so I added an additional 10ohm for a combined 77ohm solution.

Perfect. I am finally happy with it. And with that being said, she is now for sale. I have a Model 4, so what good is a III? (*cough*I'moutofroom*cough*)

I'm tired...
 

Tibs

Veteran Member
Joined
Dec 10, 2016
Messages
847
Good to hear. I ended up having to recap the video board in my 3 to get it all worked out. Mine was too dim and the image was in horrible condition. I wonder if yours was a similar issue, but of course too bright is easier to solve.
 

gp2000

Experienced Member
Joined
Jun 8, 2010
Messages
433
Location
Vancouver, BC, Canada
Cool tricks!; but why the difference?, it's just a matter of timing or maybe the CRTC have something to do?...

Both programs rely on the Z-80 being able to blank the video display when reading or writing screen memory. I have Z-80 code running from screen memory resulting in entire lines being blanked out. The blanking happens due to the Z-80 and video display circuitry needing to access video memory at the same time. When that happens the Z-80 wins and the video display is handed a 0 value resulting in 8 dots of black instead of what should be displayed. Since the Z-80 is relatively slower the conflict typically occurs over two or three consecutive bytes.

This is what causes the screen "hashing" seen on the Model I when the display is updated. The Model III can operate in the same way and the programs enable that by clearing bit 5 of port $EC. However, in normal operation that bit is set and the Model III instead causes the Z-80 to wait on screen access conflicts. This almost eliminates screen hashing on the Model III, but it can still appear on the left edge of the screen and the bottom 4 lines of non-graphics characters.

The Model 4 always makes the Z-80 wait when it accesses video memory but only for 0 to 4 cycles instead of entire lines. It has no ability to blank the display like the Model III. At least, as far as I know there's no way.

There's nothing in principle stopping programs on the Model 4 from doing carefully timed screen writes with respect to the video refresh. It is more difficult because the number of wait states varies depending on exactly when the Z-80 writes (or reads) video memory. And for non-gate-array Model 4's the 80 column video is driven by a different clock than the Z-80 which makes the timing much more variable.
 
Top