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

[RetroTechie]

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.

Yes hsyncs are always on, apparently they even appear in the mic signal when SAVEing programs to tape.

This should be easy to prove. Like have a program wait for a new frame, then run in FAST mode for a little while (short enough to not last outside top / bottom border area, long enough to last a number of hsync periods). I'm 99,99% sure this would have 0 effect on horizontal synchronization since the ULA takes care of that. A smart programmer might even takes this into account, and write some code that's mostly in FAST mode, but keeps TV sync (hor. and vert) and perhaps even display image every X frames.

So you're talking about vertical sync only which is software-generated like on the ZX80. Personally I don't see much point in adding hardware for that: if FAST processing takes long enough to last entire frames or longer, and there's nothing to look at anyway in the mean time, what's the problem with a little flicker to announce "I'm back" ?

AFAIK there's no -significant- difference between ULA versions other than the well known back porch issue.

[Paul]

If I have this right there is a problem with actual TVs going mad when the screen has nothing to show. Some switch off, mine walks though the different AV inputs to have a look if there might be something displayable.
So after fast, I need to reselect my AV input again.
Therefore I use my monitor instead of TV. This will wait for five minutes without proper sync before going to standby.

[kpalser]

Well, this thread does seem to have reached the consensus/acceptance that the HYSNC is always running. So, to reiterate my questions from yesterday:

1) About which cycle should the emulator be in the 207 cycle loop after at the OUT ($FF),A releases the 3 bit ULA character row counter (LCNTRL)? Which I would assume could be established by knowing how many cycles would have passed since the the last INTACK at the end of the central display before the bottom margin. This INTACK would have reset/resynchronised the 207 cycle for the last time before LCNTRL is reset and then released again.

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? Sorry to be pedantic over 16 cycles difference. I just want absolute accuracy. Any ideas what test could be used to establish this?

TIA
Kevin

[PokeMon]

Personally I don't see much point in adding hardware for that: if FAST processing takes long enough to last entire frames or longer, and there's nothing to look at anyway in the mean time, what's the problem with a little flicker to announce "I'm back" ?

Well like Paul said, with modern TV's (LCD/Plasma) you don't have that flickering. The modern TV's have nearly all some kind of "loss of sync" detectors and decide to do something after a (short) tmeout. Do something can be switch off/standby, change source or similar. If you have programs running in fast mode longer than 60 seconds you could run in that inconvenient handling of modern TVs. Even the load routine executed in fast mode has potential for longer fast mode running periods, especially if you have to repeat. That's worth to have a standby sync generator an a video out board.


And to the main stuff / point 4 (hsync always):
Lets say the hsync is overloaded by a very loooooooong vsync when running in fast mode.

[1024MAK]

Well like Paul said, with modern TV's (LCD/Plasma) you don't have that flickering. The modern TV's have nearly all some kind of "loss of sync" detectors and decide to do something after a (short) tImeout. Do something can be switch off/standby, change source or similar.

My Sharp Aquos LC-19D1E-BK LCD TV works okay on the TV UHF connection. Switching between SLOW, FAST and back to SLOW it responds quickly. If there is a break in the picture for a few seconds the only annoyance is the input source selection appearing in the top right corner for a few seconds (the picture having come back quickly).
When using a composite video connection if there is a break in the picture for a few seconds it takes 2.75 to 3 seconds approx to produce a display after the Zeddy starts producing a picture again. You also get the input source selection appearing in the top right corner when the picture comes back.
Note 1: a lot of the modes and options (including auto-switch to standby) on this TV can be changed via the extensive menu system.
Note 2: the above tests were carried out with two Zeddies, each using the 2C184E ULA.

Mark

[Paul]

On the UHF input my tv happily waits five minutes before shutting down. But the zeddy will only display its picture for about 30 seconds, then my tv needs retuning and th channel is lost. Therefore I use front Av. But in fast mode it searches my inputs for a valid signal. And my sat receiver always has one.
Therefore a correct sync all the time would be helpful.

[1024MAK]

But the zeddy will only display its picture for about 30 seconds, then my tv needs retuning and th channel is lost.

This is caused by the modulator output frequency drifting as both the modulator warms up and due to the heat from other components in the Zeddy increasing the heat in the case.

I get the same problems with my Zeddies and Spectrums. If I used a UHF connection for my other computers (e.g. Acorn BBC Micro) it is likely to also have some tuning drift.

After about half an hour the temperature in the computer stabilises so that the rate of tuning drift slows allowing the UHF to be usable.
Some TV's are better than others at tracking this tuning drift. It depends on the AFC circuit / function in the TV.

On my Sharp Aquos I have about 8 channels each fine tuned to a sightly different frequency. So as the Zeddy or Speccy warms up I just channel hop until I find a good picture

Synchronisation
Of course for a ZX80 with a custom video circuit and custom ROM or a ZX81 using a custom ULA and a custom ROM, it may well be possible to produce a continuous full composite sync (both horizontal and vertical combined) signal. Then have the ROM synchronise to this signal (that is wait for the next vertical sync before starting to display the picture).

For standard Zeddies it would not be that hard to produce a vertical sync generator signal, but how do we synchronise it to the Zeddies horizontal sync is the first question. The second being how do we detect when the Zeddy is producing a valid TV picture? As we have to switch between the auto sync and the ROM/ULA generated vertical sync...

Mark

[PokeMon]

For standard Zeddies it would not be that hard to produce a vertical sync generator signal, but how do we synchronise it to the Zeddies horizontal sync is the first question. The second being how do we detect when the Zeddy is producing a valid TV picture? As we have to switch between the auto sync and the ROM/ULA generated vertical sync...

It depends on realization. You could do synchronize it with the system clock and programmable counters but I decided against this solution because:
a) this precision is not necessary
b) more chips needed
c) board could not work with external signals, when just video comes out the zeddy (or other computers) and no clock available
Could do it better an cheaper with some timers realized with some resistors, capacitors and a driver.
Will extend my SMD video board.

Detecting a valid picture (or better say a valid sync) is quite easy. If sync signal is missing for a longer time (the L-O-S chips algorhythm is a few milliseconds) the standy by sync generator takes control, if sync signal comes back it is stopped. So will maybe give a very short flicker when switching (maybe you see, maybe not) but prevent the TV from thinking of doing something like switching channel or switching off.

[gozzo]

See the post "improved FAST mode display...???" in this forum....

[Andy Rea]

Just got back from Scotland, but off the top of my head IIRC when fast mode is selected from within basic using the FAST keyword, the video output is always LOW, this is like an extended Vsync pulse, so the Hsyncs are masked.

Secondly the Hsync counter is reset on ANY INTACK not just during the video generation and the actual Hsync/nmi pulse occurs 16 clock cycles AFTER the INTACK is released.

Regards Andy