Houston, we have an image!

[Andy Rea]

i have seen display corruption like that when tinkering with my ULA, it was caused by severe jitter in the oscillator bought about by slight changes in supply voltage, for example when plugging ZXpand in, after some more tinkering i changed some values around the oscillator, but it still persisted in some cases, these were cured by the addition of a small ( start with say 33pf ) cap across the ceramic resonator. i think Siggi and Sasha have had to do this.

Regards Andy

[PokeMon]

Thanks, but seems to be solved now.
Don't know exactly what it was, maybe a cold sold.
When changing 24 and 28 pin RAMs I have to change J97 which I did with soldering pad only.
So today picture is perfect even with 6116 RAM.

[PokeMon]

Now I am working on the NMI generator but the picture isn't synchronized well.
So my first question to understand is, what is the exactly difference between SLOW and FAST mode ?
If I switch to fast mode I get a perfect picture, if I switch to SLOW mode, the picture is corrupted.

So first think I thougt is that picture creation would be same part in inactive state (K cursor) for both SLOW and FAST mode. But it isn't.
I know that there is no picture generation when running programs. But when the system is in input state I thought picture is generated in same way, regardless if SLOW or FAST ?

Any more detailed information ?

nmix_sch.jpg (58.11 KiB) Viewed 4280 times

Screen in SLOW mode

nmix_slow_s.jpg (183.26 KiB) Viewed 4280 times

Screen in FAST mode

nmix_fast_s.jpg (135.62 KiB) Viewed 4280 times

[Andy Rea]

it looks like the timing of you hsync is wrong, i'm not entirely sure how your circuit is working haven't had time to look at it properly, it looks like your loading the counter with 207 on an intack (iorq low and M1 low) then after 207 clock cycles trigger the sync pulse. however this is wrong timing....

right this is how it goes, imagine a counter counting up, a reset ( intack ) will reset the counter to zero ( and hold it until either M1 goes high or IORQ goes high ) , the sync pulse occurs at count 16 thru 31 the counter will continue to count abnd wrap around from 207 to zero also.

HTH Andy

[PokeMon]

Yes I use a backward counter from 207 to 0. I adapted the NMI generator from Grant Searle.
The counter is reset (let better say preloaded with 207) when either an INTACK occurs (M1 and IORQ low) or when counter reaches 0.
The same does Grant but he counts upwards, I count downwards.
The counter doesn't stop in Grant's schematic, it is reset on both events (which occurs more early).

The only different thing is, that my counter is stopped when NMI is disables and reset again when NMI is enabled.
Not sure if this could be a problem when counter is not running 100% synchronously.

The counter 74HCT40103 does count backward, give one low pulse when counting to zero, which is stretched to 5 us (pulse is one clock cycle length only).

[RetroTechie]

AFAIK a ZX81 (and ZX80, too?) horizontal screen line is 207 clock cycles long, read: there is no count 207. Preload with value 206 instead.
If counting up, count is 0,1,...,205,206,0,1 etc, and hsync is active during counts 16-31 (tip: counts directly following that can be used as back porch signal!).
If counting down, count is 206,205,...,1,0,206,205 etc, and hsync should then be during counts (lemme think ) 190-175.

The only different thing is, that my counter is stopped when NMI is disables and reset again when NMI is enabled.

That's definitely not correct! IIRC, Grant ran some tests which showed that this 207-cycle counter is reset by an interrupt acknowledge. But apart from that, a free-running counter that generates hsyncs at fixed intervals. All a programmer can do with the NMI enable/disable flipflop, is have those hsync's passed on to the Z80 as NMI's, or not.

Don't understand why you do it like this, the correct way to control this counter is simpler as well...

The counter 74HCT40103 does count backward, give one low pulse when counting to zero, which is stretched to 5 us (pulse is one clock cycle length only).

Just decode a range of counts: for example when counting up, counts 16-31 all have the same 4 upper bits. FWIW: a stable running counter & 207-cycle period is probably more important than this 16-cycle delay from INT-acknowledge (or exact hsync pulse width, for that matter).

If available, I recommend you use a synchronous reset (or preload) for the counter. Otherwise you can have this situation: reset condition occurs, some bits from the counter reset, decoding responds to changed counter value, and reset condition ends while some other counter bits are still not reset (the counter is only 'half reset' so to speak). With a reset enable signal, and clock transition doing the actual (p)reset, you don't have that problem.

