← Experimental Atari Multiplayer Arcade

How Donkey Kong 4-Player Was Made

A record of an experiment in using AI coding agents to modify a vintage game · 4-Player v0.1, build 0038 · 6 and 7 October 2026

The original one-player Donkey Kong on the first board in the emulator: sloping red-brown girders with blue ladders, Donkey Kong at the top right next to a stack of barrels, Pauline on the top platform, an oil drum with flames at the bottom left, two hammers on the right, one Mario at the bottom, and HI SCORE, BONUS 4900 and 1UP at the top.
The original: one Mario.
The same board in build 0038 with four Marios at once, one on each of the four lowest floors: a red Mario at the bottom, a green one on the floor above, a yellow one on a ladder above that and a white one on the floor below Donkey Kong. The top left shows the player numbers 1 to 4 with 2 men each; the top right shows HI, L1, BONUS and 5000.
Build 0038: four Marios at once, here placed on four floors by a test script.
Contents
  1. What this is
  2. The goal and the starting point
  3. Source code from a cartridge
  4. How the original works
  5. Patching in place, and four traps
  6. Four players in a one-player game
  7. The rules of the race
  8. Drawing four Marios: three attempts
  9. Colour changes on the right line
  10. Scoreboard and title
  11. The music, the death jingle and the chest beat
  12. The CPU budget
  13. A sprite editor
  14. Automated testing
  15. Bugs, including the agent's own
  16. Timeline and numbers
  17. Known limits and open questions
  18. Lessons
  19. Credits

1. What this is

Donkey Kong 4-Player is an experimental modification of Atari's 1983 Donkey Kong cartridge for the Atari 400/800, programmed by Landon Dyer. Up to four people play at the same time, each with their own Mario on their own joystick port, on the same board: the first Mario to reach the top ends the board. The modification was made by an AI coding agent (Claude Code) working from the machine code in the cartridge. Testing was done automatically in an emulator; problems seen while the game was played during development were reported back to the agent and fixed.

This page was written from the project's development log, technical notes and build list. "The agent" means the Claude Code session that did the work.

2. The goal and the starting point

The request was a four-player simultaneous Donkey Kong for the Atari 800: one to four players selectable, all playing at once, unlimited hammers, players able to kill each other with hammers, so that the game becomes a race to the top; and no death from falling from a height.

The starting point was the original cartridge image: Atari's 1983 Donkey Kong for the Atari 400/800, a 16K cartridge at $8000-$BFFF. Unlike Demon Attack's cartridge, it had no free space at all. The original is a one-player game; its two-player games take turns, swapping the two players' data between turns.

"Four-player simultaneous" meant four Marios on joysticks 1–4, which only the Atari 400 and 800 have (the later XL and XE models have two joystick ports).

PlayerJoystickMario's colours (cap and overalls)
1port 1red (Mario)
2port 2green (Luigi)
3port 3yellow
4port 4white

Shirts, hair and the hammer are blue for everybody, and the faces are skin colour; section 8 explains why.

3. Source code from a cartridge

The method and most of the tools came over from the Joust 4-Player work, with fixes made during the Demon Attack work: a headless test harness, a 6502 disassembler, a source generator, and a private build of the atari800 emulator with coverage counters, a fixed random seed and a write-watch.

4. How the original works

Reading the generated source gave this picture of the original:

Copy protection in the jump. The jump routine runs LDA $8648 : ADC $8649 : CMP #$20: two bytes of the program code must add up to $20. If the code has been moved, every jump becomes a deadly fall.
HardwareOriginal4-player
Players 0–2Mario's three colour layersMarios 1–3, one player each
Player 3the bonus items, moved by the DLIMario 4 (the items are drawn into the bitmap)
Missiles0–2: Mario's hammer0–3: one per Mario, all blue ("fifth player" colour)
DLIsboard 0's colour change; player 3's bandsthe four Marios' colour changes, with board 0's colour change merged in
Joysticks1–21–4 (ports 3 and 4 through PORTB, TRIG2, TRIG3)

