nesdev.com

Something I would like to do someday is design my own game console using an FPGA. Eventhough I'm a long way away from actually doing it, I do a lot of thinking and planning for it. Since converting RGB into a NTSC is pretty complex I came up with a way of cheating.

I call it the PCM color palette. It works with a 10.53 Mhz video signal, every colorburst wave is 3 subpixels long, and colors are stored by the wave height of those 3 subpixels.

When rendering the 3 subpixels at phases 105 degrees, 225 degrees and 345 degrees, you have a color space very similar to RGB only with a few differences, such as:

Red (105 degrees), Green (225 degrees) and blue (345 degrees) would be of equal intensity .333:.333:.333 instead of .299:.587:.114, and some colors will be out of the RGB gammet.

I guess you can compensate for the out of gammet colors by use of an artistically chosen hardware color lookup table, that prevents use of illegal colors.

I made a picture of how a 6-bit PCM color palette looks like. I'll post it when I get home.

Or you could just output RGB and use one of the many video encoder chips used in commercial game consoles like the Sega Genesis.

MottZilla is right: you'll want something that can output NTSC S-Video, PAL60 S-Video, and component at 480i and component and VGA at 480p if you want to cover all your bases.

It's just the basic approach to development: start with standard stuff. Then once you have things working well enough, start seeing what parts are worth customizing/doing yourself, and whether the benefits really outweigh the costs.

You can pull a Williams and use 48K of RAM for RGB graphics and make a circuit that outputs them....I have no idea if you could also have another circuit outputting other video types from that....But what the hay, it's an idea.


I google'd 2D Graphics chip....are these not really available anywhere? You'd think something like that would be still produced today and have a standard. :/ It must be one of those things replaced by software.....



This a really cool project. I was thinking of doing something like this but since I know nothing about logic of CPU's and volts and stuff, it's out of my capability, but still.....I want to learn all that one day and attempt this too. A 2D homebrew system in todays world would probably be better then the NES, and maybe up to par with SNES! Technology has advanced so far. It's scary!


Oh well too much stupid stuff. I just get excited seeing people try this stuff. Good luck man! I can't wait to see what you come up with.

Well, there are 2D graphics chips, even NES graphics, but it's almost sure to be part of a system-on-a-chip (being cheaper overall, in huge quantities only). And really other than the Texas Instruments chip used in the Coleco, and MSX, I don't think there ever was any kind of off-the-shelf 2D graphics chip.

I don't see the benefit of this over a true composite encoder, they don't use a lot of resources or anything and if you only want 9-bit RGB you can easily build a 6-bit DAC that will work fine.

http://nesdev.com/bbs/viewtopic.php?t=4189

Or you could make the palette YUV (not HSV like on the NES), clock the DAC at 4*Fsc (14.32 MHz), and output Y+U, Y+V, Y-U, Y-V. Apple II uses something much like this.

Once the prototype is working, the problem will become one of attracting developers and one of making enough units of your console to ship to customers.

...and everybody is jumping to conclusion that I actually know how to do this.

Oh crap!!!

Well if you're serious about making your own fpga console....yes you should know this.

A few years ago I was more serious about it, and I was looking around for FPGA's and Microcontrollers, but wasn't sure if I wanted to invest all my money into it just yet. I'm just afraid I'll buy the wrong one and have to buy another one.

Once I become a little older and more independent of my own money (I'm only 19 and living under my parents) I would take action.



The technical specifications that I've decided to stick with so far are:
-6309 cpu core
-336x224 screen resolution
-256 out of 32000 colors (either RGB or "PCM" color palette)

I'm thinking of considering a NeoGeo-style sprite system, where everything is made out of sprites and there is no hardware background layer. It will be easier designing an FPGA for that than an SNES style PPU.

Not all video games can be made in a display model that uses only sprites with predefined textures. For example:

• How would a game like Qix work under your planned system? Ordinarily, it works by drawing fences in the manner of an Etch-a-Sketch and then flood-filling once the new fence reaches an existing fence, but that requires an all-points-addressable display mode. That's doable on a system with CHR RAM, but apparently the NeoGeo uses CHR ROM only.
• How would a game like Tetris work? Tetris needs up to 9*20=180 sprites for the blocks in each playfield, plus the falling piece, shadow, next piece(s), score counter, and playfield border. Just two players would put it over 380, the widely reported NeoGeo limit.
• Racing games will need some sort of deformation, at least shearing (Pole Position style) if not flat-out scanline texture mapping (F-Zero style), to draw the track. Even 2D fighters and basketball games shear their floors.

You could make a tile map reader that feeds fake sprites to the sprite compositor.

[*]How would a game like Qix work under your planned system? Ordinarily, it works by drawing fences in the manner of an Etch-a-Sketch and then flood-filling once the new fence reaches an existing fence, but that requires an all-points-addressable display mode. That's doable on a system with CHR RAM, but apparently the NeoGeo uses CHR ROM only.

I'm planning on 128-kB of SRAM for the FPGA, that can also be accessed with the 63C09.

[*]How would a game like Tetris work? Tetris needs up to 9*20=180 sprites for the blocks in each playfield, plus the falling piece, shadow, next piece(s), score counter, and playfield border. Just two players would put it over 380, the widely reported NeoGeo limit.

The Neo Geo's sprites are actually vertical strips of 32 16x16 tiles, with a different attribute table for each tile.

[*]Racing games will need some sort of deformation, at least shearing (Pole Position style) if not flat-out scanline texture mapping (F-Zero style), to draw the track. Even 2D fighters and basketball games shear their floors.

Neo Geo's sprites have a join bit that joins the next sprite to side of the last sprite. If you move one sprite, several sprites will move with it.

On my FPGA project, I will have a regular join bit, and a tile-per-offset join bit that keeps the next sprite at the side of the last sprite, but uses it's own individual y-coordinate.

This constructive criticism is here to help you avoid crippling bottlenecks that programmers for your console might discover:


CHR RAM accessed how fast? If you've ever played Videomation, you'll probably remember how slow its flood fill is.


Then they're almost more like narrow planes than like sprites per se. In Tetris or Dr. Mario, for example, each column of the playfield would be two sprites, or 48 in all for two Tetris playfields in four join groups, plus sprites for falling, ghost, and next pieces. That sounds more reasonable.


But can sprites be moved between scanlines?