Calculator graphics drawing benchmark

[rprosperi]

(01-29-2022 01:03 PM)Dave Britten Wrote:  Well shoot, guess I'd better go shopping for a 9000! How does it handle the touch keys? Is there just an unlabeled 4x4 button grid on the touch screen?

It's been too long, I don't recall all the details...

IIRC, the 9xxx machines had bitmaps of the common cards in ROM to display them on the LCD, but I don't recall if the BASIC card was included.

If time permits, I'll dig today, I have a 9500 that still works...

[DavidM]

I like these patterns. It seems like they are much more planned and deliberate than the simple algorithm would imply.

(edit: I removed examples of another approach that created horizontal and vertical dashed lines and replicated those lines in the same randomly-staggered sequence -- they deviated too much from the intended algorithm to include them here)

A "brute force" implementation on the 50g:

Code:

\<<
   R\->B
   \-> s
   \<<
      @ clear/view PICT
      ERASE { #0 #0 } PVIEW

      @ draw horizontal lines
      #0 #79d FOR y
         RAND .5 < s *
         #130d FOR x
            x y
            2. \->LIST
            x s + y
            2. \->LIST
            LINE
         s 2. * STEP
      s STEP

      @ draw vertical lines
      #0 #130d FOR x
         RAND .5 < s *
         #79d FOR y
            x y
            2. \->LIST
            x y s +
            2. \->LIST
            LINE
         s 2. * STEP
      s STEP

      @ leave image on display
      7. FREEZE
   \>>
\>>

This one isn't exactly a speed demon:
HP 50g
program: User RPL
screen: 131x80
time: 13.52s (average of 10 runs)
performance: 775


Given that other platforms were checked with alternate language options, I also tried the above method with System RPL. I knew that a lot of the slowdown in the User RPL implementations comes from type conversions and argument structuring, and both of those would be less of an issue with System RPL.

The brute-force approach I used above in a System RPL implementation looks like this:

Code:

::
   ( 1 arg expected )
   CK1NoBlame

   CK&DISPATCH1
   real ::
      ( setup/clear display )
      ClrDA1IsStat
      RECLAIMDISP
      TURNMENUOFF

      ( convert arg to BINT )
      COERCE {{ s }}

      ( draw horizontal lines )
      EIGHTY ZERO_DO (DO)
         %RAN % .5 %< ITE ONE ZERO s #*
         131 SWAP DO
            INDEX@ JINDEX@
            OVER s #+ JINDEX@
            LINEON
         s #2* +LOOP
      s +LOOP

      ( draw vertical lines )
      131 ZERO_DO (DO)
         %RAN % .5 %< ITE ONE ZERO s #*
         80 SWAP DO
            JINDEX@ INDEX@
            OVER INDEX@ s #+
            LINEON
         s #2* +LOOP
      s +LOOP

      ( abandon LAM )
      ABND

      ( freeze the display )
      SetDAsTemp
   ;
;

A noticeable improvement:
HP 50g
program: System RPL
screen: 131x80
time: 1.459s (average of 10 runs)
performance: 7,183

Thanks for the interesting exercise!

[Akuji]

(01-29-2022 01:03 PM)Dave Britten Wrote:  Well shoot, guess I'd better go shopping for a 9000! How does it handle the touch keys? Is there just an unlabeled 4x4 button grid on the touch screen?

[rprosperi]

Thanks! That was much faster than digging thru storage boxes.

I think if you use one of the common cards, such as Time/Expense, etc, then the keypad icons are visible on the emulated touchpad (these bitmaps were stored in the organizer's ROM), but in the case of the BASIC card we decided to keep it generic (i.e., to not include the scientific calculator labels) since someone may well be using the touchpad buttons for a custom BASIC program and the scientific labels would only confuse the user.

[robve]

DavidM,

Nice results for the HP 50g! Thanks for contributing!

(01-29-2022 04:36 PM)DavidM Wrote:  

Quote:...including dashed lines if that speeds up the algorithm. ... If anyone finds a faster way to run these programs, then let us know.

Reading the above led me to believe that it would be acceptable to change the approach a bit for a more optimized method that reduces some of the overhead of the brute-force algorithm. The following builds a complete row and column using the standard LINE commands, then draws those lines in stepwise fashion both horizontally and vertically with a random offset as per the standard algorithm. If this is an inappropriate optimization, let me know and I'll edit it out of this post for consistency with the other programs:

As long as the S=4 Hitomezashi-based algorithm draws (dashed) lines with random offsets then it's benchmarking properly. If a dashed line drawing feature exists, then by all means use it. Also the line drawing order does not matter, even though it may no longer produce the eye-pleasing horizontal wave/weave effect.

I don't closely follow the logic of the second version, but from your explanation and by perusing the code it appears to place a dashed line in some PICT memory (like a sprite?) to redraw copies of it at random offsets? Don't want to be a PitA, but sprite drawing is different and isn't benchmarked. Still, I feel strongly that this method should be included in the performance table somehow, but perhaps in a separate benchmark table that allows memory copy/sprite/blitting operations to speed up line drawing (per line) for all calculators that support such features. That's just my opinion, not sure what others think is most fair?

- Rob

[toml_12953]

(01-29-2022 06:08 PM)robve Wrote:  I don't closely follow the logic of the second version, but from your explanation and by perusing the code it appears to place a dashed line in some PICT memory (like a sprite?) to redraw copies of it at random offsets? Don't want to be a PitA, but sprite drawing is different and isn't benchmarked. Still, I feel strongly that this method should be included in the performance table somehow, but perhaps in a separate benchmark table that allows memory copy/sprite/blitting operations to speed up line drawing (per line) for all calculators that support such features. That's just my opinion, not sure what others think is most fair?

- Rob

You are quite correct. To give a meaningful comparison of machines, special features of any one machine or language should be avoided The same algorithm should be used on every machine. Even better, the same language should be used, if possible. Python is a big step in that direction.

[C.Ret]

Material : HP-41C connected to a HP82240A printer through a HP82242A IR module.

Preparation: setup hardware, check paper

Program:

Code:

01 ►LBL"HITO"  ADV  CF 21  FIX 0  XEQ 12
06 ►LBL 01     VIEW 01  209  XEQ 10  31  +  STO IND 01  ISG 01  GTO 01
15 ►LBL 02     VIEW 02  1  XEQ 10  16  XEQ 10  +  STO IND 02  ISG 02  GTO 02
25 ►LBL 05     SF 21  XEQ 12
28 ►LBL 03     0  ACCOL
31 ►LBL 04     RCL IND 01  ACCOL  RCL IND 02  FC?C 00  XEQ 07  ACCOL  ACCOL  ACCOL  ISG 01  GTO 04
42             PRBUF  XEQ 11  ISG 02  GTO 03
46             ADV  TONE 5  RTN
49 ►LBL 07     17  X<>Y  -  SF 00  RTN
55 ►LBL 10     PI  LN  RCL 00  +  5  Y^X  FRC  STO 00  RND  *  RTN
67 ►LBL 12     44.063  STO 02 
70 ►LBL 11     3.043  STO 01  SF 00  END

Registers:
R00: seed of pseudo random generator
R01: column indice
R02: row indice
R03-R43: Graphic Code for printing vertical dash lines (colum line)
R44-R63: Graphic Code for printing horizontal dash lines (row lines)
Flag 00: Toggle for row line
Flag 21: Suspend printing during initialisation.

Usage :
SIZE 64
randomized seed STO 00
XEQ [ALPHA]HITO[ALPHA]

   

Time: ~12'05" (~725") the printing start after 1'25" of initialisation.

Screen: 164x160
Size of print adjustable through row and register range (see instruction 068 and 071)

Performance: 36.19

The HP-41C definitively not a graphing calculator


EDITED: The value 17 at step 050 was missing in the original post.
Sorry for missing this in first edition.

[DavidM]

(01-29-2022 06:08 PM)robve Wrote:  I don't closely follow the logic of the second version, but from your explanation and by perusing the code it appears to place a dashed line in some PICT memory (like a sprite?) to redraw copies of it at random offsets? Don't want to be a PitA, but sprite drawing is different and isn't benchmarked.

Not a problem, I thought it could be out-of-scope so that's why I asked. Your mention of using dashed lines was what made me think the alternate approach might be acceptable. I've removed those examples and left the User- and System-RPL ones for the looped-LINE commands as they were, since those are comparable to the other posts.

PICT is the designated drawing area for User RPL drawing commands, so it's entirely appropriate for use here.

The method I used in the (now removed) examples was:

1. draw a single row in the defined way (repeated LINE commands)
2. extract that row as a User RPL GROB (GRaphics OBject)
3. draw a single column in the defined way (repeated LINE commands)
4. extract that column as a GROB
5. clear the drawing area
6. draw the horizontal lines (GROBs) with random offset at the specified intervals
7. draw the vertical lines (GROBs) with random offset at the specified intervals
   

I suspect a similar approach could be used with other platforms, of course, and might make sense for a separate benchmark. That method isn't special to the 50g in any way.

[robve]

DavidM: thank you for sharing the details how the approach worked with GROBs. Note that it is permitted to draw the entire image to a GROB first and display the GROB at the end. That will still count for this benchmark, because it optimizes the drawing speed of the entire image to a buffer, not bypass line drawing. I've used UseBuffer and PaintBuffer with the Ti-nspire to do just that.

C.Ret: great to see the HP-28S and the HP-41C additions to the benchmark list. Using the printer with the HP-41C offers a creative contribution!

- Rob

[DavidM]

(01-30-2022 01:38 AM)robve Wrote:  Note that it is permitted to draw the entire image to a GROB first and display the GROB at the end. That will still count for this benchmark, because it optimizes the drawing speed of the entire image to a buffer, not bypass line drawing.

While permitted, there's no performance gain on the 50g for that. Standard User RPL only allows drawing lines to the graphics display, and it's equally slow regardless of which display (graphics or text) is active. SysRPL has separate line drawing commands for both displays, but they take the same amount of time regardless of the display disposition.

There are apparently grayscale SysRPL commands that include line drawing to arbitrary GROBs, but I've never actually seen documentation for how to use them successfully. They are great at causing system crashes, though.

[Dan C]

Is it possible to write a benchmark program for the TI-81, the first Texas Instruments graphic calc?
If so, how would a prog for TI-81 look like? I just got an old TI-81, but i dont yet know how to write programs on it.

[Guenter Schink]

(01-29-2022 06:08 PM)robve Wrote:  Don't want to be a PitA, but sprite drawing is different and isn't benchmarked. Still, I feel strongly that this method should be included in the performance table somehow, but perhaps in a separate benchmark table that allows memory copy/sprite/blitting operations to speed up line drawing (per line) for all calculators that support such features. That's just my opinion, not sure what others think is most fair?

Did you ask for it?

Here is the performance index of over 38 millions on a Prime G2 Python with blitting

Code:

from hpprime import *
from urandom import *
 
def hitomezashi():
    color=255
    eval('PRINT')
    s=int(input("s = "));print(s)
    eTime=eval('time')
    loop0=100
    loop=loop0
    while loop >0:
      fillrect(0,0,0,320,240,0xffffff,0xffffff)

      dimgrob(1,320,1,0xffffff)            
      for x in range(0,320,2*s):
         line(1,x,0,x+s,0,color) 

      dimgrob(2,1,240,0xffffff)
      for y in range(0,240,2*s):
         line(2,0,y,0,y+s,color)
                   
      for y in range(0,240,s):
        i=s*randint(0,1)
        blit(0,i,y,1)      
      for x in range(0,320,s):
        i=s*randint(0,1)
        blit(0,x,i,2)
#        eval("Wait(.03)")
      loop=loop-1
      
    eTime=(eval('time')-eTime)/loop0      
    eval("WAIT")
    print("Loops  = ",loop0)
    print("Time per loop =\n {:,} sec".format(round(eTime,12)))
    performance=round(320*240/eTime)
    print("Performance =\n {:,d} ".format(performance))   
 
hitomezashi()

s = 4
320*240 Pixels
Loops = 100
Time per loop 0.00197 sec
Performance Index: 38,984,772

Still not ready for Python on the Prime?

Günter

[robve]

(01-31-2022 07:49 PM)Guenter Schink Wrote:  320*240 Pixels
Loops = 100
Time per loop 0.00197 sec
Performance Index: 38,984,772

Awesome!

(01-31-2022 07:49 PM)Guenter Schink Wrote:  Still not ready for Python on the Prime?

Günter

Got my Prime updated over the weekend. So yes, I'm ready!

- Rob

[robve]

A new addition to the benchmark: the first Sharp graphing calculator 1986. This small and quirky calculator has many features for its time, including multi-formula playback. But its graphing capabilities are slow, placing it near the bottom of the benchmark scores.

I didn't think it would be possible to run this benchmark due to the limitations of AER-II, but here it is

Sharp EL-5200/EL-9000
program: AER-II
screen: 96x32
time: 72.5s
performance: 42

Code:

Sharp EL-5200/EL-9000 AER-II (input S=4)
----------------------------------------
(spaces and newlines are not part of the program)
:Hitomezashi
M:➊
  J=1␣
  ↳ I=S INT (RND +.5)+1␣
  ↳ LINE I,J,I+S,J DRAW␣
  I=I+2S␣
  H>=I→Y→[↰]
  J=J+S␣
  32>=J→Y→[↰]
  I=1␣
  ↳ J=S INT (RND +.5)+1␣
  ↳ LINE I,J,I,J+S DRAW␣
  J=J+2S␣
  V>=J→Y→[↰]
  I=I+S␣
  96>=I→Y→[↰]
➊:S=?␣
  RANGE 1,96,97,1,32,33␣
  H=96-S␣
  V=32-S

AER programming in the virtual museum of calculators.

- Rob

[C.Ret]

Here is a version for the full graphic one-line display calculator HP-71B.

As you can see it on the picture, the HP-71B is a full graphic calculator since its display is a full matrix of LCD dots without any hole or gap between the character positions.

Here is a code that hallows the Calculator graphics drawing benchmark for any size of Hitomezashi pattern from 1 pixel up to 8 pixels. This version of the code is suitable to all HP-71B without any module or extension. It is adapted from an original code that need specific instructions from the JPC ROM ver E.

The rendering is based on the behavior of the GDISP instruction, a precursor of GROB operations on actual RPL and HPPL pockets.



1 DESTROY ALL @ DIM G$[132] @ INPUT "Hito.(1-8) ","4";N @ ON N GOSUB 10,20,30,40,50,60,70,80
3 T=TIME @ D=1+LEN(H$) @ J=CEIL(D*RND) @ FOR K=0 TO 131
5 IF NOT MOD(K,N) THEN I=CEIL(2*RND) @ G$=G$&V$[I,I] @ J=D-J ELSE G$=G$&H$[J,J]
7 NEXT K @ GDISP G$ @ T=TIME-T @ PAUSE @ DISP T @ END

10 V$=CHR$(85)&CHR$(170) @ H$=CHR$(255)
12 RETURN
20 V$=CHR$(119)&CHR$(221) @ H$=CHR$(0)&CHR$(1)&CHR$(4)&CHR$(5)&CHR$(16)&CHR$(17)&CHR$(20)
22 H$=H$&CHR$(21)&CHR$(64)&CHR$(65)&CHR$(68)&CHR$(69)&CHR$(80)&CHR$(81)&CHR$(84)&CHR$(85)
24 RETURN
30 V$=CHR$(121)&CHR$(207)
32 H$=CHR$(0)&CHR$(1)&CHR$(8)&CHR$(9)&CHR$(64)&CHR$(65)&CHR$(72)&CHR$(73)&CHR$( )
34 RETURN
40 V$=CHR$(31)&CHR$(240) @ H$=CHR$(0)&CHR$(1)&CHR$(16)&CHR$(17)
42 RETURN
50 V$=CHR$(63)&CHR$(225) @ H$=CHR$(0)&CHR$(1)&CHR$(32)&CHR$(33)
52 RETURN
60 V$=CHR$(127)&CHR$(193) @ H$=CHR$(0)&CHR$(1)&CHR$(64)&CHR$(65)
62 RETURN
70 V$=CHR$(129)&CHR$(255) @ H$=CHR$(0)&CHR$(1)&CHR$(128)&CHR$(129)
72 RETURN
80 V$=CHR$(1)&CHR$(255) @ H$=CHR$(0)&CHR$(1)
82 RETURN

Usage:
RUN
Press ENTER to select default size or type-in size and validate
The pattern is displayed full size.
Press f-CONT to display execution time in second
Press f-CONT again or RUN to get a new random pattern.

   

Screen: 132 x 8 = 1056

Speed: ~6.06" (for size 4)

Performance: 174.2574




Edited to add sample capture pictures.

[robve]

(01-28-2022 07:15 PM)Dave Britten Wrote:  Just for fun, I punched this into the Wizard BASIC card using my just-received OZ-7600 and got about 2.5 seconds. Same performance when the card is running in an OZ-7200.

The program requires almost no change from the PC-E500 version, just an adjustment to the screen dimension constants on line 10 (96x64 pixels).

This card really shines with the hugely improved keyboard on the OZ-7600 models! (QWERTY layout, better feel and response, and no diving into a SYMBOL menu constantly.)

Today I received a OZ-8B03 BASIC card and popped into my OZ-9500 to run the benchmark with the same PC-E500 program but adjusted to the 240x64 screen:

time: 2.5s
performance: 6,144

Interesting that the time 2.5s is the same as on the OZ-7600, but the pattern fills a 2.5 times larger screen.

   

- Rob

[Dave Britten]

I got ahold of an OZ-9600II and gave this a try with my 16-column BASIC card. Not bad looking! The program takes about 1.25 seconds to run.

https://i.imgur.com/iPztd6F.jpg

It's only a tiny portion of the screen, but physically it's not too much smaller than the screen on an OZ-7000 series. The 40-column spreadsheet card fills out the width of the bordered area nicely.

This is a pretty nice Wizard model. The only two obvious strikes against it are you can't easily do repeating to-do entries, and there's no 4-pin option port for connecting a CE-50P printer/cassette interface. No idea if LPRINT can be used on this model somehow.

[arhtur]

I posted a faster DM42 Hitomezashi algorithm using AGRAPH on the "Not Quite HP Calculators - but related" forum. It seems to be about 2 times faster (worst case) and more than 10 times faster (best case), depending on USB/battery power, screen resolution and S (size) setting, using sizes 4 and 8. My times were measured using the 400x240 screen resolution.

[robve]

(08-27-2023 03:57 PM)arhtur Wrote:  I posted a faster DM42 Hitomezashi algorithm using AGRAPH on the "Not Quite HP Calculators - but related" forum. It seems to be about 2 times faster (worst case) and more than 10 times faster (best case), depending on USB/battery power, screen resolution and S (size) setting, using sizes 4 and 8. My times were measured using the 400x240 screen resolution.

I didn't see it. Can you share a link for me?

I will be happy to update the results with the timing (range) and program code.

- Rob

[Steve Simpkin]

(08-28-2023 01:56 AM)robve Wrote:  

(08-27-2023 03:57 PM)arhtur Wrote:  I posted a faster DM42 Hitomezashi algorithm using AGRAPH on the "Not Quite HP Calculators - but related" forum. It seems to be about 2 times faster (worst case) and more than 10 times faster (best case), depending on USB/battery power, screen resolution and S (size) setting, using sizes 4 and 8. My times were measured using the 400x240 screen resolution.

I didn't see it. Can you share a link for me?

I will be happy to update the results with the timing (range) and program code.

- Rob

https://www.hpmuseum.org/forum/thread-20408.html