Post Reply 
Peculiar HP 97 card reader quirk
03-05-2021, 12:12 AM (This post was last modified: 03-05-2021 12:41 AM by teenix.)
Post: #2
RE: Peculiar HP 97 card reader quirk
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
Find all posts by this user
Quote this message in a reply
Post Reply 


Messages In This Thread
RE: Peculiar HP 97 card reader quirk - teenix - 03-05-2021 12:12 AM



User(s) browsing this thread: 1 Guest(s)