Atom speed benchmark....

emulators, hardware and classic software for atom + system machines
Post Reply
Prime
Posts: 2943
Joined: Mon Jun 01, 2009 12:52 am
Contact:

Atom speed benchmark....

Post by Prime »

Hi All,

Is there a speed benchmark program for the Atom, that will give a speed rating of some sort?

However it *MUST NOT* require a 6522......

Cheers.

Phill.
User avatar
IanS
Posts: 1830
Joined: Mon Aug 31, 2009 7:02 pm
Contact:

Re: Atom speed benchmark....

Post by IanS »

I can't think of anything, but it would almost have to involve some sort of manual external timing.

So could you time how long the rom checksum prog from the manual takes and compare it to a standard atom?

(Is this related to your Pi pico work?)
User avatar
BigEd
Posts: 4234
Joined: Sun Jan 24, 2010 10:24 am
Location: West Country
Contact:

Re: Atom speed benchmark....

Post by BigEd »

Perhaps this, from an earlier thread:
BigEd wrote:
Sat Dec 21, 2019 12:46 pm
A quick Atom benchmark, this seems to take about 5 sec on both this latest Atom and also on HTeMuLator:

Code: Select all

FOR I=1 TO 12345;NEXT
(Might be good to compare with a real Atom!)
User avatar
roland
Posts: 4394
Joined: Thu Aug 29, 2013 9:29 pm
Location: Born (NL)
Contact:

Re: Atom speed benchmark....

Post by roland »

You can use the 60Hz Vsync signal as a time base:

Code: Select all

Reset your counter
Wait for low to high transition
Increment the counter
Check if Vsync is still high, if so jump to previous step
End -> result is in counter
Based on the value of the counter you can calculate you the clock frequency of the 6502.

I don’t have a working programme for it yet. If you want I can write it one of these days.
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:
bprosman
Posts: 464
Joined: Sun Mar 29, 2015 11:27 pm
Contact:

Re: Atom speed benchmark....

Post by bprosman »

From the 80's I can recall there was some sort of benchmark calculating prime numbers.

https://www.youtube.com/playlist?list=P ... QifIOApqdp
User avatar
MrGpG
Posts: 76
Joined: Fri Mar 26, 2021 11:26 am
Location: Wet Wales - East Cardiff as we say in the 'Port. Tidy
Contact:

Re: Atom speed benchmark....

Post by MrGpG »

The Rugg / Feldman benchmarks come up from time to time: https://en.wikipedia.org/wiki/Rugg/Feldman_benchmarks

The main point as I remember it - is when benchmarking to use code as close as possible to that of Rugg / Feldman - its not an optimisation test, rather a comparative test.

Interesting to update Wikipedia with Atom / Elk etc.

Glen
User avatar
roland
Posts: 4394
Joined: Thu Aug 29, 2013 9:29 pm
Location: Born (NL)
Contact:

Re: Atom speed benchmark....

Post by roland »

The Atom is already in the results as you can see in this table:
Screenshot 2021-06-25 at 11-10-57 Rugg Feldman benchmarks - Wikipedia.png
It performs quite well. The table notes that the BBC Micro was the fastest of the 8-bit Basics. Can you imagine who won this "contest" if the Atom was running at 2 MHz :mrgreen:

However, I think it's quite hard to measure the exact time with a stop watch.
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:
User avatar
BigEd
Posts: 4234
Joined: Sun Jan 24, 2010 10:24 am
Location: West Country
Contact:

Re: Atom speed benchmark....

Post by BigEd »

MrGpG wrote:
Fri Jun 25, 2021 9:53 am
Interesting to update Wikipedia with Atom / Elk etc.
The Beeb and Atom are already in there, and the Electron results are available here if anyone would like to add them.

On the topic of prime numbers, we have this thread:
Short and sweet prime numbers in Basic

(It's a pity those videos of prime testing "Welcome to the Prime Number Generator" don't seem to show the source code... although some ideas in this thread.)
Last edited by BigEd on Fri Jun 25, 2021 11:02 am, edited 1 time in total.
User avatar
BigEd
Posts: 4234
Joined: Sun Jan 24, 2010 10:24 am
Location: West Country
Contact:

Re: Atom speed benchmark....

Post by BigEd »

roland wrote:
Sat Jun 19, 2021 6:07 am
You can use the 60Hz Vsync signal as a time base
An excellent plan! No stopwatch needed.

It looks like CALL FE66 would be the way to wait for a new frame? And checking bit 7 of B002 the way to see if the next frame has started.

(Here's JSAcorn by CommanderCoder to try things out...)
User avatar
oss003
Posts: 3492
Joined: Tue Jul 14, 2009 12:57 pm
Location: Netherlands
Contact:

Re: Atom speed benchmark....

Post by oss003 »

However ..... this only works in an emulator if the 60Hz signal is emulated accurately .... ;)

Greetings
Kees
User avatar
hoglet
Posts: 10351
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Atom speed benchmark....

Post by hoglet »

I'm not sure how practically you would use VSYNC to measure the execution time of a program.

Maybe if the program is short (less than one VSYNC) you could:

- Wait for VSYNC to start
- execute short program
- Loop with a counter testing for the next VSYNC start

You would have to cycle count the counter loop, and subtract this from the VSYNC interval.

But what if the program takes longer than one VSYNC?

Dave
User avatar
roland
Posts: 4394
Joined: Thu Aug 29, 2013 9:29 pm
Location: Born (NL)
Contact:

Re: Atom speed benchmark....

Post by roland »

Your program has to be short enough to run within one VSYNC cycle or must count the cycles but that takes time. Benchmarking the calculation of 1000 Pi decimals in Basic won't work here :lol: But a simple counter loop should be working.
FPGAtom: 512 KB RAM, Real Time Clock and 64 colours
MAN WOMAN :shock:
User avatar
BigEd
Posts: 4234
Joined: Sun Jan 24, 2010 10:24 am
Location: West Country
Contact:

Re: Atom speed benchmark....

Post by BigEd »

I tried this, and got the result 3. So a much faster Atom would get 1 or 2, perhaps? I think we need a bit of machine code to do the counting. Or, we need to find and fix the error in my program!

(Edit: other way around: a faster Atom would score higher, so no difficulty there.)
Atom-Bench-Attempt.png
Atom-Bench-Attempt.png (18.36 KiB) Viewed 400 times
Last edited by BigEd on Fri Jun 25, 2021 6:52 pm, edited 1 time in total.
User avatar
hoglet
Posts: 10351
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Atom speed benchmark....

Post by hoglet »

BigEd wrote:
Fri Jun 25, 2021 11:27 am
Or, we need to find and fix the error in my program!
The only bug I can see is your tests should be <128 and >=128.

GOTO is quite slow, this version gets to 7:
Screenshot from 2021-06-25 11-58-16.png
An assembler version would be better. Give me a mo....

Dave
User avatar
BigEd
Posts: 4234
Joined: Sun Jan 24, 2010 10:24 am
Location: West Country
Contact:

Re: Atom speed benchmark....

Post by BigEd »

Nice! Can Atom Basic do multi-statement lines? Is there a fast form of integer variable? Faster if #B002 is in a variable??

7 is a good answer, it should show up a 2MHz and even a 4MHz Atom. (Actually, I seem to have got myself confused: faster Atoms will produce higher numbers, so there's no problem there even for your 100MHz Atom.)

(Edit: I notice JSAtom returns 1 for your code, so something not right somewhere.)

(Edit: and your emulator returns 15. Hmm.)
User avatar
BigEd
Posts: 4234
Joined: Sun Jan 24, 2010 10:24 am
Location: West Country
Contact:

Re: Atom speed benchmark....

Post by BigEd »

Hang on, shouldn't we loop until the sync input is high? We exit the FE66 routine with the input low:

Code: Select all

  Wait Until Next CRT Field Flyback subroutine
  --------------------------------------------
Preserves Accumulator, X, Y registers

FE66  2C 02 B0  BIT #B002       In flyback ?
FE69  10 FB     BPL #FE66       ..yes, wait until finished

  Wait Until Next or Current CRT Field Flyback subroutine
  -------------------------------------------------------
FE6B  2C 02 B0  BIT #B002       In flyback ?
FE6E  30 FB     BMI #FE6B       ..no, wait for flyback
FE70  60        RTS
Edit: or, does this routine leave us in the narrow sync pulse and we actually need something which waits until the end of the narrow sync pulse, so we get almost a whole frame for our counting??
User avatar
hoglet
Posts: 10351
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Atom speed benchmark....

Post by hoglet »

Actually, it's better not to use #FE66, because that exits on the falling edge.

This version I think would be better:

Code: Select all

   10 DIMLL10,Q256
   20 PRINT $21
   30 FOR I=0 TO 1
   40 P=Q
   50[
   60:LL0
   70 LDX @#00
   80 LDY @#00
   90:LL1
  100 BIT #B002
  110 BPL LL2
  120 INX
  130 BNE LL1
  140 INY
  150 BNE LL1
  160:LL2
  170 STX #80
  180 STY #81
  190 RTS
  200:LL4
  210 BIT #B002
  220 BMI LL4
  230:LL5
  240 BIT #B002
  250 BPL LL5
  260 RTS
  270]
  280 NEXT
  290 PRINT $6
  300 REM CALIBRATE
  310 LINK LL4
  320 LINK LL0
  330 C=!#80&#FFFF
  340 REM TEST
  350 LINK LL4
  360 A=22000000/7
  370 LINK LL0
  380 T=!#80&#FFFF
  390 REM CALCULATE RESULT
  400 PRINT "  C="C'
  410 PRINT "  T="T'
  420 PRINT "C-T="C-T'
  430 END
The code at LL4 waits for the rising edge of VSYNC, so you have most of the frame to do the measurement.
Screenshot from 2021-06-25 12-21-18.png
The inner loop averages to 11.0156 cycles, so line 360 A=22000000/7 takes 5,431us.

I wonder if we can check this somehow?

Dave
Last edited by hoglet on Fri Jun 25, 2021 12:58 pm, edited 2 times in total.
User avatar
MrGpG
Posts: 76
Joined: Fri Mar 26, 2021 11:26 am
Location: Wet Wales - East Cardiff as we say in the 'Port. Tidy
Contact:

Re: Atom speed benchmark....

Post by MrGpG »

BigEd wrote:
Fri Jun 25, 2021 10:20 am

The Beeb and Atom are already in there, and the Electron results are available here if anyone would like to add them.
Added to Wikipedia...

G
User avatar
hoglet
Posts: 10351
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Atom speed benchmark....

Post by hoglet »

The inner loop averages to 11.015625 cycles, so line 360 A=22000000/7 takes 5,431us.

I wonder if we can check this somehow?

As a sanity check, if I execute:

Code: Select all

JSR LL4
JSR LL0
RTS
I get a count of 1328

1328 * 11.015625 = 14,629us.

Looking at the 6847 timings, VSYNC is low for 32 lines then high for 230 lines. which is 230 * 63.695 = 14,649us.

So pretty close.

I'm currently running on a dev build of Atomulator which emulates 63.695us lines; most Atom emulators have 64us lines.

Dave
User avatar
hoglet
Posts: 10351
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Atom speed benchmark....

Post by hoglet »

Let's try to confirm the measurement result on a real Atom with an ICE.

To recap, we are trying to estimate the execution time of the following line, using the 60Hz VSYNC as the only timer:

Code: Select all

360 A=22000000/7
Here's the BASIC program as it appears in memory.

Code: Select all

>> m 2a00 
2A00 52 54 53 0D 01 0E 5D 0D 01 18 20 4E 45 58 54 0D  RTS...]... NEXT.
2A10 01 22 20 50 52 49 4E 54 20 24 36 0D 01 2C 20 52  ." PRINT $6.., R
2A20 45 4D 20 43 41 4C 49 42 52 41 54 45 0D 01 36 20  EM CALIBRATE..6 
2A30 4C 49 4E 4B 20 4C 4C 34 0D 01 40 20 4C 49 4E 4B  LINK LL4..@ LINK
2A40 20 4C 4C 30 0D 01 4A 20 43 3D 21 23 38 30 26 23   LL0..J C=!#80&#
2A50 46 46 46 46 0D 01 54 20 52 45 4D 20 54 45 53 54  FFFF..T REM TEST
2A60 0D 01 5E 20 4C 49 4E 4B 20 4C 4C 34 0D 01 68 20  ..^ LINK LL4..h 
2A70 41 3D 32 32 30 30 30 30 30 30 2F 37 0D 01 72 20  A=22000000/7..r 
2A80 4C 49 4E 4B 20 4C 4C 30 0D 01 7C 20 54 3D 21 23  LINK LL0..| T=!#
2A90 38 30 26 23 46 46 46 46 0D 01 86 20 52 45 4D 20  80&#FFFF... REM 
2AA0 43 41 4C 43 55 4C 41 54 45 20 52 45 53 55 4C 54  CALCULATE RESULT
2AB0 0D 01 90 20 50 52 49 4E 54 20 22 20 20 43 3D 22  ... PRINT "  C="
2AC0 43 27 0D 01 9A 20 50 52 49 4E 54 20 22 20 20 54  C'... PRINT "  T
2AD0 3D 22 54 27 0D 01 A4 20 50 52 49 4E 54 20 22 43  ="T'... PRINT "C
2AE0 2D 54 3D 22 43 2D 54 27 0D 01 AE 20 45 4E 44 0D  -T="C-T'... END.
2AF0 FF 1D 2B 00 00 21 2B 00 00 2C 2B 00 00 CB 2F 82  ..+..!+..,+.../.
Let's look for the line A=22000000/7 and set a memory read watchpoint on the 0D terminators around this line:

