I spent several hours over the last few days studying traces captured from a real HP-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 that after the self-test instruction completed execution would continue in the original 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.