Questions on VGA colors and sprites

cbmeeks

I am curious how or if the Propeller could handle "TMS9918" style graphics with VGA.

Keep in mind, I could literally devote all 8 COGS to JUST a TMS "clone" but at least one COG would be needed to process outside requests from other chips.

Specs:

640x480 @ 60Hz (standard, lo-res VGA)
Active pixel resolution of 256x192 with perhaps a small border.
32 sprites with at least 4 per scanline
Sprites are normally 8x8 pixels but can be doubled to 16x16.
Sprites can also be "zoomed" to 2x size (fat pixels) which means 4 sprites on one scanline doubled and zoomed = 32 x 4 = 128 VGA pixels (half resolution)
Sprites are one color each.
All modes except one is character (tile) based. Each character is either 6x8 or 8x8 pixels


Now, that's the minimum specs. Now, let's assume worse case here:

X = background (black)
R = Sprite 1 (red pixels)
G = Sprite 2 (green pixels)
B = Sprite 3 (blue pixels)
P = Sprite 4 (purple pixels)

XRGBPXXX

That is as tight as you can get. So, the way I understand it we would use VGA mode with 4 colors. Something like:

WAITVID COLORS, %%3210  // first four pixels
COLORS := %000000xx_110000xx_001100xx_000011xx     // xx = Don't care because they are actually the H/V sync

... load next batch of COLORS

WAITVID COLORS, %%3210  // first four pixels
COLORS := %110011xx_000000xx_000000xx_000000xx     // color 3 = purple, colors 2,1,0 = black

Assuming my understanding is correct so far:

1) How would the PixelClocks and FrameClocks be set? I still get lost calculating these.

2) Can the Propeller push this many pixels for VGA?

Bonus questions!

3) Anyone who has ever used the TMS9918 knows the 4 sprites per line is frustrating. Could the propeller push the entire 32 sprites per line with more COGS? Perhaps the sprite rendering COGS could determine that within a 4 pixel line, only 4 sprites could be rendered at most (assuming 1 pixel sprites).

4) The TMS9918 typically was maxed out at 16K of VRAM. If I used a 16K HUB buffer, with a few extra line buffers, would I have enough left over for the actual driver? 16K seems to be pushing it.

5) Is it worth exploring non WAITVID techniques to drive VGA? Especially since I can devote all COGS to driving video. Heck, I even thought about devoting a COG to driving external SRAM and translating the reads/writes out to it so that I could add extra modes like full bitmap.

Thanks!!!

macca

There are a lot of discussions on this forum about graphics modes, tiles, sprites and game engines that should almost cover all your questions, just do a little search.

1), 2) and 5), take a look at the work from Marko Lukat (kuroneko), it has a wonderful collections of video drivers using various methods to obtain the desired resolutions. It has a github repository https://github.com/konimaru/waitvid.2048.git

3), I wrote a couple of tile/sprite engines that may do what you need, that http://forums.parallax.com/discussion/146667/tile-graphics-renderer is capable to display all 64 sprites on screen and up to 12 on a single scanline but are limited to 16x16 pixels, no zoom. The engine I wrote for the Abbaye des Morts here http://forums.parallax.com/discussion/162813/l-abbaye-des-morts-ported-to-dual-propeller-board#latest can display sprites from 8x8 to 32x32 pixels but has a limit of 5-6 sprites per scanline (and by the way, this is using the 640x480 driver with an active screen of 256x192 pixels, like the TMS9918, if I understand correctly).

Hope this helps.

cbmeeks

Thanks for the links. I actually did search around but didn't seem to find examples of sprites, colors and VGA. Most of what I found was centered around creating really high resolutions with lots of text or full bitmaps. Perhaps my search terms weren't that great.

Anyway, I will look into the links you provided.

But I'm curious, what was the limiting factor for 12 sprites on a scanline and 16x16 size? Was it just the number of COGS you devoted to it or did you hit some ceiling as to what a propeller could handle?

The main reason I am looking into this is because I really would love to know if the Propeller could be a true replacement for a TMS9918/28. Not the enhanced Sega Master System version (or any of the Yamaha enhancements). Or, would an FPGA be required?

I know there is the F18A FPGA solution that is awesome. But, I just can't afford $70-$80 for a single one at the moment.

Thanks everyone!

macca

cbmeeks wrote: »

But I'm curious, what was the limiting factor for 12 sprites on a scanline and 16x16 size? Was it just the number of COGS you devoted to it or did you hit some ceiling as to what a propeller could handle?

The only limiting factor is the time needed to compute all the things required to draw a scanline and this depends on the resolution (the higer the resolution, the less time you have to build a scanline) and the number of cogs dedicated to the process. That drivers work with one cog dedicated to the actual VGA output and 4 cogs dedicated to the "rendering" process, each cog working on a scanline, so the time allowed is 4 times the lenght of a single scanline, 5 cogs total, you need 1 cog for the control process so you can dedicate 2 more cogs to the rendering increasing the number of objects per scanline or the effects you want to apply.

There is no limit on the objects size, 16x16 is a good compromise as most retro-games are using sprites of that size, the Abbaye des Morts game however uses sprites of different sizes, so I wrote a rendering capable of drawing sprites from 8x8 to 32x32 pixels in all combinations. The very limiting factor is the ram space, you need to balance the graphics details with the control code complexity.

cbmeeks wrote: »

I really would love to know if the Propeller could be a true replacement for a TMS9918/28.

From what I have read of that chip, the Propeller may replace it without problems, the 16k of video ram can be placed in hub memory, you have another 16k for the control code, plenty of space if you write in PASM.

Bill Henning

I managed to make:

256 color bitmap, 256x192

255 color sprites

8 sprites per scanline

horizontal split screen, each side independently vertical scrolling

a few years ago, but it required one of my dual-prop Morpheus boards with 512KB sram.

http://www.mikronauts.com/parallax-propeller/morpheus/

There should be a video floating around from a Propeller Expo ~4 years ago showing it.

Blank Morpheus rev.2 PCB's are in stock, I no longer stock the kits. The documentation is for rev.1 (but I can supply a rev.2 schematic.

Morpheus is NOT open source hardware, people interested in it need to buy the PCB's from me.

Daviduk

I'm sorry to resurrect an old post, but as you may have seen on previous posts, I'm currently looking into graphical solutions using Propeller. This looked rather interesting!

Is Morpheus, particularly rev.2, still available?

Thanks in advance.

Publison

You might want to ask Bill:

http://www.mikronauts.com/parallax-propeller/morpheus/

Daviduk

Thank you.