Making a Model 4 Grafyx clone

2024-05-27 | [retrocomputing] [trs80]

Unfinished, just writing things down before I forget:

pin 27

The original Grafyx and modern clone both use a IC hook clip to get the OUT* (IO write) signal. We would not be able to write any data to the board without this. It might be possible to derive the OUT* from the *IN and other signals (I don't think Tandy's board used any clips at all), but I tired this on my first clone board which didn't work, and for my second attempt I figured I'd go with what works already.

On my Model 4P GA, pin 27 on the graphics expansion header is unused. It is skipped on the schematics, and on inspecting the 4P mainboard it also seems to have no trace running to it from either side. The clone Grafyx board also does not use pin 27. This made it very easy to solder a bodge wire from pin 22 of the 40 pin display controller and use that to get the OUT* onto my graphics board, cleanly - without an IC clip.

When I tried the same thing on my Model 4 NGA, it did not work. You get OUT* from pin 2 of U13, which I jumpered to graphics header pin 27 as before. On the 4 NGA, pin 27 is not a no connect pin - it is connected to DLYCLOCK, a video related signal which the Grafyx does not need. It took a very long time to figure this out:

• The trace going to pin 27 is on the connector side of the board, so you can't tell if it is going to a pin or simply passing under the connector. On the back side of the board, it looks like it's disconnected.
• Bizarrely, the system still worked with the OUT* and DLYCLOCK connected together!
  • Not only that, but the original clone board still worked perfect also (and it was modified to put OUT* on pin 27 also), whereas mine did not (the hires graphics were very glitchy).
    • I originally thought it was a problem with WAIT* since the graphics seemed to be updating too quickly. Really, it was because not all IO writes were making it through, so less WAITs were triggered.
  • I looked at the OUT* signal on a scope, and it seemed to have some sort of clock-like high frequency signal on it. I could see the clock-like signal was making it through the '138 decoder on my board, and was not making it through the '138 on the original clone. So there's your problem. Probably because I was using HCT logic chips, and the original was LS.
    • Thinking the clock-like signal was coming out of the mainboard U58 pin 14 where it originates, I tried buffering the signal from U58, but this did not work. Only after isolating pin 14 from the rest of the board, I realized that the clock-like signal was coming from somewhere else.
    • I had also done some work around the original video signal to clean it up, and thought I might have bridged a trace somewhere around there, which was really the complete wrong area of the board.
    • I then only realized after probing OUT* and some random other pins that I found the clock-like signal had the same phase and frequency as DLYCLOCK. Then, I checked again with a continuity tester, which revealed the two were truely the same net now.

Sure enough after finding and checking the M4 NGA schematic, pin 27 was clearly shown to be connected to DLYCLOCK. After almost a whole day messing with it, I decided to just cut the trace for DLYCLOCK near the graphics connector.

the last(?) glitch

After the DLYCLK incident, my board was now working on the Model 4 NGA, but shifted by 8 pixels to the left, and the rightmost block of 8 not showing up at all. A classic off-by one. Again, the original clone board did not have this problem, and my board also worked fine on my M4P GA.

I did notice on my scope that the NAND output of H I and J was a bit glitchy on my board. This combination to produce a short low pulse works so long as H I and J were aligned properly. If they are a little bit out of sync (propagation delay, trace impedance/capacitance, different rise/fall times etc.) you can get these glichy spikes. Again, this was not the case on the original clone, maybe an LS vs HCT thing again. This HIJ* controls when the shift register loads.

First, I tried lifting some chip pins, trying signals that were/weren't run through an extra gate for propagation delay in critical areas, but nothing worked. Finally, I figured I would try to slightly slow down HIJ* by adding a capacitor to GND so the rise time would be longer. I used a 120pF capacitor that was lying around, and this fixed the off by one problem instantly. It also cleaned up the glitchy behavior some, but not as good as the original clone had.

120pF is probably on the higher side of what an HCT output is supposed to drive (I usually see 50pF test conditions in the datasheets), and maybe there should be a series resistor in there to limit the current, but I guess it works for now. If that NAND gate ends up breaking I'll let you know.

additional problems (June 2024)

The board now can be written to and display pixels, but I found that reading the data back (as LIFE or SPIRO or FRACTALS do) is still a problem. My test program did only writes, so I did not see a problem at that time. Firstly, I forgot to connect the decoded GRAPHICS_IN signal to anywhere. But after lifting a pin and connecting it, it would still not work. Problem now seems to be a glitched output which causes the flip flop to trigger when it isn't supposed to, so the correct data is not read. I traced the glitch pulse all around the board, but can't find where it originates from. There is at least one IC where it shows up spontaneously, where no input or output signals that are entering the chip look like they should cause a glitch spike. This might be because I am attempting to use HCT parts instead of LS (the original uses all LS logic and the clone uses mostly LS logic, and I had a look at some of the same places in the clone board and there is no glitch to be seen). I will try to swap the timing sections with LS logic and see if it helps.

UPDATE: swapping LS chips did not seem to help. May have to write this one down as a failure.