Threaded Mode | Linear Mode

Ángel Martin · (This post was last modified: 08-24-2019 05:17 PM by Ángel Martin.)

(08-24-2019 05:06 PM)rprosperi Wrote: If the HEPAX, Advantage and IR modules handled these special OpCodes in h/w, how are CL, V41, etc. able to reproduce that behavior, meaning how do you know exactly what to have the emulation layer do to emulate the module's h/w behavior?

Good question, on V41 for sure it does it all itself since it's a software emulation. In the CL I'm not sure, it looks to me it has to allow the physical module to do it itself if plugged, but yet it should do it itself when it is a VIRTUAL plug, from the MMU settings...

Sylvain Cote · (This post was last modified: 08-24-2019 06:37 PM by Sylvain Cote.)

(08-24-2019 05:15 PM)Ángel Martin Wrote: So "0AB0" HEPCHN will give you access to HRAMS in pages A and B, whereas "0CD0" will address the HRAM pages C and D. That was the example I mentioned in the previous post.

Ok, but in your example, if I understood correctly, I am technically loosing 2 pages (either AB or CD) that I could be used to hold some other ROM.
Since we are talking 41CL only stuff here, IMHO I think the idea of having multiple HRAM sets in 41CL RAM with 1 MMU mapped at the time in OS41 space is more resource efficient, offers more space and is more flexible.

Monte Dalrymple · 08-24-2019, 08:31 PM

(08-24-2019 05:06 PM)rprosperi Wrote: If the HEPAX, Advantage and IR modules handled these special OpCodes in h/w, how are CL, V41, etc. able to reproduce that behavior, meaning how do you know exactly what to have the emulation layer do to emulate the module's h/w behavior?

Is it "simply" educated guessing (e.g. looking at disassembled code, then taking a stab), followed by lots of testing, then rinse and repeat until it works?

For the Advantage and IR modules the special opcode is an ENROM instruction. This is also one of the cases for Hepax. The operation of this opcode is understood at a macro level, but there has always been the question of whether the following instruction is fetched from the current bank or the next bank. It seems that even HP wasn't sure about this, always placing the same instruction in that location in both banks. I don't remember which way I did it in the NEWT, but it works because the code tolerates either way. Unfortunately I don't know of an easy way to determine which way the legacy hardware actually works, because it would require modifying the contents of the physical ROM to test.

The Hepax uses a different opcode to "move" the code to a different page. Since this is unique to the Hepax, and wouldn't work anyway given the MMU, the Hepax image used in the 41CL actually has that piece of the code removed from the image.

The IR printer also uses the special Peripheral instructions, which are also NOPs as far as the CPU is concerned. This operation is also well understood as far as the CPU is concerned, but I have never been able to find any documentation on how the IR module interprets them. I started looking at the code some time ago, but there are at least a dozen different "instructions" used and it's probably going to be impossible to figure out what they do from just looking at the code.

Ángel Martin · (This post was last modified: 08-24-2019 10:21 PM by Ángel Martin.)

(08-24-2019 06:35 PM)Sylvain Cote Wrote:
(08-24-2019 05:15 PM)Ángel Martin Wrote: So "0AB0" HEPCHN will give you access to HRAMS in pages A and B, whereas "0CD0" will address the HRAM pages C and D. That was the example I mentioned in the previous post.
Ok, but in your example, if I understood correctly, I am technically loosing 2 pages (either AB or CD) that I could be used to hold some other ROM.

I wouldn't say "lose" the pages - they are still there ;-) to be used by the HEPAX alternate configuration when they become active. And this option is valid for both the CL and non-CL systems.

(08-24-2019 06:35 PM)Sylvain Cote Wrote: Since we are talking 41CL only stuff here, IMHO I think the idea of having multiple HRAM sets in 41CL RAM with 1 MMU mapped at the time in OS41 space is more resource efficient, offers more space and is more flexible.

That's a sure thing, no discussion there.

Ángel Martin · (This post was last modified: 08-24-2019 10:26 PM by Ángel Martin.)

(08-24-2019 08:31 PM)Monte Dalrymple Wrote: The Hepax uses a different opcode to "move" the code to a different page. Since this is unique to the Hepax, and wouldn't work anyway given the MMU, the Hepax image used in the 41CL actually has that piece of the code removed from the image.

And it works just great with the HEPINI function to manually do what the HEPAX did automatically in the CALC_ON event/

