Threaded Mode | Linear Mode

Thomas Klemm · 12-28-2015, 11:14 PM

(12-19-2015 03:08 PM)Mike (Stgt) Wrote: The ROM contains some tables/lists, decoding them will not make too much sense, IMHO.

Maybe you can point me to the addresses?

(12-16-2015 10:37 PM)Didier Lachieze Wrote: Any reason for not using D41 from the SDK41?

Meanwhile I could disassemble the 15c.obj file using D41.EXE. However I had to split the file into 3 parts of 8192 bytes each.
What I don't understand is the line numbering in 15c.obj:
0000-17ff
2000-37ff

Any ideas as to why there's a gap?

Cheers
Thomas

Stevetuc · 07-20-2022, 01:47 PM

(12-16-2015 10:24 PM)Thomas Klemm Wrote:
(12-16-2015 05:24 PM)Mike (Stgt) Wrote: How do you disasemble the whole ROMs?

Based on the source of Nonpareil I wrote a romdump program that reads a ROM and writes the corresponding assembler code. But it currently works only for the nut-processor familly.

Quote:Another question: may you show the HP10C code too?

Unfortunately I don't have the corresponding ROM. If someone is willing to send it to me I can do that as well.

Best regards
Thomas

Hi Thomas

Would you be able to make that romdump program available?

Thomas Klemm · 07-20-2022, 04:25 PM

(07-20-2022 01:47 PM)Stevetuc Wrote: Would you be able to make that romdump program available?

Recently I was wondering where the source code of this program could be.
But I couldn't find it right away.
So I will try finding it again.

And if I can't find it anymore, I can probably recreate it.
As far as I remember it didn't take long.
Eventually I would be interested too.

Stevetuc · 07-20-2022, 04:26 PM

(12-28-2015 11:14 PM)Thomas Klemm Wrote:
(12-19-2015 03:08 PM)Mike (Stgt) Wrote: The ROM contains some tables/lists, decoding them will not make too much sense, IMHO.

Maybe you can point me to the addresses?

(12-16-2015 10:37 PM)Didier Lachieze Wrote: Any reason for not using D41 from the SDK41?

Meanwhile I could disassemble the 15c.obj file using D41.EXE. However I had to split the file into 3 parts of 8192 bytes each.
What I don't understand is the line numbering in 15c.obj:
0000-17ff
2000-37ff

Any ideas as to why there's a gap?

Cheers
Thomas

I think that's a section of the rom filled with zeros. In the rom embedded in the hp15cle firmware there is a gap filled with zeros (at a different address because the 12bit addresses are padded to 16bit)

What format was 15c.obj input to D41?
Did you convert to 16bit little-endian binary or can it read the ascii 15c.obj from non-pareil src?

Stevetuc · 07-20-2022, 04:27 PM

(07-20-2022 04:25 PM)Thomas Klemm Wrote:
(07-20-2022 01:47 PM)Stevetuc Wrote: Would you be able to make that romdump program available?

Recently I was wondering where the source code of this program could be.
But I couldn't find it right away.
So I will try finding it again.

And if I can't find it anymore, I can probably recreate it.
As far as I remember it didn't take long.
Eventually I would be interested too.

Thanks Thomas Smile

Thomas Klemm · 07-21-2022, 10:16 AM

Please find the source code to compile the romdump utility in the attached zip-file.

Contents

Code:

Archive:  romdump.zip

  Length      Date    Time    Name

---------  ---------- -----   ----

       96  07-21-2022 10:44   Makefile

      962  10-31-2006 07:26   dis_nut.h

     6695  10-31-2006 07:26   dis_nut.c

     2482  07-21-2022 11:56   romdump.c

---------                     -------

    10235                     4 files

Instructions

I assume that you have make installed.
Otherwise just compile and link the files manually.

Code:

make

cc    -c -o dis_nut.o dis_nut.c

cc    -c -o romdump.o romdump.c

cc -o romdump dis_nut.o romdump.o

Usage

./romdump 15c.obj

Output

00000: 0000 nop
00000: 0717 ?c goto 00071
00001: 0116 c=0 w
00002: 1160 sel ram
00003: 1070 rdreg 8
00004: 1356 ? c<>0 w
00005: 0417 ?c goto 00046
00006: 0101 ?nc call 24020
00007: 0240 sel p
00010: 0441 ?nc call 01510
00011: 0014 ? s=0 3
00012: 0156 ab ex w
00013: 1404 s=0 1
00014: 0604 s=0 11
00015: 0645 ?nc goto 00151
00016: 0002 a=0 p
00017: 0000 nop
…
33760: 1534 pt= 12
33761: 1042 c=c+1 p
33762: 1740 rtn
33763: 0000 nop
33764: 0000 nop
33765: 0000 nop
33766: 0000 nop
33767: 0000 nop
33770: 0000 nop
33771: 0000 nop
33772: 0000 nop
33773: 0000 nop
33774: 0000 nop
33775: 0000 nop
33776: 0000 nop

