RAM bits info for Atari 2600 games

[ankesh]

Hi,

 

I am using the Atari 2600 games for AI research, and was wondering if people here know if there's a resource that maps the information stored in RAM bits to semantic info (such as location 76 corresponds to character's x location etc.) for different games.

This info would be useful for us in accessing ground truth prediction capabilities of an AI agent.

 

Thanks,

[+SpiceWare]

You can find the Stella Programmers Guide and the memory maps at MiniDig.

 

The 2600 is unlike other consoles, registers do not exist for the X and Y locations of the moveable objects. There are 5 moveable objects: 2 players, 2 missiles, and 1 ball.

 

TIA, the video chip, is scanline based, so it's up to the program to keep track of Y.

 

For the X location the program has to strobe the RESxx registers at the correct time to set a coarse horizontal position based on where the electron beam is at on the TV. After that the HMxx registers are used along with HMOVE to adjust the coarse position to the final position.

 

Values for xx are:

• P0 - Player 0
• P1 = Player 1
• M0 = Missile 0
• M1 = Missle 1
• BL = Ball

Player = sprite in modern terminology. Missiles and ball are also sprites, but only a single pixel per scanline.

 

Games will use RAM to keep track of the X and Y locations, which specific RAM locations will depend upon the game. Additionally, some of the earlier games like Combat don't actually keep track of the X position, they just set the tanks to a known position at the start of each game, then use the HMxx registers to move them left/right as needed.

 

I've done a tutorial, Collect, that might aid you in understating how the 2600 works.

[AkashicRecord]

I'd say that there are plenty. There are a bunch of disassemblies around here by Dennis Debro, Thomas Jentzsch, and others. Check the Atari 2600 Programming subforum.

 

One thing however, is that there is NO positioning for Atari 2600 objects in the sense that you are going to expect.

 

Horizontal positioning is strictly related to CPU cycles in sync with the scanning of the electron beam, with a fine-positioning function for adjustment up to 7 or 8 pixels +/-, and the vertical aspect is related to scanline number...and this depends further on the granularity (in whole scanlines) of a particular display kernel...and there can be many "kernels" in a single program...

[BigO]

I only have a passing knowledge of this,but it almost seems like you'd have to use at least a subset of an emulator to calculate an x/y representation of game elements.

 

Does Stella expose anything that would make this exercise more feasible?

[ankesh]

 

 

Games will use RAM to keep track of the X and Y locations, which specific RAM locations will depend upon the game.

