The Museum of HP Calculators

HP Forum Archive 18

[ Return to Index | Top of Index ]

Looking for William Doug Wilder
Message #1 Posted by Meindert Kuipers on 6 Mar 2008, 4:39 a.m.

See topic. He wrote a paper about the HP41 printer, titled "HP82143A preliminary study" which is available at TOS. Would like to have the sources of the printer VASM listing with labels and permission to use these in my HP41 disassembler.

      
Re: Looking for William Doug Wilder
Message #2 Posted by Meindert Kuipers on 6 Mar 2008, 4:40 a.m.,
in response to message #1 by Meindert Kuipers

And forgot to mention: I am also looking for a list of entry points of HP-IL and timer ROMs

Meindert

            
Re: Looking for William Doug Wilder
Message #3 Posted by Eric Smith on 6 Mar 2008, 4:57 a.m.,
in response to message #2 by Meindert Kuipers

I haven't seen any "list" of entry points for either. The HP-IL ROM has a few subroutines suitable for external use, but I don't recall seeing many in the Time ROM. They're both mainly intended to provide user-level functionality.

AFAIK, HP didn't release any VASM listings for the 82143A. Much of the code is similar to the printer portion of the HP-IL ROM.

Edited: 6 Mar 2008, 4:58 a.m.

            
Re: Looking for William Doug Wilder
Message #4 Posted by Doug on 7 Mar 2008, 3:53 a.m.,
in response to message #2 by Meindert Kuipers

Hi Meindert,

As Eric Smith said above, there isn't any list, other than what's available in the PPC Journals. What I did was to use the 82162A VASM from HP to snag the labels, then painstakingly decided where they should be for the 82143A disassembly. This was a matter of looking at the code sequences for similarities. All the labels are at different locations. Lots of hair pulling! A few labels are totally "made up".

As far as permission, you don't need any, that study is not copyrighted.

The lists published in PPC are for the 62A rev 2E, the HP-IL module, the Timer 1C chip, the basic 41C VASM, and XF rev C. Note: the 62A rev 2E rom differed from the 2D rom only in that CR and LF were swapped. These were the only VASMs released by HP although Warren says that an HP VASM does exist for the 43A, I have never seen it. All the disassembly notes in that preliminary study are from my own observation and a few from the 62A VASM (digit entry stuff).

I don't have a list of labels for the 43A, haven't gotten to this yet (if ever). Any volunteers?

BTW, there is yet another cpu bug, have you seen this one?

04E C=0
09C PT=5
2D0 LD B
170 PUSH
2A0 SETDEC
1B0 POP
0E8 WRIT X
3E0 RTN
Maybe this is common knowledge, haven't seen it published though. HP didn't know about it, evidenced by the code @ MSGA 1C6C. This makes a rule: "don't POP in decimal mode".

Doug

Edited: 7 Mar 2008, 4:15 a.m.

                  
Re: Looking for William Doug Wilder
Message #5 Posted by Meindert Kuipers on 7 Mar 2008, 6:50 a.m.,
in response to message #4 by Doug

Doug,

Thanks for responding. I had already extracted the listing from your paper and took the labels out to a seperate file. I assumed that this was a lot of handwork, so thanks for that. I think your paper is just as good as the VASM listings, and better readable!

I want to have labels for use with the HP41 disassembler that I have, so that any jumps are nicely represented with something that can be understood instead of an address. In some ROMs there are also jumps straight into the IL ROM, but with the VASM listings that should not be too difficult, since that are only a few locations. Also I have seen code that have jumps into the HP41 system ROMs to non-labeled locations. I would need to document these as well.

I did not know about the bug you showed, but maybe someone else knows if this is documented somewehere?

Meindert

                  
Re: Looking for William Doug Wilder
Message #6 Posted by HrastProgrammer on 7 Mar 2008, 8:57 a.m.,
in response to message #4 by Doug

HP didn't know about it, evidenced by the code @ MSGA 1C6C.

I doubt they didn't know about it. In my copy of HP-41 ROM VASM listing there are following comments for 1C6B MSG: "!!! DOESN'T WORK IN DEC MODE !!!!!!!" and "ASSUME: HEXMODE" ... But, it is a little strange that they put SETHEX after C=STK. It doesn't make sense. Maybe the first programmer (who wrote this subroutine) didn't know about the problem and the second one didn't want to change the code - he just put a comment. So, they were aware of this behavior.

BTW, what is in C[4:7] upon the execution of C=STK in your example (I cannot test it on the real HP-41C)? I assume this is some variation of "handling hexadecimal numbers in decimal mode" undocumented feature of the Nut CPU. HP used this feature to convert numbers from HEX to DEC inside HP-41 ROM. 05E8 GENNUM is a good example ...

Edited: 7 Mar 2008, 11:20 p.m.

                        
Re: Looking for William Doug Wilder
Message #7 Posted by Doug on 8 Mar 2008, 12:38 a.m.,
in response to message #6 by HrastProgrammer

"!!! DOESN'T WORK IN DEC MODE !!!!!!!"

Thanks, I hadn't seen that comment, the mf disassembly i still use is my own so i guess i should read the published material before making comments like that... There is very little that HP did not know.

The result of the routine is in C and X(6-3): 1B00

The NUT cpu POP increments MSD if next to MSD is in the range A-F iff in decimal mode. Not likely to bite unexpectedly, yet possible. I don't see how this can be called a "feature". This seems to be the only Class 0 instruction whose characteristics depend upon the state of the decimal flag.

I have a question: does the C=0 RAMSEL PRFSEL bug in halfnut have a name? This one bit me only seven years ago. Also, anyone know what this bug actually does? I'm too lazy to test it.

Best

Edited: 8 Mar 2008, 1:04 a.m.

                              
Re: Looking for William Doug Wilder
Message #8 Posted by HrastProgrammer on 8 Mar 2008, 3:09 a.m.,
in response to message #7 by Doug

This one is not a "feature", for sure. By "feature" I meant (undocumented, I think) handling of hexadecimal numbers in decimal mode used by HP to convert hex numbers to dec. For example, with #00B in C(X) the result of C=C+1 X is #012 and C=C-1 X then gives #011 ...

I thought maybe it has something to do with this feature, but obviously this is just a bug ...


[ Return to Index | Top of Index ]

Go back to the main exhibit hall