How do Drac / Tri / Ram blades and the like interface?
steddyman
Posts: 91
I am trying to understand how to interface something like a RamBlade to a Micromite Companion board.
My understanding is the reason for these sorts of boards is so you can get fast access to memory by using a partner Prop on a dedicated board using the full io of the second prop without tying up all the pins on your main processor.
I also understand from another thread that using something like a serial SRAM directly won't be fast enough for things like Spectrum emulation.
What I don't get though, is if the later is true how can you get fast access to the memory on the add-on blade without accessing it serially (slow) or again using all your IO?
My understanding is the reason for these sorts of boards is so you can get fast access to memory by using a partner Prop on a dedicated board using the full io of the second prop without tying up all the pins on your main processor.
I also understand from another thread that using something like a serial SRAM directly won't be fast enough for things like Spectrum emulation.
What I don't get though, is if the later is true how can you get fast access to the memory on the add-on blade without accessing it serially (slow) or again using all your IO?
Comments
My RamBlade uses 30 pins to interface the 512KB SRAM as parallel with separate address and data lines (19 addr + 8 data = 27).
Another 3 pins (with decoding) are used for sharing the SRAM /CE, /WD, /RD with the EEPROM SDA & SCL and the microSD /CS (/CS, CLK, DI, DO actually share the data bus with SRAM).
This leaves 2 pins for high speed (serial) I/O. But these 2 pins can also be used to interface a 1pin PS2 Keyboard and 1pin monochrome TV composite video (80x25 etc) using a couple of resistors.
If you only require 64KB SRAM then you could recover another 3 IO pins.
The DracBlade has latches to share the address and data lines - you need to see his different circuits as they vary IIRC.
So, everything is a compromise.
So that means the RamBlade is designed as a standalone prop then? It is not designed to provide fast memory access operating as a slave prop?
My issue is I like the MicroMite design but need much more memory on the Propeller side of it in order to run the C code I need. The MicroMite design uses most of the Propeller IO because it needs it for VGA output, SD control, Keyboard control, Serial commas and I2C comms. Only 5 pins remain.
Btw it is the 23lc1024 I have wired up. Currently using only single channel but I believe it does support Quad SPI.
I also run a RamBlade circuit with Catalina C which then talks to 2 propellers serially in a commercial product.
We have a large database on the RamBlade section. The next prop talks to the RamBlade and another a few devices, one of which is a third prop in a separate box housing an LCD and keypad.
IMHO the serial RAMs will not achieve the throughput required in most circumstances. This includes Quad SPI RAMs.
The better compromise is the latched versions such as my TriBlade (Prop#1 section) and the DracBlade designs.
Or, use a faster ARM micro
I want to make something similar to the MMC which uses the MMBASIC, but is backed by a Prop with significant amounts of memory to support all the features I want. It looks like the only way to get this may be to back it with multiple props. The Microchip has plenty of IO lines spare, so the limit is always on the Prop side.
Alternatively wait for the Prop2 but I'm not sure I have that amount of patience
The issue with trying to reimplement MMBASIC in Prop is that the code is pretty big (compiles to around 100k) and I am pretty sure the license would not allow you to migrate it. Their code is only usable for personal use unless you sign a license agreement, and I am not sure they would support you in converting it to a different architecture.
The biggest challenge I have found with making the MMC work for me is trying to get all the code and functionality into the memory constraints of a single Prop. If Hub RAM was bigger I am sure it wouldn't be so much of a big deal. I suppose splitting the tasks between multiple Prop's would alleviate this problem somewhat.
Do you still sell your prop boards? If you do, do you supply them assembled or at least as complete part kits? If I wanted to get something that I could then interface a PIC to but otherwise was complete (e.g. video, SD, keyboard, sound, serial, i2c), is that something you make and sell (it would need a IO breakout area)? I could then use that configuration to test my ideas before producing something more complete from it.
Why go through this pain to make a Propeller run a big program when you can just get a really small, cheap MCU to do the same with no hassle.
Heck use an SMTM32 MCU and program the thing in JavaScript:
http://www.espruino.com/
Or Python:
http://micropython.org/
I love the Propeller but really if you need to push it to the point that you need external memory it starts to make no sense.
The reason to do this for me is produce a powerful computer which arks back to the likes of the Amiga and ST that people can use BASIC to program and still make great games. This is what Jeff has in mind for his MMC, but for me the implementation is too restrictive and complex to use.
I dislike Python with a vengeance and I want the Props to implement varied and interesting graphics modes. I don't want a device for controlling IO from a web page, there are plenty of platforms that do that already.
I appreciate and admire your goal there. I cannot see how the Propeller is ever going to do that.
What has been discussed here is how to add memory to the Propeller. Problem is that the 20 MIPs Propeller is already slowed to 5 MIPs at best if it has to run code from it's own shared memory space. Which slows to 0.5 MIPs or so if you need to use external memory devices.
At this point you have to ask "Why not just use some other 50 cent MCU that has a lot more memory space and a thousand times more performance?"
Not only that, by using external memory you have used a lot of the Props pins which means there is not much left for any other I/O. Which means those other 32 bit cogs have nothing to do. What a waste.
Let's skip over the language wars. I also avoid all languages whose names begin with "P": Pascal, PHP, Perl, Python...
The Propeller is a rare thing in the MCU world in that it can generate video whilst at the same time juggling 7 other tasks behind it's back. Amazing!
Problem is that when we step outside of it's memory capacity we sacrifice exactly those magical features.
It's very frustrating.
And that is why we are all waiting for the P2.
Yes I have boards and can assemble or not. see my website www.clusos.com
The MMBASIC code I have is direct from Geoff and I have been in touch with him via email. Nothing decided but he knows what I want to do and would like to see it on the prop.
For me I only want to use the Prop(s) to act as a slave to the PIC32. So if they can generate the video signals, handle serial and keyboard and a few other tasks (which the multiple cogs are perfect for) then will do the job for me.
I do understand that the extra memory can't be used for video. I suspect if I split the tasks across two props I won't even need extra memory.
I sent Geoff a request for access to the source code three days ago via the MMBASIC website but have so far not received any response. I think with the Prop2 and it's extra memory and speed it could be a real possibility that you could get it running along with all video functions. That would probably be a perfect storm
PS I found this interesting little circuit while looking for embedded VGA. This uses SD RAM and a RAMDAC to drive VGA video directly from the SDRAM facilitated by an MCU for graphics output at 512x480. I can't find out what the RAMDAC is and there don't seem to be many available now:
http://tinyvga.com/images/avr_sdram_vgasch.jpg
This site also has an amazingly useful table of VGA timings:
http://tinyvga.com/vga-timing
EDIT: I just noticed somebody has done this on a Prop already. Impressive stuff:
http://forums.parallax.com/showthread.php/150407-Video-graphics-controller-using-Propeller-to-control-SDRAM