Benchmarks 71B versus 48GX
06-17-2020, 08:44 PM
Post: #21
 J-F Garnier Senior Member Posts: 731 Joined: Dec 2013
RE: Benchmarks 71B versus 48GX
(06-17-2020 12:36 PM)J-F Garnier Wrote:  If it's really a 1LK7 then it's the same than used in the 28C and it supports the PC=(A) opcode. It may be a way to detect the CPU version by software. I may try.

Ok, I had to do it...

Here is the CPUV function that returns 1 if the CPU executes PC=(A), otherwise 0.

I got 0 on my oldest HP71s, but 1 on my 2842Axxx machine.

Note that both Emu71/Win and Emu71/DOS return 1 since they support the new opcodes.

Forth/assembler needed to enter and assemble the CPUV keyword.
Code:
       LEX 'CPUVER'        ID #5C        MSG 0        POLL 0        ENTRY CPUV        CHAR #F        KEY 'CPUV'        TOKEN 1        ENDTXT FNRTN1 EQU #0F216 FUNCR0 EQU #2F89B        NIBHEX 00 CPUV * install hook        GOSUB IHOOK  HOOK           P= 14        C=C+1 P   * return 1 if PC=(A) was effective        GOTO ret * set FUNCR0 to point to HOOK        IHOOK  C=RSTK        AD0EX          * save D0        D0=(5) =FUNCR0        DAT0=C A * now set A[A] to point to FUNCR0        AD0EX          * and restore D0 * prepare C        C=0 W * try PC=(A)         NIBHEX 808C     PC=(A) * return 0 if nop        C=0 W        C=0 W * return to Basic ret    GOVLNG FNRTN1                END

J-F
06-17-2020, 10:23 PM
Post: #22
 rprosperi Super Moderator Posts: 5,478 Joined: Dec 2013
RE: Benchmarks 71B versus 48GX
I struggled for a moment getting this to work, forgetting to power-off/on to add the new LEX file into the chain. It's been too long... ahem...

I also thought it may be interesting to include the result in the VER\$ poll, "CPU: 0" or "CPU: 1"...

Homework for later... into the large, but still growing, list of things to try.

Thanks J-F ! I knew you would have to do this

--Bob Prosperi
06-18-2020, 06:09 AM
Post: #23
 KimH Member Posts: 163 Joined: Jul 2018
RE: Benchmarks 71B versus 48GX
This is so cool, thanks J-F
(06-17-2020 08:44 PM)J-F Garnier Wrote:  Forth/assembler needed to enter and assemble the CPUV keyword.
Code:
       LEX 'CPUVER'        ID #5C        MSG 0        POLL 0        ENTRY CPUV        CHAR #F        KEY 'CPUV'        TOKEN 1        ENDTXT FNRTN1 EQU #0F216 FUNCR0 EQU #2F89B        NIBHEX 00 CPUV * install hook        GOSUB IHOOK  HOOK           P= 14        C=C+1 P   * return 1 if PC=(A) was effective        GOTO ret * set FUNCR0 to point to HOOK        IHOOK  C=RSTK        AD0EX          * save D0        D0=(5) =FUNCR0        DAT0=C A * now set A[A] to point to FUNCR0        AD0EX          * and restore D0 * prepare C        C=0 W * try PC=(A)         NIBHEX 808C     PC=(A) * return 0 if nop        C=0 W        C=0 W * return to Basic ret    GOVLNG FNRTN1                END

J-F
06-18-2020, 07:08 AM
Post: #24
 KimH Member Posts: 163 Joined: Jul 2018
RE: Benchmarks 71B versus 48GX
This is so cool, thanks J-F
(06-17-2020 08:44 PM)J-F Garnier Wrote:  Forth/assembler needed to enter and assemble the CPUV keyword.
Code:
       LEX 'CPUVER'        ID #5C        MSG 0        POLL 0        ENTRY CPUV        CHAR #F        KEY 'CPUV'        TOKEN 1        ENDTXT FNRTN1 EQU #0F216 FUNCR0 EQU #2F89B        NIBHEX 00 CPUV * install hook        GOSUB IHOOK  HOOK           P= 14        C=C+1 P   * return 1 if PC=(A) was effective        GOTO ret * set FUNCR0 to point to HOOK        IHOOK  C=RSTK        AD0EX          * save D0        D0=(5) =FUNCR0        DAT0=C A * now set A[A] to point to FUNCR0        AD0EX          * and restore D0 * prepare C        C=0 W * try PC=(A)         NIBHEX 808C     PC=(A) * return 0 if nop        C=0 W        C=0 W * return to Basic ret    GOVLNG FNRTN1                END

