8x16 and whatever else unreg wants to know

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

So nametable 00, should be 01, is shown for about one frame because after drawing both screens, when changing floors, collisionTables is jsred immediately; we need correct collision values for the new floor. Jsring collisionTables causes the update_vram function, in vblank, to be skipped since FrameReady isn't negative (the previous frame calculations aren't over yet). Jsring update_vram is important because $2006 is written to inside draw_our_column, which runs inside update_vram. $2000 and $2006 $2005 must be written to in order to undo the confusion that t causes after drawing the screens; that's what tepples told me. Should I write $2006 $2005 outside of update_vram outside of scroll_screen? That seems better to me because trying to make collisionTables run right after the first vblank after the screens are drawn would be bad since: 1. there may be problems caused by updating the collision information a frame later and 2. if there is ever a time when frame calculations aren't done yet $2006 $2005 won't be written to.

edit3: tepple's post I referred to

edit4.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

Haha! Success!! :mrgreen: :D I'm sorry about my post up there. After rereading tepple's post I linked to, I realized I should have been thinking about writing $2005. And so $2005 is written inside of scroll_screen and scroll_screen wasn't running because of 4 bytes of pointless code that tried to make sure that $2000 was only written to once a frame; tokumaru's most recent reply on page 90 helped me to understand that; thank you so much tokumaru! :D After removing that pointless 4 bytes the game is not flashing the wrong nametable for a frame anymore! :mrgreen: :D
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: 8x16 and whatever else unreg wants to know

Post by tokumaru »

Sorry if I can't help more, but there are a lot of details regarding the design of your own engine that we can't really follow anymore, such as the name of various subroutines and what each one of them does.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

tokumaru wrote:Sorry if I can't help more, but there are a lot of details regarding the design of your own engine that we can't really follow anymore, such as the name of various subroutines and what each one of them does.
I'm sorry, I didn't even consider you not understanding what each subroutine does. :oops: Your comment helped me so much though, thank you! :D Next time I'll include a short summary of each routine; thanks tokumaru this comment is really helpful too. :)
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

unregistered wrote:
unregistered wrote:Forcing $2000 to be written to only once per vblank took away the two 16bit columns of random tiles drawn between two of the screens on floor 3
No, the two incorrect columns of 16bit tiles were there because valid_left was incorrect so it wasn't drawing the new columns of tiles at the correct time. Near the end of see2vi, which redraws both screens when changing floors, there's

Code: Select all

lda visible_left
and #11111100b;10b
sta valid_left ; <this fixes the screen so it always works :mrgreen: :D
Without that code scrolling left is broken for about a screen. When bit1 was 1 it missed drawing two 16bit columns when scrolling right. Scrolling left wasn't broken, I think, when I posted my incorrect post that's quoted. :)
After being able to successfully travel over the first hole on level 1 and then travel left and fall down through the hole to floor 3 and then travel right, 4 columns of blocks were present between two of the screens because valid_left was 4 ahead of visible_left... so just needed to make a change to the code I posted above. Ended up setting:

Code: Select all

lda visible_left
and #11110000b
sta valid_left
Felt I should have done that earlier... if anyone is using tepples' visible_left and valid_left scrolling controls at the bottom of page69 you may want to implement that code above. It is so helpful!! :mrgreen: :D
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

The hole is near the end of the second screen. Going over the hole takes you to the third screen and then traveling left to fall in the hole crosses the character over to the second screen again. So maybe my logic at changing screens is conveluded somehow. Just wanted to explain this a bit more so you all could understand the post above a little better better. :)
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

After setting up some of the banks on MMC1 to hold all of my sister's screens for her game, two of the levels' screens took up more than 16 kb; so, we split each of those screen-groups into two banks; the same file needs to be included in each of those level's banks and asm6 doesn't build the NES ROM. It says "Label already defined." Is there a way to make asm6 build the NES ROM anyway or do I have to rename each label that appears twice?

I understand why it won't build the ROM with two identical labels, but there is no way that both of those banks will be in memory at the same time, because our MMC1 is set up so that $8000-$BFFF is the switchable bank and $C000-$FFFF is fixed.

Thank you for reading this. :)
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: 8x16 and whatever else unreg wants to know

Post by tokumaru »

One way to repeat labels in ASM6 is to use MyLabel = $ instead of MyLabel:, but you have to make sure that every instance of each label always points to the same address (i.e. the file must be included in the same address in every bank it's needed), or the program could crash. I used this when working with 32KB PRG-ROM banks, to include the CPU vectors, interrupt handlers and trampoline routines at the end of every bank.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

Thank you so much tokumaru!! :D That is so very helpful!! :mrgreen:

p.s. tokumaru, you mentioned in some recent thread that if we setup a page of memory to hold each low byte value like (just figured this out):

Code: Select all

oldaddr=$
.base $6000
i=0
.rept 256
    .db i
    i=i+1
.endr
.base oldaddr
That works with asm6 and it was found inside asm6's README.TXT. That sets the first page of MMC1's PRG-RAM. You said we could use this to do addition faster and you also said we could use it to replace txa tay, but ldy $6000,x takes 3 bytes and 4 cycles and txa tay takes 2 bytes and 4 cycles. Is this correct? :)

