Page 1 of 1

Sprites will not show up

Posted: Mon Sep 14, 2020 9:36 pm
by nyanberrycake
So I prodded around the ram, and my sprites are all there, in $0200, exactly how I transferred them.
first thing is first. I run through the init code. that stores a #$00 into the PPUMASK and the PPUCTRL I establish the oamdma area. zero out memory, put sprites at FF. etc

then, to give an overview of my program, I load everything in by scenes. scenes are arrays that contain a place, and people.
I get to the people part, and first load their palettes. everything works. then I load in their sprites. their sprites are in the ram at $0200. after I do that I return to the main loop (where i dont CLI, but i have tried it both ways), turn on the PPUMASK for rendering (00011110 inside vblank), then enable the ppu with 8x16 sprites, background pattern table at 1 and NMI enabled (%10110100 also in vblank). then jump right into main loop

I have also put code in the nmi that saves the a,x,y registers, loads #$00 into OAMADDR, and then loads #$02 into OAMDMA, then restores registers

and nothing, at all
In the fceux ppu viewer, I get the background. all the colors are loaded in. my sprites. and in the ram I see all the sprites there as well. I colored in every sprite just in case I was using the wrong pattern table (8x16 will use even numbers in my case, but I know that).

I have tried putting a write to OAMDMA after loading the sprites, I have tried making them 8x8. I have also turned on the ppu in other nametables just to see if they were written to another nametable. I just don't know what else to try. I'm really confused...

This data all shows up starting at $0200 in the ram as well. so either it is not being updated every frame or its just not working. Thanks guys I've spent all day on this

Code: Select all

spriteData:
;head
	.byte $20, $00, $00, $08; formatted by y axis, sprite number, no rotation/palette 0/no priority
	.byte $20, $02, $00, $10
	.byte $20, $00, $40, $17; some have rotation
	;body
	.byte $30, $04, $01, $08; some use different palettes
	.byte $30, $06, $01, $10
	.byte $30, $08, $01, $18
	;legs
	.byte $40, $0a, $01, $08
	.byte $40, $0c, $01, $10
	.byte $40, $0a, $41, $17


Re: Sprites will not show up

Posted: Mon Sep 14, 2020 9:55 pm
by tokumaru
It's hard to catch these kinds of bugs without the full code or a ROM, but let's consider a few things:
nyanberrycake wrote:
Mon Sep 14, 2020 9:36 pm
then, to give an overview of my program, I load everything in by scenes. scenes are arrays that contain a place, and people.
I get to the people part, and first load their palettes. everything works. then I load in their sprites. their sprites are in the ram at $0200. after I do that I return to the main loop (where i dont CLI, but i have tried it both ways), turn on the PPUMASK for rendering (00011110 inside vblank), then enable the ppu with 8x16 sprites, background pattern table at 1 and NMI enabled (%10110100 also in vblank). then jump right into main loop
How are you making sure that PPUMASK and PPUCTRL are being updated in vblank? Are you clearing the vblank flag (by reading PPUSTATUS) before enabling NMIs? If you don't do that, an NMI will fire right after the PPUCTRL write, and maybe things are not fully set up to handle an NMI at that time.

CLI has nothing to do with this. Unless you're using a mapper with IRQ capabilities, or you're relying on APU IRQs for whatever purpose, the normal procedure is to disable IRQs (using SEI) at the beginning of the program and never touch the I flag again. NMIs are not affected by the I flag, since as it says in the name, they're NON-MASKABLE Interrupts, you can't disable them from the CPU side.

Re: Sprites will not show up

Posted: Mon Sep 14, 2020 10:36 pm
by Gilbert
Are you sure the NMI codes are executed?
(Are there codes other than sprite DMA they you have confirmed to work there?)
Maybe there is a typo with labels, or whatever, such that during NMI it runs codes from somewhere else, just a suggestion.

Re: Sprites will not show up

Posted: Tue Sep 15, 2020 12:05 am
by Controllerhead
nyanberrycake wrote:
Mon Sep 14, 2020 9:36 pm
fceux
Mesen lets you view OAM ram directly. Very helpful.

Image

Re: Sprites will not show up