J-F
Post: #25
 Christoph Giesselink Member Posts: 227 Joined: Dec 2013
RE: Benchmarks 71B versus 48GX
(06-17-2020 08:44 PM)J-F Garnier Wrote:
(06-17-2020 12:36 PM)J-F Garnier Wrote:  If it's really a 1LK7 then it's the same than used in the 28C and it supports the PC=(A) opcode. It may be a way to detect the CPU version by software. I may try.

Ok, I had to do it...

Here is the CPUV function that returns 1 if the CPU executes PC=(A), otherwise 0.

I got 0 on my oldest HP71s, but 1 on my 2842Axxx machine.

Note that both Emu71/Win and Emu71/DOS return 1 since they support the new opcodes.

Forth/assembler needed to enter and assemble the CPUV keyword.
J-F

When you don't like to fiddle around with the Forth/Assembler module like me, I added the original sources, sources which can be compiled with the HPTOOLs package and a compiled L71 file for importing with the DOSLINK interface.

Attached File(s)
06-19-2020, 08:05 AM
Post: #26
 J-F Garnier Senior Member Posts: 731 Joined: Dec 2013
RE: Benchmarks 71B versus 48GX
(06-18-2020 08:00 PM)Christoph Giesselink Wrote:  ... I added the original sources, sources which can be compiled with the HPTOOLs package and a compiled DAT file for importing with the DOSLINK interface.

Thanks, Christoph.
It may be better to name the assembled file CPUVER.L71 to reflect its true nature.

To load it in the HP-71B, you will need the PIL-Box and ILPer. Make the DOSLINK "in file" point to the assembled CPUVER file and do "COPY :DOSLINK".

Now, we can build stats on the presence of the 1LK7 in the latest HP-71B?

J-F
06-19-2020, 03:40 PM
Post: #27
 Valentin Albillo Senior Member Posts: 887 Joined: Feb 2015
RE: Benchmarks 71B versus 48GX
(06-17-2020 08:44 PM)J-F Garnier Wrote:  Forth/assembler needed to enter and assemble the CPUV keyword.

Not really. Would you please post the hex dump so that we may create the LEX file just by entering the hex codes using MAKELEX ?

This will take less time than using the Assembler, the compiled LEX file is quite short.

Thanks and have a nice finde.
V.

All My Articles & other Materials here:  Valentin Albillo's HP Collection

06-19-2020, 04:40 PM
Post: #28
 KimH Member Posts: 163 Joined: Jul 2018
RE: Benchmarks 71B versus 48GX
Maybe this should be turned into an article, it's valuable information for the 71B fans.

I can try to do this next time it rains....

I have gone through all my 71's (Thanks a lot J-F!!).

My stats tells me that the earliest I have with 1LK7 CPU is 2630A and according to legend, they started with 2623A. All are 2CCCC or newer

All of them are Plastic Backs, none of my Metal Backs are 1LK7 - the latest I have is 2552A - 1BBBB.

/KimH

(06-19-2020 08:05 AM)J-F Garnier Wrote:
(06-18-2020 08:00 PM)Christoph Giesselink Wrote:  ... I added the original sources, sources which can be compiled with the HPTOOLs package and a compiled DAT file for importing with the DOSLINK interface.

Thanks, Christoph.
It may be better to name the assembled file CPUVER.L71 to reflect its true nature.

To load it in the HP-71B, you will need the PIL-Box and ILPer. Make the DOSLINK "in file" point to the assembled CPUVER file and do "COPY :DOSLINK".

Now, we can build stats on the presence of the 1LK7 in the latest HP-71B?

J-F
06-19-2020, 05:08 PM
Post: #29
 J-F Garnier Senior Member Posts: 731 Joined: Dec 2013
