Houston, we have an image!

Any discussions related to the creation of new hardware or software for the ZX80 or ZX81
User avatar
Andy Rea
Posts: 1546
Joined: Fri May 09, 2008 2:48 pm
Location: notts UK

Re: Houston, we have an image!

Post by Andy Rea » Wed Jun 12, 2013 5:27 pm

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
6 x ZX81, 1 x TS1500 , 1 x +3e, 1 x timex 2040 printer, 1 x timex 2020 cassette deck, siclair printer and some spectrum

User avatar
PokeMon
Posts: 2225
Joined: Sat Sep 17, 2011 6:48 pm

Re: Houston, we have an image!

Post by PokeMon » Wed Jun 12, 2013 9:49 pm

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.
:roll:

User avatar
PokeMon
Posts: 2225
Joined: Sat Sep 17, 2011 6:48 pm

Re: Houston, we have an image!

Post by PokeMon » Thu Jun 13, 2013 5:44 pm

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
nmix_sch.jpg (58.11 KiB) Viewed 1609 times

Screen in SLOW mode
nmix_slow_s.jpg
nmix_slow_s.jpg (183.26 KiB) Viewed 1609 times


Screen in FAST mode
nmix_fast_s.jpg
nmix_fast_s.jpg (135.62 KiB) Viewed 1609 times

User avatar
Andy Rea
Posts: 1546
Joined: Fri May 09, 2008 2:48 pm
Location: notts UK

Re: Houston, we have an image!

Post by Andy Rea » Thu Jun 13, 2013 7:57 pm

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
6 x ZX81, 1 x TS1500 , 1 x +3e, 1 x timex 2040 printer, 1 x timex 2020 cassette deck, siclair printer and some spectrum

User avatar
PokeMon
Posts: 2225
Joined: Sat Sep 17, 2011 6:48 pm

Re: Houston, we have an image!

Post by PokeMon » Thu Jun 13, 2013 9:33 pm

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).

User avatar
RetroTechie
Posts: 379
Joined: Tue Nov 01, 2011 12:16 am
Location: Hengelo, NL
Contact:

Re: Houston, we have an image!

Post by RetroTechie » Fri Jun 14, 2013 3:04 am

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. :idea:
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.
PokeMon wrote: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.

User avatar
Andy Rea
Posts: 1546
Joined: Fri May 09, 2008 2:48 pm
Location: notts UK

Re: Houston, we have an image!

Post by Andy Rea » Fri Jun 14, 2013 4:45 pm

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
6 x ZX81, 1 x TS1500 , 1 x +3e, 1 x timex 2040 printer, 1 x timex 2020 cassette deck, siclair printer and some spectrum

User avatar
PokeMon
Posts: 2225
Joined: Sat Sep 17, 2011 6:48 pm

Re: Houston, we have an image!

Post by PokeMon » Fri Jun 14, 2013 10:04 pm

RetroTechie wrote: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. :idea:
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.


RetroTechie wrote: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. :shock:

User avatar
RetroTechie
Posts: 379
Joined: Tue Nov 01, 2011 12:16 am
Location: Hengelo, NL
Contact:

Re: Houston, we have an image!

Post by RetroTechie » Sat Jun 15, 2013 3:06 am

PokeMon wrote:The counter can be reset / preloaded only in full size not partly. :shock:
No you're wrong, it's perfectly possible to reset a counter partly. :o 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 :lol: ). 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)

User avatar
1024MAK
Posts: 2569
Joined: Mon Sep 26, 2011 10:56 am
Location: Looking forward to summer in Somerset, UK...

Re: Houston, we have an image!

Post by 1024MAK » Sat Jun 15, 2013 8:45 am

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

Post Reply