Homebrew memory expansion *vs* Hydra Extreme SRAM card
Oldbitcollector (Jeff)
Posts: 8,091
There's been soooo much talk about the creation of various memory
expansion units in the forums of late that perhaps we are forgetting
that Parallax has also provided a "ready made" solution?
www.parallax.com/Store/Microcontrollers/PropellerProgrammingKits/tabid/144/CategoryID/20/List/0/SortField/0/Level/a/ProductID/444/Default.aspx
Certainly it can't be difficult to locate and connect an edge connector for the Protoboard/breadboard users.
Perhaps we need to support out favorite company here..
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
expansion units in the forums of late that perhaps we are forgetting
that Parallax has also provided a "ready made" solution?
www.parallax.com/Store/Microcontrollers/PropellerProgrammingKits/tabid/144/CategoryID/20/List/0/SortField/0/Level/a/ProductID/444/Default.aspx
Certainly it can't be difficult to locate and connect an edge connector for the Protoboard/breadboard users.
Perhaps we need to support out favorite company here..
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
The board I'm considering has all the goodies you want OBC (with 4 pins left over if you don't need VGA), and will be cheaper than a PropProto+HX512K.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Post Edited (jazzed) : 5/8/2009 12:49:38 AM GMT
The part number info & picture is in this post . Just go to Coley's comment:
http://forums.parallax.com/showthread.php?p=790475
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Aka: CosmicBob
will work with the protoboard...
www.sullinscorp.com/drawings/54____C___DRX__,_C10881-A.pdf
search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=S3303-ND
Digikey part #S3303-ND
Or am I mis-reading it? [noparse]:)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
I have both the Hydra and the Xtreme board, and have used it to run XMM programs successfuly using my Catalina C compiler - btw the next release of Catalina that supports XMM is due out "Real Soon Now" [noparse]:)[/noparse]
However, before anyone races off to buy an Xtreme, they should note out that (as delivered) only the first 64K of the Xtreme's 512K can be randomly accessed. The remainder can only be accessed serially, and setting the base address for such serial transfers is accomplished by manually incrementing the card's internal address pointer the required number of times - so go and make a cup of coffee while you wait if you want to access byte number 524,287!
Andre does give you the capability of reprogramming the CPLD that acts as the Xtreme's memory controller, so other memory access methods are theoretically possible - but I don't know of anyone who has actually done so, and it requires additional hardware not supplied with the Xtreme.
If anyone has done so (or knows of anyone who has done so) please post here!
Ross.
I'm thinking cluso is on the right track with the triblade. There are still a few things to iron out - a couple of errata that need wire links (but a lot less than my usual v 1.0 boards *grin*). But it seems a very solid design. I'm pondering what the next version might have - would you standardise with 2 ram chips? Would it be available as a kit? Would you have a 2 pin jumper if only 1 chip was installed rather than a wire link? And perhaps heretical to suggest, but maybe make the board a bit bigger and not have chips on the underside and maybe a 10 row SIL header to connect to this http://www.futurlec.com/Mini_SC.shtml (for a klutz like me who can't solder the tiny micro sd). All minor changes through, because the general concept of pairing a prop with fast random access sram is working very well for zicog and ought to be useful for other projects. Emulating drives can cope with block read/write, but emulating the working space (eg 64k) of any microncontroller really does have to have true random access as the code jumps all over the place.
FYI: I am not planning an update to the TriBlade pcb. The mods are there to stay. The pcb overhead cost of any minor change is about $500. The size would not change either as that is the size required to·exactly fit·10 pcbs on a panel. Otherwise we severely shrink the number of pcbs which dramatically increases the pcb costs. (I am just letting you know the basis of my decisions. I am not taking your suggestions the wrong way.)
My next pcb is close. It will be all smt and will be small. It's memory will be just 1 x 512KB chip and will be a little faster to access ram than the TriBlade randomly and sequentially. But my aim is purely random access. You will be surprised
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Sounds great. Are you using FRAM or just the single 512k RAM piece you have used in the past?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Will you be using 512k disk images (which could be done relatively easily just be changing a few variables)? 512k would be plenty - the n8vem has 448k and that is more than enough for packages of files, eg a wordstar package, or a mbasic package.
Post Edited (Dr_Acula (James Moxham)) : 5/8/2009 4:54:20 AM GMT
Surprise me!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
As you know... I am not a professional programmer. So even using the right word is sometimes a problem. Block transfers are not an absolute wall for me... just a hurdle and a timing waste, which I would prefer not to make.
I have some long term interests(25 years+) in the area of 3D image processing. My algorithms are naturally memory intensive. For every byte of image data... there can be a minimum of 5 to 6 bytes of dynamic data, which result from analyses... and this number can go up depending upon how far the particular analysis needs to be taken. I like to store the results of the intervening analyses... right along with the final product. This allows me to experiment with a final stage, without repeating the previous work.
Many of the intervening analyses are 1 bit deep and can be significantly compressed on the fly. The images data can be up to 48 bits per pixel but as little as 7.
Running on a single end stage-Mac Os X 10.4... a 6Meg set of images can take up to a day of computer time to analyze. I am stuck with my pre-Intel Mac and haven't tried anything on the modern platform... preferring to spend my time with my Prop[noparse]:)[/noparse]
I am mostly interested in huge images... which can be easily segmented, but occasionally when you segment the images, you also get an error.
Something in the lower right corner can change the way the computer "thinks" about something in the upper left corner. This is very rare... I can live with it... but huge memory would be very nice.
Tiny memory... tiny storage?... I can use it and there are applications for it.
I would be willing to trade a lot of speed for ease of programming. Random access, particularly if the RAM is 32 bit addressable, makes for ease of programming in my head. I would like the RAM to be capable of "simultaneous" reads by multiple Props without a significant bottleneck... except when you get to the memory module itself. Whether there is one Prop sitting there as the final memory arbitrator (and using every pin for memory and communications) or not wouldn't matter to me. I'm able to follow Hanno's thread and when this community work finally gets to the stage of implementation, I think it will be "graspable" and therefore useful to someone with my interests and limitations. The value of the work to someone like me is it's final usability.
I don't care if something is possible, if I can't do it.
Time will tell.
Rich
The only concrete thing we'll all established is that we need it. [noparse]:)[/noparse]
In the meantime, I don't think I've given the Parallax solution a fair shake,
so with that in mind there is a package on it's way from Parallax and
Digikey.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
One solution might be a wide, shared bus, like the SCSI bus. The bus itself would have only a few rules, such as no device has control of the bus unless it is selected, and when selected, does not drive the data bus unless a control pin allowed it. Beyond that, you could design devices as you choose.
If you want true random access, your device could input the full memory address before accessing a location. If you want fast access, you could have the device itself generate addresses, freeing the memory to read or write bytes as fast as the propeller could process the transfers. Or your device could operate somewhere in-between, maybe using block transfers like a hard drive, or using random access to a small block of memory at a time, like in a segmented memory design.
But the beauty of a bus like this is that you're not tied to any one of these access methods. It's true that you could get faster access by dedicating more pins to the interface, but maybe a bus like this would satisfy most people's needs.
The bus could also allow other parallel-data devices like ADCs or DACs or parallel LCDs to connect, at the same time as a memory module. Your program would just select the device you wanted to address, then use it.
I made a hand-wired version of a bus like this that plugs into two of the sockets of a spinStudio board, taking up 16 pins (but only using 15 of them). It used an 8 bit data bus, 4 pins for control of the device and 3 pins to select which device.
I used a 25-pin 'D' connector to connect devices. The connector provided the data bus, gnd, +3.3 and +5 volts, the device-specific control lines and the device select control lines. At one point I had a hard drive module working which could read data from a hard drive fast enough to play CD-quality WAV files, taking around 3 milliseconds to transfer a 512-byte sector.
It would be great to see a common hardware design for a bus like this with a common bus access library, because then anyone could design modules to plug into the bus, and people could concentrate on designing devices themselves.
I just don't see the point in developing an elaborate bus network, crazy work arounds, etc. when the Prop II in theory will make all that pointless. Plus it would also require me to have the skills to create elaborate bus network workarounds. In the meantime I'll just poke around with the Prop, but I think the serious work can start with the Prop II. IMHO
Engauging in a complicated project may cause serendipitous results, but will mostly just expand your abilities.
Everyone has some kind of an itch to scratch [noparse]:)[/noparse]
Waiting for Propeller II may be less fruitful than you think.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
as 'mov OUTB, address / mov data,INA", and you cannot get much faster than that. That's all fine
and dandy if one can work with the half dozen or so I/O left for peripheral use but I suspect most
will still be looking for a better compromise, particularly large memory with minimum I/O use.
There will still be demand for elaborate buses to make that work and what's done for the Prop I
should be usable with the Prop II.
Perhaps we should wait for the Prop III
I just know for myself I have very limited time with a young family, so I need to pick my endeavors carefully. (from both a limited time and cost POV) Some of the projects going on here are really cool, I just know for me I'll sit this one out a bit. I'm also a coder more then a hardware hacker, so I often pick simplicity over optimization in my hardware design. Hoping in code to make up for my sloppy hardware.
What do you want to do with the memory expansion?
With a 9 or 10 portpin interface you can create a memory expansion with approximately:
- Burst read/write with >= 6.6 MByte/sec, i.e. for overlays
- Random access of bytes or longs (estimated: ~ 500ns for a byte, 1us for a long)
- XMM execution with ~ 1 MIPS, maybe a little bit more
So what are the possible applications(?):
- running bigger programs with XMM or overlays -> needs a compiler/assembler which support this.
- VGA/Video graphic with higher resolution -> the access rate is to slow, I fear.
- RAM as database -> yes, but also possible with an SDcard (a bit slower, but much bigger memory).
- Emulators (i.e. CP/M with ZiCog) -> yes, but slow.
- others?
Andy
Audio delays.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Aka: CosmicBob
I used a counter to generate the addresses so the propeller just wrote bytes as if to a stack, and I used the falling write strobe to clock the counter so the propeller didn't even have to do that.
That particular project had a strict requirement to write a about a byte per microsecond, and it worked fine.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
I currently run my C programs on the Hydra using the Hydra Xtreme card. Unfortunately, only 64K of the RAM on the Xtreme can be randomly accessed, for a total of 96K of usable memory. So the Xtreme is not an ideal XMM solution - but it will do until I can get my hands on something better, such as one of Cluso99's boards.
I'll be releasing a new version of Catalina with XMM support later this week. Nothing too fancy at this stage - but it is very easy to port it to other XMM platforms.
Ross.
Photo1 shows a front view with the Hydra sram board inserted in the socket. The two pins (Hydra pins 10 & 9) are connected to propeller pins 1 & 2 in socket A. The adapter board is inserted into socket C. Photo2 shows the back view of the card. The left most pin (Hydra pin 11) is connected to the reset line and the right most pin (Hydra pin 19) is connected to the Rx propplug connectors. The center pin, 3.3V-loopback,·is connected to Pin 2 of the eeprom. Photo3 show a top view of the protocard wiring.· Photo4 shows a bottom view of the wiring (the 8 data lines).
The eeprom on the SpinStudio board must be raised, so that pin 2 can be disconnected from the socket and connected through a 10 K resistor to ground (eeprom pin 4 in this case).· Provision is made to directly connect eeprom pin 2 to the 3.3V-loopback on the Hydra card. This is shown in photo5.