BadBoy House, on Mon Jan 23, 2006 9:59 AM, said:
anyway, with regards to going through the breakout code to find out what each line does, where would i be best to look to find out what lines like these do:
HMOVE = $2A
HMCLR = $2B
CXCLR = $2C
CXP0FB = $32
and
LF005: STY WSYNC
LDA ($D0),Y
AND #$0F
AND $EE
STA PF1
thanks in advance
The first group of lines are "equates" that define what and where specific memory locations are. This is really optional, as you can write assembly code that gives the memory address rather than using an equate, *BUT* equates make it a *LOT* easier to understand the code. The locations of those particular memory addresses are fixed, they never change (although they do have "mirrored" locations at other memory addresses that can also be used), and the names used (e.g., "HMOVE") have been agreed upon through long usage and convention, plus whatever they were called by the original designers and in the original documents about what the locations are and how they're used. If you want to know more about those lines, refer to the "Stella Programming Guide":
http://www.atarihq.c...anb/a2600.shtml
- then scroll down to "Technical Files" and it's the third link.
The second group of lines is more difficult to understand. First, you need to know about 6502 assembly code, you can start here:
http://www.6502.org/...502opcodes.html
But it isn't as simple as just looking up what a given memory location and 6502 opcode does, because when you do a disassembly of a ROM image, Distella can convert some of the memory addresses to "English" using the standard equates, but it can't convert the memory addresses for subroutines and variables. You have to study the code carefully to see how specific memory addresses (variables) are being used-- for example, maybe one particular memory address is being used to store the vertical position of a given sprite-- and to figure out what the various subroutines are doing, and either add more equates and disassemble again using the additional equates, or edit the disassembly to add labels and comments, etc.
Note that there are already some commented disassemblies for some games.
I can make some intelligent guesses about the specific code lines you posted:
LF005: STY WSYNC
LDA ($D0),Y
AND #$0F
AND $EE
STA PF1
The first line starts with an address ("LF005", which is a label created by Distella to indicate that this line starts at address $F005), then a 6502 opcode ("STY", which means "store the value of the Y register"), and a memory address ("WSYNC", the equate name for the TIA register that tells the Atari 2600 to "wait for horizontal sync"). So what it's doing is storing the value of the Y register in the location that makes the Atari twiddle its thumbs until the RGB raster beams have reached the right edge of the playfield and need to be swept back to the left edge of the screen to begin drawing the next scan line. This is done to keep the graphics drawing for each scan line all lined up nice and neat.
The second line starts with an opcode ("LDA", meaning "load the accumulator"), then an indexed address ("($D0),Y", meaning "the address that's being pointed to by addresses $D0 and $D1, offset by the value in the Y register"). Based on what the fifth line says, this line is loading the graphics data that will be used for part of the playfield, and the Y index is probably holding either the scan line number or some similar value (e.g., a row number, where each row actually consists of several scan lines).
The third line starts with an opcode ("AND", meaning "perform a logical 'and' with the bits of the value in the accumulator"), then an immediate value ("#$0F", which is the hexadecimal value of the number 15). What this is doing is taking the value in the accumulator-- which is the playfield graphics data that was just loaded in the second line-- and ignoring or "zeroing" the left half of it.
The fourth line starts with an opcode ("AND" again), then an address ("$EE", which is a zero-page address located in the 128 bytes of RAM). What this is doing is taking the value in the accumulator-- the playfield graphics data that just had the left half "wiped out"-- and doing another logical 'and' with the value that's in address $EE.
The fifth line starts with an opcode ("STA", meaning "store the value of the accumulator"), then a memory address ("PF1", the equate name for the "playfield 1" register, which holds part of the playfield data). So this is taking the graphics data that was just processed in the preceding lines, and storing it in one of the playfield registers so that it appears on the screen.
Michael Rideout
1
