How the ZX81 NMI / sync works... my 10 points

[zx80nut]

Hi.
As you will have seen, I released a "Version 4" of the NMI/Sync adapter for the ZX80 to convert it to a ZX81.
http://searle.hostei.com/grant/zx80/zx80nmi.html
[Edit by Grant on 7th July 2012 - UPDATED URL !]

Some of you are aware from my web updates that I never rest until I believe something is 100% correct.
So, I have been doing some verification testing on a real ZX81 to confirm to me that what I have done is correct behaviour.

I don't claim to have "discovered" all this myself, as I have also seen other info from Andy etc.
What I want to do is to prove which information on the net is correct for those who want to create an "accurate" clone or ULA replacement.

So, here goes....

1. The Sync generator is totally free-running (doesn't need interrupts etc. to make it continue).
This can be proven with a simple program...
; Disable interrupts
DI
; Disable NMI generator
LD A,0
OUT ($FD),A
; Loop forever, preventing any other program operation
loop
JR loop
With the interrupts and NMI gen disabled, if the sync generation was not free-running then the video output would stop. However, a continual HSYNC stream is produced (no VSYNC due to NMI disabled).

2. The Vertical Sync does NOT reset the sync generator counter.
Again, this can be proven with a small program...
; Disable interrupts
DI
; Disable NMI generator
LD A,0
OUT ($FD),A
loop
; Activate and reset the VSYNC, then loop.
IN A,($FE)
OUT ($FF),A
JR loop
If the VSYNC activation was to reset the HSYNC counter then the video output would be a constant stream of very short "VSYNC" pulses. However, when observing the output, and adjusting the scope timebase carefully, it can be seen that these VSYNC pulses are actually superimposed with the correctly timed HSYNC pulses, showing that the HSYNC counter is not affected by the VSYNCs.

3. The triggering of the sync pulse is only via the sync generator counter, and does not have a seperate triggering circuit (like the sync gen in the ZX80).

4. The sync generation is permanently on.

5. The sync counter reset ONLY occurs with an INTACK signal.
I have verified this a while ago, and the SYNC will only be re-synchronised when /M1 and /IORQ are both low (ie. the Z80 INTACK signal).

6. The SYNC is clocked by the rising edge of the CPU clock.

7. The SYNC goes low on the 16th rising clock pulse AFTER the INTACK has gone high. The SYNC (and NMI if enabled) lasts 16 clock cycles and returns high on the 16th rising clock after it went low.
Scope pictures on my web page show this.

8. When enabled, the NMI is produced at the same time as the SYNC.

9. VSYNC and HSYNC are "AND"ed together. If any is low then the output is held low.

10. The "Mic" out is not pure - it also has the HSYNC signals in it during save (!).
The "low" signal is clean (due to point 9, above), but when the "high" pulse is generated, the HSYNCS also within it produce many glitches. The reason being that the HSYNC generation can't be turned off, and a common output pin on the ULA is used.
The output R/C circuit actually filters out most of the 15KHz sync signal, so not much appears on the output, but it is very visible on the video/cassette output pin on the ULA.
I am guessing that this may also be the reason why some find "cheaper" cassette tapes worked better - the lower top-end response would filter out more of the unwanted 15HKz signal.

The connections for my latest version of my NMI/Sync has split the CSYNC and the mic output signals to clean them up. However, the behaviour in point 10, above, can be introduced with slightly different wiring if a genuine accurate signal is wanted.

I'll add some of this to my web page, for info, when I get a moment.

Hope this helps.


Regards.


Grant.
http://searle.hostei.com/grant/zx80/zx80.html
[Edit by Grant on 7th July 2012 - UPDATED URL !]

[zx80nut]

...also....
The I/O port assigments appear to be because of extremely simplified decoding used, and rely on a single bit being low to activate a circuit...

OUT
xxxxx011 - Printer
xxxxx101 - Stop NMI
xxxxx110 - Start NMI

IN
xxxxx0x1 - Printer
xxxxx1x0 - Keyboard

You can see that, of the bottom 3 bits, only one is ever "0".
So, any other I/O device would need an address where the bottom 3 bits are always 1 to avoid interfering with the "internals" of the ZX81 or printer.

(There is also OUT xxxxx111, which ends the frame sync, but this will not interfere as the frame sync and video circuitry is disabled during the program active time ie. when NMI is on)

Grant.

[Andy Rea]

Nicely put Grant,

I don't think that i could have put it much more clearly myself, However... (ain't there always an 'however')

Could i just point out that whilst grants circuit appears to be 100% accurate (i have personally not tested it) for converting ZX80 into ZX81,

For those of us using it as a basis for designing ULA replacements that there is a transistorised inverter between the ULA's cpu clock output pin and the actual CPU clock pin. It doesn't make alot of difference but durring my development of a ULA replacement swapping phases under some circumstances led to the active display area moving horizontally by 1 pixel !

Regards Andy

[zx80nut]

Hi Andy.
Thanks for the reply - you are correct (as always ) - the CPU clock mentioned is "at the Z80", so within a ULA replacement, the clock phase is inverted.

One more thing...
I added (in Version 3 onwards) an extra bit in the circuit to disable the video circuitry in the ZX80. Previous circuits, and also the one I based the original on, only disabled the sync part. This addition was needed to avoid some minor flickers in the "NMI Enabled" parts of the display. It appears that some ZX81 re-designed circuits also only disable the sync part, so I suspect also suffer the same problem.

Please try the following, to see if your ULA replacement also needs something done to it...
10 LET A$=INKEY$
20 PRINT A$;
30 GOTO 10

Run it and see if there is any disturbance (small flickering lines, 1 char wide) in the top and bottom areas of the screen - may be OK, but just in case...


Grant

[Andy Rea]

Ok i have ran the small program and did not notice any disturbance in the top and bottom margins, the active display area stays as rock solid as it always was.

There is a program over on the German forum http://forum.tlienhard.com/phpBB3/viewt ... ?f=2&t=331 called ' ClckFreq.p ' (in the second post) that performs a sequence of tests that takes a set number of 'frames' when run on a genuine ZX81, to my dismay (well it is an experimental circuit) my minimal (4 chips and a handful of discretes) clone machine did not report the same result as a ZX81, My ULA replacment however did with the current version of CPLD code V7 (suppose it really ought to be v0.7) i have yet to find something that it does not do like the original.

yeah i seem to have babbled on a bit, but if your in a position to run the above program give it a go, you might be pleasantly suprised.

Regards Andy

[zx80nut]

Hi Andy.
Glad you don't have any display glitches - I must just be the ZX80 hardware that needed a bit of disabling.

I tried that ClkFreq.p on my home-made ZX80 running the NMI generator Version 4 and it checks out exactly

FRAMES TAKEN: 1863
FRAMES ON ZX81: 1863
SPEED: 100 PERCENT
EFFECTIVE CLOCK FREQUENCY:
0.8 MHZ

I'm glad that it passed the test

Regards.

Grant

[kpalser]

Grant,

Taking on board your findings regarding the free-running HSYNCs, for accuracy I reworked my main zx81 emulator loop to:
- to incorporate the sync pulse for 16 cycles every 16 cycles into the 207 cycle loop
- only have the cycle loop reset when INTACK would be generated in the central picture

Something is off in the cycle alignment of my code because a HSYNC is produced between the OUT ($FF), A, i.e. the end of the TV frame synchronization pulse / release of the 3bit ULA character row counter (termed LCNTR by Wilf Rigter). This pulse is produced even before OUT ($FE),A enables the NMI to start counting the top margin rows (see below).

As a consequence there is an extra 57th margin row (instead of 56, which is 55 NMI counted rows + 1 for sync in first horizontal line between NMI and CPU before central display output starts). There is a second consequence at the start of the central display, LCNTR is 1 and not 0, which means all the screen characters are rendered starting with their second line and finishing with the first.

The unwanted pulse occurs around the NEG operation in this fragment of G. Wearmouth assembly listing of the ZX81 ROM:

---------------
OUT ($FF),A ; end the TV frame synchronization pulse.

LD HL,($400C) ; (12) set HL to the Display File from D_FILE
SET 7,H ; (8) set bit 15 to address the echo display.

CALL L0292 ; (17) routine DISPLAY-3 displays the top set
; of blank lines.
.
.
.

;; DISPLAY-3
L0292: POP IX ; pop the return address to IX register.

LD C,(IY+$28) ; load C with value of system constant MARGIN.
BIT 7,(IY+$3B) ; test CDFLAG for compute and display.
JR Z,L02A9 ; forward, with FAST mode, to DISPLAY-4

LD A,C ; move MARGIN to A - 31d or 55d.
NEG ; Negate
INC A ;
EX AF,AF' ; place negative count of blank lines in A'

OUT ($FE),A ; enable the NMI generator.
---------------

A couple of questions:

1) About which cycle should the emulator be in the 207 cycle loop after at the OUT ($FF),A?
2) After an OUT operation releases the LCNTR is it always incremented with every the HYSNC? At the end or the beginning of the pulse?

Regards,
Kevin

[PokeMon]

Seems that I missed this thread.
Thanks for clearing the points.

[PokeMon]

4. The sync generation is permanently on.

Grant.
http://home.micros.users.btopenworld.com/zx80/zx80.html

Hmm - I am working on an extension for my video board - a sync generator to avoid loss of sync when ZX81 is running in fast mode.
So I think in point no.4 you are maybe wrong.
Sync generation is not permanently on and can (and will) be switched off when entering fast mode.

I have a ZX81 ISS1 - don't know if there is a difference to the ISS3.
On my board is a ULA 184 (not 210) which has missing back porch.
Maybe there is a difference in the behaviour through the ULA versions.

When entering fast mode, ULA #16 goes down to sync voltage level (about 2,2 or 2,3 V) - the lowest possible output level of #16.

Of course, correct me when I am wrong. But could publish a video which shows that behaviour.
Is this different on different ULA versions ?
Maybe someone could proove for the newer ULA.

[kpalser]

Hmm - I am working on an extension for my video board - a sync generator to avoid loss of sync when ZX81 is running in fast mode.
So I think in point no.4 you are maybe wrong.
Sync generation is not permanently on and can (and will) be switched off when entering fast mode.

PokeMon, sounds like an interesting extension!

I might be getting things a bit backward but I interpret Grant's fourth point as simply meaning that only HSYNCs are always being generated. And the loss of sync by the CRT in fast mode is from the user's code/key presses blocking the generation of the VSYNC, which prevents TV frames being drawn.

After months of studying the online documents describing the ZX80/1 video and reading the posts from you guys, I'm still being surprised. As a newbie please educate me if you know I'm wrong.