The FPGA Videogame Console


The veeerrry first video I got out of the device. It's some counters and comparitors being used to produce the synch pulses and blanking and all that, and the same counters are being used to generate a video pattern on the monitor. This is the result.

This is the very first Nintendo video I got out of it after a 2 day session of designing the basic PPU. At this point I had the tile engine minus sprites. Of course there were some major bugs in the system, since I was getting corrupt graphics. The screen is supposed to look like Boulder Dash. :-)

After fixing one of the adders, things start to look a tad more recognizable. There's still a problem with the counters, however, since the X drawing is taking too long and it's wrapping.

There was another slight bug in the Y counter/adder, so that has been fixed here. Some of the graphics actually look like something!

Things are looking pretty good, but some of the latch lines were routed wrong so the graphics are appearing on the screen backwards. The horrible wrap is now being caused by me sending 15KHz video to the VGA monitor that is expecting a 31KHz signal.

After fixing the backwards tiles, I added a scan doubler circuit to the FPGA so that the VGA monitor would be happy. The scan doubler sends each NES scanline out twice at 1/2 clock so that the NES' 256 pixel X resolution fits the monitor's 512 pixel X resolution. The monitor's resolution is thus 512*480 pixels.

There's still some bugs left; at the bottom of the screen, the attribute table can be seen. This is due to the "attribute skipper" logic not working properly. At this point, scrolling doesn't work either.

Finally! The tile rendering engine is working! Attribute table entries are being skipped like they should, and I have a small state machine accepting inputs from my two debug pushbuttons that allow me to scroll the screen in the X and Y directions. It's very rudimentary but it works.

I was wondering what it'd look like if I didn't clock the scan doubler at 1/2 the monitor's pixel rate... and this is what happens. The image is repeated twice as the full resolution.

I had gotten the attribute table bits backwards, so the rocks were brown and the dirt was grey. This has been fixed, so the rocks are now grey and the dirt is brown. Muuuch better!

It LOOKS like there is a bug in the video, but this is one bug that should be here! A real NES console will display this exact same "bug" if the Y scroll register is set too high. The "junk" is actually the attribute table being shown.

I was playing around with the scrolling here. Not much to say.

Now, I have a Gauntlet screen up for testing. I loaded a 4 screen nametable here and was having fun panning around the entire thing testing everything out. This test proved that the tile rendering engine was relatively bug-free. The aqua hue is from me playing with the colour emphasis bits. Now it's time to move onto step 2: sprites!

After working another 2-3 days on the sprite engine, I fired it up and this is what I got. The screen was completely covered by one giant red sprite. Whoops! The cause? Shift registers set the "D" input high if they aren't connected! I had to manually ground out each input so that it'd shift in 0's after sending the sprite graphics out.

Nothing ever works on the first try it seems, and sprites are no exception. These red lines are from me turning the emphasis bit on when an in range sprite is detected and loaded into the OAM buffer for rendering. Throughout development, the emphasis bits have been used to debug the console. It allowed for a very simple way to see what's going on without interfering with the video display. Also, it shows EXACTLY where on the scanline something is occuring.

The same thing as before, but with the tile rendering engine turned on to see the results of the emphasis bit. (Since it had never been tested before.)

This is starting to look a bit better! Some clearly defined sprite fetch patterns are starting to become apparent.

And this looks even better! The sprite Y coordinate is being properly detected now.

Yeay! I have sprites... sort of. The same tile is being fetched instead of the proper sprite tile, and the palette is not being properly represented.

Finally. Sprites are being properly pulled and displayed on the screen! W00t. At this point, the PPU memory is all ROM-based. I do not have the read/write port at 02007h working at all.

Yep. The sprite priority encoder is working properly now. They appear on top and can clip behind the on-screen tiles (verified by scrolling the screen left/right).


All HTML and graphics designed and © by Kevin Horton .