HP Forums
HP-35 chip photos, assembly code - Printable Version

+- HP Forums (https://archived.hpcalc.org/museumforum)
+-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html)
+--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html)
+--- Thread: HP-35 chip photos, assembly code (/thread-29897.html)



HP-35 chip photos, assembly code - Peter Monta - 03-16-2003

As an exercise in reverse engineering I've been playing with the HP-35 ROMs to extract the firmware. The code seems to work fine under the CASMSIM emulator---all the keys and functions behave as expected.

Code, chip photos, and emulator screenshot are here:

http://www.pmonta.com/calculators/hp-35

HP has not answered my two emails regarding permission to publish it, but then it's almost an exact subset of the HP-45 code already in one of their patents.

I wouldn't mind having an extracted netlist of the processor and register chips. (The image quality needed, though, may be a bit beyond my low-end microscope and digital camera.) One could then run a transistor-level emulation using Spice or (at the switch level) a Verilog simulator.

It would be mildly interesting to know what the bug was in the first HP-35 version. I suppose it's asking a lot, but would anyone care to send me the hardware so we could find out? I'd try not to break any bond wires during the chip surgery; there's some chance I could return it in working condition.

Cheers,
Peter Monta


Re: HP-35 chip photos, assembly code - HrastProgrammer - 03-16-2003

Excellent work! Congratulations!


Re: HP-35 chip photos, assembly code - Mike Sebastian - 03-16-2003

That's fantastic! Thank you very much for sharing your research with us!


Re: HP-35 chip photos, assembly code - Vieira, Luiz C. (Brazil) - 03-16-2003

Hi, Monta;

I second the others: Congratulations.

Just for the records: all of the technology mentioned in your post was available for consumers in 1972. I guess the technology was available in 1970 or less for ptototyping purposes.

I was 9 years old in 1970.

Best regards.

Luiz C. Vieira - Brazil


Re: HP-35 chip photos, assembly code - Michael F. Coyle - 03-16-2003

WOW!!! That is one hell of a good reverse engineering job you've done here. I've done some smaller jobs of reverse engineering and know (in principle) how to read ROMs but I've never tried it myself. I'm jealous :)

A couple of questions for you.

Is this a Mostek or AMI chip set?

Did you record the part numbers of all of the chips for future reference?

How did you get the chip packages open? Did you put them back together and if so, did the machine work?

Again, congratulations on a terrific job!

- Michael


HP-35 chip photos, assembly code - Peter Monta - 03-17-2003

> WOW!!! That is one hell of a good reverse engineering job you've done here.

Thanks! (And thanks for the other nice replies in this thread.)

> Is this a Mostek or AMI chip set?

AMI for all chips: ROMs and the processor and register chips.

> Did you record the part numbers of all of the chips for future reference?

Not for the ROMs, unfortunately, no, but the part numbers for the processor and register chips are still visible. I hope to take images of these at some point.

> How did you get the chip packages open? Did you put them back together and if so, did the machine work?

That's the nice thing about these old chips---the packages are either metal cans or ceramic with metal covers, very reverse-engineering-friendly. Plastic needs nasty acids to remove.

The ROMs were in TO-8 metal cans. I abraded off the top of the can with a Dremel tool, working all the way around the edge, kind of like a can opener. It's best to mask off the rest of the board so that metal dust doesn't get all over it. (For the ceramic chips, just a soldering iron or hot-air gun and a small knife should be enough.)

Unfortunately I broke a bond wire on the third ROM, so unless I can get access to a wirebond machine to repair it, the board will be nonfunctional. If I were to do it again,
I'd rig up some holder for the work instead of grinding freehand.

The chips should work with their covers off (though they probably should be kept dark to avoid any photocurrents), but best would be to put something over them, like a microscope-slide cover glass tacked on with RTV, so no dust or grit gets inside.

Cheers,
Peter Monta


HP-35 chip photos, assembly code - Peter Monta - 03-17-2003

There's a photo of the HP-35 processor board at the bottom of the web page. The three exposed ROM chips can be seen.

Cheers,
Peter Monta


HP-35: please post in the Articles Forum also! - Andrés C. Rodríguez (Argentina) - 03-17-2003

Congratulations! Would you like to post your work in the Articles Forum, to make it more "static" and thus available than in this discussion forum (more dynamic and volatile)?


Re: HP-35 chip photos, assembly code - Bill Wiese - 03-17-2003

Bravo, Peter, tour de force! You da man.

A few comments and perhaps some interesting background for some folks here: I've been involved with more than a few reverse-engineering activities on (P)/ROM firmware in my past.

In one case, we used a shop that used fuming nitric acid to 'decap' the plastic (epoxy) DIP packages. Ugly job, but there are co's that do it - not just for reverse engineering but for product failure analysis, etc. Cost us about $400 total to decap 3 chips and photomicrograph the dies.

