Threaded Mode | Linear Mode

**rprosperi** · 08-22-2019, 05:47 PM

The HEPAX functions READROM and WRTROM are intended exactly for copying a ROM image to and from mass storage.

Similarly, HREADFL and HWRTFL are HEPAX functions for copying individual files stored in HEPAX RAM.

One idea is you could probably write a small program to copy the MMU config info to a new HEPAX data file, then Save the entire image (including that file) to HP-IL.

Sylvain Cote · 08-22-2019, 07:38 PM

Hello Monte & Robert,
Thank you for the information, I will look at it tonight.
Sylvain

Monte Dalrymple · 08-22-2019, 07:52 PM

(08-22-2019 07:38 PM)Sylvain Cote Wrote: Hello Monte & Robert,
Thank you for the information, I will look at it tonight.
Sylvain

But I just remembered that Hepax thinks that the RAM is only 10 bits wide. Not so the MMU registers/41CL RAM, so it's going to take some futzing (that's a technical term :-) ) with the data. Geir Isene had to handle this when he did the HP-IL update stuff, so I would look at that code as a starting point.

**rprosperi** · 08-22-2019, 09:31 PM

(08-22-2019 07:52 PM)Monte Dalrymple Wrote: But I just remembered that Hepax thinks that the RAM is only 10 bits wide. Not so the MMU registers/41CL RAM, so it's going to take some futzing (that's a technical term :-) ) with the data. Geir Isene had to handle this when he did the HP-IL update stuff, so I would look at that code as a starting point.

POP!!!

Yeah, that was my bubble...

That 10-bit ROM address in the 41 has always been a real pain in the neck. Some have even a lower opinion...

Sylvain Cote · 08-22-2019, 10:54 PM

(08-22-2019 09:31 PM)rprosperi Wrote:
(08-22-2019 07:52 PM)Monte Dalrymple Wrote: But I just remembered that Hepax thinks that the RAM is only 10 bits wide. Not so the MMU registers/41CL RAM, so it's going to take some futzing (that's a technical term :-) ) with the data. Geir Isene had to handle this when he did the HP-IL update stuff, so I would look at that code as a starting point.
POP!!!
Yeah, that was my bubble...
That 10-bit ROM address in the 41 has always been a real pain in the neck. Some have even a lower opinion...

LOL ... may I add another POP!!! ... ROTFL
The 10-bit is the instruction width of the Nut CPU, the addressing (PC) is 16-bit wide (64K or 16 pages of 4K).
Smile

Sylvain Cote · 08-23-2019, 12:44 AM

(08-22-2019 05:47 PM)rprosperi Wrote: The HEPAX functions READROM and WRTROM are intended exactly for copying a ROM image to and from mass storage.

HePaX Module Owner's Manual, Volume 1, Page 65.

Quote:Don’t use the READROM or WRTROM functions to read or write blocks that are used by the HEPAX file system.
Files under the file system should be transferred using HREADFL and HWRTFL.

I have not verified yet, but I am assuming for now that the READROM/WRTROM are modifying the checksum part of the ROM image and in doing so corrupting HePaX RAM pages.

Hint:

Quote:If you get a CHKSUM ERR message, this means that the data on the mass storage medium has been disrupted.

Sylvain

**rprosperi** · (This post was last modified: 08-23-2019 01:52 AM by rprosperi.)

(08-23-2019 12:44 AM)Sylvain Cote Wrote:
(08-22-2019 05:47 PM)rprosperi Wrote: The HEPAX functions READROM and WRTROM are intended exactly for copying a ROM image to and from mass storage.

HePaX Module Owner's Manual, Volume 1, Page 65.

Quote:Don’t use the READROM or WRTROM functions to read or write blocks that are used by the HEPAX file system.
Files under the file system should be transferred using HREADFL and HWRTFL.

Hmmm... well then what the heck is the point of the READROM or WRTROM functions? Does HEPAX see an H-RAM-based ROM image as distinctly different from files in the HEPAX file system?

Update:

Flip-flip-flip (actually click-click-clickity-click) Ah, yes - exactly that.

Sylvain Cote · (This post was last modified: 08-23-2019 02:25 AM by Sylvain Cote.)

