Hacker News Reader

Comment by progre | Hacker News Reader

From the company in "The story of Mel" http://www.catb.org/~esr/jargon/html/story-of-mel.html

Mel Kaye's hack was actually performed on an RPC-4000, so the story goes.

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 Nather's story.

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 [1] 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

What Nather remembers could be an overflow of the NEXT ADDRES field, through the index tag, and into the COMMAND field. It depends on whether the RPC-4000 handled overflows by wrapping or saturation (I can't find that in the manual).

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 tell:

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 [2] 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 [3]:

  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 bet, the blackjack program that brought everyone to the Royal McBee booth would have been top of the line of the programs to be run on the RPC-4000. Perhaps, then, Nather was working on Mel Kaye's "port" of the original blackjack program, not on the RPC-4000 but on the LGP-30 emulator running on the RPC-4000. Judging from the descriptions of Mel Kaye's programs in Ed Nather's account, just having an emulator for the architecure would not necessarily mean that Kaye's programs would run without any changes on the RPC-4000.

I have no clear idea how any of the above could have worked. Just guessing.

_____________

[1] http://www.bitsavers.org/pdf/royalPrecision/RPC-4000/RPC-400...

[2] 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 )

[3] http://ed-thelen.org/comp-hist/lgp-30.html#Historical%20Note...

While the story makes it quite clear that it is about the RPC-4000 (because of the next address encoded in the spare bits of the LGP-30 instruction format), your ideas regarding the LGP-30 in (2) may actually work. Instruction "u", unconditional transfer (jump), is 12 (%1010) and the next instruction code is "t" (13, %1011), which is "test" (branch if AC is negative). So a program may cleverly overflow (by adding to the gap in the instruction) from an unconditional transfer into a conditional one, which is then ignored as AC is zero or positive and the program "falls through"…

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.

The LGP-30 version had a ‘cheat switch’. A paper-tape image is available¹ and I've disassembled it.

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.

¹ ftp://ftp.informatik.uni-stuttgart.de/pub/cm/lgp30/

The "t" (test) instruction with the sign-bit option and the "Transfer Control" button are mentioned in the post as well (see operations). On the LGP-30 this would have been the only means of manipulating the control flow from the console in a sensible manner. (I didn't have a look into the RPC-4000 yet, so I really don't know, if there had been additional options.) So the way to implement an option would have been to have a zero or positive value in the accumulator and then have a test instruction with the sign-bit set. If the "Transfer Control" button was deployed, we would take the branch (unconditionally), if not, we'd fall through to the next instruction, since the condition 'AC negative' was not met.

Nice bit of digital archeology there- thanks!

Thank you, Goblin Queen! I am persuaded by your logic.

Or without the irritating formating:

http://www.pbm.com/~lindahl/mel.html

Reply on news.ycombinator.com