SPI SRAM from microchip for cheap, may be answer to VGA problems.

Kye

Check this out,

http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en539039

They can run at 20Mhz at max speed. Thay may·be just enough time to get information from a display buffer onto the screen. They are 8 pin devices with 256kb which is enough for vga.

...Just sharing something that caught my eye.

And while we are on the subject of vga I'm trying to remake my graphics driver to support an internal 128 character ASCII set which would be completely inside the cog. The display buffer would then be a bunch of 8 bit addresses allowing for alot of characters on screen with one cog.

Is this a good idea though? Since it will not be possible then to have custom graphics, only ASCII characters and whatever else you want hard coded in the first 32 spots. Also, I mostlikely won't be able to get a cusor overlay working with one cog either due to the nature of prebuffering required to display 8 x 8 charactrers.·(Basically everything needs to be handled in 32 bit chucks)

Thanks,



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Post Edited (Kye) : 1/21/2009 9:08:27 PM GMT

Oldbitcollector (Jeff)

Available in PDIP too.. Interesting..

OBC

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?

Check out: Protoboard Introduction , Propeller Cookbook 1.4 & Software Index
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS

Mike Green

I've just ordered a small bunch of these. ON Semiconductor also has them in their product list, but there's a lead time of about 2 months'. I've been hoping to take heater's 8080 emulator and modify it to use two of these to get 64K of emulated memory and freeing up hub ram to include a terminal emulator. It should be possible to read or write 3 to 4 bytes at a time in under 4us per byte and single bytes in under 10us. This isn't as fast as using hub ram but is not unreasonable for an 8080.

Mark Swann

I just ordered a hand full from MicroChip, shipping from Thailand. Timothy Sweiter and I are considering experimenting with these as a way to provide more display ram for our various OLED projects.

Mark Swann

Question,

I posted an idea in another thread to used multiple serial SRAMs in parallel, sharing the same command and clock pins, but wiring the data-out of each SRAM to a different pin on the Prop.
My proposal is to use a gang of these chips as 8-wide (or n-wide) serial SRAMs, writing and reading to all "n" chips at the same time.

What do you think of this? Crazy? Brilliant? Just so-so?

Mark

Mike Green

Mark,

That's a very reasonable way to get higher throughput.· You'd use a MUX instruction to duplicate the command and address byte bits on the multiple I/O pins, then there's some shifting and bit logical operations needed to transfer the data 8 bits at a time to the output register, but it all should work smoothly and very fast.· The overhead of the command and address bytes·starts dropping off quickly once you transfer 3 to 4 bytes per chip (for a total of 24 to 32 bytes).· You'd transfer about 8 bytes in about 10us and another 2us (roughly) for each additional 8 bytes

Mike




Post Edited (Mike Green) : 1/21/2009 9:43:30 PM GMT

Baggers

even if that's 20Mhz to get a byte out serially through SPI, I'm guessing you'll won't get the prop to SPI at 20Mhz though.
also isn't vga ~25Mhz pixel rate. sorry to rain on your parade though [noparse]:)[/noparse]
nice find btw!

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

·

Mark Swann

@ Mike,

Thanks for confirming my idea.
Throughput would be improved during paged mode or burst (sequencial) mode of read/write where you would shift out the command and the start address only one time then repeatedly clock in or out "N" bits at a time until you have read or written all you want. Then you raise chip select to terminate the burst.

Mark

Mike Huselton

I ordered 3 pdip and 3 soic samples from Microchip Direct. Total cost: $7.30, shipping 5 days.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH - Electronics: Engineer - Programming: Professional

heater

Mike Green said...
...take heater's 8080 emulator and modify it to use two of these to get 64K of emulated memory and freeing up hub ram to include a terminal emulator

Mike I'd so much love it if you could do that.

Just today I started working on combining PropAltair and PropComm with VT100 emulaion. PropComm is only about 2500 longs so if I shrink CP/M down to a bare minimum I can probably fit the whole thing into HUB. Won't actually have enough space for CP/M to do anything much but at least we can test if it works at all, then get on to the external RAM version.

I always wanted to keep some version of PropAltair that runs on a Prop Demo board just so anyone can quickly run it up just for a look see.

As it stands PropAltair only has two free longs in the COG ! The various RAM read/write, ROM read functions I have total about 40 longs. So I don't thing we will be able to put the SPI driver in the COG.

I think what we need is a "memory controller" COG. This could be quite speedy if it was a bit smart. For example fetching instructions ahead of the program counter whilst the emulator is working on an op. Possibly even caching blocks.

With a memory controller COG we may gain space in the emulator to move some opcode handling from LMM to native PASM.

Of course if you take a look at the emulator you'll probably see many better ways to do things than I have[noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Mike Huselton

A memory controller is an idea that is long overdue. SPI, Parallel and I2C capabilities for addressing would be excellent. Who gets to write it once it has been spec'd in detail?

What do you think of the HYDRA Xtreme 512K SRAM Card for design? Should I buy it? Or wait for a memory controller object?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH - Electronics: Engineer - Programming: Professional

Post Edited (Quantum) : 1/21/2009 10:46:48 PM GMT

Bean

I wanted to use these on the SX as NTSC video memory. But there is not much idle time to update the memory.

Here was my thought:

Use two sram chips. The outputs go to a seperate input pin on the micro, and also to a 2xMUX input with the output going to generate the video signal.
When one sram is generating the video the other is free to be updated as much as needed. Then the MUX is switched and the srams exchange functions (this is done during the blanking period).

