PAGE 1
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).
|
