Author Topic: Amstrad CPC Lemmings Data Observations  (Read 155 times)

0 Members and 1 Guest are viewing this topic.

Amstrad CPC Lemmings Data Observations
« on: July 14, 2022, 10:19:01 PM »
I've recently learned how to watch RAM among other things, and I recently tried to use that to better understand the cursor glitch in CPC Lemmings (a quick video of it in case you aren't sure of what I'm talking about: I found out some interesting stuff, including some things that aren't directly related to the glitch, and I thought I would share these. I'll share more as time goes on. This post is 100% inspired by Gronkling's update in the Genesis Lemmings data topic.

At this point, all observations are of the disk release of the game, not the buggier tape release. Values prefixed with a $ are in hexadecimal.


The data for the current level is loaded into RAM from disk starting from address $2470. I don't know exactly where the level data ends, but as far as I can tell, it's only terrain data from very early on all the way to the end.

$2470: Current level's number, starting from 1 at JUST DIG! and counting up 1 by 1 independent of difficulty rank going up to 60 at the last level.

$2471: Total number of lemmings in the level. Capped at 20 ($14) under normal circumstances.

$2472: Minimum release rate. Values above 99 are slower than 1, similar to other versions.

$2473-$2475: Position of the hatch in the level.
Format... (click to show/hide)

$2476: The time (in minutes) - 1 that you have to beat the level. $00 would correspond to 1 minute, $01 to 2, etc.

$2477-$247E: The number of each skill, in the standard order.


$2480: Save requirement.

$2481-$2483: Position of the exit in the level. Format is identical to the hatch data.

$2484: UNKNOWN

$2485-$24A4: Current level's title in ASCII, starting from the very left side of the screen going to the very right. The SPACE character is used to center the text.

$2485 onwards: Seems to be all terrain data, with each byte corresponding to two adjacent pixels.

Addresses near $0000 in RAM appear to be used as video memory of sorts? I would not know the full details on that. Higher up on the screen corresponds to a lower RAM address. When the cursor glitch is performed, the cursor is forced past the top of the screen and its graphics data underflows to ~$4000 in RAM, which is right in the middle of terrain data. This corrupts the terrain data, and when you move the cursor's ghost image to the very top of the screen, it then affects the other level data sitting above the terrain data in RAM, and now that I know what all is stored right there with the level, the effects of the cursor glitch make a lot more sense. A lot of weird effects are due to data about the lemmings themselves overflowing into other data in RAM, since there are way more in the level than are normally supposed to be there. Speaking of...


The lemmings' data is split into 17-byte chunks (yes, 17!) for each lemming. The data starts at address $F540.

BYTE 1: Lower 5 bits are the lemming's current state. Upper 3 bits used for flags.
States... (click to show/hide)
Flags... (click to show/hide)

BYTE 2: UNKNOWN, set to $FF on every single frame that the lemming exists and never seems to get overwritten.

BYTE 3: X-position relative to the camera

BYTES 4-5: X-position relative to level. Byte 4 is the low byte and byte 5 is the high byte.

BYTE 6: Y-position. A value of above $7F instantly kills the lemming. A value below ~$10 may cause the lemming's graphics to corrupt the terrain data, much like the cursor glitch, but won't kill the lemming.

BYTES 7-8: Cursor offset for lemming lock-on feature. Byte 7 is x and 8 is y.

BYTE 9: Direction. $00 (and all even numbers) means left and $FF (and all odd numbers) means right.

BYTE 10: Builder bricks remaining.

BYTES 11-12: Bomber countdown timer. Byte 11 is set to 13 and decrements every physics cycle, while byte 12 is set to 5. When byte 11 reaches 0, it is immediately reset to 13, while byte 12 is decremented. Byte 12 reflects the number on screen. When byte 12 reaches 0, the lemming becomes an Oh-noer.

BYTE 13: Fall distance counter.

BYTES 14-17: Determine the animation of the lemming.
Details... (click to show/hide)

It looks like some sort of video memory (or perhaps a mirror of it) sits below this data, which explains the mild graphical glitches when you spawn too many lemmings on the disk version, and why some lemmings seem to disappear, as their data gets overwritten by video data. This is speculation on my part, so please correct me if I'm wrong on that.

I don't know if I'm ready for the tape version ;P
« Last Edit: July 15, 2022, 08:22:12 PM by The Tomato Watcher »

Offline Gronkling

  • Posts: 483
    • View Profile
Re: Amstrad CPC Lemmings Data Observations
« Reply #1 on: July 15, 2022, 01:14:50 AM »
Nice research :thumbsup: I've never really looked into these 8-bit computer versions, but I bet there's some really wacky challenge solutions that can be done seeing how glitchy it seems to be. I've still yet to find a way to crash the genesis version.