nesdev.org

It's been almost a year since I've looked at my old NES emulator (and the code is ugly....ugh) but I want to get back in the swing of things. First off, I'd like to solve an issue that had been plaguing me for a while. I still cannot figure out how to correctly load the two attribute shift registers...

Joe wrote:The next adjacent tile might change all the bits in the coarse X, but what about the previous adjacent tile?

Wouldn't the previous adjacent tile also potentially have all coarse X bits flipped?

That makes perfect sense, but I'm not exactly sure how to remedy the issue. Potentially, every bit in the coarse X could flip by time the next attribute reload happens (which would be an adjacent tile). The only possible fix I can think of is only reloading the attribute registers every 16 cycles to...

Honestly, not so much. I can't seem to find anything on the wiki about how the attribute shift registers are filled. I wrote that piece of code in August and I want to say that I found the information in a thread on here somewhere. I can't find that thread either of course.

This is how I am fetching the attribute byte: attAddress = 0x23C0 | (ppuAddress & 0x0C00) | ((ppuAddress >> 4) & 0x38) | ((ppuAddress >> 2) & 0x07); attFetch = VRAM->readVRAM(attAddress); And this is how I'm filling the two attribute shift registers: { bool xBit, yBit; //Holds the coarse...

I flipped the way my shift registers were shifting and the order I was grabbing my tile bits and nothing is flipped anymore. Thanks guys!

The color on the top of the screen is still off on the demo screen. Could I have a bit issue again?

Alternatively, do you have the endianness of the PPU tiles backwards? PPU bits are big end first/on the left. I wasn't aware that the PPU was big endian. Where exactly would this effect things? The multiplexors for the shift registers maybe? The bit order in individual CHR tiles. It looks like each...

Joe wrote:Wait a minute, are all graphics horizontally flipped? You might be interpreting bit order backwards.

The "Donkey Kong" title seems to be correct and the demo stage seems to be the right way. The rest looks flipped. Which bit order do you mean exactly?

Thanks. I fixed those errors. I've been slowly removing repeated code as I see it, but sometimes it does slip by me. I'm insanely close now. I'm finally getting the title screen and the demo screen to show up. For some reason, the text below the Donkey Kong title is backwards and the demo screen is ...

I've been working on my emulator quite a bit and I've made quite a bit of progress. I switched to SDL 2.0 for easier pixel manipulation, confirmed that my pattern tables, nametables, attribute tables and palettes are being filled correctly for Donkey Kong, confirmed that I am fetching the correct by...

I made quite a bit of progress today. I switched from freeglut to SDL 1.2 because SDL's input looked much easier. I then took a dump of VRAM at the Donkey Kong title screen and compared my dump to a VRAM dump from Nintendulator. The good news is that I am writing to VRAM correctly because my pattern...

Ah yes! That is what I meant. My lower and upper background tile names came from my own code, which was obviously confusing. Where does the bitplane bit come from?

I think my main issue right now is that I don't know how to calculate the address for the lower background tile. The skinny on NES scrolling gives the formulas for calculating the nametable address and the attribute address: tile address = 0x2000 | (v & 0x0FFF) attribute address = 0x23C0 | (v &a...

2. bit $10 of $2000 is correct but I don't really understand the rest of that code. How closely are you following loopy's PPU information? I've implemented everything from this document: http://wiki.nesdev.com/w/index.php/The_skinny_on_NES_scrolling . I can't find anything on the wiki about how to ...

Alright guys, I'm back. School is over and I'm ready to work on my NES emulator again. I'm still working on getting backgrounds to render correctly. I've tested the individual functions of my PPU and they *seem* to work correctly on their own. With that said, rendering still isn't correct, so I have...