Sinclair ZX80 / ZX81 / Z88 Forums

As mentioned in another thread, I'm re-learning the ZX81. I've been trying from various sources including here to get an accurate measure of how many clock cycles are available to the programmer per frame. So in the end I wrote a short assembly routine to test it. It simply zeroes the BC registers then increments them in a loop during one frame, and reports the total back to BASIC-
Running this on the EightyOne emulator in PAL (British TV) mode, it reports back 700 loops; each loop takes 26 clock cycles (or should do!) so that works out to 18,200 clock cycles available. By comparison, running it on the 60Hz mode there is a paltry 384 loops, which works out to 9,984 clock cycles.

Does this look correct to everyone else? From this, it would seem the UK machine ran at almost twice the speed of the US one. On the UK machine, you have about 0.29 of the time for programme code, compared to a mere 0.15 in the USA. However, this isn't a real ZX81, though I assume the emulator is accurate in this regard. Can anyone confirm? Or have I coded something wrongly?

I gave you an idea here in this thread:

viewtopic.php?f=6&t=1684#p17317

So you have around (not exactly)
148 clock cycles available per horizontal line
110 (2x55) horizontal lines per frame
50 frames per second

This result in approx. 814.000 clock cycles per second.
This corresponds to the typical given clock frequency of 0.81 MHz when using CLCKFREQ.P

I will take a look in your program to get an idea what's wrong.

*EDIT*

No - your program is correct. If you calculate it per second you will have 910.000 clock cycles.
The EightyOne gives indeed 910.000 clock cycles which is faster than a real ZX81.
I would say this is a wrong implementation of the WAIT function which is used for the display sync - or an undocumented optimization which can be achieved on a real Zeddy as well when making the WHY WAIT mod from Wilf Rigter.
So congratulation to that program - I think you are right in all points.

Well, 18,200 clock cycles per frame multiplied by 50 frames gives about 910,000 or .91 MHz, so they're in the same ballpark. 0.81 Mhz would be about 16,200. Maybe the EightyOne emulator is not quite accurate in this regard.

*EDIT*

Seeing your edit PokeMon while I was typing my reply, I take it I need to aim at about 16,000 then for a real, unmodded ZX81..?

Yes - something like that - 16.000 if you count on PAL.

I will write a personal apology to Americans on my software

i never actually tried to work it out, but i always reckoned on about 20,000 cycles ( uk pal ) available per frame for the user code, maybe i should try finding out, also it will be different if you have done Wilf Rigters why wait circuit.


regards Andy

Andy, I don't have a real ZX81 available, it would be interesting to see what result my program (above) gives on one. My "target platform" (oh ho!) is a standard, unmodded ZX81, without any improvements, UK version. (There's no way my intended code will get done in the time available on the US version, sadly).

Andy Rea wrote:i never actually tried to work it out, but i always reckoned on about 20,000 cycles ( uk pal ) available per frame for the user code, maybe i should try finding out, also it will be different if you have done Wilf Rigters why wait circuit.


regards Andy

Well - this can not be.
As you have 207 cycles per hsync and the NMI routine takes 32 cycles and the call of NMI would take another 11 cycles (like an RST instruction) you have maximum 164 clock cycles per line or 2*55*164=18.040 per frame. This means there is no single WAIT cycle and all NMI lines are executed in full length (which isn't true because of startup code in the margin routine). So assuming only 109 lines instead of 110 with code execution (2 half lines) would be around 17.876 minus the WAIT states.

doing the math i have to concur with Karl it seems like it weill be around 18,000 cycles, as for not enough cycles to do a task never say never, Bob Smith has proved time and time again that you can do far more than expected, Hell Jim Bagley has done the impossible and made it possible to stream video

I'll see if i get time at the weekend to run a few tests on various hardware

Regards Andy

I have to correct myself during some measurements this evening.
I thought that there will be 55 NMI periods for the user program plus one synchronization but it is in fact only 54 (!).
My measurements with my logic analyzer confirmed this.
I think I missed the INC A instruction after NEG instruction in the margin routine at $0292.

So all in all the picture has only 310 lines as it should be 312 (to be very exact 312.5 per frame).
So many TVs accept this resulting in 50.6 Hz nominal.
I guess the reason for this is the simplification of the system while the vertical sync is exactly 6 lines or 384us.
So I think Sinclair did use 56 lines as a multiple of 8 when the scan line counter was reset with the end of vsync pulse.
And they don't make a difference at the bottom margin which could be in theory 2 lines more than the top margin.
I think they simply used the same value resulting in 310 lines which corresponds to the investigations from Retrotechie.

So to be very exact, following is happening in a TV frame:

6 lines for vertical sync while reading the keyboard
1 line preparing the user program and start NMI counter
53 full lines user program execution
1 line sync together with WAIT for the very first display line
1 line preparing the video execution
192 lines video execution
1 line preparing the user program and start NMI counter
53 full lines user program execution
1 line sync together with WAIT for the very first display line (useless in the bottom margin)
1 line preparing the vsync start and update FRAMES variable

Give all in all 310 lines.

So we have only 53 full lines of program execution and one half line (approx.) for every margin which gives 107 lines only for program execution.

From the 207 clock cycles are 32 cycles taken for the NMI routine, 11 cycles to jump to NMI routine (similar to the RST instruction) give resulting 164 clock cycles. If no WAIT mod is taken, you have to calculate 16 clock cycles duration of sync/NMI (5us) while normally the WAIT will be generate in the second clock cycle of any M cycle. Expect the durations (M1=4, M2/M3=3, IO=5) you have an average of 4 clock cycles per M cycle (maybe a bit less) and an average of 2 cycles lost before WAIT is entered. So you would calculate a duration of 14 clock cycles waiting in an unmodified ZX81.

So this give a net time of 207-32-11-14=150 cycles.
When having approx. 107 lines with program execution we have about 16.000 cycles per frame.
You may measure a bit more in practice but I wouldn't say not more than 3 or 4% - so maximum 16.500 cycles I would say.
You can result more of course when doing hardware modifications - but when developing programs you can not expect this.

I think the EightyOne is alread modified with the WHY WAIT mod from Wilf Rigter, realized in software.
That's why it is faster than a real Zeddy.