PhantomDJ

As someone who has done a fair share of bugfixing classic games, I was pleasantly surprised to see this post. I also read the the full article. This is very cool! Don Hodges http://www.DonHodges.com

Its a fairly easy task to cheat with MAME and set the level to 255 and then complete it and see what happens. The game actually wraps to level 0 (no level info is shown in lower right corner) and plays at the same difficulty as level 255. No kill screen; it seems to play normally. When completed, the next level is level 1 and the game gets easy again and starts playing all of the screens again, until you reach level 159 again. Don Hodges One big question. Does it give extra men again when it hits level 1? Forgive my ignorance, but how does DK3 normally give out extra lives? Does it stop giving them out at a certain level or something? Don Hodges

You can make him appear by hacking the game using the MAME debugger. See http://www.digitpress.com/eastereggs/arcadedonkeykong3.htm for a screen shot. It is currently unknown if there is a way to make DK JR. appear via normal playing. Don Hodges

Its a fairly easy task to cheat with MAME and set the level to 255 and then complete it and see what happens. The game actually wraps to level 0 (no level info is shown in lower right corner) and plays at the same difficulty as level 255. No kill screen; it seems to play normally. When completed, the next level is level 1 and the game gets easy again and starts playing all of the screens again, until you reach level 159 again. Don Hodges

Wired Magazine interviewed me for this article. Enjoy! http://www.wired.com/magazine/2010/08/pl_killscreens/ Don Hodges http://donhodges.com

http://donhodges.com/phoenix.htm Phoenix's Scoring Bug Analyzed and Fixed By Don Hodges Posted 1/22/2010. Updated 1/25/2010 The 1980 arcade game, Phoenix, was created by Amstar Electronics. It is fairly well known that if the player shoots 3 birds in a row very quickly as they fly upwards during the second stage of the game, the score will jump to around 204,000 points, no matter what the player's current score is. 3 birds fly upwards and will trigger the bug if shot quickly enough. A sample score after triggering the bug. A video of the feat can be seen here: After some digging around in the assembly language code and using the MAME emulator with the dubugger, we can discover the reason that this bug exists, and design a fix for it. The program reserves 4 slots of memory for birds that have been hit by the player's missile. Each of these slots are 4 bytes long, and they are all contained in a single area of memory at locations #4370 through #437F. [The # indicates a hexadecimal number.] Slots 1 and 2 are normally used for the regular death animation for most of the birds. Slots 3 and 4are used for the special death animation which has the score shown in the middle of two shells which open on both sides of it and move apart. This is used for small birds that are flying upwards with wings outstreched, and for the large birds in the third and fourth stages. In each slot, the first byte is used as a counter which indicates the state of the animation of the dying bird. When a bird is hit, this byte is normally set to #C, or is set to #10 for the special animation. This counter is decreased as the animation of the dying bird goes through its stages, and reaches 0 (zero) when it is complete. When a bird is hit, the program first checks to see which type of bird was hit. If it was a normal bird, the memory location that is checked first is set to #4370, which is the first byte of the first slot. If it is one that uses the special animation, the first memory checked is set to #4378, which is the first byte of the third slot. Then it examines the first byte from either slot 1 or slot 3. If the byte is zero, this means that the slot is open to use and the code then uses this slot to store 4 bytes of data that are related to the animation of the dying bird. If the byte is not zero, this means that the slot is being used and the next slot is then checked. The program then checks either slot 2 or 4. If the first byte is zero, then it is then used, but if not then the code uses the next slot, without doing any more checks. This works out OK for regular hits. The third death animation becomes the special one that pulls apart onscreen. However if 3 birds flying upward are hit in quick succession, then the program, after checking the third slot and the fourth slot, ends up using 4 bytes starting at #4380 to store the data, in a nonexistent fifth slot. The memory locations #4381, #4382, and #4383 are normally used to hold the player's score! [The first byte #4380, does not appear to be used for anything.] These bytes get overwritten. #4381 always gets the value #20. This corresponds to the player's hundred thousands and ten thousands digits. The second byte #4382 gets a value of #41 or #42. This corresponds to the player's thousands and hundreds digits. The last byte can vary widely, and represents the player's tens and ones digits. When this occurs, the player's score becomes #204,XYZ, where X can be 1 or 2 and Y and Z can be various digits. [The score is held in memory in Binary Coded Decimal]. The assembly language code with my comments for all of this follows, for those that are interested. You may need some assembly language knowledge to follow this. The CPU code is assembly language from the Intel 8085A. ; come here when a bird has been hit. 0EB8: 21 78 43 lxi h,$4378 ; HL := #4378 [slot for special animation] 0EBB: 7A mov a,d ; A := D 0EBC: FE 10 cpi $10 ; Are we to use the special animation? 0EBE: CA C3 0E jz $0ec3 ; Yes, skip next step 0EC1: 2E 70 mvi l,$70 ; Else HL := #4370 [slot for regular animation] 0EC3: 7E mov a,m ; Load timer from this slot 0EC4: A7 ana a ; Is this slot available? 0EC5: CA D5 0E jz $0ed5 ; Yes, skip ahead, we will use this slot ; else check next slot ... 0EC8: 2C inr l 0EC9: 2C inr l 0ECA: 2C inr l 0ECB: 2C inr l ; Increase HL by 4. [now at 2nd or 4th slot] 0ECC: 7E mov a,m ; Load timer from this slot 0ECD: A7 ana a ; Is this slot available? 0ECE: CA D5 0E jz $0ed5 ; yes, skip ahead, we will use this slot ; else use the next slot. Bugged when birds are flying upwards. ; source of 204K bug. HL becomes #4380 which is start of score. 0ED1: 2C inr l 0ED2: 2C inr l 0ED3: 2C inr l 0ED4: 2C inr l ; Increase HL by 4 [now at 3rd or 5th slot] ; there should have been a check here to see if HL==#4380 and change it if so. 0ED5: 72 mov m,d ; Store D into byte 1 0ED6: 2C inr l ; Next byte 0ED7: 73 mov m,e ; Store E into byte 2. score becomes 20xxxx 0ED8: 2C inr l ; Next byte 0ED9: 70 mov m,b ; Store B into byte 3. score becomes 2041xx or 2042xx 0EDA: ... A Fix We can fix the bug by checking the value of L after it finds the first 2 slots filled and gets ready to use the next slot. If L is #80, then we will set it to #70 so that the first slot is used instead of the score RAM. This will end up using a normal animation for the bird death instead of the special animation, but this is probably the best way to fix this without doing a much more complete code rewrite. The fix does not appear possible to patch within the confines of the original codespace, so a hook is created to a new subroutine in an area of unused memory. This bug can be fixed by the following patch, which requires changing 10 bytes of code: 0ED2: CD E6 0E call $0EE6 ; call patch ... 0EE6: 2C inr l ; restore instructions wiped by the patch call 0EE7: 2C inr l ; 0EE8: 2C inr l ; if L becomes #80 then the S flag is set. Did it happen? 0EE9: F0 rp ; no, return and continue normally 0EEA: 2E 70 mov l,$70 ; else set L to #70 to use 1st slot, not the score RAM 0EEC: C9 ret ; return This patch has been tested and does work. It can be implemented by a MAME cheat code: :phoenix:20600000:0EEA:002E70C9:00FFFFFF:Fix 204K bug :phoenix:20710000:0EE6:2C2C2CF0:FFFFFFFF:Fix 204K bug (2/3) :phoenix:20610000:0ED2:00CDE60E:00FFFFFF:Fix 204K bug (2/3) Learn more about MAME cheats at http://cheat.retrogames.com Comments and Conclusions: Some have suggested that this bug is actually an "Easter Egg", but I disagree. It seems like this bug was not intentional. In my opinion it looks like some sloppy programming. It would suck to be going for a record score and accidentally trigger this and set your score BACKWARDS. Much thanks to Steve Fewell for inspiring me to look into this bug and providing help, and feedback on drafts of this page.

see the full report here: http://www.donhodges.com/bluemax.htm --- The computer game Blue Max was released by Synapse software in 1983 for the Commodore 64 computer. This game contains a hidden message which can be revealed by using a sector editor. I discovered this message in my youth, one night probably in 1984 or '85, probably while trying to hack the game to display my cracker name [The Phantom]. I was unsuccessful, but I did find something I was not expecting ... On Track 12, sectors 1 through 4 we find the following message: As far as I can tell, this unimportant factoid had been lost in the sands of time ... until now, 27 years later.

Full report here: http://donhodges.com/super_pacman_easter_egg.htm 4 A GOOD TIME JSR 91BD Executive summary: Here is how to trigger it: 1. Play a game and finish a stage. 2. After the stage is complete, the screen will flash a few times. 3. Press reset when the screen is flashing the yellow color. [On the Atari home computers, you can press OPTION or SELECT. On Atari 5200, press * or # on the controller pad] 4. You will see the following text scroll across the bottom of the screen: 4 A GOOD TIME JSR 91BD. Look sharp! The text will scroll away quickly, and will not return until the egg is triggered again.

http://www.donhodges.com/donkey_kong_easter_egg.htm Donkey Kong Lays an Easter Egg By Don Hodges Posted July 1, 2009 Updated 07/01/2009 In 1983, the arcade smash hit Donkey Kong was ported to the Atari 400/800 home computer systems by Landon Dyer. It was at the time the best home computer/console port for this game. Mr. Dyer, in between pulling his hair out while working on this game, included what is known as an "Easter Egg" in the game's code. If a certain sequence of moves or scores were done correctly, the designer's initials would appear somewhere on the screen. He writes on his blog, "There’s an easter egg, but it’s totally not worth it, and I don’t remember how to bring it up anyway (something like: Die on the ’sandpile’ level with 3 lives and the score over 7,000)." The Digital Press web site has a whole section dedicated to Easter eggs, and they are even offering cash rewards to those who can find out how to trigger them. Even the Landon Dyer himself did not remember how to trigger this Easter egg in Donkey Kong for the Atari home computers. It is suggested on the Digital Press site that the initials would appear in the bonus score box. 26 years later, I am pleased to announce that I have discovered the way to trigger this long lost Easter egg. Here is how to do it: 1. Play a game and get a score of 33,000 through 33,900. This score must become the new high score. [some other scores will work as well, see below.] 2. Kill off all of your remaining lives. However, your last life must be killed off by falling too far - by walking or jumping off a girder that is too high to land safely. If the last life is killed any other way, the egg will not appear. 3. Set the game difficulty to 4 by pressing the Option button 3 times. The icon for this difficulty is a firefox. 4. Wait a few minutes, and the demo screen where Kong jumps across the screen will appear. 5. The title screen will then appear, and Landon Dyer's initials [LMD] will be at the bottom center of the screen: Other base scores that will work are 37,000 ; 73,000 ; and 77,000. The hundreds digit can be anything, as can the hundred thousands digit. It doesn't matter what difficulty the game is played on to set the high score. But to see the egg, the current difficulty must be set to 4 (firefox). Technical Details How on earth did I figure this out? I started by getting a very good emulator for the Atari system - MESS [Multiple Emulator Super System]. Once in to the game, I activated the game's debugger and did a complete disassembly of the entire 64K RAM bank. This file is over 25,000 lines long. I faced a few false starts - I first believed the initials were to appear in the bonus score box. So I looked there but found nothing. I also closely observed the input routines, so see if a special sequence of joystick moves were required. This search came up empty as well. I kept digging around and eventually discovered the subroutine for drawing text to the screen. Right after the data for the "GAME OVER" text data , I found the following: 8D3E: FE ; location code to follow 8D4F: 50 BC ; screen location #50, #BC 8D41: 16 17 0E ; "L M D" [designer's initials!] 8D44: FF ; end code It was quickly after this that I traced back to the command which would display this line. It was preceded by a test based on several factors, which were all then discovered. Each of the factors are logically ANDed to each other, and the end result has to be equal to 3 to trigger the egg. 861C: A5 D2 lda $D2 ; load number of lives 861E: 2D 01 0E and $0E01 ; mix with high score, ten thousands 8621: 2D 02 0E and $0E02 ; mix with high score, thousands 8624: 25 CB and $CB ; mix with difficulty 8626: 2D 31 0E and $0E31 ; mix with Mario's last state 8629: C9 03 cmp #$03 ; result == 3 ? 862B: D0 07 bne $8634 ; no, skip Easter egg ; Easter egg 862D: A0 3E ldy #$3E 862F: A9 8D lda #$8D ; Easter egg text location at #8D3E 8631: 20 B8 AB jsr $ABB8 ; print Easter egg to screen ; resume program 8634: ... It turns out that the number of lives is set to #FF (255 decimal, or 11111111 binary) after a game is over. This provides a starting point with all of the bits turned on. Most of the bits turn to zero with the first AND at line #861E. For the high score, since the numbers 3 and 7 both have the same lower 2 bits turned on, they both work as far as this routine is concerned. [3 = 0011 binary and 7 = 0111 binary]. The game's difficulty is counted starting at zero, so level 4 has an internal value of 3 which is needed for the correct answer. Finally, line #8626 mixes in Mario's last state. The memory location referenced (#0E31) changes based on how Mario is moving. It is set to 3 when Mario falls and dies. Comments & Conclusions Of all the game hacking that I have done, this has to be one of the most rewarding and enjoyable. I played quite a bit of this game back in the day at a friend's house. It really was the best port of Donkey Kong that could be played at home. Another puzzle solved. What will I do next with all of my spare time?

According to the arcade-history.com entry: [ http://www.arcade-history.com/?n=asteroids...tail&id=126 ] I have been playing with this game a lot in MAME and cannot seem to replicate these bugs. Can anyone give more precise instructions on how to trigger these? I would love to be able to see them in action. I have reason to believe that these glitches don't actually exist, at least in this version of the game. Please help me verify that these bugs either exist, or don't , if you can. Thanks, Don Hodges http://www.donhodges.com

I just finished an analysis of triggering the diamond in Mr. Do! (arcade version). http://www.donhodges.com/mr_do!_diamond_trigger.htm Enjoy Don Hodges

You can view it at youtube: Here is what happens in this pattern. You will want to refer to another thread where I explain the code which determines targeting directions. Link Here The screen shot shows the moment where Blinky is deciding which way to go at the upcoming intersection. To make his decision, he examines the locations circled in red and computes the distance to the target. Both left and up are 1 tile away from the target, so Blinky chooses to go up because up is the last direction checked in the subroutine. Note: This is NOT a “booey”. Blinky simply never quite catches up to Pac-man in this pattern. Don Hodges DonHodges.com