BTW there's another special OpCode used by the HEPAX to write-protect an HRAM page, those guys thought of everything it seems...

(08-24-2019 08:31 PM)Monte Dalrymple Wrote: The IR printer also uses the special Peripheral instructions, which are also NOPs as far as the CPU is concerned. This operation is also well understood as far as the CPU is concerned, but I have never been able to find any documentation on how the IR module interprets them. I started looking at the code some time ago, but there are at least a dozen different "instructions" used and it's probably going to be impossible to figure out what they do from just looking at the code.

Same here, it's a tough one to figure out...

Sylvain Cote · (This post was last modified: 08-28-2019 12:30 AM by Sylvain Cote.)

Hello Podalirius,

I was able to successfully backup/restored HRAM 16K set to/from HP-IL mass storage media.

PowerCL (PWRL) module functions WRTPG/READPG works beautifully for that job. (thank you Ángel)
Unfortunately HEPAX module functions WRTROM/READROM are no so willing, these functions are modifying the image content rendering them useless for our purpose.

Look at step 9 (backup) and step 12 (restore) for your answer.

The only part missing from the initial request is the backup/restore of the MMU configuration sets.
That will have to wait a bit, I have a test job to finish for Monte before being able to address this final part.

Best regards,

Sylvain

PS: The following steps shows the process I went thru to validate the HRAM backup/restore and its integrity.

Basic configuration
Copy HRAM Templates
Map ROM & HRAM to 41OS space
Initialize HRAM-1 (HRAM set #1)
Copy empty HRAM-1 to HRAM-2 (41CL RAM-to-RAM copy, HRAM set #2)
Enter FOCAL HRAM data test program
Load data into HRAM-1
Setup HP-IL with a mass storage device
Backup HRAM-1 to an HP-IL mass storage media using PowerCL module WRTPG function
Backup HRAM-1 to an HP-IL mass storage media using HEPAX module WRTROM function
Copy empty HRAM-2 to HRAM-1 (erasing HRAM-1 content)
Restore HP-IL mass storage media data to HRAM-1 using PowerCL module READPG function
Validating HRAM-1 data integrity
Copy empty HRAM-2 to HRAM-1 (erasing HRAM-1 content)
Restore HP-IL mass storage media data to HRAM-1 using HEPAX module READROM function (failed)
Cleanup

Warning: HP-IL interface must not be plugged-in at the beginning of this procedure.

01) Basic configuration

Code:

MMUDIS                // disable MMU, will lockup the calculator if HP-IL module is plugged-in

MMUCLR                // clear MMU configuration Set 0

"YFNX"     PLUG1U     // plug YFNX module to page 9

MMUEN                 // enable MMU

CLKEYS                // clear user defined keys in order to not interfere with program local labels below

02) Copy HRAM Templates to 4 consecutive RAM pages (0x838 to 0x83B) and for this example name it HRAM-1

Code:

"0B9>838"  YMCPY      // copy HEPAX RAM template 0x0B9 to 41CL RAM page 0x838

"0B9>839"  YMCPY      // copy HEPAX RAM template 0x0B9 to 41CL RAM page 0x839

"0B9>83A"  YMCPY      // copy HEPAX RAM template 0x0B9 to 41CL RAM page 0x83A

"0B9>83B"  YMCPY      // copy HEPAX RAM template 0x0B9 to 41CL RAM page 0x83B

03) Map ROM and HRAM to 41OS space

Code:

"4LIB 4"   PPLUG      // plug 4LIB ROM to page 0x4

"OSX3 8"   PPLUG      // plug OSX3 module to page 0x8

"PWRL A"   PPLUG      // plug PWRL module to page 0xA

"%838 C"   PPLUG      // plug 0x838..0x83B HePaX RAM area to pages 0xC..0xF

"HEP2 B"   PPLUG      // mapping HePaX ROM to page 0xB

04) Initialize HRAM using HEPINI from PowerCL module (named HRAM-1 in this session)

Code:

HEPINI 4 C            // initialize HEPAX RAM 4 pages starting at page 0xC

HEPROOM               // should return 2610 in X

05) Copy empty HRAM-1 pages (0x838 to 0x83B) to HRAM-2 pages (0x83C to 0x83F)

Code:

"838>83C"  YMCPY      // copy empty HEPAX RAM at page 0x838 to page 0x83C

