I'd probably use my current button history routine in a certain way. Here's the routine:

;****************************************************************
;Deserializes the controller into a buffer.
;output: controller_buffer
;****************************************************************
.proc read_controller

    lda #$01
    sta CONTROLLER
    lda #$00
    sta CONTROLLER

    lda CONTROLLER
    ror
    rol controller_buffer+buttons::_a

    lda CONTROLLER
    ror
    rol controller_buffer+buttons::_b

    lda CONTROLLER
    ror
    rol controller_buffer+buttons::_select

    lda CONTROLLER
    ror
    rol controller_buffer+buttons::_start

    lda CONTROLLER
    ror
    rol controller_buffer+buttons::_up

    lda CONTROLLER
    ror
    rol controller_buffer+buttons::_down

    lda CONTROLLER
    ror
    rol controller_buffer+buttons::_left

    lda CONTROLLER
    ror
    rol controller_buffer+buttons::_right

    rts

.endproc

What it does is record the last 8 states of every button in each byte of controller_buffer (which has reserved 8 bytes, one byte for each button). So, if someone JUST pressed a button, you can do this:

lda controller_buffer+buttons::_a
and #%00000011  ;only care about the current and previous state
cmp #%00000001 ;since we're now only looking at the most recent two bits, if the last bit was 0, and the current bit was 1, we now know the user JUST pressed the button.

If I wanted to detect a double press, I might double up the technique and record a history of actual detected presses, with another buffer like this:

.proc record_a_presses

;TODO: Add code to make recorded presses expire after a certain amount of time by
;rotating a 0 into button_a_pressed_buffer every few frames. this timer would get
;reset any time an actual press has been recorded, too.

lda controller_buffer+buttons::_a
and #%00000011  ;only care about the current and previous state
cmp #%00000001 ;since we're now only looking at the most recent two bits, if the last bit was 0, and the current bit was 1, we now know the user JUST pressed the button.
beq button_not_just_pressed

    ;Store that button a was actually pressed into button_a_pressed_buffer
    lda #1
    ror
    rol button_a_pressed_buffer

button_not_just_pressed:

    rts

.endproc

....I'd call that record_a_presses routine over and over again on each frame (as well as the controller read routine above), and to detect a double tap I would do this:

lda button_a_pressed_buffer
and  #%00000111  ;examine last three states of whether button a was pressed
cmp #%00000011  ;this would mean two presses in a row (ONLY) were recorded
bne double_tap_not_detected

;Do your double tap action here

double_tap_not_detected:


...This might not be quite what you want either, as it may not take timing into consideration. There are other ways you could do it, but I'm fond of the bit history method, as it comes in handy for handling other types of transitions, not just button presses.

*edit* I'm thinking about timing, and you could make the button_a_pressed_buffer expire by rotating an unpressed state into it every few frames or something. Currently it'll detect the last two button presses no matter how much time passes.

Thank you for your reply!  I imagined something like this.  I really appreciate the help.  One thing that is escaping me is the syntax from above, 'lda controller_buffer+buttons::_a'  I have never seen the '::' is that syntax or just part of the variable name?  Sorry still a bit new to this.

 

Assuming you have a variable in ram somewhere called controller_buffer which reserves 8 bytes,

Sorry about that, that's ca65 (an alternative to nesasm) getting a member of a struct out. It's the same thing as if you did something like this in nesasm:
A_OFFSET = 0
B_OFFSET = 1
SELECT_OFFSET = 2
START_OFFSET = 3
UP_OFFSET = 4
DOWN_OFFSET = 5
LEFT_OFFSET = 6
RIGHT_OFFSET = 7

and then to look at the A button it'd just be lda controller_buffer+A_OFFSET.  ca65 has structs which enable you to do the exact same thing but without having to enumerate the equates manually like in nesasm. in ca65, you can do:

.struct buttons
    _a       .byte
    _b       .byte
    _select  .byte
    _start   .byte
    _up      .byte
    _down    .byte
    _left    .byte
    _right   .byte
.endstruct

and then it figures out the offsets for you by their sizes. and then you can pluck out those numbers by going buttons::_a  or buttons::_select  etc. etc.

Perfect! It looked like a struct or an enum but I had never seen it in nesasm. Thanks!

I'm interested in understanding the game mechanics behind the appearance of the "Lizard King" in the NES-game Dragon's Lair. Basically, he appears at "random" in certain spots, but I'd like to know if it's in any way possible to predict/manipulate his appearance.
What I know is that RAM-address $0718 changes to 100 before the LK turns up and starts counting down. Otherwise it's always 0. In the fceux debugger, I've located the line of code that's executed when $0718 changes to 100. This is where I'm stuck. The last lines of executed code copied from the trace logger look like this:

$D769:AD 03 03 LDA $0303 = #$00 A:00 X:00 Y:0C S:FF P:nvUbdIZc
$D76C:4A LSR A:00 X:00 Y:0C S:FF P:nvUbdIZc
$D76D:90 FA BCC $D769 A:00 X:00 Y:0C S:FF P:nvUbdIZc
...
...
...
$D769:AD 03 03 LDA $0303 = #$00 A:00 X:00 Y:0C S:FF P:nvUbdIZc
$D76C:4A LSR A:00 X:00 Y:0C S:FF P:nvUbdIZc
$D76D:90 FA BCC $D769 A:00 X:00 Y:0C S:FF P:nvUbdIZc
$D769:AD 03 03 LDA $0303 = #$00 A:00 X:00 Y:0C S:FF P:nvUbdIZc
'Here the frame advances by one and $0718 gets the value 100.
'The same loop of 3 lines of code are repeated 10 more times before the loop is broken after an execution of $D769 and other lines of code are executed

1. Maybe not related to the appearance of the LK, but is there a plausible explanation for why the game executes the same code over and over in what appears to be an infinite loop? Except for when the LK counter changes, none of the RAM-addresses change during the loop (easily verified with the "RAM search" feature in the emulator) nor do X, Y, A or the flags.
2. What does LSR act on when there are no arguments? The accumulator?
3. Where does $0718 come into the picture here? There is no reference to it and still it changes value all of a sudden?
4. What could be the explanation for breaking the loop? "RAM search" still doesn't indicate any changes to any RAM address and none of X, Y, A or any of the flags change (according to the trace logger).
5. Why is the loop broken after an execution of $D769 (LDA) and not the BCC in $D76D?

Yes, it's me again!  I have been working hard trying to mix MRN's background compression with horizontal screen scrolling, and after 2 weeks I have gotten pretty close.  I am now spinning my wheels as I have stepped through the code, reviewed what I have done and I don't even know what would be causing the glitch that I am getting.  The columns are all drawing prior to getting on screen but there is a bad glitch which I can't explain.  It almost seems like I am writing somewhere I shouldn't in the PPU, but from what I have seen so far I have not.  Now I know that without looking through the code there won't be an answer, but I am hoping by looking at the attached video maybe someone has seen it before and might point me in the correct direction.  I know it's a long shot so if not, no big deal.  

 

The video is below and I have yet to modify the background hit detection to the scrolling so that's why it is not working (that's my next goal after scrolling is fixed).  

https://www.useloom.com/embed/877...

Edit: embedding the video didn't work so just linked

It seems so random. My first thought was are you trying to do too much during your NMI? Without seeing the code, I can't really tell what's all happening during NMI.

Hopefully someone will have a better answer, but I think that may a good first check. I haven't really dealt much with scrolling with BG Compression.

Thank you.  I guess my question then since this is the first time I'm really having to understand NMI, is The act of writing to the PPU what takes a long time or is it just too much going on?  When I go to decompress the meta-tiles in a column, I set the rightmost tiles of the meta-tile (1 & 3) to the PPU and put the other 2 in a buffer for the next time I need a new column to be drawn.  This continues 30 times to get the entire meta-tile column (essentially 2 screen columns) So would the act of writing the tile numbers to a buffer, adding an extra 30 writes, but not to the PPU, be extending this process too long?  You can tell from the previous video, that there isn't a whole lot going on, and I believe I have separated my game logic outside of the NMI routine.  I don't recall how much one can do inside of NMI, but I feel as though this isn't too much, then again I don't really know what I'm talking about when it comes to NMI lol.

 

If you are decompressing outside of the nmi to buffer ram amd just writing the buffer ram to the ppu, then that probably isn't the issue.

That was it, I was loading and writing the new columns in the NMI.  I haven't fixed all of the bugs but the glitch is gone, now that I load outside and write inside.  Now to see what else is wrong now.  Thanks so much!  
 

I have been trying to find a way to get my scrolling engine that I made from MRN background compression tutorials and take it and make it work with his background collision detection tutorials.  In his tutorials he finds the meta tile as it is compared to the location of the player sprite.  It will find the index of the metatile inside the rooms meta tiles.  The first index in the room, index zero is for bank switching so the first meta tile is at index 1 in the room.  So from what I can tell the meta tile at index 45 should be in column 4 row 5.  This all still works unless the player moves and scrolls the screen.  So prior to scrolling the room addresses look and work as they are in the top part of the below picture.  The balloon is pointing at the first index.

