[HP35S] Disassembling ROM
|
02-21-2015, 12:30 PM
(This post was last modified: 02-21-2015 04:03 PM by Tugdual.)
Post: #1
|
|||
|
|||
[HP35S] Disassembling ROM
Of course it seems difficult to read the ROM (Brouhaha did an amazing work on this in the past) but we now have simulators and I believe the ROM is this file here:
C:\Program Files (x86)\Hewlett-Packard\HP 35s Virtual Calculator\Models\Model.dat I checked the preliminary SPLB31A datasheet but couldn't figure out where the RESET vector is. We also don't have a clear idea of where the ROM is loaded though $C800 seems to be a good candidate. If anybody has a clue about that... Did anybody already attempted to disassemble the 35s ROM? Note: the ROM is actually embedded into the file 35s.sml |
|||
02-22-2015, 10:26 AM
(This post was last modified: 02-22-2015 10:59 AM by Tugdual.)
Post: #2
|
|||
|
|||
RE: [HP35S] Disassembling ROM
Found some constants in the ROM.
Code: -4.95920119017593E2 Anybody knows what these constants are? Edit: ok found that these are constants used for various polynomial approximations. For example .918938533204673 is used during gamma log approximation. |
|||
02-22-2015, 12:07 PM
Post: #3
|
|||
|
|||
RE: [HP35S] Disassembling ROM
(02-22-2015 10:26 AM)Tugdual Wrote: Edit: ok found that these are constants used for various polynomial approximations. For example .918938533204673 is used during gamma log approximation. Ah, that's interesting. I always thought the 35s used some kind of approximation for Gamma resp. factorials. You may try the x! key with some non-integers so that the 35s has to evaluate the Gamma function. The result appears almost immediately. Try some integers and you'll notice an increasing lag as the values increase. 10! is returned instantly, but 150! requires roughly a second. Try 160! and the result appears immediately again. In fact the 35s seems to calculate factorials up to 158! by iterative multiplication, while 159! and up is evaluated by means of the Gamma function. In this case not Γ, but ln Γ seems to be calculated. This would also explain slight errors for large arguments. Try 225,5! and the result is exact (1,89218764486 E434 with the last digit correctly rounded up from ...856). Try 225,6! and the last digit is 3 ULP low: 3,25375380207 E434 instead of ...210). This is the point where ln Γ exceeds 1000. Even if ln Γ is evaluated accurately to all internal 15 digits, there still is a potential absolute error of 1 E–11 in ln Γ which means a relative error of this order in Γ itself so that not more than 11 correct digits can be expected. Dieter |
|||
02-22-2015, 02:43 PM
(This post was last modified: 02-22-2015 04:49 PM by Tugdual.)
Post: #4
|
|||
|
|||
RE: [HP35S] Disassembling ROM
I struggle with few technical aspects:
- lack of SPLB31A detailed doc (for example about registers usage) - how to disassemble segmented ROM - not sure I really understand how the segmented ROM works. I would imagine that before any jump the code is refreshing the BANK register and then proceeds with normal jump. Providing that I'm not sure at all about the way the ROM is organized in the 35s.sml file, that is quite a lot of try/fail. I could verify that changing the file has an effect on the simulator, so the ROM is definitely there. |
|||
02-22-2015, 03:30 PM
Post: #5
|
|||
|
|||
RE: [HP35S] Disassembling ROM
An interesting adventure anyway. I downloaded a copy and am poking around.
|
|||
02-22-2015, 06:32 PM
Post: #6
|
|||
|
|||
RE: [HP35S] Disassembling ROM
Looking at the hex dump of the file 35s.sml, there seems to be a code segment starting at $85c0. The output of the DCC6502 disassembler looks like some legit 6502/8502 code:
Code:
BTW: There are some more "human readable" parts in the file, e.g. the constants library (speed of light, etc.) starting at $18750, some warning messages starting at $201c0, the messages of the self test starting at $e7f0, and a lot of function names and symbols every here and there, e.g. starting at $182f0. If there is no checksum, one could easily poke around... |
|||
02-22-2015, 07:21 PM
(This post was last modified: 02-22-2015 07:26 PM by Tugdual.)
Post: #7
|
|||
|
|||
RE: [HP35S] Disassembling ROM
Using IDA you rapidly accumulate a lot legit 6502 fragments and it doesn't even look like it was compiled from C which I found surprising.
The difficulty is the ROM paging to know how to segment the file and detect ROM changes. There is a specific BANK register address (apparently $0000) where you select a segment and then it would map 2 blocks of 16kB respectively in $4000 and $8000. I suspect that the ROM organization should be pretty much the same as for the 48g with basically a library by segment (I'm not an expert on 48g). You can find SPLB31A datasheets here There is a test ROM located in $C000-$C7FF (not sure if it is the something built in the processor) and then you can have another range from $C800-$FFFF for a custom ROM. So this is a 16kB area. If you open the 35s.sml file with a text editor, you find the settings of the emulator at the beginning of the file: Code: ;============================================================================== Now how is that organized? My best guess would be: Code: $C000 - $FFFF That's all I know at the moment. I wonder where the code is cold booting, possibly $C000, I wonder what registers are and how they work. |
|||
02-24-2015, 01:46 PM
(This post was last modified: 02-24-2015 01:48 PM by Thomas Ritschel.)
Post: #8
|
|||
|
|||
RE: [HP35S] Disassembling ROM
(02-22-2015 10:26 AM)Tugdual Wrote: Found some constants in the ROM. The same data block can be found in the ROM entry points of the HP-48SX: Code: 2B2DC %% HP:%%12 What makes me puzzling is why these values are stored in the HP 35S in ASCII format and not as binary or BCD numbers... |
|||
02-24-2015, 02:27 PM
Post: #9
|
|||
|
|||
RE: [HP35S] Disassembling ROM
(02-22-2015 07:21 PM)Tugdual Wrote: Using IDA you rapidly accumulate a lot legit 6502 fragments and it doesn't even look like it was compiled from C which I found surprising. Hmm... maybe you start to understand the problem/difficulty in fixing things... :-) Completely non-documented (at least in anything but sparse chinese) source, non-English tools, extensive regions of assembly using non-standard assembly heavily dependent on non-documented features and registers requiring a close working relationship with the exact chip manufacturer (who doesn't have anyone who understands the chip anymore), no way to flash or change the firmware once flashed, etc If you can imagine it, chances are it is part of the issue. TW Although I work for HP, the views and opinions I post here are my own. |
|||
02-24-2015, 02:45 PM
Post: #10
|
|||
|
|||
RE: [HP35S] Disassembling ROM
(02-24-2015 01:46 PM)Thomas Ritschel Wrote: What makes me puzzling is why these values are stored in the HP 35S in ASCII format and not as binary or BCD numbers...Perhaps the compiler/assembler used didn't natively support the numerical data format used by those libraries, so that it would have been difficult to write those constants in the source code. If the data would have to be converted into another representation before it could be used, it wouldn't have harmed to store them in ASCII strings, anyway. ASCII strings of (almost) arbitrary length are supported by virtually all computer languages. Another possibility might be that these numbers were meant to be patchable. It is quite common to store such numbers or strings in some easy recognizable and parsable format in binaries, so that they can be changed later on without having to recompile the sources, often even without having access to the sources (f.e. by OEMs or end-users). Greetings, Matthias -- "Programs are poems for computers." |
|||
02-24-2015, 04:43 PM
Post: #11
|
|||
|
|||
RE: [HP35S] Disassembling ROM
(02-24-2015 02:45 PM)matthiaspaul Wrote:I would say for the sake of consistency. The constants are also stored using ASCII because we need to pick a constant on screen and then it is represented as a tiny EQN inside the code.(02-24-2015 01:46 PM)Thomas Ritschel Wrote: What makes me puzzling is why these values are stored in the HP 35S in ASCII format and not as binary or BCD numbers...Perhaps the compiler/assembler used didn't natively support the numerical data format used by those libraries, so that it would have been difficult to write those constants in the source code. If the data would have to be converted into another representation before it could be used, it wouldn't have harmed to store them in ASCII strings, anyway. ASCII strings of (almost) arbitrary length are supported by virtually all computer languages. Also whatever constant is entered manually is the same, a mini ASCII EQN. Of course this is to the detriment of performance. I wonder if the whole calculator operates in ASCII, a bit like BCD but ASCII version. That would be pretty unique! |
|||
02-24-2015, 04:56 PM
Post: #12
|
|||
|
|||
RE: [HP35S] Disassembling ROM
(02-24-2015 04:43 PM)Tugdual Wrote: I would say for the sake of consistency. The constants are also stored using ASCII because we need to pick a constant on screen and then it is represented as a tiny EQN inside the code. Haven't looked at the ROM a single "bit" but could it be that these are simply the ASCII representations of the constants for... display purposes (and that there is a binary representation elsewhere)? Graph 3D | QPI | SolveSys |
|||
02-24-2015, 06:48 PM
Post: #13
|
|||
|
|||
RE: [HP35S] Disassembling ROM
(02-24-2015 04:56 PM)Han Wrote:Good suggestion but the ASCII is definitely the value. If you change the ASCII string in the emulator you really see a different values during the code execution. Now there could be a cached binary version in memory.(02-24-2015 04:43 PM)Tugdual Wrote: I would say for the sake of consistency. The constants are also stored using ASCII because we need to pick a constant on screen and then it is represented as a tiny EQN inside the code. |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: