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

User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: 8x16 and whatever else unreg wants to know

Post by Banshaku »

I don't know what is the cause of your error but doing 5 asl in a row shouldn't be an issue. I have such code in my source code with ca65 and no such issue occur.

Must be something else that you didn't find yet.

edit:

I misread the part that it was specific to asm6 so my post may be irrelevant then ^-^;;
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 Banshaku 😊 it seems I’ve reached another asm6 zone where you all can’t help me. That’s ok. 🙂 I’ll keep working on it and report back if anything helpful is found.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re:

Post by unregistered »

Kasumi wrote: Wed May 16, 2012 11:36 am Do you keep a changelog, or backups? If so, I'd start to. Even something simple like this is good.
Version 1:
Added animations.
Add movement.
Version 2:
Added horizontal scrolling.
Added 16bit movement for sprites.

I backup my entire source folder for every major change, and keep track of changes. This allows you to only check what was changed when you have an issue. "It was working. I added X, and changed Y. Now it's not. The problem is probably in X or Y, so I'll look at their logic." This also means if you REALLY screw up, you can just copy over the last backup.
Kasumi’s advice from p.36 is excellent… maybe I’ll just copy over my last backup. 🤔
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 »

Bugs that cause programs to crash on power on are not particularly hard to find, since they happen very early on and very consistently. You can step through the code from power on (using breakpoints to skip past slow parts such as waiting for vblank or clearing memory) and see exactly when things go wrong.
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 tokumaru! :)

My ROM never even loads; from Mesen thread:
unregistered wrote: Mon Dec 13, 2021 3:52 pm
Fiskbit wrote: Fri Dec 10, 2021 8:15 pm Go Tools -> Log Window and see what Mesen has to say about the ROM you've tried to load. I'd bet your header does not match the ROM size or something like that.
You are exactly right Fiskbit! 👍😊 Thank you so much! 😀

[iNes] Invalid file (length does not match header information) - load operation cancelled.
Time to adjust the header.
During my header search I discovered that nesdev wiki lists information for a header that appears at like $FFE0… however, my header is at the top of my .lst file.

After adjusting my header to use mapper 1 (it’s byte7 was 00 for some reason), my Mesen’s log window still contains the same invalid file line.


So, is that header at $FFE0 necessary? It has a section for a checksum, but I’ve never heard of needing a header at $FFE0. :?
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: 8x16 and whatever else unreg wants to know

Post by Pokun »

No it's not necessary by any means. That's Nintendo's own header (or more like footer since it's at the end of the ROM) for administrative use. It was implemented late in the Famicom's life so most games don't use it, and even some late games like Just Breed that uses this header seems to skip the CRC and just write 0 there. Emulators definitely don't need it and it can't be related to your problem.
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! 😀

In the wiki, it says:
Even boards which different usage of upper CHR lines are all assigned to NES Mapper 1. Emulators can distinguish SOROM and SXROM from SNROM using the new PRG RAM size fields in NES 2.0 or using a PRG hash for legacy iNES ROMs. Therefore, it is recommended that ROM images of SOROM and SXROM games be stored in NES 2.0 format to allow an emulator to distinguish them from SNROM or SUROM.
at the bottom of https://wiki.nesdev.org/w/index.php?title=SxROM .

Since I’m using SXROM, now I need to use NES 2.0 after confusing my emulator (by trying to load my game using mapper 0)? I’m just trying to problem solve. :)
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: Mon Dec 13, 2021 3:52 pmAfter adjusting my header to use mapper 1 (it’s byte7 was 00 for some reason), my Mesen’s log window still contains the same invalid file line.
Sigh, according to https://wiki.nesdev.org/w/index.php?title=NES_2.0
that has told me that bytes 0 - 7 of the header are exactly the same as NES 1.0.

AND, that page specifies that the mapper number is actually implemented through bytes 6, 7, and 8.


My byte7 being 00 was not a mistake, since we’re using mapper 001. :)
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, Mesen is telling you that the length of the file is wrong... Since ASM6 doesn't have any built in features to control bank sizes and such, it's possible that a small mistake somewhere is causing the final size to be off by a small amount... Are you sure that the final PRG and CHR sizes are correct down to the byte?
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: Tue Dec 14, 2021 11:12 am Well, Mesen is telling you that the length of the file is wrong... Since ASM6 doesn't have any built in features to control bank sizes and such, it's possible that a small mistake somewhere is causing the final size to be off by a small amount... Are you sure that the final PRG and CHR sizes are correct down to the byte?
Thank you tokumaru! 😀 No, I’m not sure of that… just checked to see if all the banks were present in my .lst file; will definitely check the PRG and CHR sizes after lunch break. :)
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, all of my 32 16K PRG banks’ ends either change the PC to $C000 or to $10000, so they meet the perfect size required.

Have 0 CHR banks; using CHR-RAM :)
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: Tue Dec 14, 2021 11:12 am Well, Mesen is telling you that the length of the file is wrong...
So, the length of the file is somehow wrong… it’s 523536 bytes according to my version of asm6. How many bytes is that off?

An older working ROM of our game is 524,304 bytes… so our non-working game is missing 524304 - 523536 = 768 bytes? 😱


EDIT: So, I guess I need to find out why the .lst file is written when the ROM is not?
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: Tue Dec 14, 2021 2:03 pmAn older working ROM of our game is 524,304 bytes… so our non-working game is missing 524304 - 523536 = 768 bytes? 😱
768 == #$300

Any ideas about what could be wrong? I’ll recheck my .lst… but, rechecking seems pointless. :? It will be ok; will probably visit gdb if no response is received.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: 8x16 and whatever else unreg wants to know

Post by Pokun »

It might be a single line that got a stray character or something added by mistake and messes up the alignment. Check things like your ORG and PAD directives. I'd compare them and anything else that may look suspicious with the working version of the source.

If you know exactly what you have changed since last time it worked I would check that. It's easier if you change as little as possible between testing. I was told to always only change one thing (thing as in a routine or feature, not a single line of course) before testing because if you change two things or more you don't know which broke it when errors occurs.
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: Tue Dec 14, 2021 2:27 pmAny ideas about what could be wrong?
Like Pokun said, better double check all the ORG, BASE and PAD directives you have... Hopefully they'll be all in a single file where you can easily tell the order in which they're processed.

Now that I think of it, ALIGN may be a better directive than ORG or PAD to fill each bank to the end, since the argument to that would be the exact size of the bank, regardless of the bank's initial address. Not having to calculate what the final address is based on the initial address should reduce the chances of mistakes.

Code: Select all

.base $8000
;(stuff)
.align 16384 ;exactly 16KB

.base $C000
;(stuff)
.align 16384 ;exactly 16KB again, even though the start address is different 
Post Reply