Yes, 2^8 is 256 so 8 bits will give 256 colors (the current VGA from the propeller is 2^6 = 64 colors).
The big improvement will be the way we can have more pixels. With dithering, even 64 colors and 640x480 will look a lot better than what the propeller can do directly.
But I say no, because there are also two control lines - vsynch and hsync. And now that you mention this, that solves another problem. At the moment, the standard propeller VGA is 6 pins for colors, and 2 pins for control. We need to synch the control line (particularly hsync) with the pixels (google: VGA timing) and look at the pictures. However, if we store the hsync and vsync signals in the ram as well, then they are automatically synchronised. Plus, that saves two propeller pins. So this means 256 colors is going to need 10 bits of the ram chip.
Is there a ram chip out there that has 16 bits and can do more than 512 bytes/words in a burst?
(addit, anyone know how to search for such information? Many times in the data sheet it says that a burst length can be a "full page". However I have just been through a datasheet searching for the term "page" and it doesn't seem to be defined anywhere. Maybe it is called something else? I fond another website that says it is 2^cols, so if there are 9 columns I presume this equates to 512. )
However, if we store the hsync and vsync signals in the ram as well, then they are automatically synchronised. Plus, that saves two propeller pins. So this means 256 colors is going to need 10 bits of the ram chip.
Is there a ram chip out there that has 16 bits and can do more than 512 bytes/words in a burst?
SDRAM can only burst a single page before they need new address loading, and that re-load will not be at Pixel Clock speeds, but at some lower SW-Clock speed.
So the total timing will be a sum of SW-delays during Sync, and then N-Pixel delays during scan.
A prop is deterministic in timing, so storing sync in ram is not so crucial as it might be on another uC
What speeds do you burst clock your HC161 design to now ?
If you changed that to reload every line (which it does not actually need to do now, but will on SDRAM) then you can get a timing-idea, for what SRAM needs.
I'd guess that one timer could do SW-time locks, and Burst Generate, and the other timer could manage Line Sync generation.
(loaded twice, for Hi and Lo times)
Is there a ram chip out there that has 16 bits and can do more than 512 bytes/words in a burst?
Yes, I gave an example above. The 512M ones can do 1024 x 16 , so could cover 640/800/1024 pixel cases.
Unused pixels in a line would be ignored - each new line would reload the same X-counter start
Yes, I gave an example above. The 512M ones can do 1024 x 16 , so could cover 640/800/1024 pixel cases.
Unused pixels in a line would be ignored - each new line would reload the same X-counter start
Perfect!
re the 161, as fast as the propeller will go - toggle the /wr pin on the display, toggle the clk pin on the 161, repeat. So that is 2+2+1 = 5 pasm instructions.
I'm not sure about the VGA speeds. Most of the clock speeds http://tinyvga.com/vga-timing may be more than the propeller can do, so might need an external clock?
In particular the refresh count is 8k for both chips and the row adress is A0-12 which is 2^13 which is 8096. And so I am presuming this is the page size and hence the burst size.
If that is so then the 256mb Micron chip MT48LC64M4A2 – 16 Meg x 4 x 4 banks ought to work too.
Searching PC133 and Micron on ebay brings up lots of modules.
Working backwards, if 512mb and 256mb chips are A0-A12, then what are 128Mb chips? Search on ebay for these and they seem to be A0-A11. So that is 4k and still plenty big enough for burst size.
I don't know how easy these are to desolder? Or whether it is worth it, esp if the pins come to the header anyway?
Need to research other PC100 and PC133 modules. If they are all standardised, then presumably any ram module will work. I'm secretly hoping that I can use all the old memory modules I have sitting in old computers in the shed...
Addit - I hope I am on the right track, but if PC133 ram chips work then how about going back to PC100. Search for some generic modules, check out the part number eg HYB39S64800BT-8 which is 64mbit, and it is A0-A11. Maybe the chips on any PC100 or PC133 ram module will work here?
re the 161, as fast as the propeller will go - toggle the /wr pin on the display, toggle the clk pin on the 161, repeat. So that is 2+2+1 = 5 pasm instructions.
I'm not sure about the VGA speeds. Most of the clock speeds http://tinyvga.com/vga-timing may be more than the propeller can do, so might need an external clock?
So one frequency set would be :
(25.175/2) assumes 50% Clkedge double circuit above, & then *6 -> = 75.525MHz PLL, and a counter would generate DPixel clocks at 75.525/6, for the 640 pixels, or 25.17us of Active Video time.
SW clocking we could assume at (roughly) your HC161 value of 5 PASM = 20 SysClks, or 264.812ns/SW_Clock, so the non-pixel time can 'fit' up to 24 SW clocks, which should be plenty ?
A minimal system I think needs [Active][Read][BurstTerm] opcodes, (the rest are [nop]) and [BurstTerm] could be more elastic if the end-of-line pixels are black filled. - ie a [BurstTerm] at #671 is less important, if 640..671 are all black.
Sync timings come in at :
OpT=4/75.525e6 = 5.2962e-8
0.94u/OpT = 17.748375
3.77u/OpT = 71.1823125
1.89u/OpT = 35.6855625
Which can be a mix of SW and Timer generated.
DDR2 parts are cheaper, but come with lower Vcc, and more complex clocks and I think most have tight timing on clocks, and no full-page - so a CPLD would be needed., along with much more complex development. Even on a Prop 2 DDR2 would be a challenge.
SDRAM are 3.3V and much simpler (relatively speaking )
In particular the refresh count is 8k for both chips and the row adress is A0-12 which is 2^13 which is 8096. And so I am presuming this is the page size and hence the burst size.
Not quite: It is the column counter that does burst, so check that size, and also check it has a Full-Page burst mode.
Full-Page plus 1024 counts, are both key to this becoming easy enough.
I just downloaded the free version of Eagle PCB and checked the libraries with a search for *SDRAM* and it is coming up with these Micron parts. See attached jpg - the 4, 8 and 16 bit versions side by side. Standard TSOP 54 pin package on the board view.
This makes it easier to think about the connections. The DQ lines are bidirectional so they could go to an HC245 and then you can common them onto a smaller number of propeller pins, eg 4 or 8 prop pins. The address and bank lines don't need to be so fast so they could be driven with latches. And drive the clock and the write pins directly.
We need to work out which chip we can use. jmg says that the 16 bit one is only 512 in burst mode. So do we need two 8 bit ones? But on the other hand would be nice to do this with just one ram chip. Maybe it is not possible?
Anyway, in general terms, think of a 16 bit wide buss between the ram chip and the display. Talk to that bus with 8 propeller pins. Those 8 pins go to two 245 chips. You can then control which 245 is connected to the 16 bit buss, and which is in HiZ. And you can control the direction as well, so you can either write to the memory or read from the memory.
Playing around with some ideas. I'm not so good soldering these tiny chips and it is a bit annoying to cook a chip. So if there are a few adapter boards one can unplug and replug, that could make it easier. Attached concept to a box header. Could go to a giant DIL part if you wanted as well.
Getting a SIMM socket is another option - lots of memory around but the sockets are a bit harder to find.
Re jmg's comment
If they use the x4 memories, then you will be OK, but will need 4 packages for 16 bit.
maybe put 4 chips (each with 4 DQ lines) on this adapter board rather than one with 16 DQ lines? Or two 8's?
I'll throw something together re the 245s when I get a moment.
We need to work out which chip we can use. jmg says that the 16 bit one is only 512 in burst mode. So do we need two 8 bit ones? But on the other hand would be nice to do this with just one ram chip. Maybe it is not possible?
It is possible, but maybe not on surplus pulls.
Mouser shows this, which is 1024 x 16, TSOP 54 3.3V :
Looking at the control lines, it may be simpler in SW (and thus faster) with small logic : D-FF's and XNOR gates, to then use edges from the Processor, and then the clock can even be continuous.
/* Edge to Single Pulses, for RoW, Column and also ModeLoad
uC Pins
RASe _____/===============\__________________________________________/================
CASe _____/===========================\_______________/=====================\_________
RD_WRn _______/xxxxxxxxxxxxxxxxxx============\_____________xxxxxxxxxxxxxxxxx===========
Row,Bank Terminate Burst WrData
ModeLoad Active Col.R.Burst Col.W.Single Active Col.W.Single
RAS_ ======\_/============\_/==================~=======================\_/============
cAS_ ======\_/=========================\_/=====~=======\_/=====================\_/====
WE_ ======\_/=================================~=======\_/=====================\_/====
^-SDRAM Pins Pixels : -----PPPPP~PPPPPPPPPPP------
All other clocks are NOP
Define Address and Data, then toggle a control pin, which generates a SINGLE clock pulse Command.
Burst output is via the ModeLoad commands. Writes use Burst Read/Single Write mode.
All inactive states are NOPs
Possible Logic Devices : 4 x D-FF and 3 x 1G57 wired as RAS_:XNOR, CAS_:XNOR, WE_ : OR
*/
The special case of RAS=CAS=WRN=LLL loads the Mode Register, which I think needs Write Burst Mode=Single Location Access, and Burst Length = Full Page and Burst Type=Sequential
It is slightly faster to write same-column, during Sync times, as you do not need to update ROW, but that does constrain input data.
Things like font look-up may be able to do this, otherwise it is
Set.WrRow/toggle RASe/SetWrCol,WrDat/ToggleCASe ...Set.RdRow/ToggleRASe/SetRdCol/ToggleCASe..[Pixels stream here] TerminateBurst
Start with the principle of a propeller dedicated to driving a VGA display. It is going to consume a lot of resources so rather than try to put SD cards etc on the board, do that with another propeller. Another concept - if the max data rate is determined by getting data off an SD card (eg a bitmap) then there is no bottleneck between two fast propeller chips. Use the fast interprop comms object(s), serial or slave SPI or whatever.
So - that means 28 pins are available. Which means we can do this with a minimum of support chips. I started with lots of latches and decoders and the like, but in the end, I think it can be done with just two latches. Use jmg's chip from post #77. Use the resistors from the post above, and have R=5 bits, G=6 bits, B=5 bits.
Below is a jpg capture to give an overview but it is a bit blurry, so look at the pdf for a better version.
It seems too simple. But I can't think of anything that is missing. Even has two propeller pins left over.
It seems too simple. But I can't think of anything that is missing. Even has two propeller pins left over.
Missing is a buffer on the RAM bus, so the write data does not illuminate pixels.
The Video DACs include a BLANK pin that does this, but they are expensive.
I'm not sure if DQx signals are essential - they seem to help high speed write turnaround, at the cost of careful timing, but if you terminate before write, manage contention in SW, and accept a couple of clocks, they can be tied low ? Write is a much lower bandwidth operation than read, in this app.
This seems to have the Prop, in the video delivery path ?
The whole idea behind SDRAM burst reading, is to avoid doing that, so that the Pixel read clock can be faster than software.
ie the SDRAM drives pixels directly, via either a Video DAC + BLANK pin, or a x16 buffer + ResistorDAC with /OE on BLANK
To get reasonable write and read-setup bandwidths, I think it needs to avoid Serial chips, just use Parallel buffers to all Adr,Control lines.
In a 2 prop system, you may be able to just drive A0..A11,& Bank pins straight from Prop pins, as all those lines are latched.
Adding a 74LV174 + XNOR's (1G57) allows faster control of the RASn/CASn/WEn lines & gives more decoupling from the Video Clock.
74LVC1G57 Low-power configurable multiple function gate ?
Yes, 4/5 of those allow these simple logic functions :
* XNOR x 2, for Edge Based CASn and RASn generate, always =\_/= one Pixel CLK wide.
* OR GATE needed for WEn, which is narrow CASn qualified with a Port Pin for RD_WRn
* Inverter on CEn, to allow Global RESET on LV174, to disable SDRAM until the Prop is ready.
( XNOR RASn, CASn already have RESET to Hi (inactive) implicit )
* CLK invert. LV174 is _/= clocked, but so is SDRAM, and control signals need to change on =\_ SDRAM edge, so a =\_ CLK is needed on '174
(The Prop can generate CLK, !CLK, but that extra pin may be valuable ? )
Comments
Yes, 2^8 is 256 so 8 bits will give 256 colors (the current VGA from the propeller is 2^6 = 64 colors).
The big improvement will be the way we can have more pixels. With dithering, even 64 colors and 640x480 will look a lot better than what the propeller can do directly.
But I say no, because there are also two control lines - vsynch and hsync. And now that you mention this, that solves another problem. At the moment, the standard propeller VGA is 6 pins for colors, and 2 pins for control. We need to synch the control line (particularly hsync) with the pixels (google: VGA timing) and look at the pictures. However, if we store the hsync and vsync signals in the ram as well, then they are automatically synchronised. Plus, that saves two propeller pins. So this means 256 colors is going to need 10 bits of the ram chip.
Is there a ram chip out there that has 16 bits and can do more than 512 bytes/words in a burst?
(addit, anyone know how to search for such information? Many times in the data sheet it says that a burst length can be a "full page". However I have just been through a datasheet searching for the term "page" and it doesn't seem to be defined anywhere. Maybe it is called something else? I fond another website that says it is 2^cols, so if there are 9 columns I presume this equates to 512. )
SDRAM can only burst a single page before they need new address loading, and that re-load will not be at Pixel Clock speeds, but at some lower SW-Clock speed.
So the total timing will be a sum of SW-delays during Sync, and then N-Pixel delays during scan.
A prop is deterministic in timing, so storing sync in ram is not so crucial as it might be on another uC
What speeds do you burst clock your HC161 design to now ?
If you changed that to reload every line (which it does not actually need to do now, but will on SDRAM) then you can get a timing-idea, for what SRAM needs.
I'd guess that one timer could do SW-time locks, and Burst Generate, and the other timer could manage Line Sync generation.
(loaded twice, for Hi and Lo times)
Yes, I gave an example above. The 512M ones can do 1024 x 16 , so could cover 640/800/1024 pixel cases.
Unused pixels in a line would be ignored - each new line would reload the same X-counter start
Perfect!
re the 161, as fast as the propeller will go - toggle the /wr pin on the display, toggle the clk pin on the 161, repeat. So that is 2+2+1 = 5 pasm instructions.
I'm not sure about the VGA speeds. Most of the clock speeds http://tinyvga.com/vga-timing may be more than the propeller can do, so might need an external clock?
Page 8, MEMORY ARRAY 8,192 x 1,024 x 16
Page 15: y = 1,024 (x16)
In particular the refresh count is 8k for both chips and the row adress is A0-12 which is 2^13 which is 8096. And so I am presuming this is the page size and hence the burst size.
If that is so then the 256mb Micron chip MT48LC64M4A2 – 16 Meg x 4 x 4 banks ought to work too.
Searching PC133 and Micron on ebay brings up lots of modules.
Working backwards, if 512mb and 256mb chips are A0-A12, then what are 128Mb chips? Search on ebay for these and they seem to be A0-A11. So that is 4k and still plenty big enough for burst size.
I don't know how easy these are to desolder? Or whether it is worth it, esp if the pins come to the header anyway?
Need to research other PC100 and PC133 modules. If they are all standardised, then presumably any ram module will work. I'm secretly hoping that I can use all the old memory modules I have sitting in old computers in the shed...
Addit - I hope I am on the right track, but if PC133 ram chips work then how about going back to PC100. Search for some generic modules, check out the part number eg HYB39S64800BT-8 which is 64mbit, and it is A0-A11. Maybe the chips on any PC100 or PC133 ram module will work here?
Sticking with the lower end, for Prop 1, I find
http://en.wikipedia.org/wiki/Video_Graphics_Array#Signal_timings
So one frequency set would be :
(25.175/2) assumes 50% Clkedge double circuit above, & then *6 -> = 75.525MHz PLL, and a counter would generate DPixel clocks at 75.525/6, for the 640 pixels, or 25.17us of Active Video time.
SW clocking we could assume at (roughly) your HC161 value of 5 PASM = 20 SysClks, or 264.812ns/SW_Clock, so the non-pixel time can 'fit' up to 24 SW clocks, which should be plenty ?
A minimal system I think needs [Active][Read][BurstTerm] opcodes, (the rest are [nop]) and [BurstTerm] could be more elastic if the end-of-line pixels are black filled. - ie a [BurstTerm] at #671 is less important, if 640..671 are all black.
Sync timings come in at :
OpT=4/75.525e6 = 5.2962e-8
0.94u/OpT = 17.748375
3.77u/OpT = 71.1823125
1.89u/OpT = 35.6855625
Which can be a mix of SW and Timer generated.
DDR2 parts are cheaper, but come with lower Vcc, and more complex clocks and I think most have tight timing on clocks, and no full-page - so a CPLD would be needed., along with much more complex development. Even on a Prop 2 DDR2 would be a challenge.
SDRAM are 3.3V and much simpler (relatively speaking
Yes, with 8 ic's on it. With a little luck for a less price as for one new sdram ic alone !
Desoldering: http://www.youtube.com/watch?v=FHfJ_riTdrY
Not quite: It is the column counter that does burst, so check that size, and also check it has a Full-Page burst mode.
Full-Page plus 1024 counts, are both key to this becoming easy enough.
If they use the x4 memories, then you will be OK, but will need 4 packages for 16 bit.
Data says
This makes it easier to think about the connections. The DQ lines are bidirectional so they could go to an HC245 and then you can common them onto a smaller number of propeller pins, eg 4 or 8 prop pins. The address and bank lines don't need to be so fast so they could be driven with latches. And drive the clock and the write pins directly.
I think the addresspins could be handled with 74HC595.
Anyway, in general terms, think of a 16 bit wide buss between the ram chip and the display. Talk to that bus with 8 propeller pins. Those 8 pins go to two 245 chips. You can then control which 245 is connected to the 16 bit buss, and which is in HiZ. And you can control the direction as well, so you can either write to the memory or read from the memory.
Getting a SIMM socket is another option - lots of memory around but the sockets are a bit harder to find.
Re jmg's comment
maybe put 4 chips (each with 4 DQ lines) on this adapter board rather than one with 16 DQ lines? Or two 8's?
I'll throw something together re the 245s when I get a moment.
It is possible, but maybe not on surplus pulls.
Mouser shows this, which is 1024 x 16, TSOP 54 3.3V :
IS42S16320D-7TL DRAM 512M (32Mx16) 143MHz SDRAM, 3.3v TSOP-54 1: $12.28 100: $11.61
Looking at the control lines, it may be simpler in SW (and thus faster) with small logic : D-FF's and XNOR gates, to then use edges from the Processor, and then the clock can even be continuous.
/* Edge to Single Pulses, for RoW, Column and also ModeLoad uC Pins RASe _____/===============\__________________________________________/================ CASe _____/===========================\_______________/=====================\_________ RD_WRn _______/xxxxxxxxxxxxxxxxxx============\_____________xxxxxxxxxxxxxxxxx=========== Row,Bank Terminate Burst WrData ModeLoad Active Col.R.Burst Col.W.Single Active Col.W.Single RAS_ ======\_/============\_/==================~=======================\_/============ cAS_ ======\_/=========================\_/=====~=======\_/=====================\_/==== WE_ ======\_/=================================~=======\_/=====================\_/==== ^-SDRAM Pins Pixels : -----PPPPP~PPPPPPPPPPP------ All other clocks are NOP Define Address and Data, then toggle a control pin, which generates a SINGLE clock pulse Command. Burst output is via the ModeLoad commands. Writes use Burst Read/Single Write mode. All inactive states are NOPs Possible Logic Devices : 4 x D-FF and 3 x 1G57 wired as RAS_:XNOR, CAS_:XNOR, WE_ : OR */The special case of RAS=CAS=WRN=LLL loads the Mode Register, which I think needs
Write Burst Mode=Single Location Access, and
Burst Length = Full Page and
Burst Type=Sequential
It is slightly faster to write same-column, during Sync times, as you do not need to update ROW, but that does constrain input data.
Things like font look-up may be able to do this, otherwise it is
Set.WrRow/toggle RASe/SetWrCol,WrDat/ToggleCASe ...Set.RdRow/ToggleRASe/SetRdCol/ToggleCASe..[Pixels stream here] TerminateBurst
For 16 bits we might go 5,6,5 bits.
Anyway, nice to see photos on that website showing smooth color transitions and a wide range of colors and not needing a fancy DAC chip.
Start with the principle of a propeller dedicated to driving a VGA display. It is going to consume a lot of resources so rather than try to put SD cards etc on the board, do that with another propeller. Another concept - if the max data rate is determined by getting data off an SD card (eg a bitmap) then there is no bottleneck between two fast propeller chips. Use the fast interprop comms object(s), serial or slave SPI or whatever.
So - that means 28 pins are available. Which means we can do this with a minimum of support chips. I started with lots of latches and decoders and the like, but in the end, I think it can be done with just two latches. Use jmg's chip from post #77. Use the resistors from the post above, and have R=5 bits, G=6 bits, B=5 bits.
Below is a jpg capture to give an overview but it is a bit blurry, so look at the pdf for a better version.
It seems too simple. But I can't think of anything that is missing. Even has two propeller pins left over.
One for the main sketch and the second for the vga picture generation ?
And 24LC512 as boot eprom.
32KByte as boot data and 32KByte as additional data region.
Yes, something like that.
Need to think about the code now.
I think feritte barrel ?
Like this one:
http://www.ebay.com/itm/10-Stueck-SMD-Ferrite-25-300-MHz-M2655-/280670419224#ht_971wt_721
Missing is a buffer on the RAM bus, so the write data does not illuminate pixels.
The Video DACs include a BLANK pin that does this, but they are expensive.
I'm not sure if DQx signals are essential - they seem to help high speed write turnaround, at the cost of careful timing, but if you terminate before write, manage contention in SW, and accept a couple of clocks, they can be tied low ? Write is a much lower bandwidth operation than read, in this app.
It use two P8X32A.
The problem are the datalines from the sdram.
This seems to have the Prop, in the video delivery path ?
The whole idea behind SDRAM burst reading, is to avoid doing that, so that the Pixel read clock can be faster than software.
ie the SDRAM drives pixels directly, via either a Video DAC + BLANK pin, or a x16 buffer + ResistorDAC with /OE on BLANK
To get reasonable write and read-setup bandwidths, I think it needs to avoid Serial chips, just use Parallel buffers to all Adr,Control lines.
In a 2 prop system, you may be able to just drive A0..A11,& Bank pins straight from Prop pins, as all those lines are latched.
Adding a 74LV174 + XNOR's (1G57) allows faster control of the RASn/CASn/WEn lines & gives more decoupling from the Video Clock.
The ADV7123 and the ADV7125 are available in the following speed options 50 MHz, 140 MHz and 240 MHz.
Which one is to select ?
Yes, 4/5 of those allow these simple logic functions :
* XNOR x 2, for Edge Based CASn and RASn generate, always =\_/= one Pixel CLK wide.
* OR GATE needed for WEn, which is narrow CASn qualified with a Port Pin for RD_WRn
* Inverter on CEn, to allow Global RESET on LV174, to disable SDRAM until the Prop is ready.
( XNOR RASn, CASn already have RESET to Hi (inactive) implicit )
* CLK invert. LV174 is _/= clocked, but so is SDRAM, and control signals need to change on =\_ SDRAM edge, so a =\_ CLK is needed on '174
(The Prop can generate CLK, !CLK, but that extra pin may be valuable ? )
I hope i have done it in the right way !