6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Fri Nov 01, 2024 5:26 am

All times are UTC




Post new topic Reply to topic  [ 8 posts ] 
Author Message
PostPosted: Fri May 02, 2014 3:35 am 
Offline

Joined: Fri May 02, 2014 3:09 am
Posts: 4
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. :)


Top
 Profile  
Reply with quote  
PostPosted: Fri May 02, 2014 10:47 am 
Offline

Joined: Tue Jul 24, 2012 2:27 am
Posts: 679
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


Top
 Profile  
Reply with quote  
PostPosted: Fri May 23, 2014 10:52 pm 
Offline

Joined: Wed Jun 26, 2013 9:06 pm
Posts: 56
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.


Top
 Profile  
Reply with quote  
PostPosted: Mon May 26, 2014 9:37 pm 
Offline

Joined: Wed Feb 05, 2014 7:02 pm
Posts: 158
Aaendi wrote:
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?


Top
 Profile  
Reply with quote  
PostPosted: Tue May 27, 2014 3:33 pm 
Offline
User avatar

Joined: Thu Jun 23, 2011 2:12 am
Posts: 229
Location: Rancho Cucamonga, California
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


Top
 Profile  
Reply with quote  
PostPosted: Sun Jun 01, 2014 5:42 pm 
Offline

Joined: Wed Jun 26, 2013 9:06 pm
Posts: 56
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.


Top
 Profile  
Reply with quote  
PostPosted: Sun Jun 01, 2014 7:38 pm 
Offline

Joined: Wed Feb 05, 2014 7:02 pm
Posts: 158
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 :P.

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


Top
 Profile  
Reply with quote  
PostPosted: Wed Jun 11, 2014 2:26 pm 
Offline

Joined: Wed Jan 08, 2014 3:31 pm
Posts: 578
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.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: