NES emulator struggles

A place where you can keep others updated about your NES-related projects through screenshots, videos or information in general.

Moderator: Moderators

Post Reply
DenSinH
Posts: 2
Joined: Fri May 01, 2020 8:04 am

NES emulator struggles

Post by DenSinH » Fri May 01, 2020 8:45 am

Hello all!

For the last few days/weeks I have been having fun trying to make an NES emulator, and it has been going quite well so far. Emulating the CPU was not too hard, as most CPU's have the same jist, and I got it to work cycle perfect, matching the nestest.log file (at least as far as I know, maybe there are some strange edge cases that aren't in nestest.nes). Then I started on the PPU. Man was I struggling. After reading a lot of pages on the NesDev wiki, and watching SomeLoneCoder on Youtube explain some stuff, things started to click, so I started on the PPU. After getting the palette ram to load I was quite proud, and I started implementing all the other background related registers, and then finally the actual rendering of the background.

Now I'm a bit stuck however. Rendering the background is almost working, but not completely. I loaded the sprite tables as I thought I should from an INES file, and I implemented some way of showing them on screen, which seems to be working properly. As well as the palette ram is still the same as it is for SomeLoneCoder on Youtube. However, my rendering is off, it loads almost all sprites in the right places, but there seems to be something going wrong with the Nametables. I suspect it might be a timing issue or something, but nestest renders like this:
nestest_faillure.PNG
As you can see, it almost loads properly, except the top line says "Run all**ests", instead of "Run all tests" like it should. On the left side is the contents of Nametable0 and the corresponding attribute table below. When you compare it to the nametable as seen here: https://youtu.be/-THeUXqR3zY?t=2780, it is clear that the nametable entries are also off in those precise locations. Now this rendering mistake is pretty minor, but it can get quite bad, for example looking at Donkey Kong:
DonkeyKong_faillure.PNG
Only a few textures seem to load, and not even in the right palette... But I can't really figure out what is going wrong. My code is in this github repo: https://github.com/DenSinH/NESC-/tree/m ... esEmulator. I don't expect anyone to really look through it, but I'd love some pointers for where it might be going wrong, or maybe some of you have seen something like this happen to your project, . Maybe someone has a log file I can compare my CPU and PPU operations to for some ROM with visuals. I also tried loading some of Blargg's roms for PPU testing, but they don't seem to render properly either, not displaying a number as they should, but 2 random characters and some weird pattern of textures in the background... I tested my CPU pretty thoroughly so I don't expect that that is where the problem lies. I have also looked over the PPU render timings diagram on the wiki multiple times, and verified that mine are the same.

I will keep searching, but any input is welcome!

User avatar
Quietust
Posts: 1596
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: NES emulator struggles

Post by Quietust » Fri May 01, 2020 10:35 am

nestest.nes copies the test list onto the screen in bulk, then indicates the currently selected test by drawing a column along the left side containing a single "*" and blank space for the rest (by setting the VRAM address to $2002 and setting it to increment by 32) - I don't know what could cause that code to write two asterisks side by side, especially without clearing out the rest of the line.

Maybe your PPU is incorrectly updating the scrolling/address registers while rendering is disabled?
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

DenSinH
Posts: 2
Joined: Fri May 01, 2020 8:04 am

Re: NES emulator struggles

Post by DenSinH » Fri May 01, 2020 11:12 am

@Quietust Hmmm, okay so I had it set to where it would always increment the V register by either 1 or 32 on a $2007 read or write, but I guess I should set it to update like this only when the scanline is not between -1 and 239, and the BackgroundEnable and SpriteEnable bit in the Control register are disabled. When I do this however, it doesn't change anything. When I don't check for the scanline and only for the rendering bits, it is slightly better, but there are still 2 asterisks, however then at the top of the screen, and Donkey kong still looks about the same in that case...

Post Reply