"839>83D"  YMCPY      // copy empty HEPAX RAM at page 0x839 to page 0x83D

"83A>83E"  YMCPY      // copy empty HEPAX RAM at page 0x83A to page 0x83E

"83B>83F"  YMCPY      // copy empty HEPAX RAM at page 0x83B to page 0x83F

06) Enter FOCAL HRAM data test program

Local labels

Code:

LBL A : create HEPAX data test file filled up with data  (run time: ~ 2m36s in TURBO 50 mode)

LBL C : validate HEPAX data test file                    (run time: ~ 2m30s in TURBO 50 mode)

LBL E : delete HEPAX data test file                      (run time: negligible)

Program listing (press "View a Printable Version" at the bottom of the web page to get a more readable version)

Code:

LBL "HRAMTD"          // HRAM content initialisation & validation

SF 27                 // activate USER mode

GTO 00

                      // ---------------------------------------------------------------------------

LBL 99                // infinite loop

PROMPT

LBL 00                // show menu

"C    V    D"         // Create, Validate & Delete assigned to letters A, C & E (aka local labels)

GTO 99

                      // ---------------------------------------------------------------------------

LBL A                 // create HEPAX data file

XEQ 90                // start timer

CF 25                 // activate duplicate file error or not enough memory error

"TD"

2400

HCRFLD                // create HEPAX data file => name: "TD" size: 2400 registers

RDN                   // manage stack

0                     // init counter

SF 25                 // ignore end of data file error

LBL 01                // set data loop

1

+                     // increment counter

HSAVEX                // save X in HEPAX data file

FS? 25                // have we reached end of data file ?

GTO 01                // nop!

1                     // yes, adjust counter

-                     // number of records (should be 2400)

XEQ 91                // stop timer, expected running time ~ 2m36s in TURBO 50 mode

X<>Y                  // swap run time with number of records

"TD CREATED"

AVIEW

BEEP                  // warn user HEPAX data file has been created and initialized

GTO 99                // X = number of records and Y = running time

                      // ---------------------------------------------------------------------------

LBL C                 // validate HEPAX data file

XEQ 90                // start timer

CF 25                 // activate file not found error

"TD"

0

HSEKPTA               // set HEPAX data pointer to the beginning of the file

SF 25                 // ignore end of data file error

LBL 02

HGETX                 // get in X current HEPAD data record and increment data pointer

FS? 25                // have we reached end of file

+                     // no, do the calculation

FS? 25                // have we reached end of file

GTO 02                // loop for more records

XEQ 91                // stop timer, expected running time ~ 2m30s in TURBO 50 mode

X<>Y                  // swap run time with magic number

2881200               // result of the sum of all values

-                     // if X = 0 then the data was valid otherwise it is not

X=0?

"TD VALID"

X#0?

"TD INVALID"

AVIEW

BEEP                  // warn user HEPAX data file has been validated successfully or not

GTO 99                // X = substraction with magic number result and Y = running time

                      // ---------------------------------------------------------------------------

LBL E                 // erase HEPAX data file

SF 25                 // ignore file not found error

"TD"

HPURFL                // delete HEPAX data file => name: "TD"

FC?C 25               // was file found ?

GTO 99                // no, leave, stack unchanged

"TD PURGED"           // yes, warn user

AVIEW

BEEP                  // warn user HEPAX data file has been deleted

GTO 99                // stack unchanged

                      // ---------------------------------------------------------------------------

LBL 90                // start timer

STOPSW

0

SETSW

RDN

RUNSW

RTN

                      // ---------------------------------------------------------------------------

LBL 91                // stop timer

STOPSW

RCLSW

END                   // return running time

07) Load data into HRAM-1

Code:

XEQ "HRAMTD"          // execute test program, display: "C    V    D"

press "A"             // execute local label A, [C]reate HEPAX data test file filled up with data

                      //   display "TD CREATED" if successfull  (run time: ~ 2m36s in TURBO 50 mode)

HEPDIR                // should display: "TD      DA      2400"

press "C"             // execute local label C, [V]alidate HEPAX data test file

                      //   display "TD VALID" if successfull    (run time: ~ 2m30s in TURBO 50 mode)

08) Setup HP-IL with a mass storage device

Code:

OFF                   // put calculator in sleep mode

                      // insert the HP-IL module, 

                      // plug your PIL-Box, start an HP-IL Peripheral simulator (ILPER or pyILPER) and configure a virtual mass storage device

                      // or plug a physical mass storage device (82161A, 9114A/B, etc)

ON                    // wake up the calculator

CAT 0                 // OSX3 enhanced catalog 0 list HP-IL devices AID on the loop

                      // the catalog list must include a valid mass storage AID ("AID 16", "HP9114B", etc)

NEWM 128              // format mass storage media and allow space for 128 files

09) Backup HRAM-1 to an HP-IL mass storage media using PowerCL module WRTPG function

Code:

"PHR1C"  12  WRTPG    // write page 12 (0xC) to file "PHR1C" on mass storage media (PowerCL HRAM #1 Page C)

"PHR1D"  13  WRTPG    // write page 13 (0xD) to file "PHR1D" on mass storage media (PowerCL HRAM #1 Page D)

"PHR1E"  14  WRTPG    // write page 14 (0xE) to file "PHR1E" on mass storage media (PowerCL HRAM #1 Page E)

"PHR1F"  15  WRTPG    // write page 15 (0xF) to file "PHR1F" on mass storage media (PowerCL HRAM #1 Page F)

DIR                   // should display

                      // NAME    TYPE     REGS

                      // PHR1C   ??,S      640

                      // PHR1D   ??,S      640

                      // PHR1E   ??,S      640

                      // PHR1F   ??,S      640

10) Backup HRAM-1 to an HP-IL mass storage media using HEPAX module WRTROM function

Code:

"HHR1"

12.15

WRTROM                // write page 12 to 15 (0xC to 0xF) to file "HHR1" on mass storage media

DIR                   // should display

                      // NAME    TYPE     REGS

                      // PHR1C   ??,S      640

                      // PHR1D   ??,S      640

                      // PHR1E   ??,S      640

                      // PHR1F   ??,S      640

                      // HHR1    DA       2560

11) Copy empty HRAM-2 pages (0x83C to 0x83F) to HRAM-1 pages (0x838 to 0x83B) (erasing HRAM-1 content)

Code:

"83C>838"  YMCPY      // copy empty HEPAX RAM at page 0x83C to page 0x838

"83D>839"  YMCPY      // copy empty HEPAX RAM at page 0x83D to page 0x839

"83E>83A"  YMCPY      // copy empty HEPAX RAM at page 0x83E to page 0x83A

"83F>83B"  YMCPY      // copy empty HEPAX RAM at page 0x83F to page 0x83B

HEPROOM               // should return 2610 in X

12) Restore HP-IL mass storage media data to HRAM-1 using PowerCL module READPG function

Code:

"PHR1C"  12  READPG   // read file "PHR1C" from mass storage media to page 12 (0xC)

"PHR1D"  13  READPG   // read file "PHR1D" from mass storage media to page 13 (0xD)

"PHR1E"  14  READPG   // read file "PHR1E" from mass storage media to page 14 (0xE)

"PHR1F"  15  READPG   // read file "PHR1F" from mass storage media to page 15 (0xF)

13) Validating data integrity

Code:

HEPDIR                // should display: "TD      DA      2400"

XEQ "HRAMTD"          // execute test program, display: "C    V    D"

press "C"             // execute local label C, [V]alidate HEPAX data test file

                      //   display "TD VALID" if successfull    (run time: ~ 2m30s in TURBO 50 mode)

14) Copy empty HRAM-2 pages (0x83C to 0x83F) to HRAM-1 pages (0x838 to 0x83B) (erasing HRAM-1 content)

Code:

"83C>838"  YMCPY      // copy empty HEPAX RAM at page 0x83C to page 0x838

"83D>839"  YMCPY      // copy empty HEPAX RAM at page 0x83D to page 0x839

"83E>83A"  YMCPY      // copy empty HEPAX RAM at page 0x83E to page 0x83A

"83F>83B"  YMCPY      // copy empty HEPAX RAM at page 0x83F to page 0x83B

HEPROOM               // should return 2610 in X

15) Restore HP-IL mass storage media data to HRAM-1 using HEPAX module READROM function (failed)

Code:

"HHR1"

12.15

READROM               // read file "HHR1" from mass storage media and save it to pages 12 to 15 (0xC to 0xF)

                      // unfortunately we get the message "H:CHKSUM ERR" at the end of the file retrieval

                      // meaning WRTROM and/or READROM functions are modifying the ROM images 