RE: Benchmarks 71B versus 48GX
(06-19-2020 03:40 PM)Valentin Albillo Wrote:  Would you please post the hex dump so that we may create the LEX file just by entering the hex codes using MAKELEX ?
This will take less time than using the Assembler, the compiled LEX file is quite short.

It's decades since I used MAKELEX.
I vaguely remember that the LEX is entered as strings of hex characters with a checksum for each entered line.
Can someone can point to the right tool to generate the hex strings and checksum?

In the meantime, here is the assembly listing, if this can help.

Code:
0001 00000             LEX 'CPUVER'  0001 00000 34055565    NIBASC 'CPUVER  '       00008 54250202 0001 00010 802E        NIBHEX 802E  0001 00014 00          CON(2) 0  0001 00016 60          CON(2) #06  0001 00018 22          CON(2) #22  0001 0001A 71          CON(2) #17  0001 0001C 60          CON(2) #06  0001 0001E 02          CON(2) #20  0001 00020 A6000       REL(5) FiLeNd  0002 00025             ID #5C  0002 00025 C5          CON(2) #5C  0002 00027 10          CON(2) 0001   0002 00029 10          CON(2) 0001   0002 0002B 00000       CON(5) 0  0002 00030 F           NIBHEX F  0002 00031 7100        REL(4) 1+TxTbSt  0003 00035             MSG 0  0003 00035 0000        CON(4) 0  0004 00039              POLL 0  0004 00039 00000       CON(5) 0  0005 0003E             ENTRY CPUV  0005 0003E             * * * M A I N   T A B L E * * *  0005 0003E 000         CON(3) (TxEn01)-(TxTbSt)  0005 00041 61000       REL(5) CPUV  0006 00046             CHAR #F  0006 00046 F           CON(1) #F  0007 00047             KEY 'CPUV'  0007 00047             * * * T E X T   T A B L E * * *  0007 00047           TxTbSt  0007 00047           TxEn01  0007 00047 7           CON(1) 07  0007 00048 34055565    NIBASC 'CPUV'  0008 00050             TOKEN 1  0008 00050 10          CON(2) 1  0009 00052             ENDTXT  0009 00052 1FF         NIBHEX 1FF  0010 00055           *  0011 00055           FNRTN1 EQU #0F216  0012 00055           FUNCR0 EQU #2F89B  0013 00055           *  0014 00055 00          NIBHEX 00  0015 00057           CPUV  0016 00057 7900        GOSUB IHOOK  0017 0005B           HOOK  0018 0005B 2E          P= 14  0019 0005D B06         C=C+1 P  0020 00060 6220        GOTO ret  0021 00064           *  0022 00064 07        IHOOK C=RSTK  0023 00066 132         AD0EX  0024 00069 1BB98F2     D0=(5) =FUNCR0  0025 00070 144         DAT0=C A  0026 00073 132         AD0EX  0027 00076 AF2         C=0 W  PAGE 002             Forth Assembler      0028 00079 808C        NIBHEX 808C  * PC=(A)  0029 0007D AF2         C=0 W  0030 00080 AF2         C=0 W  0031 00083 8D612F0   ret GOVLNG =FNRTN1  0032 0008A           *  0033 0008A             END  PAGE 003             Forth Assembler     **** SYMBOL TABLE **** CPUV    00057  FNRTN1  0F216  FUNCR0  2F89B  FiLeNd  0008A  HOOK    0005B  IHOOK   00064  TxEn01  00047  TxTbSt  00047  ret     00083   SOURCE : CPUVERS  OBJECT : CPUVER   LISTING : :DOSLINK    DATE : 22:07:01 on 20/06/17  ERRORS : 000
06-19-2020, 06:02 PM
Post: #30
 Dave Frederickson Senior Member Posts: 2,133 Joined: Dec 2013
RE: Benchmarks 71B versus 48GX
(06-19-2020 05:08 PM)J-F Garnier Wrote:  Can someone can point to the right tool to generate the hex strings and checksum?

06-19-2020, 06:20 PM
Post: #31
 J-F Garnier Senior Member Posts: 731 Joined: Dec 2013
RE: Benchmarks 71B versus 48GX
(06-19-2020 06:02 PM)Dave Frederickson Wrote:
(06-19-2020 05:08 PM)J-F Garnier Wrote:  Can someone can point to the right tool to generate the hex strings and checksum?

