Originally posted by: KHAN Games

You're only storing a variable that keeps track of where on the table you currently are.

I'm not sure how you're doing controller reads, but I'll post code here like is described in one of the later nerdy nights tutorials, week 7, as "Better Controller Reading."

Buttons: .rs 1 ;current button presses
MovementTimer: .rs 1 ;timer that needs to be reached in order for movement to begin
ShipDirection: .rs 1 ;current position on our lookup table for the ship direction

MoveShip:
  LDA Buttons ;load buttons variable
  AND #%00100000 ;only keep Left bit
  BEQ .TryRight ;if Left isn't held, branch to try Right
;;left is held
  INC MovementTimer ;increment movement timer
  LDA MovementTimer ;load increment timer
  CMP #$xx ;compare to whatever value you want
  BCC .End ;if it's less than this, go to end
  DEC ShipDirection ;decrement ship direction x2
  DEC ShipDirection
  LDA ShipDirection ;check to see if ShipDirection has wrapped around the table
  CMP #$FE
  BNE .Rotate ;if it hasn't jump to Rotate
  LDA #$0E
  STA ShipDirection ;reset ShipDirection to the highest starting value (you'll change this number when you add more directions to your table)
  JMP .Rotate ;jump to Rotate
.TryRight:
  LDA Buttons ;load buttons variable
  AND #%00010000 ;only keep Right bit
  BEQ .Reset ;if Right isn't held, branch to Reset to reset the MovementTimer variable since button isn't pressed
;;right is held
  INC MovementTimer ;increment movement timer
  LDA MovementTimer ;load increment timer
  CMP #$xx ;compare to whatever value you want
  BCC .End ;if it's less than this, go to end
  INC ShipDirection ;increment ship direction x2
  INC ShipDirection
  LDA ShipDirection ;check to see if ShipDirection has wrapped around the table
  CMP #$10
  BNE .Rotate ;if it hasn't, jump to Rotate
  LDA #$00
  STA ShipDirection ;reset ShipDirection to the lowest starting value
.Rotate:
  LDY ShipDirection ;load ShipDirection in the Y register
  LDA ShipLookupTable,y ;look at the sprite for the current direction using the Y register as the offset
  STA $0201 ;store
  LDA ShipLookupTable+1,y ;look at the attribute data for this direction
  STA $0202 ;store
  JMP .Reset ;reset MovementTimer
.End:
  RTS
.Reset:
  LDA #$00 ;reset the timer if Left or Right isn't pressed
  STA MovementTimer
  RTS

ShipLookupTable:
  .db $00,$00 ;up
  .db $02,%01000000 ;up/right
  .db $01,%01000000 ;right
  .db $02,%11000000 ;down/right
  .db $00,%10000000 ;down
  .db $02;%01000000 ;down/left
  .db $01,$00 ;left
  .db $02,$00 ;up/left

A better solution would probably be to move the Rotate part of the subroutine to its own subroutine that's constantly called so that when you implement de-accelaration (making the ship slowly stop spinning when you release the button) it isn't requiring a button press to set the current direction.

This should get you started though. Let me know if anything doesn't make sense.

Originally posted by: KHAN Games

Sorry that I wasn't more clear.

1.) The .rs 1 variables are simply declaring them as variables in zero page. The default value is zero I guess, since your clearmem routine is zeroing out everything upon bootup initalization. .rs 1 is simply reserving a byte of RAM for a variable called whatever we do a .rs 1 for. Your assessment is correct. Setting it to ShipDirection = #$01 would make that variable be 1 the entire game (a constant). Reserving a byte of memory allows us to change the value to anything we want at any time.

2.) When we're looking at the table I typed out (ShipLookupTable), we can see there are 16 values (two per direction. One for sprite, and one for attribute byte). If, for example, the ship is facing up, ShipDirection would be $00 since it's at the first value of the table. If we're still turning left, it would decrement that value twice. If we decrement $00 twice, it would be $FE, which has wrapped off the bottom of the table, so we want to instead set it to the highest first-byte value of our table, which is $0E (the sprite of up/left). The same thing applies in the opposite direction. If the ship is facing up/left and we continue to press the Right direction, it will increment ShipDirection twice, which would put the value at $10, which is higher (more values) than our table goes. We want to wrap it back to the lowest first-byte of the table, which is $00.

ShipLookupTable: (the following numbers are just POSITIONS. Not values. The red text doesn't really exist in the table, but the increment/decrement code will get there when you're inc/dec past where there are values, hence the need to reset back onto the table)
$FE,$FF; if you've decremented down to this point, you've wrapped off table. reset back to $0E
$00,$01
$02,$03
$04,$05
$06,$07
$08,$09
$0A,$0B
$0C,$0D
$0E,$0F
$10,$11; if you've incremented up to this point, you've wrapped off table. reset back to $00

3.) All of the .rs values go at the top before bank zero. This is called zero page. The MoveShip subroutine (which includes a .Reset local subroutine) can go anywhere in any bank. The ShipLocation table can also go anywhere, assuming you are using a mapper that doesn't bankswitch.

4.) As mentioned in my post, Buttons gets populated through a subroutine detailed in Nerdy Nights week 7, labeled "Better Controller Reading." You don't have to use it. I was just using it to more simply illustrate the button presses (but I would recommend learning to use it, as it's how I still read controllers to this day).

Originally posted by: KHAN Games

ShipLookupTable: ;values
  .db $00,$00 ;up
  .db $02,%01000000 ;up/right
  .db $01,%01000000 ;right
  .db $02,%11000000 ;down/right
  .db $00,%10000000 ;down
  .db $02;%01000000 ;down/left
  .db $01,$00 ;left
  .db $02,$00 ;up/left

ShipLookupTable: ;positions (not actually in the game code. just writing for clarity's sake)
  .db $00,$01 ;up
  .db $02,$03 ;up/right
  .db $04,$05 ;right
  .db $06,$07 ;down/right
  .db $08,$09 ;down
  .db $0A,$0B ;down/left
  .db $0C,$0D ;left
  .db $0E,$0F ;up/left

If we load ShipLookupTable, it will be looking at the first value under ShipLookupTable. Position 0. The value just happens to also be $00. Bad example.

The way I'm looking up ShipLookupTable in the code I sent a few posts ago, I'm offsetting that by Y.

LDA ShipLookupTable,y

What this means is look up ShipLookupTable+y.

In this code, we are setting ShipDirection to Y and using that to tell us where in the table we want to use the values from.

So let's say ShipDirection is $06 and we load that into Y and then we LDA ShipLookupTable,y. That would be looking at the 6th position in the table. If we look at our positions table (which I've just written for clarity's sake and wouldn't actually be in the game code) we can see that is the first value of down/right, which is actually $02 if we look in the actual ShipDirection table. LDA ShipLookupTable,y would be $02.

LDA ShipLookupTable+1,y will load the value AFTER ShipLookupTable,y, because Y doesn't change. That would be looking at position 7, which is the palette attribute byte of down/right, which is %11000000.

So everything is basically automatic in the code I wrote. You're pressing a direction, it's running a delay timer so that it is facing a single direction for more than a single frame, then it's incrementing or decrementing ShipDirection by 2 to get to the next row of values in the table and using those values to 1) store the sprite tile and 2) store the sprite attribute byte.

No idea if you already understood this stuff, but it sounded like you might need more explanation on it so I tried to break it down more. If there's anything specific you're struggling with please let me know.

Originally posted by: KHAN Games

Thanks.   Sounds like you're fully understanding things now. That's awesome!

Originally posted by: oleSchool

1.) Is buttons2 being populated with a byte of correct values?
 

Originally posted by: KHAN Games
 
I don't know how to do the other two things you're asking, as I'm pretty crappy with using the Debugger myself. But for this you just need to open the Hex editor in FCEUX (or Mesen) and look at the $0200-$02FF addresses. You can see what values all your sprites have for all their bytes. The addresses you gave for sprite 2 are wrong though (you gave the tile/attribute for sprite one, but v pos and tile for sprite two)

And you can look in the $0000-00FF area for your zero page variable values (like Buttons and Buttons2), but you have to count how many reserved bytes you've used ahead of these variables in order to narrow down exactly which byte to look at for each variable. (ie: the first zero page variable would be $0000, the second $0001, assuming they are all a single byte).

I can show you how to use the Debugger to break when your Buttons variable is not zero, but other than that I don't know how to step through the AND reads.

Open debugger and click on Add Breakpoint. After you've figured out which address your Buttons variable is, you'll want to type this address in both Address fields. (If you can't deduce which zeropage variable is your Buttons variable, you can open the FCEUX Hex Editor and start pressing directions and a/b. You should see a value jumping around as you press them.)

After you put the address in, you'll want to click on Write and then for condition put A != #0

This is pretty much the extent of my debugging skills.   Good luck!

Originally posted by: KHAN Games

I'm assuming it has to do with how the controller is read or something because when I try to use the same kinda breakpoint on another variable that doesn't have to do with a controller it works fine.

Like I said, I don't know much about using the debugger.

Originally posted by: KHAN Games

Well, looking at the code, in order for the code to work inside NMI after pasting it back in there, you'd have to take out more than a single RTS. The NMI needs to get all the way down to RTI no matter what, so your code needs to be modified a little bit. Basically in every spot there is a RTS in MoveShip1, you'll need to delete the RTS and instead JMP to MoveShip2, so the second ship's routine is read. Then every place there is a RTS in MoveShip2, you'll need to delete the RTS and instead JMP to the end of MoveShip2 (after the RTS after .Reset2) so that it arrives at RTI.

Writing it the way you have it currently written (moving the routines out of NMI and just JSR'ing to them) is way cleaner/easier due to the ability to use the RTS in the individual subroutines. Jumping back to the main NMI this way allows you to not have to keep track of all the weird flow of things.

Right now, if it hits an RTS inside of NMI without having to go through a JSR to get there, it is returning to god knows where and it will behave erratically. I'm surprised it worked at all, honestly.