HEPDIR                // is giving us: "H:NO FILESYS"

Note: I will investigate later who from WRTROM or READROM is modifying the image

16) Cleanup

Code:

OFF                   // put calculator in sleep mode

                      // unplug HP-IL module

ON                    // wake up the calculator

MMUDIS                // disable MMU, will lockup the calculator if HP-IL module is plugged-in

MMUCLR                // clear MMU configuration set 0

CLP "HRAMTD"          // delete HRAM test program

edit: typo

hth · 09-01-2019, 02:41 AM

(08-24-2019 08:31 PM)Monte Dalrymple Wrote:
(08-24-2019 05:06 PM)rprosperi Wrote: If the HEPAX, Advantage and IR modules handled these special OpCodes in h/w, how are CL, V41, etc. able to reproduce that behavior, meaning how do you know exactly what to have the emulation layer do to emulate the module's h/w behavior?

Is it "simply" educated guessing (e.g. looking at disassembled code, then taking a stab), followed by lots of testing, then rinse and repeat until it works?

For the Advantage and IR modules the special opcode is an ENROM instruction. This is also one of the cases for Hepax. The operation of this opcode is understood at a macro level, but there has always been the question of whether the following instruction is fetched from the current bank or the next bank. It seems that even HP wasn't sure about this, always placing the same instruction in that location in both banks. I don't remember which way I did it in the NEWT, but it works because the code tolerates either way. Unfortunately I don't know of an easy way to determine which way the legacy hardware actually works, because it would require modifying the contents of the physical ROM to test.

According to the SDS-II manual (the HP MCODE development tools back in the days), the 1LG9 chip, which is the HP memory that supports bank switching, bank switching takes place immediately after executing the ENROMx instruction and it is possible to switch banks on the fly to continue execution at the next address in a different bank.

Then why are not banks switched on the fly by old ROMs you might wonder. I think the reason is not due to hardware limitations, but rather limitations in tools. My coming tools (in beta at the moment) has a linker that can deal with placement of banked fragments relative each other based on assembler directives, to allow for switching banks on the fly. I do not think there are similar support in SDS-II, making it quite a bit harder to do it, but probably not impossible.

There are a couple of things with this 1LG9 chip. It requires that the ENROMx instruction to be preceded by an instruction with the highest bit cleared. HP code uses a "GOTO $+1" instruction before any bank switch instruction to ensure this. Also bank switching only takes place in the 1LG9 chip where the ENROMx instruction is fetched from. Having multiple 1LG9 based modules plugged in means that only the one providing the ENROMx instruction will switch bank.

We no longer have the 1LG9 and no ability to program such chips. The current crop of memories (MLDL2000, NEWT and Clonix) support bank switching in a similar, but not identical way. The obvious difference is that these memories provide more pages and can handle multiple modules. To make it mimic 1LG9, MLDL2000 and NEWT defines bank switching to be page 8-9, A-B, C-D and E-F (with some special rules on the low pages). Essentially following the plug-in module addressing scheme. Clonix is different in this, in that it actually bank switch all pages and have no such grouping at all.

This might sound a bit alarming, but so far it has not posed any problems due to the way modules are written (similar to in the old days) and bank switching all address pages on the Clonix has not been a source of problems, as no low pages are bank switched (apart from IR printer and 41CX ROMs, but that works as they are handled outside Clonix).

At least Clonix will have a problem if we ever start to bank switch page 4 and make it some library or system extension page. This will require some reprogramming of its firmware. It may also cause some issues with MLDL2000 and NEWT, but I have not investigated that. But there is no problem at the moment.

It can also be worth looking at that 1LG9 only checks the ENROMx instruction if executed from within the chip. I think the other mentioned memories do the same. Old MLDLs however, read instructions on the bus and can react to the WROM (write to ROM) coming from other devices, i.e. a Zenrom. This way a Zenrom (or other module with write-to-ROM functions) can work together with a RAM only box. This can be studied in the original MLDL design in that old PPC journal. For a memory chip, it is probably a lot easier to just decode the instruction fetched internally rather than implement logics for reading instructions that appear on the bus (as on the MLDL).