Exactly, I am wondering if the description of RAM states for each game are documented somewhere. I found for some games (Montezuma's revenge for example) people just played around and inspected the RAM (https://i.imgur.com/YL8ZwHQ.png),fig from the paper https://arxiv.org/pdf/1611.04717.pdf

 

 

 

Check the Atari 2600 Programming subforum.

Thanks, I cross-posted there as well!

[+SpiceWare]

Besides the aforementioned documentation, MiniDig has some disassemblies.

 

This discussion in the programming forum has links to many other disassemblies, just have to read thru the topic to see what's available. If you're unable to find what you're looking for I'd suggest adding a reply to this topic to ask for the game(s) you're interested in.

[ankesh]

@SpiceWare, that's great thanks, this is very close to what I was looking for! I also found some disassemblies at http://www.bjars.com/disassemblies.html, do you know of any other resource that lists 2600 disassemblies, if not I can try posting on the thread later!

[ankesh]

It seems very few games have the RAM variable map though, do you know if it's easy to get that info through a debugger?

[+SpiceWare]

Some are just a disassembly without any additional work done to figure out the RAM usage. Others, like mine for Warlords, will have figured most of it out:

;------- RAM USAGE -------
                      ; $80 - not used
                      ; $81 - not used
Player1X              = $82
Player2X              = $83
BallX                 = $84
Player3X              = $85
Player4X              = $86
Player3Xprecalc       = $87 ; precalculated during Vertical Blank, used to position both players using same scan line
Player4Xprecalc       = $88 ; precalculated during Vertical Blank, used to position both players using same scan line
Player1Y              = $89        ; $54(84) = topmost position, $3C(60) = bottom   24
Player2Y              = $8A        ; $54 = topmost position, $3C = bottom
BallControl           = $8B ; VH--???? 
                            ; V = Vertical direction   0=up    1=down
                            ; H = Horizontal direction 0=right 1=left
                            ; ???? - lower nybble is used for something not yet deciphered

---

 

I'm not familiar with other 2600 disassembly resources, and had forgotten about bjars.

 

You can use Stella to create a disassembly fairly easily for a 4K game, and with a bit more effort for anything larger. You can also use it to figure out what the different RAM is used for, though that will take a lot of work. To disassemble using Stella you want to load the game, then play it for a while - be sure to try different actions and game variations. You play the game so Stella can analyze how the different parts of the ROM are used. As an example I:

• ran Stella
• loaded Adventure
• played game variation 1
• played game variation 2
• hit the ` key to enter the debugger
• typed savedis in the prompt

which created this disassembly.

Adventure (1980) (Atari).asm

 

 

 

The RAM usage is spelled out like this:

;-----------------------------------------------------------
;      RIOT RAM (zero-page) labels
;-----------------------------------------------------------

ram_80          = $80
ram_81          = $81
ram_82          = $82
ram_83          = $83
ram_84          = $84
...

---

as you analyze the code do a find/replace such as ram_8B/SquareX and ram_8C/SquareY.

 

By letting Stella analyze the code as it runs it can detect when data is used for graphics and thus show it differently in the disassembly. This is regular data:

 

Lf43b
    .byte   $1a,$a4,$01,$1d,$a9,$01,$1d,$ae ; $f43b (*)
    .byte   $01,$1d,$b6,$01,$1d,$bc,$01,$1d ; $f443 (*)
    .byte   $bf,$01,$1d,$c2,$01,$16,$c5,$01 ; $f44b (*)
    .byte   $12,$cb,$01,$1d,$b3,$01,$1d     ; $f453 (*)

---

 

while this is graphic data:

 

   .byte   %00000110 ; |     ## |            $fd3a (G)
    .byte   %00001111 ; |    ####|            $fd3b (G)
    .byte   %11110011 ; |####  ##|            $fd3c (G)
    .byte   %11111110 ; |####### |            $fd3d (G)
    .byte   %00001110 ; |    ### |            $fd3e (G)
    .byte   %00000100 ; |     #  |            $fd3f (G)
    .byte   %00000100 ; |     #  |            $fd40 (G)
    .byte   %00011110 ; |   #### |            $fd41 (G)
    .byte   %00111111 ; |  ######|            $fd42 (G)
    .byte   %01111111 ; | #######|            $fd43 (G)
    .byte   %11100011 ; |###   ##|            $fd44 (G)
    .byte   %11000011 ; |##    ##|            $fd45 (G)
    .byte   %11000011 ; |##    ##|            $fd46 (G)
    .byte   %11000111 ; |##   ###|            $fd47 (G)
    .byte   %11111111 ; |########|            $fd48 (G)
    .byte   %00111100 ; |  ####  |            $fd49 (G)
    .byte   %00001000 ; |    #   |            $fd4a (G)
    .byte   %10001111 ; |#   ####|            $fd4b (G)
    .byte   %11100001 ; |###    #|            $fd4c (G)
    .byte   %00111111 ; |  ######|            $fd4d (G)

---

If you don't play the game Stella won't know the above data was used as graphics, so would output it like this:

    .byte   $02,$3a,$fd,$ff,$4f,$fd,$06,$0f ; $fd34 (*)
    .byte   $f3,$fe,$0e,$04,$04,$1e,$3f,$7f ; $fd3c (*)
    .byte   $e3,$c3,$c3,$c7,$ff,$3c,$08,$8f ; $fd44 (*)
    .byte   $e1,$3f,$00,$80,$40,$26,$1f,$0b ; $fd4c (*)

---

 

This page is documentation for Stella, while this page is for its integrated debugger.