Hello there,

I've been writing code for generating VGA signals through PIC32 and a framebuffer, with a resolution of 256x240 and with 8-bit color. However, it requires a lot of framebuffer memory and moving graphics are limited as it tears when it updates. The "double buffering" method helps, but again, it chews up even lot more of memory.

So I've been thinking of creating a VGA adapter based on sprites/tiles which is based on the early video game consoles like NES.

Again, the thing is, it requires a lot of hardware to handle such things as no current fast microcontrollers are capable of calculating each pixel on the fly.

Should I use an FPGA for this method? It looks like I'm dealing with very specialized hardware.

Thanks.

The Parallax Propeller might work for this, if you want to keep your graphics generation purely in software. Doing tiles & sprites can utilize some pipelining, performing fetches of tile, palette, & sprite information for a line separately before it's displayed. This prefetching allows the actual raster-timed display code to be much simpler.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Earlier today I found someone on youtube with a microcontroller game, with a resolution of 104x80, and 3 sprites per scanline, which isn't very impressive.

https://www.youtube.com/watch?v=-V-NlIAHX30

Apparently an Atmega328 @ 16 Mhz isn't very good at video games, since "chasing the dot" takes away a lot of performance. Using a faster version of the same chip could give you more bang for your buck, because if it is fast enough to do single scanline rendering, it wouldn't have the overhead of drawing the same scanline twice.

Parallax Propeller @ 32 Mhz should have no problem with rendering 256x240 graphics.

Could you please elaborate on the highlighted? How can a not substantially higher clock speed (without the corresponding increase in onboard RAM) permit scanline rendering as opposed to pixel-by-pixel rendering?

The Parallax Propeller runs at 80 MHz, not 32. It can be easily overclocked to 100 MHz if necessary. It has 8 cogs (cores), each running a different program. When you download and use one of the many video drivers from the Parallax Object Exchange (obex.parallax.com), it usually starts an assembly language program in a separate cog which then takes care of generating the video signal based on a buffer in hub memory. All that the other cogs have to do is modify that screen buffer. Since all cogs run independently, each cog can run at full speed except when they access the hub; then they have to wait for their time slot which happens every 16 clock pulses.

Programming the Propeller is a little weird at first because of the architecture which is very different from every other processor in the world. But once you get used to it, it's pretty easy and you can do some amazing things. For example, in the project I'm working on (http://www.propeddle.com) and the project that I helped Vince Briel with (http://www.brielcomputers.com/phpBB3/vi ... =36&t=1515), The Propeller sits on the 6502 address bus and data bus and can interpret reads and writes of the 6502 from/to a designated memory area as reads and writes from/to the screen buffer.

A major disadvantage of the Propeller is that it only has 32K of memory on board. That means that video drivers are usually text based or tile based, not pixel based. I don't know if there are any video drivers that feature sprites but I reckon it should be possible, especially at video frequencies for standard definition screens (VGA may be more difficult). I have some ideas about generating more complex video using external hardware, for example by storing pixels in an external memory chip or by letting two or more Propellers work together. But that will be something for a different post.

===Jac

I think the Parallax Propeller has a lot of untapped potential. Most old school gaming systems used multiple tile-based layers, and a line buffer to render multiplexed sprites. I bet that you can have 320x240p 60fps, and 15-bit color, with several BG layers and lots of sprites. If you clock it at 100mhz, you can time the output by the HUB's access cycles.

Creating a pixel-level VGA driver isn't very difficult to do on an FPGA. However, it would probably be better to use tile-based rendering because of the space it saves while still permitting flexibility in art, and saving CPU rendering time. But if the SNES's PPU is any indication with it's rather confusing storage mechanism, rendering tiles requires quite a bit of glue logic. As Aaendi mentioned, you need muxes which priority-encode layers. But I think the bigger issue is mapping a tile to the current beam position... if a tile is x-by-y pixels in contiguous VRAM*, one needs to send x pixels to the frame buffer, then skip to the offset of the first row of the next tile. Then when 240/x tiles have been rendered, the glue logic needs to go to offset x in the initial tile (pixels 0 to x-1 were sent the last scanline). I can imagine the state machine for that getting complicated, and I don't think a software-based tile solution really alleviates much.

*For this example, I'm assuming a monochrome tile format, where "1" is white, "0" is black .

EDIT: Screwed up part of my example... should be fixed now.

The N8VEM project has an interface board using a Propeller board for VGA generation:

http://n8vem-sbc.pbworks.com/w/page/22474152/PropIO

Another benefit of the Propeller chip is the SID cog software which lets it emulate a SID chip. That would be right at home on any 6502 project.