ZX81+35 Clone

[RetroTechie]

Yeah, I remarked earlier in this thread that this extra flip-flop (U18.B) behind the shift register served no purpose. But I studied the schematic a bit, and found the issue is more complicated.

I'd start with this though:

Anyway you connect /CE (or Clkinhibit) together with CLK of the shift register which is very strange and may cause some side effect as well.
So when the clock is rising it should move the shift register while the clk is inhibit as soon as it is high.
You never know whats happening inside.

Well actually you do know what's happening inside: datasheet shows that both clock and clock inhibit are thrown into a NOR gate, and thus are interchangeable. But I noticed this too. It's just weird tying clock and and inhibit for the same, to the same input signal. Either it doesn't do anything, or it might cause weird glitches. And it causes a 2-input load on a signal where 1-input load would do. Fix is easy though: tie "clock inhibit" input to ground.

Issue here derives from the '165 used: its parallel load operation is asynchronous. That is: the 8 internal bits can be updated any time regardless of where in the clock period you are.

Better would be to use a '166 here. Its load operation is synchronous, that is: the 8 internal bits are always updated at a clock edge. When the "load" input is active, they're updated with the parallel input data. If not, the already-present bits are shifted. Either way, serial output is updated @ a fixed, regular interval.

You have one constraint with both '165 or '166: presenting the input data around the time that the last bit of a character (0) 'runs out' and the first bit of a new character (7) is needed. Since you have a time window in the Z80 "execute NOP" cycle, there is some freedom in choosing where in that window the parallel load occurs. Read: @ some edge of the pixel clock where ROM access time has been fullfilled and data bus still has the pixel data on it.

With the '166, all that's needed next is making sure that "load enable" is active leading up to that point where the bit 0->7 clock occurs. And perhaps a short while after ("data hold time"). It's not that hard to meet that condition, and result is a perfectly regular stream of bits. No "re-synchronisation" needed.

With the '165 however, you also need to make sure that the "parallel load" signal occurs exactly at the same time that clock edge arrives. The latter is a much harder condition to meet, imho. Too early, or too late, and you'll have pixels that are stretched or chopped up - which is what you're seeing here. A tiny bit too early or late, and the problem can be small - but you'll still have it.

Personally I would go & draw a timing diagram here, with all clock & relevant signals in it, datasheets of the logic IC's in hand, to get a good view of the sequence of events. And then re-organise that shift register load mechanism as needed (going with a '166 if it doesn't require too much rework).

[PokeMon]

Anyway you connect /CE (or Clkinhibit) together with CLK of the shift register which is very strange and may cause some side effect as well.
So when the clock is rising it should move the shift register while the clk is inhibit as soon as it is high.
You never know whats happening inside.

Well actually you do know what's happening inside: datasheet shows that both clock and clock inhibit are thrown into a NOR gate, and thus are interchangeable. But I noticed this too. It's just weird tying clock and and inhibit for the same, to the same input signal. Either it doesn't do anything, or it might cause weird glitches. And it causes a 2-input load on a signal where 1-input load would do. Fix is easy though: tie "clock inhibit" input to ground.

Okay - didn't look into the data sheet schematic.
This was a surprise. In fact clock inhibit is a separate clk input ! This is crazy. If the clock is low or any positive edge on clock inhibit during clock low will give a shift further. It is very hard to predict the behavior in all cases or better it is harder to assure that clock inhibit operates only as inhibit and not as clock. Maybe this way a linguistic joke from the developers having 2 functions on one single input. It is clock AND inhibit.

[mahjongg]

