Yes it did, and they used more pins to bring it to a lot of colors.
Specs on the ATmega644 are 4K RAM, 64K program (and I think that's flash), and some 2K EEPROM. That's 20 Mips.
The actual game runs in C, linked to a library featuring video and sound done "in the background", via interrupts. Actual game throughput is probably on par with what we get in SPIN, with some nice bursts during blanking times.
It's totally viable to drive one of these chips with a Prop, and that's exactly what Baggers and Coley did early on.
Seems to me, a Prop could also just deliver the video signal reference clock, via one of the counters too. I think that cuts the part count some, for the cases where the main CPU are clocked at some non-multiple of the color burst.
Couldn't you increase the color depth of composite/s-video by syncing two cogs, and running the TV driver on each, but on separate pins with different resistor ladders? I would think the prop would make a decent dedicated graphics chip as long as it's connected to some SRAM or something like that.
On another note, I tried your potatotext demo, potatohead. Color and resolution looked good, though I only tried it on my LCD projection TV, I got a few small displays coming in the mail. I haven't really looked at the code, but I imagine the method you used for coloring wouldn't be practical for use with bitmaps, correct?
Just took a brief peek at the demo to see set resolution. 340 is better than I would have thought it would be, but now I got to know what 512 or 640 would look like.
Potatohead said "Nope. It's got a very narrow tolerance to prevent color variations. It's tight enough that using a resonator instead of a crystal is enough to lose the color."
While you're most definitely right, I'm thinking that some of these SoC decoder chips that they use on modern small LCDs just *might* be able to lock their colorburst PLL to an higher than standard frequency. Well, I guess if anything, it's worth a shot when I get my displays in. I'll tear 'em apart too to see what they use for chipsets.
The spec is plus or minus 10 hertz!!! Many displays will tolerate a few hundred hertz tops. I've tried variations as small as a coupla percent and got rainbows. The displays just won't bend that far, I'm afraid.
@Mark: Yeah, it's actually 320, and that looks flat out great, IMHO. It's very useful, given you don't do some things. --exactly the things shown in the demo. I put them there just for people to use as a display metric. If you run it in mono, those smaller detail patterns work just fine on most displays I've tried. I just learned today how to really clean up the mono, even when color information is presented to the prop. I'll be adding that switch to the driver on the next pass.
As for color, doing a bitmap in color at those resolutions is just fine. The problem is RAM. Tiles would work however. That driver was structured for high density text, and the two color mode works with fonts. There are two colors reserved for a mouse pointer, and those two free range on the screen. That's actually what I'm coding on right now.
In that driver, there is the TV COG. It just draws whatever it finds in it's scan line and color buffers. Those could be changed to just be a full color scan line buffer pretty easy. That puts any propeller color at any pixel. From there, use another cog, or cogs to feed it tiles, sprites and bitmaps, as the HUB memory allows for. In that configuration, some planning would yield a pretty excellent display from composite. Full on bitmaps don't work on the Propeller because of HUB memory. Frankly, existing drivers get it done, because of the resolution limits in play. It's tough to get more than 160 pixels bitmap, for memory reasons. Higher resolution things either need to be color limited, or tiles, or sprites, or all of those things. The only exception is dynamically drawn displays, and the best examples of that are Baggers WOLF3D demo, and the work Linus did. Not suitable for general use, but awful fun!
I've another driver, built off that TV cog in process that does 4 colors per text tile. I plan to get a little help with sprites for it. Baggers and Eric have posted up nice sprite code. That's going to be a bit though. I chip away at these things. If you want to start hacking on that TV cog, feel free to do so [noparse]:)[/noparse]
It's worth pointing out the kit OBC mentioned above runs right at the sweet spot for composite. Horizontal resolution is 224 pixels. It's the increased color depth that people are liking. Propellers out of the box, do that resolution nicely, and with quality comparable to what that chip outputs, just FYI. The difference is fewer stock colors, 80 - 120 or so, as opposed to 256. We've got one Propeller driver that does exactly that, and it's Eric's sprite driver. That one could be modded for tiles. Maybe it should be...
The "scan doubling" used in potatotext is the higher end output option that delivers the best overall quality at higher resolutions. That's part of why I did it. Been wanting a "scan doubled" display for a long time... not many devices did it. I saw one a long time ago, and really liked it for TV. Most do either the full vertical resolution, or half vertical, limiting the overall display quality somewhat.
Short answer: Yes. It works nicely on VGA. On NTSC, I have trouble getting the PLL's running together for color. A grey scale cog can be done. One could run 160 or 320 pixel color on one COG, and 640 pixel luma on another for a very nice display, overdriving it a little. For a dead nuts perfect signal, do the 224 pixel color, and some multiple of that for detail luma, or the same for more shades of the color hues. One thing about that is the two cogs are additive. So, no tiny black pixels, only brighter, white ones, without some external logic.
Potatohead said "The spec is plus or minus 10 hertz!!! Many displays will tolerate a few hundred hertz tops. I've tried variations as small as a coupla percent and got rainbows. The displays just won't bend that far, I'm afraid. "
D'oh! Just a little wishful thinking stubbornness I guess [noparse]:)[/noparse]
By "Scan doubling", are you basically saying that two identical fields are being used to make up a whole interlaced frame? If so, I think it would also by appropriate for the small 16:9 displays - which from what I read don't draw interlaced images on alternating lines since their resolution are typically limited to half that of NTSC. At least according to a post on regarding 480x234:
"the only thing i can tell you is why are 234 lines at all.
if the LCD panels were 300 lines for example, there woud be a image conversion from 475 lines to 300. And it is more difficult to do. But if they are 234 lines (see it is half 475) then you just need to refresh each line twice so all data is shown (there is half resolution anyway but it does not care for such screen sice)."
As for syncing two cogs for composite video, I must have had a massive brain fart. I can see how it would be accomplished for VGA, which I incorrectly applied to composite/s-video. Lets see if I'm on the right page: Color is determined by the difference in phase between the original colorburst signal, and the actual color signal. In that case, the signal coming from the prop must at some (significant?) multiple of the colorburst frequency?
Sorry if I'm using incorrect terminology. I'm just trying to get a better grasp of this, because at this point, I'm convinced that all this color business is pure voodoo! Voodoo I tell you!
Yeah, that's the idea. Draw the same image on both frames. On the half resolution displays, what will happen is the color phase toggle will happen on each scan line, doubling the effective resolution, at a frame rate of 30Hz. That's dot crawl at twice the normal 15hz speed seen on full interlaced displays where all the scan lines are shown.
There some choices on the half resolution displays. If one wants to, just skip the half scan line, and blast unique frames at 60fps. Or, go ahead and output the interlace and let the display deal with it. Most will.
Yes on the color bit too. Phase is the key, and that's what makes syncing composite COGs tough. Both the PLLs must run pretty much exactly together. However, if only one is doing the color, along with whatever luma makes sense, the other one can be doing just luma. Would work for a HUD, or cursor. This can be done with both COGs outputting to the same pins, which doesn't really get you a lot of additional depth, but does allow for the HUD, cursor, etc...
If done with different pins and resistors, additional depth is on the table for sure.
In all the drivers I've seen, the core timings are all multiples of the color burst signal. Basically, one takes the period of that signal, and I call that a color clock, divide by 16 for the 4 bits of phase the chip has avaliable, calling that just "a clock", or as Eric Ball decided to do, PLLA.
Everything then is in multiples of PLLA. There are X PLLA per pixel, Y PLLA per scanline, etc...
OBC, the full fat PropGFX uses an AD724 chip to do the signal, and I feed it 15bit RGB 16th bit for sync signal, could very well be 24bit, just you don't have many pins left after that lol.
Ok, that clarifies things a bit. Might it be possible to do video using a different CNT mode on the prop? Aside from that, it's probably safe to assume additional reliable color depth can only be achieved using Baggers' method above, right?
Yeah if you want decent RGB ranges, then yeah I'd go with the AD723/4/5 route, obviously until we get PropII [noparse]:D[/noparse] but that's a while away yet.
Yep, agreed. The downside to using the COGs in parallel is generating the signal consumes a lot of a cog --that cog could be manupulating pixels instead!
Comments
Specs on the ATmega644 are 4K RAM, 64K program (and I think that's flash), and some 2K EEPROM. That's 20 Mips.
The actual game runs in C, linked to a library featuring video and sound done "in the background", via interrupts. Actual game throughput is probably on par with what we get in SPIN, with some nice bursts during blanking times.
It's totally viable to drive one of these chips with a Prop, and that's exactly what Baggers and Coley did early on.
Seems to me, a Prop could also just deliver the video signal reference clock, via one of the counters too. I think that cuts the part count some, for the cases where the main CPU are clocked at some non-multiple of the color burst.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
On another note, I tried your potatotext demo, potatohead. Color and resolution looked good, though I only tried it on my LCD projection TV, I got a few small displays coming in the mail. I haven't really looked at the code, but I imagine the method you used for coloring wouldn't be practical for use with bitmaps, correct?
Just took a brief peek at the demo to see set resolution. 340 is better than I would have thought it would be, but now I got to know what 512 or 640 would look like.
While you're most definitely right, I'm thinking that some of these SoC decoder chips that they use on modern small LCDs just *might* be able to lock their colorburst PLL to an higher than standard frequency. Well, I guess if anything, it's worth a shot when I get my displays in. I'll tear 'em apart too to see what they use for chipsets.
@Mark: Yeah, it's actually 320, and that looks flat out great, IMHO. It's very useful, given you don't do some things. --exactly the things shown in the demo. I put them there just for people to use as a display metric. If you run it in mono, those smaller detail patterns work just fine on most displays I've tried. I just learned today how to really clean up the mono, even when color information is presented to the prop. I'll be adding that switch to the driver on the next pass.
As for color, doing a bitmap in color at those resolutions is just fine. The problem is RAM. Tiles would work however. That driver was structured for high density text, and the two color mode works with fonts. There are two colors reserved for a mouse pointer, and those two free range on the screen. That's actually what I'm coding on right now.
In that driver, there is the TV COG. It just draws whatever it finds in it's scan line and color buffers. Those could be changed to just be a full color scan line buffer pretty easy. That puts any propeller color at any pixel. From there, use another cog, or cogs to feed it tiles, sprites and bitmaps, as the HUB memory allows for. In that configuration, some planning would yield a pretty excellent display from composite. Full on bitmaps don't work on the Propeller because of HUB memory. Frankly, existing drivers get it done, because of the resolution limits in play. It's tough to get more than 160 pixels bitmap, for memory reasons. Higher resolution things either need to be color limited, or tiles, or sprites, or all of those things. The only exception is dynamically drawn displays, and the best examples of that are Baggers WOLF3D demo, and the work Linus did. Not suitable for general use, but awful fun!
I've another driver, built off that TV cog in process that does 4 colors per text tile. I plan to get a little help with sprites for it. Baggers and Eric have posted up nice sprite code. That's going to be a bit though. I chip away at these things. If you want to start hacking on that TV cog, feel free to do so [noparse]:)[/noparse]
It's worth pointing out the kit OBC mentioned above runs right at the sweet spot for composite. Horizontal resolution is 224 pixels. It's the increased color depth that people are liking. Propellers out of the box, do that resolution nicely, and with quality comparable to what that chip outputs, just FYI. The difference is fewer stock colors, 80 - 120 or so, as opposed to 256. We've got one Propeller driver that does exactly that, and it's Eric's sprite driver. That one could be modded for tiles. Maybe it should be...
The "scan doubling" used in potatotext is the higher end output option that delivers the best overall quality at higher resolutions. That's part of why I did it. Been wanting a "scan doubled" display for a long time... not many devices did it. I saw one a long time ago, and really liked it for TV. Most do either the full vertical resolution, or half vertical, limiting the overall display quality somewhat.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 7/19/2010 2:15:17 AM GMT
http://elm-chan.org/works/crtc/report.html
·
Short answer: Yes. It works nicely on VGA. On NTSC, I have trouble getting the PLL's running together for color. A grey scale cog can be done. One could run 160 or 320 pixel color on one COG, and 640 pixel luma on another for a very nice display, overdriving it a little. For a dead nuts perfect signal, do the 224 pixel color, and some multiple of that for detail luma, or the same for more shades of the color hues. One thing about that is the two cogs are additive. So, no tiny black pixels, only brighter, white ones, without some external logic.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
D'oh! Just a little wishful thinking stubbornness I guess [noparse]:)[/noparse]
By "Scan doubling", are you basically saying that two identical fields are being used to make up a whole interlaced frame? If so, I think it would also by appropriate for the small 16:9 displays - which from what I read don't draw interlaced images on alternating lines since their resolution are typically limited to half that of NTSC. At least according to a post on regarding 480x234:
http://www.diyaudio.com/forums/lcd/45388-why-480x234.html
"the only thing i can tell you is why are 234 lines at all.
if the LCD panels were 300 lines for example, there woud be a image conversion from 475 lines to 300. And it is more difficult to do. But if they are 234 lines (see it is half 475) then you just need to refresh each line twice so all data is shown (there is half resolution anyway but it does not care for such screen sice)."
As for syncing two cogs for composite video, I must have had a massive brain fart. I can see how it would be accomplished for VGA, which I incorrectly applied to composite/s-video. Lets see if I'm on the right page: Color is determined by the difference in phase between the original colorburst signal, and the actual color signal. In that case, the signal coming from the prop must at some (significant?) multiple of the colorburst frequency?
Sorry if I'm using incorrect terminology. I'm just trying to get a better grasp of this, because at this point, I'm convinced that all this color business is pure voodoo! Voodoo I tell you!
There some choices on the half resolution displays. If one wants to, just skip the half scan line, and blast unique frames at 60fps. Or, go ahead and output the interlace and let the display deal with it. Most will.
Yes on the color bit too. Phase is the key, and that's what makes syncing composite COGs tough. Both the PLLs must run pretty much exactly together. However, if only one is doing the color, along with whatever luma makes sense, the other one can be doing just luma. Would work for a HUD, or cursor. This can be done with both COGs outputting to the same pins, which doesn't really get you a lot of additional depth, but does allow for the HUD, cursor, etc...
If done with different pins and resistors, additional depth is on the table for sure.
In all the drivers I've seen, the core timings are all multiples of the color burst signal. Basically, one takes the period of that signal, and I call that a color clock, divide by 16 for the 4 bits of phase the chip has avaliable, calling that just "a clock", or as Eric Ball decided to do, PLLA.
Everything then is in multiples of PLLA. There are X PLLA per pixel, Y PLLA per scanline, etc...
So, it's really all based on (colorburst/16).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!