(08-24-2019 08:31 PM)Monte Dalrymple Wrote: The IR printer also uses the special Peripheral instructions, which are also NOPs as far as the CPU is concerned. This operation is also well understood as far as the CPU is concerned, but I have never been able to find any documentation on how the IR module interprets them. I started looking at the code some time ago, but there are at least a dozen different "instructions" used and it's probably going to be impossible to figure out what they do from just looking at the code.

I think the best way forward here would be to try and track down some engineer that worked on the code or the IR module hardware. Peter Platzer had in his possession an MLDL that seemed to have been used for developing the firmware for that IR module. If he has some records where he got it, it might be possible to trace it backwards? Otherwise there may be people that are known to have worked on it or close to it at the time?

I mean, I implemented some algorithm for a quite cool optimization around 1994. I recently found my sketchbook from the time with all background information and the design of it. Information may exist and may be found if one asks the right person at the right time... Just a thought.

Ángel Martin · (This post was last modified: 09-01-2019 07:26 AM by Ángel Martin.)

Great insights indeed, thanks for sharing them.

(09-01-2019 02:41 AM)hth Wrote: This might sound a bit alarming, but so far it has not posed any problems due to the way modules are written (similar to in the old days) and bank switching all address pages on the Clonix has not been a source of problems, as no low pages are bank switched (apart from IR printer and 41CX ROMs, but that works as they are handled outside Clonix).

In fact just the opposite: sometimes I've taken advantage of such arrangements, using calls to a second-bank in the paired page from the second-bank in the original one. Unorthodox yes,, but No risk no fun, uh? ;-)

(09-01-2019 02:41 AM)hth Wrote: At least Clonix will have a problem if we ever start to bank switch page 4 and make it some library or system extension page. This will require some reprogramming of its firmware. It may also cause some issues with MLDL2000 and NEWT, but I have not investigated that. But there is no problem at the moment.

This is good to know, a Bank-switched Page-4 is still a possibility to achieve compatibility with the current implementations. It is available on the latest batch of CL's.

(09-01-2019 02:41 AM)hth Wrote: It can also be worth looking at that 1LG9 only checks the ENROMx instruction if executed from within the chip. I think the other mentioned memories do the same. Old MLDLs however, read instructions on the bus and can react to the WROM (write to ROM) coming from other devices, i.e. a Zenrom. This way a Zenrom (or other module with write-to-ROM functions) can work together with a RAM only box. This can be studied in the original MLDL design in that old PPC journal. For a memory chip, it is probably a lot easier to just decode the instruction fetched internally rather than implement logics for reading instructions that appear on the bus (as on the MLDL).

You can always force the switching by calling to the ENROMx in that page from a different one. The final RTN will ensure a return to the original caller, which effectively "drives" all the BS from a common point. I used this in CPYBNK the Copy Bank function, and more extensively in the Auto-Complete XEQ+ to access sub-functions in *any* page from the same central place. This requires all the ENROM/RTN's pairs to be placed in the same addresses - as they always are by convention from 0xpFC3 to 0xpFCA

(09-01-2019 02:41 AM)hth Wrote:
(08-24-2019 08:31 PM)Monte Dalrymple Wrote: The IR printer also uses the special Peripheral instructions, which are also NOPs as far as the CPU is concerned. This operation is also well understood as far as the CPU is concerned, but I have never been able to find any documentation on how the IR module interprets them. I started looking at the code some time ago, but there are at least a dozen different "instructions" used and it's probably going to be impossible to figure out what they do from just looking at the code.

I think the best way forward here would be to try and track down some engineer that worked on the code or the IR module hardware. Peter Platzer had in his possession an MLDL that seemed to have been used for developing the firmware for that IR module. If he has some records where he got it, it might be possible to trace it backwards? Otherwise there may be people that are known to have worked on it or close to it at the time?

In my experience all the new memories switch "on the fly" with no need for any "warm-up" instruction. It is in the return to bank-1 where there are sometimes complications, and the implementations differ. The safest way is to always return by code, although the PWOFF opcode can be used as a safe to ensure the same.

Best,
'AM

Ángel Martin · 09-16-2019, 08:36 AM

Closing on the HEPAX initialization, I've added a new article in the articles section that provides plenty of details - read at your leisure if you're interested.

https://www.hpmuseum.org/forum/thread-13...#pid121047

I believe this finally explains why its implementation on V41 is only partially correct BTW, the HEPAX ROM is not moved back to its initial location when the calculator is switched OFF...[/code]