It is currently Mon Dec 11, 2017 12:14 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 1388 posts ]  Go to page Previous  1 ... 88, 89, 90, 91, 92, 93  Next
Author Message
PostPosted: Wed Sep 13, 2017 3:35 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 804
Location: cypress, texas
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.


Top
 Profile  
 
PostPosted: Thu Sep 14, 2017 9:33 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 804
Location: cypress, texas
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


Top
 Profile  
 
PostPosted: Thu Sep 14, 2017 10:01 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Thu Sep 14, 2017 8:16 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 804
Location: cypress, texas
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. :)


Top
 Profile  
 
PostPosted: Thu Sep 28, 2017 4:19 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 804
Location: cypress, texas
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:
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:
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


Top
 Profile  
 
PostPosted: Fri Sep 29, 2017 7:49 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 804
Location: cypress, texas
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. :)


Top
 Profile  
 
PostPosted: Wed Oct 04, 2017 10:45 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 804
Location: cypress, texas
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. :)


Top
 Profile  
 
PostPosted: Wed Oct 04, 2017 10:54 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Wed Oct 04, 2017 1:24 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 804
Location: cypress, texas
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:
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:
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!


Top
 Profile  
 
PostPosted: Wed Oct 04, 2017 2:18 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 804
Location: cypress, texas
YEAY!! :mrgreen: I'm so blessed to find this works too:
Code:
oldaddr=$
.base $6000
.rept 256
    .db <$
.endr
.base oldaddr
:D


Top
 Profile  
 
PostPosted: Wed Oct 04, 2017 2:28 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
unregistered wrote:
Code:
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.

Quote:
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:
  ldx #$00
Loop:
  txa
  sta $6000, x
  inx
  bne Loop


Quote:
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.


Top
 Profile  
 
PostPosted: Wed Oct 04, 2017 2:30 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
unregistered wrote:
YEAY!! :mrgreen: I'm so blessed to find this works too:
Code:
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.


Top
 Profile  
 
PostPosted: Wed Oct 04, 2017 3:27 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 804
Location: cypress, texas
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:
.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.


Top
 Profile  
 
PostPosted: Wed Oct 04, 2017 3:57 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 804
Location: cypress, texas
tokumaru wrote:
Quote:
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!


Top
 Profile  
 
PostPosted: Wed Oct 04, 2017 4:20 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1388 posts ]  Go to page Previous  1 ... 88, 89, 90, 91, 92, 93  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: adam_smasher and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group