5. Patching in place, and four traps

For Joust and Demon Attack the generated source was made relocatable, and a relocation test showed that it could be moved. Donkey Kong was handled differently: the original is patched in place. Every original address stays where it is, and every edit is the same size as what it replaces: a JSR or JMP into new code, or NOPs. The source passes many addresses in registers and inside packed board data, so making all of it relocatable would have been a long job with little use: the ROM is full anyway, and all new code has to go into RAM. Every build compares the address of every label of the generated source with the new build and fails if one has moved.

The layout is a 32K image: the new code and its variables at $4000-$77FF, the original at $8000-$BFFF. As a cartridge it is a 32K XEGS bank-switched cartridge (type 12) that copies the new code into RAM at power-on, so it needs 32K of RAM; the program file and the boot disk load both parts on a 48K machine and start the game at $8513.

The cartridge needed a loader, and there was no free byte for one. The original's two-player swap routine (16 bytes at $B1A3), not needed when everybody plays at once, became the cartridge's boot code: it selects bank 1 and jumps to a loader there, which copies the new code into RAM and starts the game. The three calls of the swap routine became NOPs. One more constraint: the game's screen clear wipes $2100-$40FF, which includes the first page of the new code; only the loader, which runs once at power-on, lives there.

In ROM the program cannot change itself. In RAM (the program file and the boot disk) the first test builds died within seconds. The coverage emulator's write-watch on $8000-$BFFF found four writes into the program's own address space:

  1. The title unpacks a data block onto code at $8A17. The jump's checksum (above) reads exactly this instruction, so it had to stay: only its destination operand was changed, to $C000 (unmapped on a 400/800).
  2. The line address table points every line below the screen (lines 198–255) to $9680, which is code. Now $C000.
  3. The VBI writes a 0 into the title logo's data at $8808 on every frame of play. Now NOP NOP.
  4. The DLI stores through a pointer whose high byte the main loop sets to a random value $80-$BF every frame: a random byte of the program on every DLI. Now NOP NOP.

After that, the write-watch saw no write into $8000-$BFFF during 4,000 frames on each board, and the unchanged game booted as a cartridge, a program file and a boot disk on an Atari 800, and as a cartridge on an XL (builds b0001–b0004). From then on every build was kept, together with the sources that made it.

6. Four players in a one-player game

The original has one Mario, kept in a set of variables. The new player loop runs the original's Mario routine once per player, with that player's state copied into the original's variables first and copied back afterwards: $69-$7B, $82, $BB and $BC in zero page and $0E31-$0E33, 25 bytes per player. The original already reads the joystick as STICK0,X and the button as STRIG0,X, with X holding the current player of its alternating two-player game, so setting X to each player in turn makes each Mario follow his own joystick. Scores are swapped only around the score routine (16 bytes per player, the first of them the number of men left).

7. The rules of the race

Not a bug: the barrel on the ladder. A play report said that a Mario jumped over a barrel, reached a ladder and died anyway. The agent first checked jumps and landings next to every ladder of the lower floors with no barrels on the board: 216 jumps, no death. Then a scripted run (walk right, jump the barrels, climb the ladder) on the original cartridge died on that ladder too. The write-watch on the death sound showed what hit Mario: a barrel coming down that ladder, 10 lines above him. Barrels roll down ladders onto Marios in the original; the 4-player deaths there were the same. The hit boxes are the original's.
The bonus timer. Another death with nothing nearby was the bonus timer: at 0 it killed every Mario at once. That is the original's rule for one player, but in a four-player race it looks like a bug. Since b0031 nobody dies of the timer. The project's own description of the game had already said so before; it was wrong until then.

8. Drawing four Marios: three attempts

The original Mario uses three of the four hardware players and three missiles. Four Marios on the same scanlines leave each of them one player and one missile. The pictures in this section show the bottom floor after the same joystick input in each build: the Marios walk right for different lengths of time, then stop.

Close-up of the bottom floor in the original game: the blue oil drum with flames on the left and one Mario to its right, in red, blue and skin colours.
The original Mario: three players (red, blue, skin) and three missiles.

One colour each (b0005–b0010)

In the first version each Mario was one player, and the original's three colour layers were merged into one 8-pixel-wide shape in a single colour. It worked, but the Marios were single-colour shapes, and the next request was for full-colour Marios, possibly multiplexed with flicker.

Close-up of the bottom floor in build 0010: four single-colour Mario silhouettes in a row, red-brown next to the oil drum, then green, blue and yellow.
Build 0010: four Marios, one player each, one colour each.

A flicker multiplexer (b0011–b0020)

The second version drew every Mario as the original's full-colour Mario again (players 0–2 and missiles 0–2, exactly as the original's drawing routine places them, including a one-pixel offset the original's arithmetic leaves when the offset is negative), each player in their own colours. A DLI just above each Mario moved the three players and the missiles to him and set his colours, so Marios at different heights all appeared in the same frame. Marios whose lines overlapped had to take turns: the one not shown for the longest went first. Two overlapping Marios flickered at 30 Hz each, four at 15 Hz.

The player/missile memory was double-buffered: the original's area and a second one at $7800. The main thread drew the next frame into the hidden buffer, only where its Marios had changed, and the VBI flipped the buffers and the DLI event lists. Two bugs on the way: the second buffer was first placed at $4800, inside the new code once it was copied to RAM, and the emulator hung at the first board; and the VBI switched the multiplexer off before the board had started (fixed with a two-step on switch).

Four close-ups of the bottom floor in build 0020, from four consecutive frames. Each shows only one full-colour Mario: first a white and red one on the right, then a red and blue one near the oil drum, then a green and blue one, then a yellow and purple one.
Build 0020, four frames in a row: the four Marios overlap in height, so each frame shows only one of them.

The flicker was the expected weak point. The next request was for four Marios at the same time, with some detail, without flicker.

One player and one missile each (b0023–b0030)

The version in use since then rests on a detail of the hardware. ANTIC mode E, the original's screen mode, never shows the fourth playfield colour (COLPF3). GTIA's "fifth player" option (a bit in PRIOR) gives all four missiles that colour. So COLPF3 was set to blue ($86), the colour every Mario shares: shirt, hair and the hammer. Each Mario is now:

All four Marios are shown in every frame, side by side, on any floor.

A pixel diagram in four panels of Mario walking right, 9 pixels wide and 16 rows high. Panel 1: the original Mario in red, blue and skin. Panel 2: the player layer alone, each row in one colour: red cap rows at the top, skin-coloured face rows in the middle, red rows below. Panel 3: the missile layer alone, blue blocks 4 pixels wide on most rows. Panel 4: the two layers together, which look close to the original in panel 1.
How one Mario is built (frame "walk right 1", player 1's colours, drawn from the build's frame data). From left: the original Mario; the one player, one colour per row; the missile's blue blocks; the two together.

The frames are computed by a generator. For each of the 26 frames it searches the player's 8-pixel window, the missile's width and position, and for each row the player's colour and the two missile bits that reproduce the original best, with a penalty for every colour change (each change costs a DLI). It uses the positions the original really shows (with the one-pixel offset above), keeps the hammer in front and always blue, and gives the walking frames one shared colour layout (cap rows 0–2, skin rows 3–7, the rest in the player's colour), so a step changes no DLI. The result: about 87% of the original's pixels exact, and 1.72 colour changes per frame on average.

Close-up of the bottom floor in build 0038: four Marios in a row at the same time, each with a blue shirt and skin-coloured face: red next to the oil drum, then green, yellow and white.
Build 0038: four Marios in the same frame, one player and one missile each.

The work is split three ways:

The sliding playfield (b0027–b0029). With several Marios redrawn in one frame, the VBI's added work ran past the start of the next frame. The original VBI restarts the display list late in its code, so ANTIC started the screen late, and for one frame the whole playfield slid 8–42 lines down under the players: the colour bands and the girders moved, the Marios did not. It was found with debug builds (one recorded the scanline at the end of the VBI, another logged the DLIs) and by measuring the girder rows in screenshots, and fixed by splitting the VBI work into the quick early part and the late part above (b0030): the shapes are drawn after the display list restart.

9. Colour changes on the right line

The next play report said the Marios in the game looked squished compared with the frames in the sprite editor (section 13). The editor showed the right frames; the game drew them wrong. From b0023 to b0032 every colour change came one row late.

The reason is timing. In a mode E line, ANTIC's screen fetches and memory refresh leave the CPU about 59 of the line's 114 cycles. A DLI arrives at about cycle 8 of its line, and the STA WSYNC that waits for the horizontal blank must come before about cycle 105, or the CPU waits for the end of the next line. That leaves about 47 CPU cycles, and the NMI plus the operating system's dispatch take 18 of them. The first DLI loaded five colours before its STA WSYNC and got there too late. The fix took five builds:

BuildChangeResult
b0033The next event's colours prepared by the previous DLI; three registers loaded before WSYNCstill one line late
b0034Only A and X loaded before WSYNCon time; but a new pixel test found 75 of 4,628 checked pixels wrong: an event two lines after another lost its colours
b0035Every event is its own piece of DLI code, with its colours as immediate operands; each event points the DLI vector at the next event's code16 cycles to WSYNC; the five writes in the horizontal blank; done before the next DLI. Left: 58 of 4,314 pixels wrong, all from changes one line after another Mario's, which were merged into the earlier event (one row early)
b0036Two-line events: a change one line after an event goes into the event's second half, which waits for a second WSYNC and writes all five colours again76 bytes per event, 3.6K for the 48 events; the emulator hung (see section 15)
b0037The hang fixed0 of 5,102 and 0 of 9,088 pixels wrong; in longer runs (1,500 frames per board) 6 of 12,347 one row off, where three changes fall on consecutive lines

b0034 failed in a different way: its DLI fetched the next event after the colour writes, about 98 cycles of work, and still ran when the next DLI came two lines later. NMIs are not masked, so the second DLI ran inside the first; one event was repeated and the next lost. In b0035 each event needs no fetching at all, because the main thread writes the colours straight into the event's code, which is possible because the new code runs from RAM. One event, in its one-line form (simplified):

EVENT:  pha                 ; (the NMI and the OS dispatch: 18 cycles)
        txa
        pha
        lda  #c0            ; the colours are operands: the main thread
        ldx  #c1            ; writes them when it builds the event list
        sta  WSYNC          ; 16 cycles in: well before the deadline
        sta  COLPM0         ; the writes land in the horizontal blank
        stx  COLPM1
        lda  #c2
        sta  COLPM2
        lda  #c3
        sta  COLPM3
        lda  #pf2
        sta  COLPF2         ; board 0's own colour change
        ...                 ; (two-line events: a second WSYNC, five more writes)
        lda  #<NEXT         ; the next event's code
        sta  VDSLST
        lda  #>NEXT
        sta  VDSLST+1
        pla
        tax
        pla
        rti

10. Scoreboard and title

The original's scoreboard has room for one player. A four-player scoreboard needs room on every board, so the free areas were measured over 4,000 frames per board, including the "HELP!" text (Pauline moves only on the rivet board, between x 44 and 96). Free on every board: x 0–39 on lines 0–23 (on the elevator board Donkey Kong starts at line 24), x 124–159 on lines 0–14, and x 136–159 on lines 15–27 (board 3's "HELP!" reaches x 135). The first layout cleared part of Pauline, and a later one overlapped board 3's "HELP!"; the final one:

Lines of the cartridge's 6-line characters placed 6 lines apart touched each other. The scoreboard therefore uses 5-line characters, made from the cartridge's own font without its row 2 (and the "6" without row 1), only on the boards; the title keeps the original characters. The original's life icons are no longer drawn.

Close-up of the top of the rivet board: on the left the player numbers 1 to 4 one above the other, a score of 300 next to player 1 and a 2 for the men in reserve of each player; in the middle Donkey Kong and Pauline with HELP!; on the right HI 300, L1 BONUS and 4500.
The scoreboard on the rivet board.

On the title screen, SELECT now chooses 1, 2, 3 or 4 players ("SELECT FOUR PLAYER GAME"; the original offered a two-player game), OPTION picks the difficulty as in the original, and START plays. A version line was added.

The title screen of build 0007: the DONKEY KONG logo, below it a line that starts with SEL, followed by garbled characters, zeros and PLAYER GAME, then PRESS OPTION TO PICK DIFFICULTY, PRESS START TO PLAY and 4-PLAYER V0.1 B0007.
Build 0007: the new SELECT line came out garbled (fixed in the next build).
The title screen of build 0038: 1UP and HI SCORE at the top, the DONKEY KONG logo, SELECT FOUR PLAYER GAME, a barrel, PRESS OPTION TO PICK DIFFICULTY, PRESS START TO PLAY and 4-PLAYER V0.1 B0038.
Build 0038 with four players selected.

11. The music, the death jingle and the chest beat

Four of the play reports during development were about sound. All four go back to one difference from the original: the original stops the board when Mario dies, and the 4-player game does not.

"The music stopped" (b0021–b0022)

All tunes play from one buffer at $1C00. The board's song is unpacked there, and so is the death jingle when Mario dies. The original reloads the song at every new life; in the 4-player game the board goes on after a death, so from the first death on the tune played the jingle's data, with the jingle's noise distortions on the tune's notes. Measured before the fix: after one death, the tune's channel sounded noise in 329 of 700 frames. The tune was also restarted while a Mario was dying. b0021 and b0022 reloaded the song after the jingle and played the jingle only for the last Mario standing; other deaths made only their bang, and the tune went on.

"A single low note" (b0031)

That bang alone was the "single low note" heard when a Mario died while others were still playing. Since b0031 every death plays the original's bang and then the death jingle; the tunes stop for the jingle and come back two or three frames after it ends. Measured with four random players over 4,000 frames: 12 deaths, 7 jingles (deaths close together share one), and the tune back after each.

"A mystery tone" (b0032)

A tone still sounded while players died. The jingle (288 bytes) was unpacked over the tables the other players' sound effects read (walk, jump, bang: $1C00-$1D1F), so while one Mario died the others' effects played jingle bytes. Now the jingle is unpacked once at power-on into its own buffer at $7800 (the multiplexer's second player/missile area, unused since b0023), and a new hook in the sound engine plays it from there. The tone is gone, and the jingle's notes are identical to the original's.

DONK DONK DONK (b0038)

The last report was a sound like Donkey Kong going "DONK DONK DONK" a few seconds after a player died. That is his chest beat: three beats, each played as the bang, the same sound as a death. On boards 1–3 he beats his chest every 256 frames (about 4.3 seconds); on board 0 when the count of barrels thrown, modulo 8, reaches 6. The original does the same (its beats were measured at frames 181, 868, 1124 and so on), but it freezes Donkey Kong while Mario dies and restarts the board after a death, so the beat never followed a death there. In the 4-player game it came within a few seconds of nearly every death. Since b0038 the chest beat is silent while any player is alive and not dying. He still beats his chest: the animation and the barrel timing are unchanged, and so are the death's bang and the oil drum's.

12. The CPU budget

The original's main loop updates the barrels, fireballs and other objects round-robin with whatever time is left before the next VBI, each at most every second frame. Four Marios take time from that, so the measure used was the objects' update interval: the average number of frames between two updates of the same object (2.0 is the fastest the original allows). A load test measured it with four random players on each board, and a profiler, using the coverage emulator's counters, measured the cycles of each routine.

BuildBoard 0Board 1Board 2Board 3
Original, one player2.132.133.832.13
b0020, flicker multiplexer3.232.146.242.26
b0023, first one-player-one-missile version3.92.28.24.1
b00303.302.185.602.90
b0037/b00383.132.155.532.97

Object update interval in frames, four random players (one for the original). Lower is faster.

In b0023 building the DLI events cost about 4,100 cycles a frame. b0024–b0027 cut it down: events rebuilt only when a frame or line had changed, cached change lists per Mario, a five-way merge, one colour layout for the whole walk, a tuned colour-change penalty in the frame generator, one variable fewer in the per-player swap, and no item checks on board 0. In b0030 the four-Mario display cost about 2,400 cycles a frame (the flicker multiplexer about 3,900), with 2.4–5.9 DLI events per frame. The rest of the 4-player cost is the original's own per-Mario work, run four times (Mario's routine and the object hit checks), and the copying of the players' state (about 1,550 cycles). The Marios' update ran in 92–98% of frames.

13. A sprite editor

A sprite editor was requested and added (b0031), so that the computed four-Mario frames can be changed by hand. It is a web page that works under the same rules as the hardware: each row of a frame is one player row of 8 pixels in one colour (the player's own, skin or blue) plus the two blue blocks of the missile, 1, 2 or 4 pixels wide and at the same place in every row. The original Mario is shown as dots for reference; counters show how close a frame is to the original and how many colour changes (DLIs) it costs; and a preview shows the result in a 4:3 TV picture of the first board, in all four players' colours, with the walk, climb, hammer, jump and death animations. Saved edits replace the computed frames in the next build. The editor has its own test, run in headless Chrome (load, edit, save, reload, reset). In build 0038 all frames are still the computed ones.

14. Automated testing

All tests ran headless: the emulator with dummy video and audio, at turbo speed, on a private control socket, with no windows and without touching any other session's emulator. They used an emulated Atari 800 with Atari's OS-B ROM, and an emulated XL for the XL check.

TestWhat it checks
Source checksThe generated source rebuilds the original cartridge byte for byte; every build checks that each label of the original is still at its original address, and lists the byte ranges that differ from the cartridge.
Write-watchNo write into the program's address space during 4,000 frames on each board (the traps).
Smoke testThe cartridge, the program file and the boot disk boot on an Atari 800 with OS-B, and the cartridge on an XL; a game starts, the board appears and Mario moves.
Event testsSet-ups made by writing RAM through the test mailbox: walking off a girder's end, Mario lands alive; Mario 1's hammer kills Mario 2 next to him, the points go to Mario 1 and the death's bang plays; jumping at a hammer takes it once and it stays on the board; on board 1 over 600 frames Donkey Kong beats his chest twice and no bang plays.
Soak testFour players with random joysticks on each board: the game keeps running; Mario updates and DLI events per frame.
Pixel testFour random players on each board; screenshots taken only after a complete VBI; every player pixel of every Mario that did not move is checked against the colour its row should have.
CPU testsThe objects' update interval per board, and the cycles spent in each routine.
Editor testThe sprite editor in headless Chrome.

Questions about the original's behaviour were answered by running the original cartridge in the same harness: the barrel on the ladder (section 7) and the times of Donkey Kong's chest beats (section 11).

The rivet board in build 0038: blue girders with yellow rivets and yellow ladders, Donkey Kong and Pauline at the top, two hammers, a red Mario and a green Mario at the bottom left, a yellow Mario on a ladder and a white Mario at the top of that ladder.
Board 1 (rivets), random players.
The elevator board in build 0038: red-brown platforms, blue ladders, two elevator shafts, Donkey Kong at the top left, Pauline at the top, springs bouncing on the right, a fireball in the middle, and two Marios at the bottom left, red and green.
Board 2 (elevators), random players.
The conveyor board in build 0038: yellow conveyor belts with pies, blue ladders, an oil drum with flames in the middle, Donkey Kong and Pauline at the top, and four Marios at the lower left: green, yellow and red ones near the left edge and a white one on a ladder.
Board 3 (conveyors and pies), random players.

15. Bugs, including the agent's own

Garbage sprites after a hammer (b0011). Reported from play. With the hammers staying on the board, the pickup test fired on every frame of the rest of the jump: the hammer counter counted up, and every pickup added $11 to Mario's frame number, past the end of the frame tables. Now a Mario who already holds a hammer does not take another; an event test checks it.
Dots at the left edge (b0015). An item drawn into the bitmap at x 154 wrapped its 8 pixels past x 159 into the first byte of the next line (board 2's hat left two dots at the left edge; the original's player 3 had simply been off screen there). Items are now clipped.
A second buffer inside the code (b0011), and a display switched off too early (b0013). See section 8.
The sliding playfield (b0027–b0029) and colours one row late (b0023–b0032). See sections 8 and 9.
Nested DLIs (b0034). Found by the pixel test: a DLI that ran too long was interrupted by the next one, and an event's colours were lost (section 9).
A hang from one register (b0036). Inserting two instructions that clear a variable just before a TAX in the event builder made X zero, so every new event list was written into set 0, while the DLIs were running that set: stray DLI bits, and zero colours in set 1. The emulator hung. Fixed in b0037.
Shared buffers and sounds (b0021–b0038). The death jingle overwrote the song, then the effects' tables; the chest beat followed deaths (section 11).
Smaller ones: the players' colours were overwritten at every board by the original's start-up colour loop (b0006); the title's new SELECT line came out garbled (b0007, fixed in b0008); clearing the player memory in the VBI at the end of a board made the winner vanish until the end animation drew him again (b0017); the description of the game claimed the bonus timer no longer killed before that was true (fixed in b0031); and the notes in the build list lost their dollar-sign addresses to the shell.

16. Timeline and numbers

TimeBuildStep
6 Oct 23:45—Project set up; tools taken over from the Joust 4-Player work
23:47–00:30—Coverage, generated source (byte-identical), the first memory map
7 Oct 00:01–00:09b0001–b0004The original in the 32K 4-player layout; four traps removed
00:19–00:30b0005–b0010Four Marios (one colour each), joysticks 3–4, the new rules, scoreboard, SELECT 1–4 players, version line, test mailbox
00:43–01:08b0011–b0020Full-colour Marios with a flicker multiplexer; hammer grab fix; scoreboard with 5-line characters; the winner in the end animation
07:14–07:16b0021–b0022The music after a death
07:41–08:05b0023–b0030Four Marios at once: one player and one missile each; the CPU cost cut; the sliding playfield fixed
08:43b0031Every death plays the bang and the jingle; the bonus timer kills nobody; the sprite editor
09:02b0032The death jingle in its own buffer (the "mystery tone")
09:05–09:38b0033–b0037Colour changes on the right line; the pixel test
09:48b0038Version 0.1, build 0038: Donkey Kong's chest beat silent while anybody plays
Cartridge32K XEGS bank-switched (type 12): the original's 16K at $8000-$BFFF, patched in place; the new code and data (9,601 bytes, including 3.6K of DLI event code) and 684 bytes of variables at $4000-$682C, leaving about 4K of $4000-$77FF free; the death jingle's buffer at $7800
Source2,065 lines of new assembly in one new module; the generated source of the original, forked, with 90 lines changed (all marked) by recorded patch scripts, at about 35 places
Builds38, every one kept (cartridge, raw ROM, program file, boot disk, and the sources that made it)
Testssource checks, write-watch, smoke (4 boots), event tests, soak and pixel tests on all four boards, CPU tests, editor test

17. Known limits and open questions

18. Lessons

Credits