Posted: Tue Sep 15, 2020 8:48 am
by nyanberrycake
tokumaru wrote:
Mon Sep 14, 2020 9:55 pm
It's hard to catch these kinds of bugs without the full code or a ROM, but let's consider a few things:
nyanberrycake wrote:
Mon Sep 14, 2020 9:36 pm
then, to give an overview of my program, I load everything in by scenes. scenes are arrays that contain a place, and people.
I get to the people part, and first load their palettes. everything works. then I load in their sprites. their sprites are in the ram at $0200. after I do that I return to the main loop (where i dont CLI, but i have tried it both ways), turn on the PPUMASK for rendering (00011110 inside vblank), then enable the ppu with 8x16 sprites, background pattern table at 1 and NMI enabled (%10110100 also in vblank). then jump right into main loop
How are you making sure that PPUMASK and PPUCTRL are being updated in vblank? Are you clearing the vblank flag (by reading PPUSTATUS) before enabling NMIs? If you don't do that, an NMI will fire right after the PPUCTRL write, and maybe things are not fully set up to handle an NMI at that time.

CLI has nothing to do with this. Unless you're using a mapper with IRQ capabilities, or you're relying on APU IRQs for whatever purpose, the normal procedure is to disable IRQs (using SEI) at the beginning of the program and never touch the I flag again. NMIs are not affected by the I flag, since as it says in the name, they're NON-MASKABLE Interrupts, you can't disable them from the CPU side.
Yes my first time through , I enable nmi using the

Code: Select all

@waitForBlank
	bit PPUSTATUS
	bpl @waitForBlank
	lda %10110100 
	sta PPUCTRL
I do this right after the PPUMASK, which I do in the exact same manor.

Do I need to enable the PPUMASK before I write things like tiles and sprites? does the order need to be

;enable PPUMASK
;write scene data
;enable PPUCTRL

right now I have it as

;write scene data
;enable PPUMASK
;enable PPUCTRL


I'll try this method I guess. I'm just confused because the background colour shows up. What is the purpose of disabling background and sprites in the PPUMASK anyway? Is there any practical reason to turn this off?

Re: Sprites will not show up

Posted: Tue Sep 15, 2020 8:50 am
by nyanberrycake
Controllerhead wrote:
Tue Sep 15, 2020 12:05 am
nyanberrycake wrote:
Mon Sep 14, 2020 9:36 pm
fceux
Mesen lets you view OAM ram directly. Very helpful.

Image
That looks nice. It's on linux too.... I have to use fceux through WINE because their debug tools are only on the windows version... Most people have said fceux is the best choice, but I've been annoyed with its functionality as a whole... thanks for the suggestion.

Re: Sprites will not show up

Posted: Tue Sep 15, 2020 8:55 am
by Controllerhead
nyanberrycake wrote:
Tue Sep 15, 2020 8:50 am
Most people have said fceux is the best choice
A few years ago, it was. Try Mesen. The debug tools are superior in many ways.

Re: Sprites will not show up

Posted: Tue Sep 15, 2020 1:41 pm
by za909
nyanberrycake wrote:
Tue Sep 15, 2020 8:48 am
I'll try this method I guess. I'm just confused because the background colour shows up. What is the purpose of disabling background and sprites in the PPUMASK anyway? Is there any practical reason to turn this off?
There are reasons to disable them. Normally, the PPU uses the same internal address that you can set with $2006. This usage happens when it is rendering either the background or the sprites to the screen. If you disable one of them, the PPU still makes all memory accesses for both, but suppresses the pixel output for the disable layer. If you disable both, no access is done by the PPU and you are free to do whatever you want without messing things up until you turn either layer back on. This is sometimes called "Forced Blank".

When either or both layers are on, the only time the PPU stays clear of using the internal address - that is, when you can safely modify the address or write data to VRAM via $2007 - is during Vertical Blank. This is when all 240 lines have been drawn to the screen. If NMI is enabled, it is triggered at the start of VBlank (under normal circumstances) so that your program is aware that this period has started, and is immediately able to react and send all the updates to the PPU. This period only last for about 10% of the total CPU time per frame, so you can only update so much, while having an active picture rendered. Turning all rendering off to quickly push a lot of updates is great if you want to do something like fade to black, disable rendering, quickly redraw the screen contents in the shadows without the 10% per frame limit, enable rendering again, and fade back to normal colors.

There is also this effect from a Mega Man ROM hack that uses mapper IRQs to time when to disable and enable the sprites to create a "visibility bar" around Mega Man.

Re: Sprites will not show up