What was really great at the time the HePaX was made available, 1988 or late 1987 I think,
was the capability to move RAM page(s) outside of the file system and made them as Q-ROM instead.
That instantly made obsolete external Q-ROM boxes for assembly language development.
Just imagine what would had happened if the HePaX modules has been made available five years earlier.

Ángel Martin · 08-23-2019, 05:40 AM

(08-23-2019 01:36 AM)rprosperi Wrote: Hmmm... well then what the heck is the point of the READROM or WRTROM functions? Does HEPAX see an H-RAM-based ROM image as distinctly different from files in the HEPAX file system?

Hepax FileSystem refers to the management of the individual files within the HEPAX RAM pages. Think of it as the X-Mem file system, so you have HSAVEP equivalent to SAVEP, HPURFL equivalent to PURFL, HEPDIR equivalent to EMDIR, etc.

READROM and WRTROM operate at the page level, i.e. the complete 4,096 words at once. You can copy one page int another, an external ROM into a HEPX RAM page.

And you;re right, for the OS an HEPAX RAM page is indistinguishable from another ROM page - but being RAM (EPROM really) their contents can be modified using WROM OpCodes.

Hope this clarifies.

ÁM

Ángel Martin · (This post was last modified: 08-23-2019 11:13 AM by Ángel Martin.)

(08-23-2019 02:23 AM)Sylvain Cote Wrote: What was really great at the time the HePaX was made available, 1988 or late 1987 I think,
was the capability to move RAM page(s) outside of the file system and made them as Q-ROM instead.
That instantly made obsolete external Q-ROM boxes for assembly language development.
Just imagine what would had happened if the HePaX modules has been made available five years earlier.

Absolutely, it was the ultimate MLDL-into-a-chip concept, an absolute tour de force ':-)
Even by today standards (NoVoRAM is even better as it preserves the RAM content unplugged and it's re-configurable of course) so back in 1988 it was truly revolutionary.Add to that the software with special OpCode to relocate itself into the lowest available page - an amazing feat!! The holy grail according to some ;=

PS. you're not likely to be familiar with the HEPAX initialization during the CAL_ON event, but it's a piece of SW art. The HEPAX first gets plugged into the lower page of the port where it is physically plugged, and it immediately runs some initialization code. That code establishes the bus parameters, and uses that information to write a code stub in the HEPAX RAM page. That small routine is then executed (!), which thanks to the custom OpCode re-allocates the HEPAX ROM into the smallest page available - and provides XROM id#'s for all the HEPAX RAM pages as well.

In two words: A-Mazing ;-)

Ángel Martin · 08-23-2019, 11:05 AM

(08-23-2019 05:40 AM)Ángel Martin Wrote:
(08-23-2019 01:36 AM)rprosperi Wrote: Hmmm... well then what the heck is the point of the READROM or WRTROM functions? Does HEPAX see an H-RAM-based ROM image as distinctly different from files in the HEPAX file system?

Hepax FileSystem refers to the management of the individual files within the HEPAX RAM pages. Think of it as the X-Mem file system, so you have HSAVEP equivalent to SAVEP, HPURFL equivalent to PURFL, HEPDIR equivalent to EMDIR, etc.

(edited:_)

READROM and WRTROM operate at the page level, i.e. the complete 4,096 words at once. You can write/read one page to/from HPIL drive. BTW there's also a COPYROM function that allows you to copy one page into another (if the destination is HEPAX RAM of course).

(edited:_)

And you're right, for the OS an HEPAX RAM page is indistinguishable from another ROM page - but being RAM (EPROM really) their contents can be modified using WROM OpCodes.

Hope this clarifies.

ÁM

**rprosperi** · 08-23-2019, 08:38 PM

(08-23-2019 05:43 AM)Ángel Martin Wrote: PS. you're not likely to be familiar with the HEPAX initialization during the CAL_ON event, but it's a piece of SW art. The HEPAX first gets plugged into the lower page of the port where it is physically plugged, and it immediately runs some initialization code. That code establishes the bus parameters, and uses that information to write a code stub in the HEPAX RAM page. That small routine is then executed (!), which thanks to the custom OpCode re-allocates the HEPAX ROM into the smallest page available - and provides XROM id#'s for all the HEPAX RAM pages as well.

Wow, really clever! More evidence of the genius of the HEPAX team, not that more is needed...