well I "armed" myself with a printout of the 74HC165, and a logic analyzer, and will try to find out what is going on this weekend. note that due to the fact that there is no delay between CLK and /CE and that they are simply input to a NOR gate there should be no effect, but I agree that its a bad habit to do this, its better to tie /CE low. I have investigated several (4 or 5) re-builds of the ZX81, and they all use the HC165, they all, (except one) have CLK and /CE tied together, and they all have a d-flip flop. Now it could be they all copied from the same source, or perhaps they are all by the same person, (with different aliases) but I wonder why they did not find out about this problem. Rodney Knaap designed three generations of ZX81 clones, his first one had /CE tied low, but het later two designs had /CE and CLK tied together, perhaps just because it was easier to layout, and it made no difference. Wilf Rigters ZX97 is almost exactly the same as rodney knaaps one, there is also a very similar "mini ZX81" design, probably also a copy of the other four.
note that the original ZX80 also used (one) 74HC165, but doesn't put a d-flip/flop (latch) behind its output.
In fact this part of my design is an exact copy of the ZX97 see: http://www.user.dccnet.com/wrigter/inde ... 97lite.htm

so why does his design (seemingly) not have this very same problem?

i'm going to find out!

[mahjongg]

P.S. I'm wondering if this problem has anything to do with the phase of the Z80 clock signal, perhaps I need to invert it. just a hunch.

P.P.S. I have uploaded the latest schematic, (REV 3.0 first the non prototype version, of the ZX81+35) to RevSpace.
It has all the modifications I made so far.

[mahjongg]

FOUND IT!
I fixed the problem!

Inverting the Z80 clock had no discernible effect, so I removed the D-latch and coupled the D input directly through to /Q, this resulted in a video signal that was much better but not perfect, it did result in a K cursor with a defined front edge, but it was somewhat thin, and the checkerboard characters did not fit cleanly together, but at least I could say that the problem was in the D-latch, so I inverted the D-latch clock signal, and that did the trick, a perfectly clean character set with no strange effects, and best of all perfectly aligned checkerboard characters!

ZX81+35 fixed video.jpg

(1.53 MiB) Downloaded 428 times

more pictures later, have to go to sleep now.

Oh, I also looked at the back porch pulse generator to see if I could easily overlap the sync pulse with the porch pulse, but that was not easily done, at least not by modifying the selection logic for the porch pulse. The easiest solution is to simply OR the sync pulse with the old porch pulse to get a wider porch signal, perhaps with diode logic. One advantage of stretching the porch pulse is that the diode sync combiner get its easier, with the current design it needs to draw almost 5mA through the diode during the sync pulse, meaning a large diode drop, this will drop to just a few mA when the video signal is at black level (0.3V) because of the porch signal during the sync pulse, resulting (I hope) in a much better defined sync signal.

I also still need to exchange the BC847 (Q8) with a faster transistor, for improved sharpness.

[sirmorris]

Congratulations! I love a success story

[Andy Rea]

Top job sir, such a great feeling when your project starts to work correctly

[sirmorris]

... which is a feeling I am starting to forget

[mahjongg]

I'm sure you will get it back...

[mahjongg]

Okay, I promised some more ZX81 "porn".
So after I discovered inverting the Z80 clock had no discernible result I decided to take the d-latch out of the equation, and with a hot air desoldering station I removed the chip that had that D-latch, (74HC74), luckily the other half of the HC74 was not used. Then I simply connected the data with the active output, and tried it again. after a few seconds wondering why the picture was inverted, I realized the /Q was used, inverting the signal, but changing a few jumpers fixed that. This was the result of once more entering the "print the characterset" program:

PTDC0323.JPG

(2.31 MiB) Downloaded 379 times

as you can see the inverted S now has a black border around it, so success!, but not fully as the two black quarter blocks above the 6 and 7 should fit together, as should the checkerboard pattern. Also the picture seems less stable, look at the block form above the B, and the bottom left Y seems to miss a pixel. So I'm sure the d-latch serves a purpose, my guess was that the latch latched on the wrong edge of the clock, so I needed to feed it the inverse of the /6.5M clock, luckily a trace with the uninverted 6.5M clock ran nearby, so I soldered U18 back with pin 11 bent upwards, and wired the uninverted clock signal to it. This was the result:

PTDC0330.JPG

(1.91 MiB) Downloaded 379 times

Much better no?
I'm sure the edges of the characters could be even sharper, with a better transistor, and small sync irregularities should disappear with a better sync pulse, but I'm happy. In fact the above picture does not really do the quality of the video justice, blame it on my cheap camera.