CLKFREQ.P benchmark on 2K ZX81

Discussions about Sinclair ZX80 and ZX81 Hardware
sheddyian
Posts: 47
Joined: Sun Nov 15, 2020 12:53 pm
Contact:

CLKFREQ.P benchmark on 2K ZX81

Post by sheddyian »

My "best" ZX81 currently has 2K onboard RAM, I've not yet modified it for 16K. Looking at the posts about the ZX81X2 ROM, I saw a benchmark program being used. I wanted to have some numbers to compare as I progress with the tinkering, eg increasing the RAM, fitting the Why Wait mod, installing a different ROM etc. So I downloaded the benchmark.

The benchmark is the one that says C 10/1991 CARLO DELHEZ on the screen.

The version included in the earlier ZIP file posted in this thread viewtopic.php?f=5&t=2986 just caused the 2K ZX81 to freeze with a white screen when loaded.

I located another saved .p file on the net by searching for the Author's name and found the same program. This one completes the load and returns 0/0 but there is no listing to see and nothing to run. I tried both versions a number of times, results were consistent - white screen or 0/0 .

Looking at the reported program size when loaded into tapeutils on the laptop, I think they're both over 2K in size. But not by much.

So I loaded the original into an emulator, edited down the code by removing the REMs and the (C) message and a few pretty PRINTs, saved it again and it now comes in at 1911 bytes. This loads and runs successfully on my 2K ZX81.

I've attached this reduced file in case it's of use to anyone else.


But now a question. The output from the program running on either of my 2K ZX81s in SLOW mode gives me this output :

Frames taken : 2237 (sometimes 2238)
Frames on a ZX81 : 1869
Speed 83.5 Percent
Effective clock frequency : 0.67MHZ

So, if I'm understanding the output correctly, my ZX81 is running slower than.. a ZX81?? :shock:

BUT.. I have a distant vague recollection that an unexpanded ZX81 runs slower than one with 16K. Is that correct? Would that explain these numbers? Or have I misunderstood something?




Thanks

Ian
Attachments
CLKFRQ2K.p
(1.87 KiB) Downloaded 138 times
Moggy
Posts: 3231
Joined: Wed Jun 18, 2008 2:00 pm

Re: CLKFREQ.P benchmark on 2K ZX81

Post by Moggy »

A quick simple reply is that as the zeddy spends most of its time creating the screen display it follows that only a short time is allocated to actual work. The 0.67 figure reflects the effective speed of the CPU. It varies a tiny fraction between zeddies as the cheap ceramic resonator it uses for timing is hardly atomic clock standard but your figure is quite normal.

When used with the x2 ROM this figure increases to about 1.2/1.3 mhz or as I like to call it Commodore 64 speed! :lol:

The x2 ROM isn't a cure all for a slow BASIC such as Sinclair's and in some cases no difference in speed can be discerned nor will it speed up machine code, so it depends on your BASIC application, but I have found it bloody quick for my purposes and if one wants to create a souped up zeddie then I would say this ROM has to be included in any upgrade consideration.

Having said all this I sense a guru appearing. :lol:
sheddyian
Posts: 47
Joined: Sun Nov 15, 2020 12:53 pm
Contact:

Re: CLKFREQ.P benchmark on 2K ZX81

Post by sheddyian »

My main area of confusion is the "frames on a ZX81 1869" which is a fixed value, and which I'm taking to be a score to compare against. Thus, I also expect my unmodded ZX81s to give that figure for their individual score. They don't. I get a consistent higher (=slower) figure.

Is that figure of 1869 wrong , is it an expanded (=faster?) 16K ZX81 or am I misunderstanding?

Thanks

Ian
Moggy
Posts: 3231
Joined: Wed Jun 18, 2008 2:00 pm

Re: CLKFREQ.P benchmark on 2K ZX81

Post by Moggy »

The 1869 fixed value represents an "ideal" frame value for a ZX81 IE the amount of frames that pass to complete the test,in this case 1869,how the author arrived at that value I cannot say maybe he based it on one of his own computers or some mathematical precept.
After the test is run the program counts the actual amount of frames that have passed using the frame counter values held at 16436/7 (initially set to 255 in lines 45 50 and 60 of the program and decremented as the test runs.)

Then with a bit of maths works out the percentage speed of an individual ZX81 compared to the ideal.

Different zeddies run at slightly different speeds for the reason I mentioned in my previous post, different resonator speeds. A zeddy with a tip top perfect resonator should match the ideal of 1869 frames to complete the test but in reality seldom does.

My own test machine for example took 1903 frames to complete the test giving a rating of 98.2 % of the ideal and with an effective CPU speed of
.79 mhz, a reading I personally class as quite good .

When the X2 ROM is switched in it took only 905 frames to complete the test giving it a rating of 208.5% or just over double the speed of the old ROM with an effective CPU speed of 1.65 mhz.

As for your own readings they are the readings I would expect from a US 60 cycle machine which is slightly slower than the UK 81's either that or you have some very slow resonators fitted'

Whether or not fitting a RAM pack or internal RAM modification effects the timings compared to an unexpanded/unmodified computer I cannot say as that is beyond my level of technical ability so would have to let others answer that question.
Moggy
Posts: 3231
Joined: Wed Jun 18, 2008 2:00 pm

Re: CLKFREQ.P benchmark on 2K ZX81

Post by Moggy »

I should have added also that 81's were fitted with ROM/RAM chips manufactured by different companies during their life cycle, Hitachi,Mostek and NEC for example and it is possible these different chips could somehow impact the test readings experienced.
I have found If I fit NEC ROMS to my 81's then I have timing issues with EPROM and battery backed memory boards I posses,any other ROM being ok.

