(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
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
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
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-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.
(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-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.
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
(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)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
(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
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
(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
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")
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:
(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,
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 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
(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