In the beginning of the quest to create this page of memory with as few instructions as possible we started with this:

Code: Select all

oldaddr=$
.base $6000
    .align 256, <$
.base oldaddr
, but that just fills the first page with 00s because the PC doesn't increment after each byte written. :(

edit: these don't use instructions, so I'm really happy :D But, if there is a way to make the PC increment by one after each byte written that would be extremely cool!
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

YEAY!! :mrgreen: I'm so blessed to find this works too:

Code: Select all

oldaddr=$
.base $6000
.rept 256
    .db <$
.endr
.base oldaddr
:D
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: 8x16 and whatever else unreg wants to know

Post by tokumaru »

unregistered wrote:

Code: Select all

oldaddr=$
.base $6000
i=0
.rept 256
    .db i
    i=i+1
.endr
.base oldaddr
This doesn't look right... It does compile, but maybe it isn't doing what you think it is. The .base statement won't assemble to a different location (not that you could assemble to RAM anyway, which $6000 usually is), it just changes the value of the PC for labels that follow it. You're not even using any labels here, so this will just output 0 through 255 at the current location. Those .base statements are doing basically nothing. ASM6 assembles code sequentially, you can never output to a different location like you can when using segments in ca65, for example.
That works with asm6 and it was found inside asm6's README.TXT. That sets the first page of MMC1's PRG-RAM.
Like I said above, these values are not going to PRG-RAM. To put things in RAM you have to use 6502 code at runtime, you can't use compile-time commands. You need a good old 6502 loop to put this 256-byte table of sequential values in RAM:

Code: Select all

  ldx #$00
Loop:
  txa
  sta $6000, x
  inx
  bne Loop
You said we could use this to do addition faster and you also said we could use it to replace txa tay, but ldy $6000,x takes 3 bytes and 4 cycles and txa tay takes 2 bytes and 4 cycles. Is this correct? :)
Individual operations may not always be faster, but consider that you may be using the accumulator for something else, and saving/restoring it could take 6 to 8 cycles, so being able to do some operations without involving the accumulator could result in savings in the end.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: 8x16 and whatever else unreg wants to know

Post by tokumaru »

unregistered wrote:YEAY!! :mrgreen: I'm so blessed to find this works too:

Code: Select all

oldaddr=$
.base $6000
.rept 256
    .db <$
.endr
.base oldaddr
:D
Yeah, it works, but the values are going to ROM, not to PRG-RAM $6000. RAM on the NES is never populated automatically, it can only be done through 6502 code.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

Yes, now I remember you explaining about RAM needing to be loaded with 6502 instructions a long time ago. Thank you so much tokumaru for teaching me again! :D My ROM just had a gray screen forever after enabling MMC1's PRG-RAM so I just disabled it and it works great now. Also, I moved my code near the end of each of the first 15 banks and changed it to:

Code: Select all

.pad $BE00
.rept 256
    .db <$
.endr
and it works awesomely now!! :mrgreen:

edit: Honestly, I made the mistake of just looking at the .lst file and it showed the values written to $6000 just like it always shows the values written to ROM. I hadn't gotten our game to work yet so I'm sorry and I will try to be more careful in my postings in the future.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

tokumaru wrote:
You said we could use this to do addition faster and you also said we could use it to replace txa tay, but ldy $6000,x takes 3 bytes and 4 cycles and txa tay takes 2 bytes and 4 cycles. Is this correct? :)
Individual operations may not always be faster, but consider that you may be using the accumulator for something else, and saving/restoring it could take 6 to 8 cycles, so being able to do some operations without involving the accumulator could result in savings in the end.
That is an excellent point that I didn't remember; thank you so much tokumaru!! :D That will definitly result in savings! :mrgreen: This idea is so helpful, thank you for sharing it with all of us!
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: 8x16 and whatever else unreg wants to know

Post by tokumaru »

unregistered wrote:Honestly, I made the mistake of just looking at the .lst file and it showed the values written to $6000 just like it always shows the values written to ROM.
Yeah, the listing will show $6000 because you told the assembler that the PC for that part was $6000, but that doesn't mean the code will actually end up at $6000.

Contrary to what may seem at first, commands like .org and .base don't force data into a particular address, they just let the assembler know where the code will be loaded so that labels and stuff have the correct values during execution.

NES programs don't start with .org $8000 because that causes the code to be put at $8000. The code will be loaded into $8000 no matter what, even if you write .org $3A9B instead, but all the labels will be wrong and the program won't function correctly.

EDIT: BTW, I said that .base wasn't doing anything in the code you posted, but now that I think of it, it's probably causing your ROM to be 256 bytes longer than it should, making it invalid. I believe that's the case because later you reset the PC to the value it had before the table, so the table is inserted into the ROM but the space it takes is not taken into consideration by the assembler since you manipulated the PC for that part.
Post Reply