In other words compare like for like.
If your 81 has for example a Mostek ROM and NEC RAM chips then a timing comparison should be made with a similar setup.

My test example is fitted with a ZXpand memory module, Hitachi EPROM's both for normal and X2 operation and a Zilog CPU.
Does this make a difference? I cannot say but would only compare a like for like setup to have any meaning.
sheddyian
Posts: 47
Joined: Sun Nov 15, 2020 12:53 pm
Contact:

Re: CLKFREQ.P benchmark on 2K ZX81

Post by sheddyian »

A quick play with EIghtyOne emulator, and my 2K version of the test program.

If I set the RAM to 2K, I get a similar result to my real 2K ZX81s.

If I set the RAM to 16K, I get a score close to 1869, the 100% figure quoted in the program.

So, from the emulator point of view, 2K RAM is slower than 16K RAM - I wonder if this is due to the display file resizing/shrinking when there's not much memory?

I also notice that just removing some of the REM and PRINT statements that are outside of the test loops has affected the speed reported by the code!

I'll do some more tests tomorrow. Thanks for giving me your scores, am interested in comparing. Hopefully I'll get the 16K upgrade fitted soon then I can see if a real hardware ZX81 also speeds up. I predict it will.

Ian
User avatar
1024MAK
Posts: 5101
Joined: Mon Sep 26, 2011 10:56 am
Location: Looking forward to summer in Somerset, UK...

Re: CLKFREQ.P benchmark on 2K ZX81

Post by 1024MAK »

Five things:
  • The various different chips used *should not* affect the system speed. The Z80 (actually a 4MHz Z80A part) runs at approximately 3.25MHz regardless of which chips are fitted. This speed does vary a bit, as Moggy says, due to the slight differences in the 6.5MHz resonator fundamental frequency. If a chip is too slow, then either the system will crash or you will have display issues.
  • All the RAM, no matter if internal 1k, internal 2k, or a RAM expansion, it all runs at the same speed (but see below).
  • TS1000 / U.S.A. ZX81 machines configured for 60Hz television/video still run the Z80 at 3.25MHz, but because the video/screen is updated more often, there is less processor time to run a user program in SLOW mode (compared to a U.K./European 50Hz model).
  • The amount of available RAM affects the speed of BASIC. If there is less than about 4K bytes of RAM, the screen area operates in collapsed mode to reduce the amount of RAM that is needed. Taken to the extreme, the display file can be only a handful of bytes. As the program runs, every time the screen content changes (more text for example), the size of the display file changes. Then everything above the display file has to be shuffled about... With about 4K bytes or more of RAM, the display file is always fully expanded to the full screen size. So no shuffling is needed.
  • Any changes whatsoever to a published BASIC program will affect the speed of processing of that program. Especially if FOR-NEXT, GOTO or GOSUB commands are being used. Remember, the BASIC interpreter has to go and search for the wanted line whenever it jumps forward or back within a program.
I hope this helps ;)

Mark
ZX81 Variations
ZX81 Chip Pin-outs
ZX81 Video Transistor Buffer Amp

:!: Standby alert :!:
There are four lights!
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb :!:
Looking forward to summer later in the year.
Moggy
Posts: 3231
Joined: Wed Jun 18, 2008 2:00 pm

Re: CLKFREQ.P benchmark on 2K ZX81

Post by Moggy »

Thanks for the info regarding different chips,Mark. My zeddy education continues. :D
User avatar
Paul
Posts: 1511
Joined: Thu May 27, 2010 8:15 am
Location: Germanys west end

Re: CLKFREQ.P benchmark on 2K ZX81

Post by Paul »

As a hint for easy remembering:
Zeddy isn't clever enough to insert waitstates if a chip isn't fast enough. In this case it just does what it's it's supposed to do: it fails ;)
In theory, there is no difference between theory and practice. But, in practice, there is.
sheddyian
Posts: 47
Joined: Sun Nov 15, 2020 12:53 pm
Contact:

Re: CLKFREQ.P benchmark on 2K ZX81

Post by sheddyian »

1024MAK wrote: Sat Jan 09, 2021 11:55 pm [...]
[*]The amount of available RAM affects the speed of BASIC. If there is less than about 4K bytes of RAM, the screen area operates in collapsed mode to reduce the amount of RAM that is needed. Taken to the extreme, the display file can be only a handful of bytes. As the program runs, every time the screen content changes (more text for example), the size of the display file changes. Then everything above the display file has to be shuffled about... With about 4K bytes or more of RAM, the display file is always fully expanded to the full screen size. So no shuffling is needed.
Thanks for clarifying that. And that is exactly what I'm seeing. I ran the CLKFREQ program on an emulator, and found it runs faster with RAM set to 16K compared to 2K.

And I've just fitted an onboard 16K upgrade to my best ZX81, and now getting similar results there too.

I also note that when the ZX81 had only 2K onboard, the screen would sometimes glitch - ie when randomly plotting, and the benchmark would glitch when plotting the pattern as part of it's test. I had imagined this was a failing ULA or bad connection, but I noticed the emulator doing it too. Now I have 16K, this glitching is gone. Something connected with the display file shrinking?
[*]Any changes whatsoever to a published BASIC program will affect the speed of processing of that program. Especially if FOR-NEXT, GOTO or GOSUB commands are being used. Remember, the BASIC interpreter has to go and search for the wanted line whenever it jumps forward or back within a program.
This makes sense. I was still surprised that the difference was measurable in the CLKFREQ program - removing some REM statements would cause the program to run slightly faster, even though the REMs weren't part of any test loop.

Thanks for your comments

Ian
Post Reply