Thanks Dave but I meant the tool to generate the hex strings, not the MAKELEX to enter them.

J-F
06-19-2020, 06:42 PM
Post: #32
 Sylvain Cote Senior Member Posts: 1,859 Joined: Dec 2013
RE: Benchmarks 71B versus 48GX
Here is the BASIC listing for both DUMPLEX and MAKELEX from the Old HP Forum Archives
06-19-2020, 06:50 PM
Post: #33
 Dave Frederickson Senior Member Posts: 2,133 Joined: Dec 2013
RE: Benchmarks 71B versus 48GX
(06-19-2020 06:20 PM)J-F Garnier Wrote:
(06-19-2020 06:02 PM)Dave Frederickson Wrote:  HP-71 BASIC Made Easy, p133.

Thanks Dave but I meant the tool to generate the hex strings, not the MAKELEX to enter them.

J-F

Sorry, I didn't read it all. DUMPLEX is on SWAP\CHHU01.

Code:
CPUVER    ID#5C   54 bytes      0123456789ABCDEF ck 000: 3405556554250202 0B 001: 802E008581816002 66 002: B6000C5101000000 45 003: F710000000000000 A7 004: 061000F734055565 11 005: 101FF0079002EB06 58 006: 6220071321BB98F2 E2 007: 144132AF2808CAF2 EC 008: AF28D612F00      28
06-20-2020, 07:51 AM
Post: #34
 J-F Garnier Senior Member Posts: 731 Joined: Dec 2013
RE: Benchmarks 71B versus 48GX
Thanks Dave for the hex dump.

Now, one question remains : what does the 1LF2 do when it executes the 808C PC=(A) opcode?
Is it a nop or something else?

The 808C opcode is part of the 808x group, in the 1LF2 only the 8080 INTON and 808F INTOFF are defined.
So it depends on how the opcode decoding is done in the 1LF2, but I would expect the 808C opcode to be executed as INTOFF.
It may be possible to prove it, but probably not worth the effort.

J-F
06-21-2020, 04:45 PM (This post was last modified: 06-23-2020 06:23 PM by Jonathan Busby.)
Post: #35
 Jonathan Busby Member Posts: 250 Joined: Nov 2014
RE: Benchmarks 71B versus 48GX
(05-03-2014 01:57 AM)Mark Hardman Wrote:  HP-28C
1LK7 Saturn CPU (1 MHz)

Sorry, this is wrong. The HP-28C use the same LC frequency generator like in the HP-71B, so the CPU strobe frequency is 600-650 KHz. You can peek the 5 nibble =CSPEED content (#4F00Fh) on a HP-28C with an external peek program. The 5 nibble content is the CPU strobe frequency divided by 16. So a content of #09C05h mean: #09C05h -> #39941d * 16 = #639056d -> ~640 KHz.

If the value present at =CSPEED is generated in a similar fashion to how the value for the entry of the same name on the HP48 is generated, then some corrections are in order. First, on the HP48 series, =CSPEED is generated using the =clkspd routine ( which of course attempts to measure the CPU clock speed ) which is not very accurate, even if display refresh and keyboard scanning are turned off. Secondly, the HP48 series calculators' 32768Hz crystal oscillator seems to vary frequently and the LC circuit that's part of the PLL ( and which uses the crystal oscillator as a reference ) that generates the HFO ( High Frequency Oscillator, which on the HP48G/G+/GX is around ~7.34MHz to ~7.86MHz ) is also subject to frequent variation. So, although the nominal clock speed of the HP-28C may be 640kHz, it may possibly be higher or lower by a non-negligible amount probably due to similar variations in frequency that cause the HP48 series calculators' clock speed to vary, although I believe the variation to be small and on the order of ±20kHz ( ie. it's not so variable that the clock speed would be off by ~360kHz I'd imagine that would have been caught early in the design phase as it would have made the chip unstable ).

In summary, I think that the value stored at "=CSPEED" is not the most reliable indicator of the true clock speed, although I may be wrong though if the HP-28C hardware and its equivalent to the HP48 series "=clkspd" routine differ in some certain crucial aspects

Quote:
(05-03-2014 01:57 AM)Mark Hardman Wrote:  HP-48GX
Yorke (00048-80063, 160 pin QFP), 4 MHz

This is also a mistake. Only very early HP48G Series calculators had a strobe frequency of 4 MHz. The frequency was then reduced to a nominal speed of ~3.68 MHz.

Well, this is not quite 100% accurate. On the HP48 series, taking the HP48G/G+/GX as an example, the clock speed is derived from the aforementioned HFO divided by 2. AFAIK, the nominal clock speed is around either ~3.93MHz or ~3.67MHz, but, due to reasons I've already mentioned, can vary to a non-negligible degree. I have several HP48GXs that have ~3.9MHz+ clock speeds, and, it seems to me that the "nominal" clock speed is around a little below ~4MHz for these. Also, these calculators are *not* "very early" models ( I've measured ~3.9MHz+ clock speeds on HP48GXs manufactured in Singapore, China and Indonesia )