In this particular situation, unfortunately, the parts we really cared about had EPROM not mask ROM, and we couldn't get the data out (not enough chip info, semiproprietary part/pinout, address mappings, etc. These were Japanese Motorola/Toshiba custom flavors of 68HC11s.) The parts we didn't care as much about were 4-bit CPUs w/mask ROM and there were no equivalent E/PROM microcontrollers available except special eval board stuff so we couldn't do retrofits even if we'd taken the time to extract ROM data. FPGA/CPLD stuff today could've changed this perhaps.

Getting data on Japenese lower-end microcontrollers tied with Japanese products is quite difficult. These are not always 'custom' parts but they never make it into databooks.
Many of these parts are not sold in US or Europe either (esp 4-bitters and some of the low-end 8-bit variants).

On chips with smaller much feature sizes, the glass passivation layer can interfere with reading ROM contents; if the ROM metallization layer is not in the top 2 layers life can be hard too, looking at the bits. Sometimes ROM row/column lines are staggered or are in funny order too - do not have directly incrementing address relationship vs. #rows/#columns traversed.

However, we've had success with quite a few EPROM microcontrollers in the late 80s/early 90s. Many had "security bits" that were subvertible - in some cases on 8051 variants, the EPROM security bit(s) were not latched except at full reset, so booting the CPU 'wild' - straight power up w/no forced reset - allowed external program to, after awhile, get control of the free-running CPU, deal with /EA ROM-bank toggling and have external program begin to fetch & emit internal ROM data. Later revisions of these parts latched the /EA (external access) pin at power-up, not reset.

CPUs that offer either 'ROM verify' (but no readback) or even 'encrypted verify' as an option (and left enabled by mfgr in shipped product) allow a scripted EPROM/CPU burner to verify against a ROM image constructed "on the fly". Sometimes a bit of logic is needed to reset targeted CPU each pass (one pass per byte; each pass has to start back from $0000 again and verify upward to the next new byte to test.) In theroy this process could take 256*ROM_size passes, and is thus time consuming and can take overnight (depending on size of PROM area & speed of burner verify pass & communications speed). Using byte test sequences sorted by some prior knowledge of avg opcode/operand frequency (or a 2nd-order predictor - knowing some opcodes, likely operands can be chosen with higher degree of confidence) instead of just trying $00...$FF can speed things up. PROM data read back as 16 bit words would be a real b*tch to deal with since 65536 possibilities per location: set the process running and go on vacation.

Even with encrypted verify - where the data read out is still encrypted - these are usu simple XOR/XNOR masks with a short key (16 or 32 bytes), and the typical mask string has something like ***5/89 ACE CO./ ROBERT SMITH *** - that is, the key has a partially known or partially predictable plaintext. Key values that are unknown can be examined by checking decrypted/disassembled code for sensibility and checking for ROM checksum (often $00 or $0000).

Happy hacking!

Bill Wiese
San Jose, CA




Re: HP-35 chip photos, assembly code - David Smith - 03-17-2003

A lot of these early chips were not passivated with a silicon dioxide coating. Once you open the package, the outside world gets in and slowly corrupts the magic inside. Even if you fixed the wire bond, the chips would probably die in a few months anyway.


Re: HP-35 chip photos, assembly code - David Smith - 03-17-2003

There are chip doctors out there that can suck the brains out of just about any chip that you can imagine. They can read E(E)PROMs, etc with polarized light or e-beam probing. They can generate full mask sets and reverse them into schematics. All it takes is money...


Re: HP-35 chip photos, assembly code - Bill Wiese - 03-18-2003

> There are chip doctors out there that can suck the
> brains out of just about any chip that you can imagine.
> They can read E(E)PROMs, etc with polarized light or
> e-beam probing. They can generate full mask sets and
> reverse them into schematics. All it takes is money...

Yes, we were reverse-engineering engine-control firmware.
Polarized light? Hmm, dunno about that.

Doing e-beam stuff (I've heard it's a bit problematic reading EPROMs & flash in terms of reliability) would be a bit pricey for one engine computer from one model sub-year for one make/model/engine variant of a car.

One other trick for dumping 'locked' or 'secured' EPROMs on microcontrollers is to UV-expose only the security bit area - these are often in a separate physical position than the actual EPROM array in question, and if EPROM array is covered and security bits are exposed, access can be gained.

In Silly Valley here, it's quite common for prototype chips to have 'surgery' performed on them using FIB (Focused Ion Beam). Some re-metal patches can be applied too: this can save a prototype chip from needing to be respun when just one portion has failed and is locking things up yet engineers wanna test the rest of it without delay.

Getting schematics from mask peels costs $$$ and you end up with, um, a schematic. Still can take a lotta sussing out to figure out what's going on on a functional basis, very much like getting a disassembly without comments :)

Bill Wiese
San Jose, CA