The Museum of HP Calculators

HP Articles Forum

[Return to the Index ]
[ Previous | Next ]


HP-42S: New Facts

Posted by J-F Garnier (France) on 10 Apr 2002, 4:32 p.m.

Contents:
Introduction
1. ROM dump
2. Hardware
2.1 Display
2.2 Announciators
2.3 I/O registers
2.4 Clock
2.5 Keyboard
3. Software
3.1 System RPL internals
3.2 User code entry tables
3.3 The hidden XFCN keyword
3.4 The COMP bug

Introduction

Few information is available on the hardware and software design of the HP-42S. Most useful documents are:

Please refer to these documents if needed.

In the process of developing an emulator of the HP-42S, I discovered new facts that can be also useful to expand the HP-42S. Actually, I have a very basic running emulator version (text mode DOS) that I only use to study the HP-42S internals (it is NOT suitable for publication, don't ask me, sorry!).

1. ROM dump

In order to study the HP-42S internals, or to even think about an emulator, the first thing to do is to get a ROM image. Fortunately, there is a way to do it thanks to the internal memory browser. You will need: a HP-42S (!), a HP48 (with the INPRT program from HP) and a PC.

Here is the procedure:

2. Hardware

By partially disassembling and tracing the code, I managed to find out some important hardware ressources.

2.1 Display

The display is made of 131 columns numbered from 0 to 130.
Each column is made of 4 consecutive nibbles (16 pixels).
The 4 consecutive nibbles drive pixels from top to bottom.
Each nibble is a column of 4 pixels. LSB=top pixel, MSB=bottom pixel
The display is organized in two interleaved areas:

40000 : column0
40004 : column66
40008 : column1
4000c : column67
40010 : column3
...
401f8 : column63
401fc : column129
40200 : column64
40204 : column130
40208 : column65

2.2 Announciators

Each announciator is controlled by one 5-nibble word.
Valid values seem to be either 00000 (off) or FFFFF (on)
One word at 40210 seems to control all announciators globally. Should be 00000.

40210       : ^v  --^  print  ((.))  batt  G  RAD
40218       : ^v
40220       : --^
40228       : print
40230       : ((.))
40238       : batt
40240       : G
40248       : RAD

2.3 I/O registers

The 40300-4030f area is used for I/O registers. The usage of these locations is not completely clear for me. Note that the organization of this area is close to the HP-28S. Note also that a 4-nibble hardware CRC calculator is included.

00: speed
01: contrast
02
03: display?
04-07: CRC
08: battery
09
0a
0b
0c: irin??
0d: irout?
0e: beep?
0f

2.4 Clock

The clock is at 403f8-403ff: 8 nibbles.
The clock counts down at 8192 ticks per second.
Address at 403F7 is also related to the clock, and could be a status/control register?

2.5 Keyboard

The keyboard handler uses a circular 16 bytes buffer at 50086-500a5. The two nibbles at 50084 and 50085 hold the head and tail pointers. The one-byte codes stored in the buffer are simply the natural order of the keys from left to right and from top to bottom (just like the GETKEY command): 1 for 'Sigma+', 2 for '1/x', and so on until 37 for '+' (the Enter key counts for one key only). Shifted key codes are stored by adding 37 to the corresponding unshifted key code: from 38 for 'Sigma-' to 74 for 'CATALOG'.

3. Software

The HP-42S internal software is based on RPL, but system RPL is not accessible to the user (as far as I know). 3 software versions are known: A, B and C. The following applies only to the C version.

3.1 System RPL internals

The internal RPL uses a subset of objects used in the HP-28C/S: binary integer, real, extended real, complex, extended complex, character, program, code, global variable, local variable:

=DOBINT       EQU #02911 
=DOREAL       EQU #02933 
=DOEREAL      EQU #02955 
=DOCMP        EQU #02977
=DOECMP       EQU #0299D 
=DOCHAR       EQU #029BF 
=DOCOL        EQU #02B3E
=DOCODE       EQU #02B6D
=DOIDNT       EQU #02BCB
=DOLAM        EQU #02C6E

I found some system RPL entries similar to the HP-28C/S, like:

=DUP          EQU #1B729
=2DUP         EQU #1B74D
=SWAP         EQU #1B76D
=DROP         EQU #1B782
=2DROP        EQU #1B796
=ROT          EQU #1B7A4
=OVER         EQU #1B7D1
=PICK         EQU #1B7E8

There is for sure a lot of other entries similar to the 28C/S.

3.2 User code entry tables

I managed to find the user code entry tables. My goal was to study the strange XFCN function, and also explain the well-known COMP bug.

There are 3 tables:

In each of these tables, entries can be either RPL or machine code (assembly). The 2 kinds of entry are recognized with the address MSB: if set, the entry is RPL, if not it is assembly.

3.3 The hidden XFCN keyword

The XFCN is a hidden function (it is not in CATALOG) that asks for a ALPHA argument.
The XFCN has been a mystery for me for years. I tried many times to figure what it could be used for. And I always got the same message "Nonexistent"...
So as soon as I discovered the op tables, I disassembled the XFCN code. I cannot resist to give you the result:

128EB 1F00002            D1=(5) #20000
128F2 143                A=DAT1 A
128F5 34F3CA5            LC(5)  #5AC3F
128FC 8A690              ?C<>A  A / GOYES #12908
12901 8F50002            GOSBVL #20005
12908 8C8FA3             GOLONG #16402
If there is a ROM at address 20000, and if the first 5-nibble word is 5ac3f, then the XFCN code jumps to 20005. Otherwise, it returns an error. Easy, isn't it? (5ac3f is also the value of the test word at RAM location 5001a)
I never opened a HP-42S, but from was I read in some posts, I think that there is a place for a second ROM. It's true for the HP17BII which have the same hardware, and it is how HP managed the two HP17BII versions (english and international with multiple languages): one common ROM and a second optionnal ROM.
So XFCN is a hook to access an optionnal second ROM, the old mystery is over now ...

3.4 The COMP bug

In some versions, the COMP function is not working properly: if arguments are not valid (for example if the arguments are in the wrong order), then the error status is latched and COMP function always returns an error even with good arguments. Error status can be easily reset by an arithmetic operation (+, -, ...).
It has been suspected that it was related to an interaction between software and hardware. I confirm this hypothesis and can give some details. I own A and C versions. On my real machines, bug occurs with version C, but not with version A. In my emulator, the bug occurs with both versions! I found that it is related to the XM hardware status flag that is used as an error flag in COMP code, but XM is not reset when entering into COMP, nor in the main loop, nor by a machine reset! (Fortunately, it is clear by arithmetic functions...). With my real A version machine, the XM flag seems to be reset at some place, but I was unable to reproduce it in my emulator.

That's all for today.

Jean-Francois Garnier (France)
jfgarnier@wanadoo.fr

Password:

[ Return to the Message Index ]

Go back to the main exhibit hall