HP Forum Archive 09

[ Return to Index | Top of Index ]

August 1979 PPC Calculator Journal Message #1 Posted by Jeff on 8 Jan 2003, 6:30 p.m. I am looking for the following information from the August 1979 PPC Calculator Journal. Detailed Byte structure to construct compiled GTO's and XEQ's. Is there some place where I can download this document? Jeff

Re: August 1979 PPC Calculator Journal Message #2 Posted by Ernie Malaga on 9 Jan 2003, 12:32 a.m., in response to message #1 by Jeff Jeff: You owe it to yourself to buy the PPC CDs. Among other things, they contain the _entire_ collection of PPC journals in PDF format. Now to answer your question, here's an excerpt from V6N5P21: - - - - - Three byte local GTO's and local executes contain one byte from the Postfix Table which specifies the label of interest. The remaining bits are used to remember the address of the label once it has been found by a LBL search. This technique allows improved execution speed since the slow label search process is only done once. On all subsequent executions of the GTO or XEQ function the location of the label is known and no search is needed. A three byte GTO 22 instruction has the following form immediately after it has been keyed into progam memory: Function Byte 1 Byte 2 Byte 3 GTO 22 D0 00 16 If LBL 22 was the third byteof a register, 30 registers away from the GTO 22 instruction, the GTO 22 would have the following form after being executed: Function Byte 1 Byte 2 Byte 3 GTO 22 D6 16 16 If the three bytes are put end to end, the entire instruction may be viewed as: [Diagram comes here.] Thus the first four bits give the type of instruction (GTO), the next three bits give the location of the LBL within the register where it is stored, the next nine bits give the distance from the GTO to that register, the next bit tells whether the register is before or after the GTO and the last seven bits retain the name of the LBL. The name of the LBL must be retained in case program modifications invalidate the address retained in the first two bytes. Any addition or deletion of program steps sets all address bits in all GTO's and XEQ's to zero. The local XEQ function is analogous except that the first four bits are hexadecimal E instead of D. - - - - - I hope I didn't make any mistakes while retyping that! X<>Y -Ernie (6594)

Re: August 1979 PPC Calculator Journal Message #3 Posted by Vieira, Luiz C. (Brazil) on 9 Jan 2003, 1:26 a.m., in response to message #2 by Ernie Malaga Hi, Ernie; my questions go a bit beyond. If someone is building a program for the HP41 and want to record it in a custom ROM module, does the final program keep orginal byte-equivalence with the same program in RAM? As the ALPHA global labels need specific definition, what's the structure needed to record "XROM" labels? How to make them "visible" for the O.S.? Is this sort of information easy to find?

Re: August 1979 PPC Calculator Journal Message #4 Posted by Ernie Malaga on 9 Jan 2003, 9:32 a.m., in response to message #3 by Vieira, Luiz C. (Brazil) >If someone is building a program for the HP41 and want to record it in a custom ROM module, does the final program keep orginal byte-equivalence with the same program in RAM? Yes. Byte counts remain the same. That's the reason why HP decided to record distances between GTO and LBL, not absolute addresses. >As the ALPHA global labels need specific definition, what's the structure needed to record "XROM" labels? How to make them "visible" for the O.S.? Alpha labels are always searched, as far as I remember, beginning with the .END. and going _upwards_ (i.e., the opposite direction of search for compiled GTOs). Alpha labels in ROM become "visible" automatically when the module is plugged in and the calculator is powered up. At this time, also, all XROM mm,nn instructions reveal their true identity, such as PRPLOTP or 7P<>S. -Ernie

Re: August 1979 PPC Calculator Journal Message #5 Posted by Vieira, Luiz C. (Brazil) on 9 Jan 2003, 9:42 a.m., in response to message #4 by Ernie Malaga Hi, Ernie; You wrote: > At this time, also, all XROM mm,nn instructions reveal their true identity, such as PRPLOTP or 7P<>S. That's still intriguing: how does the system connect an XROM mm,nn to a LBL'name inside the module? I know it's the same "procedure" taken when "connecting" an XROM mm,nn to a function name built into a ROM module. For that, the ROM must keep a refernce table, with the function name as an ASCII sequance and it's XROM reference, right? That's why I asked about the ROM structure for a program. If it's the same as the RAM structure, the ROM program would be recognized as a user program, not a ROM program. I thought all ALPHA global names in programs contained in ROM modules were different, with a different code, so they could be "seen" by the O.S. as an XROM call instead of a LBL call. Am I reasoning correctly? What did I miss? Thank you for your answer.

Re: August 1979 PPC Calculator Journal Message #6 Posted by Meindert Kuipers on 9 Jan 2003, 11:35 a.m., in response to message #5 by Vieira, Luiz C. (Brazil) XROM mm,nn instructions refer to the FAT at the beginning of a ROM Module. If I am correct one bit in the FAT indicates if it is a user program or Mcode (I do not have all the docs at hand). The FAT is actually a collection of pointers to ROM locations, which can be a label in a user program, where the name is read from. Multiple Alpha labels in a signle user program can exist in the FAT (the PPC ROM uses this frequently. I am not certain if an Alpha label can be used inside an ROM that does not appear in the FAT. Actually, if you do a CAT 2, the machine runs through all FATs and find the string for it. There is no cross reference table in a ROM. If you type an XEQ "ROM LABEL NAME" all ROMS are searched for this label using the FAT and will be decoded to an XROM mm,nn. If you have the XROM number, the '41 only has to look at the XROM number (the first entry in a ROM) and the entry in the FAT, and obviously that is much faster. Bottom line is that a user program in ROM is almost exactly the same as in RAM, but the trick is building the right FAT. It is the HP41 operating system that treats FAT entries for Mcode and User code totally different. Hope this helps for you. Meindert

[ Return to Index | Top of Index ]

Go back to the main exhibit hall