nesdev.org

I wonder why the French NES didn't use a PPU that outputted an RGB palette.

I don't know what happened to Anonimzwx from Discord, because I heard he was making one of these things. I decided to try to come up with (I know you're probably going to facepalm this) an algorithm that is doable on a 65816, because that's all I know. So I would have to divide this into 3 parts: 1)...

Now that I think about it, the fact that VRAM is always available to the CPU is the does help a lot with reversing sprites, because you don't have to buffer everything in RAM first.

How did SMS games end up getting around the no-sprite flip limit? SMS sprites already took up more memory than NES sprites.

I like how it went off on a tangent about vram bus bandwidth. The only reason why the SMS has a 16-bit bus is because the VDP has 4bpp colors as opposed to 2bpp on the NES.

What was the technical reason the System-16 boards had 3bpp BG layers?

How many colors can the System-16 do at once in total?

I wonder what happens if you run the GameBoy and SNES versions through the same controller input. I remember the controls being off, but not quite this bad.

I just had an idea for a Y/C separation technique for SNES and NES composite output. Instead of the chroma signal being filtered horizontally and vertically, it gets filtered diagonally too. It works with the NES and SNES because they have a 3 phase rainbow swirls in both vertical and diagonal lines...

The graphics are pretty good, but the collision detection, controls and camera movement needs fixing. The samples are really muffled as well.

This is a major bump but I always find this stuff interesting. If I were making a NTSC decoder optimized for NES and SNES I would use an ADC sampling rate of 21.48 Mhz so that it's divisible by both the NTSC color carrier and the NES dot clock. Comb filter shouldn't allow any 3.58 Mhz vertical B&...

I'm guessing a good rule of thumb is, if you're using a lot of sprites onscreen in an SNES, avoid making the main character or 'regular' sized enemies more than 32 pixels wide, per line, unless the enemy is supposed to be intimidatingly huge or if you absolutely need to.

Never mind I figured out what I did wrong. Turns out it's better to filter first, then shift, instead of shift first and then sample. Shifting first can cause it to overflow.

I've always expected the 4 bit samples representing values from -8 to 7. Now I'm wondering if it's supposed to be -7.5 to 7.5 instead because I can't get the conversion math correct.

This sounds a lot more complicated, but I think I understand it. Start the frame with the CPU, when you read or write, get the SPC700 to catch up. When a frame is done, let the SPC700 to catch up again.