Many of you will be familiar with the story of Mel, the Real Programmer [ http://www.pbm.com/~lindahl/mel.html ] in which Ed Nather (writing in 1983) relates his experience from 20 years previously in attempting to patch a BlackJack program written by his ex-colleague (Mel Kaye) for the ancient RPC-4000 computer, and how the complexity of the code he had to work through left him so impressed with Mel's familiarity with the inner workings of the computer that he abandoned the attempt to patch the code and even 20 years later, he still held Mel as the archetype of a "Real Programmer". I first came across the story on a BBS sometime the early 90s, at a time when I was just starting to become competent with x86 assembly code, and self-modifying code was a pretty fascinating idea, as was extreme performance optimisation. Then recently I came across the Mel story again, and went looking to see what (if anything) of the legendary machines and codes had made their way into the retro-computing archives across the net. The 'holy grail' would be a copy of the original BlackJack program with the back-to-front cheat option, and major bragging rights would come from being able to make the patch that Ed Nather had given up looking to make. I'm not there yet. What I have found so far is: - What looks to be a dump of a paper tape copy of the BlackJack game for the LGP-30, the predecessor to the RPC-4000 [ ftp://ftp.informatik.uni-stuttgart.de/pub/cm/lgp30/papertapes/Games/bkjck.tx ] - A copy of the RPC-4000 reference manual, with description of registers and opcodes [ http://www.bitsavers.org/pdf/royalPrecision/RPC-4000/RPC-4000_Programming_M… ] - Documentation for the RPC-4000 version of BlackJack, written by Mel Kaye, including what seems to be a writeup of the feature that Ed was asked to make work correctly ("PLAYING CONVENTIONS...8:. If SENSE SWITCH 32 is depressed, there is a better than normal chance of an ace being dealt as the player's first card"). [ http://www.bitsavers.org/pdf/royalPrecision/RPC-4000/programWriteups/W1-01.… ] the loop in question must have been based around opcode 21 "COMPARE MEMORY GREATER", with the eventual 'overflow' to opcode 22 (TEST MINUS). I don't know what sort of work this loop would have been doing, although given the program documentation clearly states program execution starts at 00000, and that is also where (in the story) control is eventually transferred to once the loop exits, the loop must have been some kind of post-game cleanup, ready to re-start. So my current theory is - the data stored in the upper memory locations is the card deck, (stored initially perhaps as numbers 1..52) - as cards were "dealt" they were marked as such by (e.g.) setting the sign bit - the loop without apparant exit is going through the pack removing the 'dealt' marker, prior to being shuffled at the start of a new game. It is apparent that Ed's memory was not completely accurate; not completely surprising given the 20 year gap from when the events occurred until when they were documented. He mentions the clue that helped him understand the way the loop exited as being the fact that the index register bit was set even though Mel never used the index register, and says this index register bit is "between the address and the operation code in the instruction word". However reference manual is clear that the index register bit is the least significant bit, and in fact the opcode bits (0..4) are adjacent to the data address bits (5..16). I can't see any way the index bit could have been part of the loop/overflow.