Here's the breakdown of size required and CPU cycles for all 3 methods:

INX method: 4 bytes, 8 cycles
TXA method: 5 bytes, 8 cycles
Clean TXA method: 7 bytes, 15 cycles

So the INX method looks best since it's clean, less bytes, and equally as efficient with the CPU.

A nice site I use to look up exact details of instructions is this one:
http://www.obelisk.demon.co.uk/65...

GOOD FIRST POST!!

I'm a latecomer for the nerdy nights stuff, but maybe someone can answer my question(s). Up until this point, I've been using NESASM3 to follow along on the tutorials, but I want to switch over to asm6. I attempt to code the conversion, replacing a few lines of code, but for some reason, I'm getting a solid gray screen when I run the .nes file that was made from asm6. As far as I can tell, I just need to replace the header with the ines header, and use .base directives in the place of .bank. At this point, it's a bit frustrating, so I'd really appreciate it if someone could explain the specific code changes to make.

1) Remove all the .inesxxx stuff and specify your 16-byte ines header at the top like this:

.byte "NES",$1a
.byte $01 ; 1 PRG-ROM block
.byte $01 ; 1 CHR-ROM block
.byte $00 ;
.byte $00 ;
.byte 0,0,0,0,0,0,0,0

2) remove the lines .bank 0, .bank1 and .bank2 (asm6 doesn't use them)

3) replace .org $c000 with: .base $c000

4) remove .org $e000 (you don't really need to make a division here.  If you really want to you can replace .org $e000 with .pad $E000 followed by a .base $E000)

5) replace .org $FFFa with:  .pad $FFFA

5) replace .org $0000 with:  .base $0000

I think those are all the changes I made to get controller.asm to assemble with asm6. 

This fixed everything. Thanks so much. At first, that's all I was going to say, but then I clicked on your nesdev blog, and found a lot more to be thankful for. Looks like some awesome stuff in there!

I'm a noob assembly programmer (and not a professional programmer at all) so I was wondering if the following would screw me in the long run:

While revisiting the controller reading in a graphics test I'm doing, I was also trying to clean it up by looping through the four addresses of four different sprites tiles, but then discovered the INC and DEC instructions. So now, for example, my ReadUp looks like this:

ReadUp:
LDA $4016 ; player 1 - Up
AND #%00000001 ; only look at bit 0
BEQ ReadUpDone ; branch to ReadBDone if button is NOT pressed (0)
; add instructions here to do something when button IS pressed (1)

DEC $0200
DEC $0204
DEC $0208
DEC $020C
ReadUpDone: ; handling this button is done

I've ran through NESASM and it's working. But again, I get a bad feeling like there's something that may come around and bite me later on if I use this on more complicated stuff. Was this a decent way to handle this or was it sloppy?

I'd imagine that when you got to collision detection, this will not be as efficient. But then, I'm a noob as well, and I don't really know what I'm talking about.

I basically use a routine that stores $0200 into sprite_vertical and $0203 into_sprite horizontal. Then do all the moving, collision detection and all the with these variables. That way you can loop all the enemies and stuff through without having to write the same code for them. At the end, you just reverse the process putting the sprite_--- into the addresses then updating the other 3 sprites with reference to that one.

Make sense?

But if your way works, run with it. You have to figure out your own style.

Speak of the devil!  Collision detection is actually what I'm starting on with this latest test right now! 

Are these routines working well for you on the collision detection?  And if so (forgive me if this is massively inappropriate - like I said I'm a noob) would you mind pasting some example code?  If you'd rather not, I understand.

The problem with just using inc/dec is your movement will be fixed at 1 pixel/frame. Later you will want variable speeds, sub pixel movement, etc. But for now its just fine.

See the second demo in this thread (in the original post).

http://www.nintendoage.com/forum/messageview.cfm?catid=22&am...

I have this for all four directions, this is for the Up botton:

  LDA $0200       ; load sprite Y position
  SEC             ; make sure the carry flag is clear
  SBC #Speed       ; A = A + the variable  
  STA $0200

  JSR transfer_nightman_info ;transfers the $0200 and $0203 into the variables

  JSR top_wall_collision   ;checks to see if he has hit the top wall, then sends it to the various room detections

  LDA #room_change    ;for room changes skip the next part
  BEQ AnimationupCounter

  JSR update_nightman_sprites

top_wall_collision:    ; This is for all four directions

  LDY #$00
  STY room_change

  LDA sprite_vertical
  CMP #top_wall    ;check location
  BCS .done        ;jump to code for inside the L/R door frames

  LDX door_status  ;see if the doors are open
  CPX #$01
  BEQ .doorclosed  ;either jump to the top wall collsion or enter the door

  TAY
  LDA banks_and_doors    ;enter the door/active room switching
  AND #%10000000   ;see if there is a door in this direction
  BEQ .doorclosed

  LDX sprite_horizontal                ;see if he is in the door frame
  CPX #vertical_door_right+2
  BCS .doorclosed
  CPX #vertical_door_left-2
  BCC .doorclosed
 
  LDX #vertical_door_left+2    ;this is so the dumb ass doesn't run into said door frame.
  STX sprite_horizontal

  TYA
  CMP #top_exit       ;see if he is at the top yet
  BCS .done2
 
  JSR exit_on_top
  LDY #$01
  STY room_change
  RTS

.doorclosed:
  LDA #top_wall   ;if the door is closed or outside the frame, stay below the wall
  STA sprite_vertical
  JSR direction_change
  JMP .done2

.done              ;doors open routine
  LDX door_status  ;see if the doors are open
  CPX #$01
  BEQ .done1

  CMP #horizontal_door_top    ;this is for if he is in the door frame
  BCS .done1                  ;see if he is at the top of the door

  LDX sprite_horizontal             ;check left
  CPX #left_wall
  BCC .next

  CPX #right_wall+1     ;check right
  BCC .done1
 
.next
  LDA #horizontal_door_top  ;stay in the door frame
  STA sprite_vertical
  JMP .done2 

.done1             ;load info for which direction to use
  LDX #$00
  STX collide_direction
  JSR collision_detection  ;indirect jump to collision detection
 
.done2
  RTS

collision_detection:   ;indirect jumping for collision detection
  JMP [collideptr]          ;the collideptr is set to collide0 in the room loading routine

collision0:
  .word up_collide0,down_collide0,right_collide0,left_collide0

collide0:
  LDX collide_direction  ;$00=up, $02=down, $04=right, $06=left
  LDY collision0,X
  STY collideptr2
  LDY collision0+1,X
  STY collideptr2+1

  JMP [collideptr2]

up_collide0:

  LDA sprite_vertical
  LDX sprite_horizontal  ;top pipe on right side of the screen
  CPX #$7F
  BCC .done
  CPX #$C8
  BCS .done
  CMP #$70
  BCC .done
  CMP #$78
  BCS .done
  LDA #$78
  STA sprite_vertical
  JSR direction_change
  JMP .dones

.done
  CPX #$68  ; bottom of the engine
  BCS .done1
  CMP #$AF
  BCS .done1
  CMP #$A0
  BCC .done1
  LDA #$AF
  STA sprite_vertical
  JSR direction_change
  JMP .dones

.done1
  CPX #$78  ;very top piece of pipe
  BCS .done2
  CMP #$67
  BCS .done2
  LDA #$67
  STA sprite_vertical
  JSR direction_change
  JMP .dones

.done2
  CPX #$7F  ;bottom pipe on right side of the screen
  BCC .done3
  CPX #$C8
  BCS .done3
  CMP #$B0
  BCC .done3
  CMP #$B8
  BCS .done3
  LDA #$B8
  STA sprite_vertical
  JSR direction_change
  JMP .dones

.done3
  CPX #$68  ;get around the top corner of the engine
  BCC .done4
  CPX #$6E
  BCS .done4
  CMP #$A7
  BCC .done4
  CMP #$AE
  BCS .done4
  INC sprite_horizontal
  JMP .dones

.done4
  CPX #$C8
  BCC .done5
  CPX #$CE
  BCS .done5
  CMP #$6D  ;Get around the top pipe tip.
  BCC .next
  CMP #$78
  BCC .next1
.next
  CMP #$AD  ;get around the bottom pipe tip
  BCC .done5
  CMP #$B8
  BCS .done5
.next1
  INC sprite_horizontal
  JMP .dones

.done5
  CMP #$68    ;move around the top elbow
  BCC .done6
  CMP #$78
  BCS .done6
  CPX #$74
  BCC .done6
  CPX #$80
  BCS .done6
  DEC sprite_horizontal
  JMP .dones

.done6
.dones
  RTS

Nice.  I thought you said you were a noob!  This is way far ahead of anything I'm doing!  :-)  Of course, I've also only been playing around with all this for about two weeks.  I mean, I am a NOOB!

Anyway, thanks for the guidance!  This NES Homebrew stuff is so awesome!

One technique you can use to clean things up is to separate controller reading from input handling.  Week 7 talks about how to do this.

Another thing you can do is instead of treating each of those 4 sprites as individuals, is to wrap them in a "metasprite".  A metasprite will be a data type that you create to organize objects that are made up of more than one sprite.  Your metasprite will have its own pair of X/Y coordinates, and pressing up for example will decrement the metasprite's Y coordinate (1 subtraction), rather than doing each of the pieces individually (4 subtractions).  Then, in your metasprite handling code you set the X/Y coords of the individual pieces to values relative to the metasprite's X/Y.

This separation makes things cleaner when your program becomes large.  Instead of having to keep track of 64 sprites that can go all over the place you are instead dealing with a handful of metasprites.  Each metasprite will be in charge of setting the values for each of its own individual sprites.  And the individual sprites themselves are effectively hidden from the rest of the program - only their parent metasprite touches them.

Thanks MetalSlime.  I've been reading the word "metasprite" dropped here and there on the forums recently.  But only now after reading your description do I understand what they actually are.

I'm confused, however, as to how one goes about coding something like that.  Is it done perhaps by storing the cooresponding addresses in a db directive?  For example, say we have a 4tile x 4tile metasprite:

Metasprite1y:
  db. $0200, $0204, $0208, $020C
..then when I want to move it UP...
  INC Metasprite1y
?

Or can those addresses be grouped together in a constant or variable?  I'm just getting my feet went on directives and am having a really hard time finding out exactly what they do.  For example, I'm still completely clueless on what .word does (or .dw, which I understand is the same thing from reading the NESASM usage doc).  As for constants or variables, I'm kind exploring the different uses of those, as well, testing out different things and seeing what makes the assembler yell at me.  :-)

Here is an example of how to code the metasprite updates:

update_enemy1_sprites:
LDA sprite_vertical
STA $0214 ; save sprite Y position
STA $0218
CLC
ADC #$08
STA $021C
STA $0220

LDA sprite_horizontal
STA $0217 ; load sprite X position
STA $021F
CLC
ADC #$08
STA $021B
STA $0223
RTS

The way your doing it doesn't mean anything.  What MetalSlime meant is that you transfer $0214 and $0217 to the variables above, then run your moving and collision detection ON the variables, then run something like above.  You can't update them like you're doing there.

.db is for numbers, .word is for addresses.  MetalSlime goes through this in his sound tutorials.  i.e.

  .db $01, $02, $09, $FF, etc.

  .word $0217, $0218, $02FF, etc.

or you can use variables or constants defined in your zerospace in these tables or pretty much anything you want. 

Thanks again, m-RIGHT-n.  That was very helpful.  Just thought about it and rushed here to correct.  Looks like you beet me to it.  :-)