Designation of Origin

Both files dis_nut.h and dis_nut.c were copied as is from nonpareil-0.78.
The function trim_trailing_whitespace was copied from util.c.
Both functions parse_hex and nut_parse_object_line were copied from proc_nut.c.
The typedef rom_word_t stems from proc.h.

The function read_object_file is based on sim_read_object_file from proc.c.
But instead of using sim_write_rom the function nut_disassemble_inst is used to print the line.
Also I removed code that seemed not necessary for the task.

Caveat

I just quickly cobbled this together but hope it is still useful.
Please ignore the first line of the output.
Also the last line is missing.
But I didn't bother to fix this.

Thomas Klemm · 07-21-2022, 10:20 AM

(07-20-2022 04:26 PM)Stevetuc Wrote: What format was 15c.obj input to D41?
Did you convert to 16bit little-endian binary or can it read the ascii 15c.obj from non-pareil src?

Unfortunately I don't remember.

Stevetuc · 07-22-2022, 08:41 AM

(07-21-2022 10:16 AM)Thomas Klemm Wrote: Please find the source code to compile the romdump utility in the attached zip-file.

Many thanks for posting this. : )

brouhaha · (This post was last modified: 03-07-2023 07:03 AM by brouhaha.)

(12-28-2015 11:14 PM)Thomas Klemm Wrote: What I don't understand is the line numbering in 15c.obj:
0000-17ff
2000-37ff

Any ideas as to why there's a gap?

