Time Available For Application Code On ZX81

[IanB]

Well, the easiest way to get an answer will be if somebody runs the test program on a real unmodded ZX81

[PokeMon]

Well - for me not necessary as I know what will happen. Measured out yesterday again.
I swore it would be 16.000 +/- 3% on an unmodified Zeddy running PAL and the original ROM.
Any volunteers with some time may run your measurement program.
The calculation is by the way confirmed with the measurement of CLCKFREQ.P which shows a calculated running frequency of 0.80 or 0.81 MHz on a usual ZX81.
16.000*50=800.000=0.8 MHz.

Could and will give much more on the Uber Zeddy from Andy, quite sure.

[IanB]

Well I'm targetting 16000 at the moment. It's quite crucial to me because I need a dynamic display file, and moving bytes takes a lot of clock cycles 21 per byte for an LDIR, you can shave some off with an LDI block and fewer loops, like

LDI
LDI
LDI
LDI
jp pe, LOOP

-that is 18.5 clocks per byte, but that costs crucial bytes of code space. Speed and compactness are enemies!

But anyway, I don't see any way to get that all done in the lesser time on a US model. As it stands, my worst case will take at least 10k clock cycles just to adjust the display file, which has to be done in one frame gap. This is why clock cyles matter so much to me

[PokeMon]

Well is it really necessary to update so much bytes ?
You may take a look at Wilf Rigter's WRX1K which does HiRes in a smaller area on a 1k Zeddy.
Works in emulator as well as long as WRX is activated in the hardware options.

http://www.user.dccnet.com/wrigter/inde ... khires.htm

I think the point on the 1k games are the cleverness used to handle with all restrictions.
Ofcourse it is always a challenge.

[IanB]

Yes, I'm working lo-res and the standard display. The intention is full screen graphics in 1K, among other things. This means judicious use of short lines

[Andy Rea]

Still to pull out the Zeddy and do some real world testing but for what its worth...

you can update the display ever other frame for 25FPS or every 4th frame for 12.5FPS ( probably as slow as you would want to go) which in turn gives you twice or 4 times as many clock cycles between screen updates.

Regards Andy

[PokeMon]

Reducing the screen has double effect.
You need less time for changing and you could have more running time when reducing displayed lines and increase margin lines.
This could be done with not too much extra code, I think.

You have to modify IX register and increase AF' register in your routine when called - something like that.
Worth to experiment with.

[Andy Rea]

indeed a reduction of 8 scanlines ( i.e. 1 character line ) should yield 1312 extra clock cycles per frame

Andy

[IanB]

Andy, Pokemon-

I'm aiming for full screen display and, since this means rearranging the display file (moving which lines are long and short), it has to be done between fields, to prevent jittering and artifacts, etc.

[Andy Rea]

wow i am surprised

PAL
on a standard unmodified zeddy i get 611 loops so approx 15886 cycles.
with Wilfs why wait mod i get 670 loops so approx 17420 cycles.
with a 2X turbo mode (6.5Mhz) i get 1405 loops so approx 36530 cycles. ( oddly more than double standard )

and... because i can...

20Mhz Turbo mode i get 4916 loops so approx 127816 cycles !

regards Andy

EDIT: at 60HZ US mode
standard 335 loops so approx 8710
2x turbo 711/712 loops so approx 18499 cycles