Problem is still in the logic I think:
Are you sure about that? /IORQ going low activates IC18's /preset input, which would change that flipflop's state if it was "0" before that (pin 6 in schematic above is inverted output btw). Read: if flipflop was internally "1" (pin 6 output = low), /IORQ going low would do nothing. Also note the possibility of both /preset and /clear inputs active (/clear input tied to outgoing SYNC signal), which -according to the '74 datasheet- would set both Q and /Q outputs high.PokeMon wrote:1. There have been horizontal sync disturbing pulses which are created from IC 19.
The problem is, every Low pulse on /IORQ makes a Preset at IC18 which creates a sync pulse two M1 cycles later.
The way I see it, SYNC output is only changed by [any IO write] and [any IO read with A0 = 0, as in: keyboard read]. IC18+19 just use /M1 to synchronize those events with Z80 cycle timing. Presumably to make sure that SYNC transitions occur at exact points in time -> regular spaced SYNC pulses so that TV's produce a stable image.
Perhaps confusing is that the ZX80 only has the software-generated sync (which must serve both as hsync and vsync). Whereas in the ZX81, hsyncs are hardware-generated (but for use as NMI, masked by the NMI enable/disable flipflop), and vsyncs are still software generated (but started & stopped on certain IO operations as with the ZX80). Also see ZX80 <-> ZX81 ROM differences.
The logic is simple though:2. Every (disturbing and regularly) horizontal Sync caused a "+1" for the scanline counter. That was my problem with the crunched lines.
1. A vertical sync should reset the line counter. Whether that is "reset once when vsync goes active" or "keep resetting, and release when vsync goes inactive" makes no difference when there's just one, continuous vertical sync for each TV frame. At the end of vsync, line counter should read 0.
2. A horizontal sync (= next screen line) should increment the line counter +1. After 7, next count is 0 again - and so on. Whether those hsync's are used as Z80 NMI, whether NMI-enable flipflop is switched on or off in the mean time, should have no effect on this: each screen line should advance the counter +1, and counter should never be advanced more than +1 per screen line.
If 1) and 2) both apply, counter output will be what's needed. If not, the logic for clocking/resetting it is wrong.
Correct - The IO write releases VSYNC, and this in turn releases the line counter (still at 0) so that it can count up.So the scanline counter is reset after VSYNC pulse, the OUT ($FF),A does not trigger the counter as described above
Well there's your problem then. If that happens right after VSYNC ends, but before another screen line has passed, the line counter shouldn't be incremented. Not once, twice, and certainly not +3 (see above).and the two other OUT instructions and the T-state-SYNC line will trigger the counter and set it's value to 3 when the picture display begins. Too bad.
Just a keyboard read should not generate a VSYNC pulse.Lets look at the BASIC interpreter. This will execute line by line and after each line it checks wether BREAK key pressed or not with IN A,($FE). This will by the way start a "VSYNC pulse" of variable length (depending on the point of time in execution) in the NMI on phase.
For reference, see the AND gate left of "start_vsync" in my ZX81 ULA schematic. NMI's should be disabled for a keyboard read to start a VSYNC pulse. That's either during VSYNC or active display period. Oh wait, BASIC interpreter isn't executing there! (so those BASIC interpreter's keyboard reads take place while NMI's are enabled, and thus do nothing to VSYNC)
Effect of RC delay you mentioned earlier?Last but not least I have still a problem with a short black line appearing on chars 5 to 10 in the very first line of the screen, which is the T-State SYNC visible on screen.
