MCODE: Card_Reader 1G ROM
|
05-11-2019, 11:13 AM
(This post was last modified: 05-11-2019 11:15 AM by Ángel Martin.)
Post: #1
|
|||
|
|||
MCODE: Card_Reader 1G ROM
Recently I've been looking into the Card_Reader 1G ROM to learn more about the section dealing with the HP-67 code conversion.
This ROM is a piece of work, fully packed and stuffed with tons of interesting tricks. Looking at the ROM contents it becomes clear that the Card_Reader was a difficult peripheral to control. I guess the breakthrough was the original models on with the HP-65 and 67, but the 41 implementation is a real masterpiece. Anyway I was wondering if somebody had already disassembled the HP-67 code conversion part of the ROM, located at addresses E469 to E566 and E5A7 to E608. Those tables appear though to crack, I'd expect them to be some kind of mapping between HP-67 and HP-41 instruction codes but so far I haven't figured it out... Best, ÁM "To live or die by your own sword one must first learn to wield it aptly." |
|||
05-12-2019, 11:13 PM
Post: #2
|
|||
|
|||
RE: MCODE: Card_Reader 1G ROM
(05-11-2019 11:13 AM)Ángel Martin Wrote: Recently I've been looking into the Card_Reader 1G ROM to learn more about the section dealing with the HP-67 code conversion. I haven't looked at it in detail, but the fact that it's revision -1G implies that it was a challenge to get right. |
|||
05-13-2019, 07:22 AM
(This post was last modified: 05-13-2019 07:23 AM by Ángel Martin.)
Post: #3
|
|||
|
|||
RE: MCODE: Card_Reader 1G ROM
(05-12-2019 11:13 PM)Monte Dalrymple Wrote: I haven't looked at it in detail, but the fact that it's revision -1G implies that it was a challenge to get right. Yep, so I'm now looking for the "HP-67 Byte Table"- if such a thing ever existed? I seem to remember an article on PPC dealing with the HP-67 instruction codes, but again, it might be just a figment of my imagination... My guess is that there must be a look-up table mapping 67-instruction codes to 41-byte_table values. Time for another wading session... "To live or die by your own sword one must first learn to wield it aptly." |
|||
05-13-2019, 10:07 AM
Post: #4
|
|||
|
|||
RE: MCODE: Card_Reader 1G ROM
Here's one: http://www.panamatik.de/ProgramCodes.pdf
|
|||
05-13-2019, 04:44 PM
Post: #5
|
|||
|
|||
RE: MCODE: Card_Reader 1G ROM
(05-13-2019 07:22 AM)Ángel Martin Wrote: Yep, so I'm now looking for the "HP-67 Byte Table"- if such a thing ever existed? The initial HP-67 8-Bit Program Codes table appeared at the end of Louis Cargile's article, HP-67 Internal Codes and Quasi-Alphanumerics, from HP65 Notes Volume 4, Number 1, pages 5 - 8 (1977). Some of us remember Lou as the inventor of the HP-67 "Black Box", first described in 65 Notes V4N5 in his amazing article "Zen and the Art of HP-67 Maintenance", starting on page 4. Building that box was my very first soldering adventure :-) Jake |
|||
05-14-2019, 10:33 AM
Post: #6
|
|||
|
|||
RE: MCODE: Card_Reader 1G ROM
(05-13-2019 10:07 AM)Thomas Okken Wrote: Here's one: http://www.panamatik.de/ProgramCodes.pdf Perfect!, thanks very much Thomas. "To live or die by your own sword one must first learn to wield it aptly." |
|||
05-14-2019, 10:34 AM
Post: #7
|
|||
|
|||
RE: MCODE: Card_Reader 1G ROM
(05-13-2019 04:44 PM)Jake Schwartz Wrote: The initial HP-67 8-Bit Program Codes table appeared at the end of Louis Cargile's article, HP-67 Internal Codes and Quasi-Alphanumerics, from HP65 Notes Volume 4, Number 1, pages 5 - 8 (1977). Some of us remember Lou as the inventor of the HP-67 "Black Box", first described in 65 Notes V4N5 in his amazing article "Zen and the Art of HP-67 Maintenance", starting on page 4. Building that box was my very first soldering adventure :-) Yeah, those names do ring the bell...many thanks for the information, will follow up shortly. "To live or die by your own sword one must first learn to wield it aptly." |
|||
05-16-2019, 01:29 AM
Post: #8
|
|||
|
|||
RE: MCODE: Card_Reader 1G ROM
I can't believe its not GOT butter!
Is there really no commented source code for the Card Reader from HP ??? Angel, those spaces don't look like tables to me. To start with they only represent half the codes for the 67, also the codes that do fit are in higgledy-piggledy order - any responsible assembly table maker would have reduced the table order to 1,2,3,4... order. Next there doesn't seem to be any table addressing code in the whole of the card reader ROM, not even an offset address, by one or two bytes, i.e table 1 is at E469 so the search would be to look for an ld@ code having 9h as the last digit of a 4 digit address, but with an offset of a byte it would be 8h or if 16 bit offset it would be 7h, but none of these are apparent in the ROM. Its the same for the other table 2 at E5A7. Its like the 1G updated version has some left over code that is not cleaned up from the previous version. Just a few thoughts on the matter. DA |
|||
05-16-2019, 04:59 AM
(This post was last modified: 05-16-2019 05:03 AM by Ángel Martin.)
Post: #9
|
|||
|
|||
RE: MCODE: Card_Reader 1G ROM
(05-16-2019 01:29 AM)derekamos Wrote: I can't believe its not GOT butter! Hi Derek, thanks for chiming in. I'm half-way through the decoding of the tables, which I'm pretty sure there are active tables, even if decoding their logic requires more information than usually. (HP would not leave all that dead code there, it's MCODE heresy!) For starters the table is exactly 256 bytes long, which provides a pretty good hint of its contents. Obviously one needs to follow the order defined by the HP-67 "byte table". Thanks to Thomas (and Eberhard) this was revealed to be the proper sequence of the words on the table starting at E467 (not at E469 as I first thought - thanks to Mike for that pointer as well). As to the index or starting location, it's implicitly built in the call to the subroutine at E465: the call loads E467 in the return stack, from where it's picked up by the subroutine. The table offset (i.e. position to read) is expected to be in A.M on entry. The logic fetches the word, and depending on the value of the XS nibble it interprets the word as : a. if XS=0, a direct translation into an HP-41 byte code b. if XS=3, one of the XROM id#'s from the card reader itself c. if XS=1, the address of the location where the actual combination of instruction codes are to be found d. if XS=2 - not clear yet.... All this is of very limited use since the HP-67 code cannot be read by the HP-41 directly unless thru the utilization of the card reader obviously - and separating it into an independent function doesn't seem to be very useful; it's just the challenge of course. To be continued, this is just the beginning. See below the gory details ;-) Code: E467 084 STOP "To live or die by your own sword one must first learn to wield it aptly." |
|||
05-16-2019, 11:56 AM
Post: #10
|
|||
|
|||
RE: MCODE: Card_Reader 1G ROM
Thats OK Angel, I figured you might like the assembly-code insights, & you were red-hot with spying out the 2-byte offset to the table address. Even if its not in line-code that is readily readable.
The table looks like an ugly SOB, not something I would want to decode! That brings me to the 2nd table, it doesn't seem have an E5A7 or an offset-E5A5 address in the ROM, that I could see? I'll just wish you good luck with that one. DA |
|||
08-02-2019, 05:05 AM
(This post was last modified: 08-02-2019 11:17 AM by Gene.)
Post: #11
|
|||
|
|||
RE: MCODE: Card_Reader 1G ROM
(05-16-2019 04:59 AM)Ángel Martin Wrote: ... it's just the challenge of course.So here is a "quick writeup" of what I've been working on with the commenting the card reader mcode - diverting my attention to the 67 translation table rabbit hole. Starting partway through the process of translation. Assume the 67 program is already read in, and now we need to translate it a byte at a time (according to the card reader manual, this is how it works), starting from the end of the program and moving to the beginning. I love how the 41C engineers played with addresses, having one translation table at address 0xE467 (get it? For 67?) and the main translation code starts at 0xE567 ... another 67 address. And this is some intricate code using highly coupled code, data, and addresses. Note: Names of the tables, translations, and code labels are all mine (and may change in the future). Overview -------------------- There are two translation tables and 5 different kinds of translation. The two translation tables: TABLE 1 at 0xE467 contains single word translation codes (TC) that are used to specify how to translate a 67 byte code (67BC) into one or more 41 byte codes (41BC). TABLE 1 is indexed by the 67 byte code. TABLE 2 at 0xE5A7 is used to translate one 67BC into one or more 41BC that may require some processing of the codes found within. It is index by mcode that takes the TC from Table 1 (values 0x100-0x3FF) and turns it into an address into TABLE 2. There are 5 different kinds of translation used (my naming): SINGLE: This is a direct, one to one translation of a single 67 byte code into a single 41 byte code. This uses only TABLE 1. Let look at the LOG function as an example (67BC = 0x27, 41BC=056). Using the 67BC as an index into the table (0xE467+0x27=0xE48E), we get the TC value of 0x56. The translation MCODE sees that the value is between 0x000 and 0x0FF, so it knows it is a SINGLE translation (actually knows not to do a "multi" translation). XROM: This is a one to 2-byte translation that takes a 67BC and translates it into an XROM call to a card reader function. The card reader is XROM ID 30, which gives 0xA780 - 0xA7A4 as XROM codes for its 36 functions. For TC values that are > 0x380, the code interprets the TC as specifying an XROM code. It does a "magical calculation" (see below) that extracts the last byte (0x080) and outputs that and an 0xA7. EXEC: This is special translation that uses the TC to generate (same "magical calculation") an address in the card reader rom and then jumps to that address (using a GOTOC). This EXEC translation is used twice. The first is for translating the 67BC for CHS, which requires special code because the 41 actually has two byte codes for this: CHS as a unary operator, and NEG for data entry (and exponent). The second time is for the 67BC GTO 0 thru GTO E, and here the code just translates from a 67BC 0xD0-0xDE to a 41BC 0xB1-0xBF, and then outputs a 0x00 (for the jump count). MULTI-A, MULTI-B: These are a one to many translation that uses the TC to generate (same "magical calculation") an address into TABLE 2 where a list of one or more words is found. MULTI-A alters the first word in the list, and then acts like MULTI-B. The list can be thought of as 41BCs that are output one at a time, until the 41BC has a value greater than 0x0FF (has a non-zero value in the high 2 bits). These MULTI translations are used for three purposes. (1)for single 41 bytes that require "extra stuff" from the 67 version. For example, the statistic functions (S+, S- MEAN, SDEV) all translate to three bytes on the 41, because they have a SREG 14 prepended (to ensure the sigma registers are at the 67 equivilent location). Also, the 67 LBL A-Ea-e include not only a 41C LBL A-Ea-e, but also a numeric LBL 10-19. (2) for multi-byte 41BCs, such as STO, RCL, SF, CF, XEQ, LBL etc. where the single 67BC must translate into 2 (or more) 41BCs. (Also the special nature of 67 flag 3 - similar to 41 flag 22 - is handled here). (3) there is one case where an XROM is handled this way - the DSP0-9 translating to XROM 7DSP0-9. THE MCODE -------------------- We start around 0xE465. We have a 67BC in A:M (mantissa field of CPU A reg), and we do a GOSUB 0xE567 (TRANS67) to translate it. 0xE567 is going to get the TC from the table (CXISA), and then test the TC for greater than 0x0FF (is this not a SINGLE). If it is not a SINGLE, it calls 0xE609 (TROTHER) ... see below. Then (either a SINGLE, or the last translation of a XROM/EXEC/MULTI-A/MULTI-B), it calls 0xE637 (TROUTONE) to output one 41BC. Then it checks if we are at the beginning of the 67 program (remember, we are going from end to beginning). If not, we loop and do the next byte. If at the end, we output a LBL 67 as the first instruction in the 41 code. (Note that before we started - at 0xE458 - we output a GTO 67 as the last instruction). The code at 0xE609 (TROTHER) handles all the non-SINGLE translations. All of these start out with the "magical calculation" that takes a TC, and turns it into an address. So a TC of 0xpqr, turns into either 0xE5qr or 0xE6qr. This address is used for XROM ... the qr becomes A7qr. For EXEC, the address is 0xE6qr. For MULTI-A or MULTI-B, the address is into Table 2 and is 0xE5qr or 0xE6qr. At the end of this calculation, we then repeatedly test and branch ... first testing the TC >= 0x380 (for XROM), then for >= 0x25F (EXEC), then >= 0x1C4 (MULTI-B) or else MULTI-A. And MULTI-A alters the first TC2, and then falls into MULTI-B. For all of these, if they generate n 41BCs, then they will output n-1 of them, and then return with the last one in C:X, which will be output by the caller as a SINGLE. That's the "simple" overview. For more details, feel free to look at my code (source and listing files attached below). Please remember that this source is a work in progress ... I'm a long way from my goal which is commenting the entire 4K card reader rom. Feel free to comment or send suggestions. Table 1 -------------- Code:
Table 2 (-- Edited by GW to Table 2 from Table 1 heading) -------------- Code:
Enjoy! crdlst.txt (Size: 299.22 KB / Downloads: 8) crdsrc.txt (Size: 152.25 KB / Downloads: 8) |
|||
08-02-2019, 07:49 AM
Post: #12
|
|||
|
|||
RE: MCODE: Card_Reader 1G ROM
Great job Robert! many thanks for the detailed descriptions; time to delve in again but I think you pretty much covered all bases.
ÁM "To live or die by your own sword one must first learn to wield it aptly." |
|||
08-03-2019, 03:07 AM
Post: #13
|
|||
|
|||
RE: MCODE: Card_Reader 1G ROM
Fantastic!
LB_E781 is RSTKCA, 'rebuild the key reassignment bit maps' which also appears in the extended functions module. |
|||
08-04-2019, 04:56 PM
Post: #14
|
|||
|
|||
RE: MCODE: Card_Reader 1G ROM | |||
08-04-2019, 09:13 PM
Post: #15
|
|||
|
|||
RE: MCODE: Card_Reader 1G ROM
Can this go to Github (or similar site)? I am thinking that it would be good to have it one official location.
|
|||
08-04-2019, 10:16 PM
Post: #16
|
|||
|
|||
RE: MCODE: Card_Reader 1G ROM
Suggest this be kept in the fan community; no need for excessive exposure, poking the bear.
I'd say TOS is the most logical and appropriate place to post it - that's probably where most folks would go looking for it as well. --Bob Prosperi |
|||
08-05-2019, 04:38 AM
(This post was last modified: 08-05-2019 04:39 AM by Ángel Martin.)
Post: #17
|
|||
|
|||
RE: MCODE: Card_Reader 1G ROM
(08-04-2019 10:16 PM)rprosperi Wrote: Suggest this be kept in the fan community; no need for excessive exposure, poking the bear. Definitely it should also be in the articles section, where it won't be buried by all the forum activity. ÁM "To live or die by your own sword one must first learn to wield it aptly." |
|||
08-05-2019, 01:06 PM
Post: #18
|
|||
|
|||
RE: MCODE: Card_Reader 1G ROM
(08-05-2019 04:38 AM)Ángel Martin Wrote:(08-04-2019 10:16 PM)rprosperi Wrote: Suggest this be kept in the fan community; no need for excessive exposure, poking the bear. Yes, both places are best as Angel points out; submit it to Warren and ask to have it added to the Library at TOS, but also add it in the Articles Forum here at MoHPC. --Bob Prosperi |
|||
08-05-2019, 09:14 PM
Post: #19
|
|||
|
|||
RE: MCODE: Card_Reader 1G ROM
(08-05-2019 01:06 PM)rprosperi Wrote: Yes, both places are best as Angel points out; submit it to Warren and ask to have it added to the Library at TOS, but also add it in the Articles Forum here at MoHPC. Happy to take a second swing at the "quick overview" and submit it to the articles here ... maybe as a pdf, and even to TOS. Were you guys (thinking of me submitting the src/lst files as well? Even though they are very incomplete? |
|||
08-06-2019, 02:48 AM
Post: #20
|
|||
|
|||
RE: MCODE: Card_Reader 1G ROM
(08-05-2019 09:14 PM)RobertM Wrote: Happy to take a second swing at the "quick overview" and submit it to the articles here ... maybe as a pdf, and even to TOS. I'd say that if you're planning to work on it further, best to wait until you complete it, or get as far as you think you can, and then post it to both places; there's likely no urgent demand, just nice to have it in the places future fans are likely to look. If it will be some time before completion, you might submit it now to TOS, the files (docs and src/lst files) can be easily updated with new versions when available. Articles here are more difficult to update, but you could always post an article now and later post another one, referencing the original. --Bob Prosperi |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 4 Guest(s)