Regards,

Jonathan

( NOTE : Edited this post to fix typos : "Hz" -> "kHz")

Aeternitas modo est. Longa non est, paene nil.
06-21-2020, 09:55 PM
Post: #36
 Mark Hardman Senior Member Posts: 525 Joined: Dec 2013
RE: Benchmarks 71B versus 48GX
Please note that I was quoting specifications from Craig Finseth's HPDATAbase. If there are any corrections, please let Craig know.

(05-03-2014 01:57 AM)Mark Hardman Wrote:
(05-02-2014 09:23 PM)John W Kercheval Wrote:  Does anyone have a raw chip speed comparison between the 71B and the 48GX?

From Craig Finseth's invaluable HPDATAbase:

Ceci n'est pas une signature.
06-22-2020, 04:48 AM (This post was last modified: 06-22-2020 04:50 AM by RMollov.)
Post: #37
 RMollov Member Posts: 264 Joined: Dec 2013
RE: Benchmarks 71B versus 48GX
(06-21-2020 04:45 PM)Jonathan Busby Wrote:  Well, this is not quite 100% accurate. On the HP48 series, taking the HP48G/G+/GX as an example, the clock speed is derived from the aforementioned HFO divided by 2. AFAIK, the nominal clock speed is around either ~3.93MHz or ~3.67MHz, but, due to reasons I've already mentioned, can vary to a non-negligible degree. I have several HP48GXs that have ~3.9MHz+ clock speeds, and, it seems to me that the "nominal" clock speed is around a little below ~4MHz for these. Also, these calculators are *not* "very early" models ( I've measured ~3.9MHz+ clock speeds on HP48GXs manufactured in Singapore, China and Indonesia )

Regards,

Jonathan

I can confirm that, my HP-48GX is from the latest ones, SN ID30700327 and always reports abt 3.933MHz

Cheers,
06-28-2020, 02:11 AM
Post: #38
 Giuseppe Donnini Member Posts: 124 Joined: Feb 2014
RE: Benchmarks 71B versus 48GX
To my knowledge, there was a second instruction added to the 1LK7, namely RSI (Reset Interrupt System) with an opcode of 80810.

Maybe Jean-François Garnier could enlighten us as to how a late-production HP-71B equipped with the 1LK7 would react to the issuance of that instruction, and how, on the other hand, the 1LF2 in a standard HP-71B would internally decode the corresponding opcode?
06-28-2020, 07:35 AM
Post: #39
 J-F Garnier Senior Member Posts: 731 Joined: Dec 2013
RE: Benchmarks 71B versus 48GX
(06-28-2020 02:11 AM)Giuseppe Donnini Wrote:  To my knowledge, there was a second instruction added to the 1LK7, namely RSI (Reset Interrupt System) with an opcode of 80810.

Maybe Jean-François Garnier could enlighten us as to how a late-production HP-71B equipped with the 1LK7 would react to the issuance of that instruction, and how, on the other hand, the 1LF2 in a standard HP-71B would internally decode the corresponding opcode?

It's has always been a mystery for me why the RSI is opcode 80810 and not just 8081. Maybe this additional fetched nibble gave more time for the RSI execution? I would be glad to get the opinion of people more expert than me in the Saturn chipsets.

