jazzed inspired NTSC/PAL Driver.

[davidsaunders]

jazzed challenged me to make a full color video driver for output to television using the Propeller Platform (by: Gadget Gangster) SDRAM module for the frame buffer and video output. Giving the conditions that it must exceed the current drivers in display capability, to the point of being able to not having to repeat any pattern in order to fill the display and it must use 5 COGS or less.

And I accepted his challenge. I am going to order the SDRAM module as soon as I can afford it. In the mean time I will be using a SDRAM IC scavenged from an old DIMM to get started (to which I had already soldered leads to breadboard it for another project, that is long since done). I am also looking through all my old hardware to find the appropriate resistors for the video out. Hopefully the IC on the SDRAM module is close enough that I will not have to make major modifications in order to use my code on the correct HW.

So as to keep the number of posts I have decided to post a periodic log of the status of the progress I am making with this project. and here it is:

3/23/2011
1:) Pixel and simple line drawing functions implemented. Up to 2000 vector draw commands per
frame, though in some cases as few as 150 (figure aprox 2000 pixels updated by vector drawing
per frame).
2:) Still trying to get the output timing lined up for NTSC video.  This part may take a while.

3/23/2011
Wow what a day.  I have not accomplished this much in a single day in a while.
Today I accomplished the fallowing:
1:)  Accepted the challenge to code a better TV video driver for the Propeller Platform using
external SDRAM.
2:) Managed to get a SDRAM driver working on the Propeller, that is based on an earlier,
unreleased driver that I had written for the AVR.
3:) Got the SDRAM read and write speed up to about 4700000 bytes per second max. This
is fast enough for this application.
4:) Began refreshing my knowledge of NTSC, and began studying PAL in relation to NTSC.

[jazzed]

... Giving the conditions that it must exceed the current drivers in display capability, to the point of being able to not having to repeat any pattern in order to fill the display and it must use 5 COGS or less.

Remember the other driver uses 3 COGs for the sprite animations, so you really only get 2 cogs to do the "background" video layer and run the SDRAM driver. Having this will make beautiful GUIs possible.

I think it's great that you accept the challenge. Video on Propeller has made some nice advances in the last 12 months and if you can get something like this working by UPEW end of May, then we will all have something to celebrate in Rocklin.

No pressure though. We'll all be happy to enjoy your contribution whenever it's done.

[davidsaunders]

As I am looking at everything (including my old AVR code), I think that I can do this in two COGS with sprites, and a mouse driver (sorry KB would take another COG). Though if I am wrong at least this will encourage me to keep the COG count way down. I say this as this took two AVRs, one of which was only using about half its available processing power), though required a lot more support HW, and that project did have Mouse and KB.

[davidsaunders]

It looks like it takes 40 longs of code and 4608 clocks (aprox 1.1 millisecond) to read a 256 byte page into COG mem. So if I can keep every thing going this small, should be able to have one cog reading SDRAM while another renders a scan line, and have the one reading SDRAM scan the keyboard and mouse between finishing its read and the beginning of the next scan line (when it is its turn to render). I am keeping my fingers crossed.

[Rayman]

I'm looking forward to seeing what can be done. SDRAM offers some huge capacity and a low price. Plus, I guess it's the future as Chip promised SDRAM support in Prop2 (whenever that comes).

[davidsaunders]

HELP: How can you accurately sync code running in a COG to the Counter?? I am using the counter to clock the SDRAM, and I seem to be well out of sync (and so does my code relative to the generated clock ).

[trodoss]

I think that cog syncronization was discussed in this thread:
http://forums.parallax.com/showthrea...onisation-code.

Hope that helps.
--trodoss

[kuroneko]

HELP: How can you accurately sync code running in a COG to the Counter??

Take your pick, either actively wait for a clock edge and go from there or setup the clock so that it fits (phsx preset).

[davidsaunders]

Thank you trodoss.
Thank you kurenko.

[davidsaunders]

Ok I feel a little space headed now. I had already used the info from the article at: http://www.linusakesson.net/programm...er/pllsync.php to sync my VGA stuff, and I did not even think of it for the SDRAM.

[davidsaunders]

Ok back on track the SDRAM is doing good with 256 Byte burst reads, and writes. Maybe I should actually take a couple minutes to look at someone else code see if I get any Ideas. And double duh, Watch the counter that you are using and you have sync.

[davidsaunders]

And we are off will only post progress here from here on. Currently it takes 2704 clocks to Write or Read 256 bytes of SDRAM. So now that the SDRAM acces is fast enough there are no remaining barriers. at this time. (I am sure that I will find some as I progress though those will not be part of this thread, rather they will be directed to the most appropriate thread I can find). I hope that it will not be more than a week or two before I have enough to post some form of code.

[jazzed]

Ok back on track the SDRAM is doing good with 256 Byte burst reads, and writes. Maybe I should actually take a couple minutes to look at someone else code see if I get any Ideas. And double duh, Watch the counter that you are using and you have sync.

This is in one of the links i posted for you in the other thread. SdramTest-8bit

[davidsaunders]

Thank you Jazzed, that helped a bit.
Some information on the progress:
The Video driver will use COGS 7 and 6 (at this point), and the hub mem used for parameters and buffers is defined by the following addresses:
sdrcmd = $77C0
sdrhub = $77C4
sdraddr = $77C8
drawbuff = $77D0
viddat = $7BD4
vidcmd = $7BD4
vidpar0 = $7BD8
vidpar1 = $7BDC
vidpar2 = $7BE0
vidpar3 = $7BE4
vidxsz = $7BE8
vidysz = $7BEC
linebuff = $7BF0
inbuff = $7BF0
outbuff = $7DF0

The details of the commands is still somewhat in limbo.

[davidsaunders]

I ask what would be expected as far as callable spin code is concerned from this driver? When I run into a snag I work on support functions while working it out in the brain.

[jazzed]

I ask what would be expected as far as callable spin code is concerned from this driver? When I run into a snag I work on support functions while working it out in the brain.

The driver you need to beat should be your guide. Do not ignore work that has come before you.

If at all possible, the SDRAM should serve as both a video buffer and a program code/data store. I suppose one could use 32MB for video buffers only. One thing at a time is fine.

Hardcoded addresses for each of your variables is probably a mistake. Create a "DAT structure" that can live anywhere in memory and be passed to your driver by reference.

Unfortunately a driver requiring 6 or 7 COGs will probably not get used. Maybe that can be optimized later.

[JLocke]

I think he said it will use cogs 6 & 7, not require 6 or 7 cogs.

[Phil Pilgrim (PhiPi)]

I think he said it will use cogs 6 & 7, not require 6 or 7 cogs.

Ugh. Yes, that's what he said alright.

DavidSaunders, do not use coginit to start your cogs! It's very bad programming practice. Use cognew, and record the cog number that's returned, in case you need to stop the cog later.

-Phil

[davidsaunders]

Jazzed:
Cogs 6 & 7, only constitute 2 out of the cogs available in a Propeller. As to the thought on not using static locations; Is there a way to make sure that DAT locations are as close to the top of mem as possible? I ask this because the reason for this choice is to make sure that everything is as much out of the way as possible, as most of the code that I have taken the time to look at only uses the lower addresses, and I wish to make it simple to overwrite the contents of hub ram for applications that would benefit from doing so. Also the buffers are just the default locations, the command and parameter stores are the only portion limited to the static address range.

[davidsaunders]

Phil:
Done. Now the CogInit statements are replaced with CogNew. There were only 3 of them total.