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
Video emulation problem on a Nintendo NES emulator
Moderator: Moderators
thanks for your answer tepples!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.
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)
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.
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.
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.
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.
) thecnique, it seems as interesting as hardful to apply! bet that LoopyNES is the only emulator cappable to do that 8)
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.
For most games, scanline rendering will work fine. LoopyNES is a good NES emulator but I don't believe it uses pixel based rendering.
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.
