color palette for FPGA users

A place for your artistic side. Discuss techniques and tools for pixel art on the NES, GBC, or similar platforms.

Moderator: Moderators

psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

color palette for FPGA users

Post by psycopathicteen »

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.
User avatar
MottZilla
Posts: 2837
Joined: Wed Dec 06, 2006 8:18 pm

Post by MottZilla »

Or you could just output RGB and use one of the many video encoder chips used in commercial game consoles like the Sega Genesis.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

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.
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg »

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.
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames »

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. :P


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! :P 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.
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Post by Memblers »

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.
User avatar
kyuusaku
Posts: 1665
Joined: Mon Sep 27, 2004 2:13 pm

Post by kyuusaku »

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
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

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.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Post by psycopathicteen »

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

Oh crap!!!
User avatar
Jeroen
Posts: 1048
Joined: Tue Jul 03, 2007 1:49 pm

Post by Jeroen »

Well if you're serious about making your own fpga console....yes you should know this.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Post by psycopathicteen »

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)
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Post by psycopathicteen »

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.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

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.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Post by psycopathicteen »

[*]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.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

This constructive criticism is here to help you avoid crippling bottlenecks that programmers for your console might discover:
psycopathicteen wrote:I'm planning on 128-kB of SRAM for the FPGA, that can also be accessed with the 63C09.
CHR RAM accessed how fast? If you've ever played Videomation, you'll probably remember how slow its flood fill is.
The Neo Geo's sprites are actually vertical strips of 32 16x16 tiles, with a different attribute table for each tile.
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.
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.
But can sprites be moved between scanlines?
Post Reply