commie wrote:2. Again, with your hsync generator, your syncro counters have 'chip enable'(ce), it looks like an ls161 ttl counting scheme?, so what I did was, second syncro counter is clocked with tc(terminal count) from the first syncro counter which is clocked with 3.25MHz cpu clock. The hsync/back_porch and reset logic remain the same except on your back_porch you are gating tc?, I removed it.
IIrc that's "clock enable" but is kinda the same thing in this context..
I was wondering though: in a ZX81 the hsync pulses come at 207-cycle intervals. Logic decoding the counter bits just decide where in the 207-cycle period hsync and back porch are active. Could you post the
exact logic you're using to decode these 2 signals? (as a function of that 207-cycle's count value). Maybe there's something in there we're overlooking.
Just some extra info which might help, the t state synchroniser which is a npn bjt emitter=nmi, collector (via 1k resistor)=cpu wait and base (via 10k resistor)=halt. If I remove the halt 10k base resistor then wait states are no longer activated, with this resistor out of circuit, I get a corrupted inverted K cursor(pixel related) and the system is running in slow mode, pressing 'print' gives corrupted print on the screen(pixel related), which tells me the cpu is running successfully in slow mode.The top right hand corner of the screen is also corrupted.
That's a question I didn't see fully answered so far: does the machine hang
always when NMI's are passed through (no matter what else you do), or is it screen corruption only? Why this matters:
There's quite a few things that can go wrong in an ULA implementation like this. BUUUTTT... much of that affects screen output only. Shift register, when pixel data is grabbed from databus, invert bit, etc. The Z80 doesn't care & will execute programs (or forced NOPs) as usual. With 2 exceptions:
- /ROMCS and /RAMCS (and related to them, that "stretch" signal in my CPLD design). If this were messed up, chances are FAST mode wouldn't work reliable either. Or you'd have no sensible looking screen output at all. So I think this part is working.
- /NMI output to the Z80. That signal has the potential to cause a hanged CPU. For example when a NMI is received while Z80 is just processing a NMI: if I'm not mistaken, NMI's are basically handled as CALLs (with a special effect on Interrupt FF's), so nested NMI's could cause the machine to run out of stack space / stack overwriting system variables or similar.
What also may help is posting a few screenshots... sometimes what's going wrong is right there to see on screen.