With same-speed logic this might not be an issue, but when using a 74HCT counter + output decoding with for example 74ACT, 74F or LVC logic, you might very well run into this problem.

[Andy Rea]

oops my bad... well spotted RetroTechie, coutn should of course be 206 down to 0 and then back to 206 and so on, or 0 to 206 and so on

Regards

[PokeMon]

AFAIK a ZX81 (and ZX80, too?) horizontal screen line is 207 clock cycles long, read: there is no count 207. Preload with value 206 instead.
If counting up, count is 0,1,...,205,206,0,1 etc, and hsync is active during counts 16-31 (tip: counts directly following that can be used as back porch signal!).
If counting down, count is 206,205,...,1,0,206,205 etc, and hsync should then be during counts (lemme think ) 190-175.

Thanks, that's maybe an issue. You maybe right about preloading the counter with 206. But this depends on wether I reset/preload it asynchronously or synchronously. I first decided to preload it asynchronously which would preload 207 immediately when reaching 0. So then I will have 207 cycles and not 208 per period. After I decided to change to synchronous preload (preload is performed on next clock cycle and not immediately) because the asynchronous gave a very small /TC zero pulse at output (about 50ns). That wasn't stated this way in the datasheet. It's stated to deliver a pulse of one clock cycle length (308 ns) - but only in synchronous mode I think.

The next thing is maybe more important. I do the sync pulse when reaching 0 and not 16 cycles after preload / sync condition with INT ACK. Hmm didn't think that this make a big difference as the hsync should be only regularly every 64us / 207 clock cycles. But now I am not sure.

And I extend the 308 ns hsync pulse to (about) 5us. I think the exact length (4.7, 4.8, 4.9, 5.0, 5.1 us) is not that important.

The reason to use this counter was to simplify the NMI generator circuit and to kill some and gates to get the 207 count. I think it's more easy to count down.

If available, I recommend you use a synchronous reset (or preload) for the counter. Otherwise you can have this situation: reset condition occurs, some bits from the counter reset, decoding responds to changed counter value, and reset condition ends while some other counter bits are still not reset (the counter is only 'half reset' so to speak). With a reset enable signal, and clock transition doing the actual (p)reset, you don't have that problem.

With same-speed logic this might not be an issue, but when using a 74HCT counter + output decoding with for example 74ACT, 74F or LVC logic, you might very well run into this problem.

I don't understand what you mean. The counter can be reset / preloaded only in full size not partly.

[RetroTechie]

The counter can be reset / preloaded only in full size not partly.

No you're wrong, it's perfectly possible to reset a counter partly. On paper one might think that can't happen, but reality says otherwise. This is a perfect example of the old saying "in the end, all digital circuitry is analog too".

Let's say your datasheet says a reset pulse should last at least 10 ns. But you apply a reset pulse that only lasts 0.5 ns. Will it reset? Probably not.

Now increase your reset pulse width to exactly the time needed for any bit to reset (and no picosecond longer ). You think that required time will be the exact same for all bits? Think again: there will be differences between how long it takes each bit to reset (no matter how small those differences might be).

So @ that point, a bit will reset, most other bits will be near the point where they'll reset, but haven't yet. End the reset pulse there, and you have a partly reset counter.

In most cases, logic detecting a max-count or similar will need some time to respond to the counter output. And the counter output itself takes some time to reflect the internal counter state. So by the time decode logic has caught up with the resetting counter, the reset is completed already.

But that's the usual case, not a guarantee in any way. Especially when the decode logic is (much?) faster than the counter logic, things may start to behave unexpectedly. Add board/trace capacitances, temperature effects, differences between parts from different manufacturers, etc, etc (you get the picture). Like said: if there's a synchronous (p)reset available, where you just set 'flags' and a clock signal does the actual reset: use it, and avoid a lot of these nasty issues.

For further reading, eg. look here: Metastability in electronics (Wikipedia)

[1024MAK]

One lesson we learnt in college was the problems of decoding the outputs of asynchronous ripple counters. As it takes time for each stage to operate, the higher bits will be updated last, meanwhile the decoder logic has seen both valid updated lower bits and the (old) state of the higher bits, so it sees the "correct" logic inputs and so erroneously outputs a decode= true output! Okay, the decoder output does not stay "true" for long.
This "glitch" may or may not affect the functioning of the following logic circuits...

Mark