So, I have to ask: how can HEPAX create and use a custom OpCode, since the 41's CPU is fixed; i.e. how is the CPU's vocabulary extended?

Back to the READROM/WRTROM topic - why can't these commands be used to simply copy the block(s) that contains the HEPAX File System? It seems to be consistent with the descriptions in both the manual and your comments here, yet the manual suggests to not do so (though it does not say this will cause errors...). Perhaps the statement in the manual is merely pointing out that the file-level commands are available for more granular access than copying entire pages?

Monte Dalrymple · 08-23-2019, 08:52 PM

(08-23-2019 08:38 PM)rprosperi Wrote: So, I have to ask: how can HEPAX create and use a custom OpCode, since the 41's CPU is fixed; i.e. how is the CPU's vocabulary extended?

Any opcode that the CPU doesn't recognized is executed as a NOP as far as the CPU is concerned.

**rprosperi** · (This post was last modified: 08-23-2019 10:16 PM by rprosperi.)

(08-23-2019 08:52 PM)Monte Dalrymple Wrote:
(08-23-2019 08:38 PM)rprosperi Wrote: So, I have to ask: how can HEPAX create and use a custom OpCode, since the 41's CPU is fixed; i.e. how is the CPU's vocabulary extended?

Any opcode that the CPU doesn't recognized is executed as a NOP as far as the CPU is concerned.

That makes sense (though I did not know that, so thx) but how does a non-std OpCode, which is treated as NOP, let HEPAX do things like remap portions of code? Is it simply a marker for other code to recognize and then act upon?

Monte Dalrymple · 08-23-2019, 10:18 PM

(08-23-2019 10:05 PM)rprosperi Wrote:
(08-23-2019 08:52 PM)Monte Dalrymple Wrote: Any opcode that the CPU doesn't recognized is executed as a NOP as far as the CPU is concerned.

That makes sense (though I did not know that, so thx) but how does an a non-std OpCode, that is treated as NOP, let HEPAX do things like remap portions of code? Is it simply a marker for other code to recognize and then act upon?

Hardware outside the CPU watches for the opcode and acts when it sees it. I use the same technique with the WCMD instruction in the NEWT. Depending on the contents of one nibble in the C register (which is visible on the data bus) the logic sets the Turbo mode, reads or writes physical memory, enables or disables the MMU, etc. I would assume that logic in the Hepax module does something similar.

**rprosperi** · 08-23-2019, 11:09 PM

(08-23-2019 10:18 PM)Monte Dalrymple Wrote:
(08-23-2019 10:05 PM)rprosperi Wrote: That makes sense (though I did not know that, so thx) but how does an a non-std OpCode, that is treated as NOP, let HEPAX do things like remap portions of code? Is it simply a marker for other code to recognize and then act upon?

Hardware outside the CPU watches for the opcode and acts when it sees it. I use the same technique with the WCMD instruction in the NEWT. Depending on the contents of one nibble in the C register (which is visible on the data bus) the logic sets the Turbo mode, reads or writes physical memory, enables or disables the MMU, etc. I would assume that logic in the Hepax module does something similar.

OK, thanks. I was aware of that in the NEWT (which has power and speed to spare), but did not think the HEPAX module had such sophisticated capabilities back in 1987. The more I learn about it, the more impressive it is. Smile

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

(08-23-2019 11:09 PM)rprosperi Wrote:
(08-23-2019 10:18 PM)Monte Dalrymple Wrote: Hardware outside the CPU watches for the opcode and acts when it sees it. I use the same technique with the WCMD instruction in the NEWT. Depending on the contents of one nibble in the C register (which is visible on the data bus) the logic sets the Turbo mode, reads or writes physical memory, enables or disables the MMU, etc. I would assume that logic in the Hepax module does something similar.

OK, thanks. I was aware of that in the NEWT (which has power and speed to spare), but did not think the HEPAX module had such sophisticated capabilities back in 1987. The more I learn about it, the more impressive it is.

There are other examples: The Advantage Pac and the IR printer module also act on "special" OpCopes to switch their banks .... so it was not only the HEPAX. Also the ZEPROMS implemented their own bank-switching scheme... so imagine: the NUT CPU is happily NOPing while all that wild bank switching happens ;-)

As to the WRTROM/READROM instructions, absolutely they can be used on HEPAX RAM pages - so the user could (re)store their HEPAX RAM contents on disk.