Fuck MLN. I'm mRn...recognize.  

DOn't talk bad about Vito like that..

I realise that this is an old (if bloody excellent) tutorial, but I wondered what (if any) significance the other 7 bits have, in reading from $4016 each time? Are they just random noise? Seems strange to transmit only one bit of data each time, when the whole controller could be mapped to one byte. Also, if I had a button pressed and let go before that button state was passed to the processor, would there be some lag in value?

Doh! Reread it. That's what the latch is for. So, if I let go it won't matter as the bit will already be set and I won't lose the fact that a button was pressed. However, if you are familiar with real sized projects, just how often can this call be made to the controller, given a typical load of other code? That is, what is a likely frequency of checking the controller status per second?

It's good practice to also check the 2nd bit (D1) because Famicom external controllers use it. The other bits are not really very useful for normal stuff (they go to the expansion port however). Bits D8-D5 are not connected at all and will return whatever value was previously on the data line (unless the cart has resistors on the data lines like the PowerPak).

Most (probably ~all) games check the controller once per frame, so 60Hz on NTSC, 50Hz on PAL. Well, actually games that use DPCM check it multiple times per frame because NTSC CPU has a bug where it will corrupt the controller bits sometimes when DPCM samples are playing.

So, if I only wanted to check A, I would rewrite $0100 to $4016 and that would reset the shift register so a read would take the A button? That right?

Yes.

I have another problem. I wanted to add some more sprites but i cant put more than 8 sprites on the screen. Is this because of the NES limits or is something wrong with my code?