HP-38C ROM bank switching


I've been trying to get the HP-38C working in Nonpareil. In the Spice series, the HP-34C, HP-38E, and HP-38C all have more than 4 Kwords of ROM. Since 4K is the addressing limit of the processor, they use bank switching. The HP-38E/C have two banks for quad 1 (1 Kword from 2000..3777 octal), for a total of 5 Kwords. The HP-34C has two banks each for quads 1, 2, and 3.

I've been trying to figure out the details of the bank switching by comparing Nonpareil traces to captured traces from the real thing. My first guess was that the instruction 1060 octal did an immediate switch of the quad the instruction was fetched from. This was quickly disproven.

The next guess was that it did the bank switch of the current quad, but delayed by one instruction cycle to allow time for a branch instruction to be fetched from the original bank. This is probably not completely correct, as the 38C isn't functional, but it does now display "Pr Error", so I think I'm on the right track.

I'll have to continue capturing traces for comparison. Currently the comparison is a fairly labor-intensive process, but I'll write a script to partially automate it.

Prior to the Spice series, the HP-19C, HP-67, HP-92, HP-95C, and HP-97 used bank switching. I suspect that the technique will be the same as that of the Spice series, but won't know until I can dump the ROMs. Before Spice, the calculators did not have a self-test, so dumping the ROMs of those will be much more difficult. With the self-test, I simply passively monitor the Phi2, SYNC, and ISA signals to grab
the ROM addresses and data as the ROM checksum is computed.


It is amazing to see that successive calculator generations use bank switching at some point: 4k Spice, 64k CocoNut, 512k Saturn.

Addressable memory space seems always to be too small...

Thanks, Eric, for these very interesting information.



The Saturn CPU don't use bank switching, the CPU use "covered" technology in connection with then "CONFIG" and "UNCFG" commands.

The difference is,

- Bank switching is normally realized by switching address lines, so each bank has the same size.

- Covered technology overload parts of the accessable memory and each mapped controller can have a different address and size. Covered technology is priority controlled.

But back to bank switching, some Saturn based calculators use bank switching to select memory banks of the 2nd card slot on the HP48GX or selecting banks of the flash ROM on the HP49G. In both cases bank switching provided by external hardware.




Christoph Giesselink writes of some later Saturn-based calculators that use a form of bank switching:

In both cases bank switching provided by external hardware.

In the Classic, Woodstock, Spice, and Nut series, the bank switching is also provided by external hardware, which is built into some of the ROM chips. The CPU has no idea that there are multiple banks, and executes the bank switch instructions as NOPs. The bank-switched ROMs watch the instructions the CPU fetches and handle the bank switching on their own.


The Classic series started with a 256 word ROM address space, and used bank switching from the beginning to expand that to 2 Kwords (up to 8 ROMs). That wasn't enough for the HP-65 and the HP-55, which each used 3 Kwords. So they added a second level of bank switching to allow for two groups of eight ROMs (up to 4 Kwords possible).

The HP-9805 was developed by Ft. Collins division using the Classic chip set. It needed even more ROM than that, so they added more bank switching logic external to the CPU and ROMs, as well as a second instruction set (in a sense, a precursor of the "intelligent peripheral" concept used by the Nut CPU, the 1LB4 NPIC chip in the 82143A printer interface, and the 1LB6 PIL chip in the 82160A HP-IL interface).

The HP-46 and HP-81 designs appear to be derived from the HP 9805, but since they don't need nearly as much ROM as the HP 9805, they probably don't use the external bank switching. I haven't studied the HP-46 internals yet and don't have an HP 9505 or HP-81 to examine.


I spent several hours over the last few days studying traces captured from a real 38C trying to figure out the details of the bank switching. Sometimes the 1060 instruction seems to switch banks and other times not, yet it doesn't appear to be data dependent. At least not in any obvious way.

Just after I got to bed last night, another possibility occurred to me. I've only confirmed a part of the supporting evidence so far; I'll have to revise my code that extracts the ROM image from the raw romsucker log in order to fully test it.

What I realized is that during the execution of the checksum instruction, which checksums a 1K block of ROM, the bank instruction probably still takes effect when it is read out, and that it probably does in fact always take effect immediately as I'd originally guessed. If that's the case, rather than the self test doing the checksum over a single coherent 1K bank, and then the other, it is just doing it twice starting from opposite banks but toggling back and forth within the block.

For that to work and still be able to do a comprehensive checksum of each bank, it would be required that the 1060
instruction always be present at the same location in both banks. And it would be quite likely that there would be an even number of 1060 instructions in each bank.

So far tonight I've verified that both the 38E and 38C ROMs do contain an even number of 1060 instructions in both banks of block 1 at corresponding addresses.

Tomorrow I'll hack the log extraction problem and Nonpareil to test the theory.


Not only was that theory correct, but ALL bank-switched ROMs track a single bank switch state, and toggle on every 1060 instruction, regardless of from what ROM address the 1060 is fetched. This is unlike the bank-switching on the HP-41C, where every 4K address block that supports bank switching tracks its own independent bank switch status.

Now the 34C, 38E, and 38C limp along somewhat. Most basic math functions on the 34C are working correctly. The 38E and 38C aren't working quite as well. In a 38C trace from a cold start ("Pr Error") through two presses of the "1" key, I can see some differences. I'll have to study the traces to figure out what instruction(s) I've implemented incorrectly.
It may be the same bug that's keeping the logarithmic and exponential functions of the 25 from working correctly.

I hope the bank switching on the 19C, 67, 92, 95C, and 97 works the same way, as that will save me a lot of effort.


The trace shows a branch on no carry instruction not branching in the simulator though it does on the calculator. The instructions leading up to the branch instruction do in fact set up conditions such that the branch should not be taken, which means that there's something going wrong earlier leaving incorrect state somewhere. This will be hard to track down, so I'll take some more traces of various operations and hope that some of them show a discrepancy closer to the actual problem.

Possibly Related Threads...
Thread Author Replies Views Last Post
  HP 50g switching two keys in the user keyboard Sean Freeman 9 1,560 12-05-2013, 11:44 AM
Last Post: Mark Puscas
  41 SOLVE & INTEG Bank-switched Implementation. Ángel Martin 0 395 06-21-2013, 11:31 AM
Last Post: Ángel Martin
  HP85 Programmable ROM cardtridge 82929A-service ROM not working- inaki 2 734 04-25-2013, 08:08 AM
Last Post: inaki
  shelf life time of a ROM, EEPROM, EPROM vs Mask Rom Guido (Canada) 6 1,065 01-11-2013, 04:09 PM
Last Post: Thomas Falk
  Need help - HP 48SX bank switching 1MB card JJB299 1 437 11-07-2012, 07:34 AM
Last Post: Raymond Del Tondo
  Big ROM - 41 System DEMO ROM Ángel Martin 5 972 10-16-2012, 05:28 AM
Last Post: Ángel Martin
  HP clear cased 38C Keith Midson 14 1,598 07-17-2012, 07:45 AM
Last Post: Keith Midson
  Power_CL: updated CLUTLS module - bank-switched (!) Ángel Martin 7 866 06-03-2012, 04:23 PM
Last Post: Ángel Martin
  HP 38c Battery Door Joel Braun 1 423 03-25-2012, 09:22 AM
Last Post: aj04062
  HP-33s Battery Switching--What's the gag? Matt Agajanian 0 335 03-03-2012, 07:09 AM
Last Post: Matt Agajanian

Forum Jump: