edit3: tepple's post I referred to
edit4.
Moderator: Moderators
I'm sorry, I didn't even consider you not understanding what each subroutine does. Your comment helped me so much though, thank you! Next time I'll include a short summary of each routine; thanks tokumaru this comment is really helpful too.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.
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:unregistered wrote: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'sunregistered 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 3Without 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.Code: Select all
lda visible_left and #11111100b;10b sta valid_left ; <this fixes the screen so it always works :mrgreen: :D
Code: Select all
lda visible_left
and #11110000b
sta valid_left
Code: Select all
oldaddr=$
.base $6000
i=0
.rept 256
.db i
i=i+1
.endr
.base oldaddr
Code: Select all
oldaddr=$
.base $6000
.align 256, <$
.base oldaddr
Code: Select all
oldaddr=$
.base $6000
.rept 256
.db <$
.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.unregistered wrote:Code: Select all
oldaddr=$ .base $6000 i=0 .rept 256 .db i i=i+1 .endr .base oldaddr
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:That works with asm6 and it was found inside asm6's README.TXT. That sets the first page of MMC1's PRG-RAM.
Code: Select all
ldx #$00
Loop:
txa
sta $6000, x
inx
bne Loop
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.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?
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 wrote:YEAY!! I'm so blessed to find this works too:Code: Select all
oldaddr=$ .base $6000 .rept 256 .db <$ .endr .base oldaddr
Code: Select all
.pad $BE00
.rept 256
.db <$
.endr
That is an excellent point that I didn't remember; thank you so much tokumaru!! That will definitly result in savings! This idea is so helpful, thank you for sharing it with all of us!tokumaru wrote: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.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?
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.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.