My problem is when the screen scrolls to the next meta row and it throws the pointer off, shown by the second example with the balloon marked '2'.  I have not figured out how to solve this problem.  I was thinking that I could still use the index found by his routine and move the index to the next meta tile column (02).  This way the index could be the same just starting from the new pointer.  And if the column part of the index found is greater than the difference of the column at the index given, then I would need to increase the pointer to the next room and add the rows.  I think this would work except the screen scrolls by 8 and the meta tiles are 16 wide, so how do we account for this? 

Has anyone figured out how to keep track of background collision when scrolling using background compression?  Im not looking for a full solution but maybe a different way of thinking that might lead to the answer.  I have been staring at this for a week now and am losing hope lol.  Any help is greatly appreciated.

This is a fun one! I'm sure someone with a better answer will pipe in before I figure out a solution, but thanks for raising the question.

I am watching this as well. Sorry that I don't have an answer for this one. I know that some will.

Shift your bits right until you get the correct index. Say you have the scroll index based on 8px blocks, shift your bits right once (which is the same as dividing by 2), you'll discard the least significant bit (which you don't need since two 8px blocks fit into one 16px block) and get a 16px index.
Usually your scroll offset will be defined to the pixel though, since that's how the PPU uses it, so in that case you'd shift that number right four times (1->2->4->8->16) to get a 16px index. This kind of operation is very common in 8bit assembly programming.
Sorry if I misunderstood your question.

  There's no single correct way to do that, as it completely depends on the way you compress your stages. For crazy compression like SMB, where every part of the stage is generated by algorithms and prefabricated structures, you'd have to decompress your stages data and copy the result into RAM, and read from that instead of ROM data. The problem is of course that the NES doesn't have a whole lot of RAM (unless you use extra RAM on the cartridge), so usually what you'd do is only decompress the area right around the characters that need to check for background collisions.

The simplest, most effective compression method I've been using is simply using metatiles of metatiles. So similar to your 16px metatiles, you'd have 32px metatiles of four 16px ones, and 64px metatiles of four 32px ones, making sure to reuse the same ones as much as possible and limiting yourself to 256 different metatiles of each type at most. That kind of compression allows me to decompress on the fly whenever I need a metatile index by using bit shifting similar to what I described above (shift your 16px index right once to get the 32px index, etc)

Yes, if you have 16px metatiles for collision checking, there are most often 17 visible column offsets your character could be positioned in. Fortunately there are only 15 vertical rows, so technically you should still be able to do with an 8-bit index from your starting offset.

However, if you're doing horizontal scrolling anyway, there are essentially many more columns your character could be in. So instead of basing your offset on the scroll amount maybe start out using your characters X position (in world coordinates, not the sprite's screen coordinates) to determine which column it is in out of the entire stage, and use that as offset?

What I did for my own multi-purpose scrolling engine, was storing the stage into "room" sized metatiles, each representing a full visible 256x240 NES background, so whenever I check collisions of a single pixel, I start out using the high byte of its X position to find out which "room" it is in, and use that for offset.

Hello All: Dark_human here. I've been wading into the 6502 pool here for my new project, and I've been making a little progress. I am running into just a few small bugs while programming in NESASM3 and I would love a few pointers. I have read through all of the Nerdy nights tutorials, and I was able to follow them as I have learned quite a bit of older programming from years past.
My first question would be about moving sprites. I can get multiple sprites to move together with button presses, but how would I go about making the sprite move and then stop without releasing the button. (like pressing select to change game modes in Kung Fu). It just keeps cycling through the options endlessly until the button is released.
Secondly, I can turn the screen on and off to draw different option menus, but pressing a button to do so draws the screen incorrectly until the button is released, Unless I turn the screen of and wait for the next time my "Drawscreen" subroutine runs (then the sprites from the previous screen I did not want are rendered)
i.e.
LDA #%10010000 ; enable NMI, Sprites = Pattern table 0 / BG = Pattern table 1
STA $2000
LDA #%00011110
STA $2001
LDA #$00
STA $2005
STA $2005

