CHALLENGE: ==Graphics-object-compatible TV driver with SRAM buffer.==

Microcontrolled

I am not currently offering a prize for this one: so for now it's just for the fame and glory of the parallax forums.· Your username will be annouced as winner in my signature for 3 months.·

This is the challenge: Create a standard TV driver that is compatible with an external SRAM chip in which it will use as the display buffer. The more fuctions the better; and you get even more points if you can make it able to run 2 screens at once on different cogs, since all buffer space must be on the external SRAM. I do not know anything about composite video, so I won't be trying to make this too. The driver MUST BE COMPATIBLE WITH·THE PARALLAX GRAPHICS DRIVER!!!

This is a just-for-fun contest that will hopefully challenge, create, and just give you something to do.·
Good Luck!!!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Toys are microcontroled.
Robots are microcontroled.
I am microcontroled.

jazzed

The Graphics driver writes directly to the HUB ram being used for display and that code will have to change. Everything else should remain the same in the Graphics object ....

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

stevenmess2004

This could actually be a bit difficult. How about using a dual port ram? Would make it a lot easier...

The difficulty comes from having to sync reads and writes from two different cogs that aren't going to be synced very well due to the way the graphics commands work. It may be possible to get the job done by just using the locks but there isn't any room in the graphics driver to fit anything more in unless you start using overlays or take stuff out.

I believe that Baggers or someone was experimenting with tv/vga drivers that used the 512kB hydra sram card. If you have a look in the hydra forum you should be able to find it.

Baggers

Yes, it's true I've been looking into this [noparse]:)[/noparse] the issues that have arisen are speed, even with full access to sram pins like Cluso99's boards this is still a bottle neck, as it takes 4 instructions to get a byte, in PAL you have 64us per scanline, at 24Mips (6Mhz Crystal) you have 24*64 (1536) instruction slots per scanline, at 4 instructions per byte, gives you 384 byte reads in total, per scanline, that's not including setup etc.
so basically all the sram access time is used up by reading the display for rendering, during display time, you are then free to write to sram in the vertical borders and blanking time, not overly much time to update the whole screen, ie, you couldn't clear the frame buffer each frame because you would probably only get a third ( don't quote me on that third I just picked that out of thin air but it wouldn't be a LOT of writing time. ) cleared before the next frame,
You could however try for 16 colours per pixel, giving you more time, also maybe some time for writing some bytes during screen display time too.
I've got a display driver working 256x192 8bit with sprites ( from hub-ram ) but i'm not overly happy with performance of updating the background.
will do some more jiggery pokery and show all as it were.

Baggers.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

Microcontrolled

It is hard, (That's why it's a "challenge") but not impossible. At least I can tell that you guys know what you are doing. Speed is an issue, but it is still possible to write to the SRAM and read it in time to refresh the display.

@jazzed: I have thought of that too. If you want, you could just write a combanation TV/Graphics driver.

@steavenmess2004: I have seen the one in the Hydra forum. The problem is, few people own a Hydra, and of those who do few people own an expantion card.


P.S. My signature is ready for the winner!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Toys are microcontroled.
Robots are microcontroled.
I am microcontroled.


If it's not Parallax then don't even bother. :-)

Propeller SRAM TV driver winner: ==NOT COMPLEATED: 3 WEEKS UNTIL ENDING TIME==

jazzed

SRAM byte writes actually take more than 4 instructions with separate address and data pins - would be better if rdbyte didn't sign extend [noparse]:)[/noparse]. Having the data bus on the upper 8 pins would help a little.

Performance can be improved by writing more than a byte at a time with 2 COGs ... I've seen a PASM design using 5 COGS for block access. For 2 COGS, COG1 sets address, data, and enables ctra controlled write strobe, and triggers COG2; COG2 is the address stepper COG. By using a long write and 2 COGS, one can realistically get 3 instructions/byte for random long access or 2 instructions/byte for a block write.

The spin *move instruction loop takes 6 instructions per long (after setup) for block move. So if one creates a specialized longmove that sets address and signals the address stepper cog at startup, the situation looks better.

The net effect could be that the block move may add 8 instructions to the "block loop" per long vs spin's longmove (6 intra hub -> becomes -> 14 inter device).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

kuroneko

jazzed said...
SRAM byte writes actually take more than 4 instructions with separate address and data pins - would be better if rdbyte didn't sign extend [noparse]:)[/noparse].

Did I miss something? My rdbyte zero extends (as stated in the data sheet).

jazzed

Yes, it is zero extend. Similar effect though. Set address on p8-N, rdbyte p0-7 ... address gone before next rdbyte.
Some alternatives do exist of course including having another cog handle the address [noparse];)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

kuroneko

jazzed said...
Yes, it is zero extend. Similar effect though. Set address on p8-N, rdbyte p0-7 ... address gone before next rdbyte.
Some alternatives do exist of course including having another cog handle the address [noparse];)[/noparse]

OK, point taken [noparse]:)[/noparse] Better get my morning coffee ... Then again, I would be really cross right now if it didn't zero extend!

Post Edited (kuroneko) : 6/11/2009 11:39:59 PM GMT

jazzed

Point taken [noparse]:)[/noparse] Of course with the right speed memory and enough COGs one could do almost anything [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

Post Edited (jazzed) : 6/11/2009 11:56:55 PM GMT

Tubular

For timing discussions, it might be worth disclosing the screens I have in mind (aside from VGA monitors). I intend to use Bill's 6.25Mhz crystal, PLL16x, divide by 5 to generate the 20 Mhz for the clocked SRAM

1) The Sharp LQ043T3DX0A (PSP), the touch verion of that sold by Sparkfun
4.3", 480*272, 9MHz dot clock
This screen has very lean blanking intervals but a low dot clock

2) AU Optronics G065VN01 (TTL version)
6.5", 640*480, 20 MHz dot clock
This screen *may* have relatively large blanking intervals which would allow some sprite manipulation at the end of each horizontal line. According to the datasheet,
Horizontal max: 640 active pixel clocks + (130-430 blanking clocks) 430 is 40%, double the standard
Vertical max: 480 active lines + (40-142 blanking lines). 142 is 22.8%, again about double the standard.
*If* all stretches can be simultaneously exploited, that gives an overall active % of (640*480)/(1070*622) or 46%, leaving up to 54% of the time for SRAM writing

I should declare my own goal is just to prove the concept for static images at 20 Mhz. I probably will just pre-load the SRAMs at leisure using SPIN with a blank screen, then switch over to 'sync clocked display mode'. I'll do a simple PCB to suit the proto board. Then others more familiar with this PASM can work on the driver smarts.


tubular

Microcontrolled

I was talking about a standard NTSC-compatible screen, tubular. Not a miniture LCD!!

Edit: sorry if it sounded like I was yelling at you. Things always read different then you type them to be.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Toys are microcontroled.
Robots are microcontroled.
I am microcontroled.


If it's not Parallax then don't even bother. :-)

Propeller SRAM TV driver winner: ==NOT COMPLEATED: 3 WEEKS UNTIL ENDING TIME==

Post Edited (microcontrolled) : 6/12/2009 10:49:38 PM GMT

Tubular

I hear ya, Microcontrolled!

As indicated in the other thread it should be possible by adding a RGB to NSTC chip such as the AD723. I do intend trying this but haven't checked the detail on the required timing just yet. Due to the interlace it will require graphics written to two locations in the SRAM.

I don't have the AD723 yet but to have the LCDs handy

This schematic from the AD723 datasheet makes it look quite possible...

Dennis Ferron

I've been working on a "rolling buffer" NTSC driver that could be useful here. It's sort of an NTSC-generating back-end that you can tack various front-ends onto. The driver uses a buffer in hub RAM as its input and outputs the contents of the buffer as an NTSC signal. The trick is you don't need a complete framebuffer - the buffer is only as big as a fraction of the screen size, typically between 2 and 20 scanlines. When the driver gets to the end of the buffer, it "rolls over" and repeats the beginning of the buffer - that's why I call it a rolling buffer. If you didn't put anything else into the buffer, of course the screen would just be filled with repeats of the same 20 lines. The reason that doesn't happen is that *by the time the NTSC backend wraps around* your front end will have already filled the buffer with the *next* 20 lines. The front end just needs to pump out lines fast enough to stay ahead of the NTSC driver.

There's two benefits to this: one, it does the hard work of generating the NTSC signal so your front end can be simpler. Both in the respect of not needing to do the hard programming, but also in terms of the front-end cog not needing to spend *time* doing the NTSC. I've pretty much convinced myself that there is not enough time to do a lot of the more complicated things in the same cog as what's generating the NTSC; I'm pretty sure for a lot of these things (accessing SRAM being one of them) you're going to need 2 cogs, one to talk to the RAM, the other to make the NTSC.

But the other benefit is that having this buffer of some number of scanlines allows the front end to have time to "catch up" during the lull periods while the NTSC driver is waiting for HSyncs and VSyncs. I originally wrote the driver for my Prop6502 laptop; I wanted to make a TV driver that used the 6502's SRAM as a framebuffer. The fastest I was able to overclock the 6502 to pull data from the SRAM chip was 3.6 MB/sec, and I needed at least 3.8 MB/sec to keep up with the TV scan! But, if I made the buffer big enough, I could pre-load part of the frame, fall behind throughout the whole frame because my data pull can't keep up, but by the time we get to the end of the frame it's Vsync time and I can catch up and preload lines for the next frame.

I've started and stopped working on this driver over a course of about 2 years - I keep getting busy and not finishing it. The state that it's at right now, if I recall, is that it does work to generate NTSC from a framebuffer, but currently it uses a rolling buffer that's still as large as all the scanlines. That's because the part I haven't finished is the design of the synchronization mechanism that will tell the front end what scanline it's on and when to run & when to stop (because if the frontend goes too fast, it could overwrite lines that haven't yet been displayed). The other part not finished but planned is a way for the front end to tell the driver "whoa, whoa, I can't keep up!". When that happens, what you would do is set a flag in your front end code that says "I took too long to render this line; please DOUBLE UP on this last line when you display it (display same line twice in a row); meanwhile I'm going to elect to skip the next line and render the one after that."

Post Edited (Dennis Ferron) : 6/12/2009 9:09:36 PM GMT

Microcontrolled

@tubular: Actully, now that I think about it; an object for a miniture LCD with SRAM is just what I am wanting to experiment with, so it is valid for the challenge!!!
I am developing a "Propeller moble device development kit" as soon as I get enough money, so this is just what I needed! However, to not interfere with the other developers I will reserve a special place for you in the annoucment if you evr get it made.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Toys are microcontroled.
Robots are microcontroled.
I am microcontroled.


If it's not Parallax then don't even bother. :-)

Propeller SRAM TV driver winner: ==NOT COMPLEATED: 3 WEEKS UNTIL ENDING TIME==

Microcontrolled

Is anyone planning on making this? Or is this just a bad idea?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Toys are microcontroled.
Robots are microcontroled.
I am microcontroled.


If it's not Parallax then don't even bother. :-)

Propeller SRAM TV driver winner: ==NOT COMPLEATED: 3 WEEKS UNTIL ENDING TIME==

jazzed

Hard yes. Impossible? Maybe. Bad idea? We'll see. I have SRAM modules coming this week that support fast access SRAM. I will look at your challenge, but it will not be certainly not be done in 3 weeks.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

Phil Pilgrim (PhiPi)

I've had a double-buffered VGA design in schematic form for a couple months that uses two sets of three serial RAM chips and eight Propeller pins. I started a PCB layout, but it got put on hold due to more pressing commitments. Although the double-buffering gives one an indefinitely wide time window for writing the memory, the serial addressing inefficiencies may still render it impractical for real-time graphics work. I'll probably just have to finish it and try it out to see. The Microchip serial RAM is rated to 20MHz. VGA requires a 25MHz dot clock, but my thinking was that the RAM could be overclocked by 25% and still work. We'll see.

-Phil

Tubular

Yes, finding the blissful union of dot clock, horizontal sync and crystal to drive it all is surely the key. I don't know yet how the 23K256's respond to overclocking, I'm about a weekend away from finding out

As far as I can tell, the 25 Mhz dot clock isn't required for VGA. What is required is accurate timing, but because of the highly divisable (/16) nature of the prescribed porch and sync intervals, it should be easy to underclock but with the same overall absolute timing. This is why I chose 0.75* - dot clock is 18.9 Mhz, 480 rather than 640 active pixels, but in the same 25.17 uSec active time.

Phil, I think the double buffering should be useful for interlaced video output.

I haven't designed up a PCB but am starting to think what could be done. I'm thinking mounting the SRAMs on both side of the board (TSSOP or perhaps even twin DIP) would at least keep up with the 0.1" pitch per pin.