Due to this trailing 0, an attempt to execute RSI on a 1LF2 will probably put the CPU out of sync with the next opcodes.

As for the effect of RSI on a HP-71 with 1LK7, I don't know. Actually I'm not sure of the exact effect of RSI on the 28C.

The SASM doc says:
"This instruction causes CPU to consider any input line (ie
input register bits) presently high as a new interrupt. If
the CPU is presently in the interrupt routine it will wait
for an RTI before vectoring, otherwise the CPU will vector
immediately following the RSI instruction. For a complete
discussion on the interrupt system see the CPU Hardware
Specification (A-1LK7-9005-1). This instruction is not
available on the 1LF2 version of the Saturn CPU."

This description is not fully clear for me, and unfortunately, I don't have access to the 1LK7 CPU Hardware Specification.

J-F
07-29-2020, 08:40 PM (This post was last modified: 07-29-2020 10:26 PM by Jonathan Busby.)
Post: #40
 Jonathan Busby Member Posts: 250 Joined: Nov 2014
RE: Benchmarks 71B versus 48GX
(06-28-2020 07:35 AM)J-F Garnier Wrote:
(06-28-2020 02:11 AM)Giuseppe Donnini Wrote:  To my knowledge, there was a second instruction added to the 1LK7, namely RSI (Reset Interrupt System) with an opcode of 80810.

Maybe Jean-François Garnier could enlighten us as to how a late-production HP-71B equipped with the 1LK7 would react to the issuance of that instruction, and how, on the other hand, the 1LF2 in a standard HP-71B would internally decode the corresponding opcode?

It's has always been a mystery for me why the RSI is opcode 80810 and not just 8081. Maybe this additional fetched nibble gave more time for the RSI execution? I would be glad to get the opinion of people more expert than me in the Saturn chipsets.

Due to this trailing 0, an attempt to execute RSI on a 1LF2 will probably put the CPU out of sync with the next opcodes.

As for the effect of RSI on a HP-71 with 1LK7, I don't know. Actually I'm not sure of the exact effect of RSI on the 28C.

The SASM doc says:
"This instruction causes CPU to consider any input line (ie
input register bits) presently high as a new interrupt. If
the CPU is presently in the interrupt routine it will wait
for an RTI before vectoring, otherwise the CPU will vector
immediately following the RSI instruction. For a complete
discussion on the interrupt system see the CPU Hardware
Specification (A-1LK7-9005-1). This instruction is not
available on the 1LF2 version of the Saturn CPU."

This description is not fully clear for me, and unfortunately, I don't have access to the 1LK7 CPU Hardware Specification.

J-F

Well, it seems you have found one of the many Saturn "opcode holes" I don't know why the RSI instruction was encoded as 0x80810 -- perhaps HP was planning on adding more opcodes in future Saturn chips but they never got around to it?

Anyway, I don't know about the HP-71B 1LF2 or 1LK7 CPUs, but on the Yorke Saturn it seems that invalid opcodes are just ignored. For example, the following code contains the invalid opcode 0x80811 . I̵f̵ ̵I̵ ̵a̵p̵p̵e̵n̵d̵ ̵a̵ ̵0̵x̵0̵4̵ ̵t̵o̵ ̵t̵h̵e̵ ̵o̵p̵c̵o̵d̵e̵ ̵t̵h̵e̵n̵ ̵t̵h̵e̵ ̵R̵4̵=̵A̵ ̵i̵n̵s̵t̵r̵u̵c̵t̵i̵o̵n̵ ̵i̵s̵ ̵e̵x̵e̵c̵u̵t̵e̵d̵ -- EDIT : Actually, I made an oopsie -- the above invalid opcode with just 0x04 appended is actually SETHEX. If I append 0x104 then it's R4=A , as demonstrated in the following code :

Code:
ASSEMBLE     NIBASC    /HPHP48-R/ RPL CODE     GOSBVL    =SAVPTR     A=0    W     R4=A     LAHEX    0123456789ABCDEF     NIBHEX    80811104     A=R4     P=    15     GOVLNG    =PUSHhxsLoop ENDCODE

I've attached an HP48G-R compatible compiled binary of the above code to this message.

( NOTE : The on-calc checksum is # F393h )

Regards,

Jonathan

Attached File(s)