(also if I don't do LDA #%00011010 there I get unwanted artifacts too). Thanks for your wisdom and help in advance!! -DH

Hey Dark, sorry that no one has gotten back to you here yet. Are you still needing help with this?

Hi All,
I'm having trouble getting my head around indexing into a table, it's been a little while since I've had to try and do this but I'll try and explain what I'm attempting as best I can.

I have a table of collision data that I want to check against my current sprite location. I can get the sprite locations easy enough and then use the X,Y registers to obtain the index I'm after. (spite is in location 3, 4 for example). So my Y index (3) would be the row in the table and the X index number (4) would be the column.
I grab these and store them in my temp vars room_pos_x and room_pos_y.

Example of my table for reference:
BG_COLL_DATA:
.byte $01,$01,$00,$01,$01,$01,$00,$01,$01,$01,$01,$01,$01,$01,$01,$01
.byte $01,$01,$00,$01,$01,$01,$00,$01,$01,$01,$01,$01,$01,$01,$01,$01
and so on...

I'm then grabbing pointers to my collision table:
LDA #<(BG_COLL_DATA)
STA collisionLo
LDA #>(BG_COLL_DATA)
STA collisionHi

How can i then index into this table using Y as the row (16byte increments) and x as the column (1 byte increments)?

I feel like i need to check what the value of room_pos_y is, if it is 3 i need to index in by 32bytes for the row. But I feel this would be inefficient as i would have a massive CMP/Branch block for each of the 16 possibilities.
I think its the 16byte increment bit that's doing my head in.

(Warning. No idea if this will actually work.)  

tempx .rs 1
tempyLo .rs 1
tempyHi .rs 1

GetTableOffset:
  LDA #<(BG_COLL_DATA)
  STA collisionLo
  LDA #>(BG_COLL_DATA)
  STA collisionHi

  LDA #$00
  STA tempx
  STA tempyLo
  STA tempyHi
  LDX room_pos_x
  LDY room_pos_y
.LoopY:
  CPY #$00 ;decreases Y until it's 0, to find out the Y table offset
  BEQ .LoopX
  LDA tempyLo
  CLC
  ADC #$10
  STA tempyLo
  BNE .NoWrap
  INC tempyHi
.NoWrap:
  DEY
  JMP .LoopY
.LoopX:
  CPX #$00 ;decreases X until it's 0, to find out the X table offset
  BEQ .ExitLoop
  INC tempx
  DEX
  JMP .LoopX
.ExitLoop:
  LDA tempx
  CLC
  ADC tempyLo
  CLC
  ADC collisionLo
  STA collisionLo
  LDA tempyHi
  CLC
  ADC collisionHi
  STA collisionHi

  LDY #$00
  LDA (collisionLo),y
;;current value from table is now in A

Thanks, i'll have a look at this today and see how I go. It already looks a lot better than the horrible CMP/Branch code that I wrote to test my theory  

Ended up figuring out the table indexing thing, sorry it took me a while to get back.

New thing I'm trying to work out, how to find the position of my sprite relative to the background byte in the nametable   oh joy

EDIT: So i've been doing some research over a few days now but can't find much related to determining what nametable byte my sprite is overlapping. I found this but I'm struggling to translate it to my use case - https://forums.nesdev.com/viewtop...

I have a single screen level, no scolling. Using 16x16 metatiles for my background. My sprite (also 16x16) moves 16px at a time so will always start/stop within a matching 16x16 background metatile boundary. I can work out my sprites top left (8x8) tile top(x) and left(y) positions easily enough using the OAM values. But I'm finding it hard to figure out how to translate that to a nametable address. I want to do this because when my sprite moves to a certain tile I want to swap out the background tile in the nametable. Which i can do manually with some testing code, buut obviously I need to do this programatically.

e.g. 8x8 sprite tile top = 48px down from top of screen, left = 128px across the screen should = $2110 in the namtable for example.

EDIT: Figured it out - feels so satisfying when it comes together. For those curious, I had already created a collision table and was indexing into that for collision detection. I just re-used the collision coords and did a bit of math to calculate the number of bytes to index into the nametable address space.

Hello there,

I recently started reading up on nes development (I'm new to it) and I'm currently going through the Nerdy Nights tutorials. I'm moving through the tutorial at an ok clip, so I started thinking about what kind of game I'd want to make.

I'm interested in making a puzzle game of some sort, but I'm wrestling with the fact that there's a limit of 8 sprites per scanline (mainly because I was considering making a competitive two player game, similar to Tetris or Puyo Puyo). I've been looking at some other nes games for ideas, and came across Palamedes.

Now I'm not overly familiar with Palamedes, but in its two player mode, it seems to be able to use more than 8 sprites per scanline (the well has a width of 6 sprites for each player). My question is this: does anyone know how Palamedes is able to accomplish this?

Thanks in advance to anyone who has any insight into this.

Throw it into FCEUX, pop open the nametable viewer, and see if those are really sprites  . Just guessing, I'll have to look later. And welcome back!

Ah, good idea, thanks Beau   My nose has been to the grindstone recently looking for work, so I spaced on my NES studies lol. It's kinda neat looking at assembly again. Most of the time I work with higher level languages like Lua or JS.