Re:What it was like developing for NES back in 1990
by FPGAhacker on Saturday August 07, 2021 @05:55PM
(#28102226)
And how would one know the bit was set... polling?
Re:What it was like developing for NES back in 1990
by nicetryguy on Saturday August 07, 2021 @11:09PM
(#28103919)
Yes: but it's messy. You spin in a loop with a BIT instruction polling the PPU_STATUS register and a BVC instruction pointing backwards waiting for bit 6 to be set. Besides the fact that you're stuck doing this, the main problem is synchronization, this little loop takes 7 CPU cycles (with each CPU cycle taking 3 PPU cycles, or 3 "pixels" of distance) leading to an 21 "pixel" variance. When dealing with the very short horizontal blanking period between scanlines, it leaves very little time to do anything meaningful with the PPU in that window.
If you've ever noticed some "weird flickering" near status bars in NES games, this is probably the culprit: Few very skilled developers were able to pull it off cleanly.
There are two other mechanism I know off the top of my head.
One is to put some circuitry on the cartridge, and then arrange the usage of tiles such that all the background tiles are in one bank and all the foreground tiles are in another. If you do this right, you get an address line which cycles high and low once each scanline–and you can put a circuit on the cartridge which counts the scanlines, triggering an interrupt. This was only available if you could put that circuitry (usually, a “mapper”) on the cartridge.
The last method is to count cycles.
I would note that among other differences, this is much, much easier on a Game Boy. The Game Boy has a register you can read which tells you which row you are on. Not the only thing that’s easier on a Game Boy—there’s also a hblank interrupt, and the tilemap is larger than the screen. Anyone interested in NES programming but unsure about how much they like dealing with obscure technical problems may want to try Game Boy programming first to get a taste for it.