Section 4.9.3:
The Colors parameter is a 32-bit value containing either
four 8-bit color values (for 4 color mode) or two 8-bit
color values in the lower 16 bits (for 2 color mode). For
VGA mode, each 8-bit color value is written to the pins
specified by the VGroup and VPins field.
I might have misread it but a 32-bit value divided over four 8-bit colow values sounded like 32-bit RGBA. Sorry, my mistake.
Nick, thats not correct. The internal hardware is·4 colors per tile, but each color value can be 1 of 64 colors, for VGA those two "missing" bits for color are used for the vertical and horizontal sync required by the VGA standard. Remember the internal memory is only 32K, at a 4:3 ratio this means a maximum size of 416x312 or the closest (semi) standard size of 512x384. Halve these figures if you want non-glitchy double-buffering.
Now multiple cogs can be ganged to achieve higher resolution (or higher bit depth), but for every bit you add to the color space, you are also dropping the maximum displayable size (for true bitmapped drawings, which is what you want).
You could up the memory by adding external memory and use a cog to page sections into hub space, but again your faced with consuming nearly all of the I/O pins.
The last chapter in my "Programming the Parallax Propeller using Machine Language" contains a thorough investigation of how to use the Video Logic "in general". it is not so specific as to VGA timing, but it will greatly further your understanding of its terrific working - and also of its terrific shortcomings
It's 4 colors AT ALL
Except you use some clever tricks......
Nearly all of the work of our Video Gurus is optimizing such clever tricks
Ouch, that is a shortcoming for sure. So interfacing the propeller with anything more than something off an Atari would probably destroy it. I really don't want to use the internal GPU because of the limited colors, but it looks like I may have no choice. Oh well, sorry for all of the trouble! Thanks,
Nick
Post Edited (nick112147) : 3/6/2008 11:06:53 PM GMT
Nick, just for perspective, the NES has only ~50 some colors, Atari Computers 256, VCS 128, and C 64 has only 16!
You can directly code for 1, 2 or 8 bits per pixel. Some of the propeller "colors" are signal level ones, meaning they actually do SYNC and such. Other bit-depths require additional logic running in the COG.
If you are working with NTSC displays, you can get ~400 colors at 160 pixels of horizontal resolution.
Also not mentioned yet on this thread is serial RAM memory devices. Jasper_M has written a driver that makes use of one of these, thus moving the display to an external memory device. That driver was standard Propeller colors, but more could happen. Look on the HYDRA topic section for some nice NES+ quality screenies.
Sounds awsome potatohead! But I am also looking for semitransparency support, and I would bet my left leg the propeller, even though it is a work of art, doesnt support things like that. Is there any way to expand this 32K limit to whatever I want by interfacing it with external RAM and some clever programming?
You can certainly connect external RAM to a Propeller, but it takes a lot of I/O pins. Andre' developed an external 512K SRAM for the Hydra by using a gate array and some people have written video drivers that use it. Clearly, using some 8-bit latches for addresses would help a lot in terms of I/O pin requirements.
Yes! I have been studying latches and address decoding since I bought Embedded Microprocessor Desing:Real World Design by Stuart Ball in ebook format earlier this evening. Latches and decoders would be great for RAM if combined with a serial interface. Would a 16-bit video processing device be too hard on the Propeller, even with say, one to two megabytes between them? I would like to try running the program from external RAM, rather than having to run it in COG or HUB RAM, is this possible?
The program itself can only run from internal RAM, but you can put the screen buffer into external RAM.
I was thinking in terms of three 8 bit latches with their data inputs all in parallel and connected to 8 I/O pins. There would be a latch clock for each connected to an I/O pin as well as the read and write strobes and output enable for a total of 6 control lines.
The idea is that you could load any of the 8 bit latches with address information. On a write cycle, you'd put the data on the same 8 I/O pins and strobe the write line. On a read cycle, you'd make the 8 I/O pins inputs, then do a read strobe and enable the RAM outputs. You could probably do a read or write cycle in about a microsecond, less if you didn't have to change all 3 address bytes.
Using that for RAM, I could make the ROM access serial by using SD Cards. Load all of the program data from the card into RAM first, and then simple have the CPU load it from RAM using commands from the BIOS. Does the Propeller have the power to manage a decent sound chip?
IMHO, you can do semi-trans on the Prop, but it's expensive.
The way the video works is it is just a nice serializer. You can serialize video, or other things, it's all just a bit-stream, latched to specific timings.
In it's simplest form, it's just a bitmap. So, pixels and their related signals get blasted to the screen, and that's that.
The more you want to do with that bit stream, the more calculations you do in the COG's prior to sending it out.
The sprite drivers do this.
Essentially, they are sets of sprite data which are assembled scan-line by scan-line, before arriving at the display. Semi-transparency is an additional color look up, in addition to the masking that needs to happen anyway. One COG is blasting scan lines to the display, while the others are filling them up.
The limited color space provided by the on-board video capabilities isn't all that great, in terms of transparency. Other video circuits would be. That's essentially some DAC's and external RAM. At that point, you are really building a GPU as those tasks will more or less consume one Propeller. Again, that's exactly where the PropGFX project is headed. Prop as programmable GPU.
The onboard stuff is really handy, but by no means the only option.
Within that space, semi-transparent objects are doable, but will be only as fine as the color space is. There is no fundemental hardware limitation that prevents that from happening, other than the overall coarseness possible.
Like Mike said, the video buffer can be located in the external RAM --so can movable objects too. All a matter of how much video software you want to end up writing, and external goodies added.
At the current 80Mhz reference clock, the number of effects you can drive at once is probably lower than your overall expectations have run on this thread.
You might find it interesting to engage in building a video circuit, for RGB with DAC chips. That's gonna give you the color depth you want. From there, encoders can convert that to TV display compatible graphics, or you can just use a VGA type display and call it good. 24 bit color has been done that way already, 8 bits each R,G,B.
With that approach, it's all compute essentially. It can even be done without using the hardware video generators at all (no waitvid). It then is just a timing and compute problem, where you have one COG moving the video bits, and other COG's building scan line buffers and doing pixel masking and color correction.
The trade-off is gonna be number of things manipulated at one time. If you do sprites only, with standard transparency, say you get X number of those. Add in background layers and that number might drop, use tiles and it might rise. Factor on additional masking for the transparency calcs, and or lookups, and it will drop again.
No free lunch, but I think it's safe to say it can be done.
So really, in order for me to do any of the things to be on par with atleast the SEGA Genesis, I would need around three to four propellers. I would like to learn more about the 24-bit color you mentioned. Where can I find out more about it, especialy if it was done with the propeller.
Not sure what level of graphics the Genesis has. The prop can easily do NES / Atari / C64 quality plus.
Graphics:
- 64 simultaneous colors of 512 color pallete.
- Pixel resolution: 320 x 224
- VDP (Video Display Processor)
- 3 Planes: 2 scrolling playfields, 1 sprite plane
Just looked it up. The core Genesis specs are detailed above. These are within the limits of the Prop. Gonna take some nice video code to get done though. Gonna need RAM. Might not be able to draw as many sprites.
The semi-stuff appears to be related to the add-ons and video stuff. Probably outside the limits of the Prop.
nick112147,
Similar to what potatohead said about video handling, a Propeller can do a complete vocal tract synthesis (singing monks!) in stereo with dynamic spatial positioning with a couple of cogs. It's flexible raw compute power with some limitations (available memory mostly). MP3 sound decoding looks like it will be a problem, mostly because of memory limitations. It looks like it would be possible, but not practical. It's too easy and cheap to use a specialized MP3 decoder.
I think it's too easy to lose sight of the Propeller as a flexible microcontroller. It's not a "mainframe" computer. It's not a graphics processing unit. It's not an audio processor. It's not a network processor. It's not a TV or VGA display generator. Yet, it can do parts of all of those and more. It can do somewhat simple versions of several of those at once. That's pretty good for a $13 part that's reliable and easy to use.
@Mr.Green: Oh yes, the propeller, for its cost is an absolute wonder. I would be frieghtened to think of what it would cost if say Intel or AMD created it. It is an excellent low cost microcontroller. I probably wouldn't use MP3's because of their size, I think something along the lines of FM synthesis would probably be better. A generic Super Nintendo FM music file, containting around 2 minutes of data is only about 12K. FM synthesis is efficient and small, but it does lack a little bit of quality. Programmable sound generators work quite well to for ultra basic stuff. I think using both the propellers sound hardware backed up with a synthesis chip would do quite well. An 8-bit Yamaha LSI FM synth chip is nice, it is close to that of the default ringtones on a Moto RAZR cell phone. Thanks.
@potatohead: I think maybe I should tone down my end goal, because I really do have alot to learn about hardware design. To be honest, and I am not trying to attract pitty, but I am only 18 years old, barely out of high-school, with NO EE or other type of engineering background,·so trying to design something that is on par with the Neo-Geo or something from the early 90's is abit out of my league...for now ;-). I am reading about microprocessor architecture design right now, so I am slowly learning. I would say by the time I finish designing, build, test and create software for my system, I should know enough to do something a little bit more advanced. Although it was very reassuring to hear that it can atleast do something near the Genesis. Semi-trans isn't possible on the SNES, Genesis, or Neo-Geo without the use of their external DSP's. In the end, I think shooting for doing something like a high-end NES would be more inside my capabilites AND the Propellers capabilities! Thanks.
Nick
Post Edited (nick112147) : 3/7/2008 6:50:33 AM GMT
Dude! What a great time to be 18! No pity here man. Go for it, have a lot of fun, and don't worry so much about breaking stuff. (nobody has to know) If only I had that free time back now... Family, work, ugh! There is not anywhere near enough Prop time for me these days. Have to pick and choose, chipping away at stuff.
When I was 18, it was Atari / C64 / CoCo time! ~1Mhz chips, 64 K RAM (well, 48K on the Atari)
Here's some perspective for you. The guy that designed this chip, Chip Gracey, started out exactly where we both did. Everything you ever wanted to know about this stuff is online, parts are cheap, and there are people to talk to. IMHO, it's just an excellent scene by comparison to the local library, what ever computer rags and software I had back then. Let's put it this way. The small town I lived in, had a Radio Shack that was considered the place to go for goodies. Half of us didn't even have disk drives. The BBS scene started about that time, but was very limited compared to the Internet we have today.
The Propeller is the result of 8 years of his time and effort to do something really robust and useful! It's aimed right at people just wanting to do stuff. Lots of people were right where you are. I still have my Z80, 6502, 6809 data books, programming references and such. Fun stuff! Have a great time.
If it were me, I would build up some graphics using the onboard stuff. You've gotta work through timing, learn how to get the COGs all working together, signals and other details. Having been through that, I can tell you it's a stiff ramp at first, then the doors start to open up nicely after that.
You then can interface some hardware for game controllers, maybe sound, RAM, etc... Get a project up and running, then add something to it and take that learning path, using your up and running stuff as a base to build on and focus your efforts. Another really great path is to take a protoboard, or roll your own, then hack other devices to do this or that. Oldbitcollector has been having a great time doing that kind of thing. Do a search on his Propeller Cookbook. Lots of fun there.
Get a scope. I had one as a kid, and it made all the difference in the world.
I would not devalue the on-board stuff too much. The difference between hardware GPU's and software based ones is flexibility. Look at the old Atari 2600 (VCS). That thing has 128 bytes of system RAM, and a video display system that's CPU driven, much like the Propeller is. The thing was originally designed to do ball and paddle games and has a 4K ROM address space. The software component for the video has permitted hacking and learning to squeeze more out of it than anybody thought possible. Here, so many years later, there are still new techniques being discovered to get more colors, objects, etc... The games being built today, for fun, would have sold millions in the day, and do things on that hardware thought impossible.
We've not seen all that can be done with the on-board video stuff. Software based systems are very powerful in this regard. This is one of the things that really makes the Propeller what it is.
Also, it is possible to build a video display kernel specifically for a given project. That's been the approach taken for many of the things done here. Doing that means being able to make the most of the RAM and the COGs.
In case you didn't know, the PropGFX full will do 15-bit RGB (5-bit per channel), to an AD724 (IIRC) which then converts the colours to NTSC or PAL S-Video or Composite. Some of it's features are impressive already; and theres only two of the prototypes in existance and possibly major redesigns on the cards
@potatohead: Yeah I used to have a real gas programming the Atari STELLA chip. I think Lowes carries logic probes, and my RadioShack might carry a really cheap scope, but they are mostly good for small components like resistors or something like that. It honestly sounds like the propeller can do something along the lines of the Turbo-Grafx 16. I just bought a book about building embedded systems, and it is helping me QUITE A BIT. In conjunction with Google and the fact that alot of tech universities publish alot of their lessons freely in PDF and PowerPoint format is helping me alot.
@OwenS: Since the propGFX uses only a propeller for video, I am assuming the propeller can output 15-bit video rather than only 8-bit? I don't want to use pre-made hardware, as I hate designing around other peoples work. Besides, I would rather learn about it than have someone do it for me lol, that way I actually learn. Thus I am also assuming that the 15-bit video is software controlled, so it is up to my own program to get 15-bit video, correct?
Post Edited (nick112147) : 3/7/2008 10:42:20 PM GMT
Nick,
FYI
with PropGFX we didn't use the Propeller video hardware to generate the 15 bit RGB rather it is hard coded and the resulting R, G, B and Sync fed into the tv encoder chip.
Regards,
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ PropGFX Forums - The home of the Hybrid Development System and PropGFX Lite
So it is purely software, and the TV encoder translates the 15-bit value into a video signal. I was wondering why you guys used a TV encoder when the propeller already contained one. Very ingenious! Very nice indeed, out of curiousity, what kind of load does it put on the propeller?
Comments
The Colors parameter is a 32-bit value containing either
four 8-bit color values (for 4 color mode) or two 8-bit
color values in the lower 16 bits (for 2 color mode). For
VGA mode, each 8-bit color value is written to the pins
specified by the VGroup and VPins field.
I might have misread it but a 32-bit value divided over four 8-bit colow values sounded like 32-bit RGBA. Sorry, my mistake.
Now multiple cogs can be ganged to achieve higher resolution (or higher bit depth), but for every bit you add to the color space, you are also dropping the maximum displayable size (for true bitmapped drawings, which is what you want).
You could up the memory by adding external memory and use a cog to page sections into hub space, but again your faced with consuming nearly all of the I/O pins.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 3/6/2008 10:25:35 PM GMT
It's 4 colors AT ALL
Except you use some clever tricks......
Nearly all of the work of our Video Gurus is optimizing such clever tricks
Nick
Post Edited (nick112147) : 3/6/2008 11:06:53 PM GMT
You can directly code for 1, 2 or 8 bits per pixel. Some of the propeller "colors" are signal level ones, meaning they actually do SYNC and such. Other bit-depths require additional logic running in the COG.
There is a nice discussion about colors here: http://propeller.wikispaces.com/Colors
If you are working with NTSC displays, you can get ~400 colors at 160 pixels of horizontal resolution.
Also not mentioned yet on this thread is serial RAM memory devices. Jasper_M has written a driver that makes use of one of these, thus moving the display to an external memory device. That driver was standard Propeller colors, but more could happen. Look on the HYDRA topic section for some nice NES+ quality screenies.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
I was thinking in terms of three 8 bit latches with their data inputs all in parallel and connected to 8 I/O pins. There would be a latch clock for each connected to an I/O pin as well as the read and write strobes and output enable for a total of 6 control lines.
The idea is that you could load any of the 8 bit latches with address information. On a write cycle, you'd put the data on the same 8 I/O pins and strobe the write line. On a read cycle, you'd make the 8 I/O pins inputs, then do a read strobe and enable the RAM outputs. You could probably do a read or write cycle in about a microsecond, less if you didn't have to change all 3 address bytes.
The way the video works is it is just a nice serializer. You can serialize video, or other things, it's all just a bit-stream, latched to specific timings.
In it's simplest form, it's just a bitmap. So, pixels and their related signals get blasted to the screen, and that's that.
The more you want to do with that bit stream, the more calculations you do in the COG's prior to sending it out.
The sprite drivers do this.
Essentially, they are sets of sprite data which are assembled scan-line by scan-line, before arriving at the display. Semi-transparency is an additional color look up, in addition to the masking that needs to happen anyway. One COG is blasting scan lines to the display, while the others are filling them up.
The limited color space provided by the on-board video capabilities isn't all that great, in terms of transparency. Other video circuits would be. That's essentially some DAC's and external RAM. At that point, you are really building a GPU as those tasks will more or less consume one Propeller. Again, that's exactly where the PropGFX project is headed. Prop as programmable GPU.
The onboard stuff is really handy, but by no means the only option.
Within that space, semi-transparent objects are doable, but will be only as fine as the color space is. There is no fundemental hardware limitation that prevents that from happening, other than the overall coarseness possible.
Like Mike said, the video buffer can be located in the external RAM --so can movable objects too. All a matter of how much video software you want to end up writing, and external goodies added.
At the current 80Mhz reference clock, the number of effects you can drive at once is probably lower than your overall expectations have run on this thread.
You might find it interesting to engage in building a video circuit, for RGB with DAC chips. That's gonna give you the color depth you want. From there, encoders can convert that to TV display compatible graphics, or you can just use a VGA type display and call it good. 24 bit color has been done that way already, 8 bits each R,G,B.
With that approach, it's all compute essentially. It can even be done without using the hardware video generators at all (no waitvid). It then is just a timing and compute problem, where you have one COG moving the video bits, and other COG's building scan line buffers and doing pixel masking and color correction.
The trade-off is gonna be number of things manipulated at one time. If you do sprites only, with standard transparency, say you get X number of those. Add in background layers and that number might drop, use tiles and it might rise. Factor on additional masking for the transparency calcs, and or lookups, and it will drop again.
No free lunch, but I think it's safe to say it can be done.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
The PropGFX site is here: http://www.propgfx.co.uk/
Not sure what level of graphics the Genesis has. The prop can easily do NES / Atari / C64 quality plus.
Graphics:
- 64 simultaneous colors of 512 color pallete.
- Pixel resolution: 320 x 224
- VDP (Video Display Processor)
- 3 Planes: 2 scrolling playfields, 1 sprite plane
Just looked it up. The core Genesis specs are detailed above. These are within the limits of the Prop. Gonna take some nice video code to get done though. Gonna need RAM. Might not be able to draw as many sprites.
The semi-stuff appears to be related to the add-ons and video stuff. Probably outside the limits of the Prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Similar to what potatohead said about video handling, a Propeller can do a complete vocal tract synthesis (singing monks!) in stereo with dynamic spatial positioning with a couple of cogs. It's flexible raw compute power with some limitations (available memory mostly). MP3 sound decoding looks like it will be a problem, mostly because of memory limitations. It looks like it would be possible, but not practical. It's too easy and cheap to use a specialized MP3 decoder.
I think it's too easy to lose sight of the Propeller as a flexible microcontroller. It's not a "mainframe" computer. It's not a graphics processing unit. It's not an audio processor. It's not a network processor. It's not a TV or VGA display generator. Yet, it can do parts of all of those and more. It can do somewhat simple versions of several of those at once. That's pretty good for a $13 part that's reliable and easy to use.
@potatohead: I think maybe I should tone down my end goal, because I really do have alot to learn about hardware design. To be honest, and I am not trying to attract pitty, but I am only 18 years old, barely out of high-school, with NO EE or other type of engineering background,·so trying to design something that is on par with the Neo-Geo or something from the early 90's is abit out of my league...for now ;-). I am reading about microprocessor architecture design right now, so I am slowly learning. I would say by the time I finish designing, build, test and create software for my system, I should know enough to do something a little bit more advanced. Although it was very reassuring to hear that it can atleast do something near the Genesis. Semi-trans isn't possible on the SNES, Genesis, or Neo-Geo without the use of their external DSP's. In the end, I think shooting for doing something like a high-end NES would be more inside my capabilites AND the Propellers capabilities! Thanks.
Nick
Post Edited (nick112147) : 3/7/2008 6:50:33 AM GMT
When I was 18, it was Atari / C64 / CoCo time! ~1Mhz chips, 64 K RAM (well, 48K on the Atari)
Here's some perspective for you. The guy that designed this chip, Chip Gracey, started out exactly where we both did. Everything you ever wanted to know about this stuff is online, parts are cheap, and there are people to talk to. IMHO, it's just an excellent scene by comparison to the local library, what ever computer rags and software I had back then. Let's put it this way. The small town I lived in, had a Radio Shack that was considered the place to go for goodies. Half of us didn't even have disk drives. The BBS scene started about that time, but was very limited compared to the Internet we have today.
The Propeller is the result of 8 years of his time and effort to do something really robust and useful! It's aimed right at people just wanting to do stuff. Lots of people were right where you are. I still have my Z80, 6502, 6809 data books, programming references and such. Fun stuff! Have a great time.
If it were me, I would build up some graphics using the onboard stuff. You've gotta work through timing, learn how to get the COGs all working together, signals and other details. Having been through that, I can tell you it's a stiff ramp at first, then the doors start to open up nicely after that.
You then can interface some hardware for game controllers, maybe sound, RAM, etc... Get a project up and running, then add something to it and take that learning path, using your up and running stuff as a base to build on and focus your efforts. Another really great path is to take a protoboard, or roll your own, then hack other devices to do this or that. Oldbitcollector has been having a great time doing that kind of thing. Do a search on his Propeller Cookbook. Lots of fun there.
Get a scope. I had one as a kid, and it made all the difference in the world.
I would not devalue the on-board stuff too much. The difference between hardware GPU's and software based ones is flexibility. Look at the old Atari 2600 (VCS). That thing has 128 bytes of system RAM, and a video display system that's CPU driven, much like the Propeller is. The thing was originally designed to do ball and paddle games and has a 4K ROM address space. The software component for the video has permitted hacking and learning to squeeze more out of it than anybody thought possible. Here, so many years later, there are still new techniques being discovered to get more colors, objects, etc... The games being built today, for fun, would have sold millions in the day, and do things on that hardware thought impossible.
We've not seen all that can be done with the on-board video stuff. Software based systems are very powerful in this regard. This is one of the things that really makes the Propeller what it is.
Also, it is possible to build a video display kernel specifically for a given project. That's been the approach taken for many of the things done here. Doing that means being able to make the most of the RAM and the COGs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Oh well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
@OwenS: Since the propGFX uses only a propeller for video, I am assuming the propeller can output 15-bit video rather than only 8-bit? I don't want to use pre-made hardware, as I hate designing around other peoples work. Besides, I would rather learn about it than have someone do it for me lol, that way I actually learn. Thus I am also assuming that the 15-bit video is software controlled, so it is up to my own program to get 15-bit video, correct?
Post Edited (nick112147) : 3/7/2008 10:42:20 PM GMT
FYI
with PropGFX we didn't use the Propeller video hardware to generate the 15 bit RGB rather it is hard coded and the resulting R, G, B and Sync fed into the tv encoder chip.
Regards,
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX Forums - The home of the Hybrid Development System and PropGFX Lite