+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: Articles Forum (/forum-14.html)
+--- Thread: The Amazing HEPAX MCODE Initialization Process (/thread-13665.html)
The Amazing HEPAX MCODE Initialization Process - Ángel Martin - 09-16-2019 08:23 AM
The Amazing HEPAX Initialization Process.
The following describes the initialization process performed by the HEPAX module to relocate its own ROM and to initialize the Hepax FileSystem in the HEPRAM pages. It's a very clever and tricky process, better read it slowly and attentively ;-)
Top-level process Quick Description
Suppose you plug the Standard HEPAX in PORT-1, that is pages #8 & #9. At that moment both the HEPAX ROM *and* the first HEPRAM are mapped to pg#8, and the second HEPRAM to pg#9. -
Then you switch the calculator ON, and triggered by the CALC_ON event, the initialization routine in page#8 from the Hepax ROM starts running, looking for available pages to relocate itself. These can possibly be either internal (#5, #6, #7) or external above the HEPRAM. , i.e. #A-F. If no pages are available an error message is shown (“ ILL CONFIG”) and the initialization aborts, leaving the HEPAX ROM in a double-mapped page#8, and the FIleSystem not ready.
But chances are that at least one free page is available (otherwise remove other modules until that's the case). After the relocation is successfully made the HEPROM continues to run MCODE to initialize the FileSystem in HEPRAM. By now the HEPRAM in pg#8 is not occluded anymore, since the previous double-mapping has been resolved.-
When the calculator is switched OFF things go back to the initial status, with the Hepax ROM mapped to page#8. The user may want to add/remove modules using any of the free pages and therefore the HEPAX ROM needs to "come back home" and free its borrowed page.
All the above is repeated every time the calculator is switched ON, so there's no difference between the "first" time and all others.
A more detailed view of the process.
The [FILESYS] routine is executed when the calculator is turned on by the CALC_ON event. Its first purpose is to look for the lowest available page to relocate the HEPAX ROM and to configure the FileSystem in HEPRAM.
Initially the Hepax ROM is located in an even external page, i.e. #8, #A,#C or #E. After the relocation it may get plugged in an internal page like #5 (if the TIME module is not there), #6 or #7 (if the HP-IL is not present). But it may also be reallocated to another external page, above the HEPRAM in pages #8 and #9.
Should that be the case, we need to avoid a repetition of the execution that would take place when the OpSys reaches the new location during the polling points interrogation of the I/O bus. This is achieved by flagging the poll vector during the first execution (i.e. when it was run from page#8), writing "E" in the 11th. Nybble. The code checks for this and skips the initialization if the nybble is marked.
Another criteria used to skip the initialization exists: the code checks whether the Hepax ROM is located in an odd page, which can only be the case if it had already been relocated. When that's the case the initialization is also skipped.
Note that this is so by design: the reallocation is undone every time the calculator is switched OFF (via Hardware latch), thus the Hepax ROM is always located in an even page upon CALC_ON
Note as well that the method used to relocate the Hepax ROM needs the existence of a HEPRAM page present in the BUS to write two instructions in it { BLKMOV, RTN }, and to transfer the execution to that code stub from the Hepax ROM via GOTOADR OpCode. This also requires pushing a new RTN address in the RTN stack so the execution will return to the relocated address after that RTN, and not to the place it was transferred from (!)
This last comment explains why the commercial HEPAX modules always offered an even number of HEPRAM pages: either 2 (Standard HEPAX), or 4 (Advanced HEPAX). The first HEPRAM page is initially occluded by the Hepax ROM, thus the re-location code stub needs to be written in the next page.
Side bar:
The table below shows the pointers and control words written in every HEPRAM block during the FileSystem initialization:
Code:
Address Byte value Comment
x000 ROM id# => not same as pg# Always done
xFE7 Previous HRAM page# (zero if 1st.) Always done
xFE8 Next HRAM page# (zero if last) Always done
xFE9 Fixed value = 091 Won’t be overwritten if not zero
xFED Fixed value = 090 Done always
xFEF Fixed value = 091 Won’t be overwritten if not zero
xFF1 Fixed value = 0E5 Done always
xFF2 Fixed value = 00F Done always
XFF3 Fixed value = 200 (or 100) Done alwaysHepax RAM Contents volatility.
The Hepax RAM contents are maintained while the Hepax Module is plugged into the calculator. Adding or removing other modules does not affect the Hepax RAM at all - remember that programs in HepRAM can be run directly, no need to copy them to Main Ram first like it happens with X-Memory. A Hepax RAM page is seen by the OS as another plug-in ROM with FOCAL code in it.
The original Hepax was introduced in 1987. The custom chips included were not “Flash Memory”, so the HepRAM contents were lost when you removed the module from the calculator. This was a design limitation, not an intended feature. Newer HEPAX clones like the NoVoRAM offer flash-EPROMS that maintain the HepRAM contents even when the module is disconnected.
There are several other things being checked during the initialization, such as the write-protected status of the HEPRAM pages and the existence of new HEPRAM pages to name just two. The code is very cleverly written and it's a pleasure to behold - all that complexity completely transparent to the user.
FILESYS MCODE Details
See the attached pdf for a complete listing of the FILESYS routine.