ppu corruption when trying to buffer nametables

[lazerbeat]

I have been fiddling about with ccovells anims demo for a while with a view to making a simple animation program but I have hit a problem. When using the rom the graphics are garbled so I checked in the ppu viewer in FCEUX and it looks like the PPU data is corrupt. I am honestly a bit stumped with this one as I don't THINK I am writing to $0000-$0FFF which is the only thing I can think of which would cause the corruption.

Would anyone be kind enough to have a look at the code?

http://pastebin.com/pskP6azC

[Kasumi]

You don't appear to be including any actual graphics in this .asm file. The .NAMs from the original are data about which tiles should be drawn where/palette information. They don't contain the actual tiles (graphics) themselves. That's in the .CHR.

These are literally the only changes I made.

Code: Select all

pic0:
        .include "Greys.NAM";Including data from the original since you didn't provide yours
pic1:            
        .include "Greys.NAM"     
pic2:            
        .include "Greys.NAM"
pic3:            
        .include "Greys.NAM"
pic4:            
        .include "Greys.NAM"
pic5:            
        .include "Greys.NAM"
pic6:            
        .include "Greys.NAM"
pic7:            
        .include "Greys.NAM"

;       ----------------------------------------------------



;       ----------------------------------------------------

	.ORG $fffa              ; vectors. You already had these here and I didn't change them
	.DW NMI
	.DW Reset

	.INCBIN "Greys.CHR";Adding a chr block.

Another potential error is using .INCBIN to include the original .NAM files. If you have files like them, they should be .include d. If you've got your own data files called pic(X).nam, and they are in fact 1024 byte files, incbin is correct. I don't have your files, so I dunno which you want, just letting you there's a difference.

That aside what you have will work for a frame. You have some stuff broken at the moment if you want more than a frame, but try out fixing it once you have the CHR included and can see what you're doing.

Extra info: If you're using CHR ROM (and the original is, and your rom's header says it is), writes to $0000-$1FFF etc on the PPU side shouldn't have an effect.

[lazerbeat]

Sorry, I should have been clearer about that. I include the .chr file when compiling with this script

Code: Select all

#!/bin/bash
rm nesanimation.nes
asm6 nesanimation.asm test.bin
cat test.bin nesanimation.chr >> nesanimation.nes
rm test.bin
fceux nesanimation.nes

I did try adding in the INCBIN "graphics.CHR" and using include for the .nam files, but not change I am afraid. Thanks for the ideas though!

[Kasumi]

Can you provide more information about what you're expecting vs what you're getting, or just your actual data, then?

I did exactly what I described, and got exactly what I described. It works, for one frame.

So you are either getting something different, or expecting something different, or have some different version of asm6 or something weird.

I don't know what exactly you expect to see, I don't know exactly what you end up seeing instead, and I don't have your data to make good guesses about it. Help me help you.

My only real guess is that you are wondering why it's not working for one frame, but I assumed you knew it would not work because you have the code to load new screens (jsr loadnewscreen under the NMI label) commented out. Is the the issue you're looking for help with what happens after you uncomment that line?

Edit: The problem could even just be the palette. The frame I took from greys looks different than the actual greys because the palettes are different. But this fixes that:

Code: Select all

palette:                        ; palette data
        .byte $0F,$00,$10,$30,$0F,$30,$30,$30,$0F,$30,$30,$30,$0F,$30,$30,$00

So let me know in detail what you're getting vs what you want to get.
Edit: Or not. I've compared the two, and now I actually see the problem, so I'll look for the cause.
Edit2: Found it. Lack of IRQ vector put the CHR in the wrong place. I feel dumb.

Code: Select all

.ORG $fffa              ; vectors
	.DW NMI
	.DW Reset
	.DW IRQ

To be fair, I'm usually a nesasm user, and nesasm pads in this case.

I'm actually wondering why more emulators didn't complain about the result. That's worrying more than anything else. Without the .DW IRQ, you get a 32,782 with one you get a 32,784 file which is correct. Then adding the CHR like you did should have generated a file that was the wrong size.

Edit4: To really explain it, the CHR got corrupted because the PPU was seeing it without its first two bytes, essentially.

Edit3: Nestopia is the only emulator I have that was nice enough to tell the file wasn't the right size.

That's interesting. Interesting set of problems. Was fun to work on. If there's STILL an issue, well... I was too blind to see it.

[lazerbeat]

Sorry, I should have explained that a bit better.

Basically the desired behavior at this stage is pretty much what nesanimation.nes is doing. It buffers one nametable, once it is full, it flips which name table is being displayed and starts buffering a new one.

The thing I am trying to fix is the ppu corruption shown in ppucorruption.png. The left side is what the .chr file looks like when opened in nes screen tool, the right side shows what it looks like in the ppu viewer in fceux.

I hope that helps!

[Kasumi]

I edited after you read, heh. Sorry, I get edit heavy.

You just need an IRQ value here:

Code: Select all

.ORG $fffa              ; vectors
	.DW NMI
	.DW Reset
	.DW IRQ

The tl;dr version of the edit to the last post is, asm6 doesn't pad files because it's not NES specific. So without those two bytes, the file is the wrong size (which NES emulators don't seem to really complain about ), and then the CHR file has its first two bytes cut off as far as the PPU is concerned.

I downloaded your test, I applied this fix, and the corruption seems gone. (Though I did use an .incbin "nesanimation.chr" after the .dw IRQ instead of combining files with the commandline.)

[lazerbeat]

Thanks so much for that! I wouldn't have even thought to look for that. I got it working in under a minute! Now on to the next step,

Thanks again.