Propeller as a Renderer
Vega256
Posts: 197
Hi Guys,
I originally turned to the Propeller because I needed a Video Display Adapter in my circuit that could generate composite color NTSC and possibly PAL video signals. All other such video ICs that I have researched has been obsolete for a number of years. I need an IC for the sole purpose of inputting pixel and tile data (position, color), processing that information into a composite video signal, and outputting that signal.
I understand that the Propeller is a microcontroller but I only need it for video generation and my sprite data will not be in the chip's main memory.
Is there any way that I can have the Propeller look for image data in other places besides its own 32K?
I originally turned to the Propeller because I needed a Video Display Adapter in my circuit that could generate composite color NTSC and possibly PAL video signals. All other such video ICs that I have researched has been obsolete for a number of years. I need an IC for the sole purpose of inputting pixel and tile data (position, color), processing that information into a composite video signal, and outputting that signal.
I understand that the Propeller is a microcontroller but I only need it for video generation and my sprite data will not be in the chip's main memory.
Is there any way that I can have the Propeller look for image data in other places besides its own 32K?
Comments
I'm sure it's quite doable since the data rate for VGA is much higher than for composite video. You can't cause the Propeller to directly access external SRAM for its video data, but there are a variety of designs using different amounts of I/O pins for control, address and data busses that are fast enough for the task.
Hi Vega256,
The newer version of Morpheus can be built to have a video output instead of VGA, but I have not built any external memory NTSC (or PAL) video drivers yet.
You need to give more information about your application before we can tell if it is feasible on a Propeller - for example, you mention sprites, but not what size or how many sprites. What bitmap (background) resolution are you looking for? How do you want to draw your background and sprites? You mention your sprites will not be in the chip's main memory - where will they be?
Sorry about that. My project, in essence, is a microprocessor system. The main controller/brain is an 8-bit microprocessor. I have ROM and RAM, both of which are connected to an address and data bus. Simply explained, the image data will reside in ROM and it is there that I want the Propeller to access. At the minimum, I would like to have 8x8 or 16x16 tile sizes with at least a 256x240 background resolution. I would like to have a rather rich variety of colors but it is not necessary.
Is the ROM like a game cartridge, where it contains the program, and the RAM is operating space?
Would the prop actually draw sprites, or do you want it to be a frame buffer?
How would Prop access ROM? Is it a DMA, with a CPU halt, sharing the clock, ?
Props can generate a variety of graphics. It comes down to pins. If you use a few pins, you get a few colors. If you use more pins, you can get more colors.
What role does the Propeller internal RAM play? Will it only hold renderer code, or is it expected to fetch from RAM visible to the 8 bit CPU?
It is the 8088. I consider it an 8-bit processor because even though it supports a 16-bit instruction set, its data bus is only 8 bits wide. Yes, your description is exact. The Propeller's job in my project is to be a framebuffer.
Seems to me then, you've got one COG generating the video signal. It reads from a scan line buffer internal to the prop, which is filled in advance of the line actually being scanned on the display. Really easy to double buffer this, so that memory fetches can operate around the CPU wait cycles. Only need enough access windows to populate the buffer in that case. While one scan line is being displayed, the fetch cog is populating the other one.
There would have to be one more COG fetching data from the external address space, populating the buffers.
A third cog watches the BUS and sends control signals to the fetch COG to enable it to access the RAM at the right times.
Finally, a fourth cog for control purposes. Video on, off, resolution change, screen buffer address change, color depth change, etc...
It's gonna look something like that on the Prop. Probably more complex, but that's the rough idea. Some buffer chips will be needed so that you can latch addresses, and data for capture by the Prop. The minimum for reasonable (80-200) color NTSC video is three pins. There are lots of drivers written, and various ways to create the signal, each with pros and cons. We've done everything from a fairly straight forward TV driver that does ~96 colors, using the internal Propeller chroma generator for that purpose (16 hues, 6 greys), to drivers using more pins and or PWM, artifacting (NTSC), etc... for lots of different screen layouts.
The resolution you desire is well inside the operating range of the Prop too.
If the ROM is small, it might be a good idea to just burst copy it to the Propeller internal memory straight away. That might save you DMA cycles each scan line, leaving only the RAM area to be fetched repeatedly.
If you had two fixed screen pages, that might simplify your operation on the bus too. Not sure about that, but it seems worth consideration.
How big is the RAM?
Finally, software sprites then? The 8088 blitting to and from the screen buffer page(s)?
Heck, there might be some propeller left! Could do sound, perhaps Sid COG. We've got a very accurate SID that runs in one COG, and the YM chip done too.
http://www.parallax.com/tabid/708/Default.aspx
As I am preparing to order the Propeller, will you say that all that I need for the initial design would be the Propeller itself? I have an EEPROM programmer; what else would I need?
For Propellers EEProm (Can be biger that 32KB) - That are I2C connected to it --- You not need any programmer. Propeller program it by its own software 8Inbuild).
You need only Propeller plug else standard serial COM to Yours PC that are prepared to have even Reset Propeller possibility.
http://www.parallax.com/tabid/708/Default.aspx
Look that over closely to see how the propeller builds addresses, and captures data off the bus.
So no. You will need more than the propeller. Some resistors to form the video circuit, some external chips to handle the data and address bus operations, crystal, if not using the other system clock somehow at a minimum. Others here will know a lot more than I do about that interfacing part of things. The scope of what you want to do fits a prop program wise. Electrically interfacing it to your project warrants some more discussion, IMHO.
If it were me, I would also get a prop plug. It's handy for programming the Propeller from your PC. Once you've got that all up and running, the Prop can program it's own EEPROM as Sapieha says in his post above.
Sorry Guys, I do not mean to bump but I would like to reconfirm some things.
Regarding the method of communication with the Propeller, I have stated that I do an external EEPROM and a programmer but I forgot to mention that I have the Propeller tool which from my understanding can save EEPROM files. So, can't I just have the program written to the external EEPROM and have the Prop load it from there?
In conclusion, thanks guys for the assistance.
I don't know about others, but I have programmed the Prop several hundred times, sometimes every minute, developing complex video code.
While I'm waiting on that, I'll just summarize how the Prop does things.
Propellers have very basic video capability in the chip. The video generators do little more than provide some hardware assist for a software video signal. It's possible to do software video on most any micro-controller these days. Somebody even did it on the little TI launch pad thing recently. (damn cool, BTW)
The Propeller video generators take color and pixel data and output it serially using the PLL. This keeps code deterministic, simplifies the software video task, and permits one COG to output a signal, and do the work necessary to feed it. Since there are no interrupts on the Propeller, video is typically done with one or more COGS rendering the video. That video driver typically consists of a kernel, which does the core signal, and optionally, one or more render COGS that actually build the display.
"The driver" is literally anything you want. We've got lots of drivers that do lots of things. Some are simple, like a bitmap driver that just scans part of the HUB memory, drawing it to the display. Those, more often than not, can just be a single COG. We've got others that do sprites and tiles. On those, some memory is scanned according to a tile list in memory, and sprites are added to that, scanned from other parts of memory, or the same memory, if a sprite and tile are actually the same thing, drawn according to a sprite list. Still other drivers dynamically display things in highly specialized ways, literally building a display that's dedicated for a single purpose, such as showing a bar graph, or drawing game graphics. Finally, we've got "text" drivers that utilize either the ROM font in the propeller, or 8x8 fonts from older machines. The screen consists of bytes that represent character values, and one 8x8 character is drawn to the screen based on the bytes in screen memory. That's like your older 8 bit computer, or DOS PC display.
So there are "graphics drivers", "renderers", "libraries" all rolling up into various display capabilities, largely determined by the task at hand.
We've also got "Prop as graphics chip" kinds of drivers where a serial or 8bit parallel comms is used to send graphics data to the Prop, including mode, tile, sprite, position, etc... Look at "PropGFX", and Microcontrolled did one like that, both of which dedicate the prop to the task of displaying things sent to it, much like a terminal would.
In your case, you are wanting to do "prop as graphics chip", meaning you need to spec what you want it to do, then build up the pieces. There are lots of video signal and renderer pieces laying about. The pieces that are not so much there are the ones that you need to interface the Propeller to your project. Those are probably harder than the video bits are.
In my blog, I've got a nice VGA games type driver that does tiles and sprites. Baggers and I worked on that one, with the big deal being a great sprite renderer Baggers did!
Both work off of lists. For the tiles, there is a tile data list containing the pixel and color definitions of the tiles, and a screen list that determines which of that data is displayed for each fixed tile position. Tiles are 64x25, and each tile is 4 pixels by 8 pixels high. Screen resolution is 256x240. On top of that are sprites, which operate the same way. There is a sprite data list, which can also just be the tile data list, and a sprite position list, consisting of the sprite x position, y position, and sprite tile address values, which are drawn to the screen each frame.
That driver takes 3 COGS for a fairly good display, and with 5 can do a lot of sprites! (coupla hundred on screen)
Others include a WOLF3D concept demo, where the first level of the game is drawn to the screen, complete with movement and such. It's quite impressive really. That level, video, and textures are crammed into the 32K HUB memory on the Prop. Linus did a "demo scene" style thing with FM sound and great visuals that won 1st place in the Breakpoint demo party "wild" compo a year or two back. Can't recall the name of it right now, but somebody will.
And that's just a sampling of what's been done. There is no defined video capability. What we've got is some silicon that helps make generating the video signal robust and consistent, and from there people build up video display schemes that do what they want them to do, within the I/O and instructions / clock limits of the chip itself. How you do the display will be up to you really.
Edit: (has food now)
What you are going to want to do is fire up your Prop chip when you get it, and run video code. There is a lot of stuff out there, and the best way to get started is to go run existing drivers, then modify them. It's a lot of fun, and something I personally enjoy. There are some sharp people here, and together we've done some crazy good video related stuff. Be sure and look that project Dennis did over closely too. I've wanted to build it, and have the parts, but haven't yet. Some of what he does in there, connecting the Prop to another CPU is info you will need.
Probably, you will want to write your own driver or two, and at that point, it will be possible to start designing your end project. Software video requires thinking about the whole process. That's harder because it's not defined very well, and you have to be careful to work through things small changes at a time. But, the reward is often really great video. Have fun.
You would still have to sort out comms. As written, that driver operates out of the Prop HUB memory, because the data transfer rates are high. Can't feed the beam that way from external RAM. (well, nobody has done it yet) In my earlier posts, I mentioned using some COGS to deal with your project device. Assuming that's done, the code in the driver is there for you to use. Could be as simple as just streaming data into the prop via 8 bit data bus, or have the prop fetch data, or??? Up to you.
Props are just CPUS with I/O, counters and a the video generator piece needed for quick 'n dirty displays. Beyond that, it's code and whatever you choose to do with them.