When I was doing my CS degree and had plenty of time in my hands for that sort
of thing, I had a look at the manuals for the two systems and tried to follow Ed
It looks like Ed Nather misremembered the story (in his defense it had been
several decades since he'd seen it) because the whole hack rested on the machine
having an index register bit "between the address and the operation code in the
instruction word", but the RPC-4000 had the index register bit ("index tag") at
the end of the instruction word  and nothing between the current instruction
and operand address, which is, I think, the natural reading of "operation code"
and "address" respectively. There's also nothing between the operand address and
the next instruction address. The RPC-4000 word looks like this:
[COMMAND][OPERAND ADDRESS][NEXT ADDRESS][X]
|0 4||5 11|12 17||18 24|25 30||31|
TRACK | SECTOR TRACK|SECTOR
On the other hand, Nather's account states that the hack changed an instruction
to a jump instruction- and the RPC-4000 does not have a jump instruction,
because it doesn't need it: like Nather's story says, every instruction has its
own GOTO- in the NEXT ADDRESS field.
Here's some alternative ways the hack could have played out, from what I can
1. The hack used the "Branch control" facility.
The RPC-4000 had another facility, the "Branch control", an internal flip-flop
with only one bit that was turned on when an arithmetic overflow was detected.
Kaye could have used this instead of the index tag and Nather may have
misremembered it as being the index tag.
2. The hack was actually done on the LGP-30
The hack might also have been possible to pull off on the LGP-30, that had two
bits between the opcode and the operand address  and an uncontrolled jump
instruction ("Unconditional transfer" in the manual). Kaye could have kept those
two bits set and caused an overflow, as told in the story.
3. The hack was done on an RPC-4000 emulating an LGP-30.
Royal McBee had an emulator written for the RPC-4000, specifically to be able to
run LGP-30 programs on the new machine :
My name is James William (Bill) Bryner ... In 1960 I was hired by Royal-McBee
to write the assembler for the replacement to the LGP-30, the RPC-4000.
Mel Kaye designed the RPC-4000 assembler. It was titled ROAR (Royal-McBee
Optimizing Assembler Routine). Edward W. Dubbs and I programmed that
assembler. Following that, I wrote an LGP-30 simulator to run on the
RPC-4000. This was meant to allow all programs written for the LGP-30 to be
executed on the RPC-4000 without further programming. A drum computer
simulating a drum computer is agonizingly slow!
I have no clear idea how any of the above could have worked. Just guessing.
 Here's an example from the LGP-30 manual, as in the article:
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0
order bits track bits sector bits
= bring = 20 = 00
( address = 2000 )
The LGP-30 has one conditional branch instruction, ‘T’, which normally tests the sign of the accumulator. But it has a variant form: if the sign bit of the instruction word is set (‘−T’), and the front panel TRANSFER CONTROL switch is set, then the branch is unconditionally taken.
This variant instruction form appears once in the game. In the normal case, a player using a simple strategy (take another card if ≤16) will quickly be in the hole. But if the TRANSFER CONTROL switch is set, they'll be ahead.
I don't have my notes handy, so my description of how this works may be slightly wrong.
The game has no seed for its pseudo-RNG; from a fresh load, if the player makes the same choices, the computer deals the same cards. (I can't think of any way to implement a changing seed on the LGP-30, other than asking the user to enter one.)
The game has a table of cards, indicating whether each card has been dealt or not. To deal, it pseudo-randomly selects a card, and checks whether it has been dealt already; if so, it tries again. (Yes, this is slow.) When all cards have been dealt, it clears the table to ‘open a new deck’.
When the program starts, it initializes the deck, unless the TRANSFER CONTROL switch is set. If the switch is set, the game starts with the deck table as loaded from paper tape. That (if I remember correctly) marks two aces as already used, and that is enough to skew the game play in the user's favour.
Similarly, we could overflow from "t" (test, conditional transfer) to "h" (store and Hold the contents of AC), but this doesn't make much sense, since we have a conditional branch instruction in place right from the beginning.