Beginner's sync questions

[zx80nut]

Wilf's page is excellent, and I used it to get some early information. However, the timing details that he gives is incorrect for the ZX80 (and also presumably the ZX81). They may be how his circuit uses them, but is not the same as the original.
Also, his circuit is an "equivalent", but is not accurate with the original, due to incorrect sync timing and also the sync is incorrectly re-synchronised with the VSYNC. It's very good, but not accurate.

Grant.

[PokeMon]

Maybe this information can help as well.
http://www.user.dccnet.com/wrigter/inde ... 81WAIT.htm

He's talking about Jitter which can occure when executing code till interrupt takes effect. This is done via wait states and synchronizing to NMI.
I don't know if this refers to original hardware or modificated hardware but sounds plausible.
So just for information what else could be the problem with exact sync. Regardless wether accurate or not.

[zx80nut]

Yeah, Wilf's pages are fascinating - he's done an amazing job.

By the way, I've been doing some updates to the timing pics page, and I have included real ZX81 scope traces to show which timings are identical to the ZX80, and which are different.
The only difference in timing is the ROM enable during the refresh. The NOP injection and Char out are identical, so timings observed, or calculated by following the ZX80 scematic can also be applied to the ZX81. This implies that the ZX81 internal ULA logic is very similar (functionally identical) to the ZX80 schematic in the character output and data bus control (apart from the ROM CS, as mentioned above).

Updated pics here...

http://home.micros.users.btopenworld.co ... ePics.html

You will probably need to refresh the page in your browser, as it should show the update date of "2nd October 2011" near the top.
...any ideas how I can force page invalidation, as I often need to do a forced page refresh in by browser (Firefox) when I have updated a page.

Regards.

Grant.

[PokeMon]

You will probably need to refresh the page in your browser, as it should show the update date of "2nd October 2011" near the top.
...any ideas how I can force page invalidation, as I often need to do a forced page refresh in by browser (Firefox) when I have updated a page.

Just set a meta tag in your html header of your page:

<meta http-equiv="expires" content="0">
This will reload a page every time its clicked, can use any counter instead of 0 in seconds, e.g. content="60" reloads after 60 seconds of last delivery.

See more here:
http://www.i18nguy.com/markup/metatags.html

[zx80nut]

Oooh - thanks PokeMon

I'll update the HTML.

Grant.

[Thommy]

Sorry, some further questions, concerning the ZX81 specifically.

Wilf's page asserts, under point 5, that if the NMI generator is disabled then an input on port fe "turns off the HSYNC generator (only if NMI is off)" and an output on port ff "turns on the HSYNC generator". Is it possible that all he observed was the way that hsync and vsync are combined — i.e. sync output is active if either is active? Grant's and Wilf's pages would otherwise appear to be in disagreement.

(EDIT: to be clear, since an alternative Wilf source has been posted, those quotes come from http://www.user.dccnet.com/wrigter/inde ... torial.htm)

Otherwise my understanding, primarily from Grant's page is that:

• the ZX80's HSYNC generation logic is completely absent;
• instead there's the counter, on the same clock as the CPU, which is reset on interrupt acknowledge and overflows immediately after value 206;
• HSYNC is generated if the counter has a value in the range [16, 31] (inclusive);
• port accesses (input or output) enable or disable NMI generation — upon a port access A1 is low then NMI generation is disabled, if A0 is low then NMI generation is enabled;
• if NMI generation is enabled then the NMI line is active exactly when HSYNC is being output;
• wait is active if NMI is active and halt is inactive.

I'm not 100% confident particularly on that port decoding logic. I'm actually a little unclear on port logic in general, especially with respect to what differences may exist between ZX80 and ZX81 if any. Sources don't tend to be explicit.

[zx80nut]

Hi Thommy.

For the ZX81, I wrote a small program to disable the NMI pulses then loop, preventing any other program execution.
When doing this, the syncs are still produced, but no NMIs produced.
I haven't seen anywhere when testing the ZX81 where the syncs are (or can be) disabled.
Even during save, the syncs are still present, causing lots of glitches to the "mic" signal (which are then filtered with the output r/c circuit).
I would assume that if they can be disabled somehow then they would have been turned off during the save.

... VSYNC low ties the output low, so it is possible that he is seeing that behaviour, as you point out.

I think Andy Rea has also been doing some investigation in some of these areas - Andy, any comments?

Regards.

Grant

[Andy Rea]

Hsyncs ARE free running you CAN'T turn then OFF.

but you can reset them by enabling int's and by careful use of the refresh register cause an int to occur which will then be acknowledged by the CPU this IntAck (M1 and IORQ both low) it can be noted that on system that reset the hsync's when vsync goes active that instead of the usual diagonal stripes when waitibg for a tape signal you will see vertical bars with 3 or 4 small breaks, this behaviour is what led me to deepen my investigations when developing my ULA replacement (which is still under development !) I too wrote some small test programs that invovled switching Vsyncs on and off and observing the output on an oscillascope, it was back at the end of april (2011) that i made this discovery, up until that point i had held the belief that hsync where reset by vsync.

and yes if vsync is low you will not see the hsync but they are stilll happening, this can be verified by controlling the lenght of you vsync pulse and you can determine to the exact clock cycle where the next hsync will occur once vsync is released.

Erm i've probably missed out loads of important stuff but i'm more of a zx81nut than ZX80.

Andy

[zx80nut]

Regarding I/O mapping.
It appears (I haven't verified this 100%, maybe someone else has) than the lowest 3 bits are reserved for sinclair hardware.
Minimal decoding depends on a single bit of the lowest 3 being low at any time (except for "end VSYNC", as all other bits have been used, and accidental triggering doesn't matter)

Code: Select all

OUT
xxxxx000
xxxxx001
xxxxx010
xxxxx011  <- FB Used for printer
xxxxx100
xxxxx101  <- FD Used to stop NMI
xxxxx110  <- FE Used to start NMI
xxxxx111
xxxxxxxx  <- ANY will end VSYNC, FF used in ROM to prevent interference
     ^^^
     |||_ Start NMI
     ||__ Stop NMI
     |___ Printer

IN
xxxxx000
xxxxx001
xxxxx010
xxxxx011  <- FB Used for printer
xxxxx100
xxxxx101  
xxxxx110  <- FE Used to read Keyboard (etc) / Start VSYNC
xxxxx111
     ^ ^
     | |_ Read keyboard
     |
     |___ Printer

So..
/Bit 0 is the start NMI bit (out) or read keyboard, cassette and US bit (in)
/Bit 1 is the stop NMI bit (out)
/Bit 2 is the printer bit (in/out)

As a result, other hardware would need to have port addresses that always have the bottom 3 bits set to 1.
...this would effectively reset the VSYNC, but as it is always already reset when the program is running in slow mode, it won't make any difference

EDIT: (8thOct) Updated "Out" table above, to show ANY will reset VSYNC, as mentioned in Andy's comments below

Regards.

Grant

[Andy Rea]

Err...

Ok if NMI is off, OUT ($FD),a

--- then you can do...

IN a,($FE) which does 2 things, reads port FE (leyboard,tape,us/ukbit) and starts VSYNC (goes low)

further IN a,($FE) will read port FE but have no other effect.

IN a,(any port) will read any port but otherwise will have no effect.

OUT a,(any port) will stop the VSYNC

--- then you can do...

OUT ($FE),a which will restart the NMI's

Erm maybe thats not any clearer

Andy