New 42S owner seeking info
Gary Stringham
quit and I figured that was a good excuse to upgrade.) As such, I would
like to know what there is to know about the little machine. I have
been watching this notes group for a couple of months now without having
seen much traffic so I doubt anybody has very much. But I would
appreciate people posting or emailing what they have saved or posted
about the 42S. I am looking for anything on
- Synthetic programming.
- Backdoor, undocumented, unsupported stuff.
- Your fancy program.
- Other comments.
I have a few ideas of programs that I want to do after I finish reading
the manual. If I think it's anything useful, I post it.
Gary "Long live the 42S! (Somebody has to be for the little guys)" Stringham
Gary Stringham
Gary Stringham
ga...@hpbbn.bbn.hp.com
Joseph K. Horn
HP-42S works.
The following is quoted verbatim from HPX Exchange, V1 N6
(August/December 1988):
MATRIX SEARCH
-------------
To search for a particular value in a matrix and find out its location,
you can use the [FIND] function.
1. Index the matrix to be searched: INDEX (name).
2. Place the value to be searched for in the X register.
3. Execute [FIND].
4. If performed from the keyboard, Yes indicates that the number was
found, and No indicates that it was not found.
5. If performed in a program, the do-if-true rule is followed (see page
149); that is, if the value is not found, then the next program line
is skipped.
6. If the value is found, then pointers IJ are set to its location, and
the search immediately ends. If the value is not found, IJ are not
affected.
Copyright (C) 1988, Joseph K. Horn
----------
Disregard the copyright; I don't have a 42S any more.
Hope this helps. -jkh-
Nick Reid
>Rick Homard asks if anybody has figured out how the [FIND] command on the
>
>
>----------
>
>Disregard the copyright; I don't have a 42S any more.
>
Of course you do. It's just that battery is a bit a bit low and the
light is not striking it at the right angle.
Joseph K. Horn
> There is no equivalent of "synthetic programming" in the 41 in the
> 42S. The 42S operates in a different way on a different processor.
Au contraire! There is a program in the Owner's Manual that displays
the HP logo graphically. It's rather large, and runs in fits and
starts. It can be written using synthetic text strings to display the
graphic in only two passes, and it shrinks (if I remember correctly) by
a factor of 10.
What I always did was put the number 111111111111 in the program
immediately before the place I wanted to do some synthetic poking, and
then use the hex memory editor (sometimes called the "debugger") to scan
through memory until the easily-seen 1's scroll by. That gets you
there; the hex table is then all you need to poke synthetics into
memory.
You are correct if you mean that the HP42S does not allow you to create
new functions synthetically that do powerful and otherwise impossible
things, like the HP41 could do. Unfortunately, the HP42S checks the
arguments of all functions, even synthetically created ones in program
memory, and politely errors out when it encounters synthetic jollities
like CLV 01 and TONE 99. Bummer, huh? But you can use synthetics to
create text and variable names containing any desired bytes. You can
also put all the non-programmable functions into a program (even CLALL,
which works!). Any other uses of synthetics eluded me.
> Fr Joseph Horn has published a 42S hex table with entry points, and
> may post it here if he is asked nicely. My copy of it is dated 13 Nov
> 1988.
Well, not entry points per se; I have no idea where the functions begin
in the operating system. What I do have (and what Nick has) is the hex
table for HP42S programs in program memory. For example, INPUT 01 is
F2D001. The table is fun to make; just fill a program with junk (like a
bunch of ENTERs) and then go into the debugger, poke values into it,
exit the debugger, and look at what it changed your program to.
If you haven't the patience or desire to go spelunking, here's something
to keep in mind: the HP42S hex table is IDENTICAL to the HP41 hex table.
Even most of the XROMs are the same! (E.g. XTOA is A66F in both
machines!) The functions which were newly introduced in the HP42S are
either new XROM numbers (e.g. DIM? which is A6E7), or special text
codes (e.g. STO IND "D" is F28144, with F2 meaning "two-byte text", 81
meaning "special text command: STO IND name", and 44 meaning "D").
The HP41 hex code was published in many places. The remaining special
HP42S hex codes were published in HPX Exchange, V1 N6 (December 1988),
page 13. If you would like, I can retype it and post it here.
Forgive any vagueness; it's been three years since I even looked at any
of this stuff. I gave my 42S to my brother, Jim "Roo-man" Horn, as a
token of thanks for the gift of his legendary HP75C. Is anybody going
to do VisiCALC for the HP48???
> Sometimes more immediate output would be helpful.
Using synthetics and Turbo Mode, all of my programs ran real quick!
All two of them.
-Joe Horn-
Nick Reid
>Nick Reid writes:
>
>> There is no equivalent of "synthetic programming" in the 41 in the
>> 42S. The 42S operates in a different way on a different processor.
>
>Au contraire! There is a program in the Owner's Manual that displays
>the HP logo graphically. It's rather large, and runs in fits and
>You are correct if you mean that the HP42S does not allow you to create
>new functions synthetically that do powerful and otherwise impossible
>things, like the HP41 could do. Unfortunately, the HP42S checks the
That's what I mean....
>arguments of all functions, even synthetically created ones in program
>memory, and politely errors out when it encounters synthetic jollities
>like CLV 01 and TONE 99. Bummer, huh? But you can use synthetics to
>create text and variable names containing any desired bytes. You can
>also put all the non-programmable functions into a program (even CLALL,
>which works!). Any other uses of synthetics eluded me.
....and that's what I call just poking into RAM.
>> Fr Joseph Horn has published a 42S hex table with entry points, and
>> may post it here if he is asked nicely. My copy of it is dated 13 Nov
>Well, not entry points per se; I have no idea where the functions begin
>in the operating system. What I do have (and what Nick has) is the hex
>table for HP42S programs in program memory. For example, INPUT 01 is
Right - sorry: I remembered the distinctive date, but not the exact content
of your table. Jeremy and I were poking around in the 42S at that time and
sent some entry points off to Brian for HPX, as I recall (or maybe I just
posted them to the FidoNet HPHH echo) and I noted some more in the next
month or two (using, I'm sure, your hex table to help in some way) but it
is now so long ago and I lost interest in the machine because of its display
so don't remember a lot about it (and I never keep notes of anything #|)
>> Sometimes more immediate output would be helpful.
>
>Using synthetics and Turbo Mode, all of my programs ran real quick!
>All two of them.
It's not the speed of the machine that I was referring to, it's the
difficulty of seeing the display - for me that turned an excellent
device into just something that's occasionally useful as a lightweight
make-do calc when I don't have space in my luggage for a more visible one.
Rick Homard
>
>What I always did was put the number 111111111111 in the program
>immediately before the place I wanted to do some synthetic poking, and
>then use the hex memory editor (sometimes called the "debugger") to scan
>through memory until the easily-seen 1's scroll by. That gets you
>there; the hex table is then all you need to poke synthetics into
>memory.
>
in memory to look. You gave the example of placing 1's in
a program then scan through memory via the hex editor.
The hex editor scans 1M of addresses. Where do you start
looking? (ie: where does the user memory begin-end)
>Well, not entry points per se; I have no idea where the functions begin
>in the operating system. What I do have (and what Nick has) is the hex
>table for HP42S programs in program memory. For example, INPUT 01 is
>F2D001. The table is fun to make; just fill a program with junk (like a
>bunch of ENTERs) and then go into the debugger, poke values into it,
>exit the debugger, and look at what it changed your program to.
>
Ditto the above question.
>If you haven't the patience or desire to go spelunking, here's something
>to keep in mind: the HP42S hex table is IDENTICAL to the HP41 hex table.
>Even most of the XROMs are the same! (E.g. XTOA is A66F in both
>machines!) The functions which were newly introduced in the HP42S are
>either new XROM numbers (e.g. DIM? which is A6E7), or special text
>codes (e.g. STO IND "D" is F28144, with F2 meaning "two-byte text", 81
>meaning "special text command: STO IND name", and 44 meaning "D").
>
>The HP41 hex code was published in many places. The remaining special
>HP42S hex codes were published in HPX Exchange, V1 N6 (December 1988),
>page 13. If you would like, I can retype it and post it here.
What is (was?) the HPX Exchange? Are back copies available?
Could (and would) you direct me to a source for the HP41 hex code.
And yes would you please post the information regarding the
remaining hp42S hex codes.
Also, does a good source still exist to help beginners (like
myself) in "synthetic" programming. It appears that the
techniques involved in synthetically programming the hp41 can
also be applied to the hp42s.
Also what is the "Turbo Mode"?
Any help would be appreciated.
rick homard
b64...@utarlg.uta.edu
Joseph K. Horn
one can use the hex memory editor to poke around in a program.
The magic address is 503DA. Memorize it! The five nibs between 503DA
and 503DE are a pointer that tell where the last program in memory (the
one that ends with .END.) begins. The next five nibs, from 503DF thru
503E3 are a pointer to the .END.
So first jump to 503DA, look at the pointer, and then jump there, and
then it's easy to scan for the 111111111111 "marker" that you put in your
program.
The hex table and any other ancient goodies I can dredge up from the past
will be posted tomorrow (+/- 3dB).
-jkh-
Joseph K. Horn
| HP-42S Hex Table |
| -Joseph K. Horn- |
+------------------+
[Same as the HP-41 hex table, plus the following]
XROM 01
--------------
A0 61 SINH
A0 62 COSH
A0 63 TANH
A0 64 ASINH
A0 65 ATANH
A0 66 ACOSH
A0 6F COMB
A0 70 PERM
A0 71 RAN
A0 72 COMPLEX
A0 73 SEED
A0 74 GAMMA
XROM 02
--------------
A0 9F BEST
A0 A0 EXPF
A0 A1 LINF
A0 A2 LOGF
A0 A3 PWRF
A0 A4 SLOPE
A0 A5 SUM
A0 A6 YINT
A0 A7 CORR
A0 A8 FCSTX
A0 A9 FCSTY
A0 AA INSR
A0 AB DELR
A0 AC WMEAN
A0 AD LINsigma
A0 AE ALLsigma
XROM 03
--------------
A0 E2 HEXM
A0 E3 DECM
A0 E4 OCTM
A0 E5 BINM
A0 E6 BASE+
A0 E7 BASE-
A0 E8 BASEx
A0 E9 BASE/
A0 EA BASE+/-
XROM 09
--------------
A2 59 POLAR
A2 5A RECT
A2 5B RDX.
A2 5C RDX,
A2 5D ALL
A2 5E MENU
A2 5F X>=0?
A2 60 X>=Y?
A2 61 (CLALL)
A2 62 CLKEYS
A2 63 KEYASN
A2 64 LCLBL
A2 65 REAL?
A2 66 MAT?
A2 67 CPX?
A2 68 STR?
A2 69 (QUIET)
A2 6A CPXRES
A2 6B REALRES
A2 6C EXITALL
A2 6D CLMENU
A2 6E GETKEY
A2 6F CUSTOM
A2 70 ON
XROM 22
--------------
A5 87 NOT
A5 88 AND
A5 89 OR
A5 8A XOR
A5 8B ROTXY
A5 8C BIT?
XROM 24
--------------
A6 31 AIP
XROM 25
--------------
A6 41 ALENG
A6 46 AROT
A6 47 ATOX
A6 5C POSA
A6 6F XTOA
A6 78 sigmaREG?
XROM 27
--------------
A6 C9 TRANS
A6 CA CROSS
A6 CB DOT
A6 CC DET
A6 CD UVEC
A6 CE INVRT
A6 CF FNRM
A6 D0 RSUM
A6 D1 R<>R
A6 D2 I+
A6 D3 I-
A6 D4 J+
A6 D5 J-
A6 D6 STOEL
A6 D7 RCLEL
A6 D8 STOIJ
A6 D9 RCLIJ
A6 DA NEWMAT
A6 DB OLD
A6 DC {left}
A6 DD {right}
A6 DE {up}
A6 DF {down}
A6 E0 (GOTO)
A6 E1 EDIT
A6 E2 WRAP
A6 E3 GROW
A6 E4 (MATA)
A6 E5 (MATB)
A6 E6 (MATX)
A6 E7 DIM?
A6 E8 GETM
A6 E9 PUTM
A6 EA [MIN]
A6 EB [MAX]
A6 EC [FIND]
A6 ED RNRM
XROM 29
--------------
A7 47 (LIST)
A7 48 PRA
A7 4D (PRP)
A7 52 PRsigma
A7 53 PRSTK
A7 54 PRX
A7 5B MAN
A7 5C NORM
A7 5D TRACE
A7 5E PRON
A7 5F PROFF
A7 60 DELAY
A7 61 PRUSR
A7 62 PRLCD
A7 63 CLLCD
A7 64 AGRAPH
A7 65 PIXEL
SPECIAL TEXT BYTES
------------------
Fn 80 VIEW nameFn 88 VIEW IND name
Fn 81 STO nameFn 89 STO IND name
Fn 82 STO+ nameFn 8A STO+ IND name
Fn 83 STO- nameFn 8B STO- IND name
Fn 84 STOx nameFn 8C STOx IND name
Fn 85 STO/ nameFn 8D STO/ IND name
Fn 86 X<> nameFn 8E X<> IND name
Fn 87 INDEX nameFn 8F INDEX IND name
Fn 90 MVAR nameFn 98 MVAR IND name
Fn 91 RCL nameFn 99 RCL INDname
Fn 92 RCL+ nameFn 9A RCL+ IND name
Fn 93 RCL- nameFn 9B RCL- IND name
Fn 94 RCLx nameFn 9C RCLx IND name
Fn 95 RCL/ nameFn 9D RCL/ IND name
Fn 96 ISG nameFn 9E ISG INDname
Fn 97 DSE nameFn 9F DSE INDname
Fn A0 --Fn A8 SF INDname
Fn A1 --Fn A9 CF INDname
Fn A2 --Fn AA FS?C IND name
Fn A3 --Fn AB FC?C IND name
Fn A4 --Fn AC FS? INDname
Fn A5 --Fn AD FC? INDname
Fn A6 --Fn AE GTO INDname
Fn A7 --Fn AF XEQ INDname
Fn B0 CLV nameFn B8 CLV IND name
Fn B1 PRV nameFn B9 PRV IND name
Fn B2 ASTO nameFn BA ASTO IND name
Fn B3 ARCL nameFn BB ARCL IND name
Fn B4 PGMINT nameFn BC PGMINT IND name
Fn B5 PGMSLV nameFn BD PGMSLV IND name
Fn B6 INTEG nameFn BE INTEG IND name
Fn B7 SOLVE nameFn BF SOLVE IND name
Fn C0 ASSIGN nameFn C8 --
Fn C1 VARMENU nameFn C9 VARMENU IND name
Fn C2 KEY # XEQ nameFn CA KEY # XEQ IND name
Fn C3 KEY # GTO nameFn CB KEY # GTO IND name
Fn C4 DIM nameFn CC DIM IND name
Fn C5 INPUT nameFn CD INPUT IND name
Fn C6 EDITN nameFn CE EDIT IND name
Fn C7 --Fn CF --
F2 D0 INPUTregF2 D8 (CLV reg)
F2 D1 RCL+regF2 D9 (PRV reg)
F2 D2 RCL-regF2 DA INDEX reg
F2 D3 RCLxregFn DB sigmaREG IND name
F2 D4 RCL/regFn DC FIX IND name
F1 D5 -- Fn DD SCI IND name
F1 D6 -- Fn DE ENG IND name
F1 D7 -- Fn DF TONE IND name
Fn E0 --F2 E8 (PGMINT reg)
Fn E1 --F2 E9 (PGMSLV reg)
F3 E2 KEY # XEQ labelF2 EA (INTEG reg)
F3 E3 KEY # GTO labelF2 EB (SOLVE reg)
Fn E4 --F2 EC (DIM reg)
F1 E5 --Fn ED --
F1 E6 --F2 EE INPUT IND reg
F1 E7 --F2 EF (EDITN reg)
Fn F0 CLP labelF2 F8 (VARMENU IND reg)
Fn F1 XFCN labelFn F9 --
F3 F2 GTO.nnnnFn FA --
Fn F3 GTO..Fn FB --
Fn F4 GTO.labelFn FC --
Fn F5 --Fn FD --
F3 F6 DEL nnnnFn FE --
F3 F7 SIZE nnnnFn FF --
Nick Reid
>>
> in memory to look. You gave the example of placing 1's in
> a program then scan through memory via the hex editor.
> The hex editor scans 1M of addresses. Where do you start
> looking? (ie: where does the user memory begin-end)
>
It's not as much as that: you will find that the whole caboodle repeats
itself four times through the memory space (something going on there #|)
so that you only have 1/4 Meg to scan. Also if you do something like
filling the alpha reg with, say all "U"s (so you get a l-o-n-g string
of hex "5"s) or similar, then it shouldn't take you more than a few
minutes to find it (the debugger zips along in increments of 10H and
more off some of the keys). ARCL other patterns into the stack and
look for them in the general region of where you find the alpha reg:
actually just stumbling around and trying to make sense of it yourself
is a really good way to get a line on what is happening. You can tell
where user memory is because you can poke values into those places -
when you are in ROM the values you poke have no effect on what is
displayed when you go back to see what happened. By the time you have
crashed the machine a few times someone will have gotten a hex table
to you (re your email: I'm not in a position to forward anything for
a fair while - I seldom make notes, and those I did make aren't to hand,
sorry). Recalling more about it, I now remember that it wasn't the
actual hex table that helped find some of the entry points, but some
cryptic notes that were on the *back* of the table that Joseph distributed.
Something in the debugger runs code from the address it is pointing to
(from memory, the ".", ??) and so you have a tool to check your hunches.
I'm not saying that some solid info won't help a lot in your effort to
try to understand the machine, but a big part of making sense of it,
in the absence of published IDS, is just foolin' about and trying to
figure out what is going on.
>>The HP41 hex code was published in many places. The remaining special
>>HP42S hex codes were published in HPX Exchange, V1 N6 (December 1988),
>>page 13. If you would like, I can retype it and post it here.
>
> What is (was?) the HPX Exchange? Are back copies available?
> Could (and would) you direct me to a source for the HP41 hex code.
HPX was an HP handheld user group that published a few issues of a journal
at about the time the 42 came out. Brian Walsh was the editor - he now
lives in Chicago, and still has plans to publish more, but so far has yet
to get them onto the streets.
The hex table that Joseph is referring to is a list of codes ("tokens")
that are put sequentially into user memory as you enter a program that
are later interpreted by the operating system when the program is run.
The entry points I was referring to are within the operating system that
does the interpretation. Synthetic programming consists of fiddling
with the sequence of hex codes to make the operating system come up with
some bizarre interpretations. This was very effective in th 41 as there
were few internal safeguards against it, but in the 42 the operating
system is a lot more sophisticated and "corrects" a lot of these errors
(in fact all of the errors that actually make "synthetic" instructions
and enable little tricks like running programs out of the alpha register
etc).
> Also, does a good source still exist to help beginners (like
> myself) in "synthetic" programming. It appears that the
> techniques involved in synthetically programming the hp41 can
> also be applied to the hp42s.
Not really - that's why I don't class it as synthetic programming 41-style:
see the comments above re too many safeguards....
> Also what is the "Turbo Mode"?
There is a nybble in reserved RAM that controls the speed of the processor.
The original Turbo mode altered this nybble to make the calc run faster
but unfortunately the ever vigilant operating system would pounce on it
as soon as a program stopped (or something like that - maybe it was when
you next pressed Enter, whatever #|) and so you were back at standard
speed. The good news is that Chris Bunsen, who had a lot to do with the
design of the 42, has recently published a method of altering the nybble
using the operating system to do it, so it doesn't lose its speed at the
drop of a hat.... that's the one you should be looking out for.
Above all, don't worry, be happy. If you keep your eyes open, and are
not afraid of poking around in the system you'll cotton onto all this
pretty soon. And if you really want to hack an HP calc, either get a
41 or try a 48 and jump into SYSEVAL land. 'sall just fun, you know.
The _value_ of a 42 is in what is offered officially in the handbook:
a highly developed version of RPN that makes technical calculation with
vanilla methods a breeze.
Regards,
Nick
Shannon Mann
>In article <291e29eb:4083.7comp.sys.handhelds;1...@hpcvbbs.cv.hp.com>, akcs.j...@hpcvbbs.cv.hp.com (Joseph K. Horn) writes...
>>
>>What I always did was put the number 111111111111 in the program
>>immediately before the place I wanted to do some synthetic poking, and
>>then use the hex memory editor (sometimes called the "debugger") to scan
>>through memory until the easily-seen 1's scroll by. That gets you
>>there; the hex table is then all you need to poke synthetics into
>>memory.
>>
> What I am having problems with is that I do not know where
> in memory to look. You gave the example of placing 1's in
> a program then scan through memory via the hex editor.
> The hex editor scans 1M of addresses. Where do you start
> looking? (ie: where does the user memory begin-end)
An evenings poking around found the following: (NOTE: much of this has
been posted before)
Well, in a nutshell, we have found some interesting things in the monitor.
You can get into monitor mode by using EXIT/LOG together and then the
backspace key.
Note one address contains a nybble ie. the address counts nybbles. The
data field shows the nybble of the current address and the next 15
nybbles. The monitor address space size is 100000h = 2^20 nybbles =
2^10 Knybble = 1 Mnybble (=512 Kbyte).
Keyboard is now configured:
_
E+ 1/x \/x LOG LN XEQ
A B C D E F
STO RCL R; SIN COS TAN
I10
ENTER X><Y +/- E <--
^ 7 8 9 (divide)
I1000 7 8 9 D100
(down) 4 5 6 x
D1000 4 5 6 I100
(shift) 1 2 3 -
1 2 3 D1
EXIT 0 . R/S +
0 I1
The open spaces represent a drop back to test mode, with the exception of
'.' which does an execute.
The I and D numbers represent increase and decrease in addresses. The
digits allow you to modify the contents, incrementing one for each press.
The cos key prints to the IR port. Most of this was posted already.
Now for the really interesting stuff. We did some searching through the
memory map, looking for RAM and ROM, by seeing what data we could alter
and what we couldn't. We found RAM at 50000..5FFFF, which appears to be
the same 4000 nybble block repeated 4 times, which agrees with the 42
having 8 Kbytes RAM (4000h nybbles = 2000h bytes = 8192 bytes). Thus RAM
is located 50000..53FFF. We found ROM at 00000..1FFFF, which is 128
Knybble = 64 Kbyte (does the 42 have 64 K ROM?).
The stuff at $40000 seems to be a bit map of the display. Modifying its
contents changes the display. There is not a simple one-to-one
relationship with the bits as you enter them... Two successive columns of
pixels are not controlled by two successive memory locations...
The region from $503F8-$5044F is the alpha register, all 88
nybbles of it. We tried to determine if putting a large array on the
stack actually moved the location of the alpha register. The register did
not move when we placed a 10x10 matrix on the stack. If the memory map of
the HP42s found on page 272 of the manual is accurate, the non-moving
alpha register suggests that they use pointers into available memory to
store the actual contents of the stack.
If the memory map is accurate, the flags are located in the region beyond
$5044F. The difficulty seems to be that each nybble contains between 1
and 4 flag bits. An attempt to find the flag region failed as setting a
recognizable pattern in the user flags failed to turn up in memory.
We believe that user flags are stored one flag to a nybble. We suspect
that the system flags use a variety of storage formats based on functional
class. Four bits of a nybble might be used for flags 36-39, 56-59, 68-71.
Three bits of a nybble might be used for flags 61-63. Two bits of a
nybble might be used for flags 15-16, 22-23, 24-25, 28-29, 34-35, 40-41,
50-51, and 76-77. The other remaining flags may very well be stored one
bit to a nybble. All of this remains very much conjecture, as we have yet
to happen upon some method of testing these theories.
We don't even know if the flags are held in memory in contiguous order.
R. Homard's posting regarding the undocumented XFCN command. All we
noticed about this is that it wants the name of a program for a parameter.
Anyone figure this out?
Does the 42 use the same processor and assembly language as the 28 and 48?
How do we do a ML call from normal operating mode? How do we store an ML
routine as an object so it doesn't corrupt memory or get corrupted, and
how do we keep track of its address? ETC...
Is there any more on the 4 pins that can be seen when the battery
compartment is open? (look at the metal plate behind the batteries. You
can see them in the reflection...)
Has anyone opened their 42? Is this a reversible process?
HP has a book on the 42, something like 'Programming Examples and
Principles', or whatever. Does this contain general reference info or is
it just a bunch of programs? ie. does it have a more comprehensive
command reference (acceptible argument types, etc) with stuff like complex
branches used for the usual real functions with complex arguments, etc?
If it's just a bunch of programs to illustrate use of program commands and
constructs; there was enough info in the user's manual to figure this
out.
Long live the 42S - _lean_ and mean.
- Shannon Mann and Terrence Dick
>>The HP41 hex code was published in many places. The remaining special
>>HP42S hex codes were published in HPX Exchange, V1 N6 (December 1988),
>>page 13. If you would like, I can retype it and post it here.
I have received initial permission to create a small (<100k) archive of
hp42s software and other info on a local machine, accessable to all via
anonymous ftp. Of course, I need information.
I would appreciate the original hp41 hex tables as well as the new
additions to the 42s (I believe some of this was already posted).
Any and all hp42s/41 programs that you have, send them to me. I will try
to make some sort of indexing into the mess and possibly delete/not
include duplicates, etc. If the archive gets larger, I think I could
convince the local system operators to allow the archive to grow...
(after all, I do work here :-)
> rick homard
-=- -=- Diplomacy is the art
-=- Shannon Mann -=- ma...@watserv1.UWaterloo.Ca -=- of letting someone
-=- -=- have your way.
P.S. More goodies to come....
Joseph K. Horn
--
WolfNet BBS Pisa (Italy) Tel. +39-50-589050 300-14.4K Baud Matrix 2:332/602.0
Joseph K. Horn - via FidoNet node 2:33/800
UUCP: ...!gear!wolf!Joseph.K..Horn
ARPA: Joseph.K..Horn@wolf.sublink.org
Joseph K. Horn
Rick Homard
--
WolfNet BBS Pisa (Italy) Tel. +39-50-589050 300-14.4K Baud Matrix 2:332/602.0
UUCP: ...!gear!wolf!Rick.Homard
ARPA: Rick....@wolf.sublink.org
Nick Reid
--
WolfNet BBS Pisa (Italy) Tel. +39-50-589050 300-14.4K Baud Matrix 2:332/602.0
UUCP: ...!gear!wolf!Nick.Reid
ARPA: Nick...@wolf.sublink.org
Joseph K. Horn
--
WolfNet BBS Pisa (Italy) Tel. +39-50-589050 300-14.4K Baud Matrix 2:332/602.0
UUCP: ...!gear!wolf!Joseph.K..Horn
ARPA: Joseph.K..Horn@wolf.sublink.org
Nick Reid
>
>memory map, looking for RAM and ROM, by seeing what data we could alter
>and what we couldn't. We found RAM at 50000..5FFFF, which appears to be
>the same 4000 nybble block repeated 4 times, which agrees with the 42
>having 8 Kbytes RAM (4000h nybbles = 2000h bytes = 8192 bytes). Thus RAM
>is located 50000..53FFF. We found ROM at 00000..1FFFF, which is 128
>Knybble = 64 Kbyte (does the 42 have 64 K ROM?).
Wlodek Mier-Jedrzejowicz writes me the following:
You write that the whole 42S memory repeats itself 4 times and say
(something going on there #|)
Well, the same happened with the 28 (C or S? I no longer recall). I
believe they have 4 memory controllers, in case these should be
necessary in a future version, and on these models all 4 address the
same RAM though at different addresses. Now, why oh why don't HP finally
produce the models with RAM to use all that address space - especially a
42S with time functions and I/o too?
Well, we've been through that beef many times already. My current beef
is that I can read csh from my university machine, but cannot reply to
it - only to individuals :-(
At the Corvallis, Oregon, "launch" of the 42S, in the Oregon State U
bookstore, not only did some of the development team turn up in bright
blue Superman costumes, but some of them also brought along their development
machines as demonstrators to make up for the (then) lack of production models
for that purpose, one of which was particularly interesting. Not only did
it have a large rectangular hole cut out of the back cover to accommodate
a protruding Type 27 EPROM, but under the battery cover where there is
normally a single IR transmitter there was _also_ an IR _receiver_....
>The stuff at $40000 seems to be a bit map of the display. Modifying its
>contents changes the display. There is not a simple one-to-one
>relationship with the bits as you enter them... Two successive columns of
>pixels are not controlled by two successive memory locations...
As I recall, you can get a very interesting slow fade-out crash by poking
into one of the nybbles around there.
>Does the 42 use the same processor and assembly language as the 28 and 48?
The processor is a "Saturn" chip running at 1 MHz: the assembly language
is the same as that documented for the Saturn chip in the HP-71 (published
IDS) with the addition of a few instructions. However, the internal
programming is mostly done in RPL (as with HP calcs in general).
>How do we do a ML call from normal operating mode? How do we store an ML
>routine as an object so it doesn't corrupt memory or get corrupted, and
>how do we keep track of its address? ETC...
My guess is the the os would clobber it pronto, the moment it thought it
was there. However, it should be possible to jump pseudo-synthetically
into arbitrary points in ROM, and that could provide useful tools. It
should also be possible to store something below .END. that might be
able to escape such undesirable system attention.
>Has anyone opened their 42? Is this a reversible process?
HP's fabrication process for this sort of casing involves deforming some
internal fasteners to lock the thing closed - they look as though they
would be very difficult, if not impossible to reclose once prised apart.
Nick Reid
>>routine as an object so it doesn't corrupt memory or get corrupted, and
>>how do we keep track of its address? ETC...
>
>My guess is the the os would clobber it pronto, the moment it thought it
>was there. However, it should be possible to jump pseudo-synthetically
>into arbitrary points in ROM, and that could provide useful tools. It
>should also be possible to store something below .END. that might be
>able to escape such undesirable system attention.
Sometime later Nick Reid engaged his brain and bothered to look at the
memory map. He should have said below the first moveable boundary.
(Something in system memory will point to it, surely, ?? Is the space
between it and the other moving boundary easily clobbered, ?? Poke
something in there and do a bunch of stuff and go back and look, ??)
As atonement he wheedled Jeremy Smith into digging through his files and
coming up with two moving numbers of interest:
At 403f7 to 403ff is a clock and at 40304 is a 16 bit counter that seems to
be doing its nut in a non-clocklike way and might be a program or data pointer.
Both of these are viewed in motion by going to those addresses in the
hex editor, aka debugger, and then holding down the backarrow key.
The least significant nybble of the clock is of interest in that it might
demonstrate an easy technique for finding other rapidly changing pointers, IF
there are any: if the key is held down it appears as a 0, but by flicking
the key other, very transitory digits can be frozen in the display.