Until 1988 when HP updated the Voyager electronics to use the newer SST chip ("Single-chip Series Ten", 1LQ9, see Chuck McCord's HHC 2022, HPCC 2022, and Allschwil 2022 presentations), the Voyager calculators used a 1LF5 (later 1LM2) Nut CPU and a 1LE2 (later 1LH1) R2D2. The R2D2 chip provides 6144 10-bit words of ROM, 40 56-bit words of RAM, and the LCD display driver. That was sufficient for all models but the 15C. In fact, the 10C only used 4096 words of ROM and 24 words of RAM, and at onee time there was consideration to making a cost-reduced R2D2 that would only have that much memory.

The ROM of the R2D2 is normally addressed to start at 0x0000, so it ends at 0x17ff. The RAM is split into two sections, from 0x00 through 0x07 (mostly used for the RPN stack, temporaries, housekeeping), and 0xe0 through 0xff (mostly used for numbered user registers, the user program, and more housekeeping). The LCD is bit-mapped at RAM addresses 0x09 and 0x0a. There is a hardware register of some kind, which might be a sleep timer, at 0x08.

The 15C needed more memory, so it was designed to use two R2D2 chips. The LCD controller of the second one is not used, so it is disabled, and the pins for it are not bonded out, allowing it to be packaged in the smaller square QFP package like the Nut CPU. In order to have two R2D2 chips, the memories needed to be in diffeerent address ranges. The 1LE2 wasn't designed for that, but the newer 1LH1 R2D2 was. It could have different base addresses fro the RAM and ROM mask programmed. It supported at least one alternate address setting, which is used by the 1LH1-0302 in the 15C. The ROM is from 0x2000 to 0x37ff, the small RAM block is from 0x10 through 0x17, and the large RAM block is from 0xc0 through 0xdf.

The 10C was discontinued before the SST chip was used, but the 11C, 12C, 15C, and 16C were redesigned to use the 1LQ9 SST chip (with four different ROM masks). The SST incorporated the functionality of the Nut CPU and one R2D2 chip, so in the 11C, 12C, and 16C the 1LQ9 was self-contained, forming a true Single-chip Series Ten. In the 15C, the 1LQ9-0325 was configured to communicate with the second R2D2, the 1LH1-0302, as was used in all 15C variants through its discontinuation. (The 15C LE hardware is entirely different, based on the Atmel AT91SAM7L128 ARM microcontroller.)

J-F Garnier · 01-14-2023, 09:01 AM

Eric, is the fact you accessed this thread an indication that you are considering fixing this "bug"?
If yes, you may also consider these ones:

GSB I with I<0 doesn't jump correctly
thread-196480.html

If a program ends with a conditional test that is evaluated false,
program pointer skips to line 1 and continue from there, instead of stopping at line 0.
thread-210753.html

But maybe you already spotted them...

J-F

Side note: each time I feel sad when see references to Mike (Stgt)'s posts that were arbitrarily and deliberately deleted. What a loss, this was history.

EdS2 · (This post was last modified: 01-14-2023 03:57 PM by EdS2.)

(Some fraction of missing posts can be found at the Internet Archive, for example here and here.)

brouhaha · 01-15-2023, 12:19 AM

(01-14-2023 09:01 AM)J-F Garnier Wrote: Eric, is the fact you accessed this thread an indication that you are considering fixing this "bug"?

I hadn't really intended to fix any bugs. My primary intent was to accurately simulate the calculator as HP sold it.

Quote:GSB I with I<0 doesn't jump correctly

I wasn't aware of that one.

Quote:If a program ends with a conditional test that is evaluated false,
program pointer skips to line 1 and continue from there, instead of stopping at line 0.

I discovered that my self just a few days ago. I was researching how certain 15C user instructions are dispatched in the code, by putting just a single user instruction into a program then tracing from either SST or R/S. When I started looking into TEST, I discovered the bug.

Thomas Klemm · 01-15-2023, 11:52 AM

(01-13-2023 10:51 PM)brouhaha Wrote:
(12-28-2015 11:14 PM)Thomas Klemm Wrote: Any ideas as to why there's a gap?

(…)

Thank you for your detailed explanation.
I appreciate that very much.

Thomas Klemm · 01-15-2023, 11:53 AM

(01-14-2023 03:56 PM)EdS2 Wrote: (Some fraction of missing posts can be found at the Internet Archive, for example here and here.)

From this link I quote:

Quote:
(12-28-2015 11:14 PM)Thomas Klemm Wrote: Maybe you can point me to the addresses?

In the ROM of HP16C there is a table starting @0400x. Here the first six lines of it:

Code:

0400 3BF Data  959 - DSZ ref. 0FBF 0401 2C3 Data  707 - ?? 0402 3BE Data  958 - ISZ ref. 0FBE 0403 2C4 Data  708 - ?? 0404 155 Data  341 - SQRT ref. 0D55 0405 0C5 Data  197 - ??
With the first line the address is computed where to jump for the function in question, the second line I quess it could be for the display in PRGM mode. There are Voyagers which use the second line only in PRGM mode. The table is only for functions without modifiers (STO n, RCL n, FIX n etc. I am still investigating) In other Voyagers the table could be located somewhere else. (The sequence of the related functions is according the program codepoint.)

An other table is at 03E0:

Code:

03E0 1BC Data  444 - 0 03E1 088 Data  136 - 1 03E2 1E4 Data  484 - 2 03E3 1E8 Data  488 - 3 03E4 0D8 Data  216 - 4 03E5 178 Data  376 - 5 03E6 17C Data  380 - 6 03E7 0A8 Data  168 - 7 03E8 1FC Data  508 - 8 03E9 1F8 Data  504 - 9 03EA 044 Data   68 - r 03EB 040 Data   64 - Blank? 03EC 14C Data  332 - o 03ED 0F4 Data  244 - P 03EE 174 Data  372 - E
to build readouts like 'Pr Error', digits and younameit.

An other table starts at 0010x, here few lines:

Code:

0010 308 Data  776  ** key 21, reference 0011 166 Data  358  ** key 31, ref. 0012 14A Data  330  ** key 10, ref. 0013 0EE Data  238  ** key 11, ref. 0014 14C Data  332  ** key 30, ref. 0015 14D Data  333  ** key 40, ref.

It lists where every key hit goes for execution, key 31 (R/S on the HP16C - ah - on all Voyagers) will continue at 0166x, etc. Analogous to the discontinuous keycodes the list is somewhat sliced, last entry at 00C8, and interspersed with code.
In addition there is a list in which sequence you ought hit the keys to pass the keybord test.

If you find more, pls tell me - or here at best. Smile

Ciao.....Mike

These are the corresponding sections from the romdump of 16c.obj:

Code:

 02000: 1677 ?c  goto 01767

 02001: 1303 ?nc goto 01731

 02002: 1676 b sr    s

 02003: 1304 s=0 13

 02004: 0525 ?c  call 30525

 02005: 0305 ?nc call 67461

Code:

 01740: 0674 ? rcr 11

 01741: 0210 s=1 5

 01742: 0744 selprf 7

 01743: 0750 wrreg 7

 01744: 0330 c<>g

 01745: 0570 rdreg 5

 01746: 0574 ? rcr 6

 01747: 0250 wrreg 2

 01750: 0774 ? rcr -1

 01751: 0770 rdreg 7

 01752: 0104 s=0 4

 01753: 0100 wrrom

 01754: 0514 ? s=0 6

 01755: 0364 ??? 3

 01756: 0564 ??? 5

Code:

 00020: 1410 s=1 1

 00021: 0546 a=a+1   x

 00022: 0512 a=a+c   wp

 00023: 0356 bc ex   w

 00024: 0514 ? s=0 6

 00025: 0515 ?nc goto 50523

Quote:The ROM contains some tables/lists, decoding them will not make too much sense, IMHO.

As we can see the romdump decodes these sections as code and not as data.