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 »

Thank you Pokun and tokumaru! :)

I finished checking every PAD, BASE, and ORG… they are all fine.

@tokumaru, my banks don’t end with a pad bc each bank’s footer allows for reset to work no matter what bank loads at startup. But, thank you; a cool idea. 😀
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 »

It definitely has to do with my code… bc the original asm6.exe also assembles a ROM of size 523536 bytes. So, phew, it has nothing to do with my asm6_.exe modifications. :)
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, just now, after adding your

Code: Select all

.align 16384
line to the very end of every bank (including both fixed banks), our game still builds with 523536 bytes. :o

So, does .align only affect .lst file creation? (To everyone:) Or how is it possible for my game to be created with 768 bytes less than normal - after adding tokumaru’s .align lines at the very end of ALL 32 banks?


Is reset missing 768 bytes? Oh… no, reset is part of my bank 15.


EDIT: reminder: 768 == #$300 :)
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 »

^Note: my header is iNES. Would changing to NES2.0 fix anything?

My NES1.0 (iNES) header:

Code: Select all

4E 45 53 1A

20; 32 16kb PRG-ROM blocks

00; CHR-RAM

13 00; ROM control bytes: Vertical mirroring, yes SRAM, no trainer, Mapper #1,  NES 1.0

00 00 00 00 00 00 00 00; Filler
Noticed the first byte on the filler is a seldom used RAM measurement. 0 defaults to 8kb. MMC1 gives me 32kb of RAM, but that’s separated into 4 selectable 8kb banks, so the first filler (9th byte) being 00 is appropriate, right?


Your wiki also said that bit0 of 13 is useless on MMC1 games bc that mapper controls the mirroring itself. Would my mapper set up for horizontal mirroring cause the 768 byte loss? Sry, just attempting to figure this out.


EDIT: All iNES values given here are in hexadecimal form; felt that was pretty obvious; clarifying. :)
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 »

Have you tried building a stripped down version of the ROM without any of the code or data, just the header and the bank organization stuff? If you can reproduce the problem that way, the error might be easier to find.
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: Wed Dec 29, 2021 9:48 am Have you tried building a stripped down version of the ROM without any of the code or data, just the header and the bank organization stuff? If you can reproduce the problem that way, the error might be easier to find.
Thank you tokumaru! Great idea! :D So far I’ve emptied my MainLoop and I receive the same error.

Now, I remove all other code from my stripped down game copy? Oh, yes, vblank still has code in it; the other code doesn’t run any more bc main loop is empty.


My banks have been untouched so far.
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 »

Now, after severely simplifying vblank: and clearing all banks, my “game” builds with 524304 bytes, and it loads! 😀

So now I guess I’ll restore each bank, add a new old one each time, and see what happens.
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 »

Weird! 😔

bank2 causes the game to lose 64 bytes. :(

There isn’t anything wrong with its code, that I can see. However, there are four:

Code: Select all

$=$+16
lines in bank2.

4*16=64…

And, just searched for “$=“ and found 48 of those throughout my entire game.

48*16=768 :o


So, why does asm6 fail to move the program counter ahead 16, yet its .lst file spouted looks like a sane list file? AND, asm6 doesn’t just fail in that way; it subtracts those 768 bytes from my nes file. :(

Therefore, I’ll simply change each $=$+16 into .pad $+16, I guess… . :D :mrgreen: Thank you tokumaru so much! 👍😀


—-
EDIT: $=$+16 has worked flawlessly before… oh well, happy to know it doesn’t work for me anymore. 🙂
FINAL-EDIT: Our game works again! PRAISE GOD!! :D :mrgreen:
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 »

Maybe $= works like BASE and not like ORG. Could check the source code to be sure. Why do you need to skip 16 bytes anyway?
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: Thu Dec 30, 2021 4:45 pm Maybe $= works like BASE and not like ORG. Could check the source code to be sure. Why do you need to skip 16 bytes anyway?
maybe so 😀; it used to work how I wanted it to, for a while at least


skipping 16 bytes temporarily bc our game has many palette files.
It’s just to space banks correctly until I have all the lvl palette files. :)
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 »

In this case, I think DSB would be the best directive to use. It's the one that most closely matches the effects of including a block of data (via INCBIN, INCLUDE, DB, etc.), except you're just generating multiple copies of the same value.

In my programs, I generally avoid manipulating the program counter directly in included files... All ORGs, PADs, BASEs, SEGMENTs, etc. (the directives for ROM organization can vary a lot from assembler to assembler) go in a top-level file that includes all the code and data.
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: Thu Dec 30, 2021 6:08 pm In this case, I think DSB would be the best directive to use. It's the one that most closely matches the effects of including a block of data (via INCBIN, INCLUDE, DB, etc.), except you're just generating multiple copies of the same value.

In my programs, I generally avoid manipulating the program counter directly in included files... All ORGs, PADs, BASEs, SEGMENTs, etc. (the directives for ROM organization can vary a lot from assembler to assembler) go in a top-level file that includes all the code and data.
Thank you tokumaru! :D I’ll use .dsb; it’s different; that’s what I was striving for.
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 »

I'm glad you managed to fix it.

BTW, looking at asm6's documentation for the BASE directive, it explicitly says that "The same can also be accomplished by assigning the '$' symbol directly (i.e. '$=9999')", so yeah, that just changes the PC without inserting any padding, so you were just skipping 16 bytes in various places. I don't think it ever worked the way you thought it was working, but somehow the ROM still functioned as expected.
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 »

:D

Ummm… the ROM spaces containing the $= lines were in currently unused-in-game banks; I guess it seemed to work bc I placed those lines in blank sections of the banks. After their change into dsb, my game functions extremely normal again (i.e. it’s now possible to assemble 5 consecutive asl statements).

So, I also agree with you and think we should never store a value, that has to be calculated, to $. At least not 48 or so times in the same asm6 ROM. :wink:
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 »

Well, there are legitimate reasons to directly change the PC value like that, such as beginning a new bank or assembling code that will run at an address different from where it's stored (i.e. code that will be copied to RAM), but in these cases you'd normally use a constant address, not one based on the current address... and since the assembler provides a dedicated directive for this purpose, it's probably better to use that than the PC assignment.
Post Reply