Peculiar HP 97 card reader quirk

[Dave Britten]

I was experimenting with my 97 a bit, and discovered an odd quirk when reading cards. This was actually inspired by my TI-59, having recently gotten its card reader fully operational. On the 59, you can force a side of a card to be loaded into any of the four 240-byte banks of its 960-byte memory, even if it's not the original bank that the card was recorded from. It's a little bit like the MERGE operation on the 67/97, though you can't specify exactly which program step to load to. This works with both program and data cards.

It dawned on me that this is a handy way to quickly verify a card that you've just written: simply read it into a different (higher) bank that's either empty or partitioned as data registers. If you get no error, the card was recorded properly, and you don't risk blowing away the program you've keyed in if there is a read/write error. Handy! HP 65/67/97 owners are probably familiar with the strategy of recording two copies of a program card on the off chance that one of the copies fails to write cleanly.

So I started experimenting with the MERGE function on my 97 to see if this card verification operation could be replicated. Obviously, you can't force the 97 to load a program card into the data register part of memory, but according to the manual, you can position the program pointer to the last step in program memory that you want to keep, press f MERGE, and feed in the card. So why not GTO .224 and then MERGE, effectively reading the whole card, but not actually loading the program steps anywhere? As long as you don't get a read error, you should be good, in theory.

But that's not actually what happens! At first I was starting to suspect a problem with the cards I was trying to read, but it turns out that GTO .224 MERGE has some weird effects. If you read a two-sided card, the first side will be read and the "Crd" prompt will appear, but when you feed in the second side, the motor runs about a quarter of a second longer than it should and the calculator reports "Error". If you try to merge in a one-sided card, there's no error, but the display register will show strange things like "-0.000000000-0" (yes, only one zero for the exponent). Pressing Enter seems to preserve the strange display, but any other operations normalize it to 0.00.

Could this possibly be some kind of interesting non-normalized number trick with useful side effects? I can't say I've ever seen this mentioned in PPC Journal. Does the 67 behave the same way?

[teenix]

The software engineers must have thought about this although may have overlooked this case.

For a card load operation in a 67 which should be the same as a 97...

The first code snippet is when GTO .050 was used with MERGE

The second code snippet is when GTO .224 was used with MERGE

Code:


$17B8 270   c -> data address RA=40
$17B9 23C   1 -> p            P=1
$17BA 2E2   if c[p] = 0       C=C5805FF300F128 P=1
$17BB 3DA   then go to $7DA   C=C5805FF300F128
$17BC 33C   0 -> p P=0
etc

$17B8 270   c -> data address RA=15
$17B9 23C   1 -> p            P=1
$17BA 2E2   if c[p] = 0       C=C5805FF300F70F P=1
$17BB 3DA   then go to $7DA   C=C5805FF300F70F
...
$17DA 210   return

You can see that the RAM address is set to 40 in the first example and the first card data will be placed in the appropriate register location that corresponds to step 51, in this case byte [1] of register 40. regC [2][1][0] = 128 = 28hex(40) + offset 1 = step 51.

The second example shows RAM address 15 which is not program memory area. Also register C[1] = 0 which causes the storage part of the code to be bypassed. This will occur also, if there is not enough steps before the end of program memory to load a card into, although no error is raised. regC [2][1][0] = 70F = 0Fhex(15) + offset 7 = step (???). Also there is no offset 7 in a register only 0 - 6. Maybe your 97 is actually trying to access an invalid RAM location.

Both my 67 and 97 simulators report an error for single or dual card merges from step 224.

There are multiple reason why an error may be raised in the code - too early in the morning :-)

cheers

Tony