Look at the subroutine `EnemyMoveGetMaxRowBot` starting at line #9353. On #9414 the data row pointer is set to the enemy's current row. On #9441 it checks if the column to the left is a pole. On #9516 it checks if the column to the right is a pole. Now notice that on #9461 the row pointer is moved to the row below so it can check for a walkable tile (brick or ladder). When the right-side check is done after a left-side check the row pointer will be on the wrong row.

Here it is in C (from my own notes)

    SetCurrentRow1(y);
    if (CURROW1[x] != 0) {
        if (x != 0) {
            if (CURROW1[x-1] == 4) {
                TargetY = y;
                if (y >= PlayerY)
                    return y;
            } else {
                SetCurrentRow1(y+1);
                if (CURROW1[x-1] == 1 || CURROW1[x-1] == 2 || CURROW1[x-1] == 3) {
                    TargetY = y;
                    if (y >= PlayerY)
                        return y;
                }
            }
        }
        if (x < 27) {
            if (CURROW1[x+1] == 4) {
                TargetY = y;
                if (y >= PlayerY)
                    return y;
            } else {
                SetCurrentRow1(y+1);
                if (CURROW1[x+1] == 1 || CURROW1[x+1] == 2 || CURROW1[x+1] == 3) {
                    TargetY = y;
                    if (y >= PlayerY)
                        return y;
                }
            }
        }
    }

The Apple II, Atari 8-bit, Commodore 64, and naturally the VIC-20 versions of the game have this bug since they were all made by Broderbund. But interestingly so does the Hudson Soft NES port. The later Macintosh version, which is otherwise a direct port of the Apple II code, fixed it. The IBM-PC version didn't have this bug because it was rewritten with the memory layout column-ordered instead of row-ordered. But then introduced a similar bug by subtracting when it should be adding.

(edit: I hadn't checked until just now but I'm amused to find that Lode Runner Legacy from 2017 preserved this bug in the classic game mode.)

Just wanted to note: this is in no way the original source code for the game. It's disassembled and commented source code.

Here is the repository owner explaining the process himself: https://github.com/Piddewitt/C64-Game-Source-Code

Nice work and interesting still, but maybe we can correct the title?

This can't be the original source code.

https://github.com/Piddewitt/Loderunner/blob/main/Lode%20Run...

Original source, I imagine, would be very tersely commented, if only to fit in memory / floppy, and would have very short variable and subroutine names, and lots of mess and commented-out lines from experiments.

This looks like a very lovingly done disassembly.

I just went to a talk at Portland Retro Game Festival by the dutch guy that made an official Atari Lode Runner port. He said he found a japanese book that had the C source in it and got the enemy AI from that.

This is pretty cool.

For anyone curious, the draw a circle code in Circle.asm appears to use Bresenham's circle drawing algorithm.

https://www.geeksforgeeks.org/c/bresenhams-circle-drawing-al...

The secret is to draw 1 arc of a 45 degree angle and the reflect it (redraw it with different coordinates).

this is a great remake of the Load Runner follow up, Mad Monks Revenge. it works amazing on a modern macOS!

https://mmr.quarkrobot.com/

I don't think I ever played an actual 'Lode Runner', just Steve Moraff's version (DOS shareware?)

Whatever happened to that guy?

I love how well structured these old 8bit asm games always seem to be.

oh my, they used my favorite solution for the how to draw a circle interview question

Aaaaah it's one 21k assembly file (including data in hex format). Step #1 for anyone trying to port this to another platform will be to split it up into smaller files, no doubt.