IN fact, moving to the CL now, the user can have MULTIPLE sets of HEPAX RAM blocks in sRAM and manage them via (UN)PLUG commands to swap the sets on demand.

Even more interesting, with the HEPAX_4H revision two sets of HEPAX RAM pages can be plugged-in simultaneously and the Hepax FileSystem addressing can change the mapping of the respective sets. This requires functions HEPINI and HEPCHN but it really is quite easy.

Impressive indeed...

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

(08-24-2019 05:13 AM)Ángel Martin Wrote:
(08-23-2019 11:09 PM)rprosperi Wrote: OK, thanks. I was aware of that in the NEWT (which has power and speed to spare), but did not think the HEPAX module had such sophisticated capabilities back in 1987. The more I learn about it, the more impressive it is.

There are other examples: The Advantage Pac and the IR printer module also act on "special" OpCopes to switch their banks .... so it was not only the HEPAX. Also the ZEPROMS implemented their own bank-switching scheme... so imagine: the NUT CPU is happily NOPing while all that wild bank switching happens ;-)

In the end, we were somewhat lucky that HP did not upgrade their NUT CPU and used theses opcodes to do something else.

(08-24-2019 05:13 AM)Ángel Martin Wrote: As to the WRTROM/READROM instructions, absolutely they can be used on HEPAX RAM pages - so the user could (re)store their HEPAX RAM contents on disk.

I still need to test these ones, right now I am successfully writing and reading HRAM test pages using WRTPG/READPG from PowerCL 4X ROM.

(08-24-2019 05:13 AM)Ángel Martin Wrote: In fact, moving to the CL now, the user can have MULTIPLE sets of HEPAX RAM blocks in sRAM and manage them via (UN)PLUG commands to swap the sets on demand.

Yep! as demonstrated in the post #19 on this thread.

(08-24-2019 05:13 AM)Ángel Martin Wrote: Even more interesting, with the HEPAX_4H revision two sets of HEPAX RAM pages can be plugged-in simultaneously and the Hepax FileSystem addressing can change the mapping of the respective sets. This requires functions HEPINI and HEPCHN but it really is quite easy.

I do use the 4H ROM revision (HEP2) unfortunately the last version of the document that I found is 1G.
I will have to re-read the HePaX chapter of your PowerCL version 4N manual because I never grasp that is was possible.
The possibility of having multiple HRAM set was always there, in fact when you copy 4 CL templates (0x0B9) to build a 16K set, you have 4 unlinked 4K HRAM memory until you linked them.
As far as I know, the problem is that the HePaX ROM will only look for the first HRAM.

(08-24-2019 05:13 AM)Ángel Martin Wrote: Impressive indeed...

Wholeheartedly agree!

edit: typo

**rprosperi** · (This post was last modified: 08-24-2019 05:07 PM by rprosperi.)

(08-24-2019 05:13 AM)Ángel Martin Wrote:
(08-23-2019 11:09 PM)rprosperi Wrote: OK, thanks. I was aware of that in the NEWT (which has power and speed to spare), but did not think the HEPAX module had such sophisticated capabilities back in 1987. The more I learn about it, the more impressive it is.

There are other examples: The Advantage Pac and the IR printer module also act on "special" OpCopes to switch their banks .... so it was not only the HEPAX. Also the ZEPROMS implemented their own bank-switching scheme... so imagine: the NUT CPU is happily NOPing while all that wild bank switching happens ;-)

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?

Ángel Martin · 08-24-2019, 05:15 PM

(08-24-2019 03:51 PM)Sylvain Cote Wrote: I will have to re-read the HePaX chapter of your PowerCL version 4N manual because I never grasp that is was possible.
The possibility of having multiple HRAM set was always there, in fact when you copy 4 CL templates (0x0B9) to build a 16K set, you have 4 unlinked 4K HRAM memory until you linked them.
As far as I know, the problem is that the HePaX ROM will only look for the first HRAM.

using HEPCHN you can alter the default order of HRAM pages in the FileSys. It is possible to configure it to look at the second HRAM first, then the first (i.e. inverted sequence) or to ignore the first one altogether. I admit I haven't tested all combinations but theoretically you can have a HRAM configuration in any order you want, say "0FABC0" to put just one example/

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.