So 640x480 is 307200 and at 16 bits it is one pixel per word, so a 16megabit chip is 1 megaword so lots of space left for buffering sprites etc. But if it is 640, will that work if the burst is only 512?
512 is not enough to easily do 640, hence my references to 1024 (or using 2 x 8 x 1024), and why the burst-size is likely to select the memory, more than Size.
SDRAM takes a few clocks to re-address outside the simpler Auto-Inc of Full page, so would then need buffering and faster clocks. Quickly gets complicated.
Easier to select a part that can Auto-inc burst enough clocks, and Page align scans ?
it is on that discussion thread somewhere, but it will take a bit of time to find it (i'm not so good with the forum search). But it was just five 161 counters chained one after the other to count the address line of a sram chip. Nothing special, but it saved a lot of propeller pins. It was for sram chips that (as far as I recall) were never going to be fast enough to drive a vga scanline in real time, so we never went down that road. But these sram chips being discussed here are much better - they are faster, they have automatic clocking and they are bigger and they are cheaper.
Good points jmg. Yes, the burst size will select the memory. Is 640 the minimum? Or could one accept 512 and have black bars on the sides? Or stretch it a little? Hmm - I suspect if it works for 640x480 pretty soon we are going to want 800x600 and 1024 etc. May as well plan for a decent size? The part that was over $10 - given all the other costs such as making PCBs and support chips, that may not be such an issue.
Yes, no problem with the voltage. The propeller is 3.3V and the ram chip is 3.3V. They can be connected directly. Might need some 74HC245 buffers if you want to save propeller pins by connecting 8 propeller pins to 16 ram data pins, but the HC series also run at 3.3V.
Writing the driver for the chip is going to be the hardest part. Will need to work out which pins need to go directly from the propeller to the sram (eg clock) and which ones can go via another chip (maybe latches or 595s for the address and bank pins. HC373 or HC374s are going to be faster but use more pins. ). Then write the code. I find it easier to write code in spin first and get it working slowly and then translate to pasm, but some of this is going to need to be debugged in pasm as it needs to be very fast. At the simplest level, writing a spin driver to write a byte to the ram and then read it back would be a start. The data sheets are a bit complicated!
Another idea. By the time you buy one of these chips, plus an adapter, and try to solder it, I wonder if it might be better to recycle a PC100 or PC133 memory module? Available for $1 or even giveaway, and the pins are easy to solder to (or get a socket?). Lots of chips on the module and maybe you only use one of them? Would need modules that have chips that can do burst mode though. Need to look at the specs. eg quick search http://pdf1.alldatasheet.com/datasheet-pdf/view/37694/SAMSUNG/PC100.html and this seems to have burst mode. 64 bits, ok, we only use 16 or less of those so that makes wiring simpler.
SIMM 72 is an earlier ram format. Sockets for these might be the hardest part - lots of sockets soldered into boards but not so many around that are unused at a good price. The socket might cost a lot more than the ram module. Must be some other micro users out there who have hacked these? It is a trip back in time, eg simm 30 pin is 60ns which is too slow and also seem to be 5V. I'm seeing 5V also for some simm72. Not sure when everything changed to 3V3. The 168 pin ones seem to be either 3V or 5V. More pins =more recent = bigger but potentially more complicated. Don't want too many support chips just to talk to these modules.
Good points jmg. Yes, the burst size will select the memory. Is 640 the minimum? Or could one accept 512 and have black bars on the sides? Or stretch it a little? Hmm - I suspect if it works for 640x480 pretty soon we are going to want 800x600 and 1024 etc. May as well plan for a decent size?
The part that was over $10 - given all the other costs such as making PCBs and support chips, that may not be such an issue.
- that price will also (hopefully) come down.
Looking at clock choices, I see DDR memories tend to be lower voltage, and with more complex clocks, and they dropped the Full page burst modes.
However the SDR memories have very tolerant clock widths, so would lend themselves to clock doubling at the pin, using a XOR gate (Tiny Logic 74LVC2G86DC or similar).
That means a single edge from a Prop is needed for SW loads, and the burst-read-clock can be halved in frequency, which also makes life easier from a Prop1.
SIMM 72 is an earlier ram format. Sockets for these might be the hardest part - lots of sockets soldered into boards but not so many around that are unused at a good price. The socket might cost a lot more than the ram module. Must be some other micro users out there who have hacked these?
The TSOP ii 54 pin packages are 0.8mm, so that is not too hard to manage ? - you need only one.
.... Then write the code. I find it easier to write code in spin first and get it working slowly and then translate to pasm, but some of this is going to need to be debugged in pasm as it needs to be very fast. At the simplest level, writing a spin driver to write a byte to the ram and then read it back would be a start. The data sheets are a bit complicated!
The refresh nature of DRAM means going too slow will have issues, but you could make a (roughly) hardware-compatible SRAM interface, that used load-able Column counters (which you have already), from CAS#, and latches for Row (RAS#) and Bank (both RAS# and CAS# ).
It is just a few gates, or a SPLD, to take SDRAM control lines to SRAM+Latches+Ctr.
Pass 1 could hold Bank static and just load Row/Col on one pane, for simplicity.
Looking at AS4C16M16S Fig 36.1, it looks like a moderate bump in complexity might bring banks into play ?
Provided you can pre-read banks, and then flip-on-the-fly, then the pixel stream is unbroken.
It needs a carefully timed, mid-line bank-change.
Fig36.1 seems to show that.
However, starting with a larger Full-page device avoids that detail, early on, and allows everything else to work.
Adding in bank change mid line, would allow smaller SDRAMs to be used, but I suspect the bigger parts will fall in price, and their easier higher clock handling, and less critical timing will win out.
Looking at the schematic on that site http://tinyvga.com/avr-sdram-vga there is a micro and the ram chip and then a DAC chip. Not much else. It might be a bit more complex on the propeller as the prop doesn't have quite as many pins (eg when you devote 4 to an SD card etc). But it provides a starting point. The ramdac could be replaced with resistors. I think rayman did some clever calculations with the impedance to get better colors with 2 bits per color, so if it works for 2 bits, could we go for 3 bits per color etc. Start simple and grow it. If the current circuits are any guide, it is 3 resistors per bit (the demoboard used two resistors but 3 resistors is better). If soldering lots of resistors is a pain, there are always resistor networks.
Nice to see a TSOP can be soldered to a homebrew board.
Plus the photo on that page is actually a photo of the display, displaying the board, and it looks pretty good even with 8 bits and 512 pixels. Looks like they came up against the 512 pixel cache-burst problem too, but maybe it is better to walk before you can run, and start with 512 pixels and 8 bits and know that it can be extended to higher resolution using techniques jmg describes.
The code is a different assembly but this shows it is not a crazy idea at all. All we have to do now is to declare it "impossible to do on the propeller"
I think rayman did some clever calculations with the impedance to get better colors with 2 bits per color, so if it works for 2 bits, could we go for 3 bits per color etc. Start simple and grow it. If the current circuits are any guide, it is 3 resistors per bit (the demoboard used two resistors but 3 resistors is better). If soldering lots of resistors is a pain, there are always resistor networks.
Rayman uses the ADV7125 I think, on his SSD1963 Board, and that would be a natural for this.
The AVR design was done long before you could buy N x 1024 x 16 SDRAM parts, so they stuck at 512 x 8.
Their output DAC looks to be the older Video RAM+DAC, which has a palette lookup, from way back when memory was expensive and Analog was cheaper. I'd guess an ADV476 equivalent as that came in a 28 pin package.
With 16 lines, the ADV7125 would replace that obsolete part.
http://www.farnell.com/datasheets/1674468.pdf
In the datasheet for the MT48LC8M16A2P are listed 3 different ic's.
MT48LC32M4A2 – 8 Meg x 4 x 4 Banks
MT48LC16M8A2 – 4 Meg x 8 x 4 Banks
MT48LC8M16A2 – 2 Meg x 16 x 4 Banks
On page 8 - 10 are 3 different functional diagrams. Which one is for the MT48LC8M16A2 – 2 Meg x 16 x 4 Banks ?
Which one is meaned on page 46 with y = 1024 (x8) ?
So - lots of pins going into the ram chip - and then some bidirectional pins. Some of those pins need to run fast, eg a clock pin, so that would go directly to the propeller? Some can run a bit slower, though octal latches will be faster than 595s. (but use more pins). Speed vs pins. Prop2 may be able to do this with no glue logic.
Dr_Acula then the ic has a full page access with y = 512 (x16). Is this similar to 1024X8 ?
Page 18: 1 .For full-page accesses: y = 2,048 (x4), y = 1,024 (x8), and y = 512 (x16).
Some of those pins need to run fast, eg a clock pin, so that would go directly to the propeller?
Because speed matters, and these parts have very tolerant clock pins, I would suggest a tiny Doubler (edge to Clock) which would halve the burst speed needed from Prop and also remove Sw lines just to restore the clk pin. (You may do this already for HC161's ?)
Edge to Clock Generation
__
---o-------------------\\ \
| || |----- ==\__/==
| __ ,--//__/
| VCC --\\ \ | Every edge in
| ___ || |--' gives CLK pulse
+-|___|--//__/
74LVC2G86
R optional
trim delay
Dr_Acula then the ic has a full page access with y = 512 (x16). Is this similar to 1024X8 ?
Page 18: 1 .For full-page accesses: y = 2,048 (x4), y = 1,024 (x8), and y = 512 (x16).
Actually that is the one bit I can't determine from the datasheet - how large is the full page. That info suggest 512. If so, it may be better to use two 8 bit chips in parallel. But that is getting ahead of things. Can still get things to work at 512 and test the whole concept. I'd be thinking of starting really simple and using 6 bits (2 per color) same as the propeller can output and the standard VGA relay driver circuit, and try writing to the ram and reading from the ram, then store just one line and output it 480 times to check the timing. It is easy to grow things later to better resolution - the early stuff needs to test the concept - eg how easy is it to hack the existing VGA drivers and preserve the back porch and front porch timing and instead of outputting data from the propeller, output a clock signal instead. That can test whether we need double clock speed or not (as per post above).
and at the heart of this is the waitvid command. I am not sure about the timing of the clock and how this would work replacing it with another pasm instruction and whether the timing will be precise enough - eg a simple pasm loop might be too fast, but add one nop and it might be too slow, and how do you get the timing (ie the screen width) precise?
But maybe one could borrow from that avr design, and have an external clock (xtal?). I think there is a pin that disables the ram chip so that you can set it all up ready to go and then release that pin and it sends out a burst of data. Not sure how precise that would be and need to make sure the pixels line up on each row. Or maybe the propeller can produce timing pulses with sufficient accuracy? Or could you replace the rdlong with a command to make a pin high, and the add with a command to make it low, and that becomes the clock? Or is it easier to use a dedicated chip like Rayman did?
But maybe one could borrow from that avr design, and have an external clock (xtal?). I think there is a pin that disables the ram chip so that you can set it all up ready to go and then release that pin and it sends out a burst of data. Not sure how precise that would be and need to make sure the pixels line up on each row. Or maybe the propeller can produce timing pulses with sufficient accuracy? Or could you replace the rdlong with a command to make a pin high, and the add with a command to make it low, and that becomes the clock? Or is it easier to use a dedicated chip like Rayman did?
? This has to be very close to what you do already, in your HC161 design ?
ie There is a setup phase, where things are loaded, and then a change to a burst-read phase where the Prop does nothing but create (or gate) a CLOCK.
That could be SW, or Counter, and the Double circuit above allows a 12.5MHz Pin clock for a 25MHz pixel rate from the RAM.
The 12.5MHz(50%) is a little easier to generate, as is the next step of 20MHz (50%)
Yes it is similar to the 161, only difference is the touchscreens don't care about timing as they have their own internal ram, but for VGA timing is critical. We could start by using the existing timing for 640x480 in Kye's driver (and/or other VGA object code). Even if it started with two pixels per count so it was only 320 that is a start. I think that can work, and at least show the concept that data can be dumped out of a ram directly rather than going through the propeller.
Then there is the challenge of the setup code for these ram chips. Time to read the datasheets. But payoff makes it worthwhile - the same code could be used for the touchscreen and also for XMM in C. I guess we all need to get some of those chips?
Comments
512 is not enough to easily do 640, hence my references to 1024 (or using 2 x 8 x 1024), and why the burst-size is likely to select the memory, more than Size.
SDRAM takes a few clocks to re-address outside the simpler Auto-Inc of Full page, so would then need buffering and faster clocks. Quickly gets complicated.
Easier to select a part that can Auto-inc burst enough clocks, and Page align scans ?
Good points jmg. Yes, the burst size will select the memory. Is 640 the minimum? Or could one accept 512 and have black bars on the sides? Or stretch it a little? Hmm - I suspect if it works for 640x480 pretty soon we are going to want 800x600 and 1024 etc. May as well plan for a decent size? The part that was over $10 - given all the other costs such as making PCBs and support chips, that may not be such an issue.
But how can i save pins with the 74HC245, it has 8 inputs/outputs on both sides ?
Is a 74HC4051 not a better solution ?
Might need an adapter board as well eg http://www.proto-advantage.com/store/product_info.php?products_id=2200241 (click to enlarge just under the 'add to cart'. Pins are close!)
Another idea. By the time you buy one of these chips, plus an adapter, and try to solder it, I wonder if it might be better to recycle a PC100 or PC133 memory module? Available for $1 or even giveaway, and the pins are easy to solder to (or get a socket?). Lots of chips on the module and maybe you only use one of them? Would need modules that have chips that can do burst mode though. Need to look at the specs. eg quick search http://pdf1.alldatasheet.com/datasheet-pdf/view/37694/SAMSUNG/PC100.html and this seems to have burst mode. 64 bits, ok, we only use 16 or less of those so that makes wiring simpler.
Correct.
- that price will also (hopefully) come down.
Looking at clock choices, I see DDR memories tend to be lower voltage, and with more complex clocks, and they dropped the Full page burst modes.
However the SDR memories have very tolerant clock widths, so would lend themselves to clock doubling at the pin, using a XOR gate (Tiny Logic 74LVC2G86DC or similar).
That means a single edge from a Prop is needed for SW loads, and the burst-read-clock can be halved in frequency, which also makes life easier from a Prop1.
The TSOP ii 54 pin packages are 0.8mm, so that is not too hard to manage ? - you need only one.
Looks like others have thought of this too...
The refresh nature of DRAM means going too slow will have issues, but you could make a (roughly) hardware-compatible SRAM interface, that used load-able Column counters (which you have already), from CAS#, and latches for Row (RAS#) and Bank (both RAS# and CAS# ).
It is just a few gates, or a SPLD, to take SDRAM control lines to SRAM+Latches+Ctr.
Pass 1 could hold Bank static and just load Row/Col on one pane, for simplicity.
Looking at AS4C16M16S Fig 36.1, it looks like a moderate bump in complexity might bring banks into play ?
Provided you can pre-read banks, and then flip-on-the-fly, then the pixel stream is unbroken.
It needs a carefully timed, mid-line bank-change.
Fig36.1 seems to show that.
However, starting with a larger Full-page device avoids that detail, early on, and allows everything else to work.
Adding in bank change mid line, would allow smaller SDRAMs to be used, but I suspect the bigger parts will fall in price, and their easier higher clock handling, and less critical timing will win out.
Interesting, they use a RAM DAC, which is rather hard to buy anymore....
- but the idea looks to be sound.
Nice to see a TSOP can be soldered to a homebrew board.
Plus the photo on that page is actually a photo of the display, displaying the board, and it looks pretty good even with 8 bits and 512 pixels. Looks like they came up against the 512 pixel cache-burst problem too, but maybe it is better to walk before you can run, and start with 512 pixels and 8 bits and know that it can be extended to higher resolution using techniques jmg describes.
The code is a different assembly but this shows it is not a crazy idea at all. All we have to do now is to declare it "impossible to do on the propeller"
Rayman uses the ADV7125 I think, on his SSD1963 Board, and that would be a natural for this.
The AVR design was done long before you could buy N x 1024 x 16 SDRAM parts, so they stuck at 512 x 8.
Their output DAC looks to be the older Video RAM+DAC, which has a palette lookup, from way back when memory was expensive and Analog was cheaper. I'd guess an ADV476 equivalent as that came in a 28 pin package.
With 16 lines, the ADV7125 would replace that obsolete part.
The ADV7125 or ADV7123 can be used to generate a vga output signal.
The AD725 to generate PAL or NTSC output.
As i know rayman converts the RGB-signal from the SSD1963 with the ADV7125 into vga-signals.
Something about the ADV7123:
http://www.johnloomis.org/altera/DE2/vga.html
Must the chip have a 8-bit or a 16-bit architecture for the burst length = 1024 ?
Like MT48LC8M16A2P 8 Meg x 16 = 16Bit architecture
or like MT48LC32M8A2P 32 Meg x 8 = 8Bit architecture
The combination of 16b and 1024 counts/Page size are merely the most natural fit, as it allows ONE ram device.
Saves PCB space and routing.
However, if you do not mind multiple packages, then moving to 8b usually doubles the Counter size, and 4 bits doubles again.
In the datasheet for the MT48LC8M16A2P are listed 3 different ic's.
MT48LC32M4A2 – 8 Meg x 4 x 4 Banks
MT48LC16M8A2 – 4 Meg x 8 x 4 Banks
MT48LC8M16A2 – 2 Meg x 16 x 4 Banks
On page 8 - 10 are 3 different functional diagrams. Which one is for the MT48LC8M16A2 – 2 Meg x 16 x 4 Banks ?
Which one is meaned on page 46 with y = 1024 (x8) ?
So - lots of pins going into the ram chip - and then some bidirectional pins. Some of those pins need to run fast, eg a clock pin, so that would go directly to the propeller? Some can run a bit slower, though octal latches will be faster than 595s. (but use more pins). Speed vs pins. Prop2 may be able to do this with no glue logic.
Page 18: 1 .For full-page accesses: y = 2,048 (x4), y = 1,024 (x8), and y = 512 (x16).
Because speed matters, and these parts have very tolerant clock pins, I would suggest a tiny Doubler (edge to Clock) which would halve the burst speed needed from Prop and also remove Sw lines just to restore the clk pin. (You may do this already for HC161's ?)
Edge to Clock Generation __ ---o-------------------\\ \ | || |----- ==\__/== | __ ,--//__/ | VCC --\\ \ | Every edge in | ___ || |--' gives CLK pulse +-|___|--//__/ 74LVC2G86 R optional trim delayActually that is the one bit I can't determine from the datasheet - how large is the full page. That info suggest 512. If so, it may be better to use two 8 bit chips in parallel. But that is getting ahead of things. Can still get things to work at 512 and test the whole concept. I'd be thinking of starting really simple and using 6 bits (2 per color) same as the propeller can output and the standard VGA relay driver circuit, and try writing to the ram and reading from the ram, then store just one line and output it 480 times to check the timing. It is easy to grow things later to better resolution - the early stuff needs to test the concept - eg how easy is it to hack the existing VGA drivers and preserve the back porch and front porch timing and instead of outputting data from the propeller, output a clock signal instead. That can test whether we need double clock speed or not (as per post above).
Later 8-bit color and then 16-bit color and higher resolution !
Things like the front porch and back porch can stay as they are. The core loop displaying video is this
videoLoop rdlong screenPixels, buffer ' Download new pixels. add buffer, #4 ' waitvid screenColors, screenPixels ' Update display scanline. djnz counter, #videoLoop ' Repeat.and at the heart of this is the waitvid command. I am not sure about the timing of the clock and how this would work replacing it with another pasm instruction and whether the timing will be precise enough - eg a simple pasm loop might be too fast, but add one nop and it might be too slow, and how do you get the timing (ie the screen width) precise?
But maybe one could borrow from that avr design, and have an external clock (xtal?). I think there is a pin that disables the ram chip so that you can set it all up ready to go and then release that pin and it sends out a burst of data. Not sure how precise that would be and need to make sure the pixels line up on each row. Or maybe the propeller can produce timing pulses with sufficient accuracy? Or could you replace the rdlong with a command to make a pin high, and the add with a command to make it low, and that becomes the clock? Or is it easier to use a dedicated chip like Rayman did?
? This has to be very close to what you do already, in your HC161 design ?
ie There is a setup phase, where things are loaded, and then a change to a burst-read phase where the Prop does nothing but create (or gate) a CLOCK.
That could be SW, or Counter, and the Double circuit above allows a 12.5MHz Pin clock for a 25MHz pixel rate from the RAM.
The 12.5MHz(50%) is a little easier to generate, as is the next step of 20MHz (50%)
Then there is the challenge of the setup code for these ram chips. Time to read the datasheets. But payoff makes it worthwhile - the same code could be used for the touchscreen and also for XMM in C. I guess we all need to get some of those chips?
Is the 8-bit version good enough for a 640x480 8-bit color version with 256 colors ?