nesdev.org

For the record: I'm pretty sure you're using an old version of nesasm. The one I have (nesasm3) says the branch is out of range when I add a nop there. http://www.nespowerpak.com/nesasm/NESASM3.zip Yeah, I've got multiple versions floating around my hard drive and I was in fact using the older one....

tokumaru wrote:well by that time the CPU was already completely lost and was trying to execute your variables as code, which is never good

Ha ha ha. True and hilarious.

FCEUXD's debugger

I'm going to have to learn how to use that.

Thanks a ton.

Only I don't use NESASM, so I can't assemble your sources... Not that it matters but, I included NESASM.exe in the zip. I remember running into this problem but I thought it was with all commands that goto an address. I didn't know branches were more limited than JMP's. Everything you said makes pe...

EDIT: I'm taking a look at the ROM without the error to see if I can find something, but the one with the error would be more interesting. Well that's easy enough to do. I just added a nop on line 191 just after: lda $4016 ; load RIGHT Status and #1 http://www.mediafire.com/?sharekey=423a49e6ada136...

It doesn't really matter how NESASM treats them, iNES files always counts PRG banks in 16KB units. Anyway, it's a fact that you are trying to assemble 32KB of PRG ROM, and if ".inesprg 1" writes a 1 to the PRG bank count field in the header, it's wrong. Try using a 2 here and see if it ma...

Looks ok.. Can you stick the other files somewhere. That would make it much easier to fix. http://www.mediafire.com/download.php?jymyigz4wyj Another thing that appears to be wrong (but I'm not sure because I'm not a NESASM user) is that you state that there is only one PRG bank (.inesprg 1) but in ...

I can't believe I missed that obvious mistake. Explains why the NMI routine wasn't breaking it when it was being executed (in theory) after the start code. I guess it would have been easier to debug if the rest of the files were supplied to assemble it. I can upload the files somewhere if anyone ca...

You don't have any reset vectors at $FFFA-$FFFF defined, do you? *My* code doesn't start until the controller checking starts. So, the resets are probably taken from GBA Guy. This looks like the extent of it. .bank 1 .org $FFFA .dw VBlank_Routine ; address to execute on VBlank .dw Start ; address t...

I just copied the start up portion from the web. So if it is a typo, it isn't mine.
I added "JMP Start" after the bne clrmem, but NOP's still crash it.

I've spent a lot of time away from NES programming and I'm trying to come back and get a better feel for it. I'm working on a ball and paddle game and I'm running into problems right away. My lame collision works as it is. But, if I add so much as a NOP, it hangs upon collision. It also fills the se...

Solved! somewhat... I opened the rip and the rom in hex editors and found that the only difference was 0d0a in place of 0a. Now 0d0a is the ascii newline character. But 0d was appended to 0a not 0d0a inserted randomly. I don't really know what made this happen but a simple find and replace all made ...

ROM format types. Since UNIF unfortunately did not take off within the wider emulation scene, I'd wager that your ROM is in iNES format (if the first four bytes are "NES" followed by $1A then it's iNES, if those bytes are "UNIF" then it's UNIF). It is iNES. The ROM size is corre...

Rom=24592 bytes
Rom Prg=16602 bytes
Rom Chr=8195 bytes

Rip=16384 bytes

I don't even know INES and UNIF are. Header types?

Here's something crazy to try: Open the PRG in a tile editor such as 8TED or Tile Layer Pro. It should look like garbage, but if you can find garbage that repeats, you have an overdump, and you can begin to investigate the address line problem. My dump seems to repeat what may or may not be "g...

tepples wrote:Should I make a program to do byte-wise heuristics on a file, so that we can determine whether the data lines coming out of the ROM are scrambled?

Do you mean the chip was ripped with a13 set as a14 or some such pin mixup?