tubular

Microcontrolled

@Jazzed: You can take up to 3 years if you want too, but if someone maraculously compleated in 2 weeks then I would annouce them as winner.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Toys are microcontroled.
Robots are microcontroled.
I am microcontroled.


If it's not Parallax then don't even bother. :-)

Propeller SRAM TV driver winner: ==NOT COMPLEATED:·2 1/2·WEEKS UNTIL ENDING TIME==

jazzed

I've never committed to the challenge. It's fun to talk about though [noparse]:)[/noparse]

If you want "Mobile Device Development Kit" hardware, why don't you just use a $15.00 Nokia Knockoff 1.5" LCD which has SDIO accessible SRAM (not TV fast) and controller already built in?· You could use the $40 on a breakout card with supporting regulator ... or custom board with a Propeller for about the same price. I have a device driver and graphics widgets you can use for your dev-kit already written.·Maybe you saw the video http://www.youtube.com/watch?v=YalcMqkdHEU .... There is Rayman's PSD of course ...·don't know if the·QVGA·has buffer memory or not.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

Microcontrolled

I was planning on using that exact screen for the "Moble device Development kit". I did not know that it had a built in SRAM and had a driver written for it! If it is small, then that would provide more room for other input means. It would be really great if I could find a touchscreen to fit it. I was planning on getting a board made for it (open for manufacturing company suggestions) and I was going to use Advanced Assembly to assemble the board for me. I have a small budget, so if I ever did get it made then it would have to be that i got some commited orders ahead of time; which most likely won't happen.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Toys are microcontroled.
Robots are microcontroled.
I am microcontroled.


If it's not Parallax then don't even bother. :-)

Propeller SRAM TV driver winner: ==NOT COMPLEATED:·2 1/2·WEEKS UNTIL ENDING TIME==

jazzed

The LCD I mentioned is actually 1.8" diagonal 1.3" square viewing area. My biggest complaint is with the backlight which shows up on the youtube video as two bright glowing areas at the top ... the good news is the display can be flipped upside down so the backlight doesn't look so bad. I was also thinking about this mobile development idea (MDK) last year and is why I started writing a GUI program for drawing widgets. Software is a hard sell around here though [noparse]:)[/noparse]

I've attached a picture of my hacked case, LCD, 3.6V NiMh·battery (3x1.2V), and a quarter. The Propeller is on a hacked protoboard and mems accelerometer resting behind the LCD. The program is the same one from the video.

Problems to overcome are: finding an attractive case and keypad, designing a pcb for the case, and having a reasonable battery charger or 3AAA case (I'm using a cordless phone for charging now). I have no idea how to find such a small touch screen. At least the propeller has lots of free pins for this [noparse]:)[/noparse]

Anything else on this device should be in another thread I guess.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

Microcontrolled

I'm starting a new thread now.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Toys are microcontroled.
Robots are microcontroled.
I am microcontroled.


If it's not Parallax then don't even bother. :-)

Propeller SRAM TV driver winner: ==NOT COMPLEATED:·2 1/2·WEEKS UNTIL ENDING TIME==

kwinn

In many cases I can buy a new 15/17” monitor from my local computer parts supplier for less than all but the smallest displays I see advertised on line or mentioned in this forum. I would love to use them for graphics so here is a block diagram of what I would like to see in a graphics display controller.
I see no reason why such a chip could not be produced at reasonable cost. This would essentially be an updated Intel 8275/Motorola 6845 with a built in processor.

The display parameters (dot clock frequency, H Sync, V Sync, H Pixels, V Pixels, etc.) would be programmable.

It should be able to handle 2meg of 8, 16, or 24 bit wide memory for 256, 64k, or 16M colors, and maximum resolution would be 1920x1080. If this resolution can’t be achieved economically then 1280x1024 or 1024x768 could be used.

Communications between the controller and the micro would be serial (I2C, SPI, ?) to minimize signal lines.

Objects to be displayed would be uploaded as sprites (widgets?) and commands would place them where wanted on the screen along with information to be displayed. The controller would update the ram image based on the commands sent by the microcontroller.

Oops, almost forgot the block diagram.

Post Edited (kwinn) : 6/21/2009 7:51:21 PM GMT