Can you use extra EEPROM space for video buffer stack? (Like on a 128K EEPROM?)
Microcontrolled
Posts: 2,461
I have been making many vidio related projects and I was just wondering if thier was a way to put the video buffer into the remaining 96K so that it dosn't hog program space. Thank you for any ideas you might have.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Toys are microcontroled.
Robots are microcontroled.
I am microcontroled.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Toys are microcontroled.
Robots are microcontroled.
I am microcontroled.
Comments
a) changes frequently
b) has to be read very quick
You can use it to store strings or bitmaps or do it the other way around. Use a lot of RAM for the video buffer leaving only a little bit of RAM for the software and exchange the code frequently. It's very easy to rip off PASM drivers from the SPIN code surrounding it and put it into EEPROM. During initialisation you first load all COGs you need and then you load the main program.
Of course video buffers could be placed in external SRAM. Driven either by port-pins or by a CPLD which keeps the number of needed pins low.
Short answer: No
Long answer:
The EEPROM is accessed over I2C, and even if you got EEPROM's rated for 1MHz I2C, that would still only be about 100KB/sec assuming the EEPROM was able to send you its data at full wire rate.
Even if all you were interested in was a 32 column by 24 row text display on a TV, each second you would need to read:
32 x 24 x 2 x 60 = 92,160 bytes per second
The "2" is because you need two bytes for a tile address
The "60" is because the TV needs 60 fields per second.
This is just barely shy of the wire rate for rare 1MHz capable EEPROMs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Las - Large model assembler for the Propeller (alpha version this week)
Largos - a feature full nano operating system for the Propeller
www.mikronauts.com - a new blog about microcontrollers
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Toys are microcontroled.
Robots are microcontroled.
I am microcontroled.
Microchip direct carries SPI SRAM (in DIP8 format) for $1.18 (256K) and $.64 (64K) and with a max operating speed of 20 MHz (2MB/s), i think it would be perfect for video buffer memory
www.microchip.com/ParamChartSearch/chart.aspx?branchID=270121&mid=〈=en (256K)
www.microchipdirect.com/ProductDetails.aspx?Catalog=BuyMicrochip&Category=23K640&mid=1&treeid=3 (64K)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Disclaimer: I cannot guarantee any information i post is accurate, but most of the time, it is correct.
known programming languages: SX/B, PASM, SPIN, BASIC, PBASIC, PICAXE BASIC, C/CPP, 8086 ASM
Misses 8 bit computing
Post Edited (Matthew Burmeister) : 6/8/2009 11:09:57 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
No purchase necessary. See back panel for more details.
SIP SRAM?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Disclaimer: I cannot guarantee any information i post is accurate, but most of the time, it is correct.
known programming languages: SX/B, PASM, SPIN, BASIC, PBASIC, PICAXE BASIC, C/CPP, 8086 ASM
Misses 8 bit computing
Post Edited (Matthew Burmeister) : 6/8/2009 11:06:11 PM GMT
Typo. I meant SPI.
Mike, thanks for the information! I have been looking for some external RAM for propeller chip. maybe sooner or later when I learn assembly and SPIN, I will eventually use that for video buffer.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
No purchase necessary. See back panel for more details.
The current SPI drivers should be able to handle SPI SRAM, or would be easy enough to modify if they don't (note that you'll need PASM drivers to get any reasonable kind of speed). A quick look at the SRAM datasheet indicates they would probably need some modification to handle the non-page based sequential access modes.
However, a quick "back of an envelope" calculation (and also this website http://www.pcguide.com/ref/video/memBandwidth-c.html) seem to indicate that even at 20MHz this is not fast enough for even the lowest resolution video display.
Am I missing something?
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Along with sync pulses off the prop counters for H and V, couldn't that do something like a 640*400*8 color display? You'd update the SRAM in between fields using the byte mode or sequence mode.
tubular
Good idea - I didn't think of that. But you'd probably need at least one cog to drive each SRAM chip to read the stuff in, plus (based on previous experience) at least one cog for each color plane to push the stuff out again as VGA - which wouldn't leave many cogs left over for much else.
Also, if I'm right in thinking that reading the video buffer data in from SRAM and pushing it out again as VGA can't be done on the same cog, then we're back where we started - i.e. requring video buffers in hub ram.
Not dismissing the idea - just wondering if it's really worth it. I don't think SPI SRAM was designed with this kind of high-bandwidth application in mind.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I'm not thinking of bringing a whole lot of data back IN to the prop... leave the video buffer out in the 3 SRAMS, and just 'paint' to the buffer as required, as fast (pasm) or slow as you like (spin?), during the time in between displayed fields. Remember the srams can be addressed in byte mode or page mode so you just update the part of the buffer you need to.
It could be "optional" to bring the SRAM serial out back into the prop (for image processing apps or other sram use)
tubular
edit: just use counters to drive the H, V, and SRAM clocking. You could certainly do all the output stuff in 1 cog.
Post Edited (Tubular) : 6/9/2009 1:06:15 AM GMT
You could certainly use the SRAM to build and store bitmapped displays, then read them back in later when you needed to display them. Perhaps this was what Microcontrolled originally had in mind - a place to store memory-hungry screen images when you didn't currently need them.
In fact, a similar technique is used (in a read-only way) by some programs on the Hydra, which has a 128k eeprom - the lower 32k of the eeprom is used to store the application code, and the upper 96K of the eeprom is used to store other 'assets' (hence the need for a 'Hydra Asset Manager') - such assets can be sound files, screen images or just about anything else.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Las - Large model assembler for the Propeller (alpha version this week)
Largos - a feature full nano operating system for the Propeller
www.mikronauts.com - a new blog about microcontrollers
I don't think I'm explaining it well... let me try again, just thinking straight "output" for a moment to keep it simplest.
The R, G and B SRAMs would be continually dumping their entire 1-bit buffer out to the VGA monitor, about 60 times a second, using their 'sequence (burst) mode' (which, as I understand, can spit out all 262144 bits in one long sequence). This could all be driven by counters to deal with porches, H and V sync etc.
The only time the Prop would write to the SRAMS would be when some change was required on the screen. It could do this by just writing to the byte/page that needs updating, *during the interval when the SRAM is idle in between screen refreshes*. Spin could be used, or PASM, as long as the update was complete before the SRAM goes into over to 'output' mode again.
The technique could easily be expanded to 6bit/64 colors (using 6 SRAMs), or beyond. You're just increasing color depth so bandwidth wouldn't change. You could even do 24 bits by tying up almost all the prop pins, OR by having an external latched colour mask.
hope that explains it better
tubular
If only updating when something changes on the screen, do you really need massive bandwidth? I think a lot of the time the updated sections are pretty small.
It should also be possible to temporarily pause the SRAM output stream (black screen), load up the SRAMS (or a portion thereof) at 20Mhz, and resume. But I expect that getting the data pre-assembled in the prop will be the bottleneck, not the 20MHz dump to SRAM.
Hence updating the SRAMs in between fields might actually work reasonably well (because the Prop can be assembling picture data the rest of the time while the SRAMs are in output mode).
tubular
No, I'm not sure I get it. Let me think out loud here, and you let me know if I'm on the right track ...
You talk about the SRAMs 'dumping' their output, which I can kind of understand - sort of like having an external chip doing what the WAITVID instruction on the Propeller does - but with a bit buffer that can hold 32k bits instead of just 32 bits at a time (which is all that WAITVID can handle). You probably wouldn't do this for a whole screen, because a lot of the time when generating a VGA signal you aren't actually outputing any data (e.g. during the front and back porches etc). And you normally need this time for 'housekeeping' anyway - e.g. to update your screen image. But you could perhaps have the SRAM dump a scanline at a time. But the timing of this 'dumping' is actually very critical when generating VGA ouptut, which means you'd have to be able to control the clock speed of the SRAM chip with precision, the same way the Prop does with all its internal clock circuitry - but then perhaps you could actually drive the SRAM clock from the Prop itself. Is that what you intended?
If this is what you had in mind, the biggest problem I can see is the synchronization required between all the SRAM chips. This has to be perfect, or the output will be just rubbish. I don't know how you would achieve that without a cog dedicated to each chip. You also need an SPI interface dedicated to each chip. Maybe you could do all the VGA timing, screen updates AND handle the SPI interface in a single cog per SRAM chip - but I doubt it. I still lthink you will need at least two cogs per SRAM chip.
But at least I think I can now see how you intend to avoid the need to have the screen buffers in hub ram.
Am I on the right track here?
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Yep getting close now. I was thinking of using the 256kbits chip, to hold the entire 641*400 pixels where the 641th is black.
The SRAMs are inherently synchronised, during "output phase" you would be sending exactly the same command to all three, and the CS and CLK would be common. There is one pixel per clock. The Prop is great for keeping stuff like this sync'd.
I'm rusty on my porches - it may be possible to simply incorporate these in the buffer to make it easy to dump an entire screen at a time, porches and all, end minimise cog requirement.
tubular
Okay, I think I get it - interesting notion. Using the chips this way would waste quite a bit of RAM (the VGA scanline is much wider than the active part of the line) but RAM is cheap, so why not?
Let me know when you've bult one - if you can do it in less than 6 cogs I might even buy one [noparse]:)[/noparse]
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I have a better notion - I'll give you a 50% discount on a copy of Catalina!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I understand what you are proposing, and it would work - but my "back of the envelope" calculation shows it would take approx. 0.3sec to repaint the whole screen with 80x25 text if only the vblank,vfp,vbp times were used - which was why I never built the circuit, as it was too slow for my purposes. Mind you, if you did not have to update the whole screen at once, it would work much better, and your suggestion of blanking the video for a frame or two also has merit.
If I was not so busy getting ready for UPEW I might wire it up [noparse]:)[/noparse] maybe afterwards if no one else does it first.
Only reason I'm reading/posting is its a nice break during debugging Largos & Las!
Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Las - Large model assembler for the Propeller (alpha version this week)
Largos - a feature full nano operating system for the Propeller
www.mikronauts.com - a new blog about microcontrollers
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
50% off (free) Catalina? Quick where do I sign? I think it was Lindsay Fox I once heard say that aussies will buy *anything* at 40% off. Even free software. Jousting sticks, anyone???
@Bill,
Don't let me distract you too much from largos, we're all curious about that one! I really don't have too much time ATM either but will get some chips in and see if I can at least prove the concept as I'm curious myself.
@Steve,
I think I remember the thread but will have to hunt as well. It may have been under Ken's "will the real SPI object..." thread
tubular
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
Post Edited (James Michael Huselton) : 6/9/2009 7:36:20 AM GMT
How much? Tell 'im he's dreamin'
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Toys are microcontroled.
Robots are microcontroled.
I am microcontroled.
LOL, sorry for hijacking the thread and heading somewhat off coarse. I hope some good will come of it soon, but in the mean time I am happy to start a new thread specific to RGB SRAM.
Rather than rename, you might to kick off a new thread - that way fresh eyes may see it without sifting past all the Sram stuff.
The SRAM ideas discussed may still be useful with the assistance of something like an AD723/4/5 to bring it back to NTSC.
tubular
after reading 2/3 of the postings I came to this opinion:
everybody who enjoys DEVELOPING new things do it.
If my goal would be a big displaybuffer I just would use a second prop.
a display-prop and a "do all the rest-prop"
The effort for developing this will be much smaller
best regards
Stefan