hi everyone! i'm trying to write a nintendo nes emulator. i'd written almost the 50% of the cpu core, but i have some doubts with the video emulation.
i'd already took a look to ppen source nintendo nes emulators, but since the source code it's not commented it's hard to understand.
i'm just asking for a few advices to write my own PPU emulator. where should i start writing the ppu emulator?
any advice will be greatly apreciated!
PD: sorry about my poor english, i'm from argentina
To start emulating the PPU, first emulate the timing signals it generates: vblank, vblank NMI, and hblank. This involves bit 7 of PPUCTRL ($2000) and bit 7 of PPUSTATUS ($2002). This will at least get games that don't use a split screen to start running without video.
tepples wrote:
To start emulating the PPU, first emulate the timing signals it generates: vblank, vblank NMI, and hblank. This involves bit 7 of PPUCTRL ($2000) and bit 7 of PPUSTATUS ($2002). This will at least get games that don't use a split screen to start running without video.
thanks for your answer tepples!
in that way, wich games do you recommend to start testing my emu? obviusly it'll be a game with mapper 0, but there's any game in particular that you recommend to start with?
If you want a sequence of increasingly complex test cases from the NES commercial era, try these, in this order:
- Mario Bros. and Balloon Fight (1 player mode)
- Balloon Fight (Balloon Trip)
- Super Mario Bros.
- Milon's Secret Castle (mapper 3)
- Contra (mapper 2)
(Why do I sometimes appear to have a Balloon Fight fetish? XEvil's chopper boy character helped introduce me to a play style that originated in Joust and Balloon Fight; a meme on DDREI.com around the release of DDR Extreme (U) for PS2 locked it in.)
ok thanks again!
I'd like to recommend Donkey Kong and Donkey Kong Jr. Both are easy to get running with very primitive video register emulation.
Mario Bros you have to be sure to have implemented PPU reading via register 2006/2007 or else the game won't run properly.
When you are ready to step above NROM, UNROM is a great mapper to attempt first. Contra as mentioned isn't terribly hard to get running, also Mega Man is another.
another question came up to my mind. do you think it's a good idea to programm a tile viewer (like Tile Layer Pro... but mucho more simply) to get the hang with the PPU emulation?
It depends on how you emulate video, but it doesn't hurt to get used to dealing with NES 2bpp format tiles. When I started I did a basic tile based drawing for rendering. So I did sort of what you are saying by first making the function to draw a tile, and then using it first to show all tiles in PPU space 0000-1fff. After that I used it for some basic PPU emulation.
Tile based rendering is enough for some games like Donkey Kong, Contra, and Mega Man. However once you start using mid-frame scroll changes for status bars then you may want to move on to line rendering.
Something else to keep in mind with video emulation is there are 3 different levels of PPU accuracy. The least accurate would be rendering by drawing full tiles and drawing the entire screen once the final frame scanline has been executed by the CPU. It works for simple games fine.
The next level would be rendering by drawing each scanline. So you'd run roughly a scanline's worth of CPU cycles, then draw the scanline. This is pretty accurate and works fine for most games.
The final level would be pixel accurate rendering, where you constantly draw pixels at the same time as executing CPU cycles. This would be required for the ultimate hardware accuracy. It's very slow though it is fairly easy to understand.
So I would recommend you do what you are thinking about and make it so you have functions to draw the tiles in a tile viewer.
wow thanks MottZilla! your techniques describement were really helpfull!!!
about the third (and ultimate
) thecnique, it seems as interesting as hardful to apply! bet that LoopyNES is the only emulator cappable to do that
Balloon Trip-mode in "Balloon Fight" has a very ugly CPU-timing loop for splitscreen scrolling. Could be usefull for checking out accuracy of your CPU-emulation.
Actually, the 3rd technique of pixel based rendering is used in several emulators. And no it's not hard, infact it's pretty easy in my opinion. But it's very slow unless you optimize it.
For most games, scanline rendering will work fine. LoopyNES is a good NES emulator but I don't believe it uses pixel based rendering.
Look at marble madness, that will instantly tell you whether it's using pixel-based rendering or not.
LoopyNES appears to use pixel-based rendering, but has timing errors for that game.
If you can make scanline rendering significantly faster than pixel rendering, go ahead and use it. PocketNES (a fork of LoopyNES for GBA) uses scanline rendering so that it can take advantage of the underlying platform's 2D acceleration, and Dwedit can tell you about the smart approximations it does to make tricky games like Marble Madness look decent despite the fact.
ok ok thanks again! but i'm still sutcked... i don't even learn how the NES shows graphics... i'm reading all the stuff i could get, but it's complicated. this project is driving me crazy
It's not that hard. Just be sure to stick with it and not give up.
MottZilla wrote:
It's not that hard. Just be sure to stick with it and not give up.
yeah, i try and try and try, but nothing comes out
i'll keep reading and investigating. of course i'm counting with your help me too, you'll be my guiding light
of course you'll be credited on my NES emu "About..." menu
sorry for being such a ballbreacker
Well, if you are writing an emulator as a way to learn more about the console then it's only natural that you hit your head at the wall every once in a while. Through trial and error you'll verify what works and what doesn't.
tokumaru was right with this one. I have hit walls many-many times
.
but i didn't give-up, Nes emulator development is really fun.... hope my emu grows more accurate