I had a lot of questions, but most of them are now solved thanks to your support
Before proceeding, I wrote my "hello, world" ROM where I implemented most of the ideas that I learnt.
Sadly, when I load it on my real hardware (AVS retroUSB + EZ Everdrive N8 Pro), I just get a blank screen.
Does anybody know, what the cause might be?
In case, my code is attached. Thanks in advance for your help!
Ps: the code shows a "Title Screen". After pressing Start, you move Mario and get a Game Over when hitting Goomba.
Everything very rudimentary, just for the sake of practicing.
Code: Select all
WaitForPPU: bit $2002 ;makes sure the vblank flag is off Wait: bit $2002 bpl Wait rts
In which emulators have you tested this? If you can find an emulator which gives the same result as on hardware that has at least some debugging features, you can try tracing through the code to see if all the code is executing as expected.
Thank you so much, especially for having clearly explained the reasons beyond any suggestion
Code: Select all
NMI: ;(do all your NMI stuff here) IRQ: ;<-- point the IRQ vector to this label, instead of 0 rti ;returns from either the NMI or the IRQ
Now for the biggest problem in the Nerdy Nights tutorials: the entire game logic runs during vblank! The NMI signal is there to notify the CPU that vblank has started, so that you can make the most out of that short period and do all your video updates (sprites, name tables, palettes, etc.). But that's not how the tutorials use it, instead they do a bunch of tasks that have no place running during vblank, such as reading the controllers and reading sprite, and only after that will it carry out the necessary video updates.
Since video updates can only be done during vblank, this means that both the game logic and the video updates have to fit in the vblank period, witch is a measly 20 scanlines out of 262. That's right, Nerdy Nights programs can only use less than 8% of the CPU power of the NES before they start to glitch.
I'm not sure if they fix this in later lessons (I hope they do!), but sometimes you see people trying to create basic games such as Pong using Nerdy Nights as a base, and the games suddenly breaks because they added too much logic and the video updates started spilling out o vblank and into rendering time.
The simplest fix here is to invert the order in which you do things in the NMI handler: first do the video updates (using data computed during the previous NMI), then process the game logic for the *next* frame. Just be careful to not do a glitchy round of video updates the first time the NMI handler runs, possibly by having a flag signal whether the NMI handler is supposed to do any video updates. A flag like this is normally needed anyway for cases when you want to disable rendering and do big name table updates, so the NMI handler won't interfere with those.
Nope, at least not in Bunnyboys tutorials (though which are great in many ways anyway) IIRC. The Nerdy Nights sound tutorial by Metalslime does teach you this however which is one reason it's also great. It's a sound tutorial but it actually teaches you how to make a buffering system for the graphics, just for the purpose of the simple music player interface it uses to teach sound.
I highly recommend to look at this tutorial after you are quite comfortable with what's taught in the regular tutorials.
My apologize for being so late (busy with work): I saved your post in order to be ready when I am more comfortable with NES programming