Threaded Mode | Linear Mode

J-F Garnier · 06-17-2020, 08:44 PM

(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

**rprosperi** · 06-17-2020, 10:23 PM

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 Wink

KimH · 06-18-2020, 06:09 AM

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

KimH · 06-18-2020, 07:08 AM

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

Christoph Giesselink · (This post was last modified: 06-19-2020 11:40 AM by Christoph Giesselink.)

(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.

J-F Garnier · 06-19-2020, 08:05 AM

(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

Valentin Albillo · 06-19-2020, 03:40 PM

(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.

KimH · 06-19-2020, 04:40 PM

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.

Hope this is helpful.

/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

J-F Garnier · 06-19-2020, 05:08 PM

(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

Dave Frederickson · 06-19-2020, 06:02 PM

(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?

HP-71 BASIC Made Easy, p133.

J-F Garnier · 06-19-2020, 06:20 PM

(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?

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

Sylvain Cote · 06-19-2020, 06:42 PM

Here is the BASIC listing for both DUMPLEX and MAKELEX from the Old HP Forum Archives

Dave Frederickson · 06-19-2020, 06:50 PM

(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

 3405556554250202 0B

 802E008581816002 66

 B6000C5101000000 45

 F710000000000000 A7

 061000F734055565 11

 101FF0079002EB06 58

 6220071321BB98F2 E2

 144132AF2808CAF2 EC

 AF28D612F00      28

J-F Garnier · 06-20-2020, 07:51 AM

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

Jonathan Busby · (This post was last modified: 06-23-2020 06:23 PM by Jonathan Busby.)

(05-04-2014 10:56 PM)Christoph Giesselink Wrote:
(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 Smile

I'd imagine that would have been caught early in the design phase as it would have made the chip unstable Smile

).

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 Smile

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 Smile

( I've measured ~3.9MHz+ clock speeds on HP48GXs manufactured in Singapore, China and Indonesia Smile

)

Regards,

Jonathan

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

Mark Hardman · 06-21-2020, 09:55 PM

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:

RMollov · (This post was last modified: 06-22-2020 04:50 AM by RMollov.)

(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,

Giuseppe Donnini · 06-28-2020, 02:11 AM

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?

J-F Garnier · 06-28-2020, 07:35 AM

(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

Jonathan Busby · (This post was last modified: 07-29-2020 10:26 PM by Jonathan Busby.)

(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" Smile

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 Tongue

-- 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