Code: Select all

>> watchr 2a6c
Mem Rd Watch set at 2A6C
>> watchr 2a7c
Mem Rd Watch set at 2A7C
There is a disassembly of Atom Basic here:
http://www.acornatom.nl/atom_handleidin ... m/c000.txt

So let's also set some watch points on the divide code, just as a sanity check:

Code: Select all

>> watch c689
Ex Watch set at C689
>> watch c693
Ex Watch set at C693
>> watch c6d9
Ex Watch set at C6D9
Then let's see what happens when we run the program:

Code: Select all

>> c
CPU free running...
01.419885 : Mem Rd Watch hit at C478 reading 2A6C:0D  .
01.420207 : Mem Rd Watch hit at C4E8 reading 2A6C:0D  .
01.433962 : Mem Rd Watch hit at C55D reading 2A6C:0D  .
01.435724 : Ex Watch hit at C689
01.436044 : Mem Rd Watch hit at C478 reading 2A7C:0D  .
01.436337 : Ex Watch hit at C693
01.438972 : Ex Watch hit at C6D9
01.439088 : Mem Rd Watch hit at C27F reading 2A7C:0D  .
01.439214 : Mem Rd Watch hit at C27F reading 2A7C:0D  .
01.439304 : Mem Rd Watch hit at C4E8 reading 2A7C:0D  .
01.439421 : Mem Rd Watch hit at C55D reading 2A7C:0D  .
01.755094 : Mem Rd Watch hit at CDA5 reading 2A6C:0D  .
01.755300 : Mem Rd Watch hit at CDA5 reading 2A7C:0D  .
So, which of these to choose? The best measurement point I think is C55D:

Code: Select all

  Return Routine
  --------------
- All routines generally return to BASIC here.
- Goes on to interpret the next statement.
C55B  A0 00     LDY @#0
C55D  B1 05     LDA (#5),Y
C55F  C9 3B     CMP @#3B
C561  D0 1A     BNE #C57D
C563  4C 1B C3  JMP #C31B
Using C55D as the measurement point, the ICE gives us 01.439421s - 01.433962s = 5,459.0us.

This is an actual measurement of the total time to interpret line 360.

So how accurate was our VSYNC based estimate?

If I run the test multiple times, sometimes the result is 495 iterations, sometimes it is 496 iterations.

So let's run it 1000 times average the result. That gives us 495.8 iterations, which is 495.8 * 11.015625 = 5461.5us.

This shows the estimate is with a couple of microseconds of the ICE-based measurement.

Dave
User avatar
hoglet
Posts: 10351
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Atom speed benchmark....

Post by hoglet »

Ed raised an github issue against the JavaScript Emulator:
Atom frame sync benchmark gives unexpected result

It's actually quite interesting....

The moral of the story is "Beware of implict empty statements in Atom BASIC!"

The gory details are in the issue.

Dave
User avatar
CommanderCoder
Posts: 113
Joined: Wed Nov 06, 2019 5:50 pm
Location: Royal Leamington Spa
Contact:

Re: Atom speed benchmark....

Post by CommanderCoder »

Just to say I've been looking into this and I've not quite got a perfect result but with some rewrite to the video loop I now obtain:
Screenshot 2021-07-12 at 09.53.36.png
I think I may have some of my assumptions about clock speeds wrong.
Is the VDG clock speed running at 3.579545Mhz ?
Does it take 63.695ms to scan 256 pixels (32 characters?)
I don't know how long it takes for the vertical flyback and I assume the horizontal is almost negligible.
Post Reply

Return to “acorn atom and acorn system series”