Posted: Tue Sep 15, 2020 3:45 pm
by nyanberrycake
tokumaru wrote:
Mon Sep 14, 2020 9:55 pm
It's hard to catch these kinds of bugs without the full code or a ROM, but let's consider a few things:
nyanberrycake wrote:
Mon Sep 14, 2020 9:36 pm
then, to give an overview of my program, I load everything in by scenes. scenes are arrays that contain a place, and people.
I get to the people part, and first load their palettes. everything works. then I load in their sprites. their sprites are in the ram at $0200. after I do that I return to the main loop (where i dont CLI, but i have tried it both ways), turn on the PPUMASK for rendering (00011110 inside vblank), then enable the ppu with 8x16 sprites, background pattern table at 1 and NMI enabled (%10110100 also in vblank). then jump right into main loop
How are you making sure that PPUMASK and PPUCTRL are being updated in vblank? Are you clearing the vblank flag (by reading PPUSTATUS) before enabling NMIs? If you don't do that, an NMI will fire right after the PPUCTRL write, and maybe things are not fully set up to handle an NMI at that time.

CLI has nothing to do with this. Unless you're using a mapper with IRQ capabilities, or you're relying on APU IRQs for whatever purpose, the normal procedure is to disable IRQs (using SEI) at the beginning of the program and never touch the I flag again. NMIs are not affected by the I flag, since as it says in the name, they're NON-MASKABLE Interrupts, you can't disable them from the CPU side.
Ok I found the problem. It won't generate a NMI. I put a variable in the main loop that increments each time and a variable in the NMI code that increments each time, and the variable in the nmi never increments. I have tried everything to get an interrupt and I can't seem to get one. i have put

Code: Select all


	bit $2002
@loop:
	bit $2002
	bpl @loop
	lda %10010000
	sta $2000
in every known location of running code. its almost laughable at this point, it just won't turn interrupts on no matter what. Is there anything you can think of that I am missing? Thnx for your help, this is so weird

Re: Sprites will not show up

Posted: Tue Sep 15, 2020 3:51 pm
by Quietust
nyanberrycake wrote:
Tue Sep 15, 2020 3:45 pm

Code: Select all


	bit $2002
@loop:
	bit $2002
	bpl @loop
	lda %10010000
	sta $2000
in every known location of running code. its almost laughable at this point, it just won't turn interrupts on no matter what. Is there anything you can think of that I am missing? Thnx for your help, this is so weird
You're missing a # sign to mark the LDA operand as Immediate - without it, you're just reading a variable from RAM.

Re: Sprites will not show up

Posted: Tue Sep 15, 2020 4:38 pm
by nyanberrycake
Quietust wrote:
Tue Sep 15, 2020 3:51 pm
nyanberrycake wrote:
Tue Sep 15, 2020 3:45 pm

Code: Select all


	bit $2002
@loop:
	bit $2002
	bpl @loop
	lda %10010000
	sta $2000
in every known location of running code. its almost laughable at this point, it just won't turn interrupts on no matter what. Is there anything you can think of that I am missing? Thnx for your help, this is so weird
You're missing a # sign to mark the LDA operand as Immediate - without it, you're just reading a variable from RAM.
omg wow thank you. I feel rllllly dumb now. that fixed it

Re: Sprites will not show up

Posted: Tue Sep 15, 2020 5:11 pm
by Jeroen
nyanberrycake wrote:
Tue Sep 15, 2020 4:38 pm
Quietust wrote:
Tue Sep 15, 2020 3:51 pm
nyanberrycake wrote:
Tue Sep 15, 2020 3:45 pm

Code: Select all


	bit $2002
@loop:
	bit $2002
	bpl @loop
	lda %10010000
	sta $2000
in every known location of running code. its almost laughable at this point, it just won't turn interrupts on no matter what. Is there anything you can think of that I am missing? Thnx for your help, this is so weird
You're missing a # sign to mark the LDA operand as Immediate - without it, you're just reading a variable from RAM.
omg wow thank you. I feel rllllly dumb now. that fixed it
Haha, I think everyone who's worked with 6502 assembler has made that mistake at some point. It's completely normal :P

Re: Sprites will not show up

Posted: Tue Sep 15, 2020 5:28 pm
by Controllerhead
The rake strikes again! viewtopic.php?f=2&t=19983#p249224

I made mine red. Helps. Sometimes...

Image