The only downside is that everything must be written twice so both srams have the same data. But I think that still be MUCH faster than only updating the sram during the blanking periods.

Bean

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
·The next time you need a hero don't look up in the sky...Look in the mirror.


·

Kye

I'll write the memory controller for you guys. I'm remaking mikes I2C driver right now in asm with additonal hooks for any I2C device that needs to be used. As long as you can put the interface code in the cog memory you'll be able to control multiple devices on the I2C line. I'm also working on an SPI engine similar to the the way I plan to have the I2C engine work.

I won't have these done for a while however, I have other drivers to fix up first. I'll be re releasing my keyboard and mouse drivers again in fully commented and explained form for the demo board and hydra. I'll also have combo versions for the demo board and hydra. All of them are plug n play. I'm also adding more felexibily to my serial driver and making a half duplex version for anyone who needs one, I think I'll be including Xon / Xoff flow control also. And I need to fix up my video driver... The characters could use some work. So, as I said I won't be able to get to those for a while. I'll be taking suggestions however.

As for a complex system to exploit multiplt chips at once on different pins I won't be able to do that, mainly because I can't test it and its not on my driver list plan. (Trying to make a system in which the propeller does everything, all nonessiental chips should be replaced with the propeller).

And back to my original question... no one answerd it... on the first post.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Mark Swann

@ Kye,

Putting what is essentially a 128 character array into cog ram is a good idea. That's 4 characters per word, using only 32 cog words.

Mark

Kye

Well, its more like half of the cogs ram. I already wrote the character set but it requires alot of prefecting get all the necessary data in time. It also requires a 20 long buffer to store the prefetched scan line.

The hard part is looping through the character array since masking operations must be done. etc, etc.

Pretty much similar to the way my keyboard driver looks up the pressed key.

BUT it would save about a fourth / fifth·of the internal memory space within the hub ram.

I would actually rather use the propellers character font (BUT ITS INTERLEAVED - BAD ! IDEA FOR HIGH RESOLUTIONS !) (some anger there...) but I can't change the color fast enough to display both even and odd characters.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Mark Swann

Kye said...
Well, its more like half of the cogs ram. I already wrote the character set but it requires alot of prefecting get all the necessary data in time. It also requires a 20 long buffer to store the prefetched scan line.

The hard part is looping through the character array since masking operations must be done. etc, etc.

Pretty much similar to the way my keyboard driver looks up the pressed key.

BUT it would save about a fourth / fifth·of the internal memory space within the hub ram.

I would actually rather use the propellers character font (BUT ITS INTERLEAVED - BAD ! IDEA FOR HIGH RESOLUTIONS !) (some anger there...) but I can't change the color fast enough to display both even and odd characters.

That is true for 1 character per word, but each word can store 4 characters.
I guess I don't understand your data structure for the 127 characters.
·

kwinn

It's a nice chip for storing data for some applications but not too useful for displays or emulators. Every change from reading/writing/address requires a time consuming update of the status and/or address.

Display memory requires continuous sequential reads to refresh the display, interleaved with frequent writes to update the stored image. While it might be possible to use multiple blocks of chips and write one block while the other one refreshes the display it would require extra hardware and some tricky programming.

For an emulator it would be several sequential reads (instruction fetches) interspersed with reads and writes to non sequential locations. Multiple blocks of chips might help for emulating a Harvard architecture CPU, but would not do much for a Von Neumann architecture.

Cluso99

@Kye: I am doing a pasm I2C driver now ( http://forums.parallax.com/forums/default.aspx?f=25&m=321836 ). Initially just read function for loading cogs or overlays, but will expand to write as well (quite simple). I require very tight pasm for minimum footprint in hub for this thread
http://forums.parallax.com/forums/default.aspx?f=25&m=320151&p=3

Any suggestions are welcome and you are welcome to use it also.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index

My cruising website is ·www.bluemagic.biz

Mike Green

I assume you guys have looked at the pasm I2C routines in FemtoBasic. I've thought a bit about how I'd redo them. They were written to be generalized, so they could be used for a variety of I2C devices, not just EEPROMs 32K to 128K in size. As a result, there's a lot of conditional code to handle the various cases. If I were to redo them, I'd go back to just an I2C driver (with the low level SD card driver in its own cog). I'd use the recovered space to implement a sort of JIT (just in time) I2C driver compiler that would generate the particular code sequence needed for the device and the read or write transfer along with the speed stuff (100KHz, 400KHz, 1MHz).

Cluso99

Thanks Mike, I looked last night after I had done my code (while looking at PropComm). The biggest problem is continually reinventing the wheel because we don't know what exists and often its burried in something else. Anyway, I have spent some time trying to shrink the pasm footprint and think i have achieved this quite well, though still more room to shrink. I will add writing later - currently only want reading for compactness.
see I2C EEPROM PASM Driver (AT24C512, etc) http://forums.parallax.com/forums/default.aspx?f=25&m=321836

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index

My cruising website is ·www.bluemagic.biz

Kye

Well, I'm more foceused on making a generalized driver. Like it would have the communication done at low levels and then calls could be made from higher level drivers which could be added into the asm footprint.

@cluso99 - I actually need to make all the drivers I use for the final project I'm working on myself (with help from others too ) because I need to know every last bit of code. Addtionally, its a really good learning process. I'm just a freshman in college, this stuff is new to me.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

jazzed

Hi Kye.

You should accept the challenge to use 4 or more SPI devices in parallel for scalable bandwidth.
One is easy, N with the bandwidth of one is also easy. N with the bandwidth of N is challenging.

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