Using propeller to translate SPI/i2c SRAM and EEPROM for older CPUs?
rwgast_logicdesign
Posts: 1,464
Ive been looking around at a few classic trainer computers, Like the COSMAC ELF, and the z80 Micro Professor. I would like to build an SBC using mostly modern parts except the CPU. Old DIP SRAM is hard to source and EPROMS require special programmers, which make them both unappealing. It seems to me that using a micro controller like Propeller to translate between the CPU's parrallel bus and the i2C/SPI bus of the memory would not be to hard of a task to accomplish. Nut im wondering if using the propeller as a middle man would be a cause a huge slow down in the memmory access time between the CPU and Memory? Although we are talking about using an 80 mhz micro to translate to a 2-20mhz CPU depending on make and model of CPU chosen. Is this a dead end path? maybe better off learning and using a CPLD? Any suggestions for SPI to parallel translation are welcome.
Comments
Typical 8 bit era trainer and dev boards would have:
1) 8 bit CPU. Z80, 6502, 6800 etc.
2) A few kilobytes of RAM. My 6809 board only had 1K in two 4our bit wide chips.
3) A few kilobytes of EPROM. Maybe a 2708 1K byte, or perhaps 2716 2K byte.
4) UART
5) Parallel port
6) Interrupt controller.
7) Hex key pad
8) Six digit 7 segment display.
Typical 8 bit computers, say an Intertec Superbrain, maxed out at 64K RAM and added video output and floppy drives.
So how how about this idea...
Take the 8 bit CPU of your choice and use Propellers as your RAM, ROM and peripherals.
Each Prop provides up to 32K of memory space so two Props would max out you 8 bit address space already.
Code loaded into a COG on each Prop would serve up the HUB memory over the Prop pins to the 8 bit CPU should be quite fast enough. Over clock the Props to 100+ MHz anyway.
That leaves you with 14 COGs that can emulate those old, PIO, timers, interrupt controllers, floppy drives (on SD card) etc.
Using all the RAM from a Prop for the 8 bitter seems a bit tight so how about just using 16K of it and have four Props for the full 64K.
Now, I'd want a green screen text terminal so that will probably require a Prop of it's own as that uses lots of Pins and RAM.
So there we have it. Old 8 bit CPU, 5 Prop chips and perhaps a little external logic for address decoding or whatever.
This idea crosses my mind occasionally as I have a few 8080, z80 and 68000 chips waiting to see action here.
I'm not quite following - there are plenty of DIP SRAMs still available ? - you just need to adjust your size to what suppliers offer. eg Digikey show 19 DIP SRAMs in stock, even up to 4MBit at a reasonable sub $5. (55ns 2.7-5.5V)
32kx8 are now cheaper than smaller RAMs
You could parallel EEPROM for CODE, or use some logic/SPLD to overlay CODE/RAM, and run a small loader.
(eg run a Prop on the same BUS, and hold the old CPU in reset while the Prop loads the Code )
If you choose an old CPU that is not too old, (ie Static CMOS, not dynamic NMOS) you may be able to single step it from the Prop control.
With a little care, such dual memory sharing could be made quite nimble, for run-time use as well.
What micro are you planning to use with it?
Sure, that is the exact flow I described above.
It would be nice to have a part that pricey doing some real work
To save pins, you could Prop-load a very small Z80 stub, that then loads the rest of the code
Not directly, but you can use Logic to Page swap, and that can allow simple extensions, and also help the Z80 loader approach.
- for example, you can have a Boot-page, a 64K Code+Data (RUN) Page 1 and then you can swap-in 32k or 16k slices from higher memory, if you need more... depends really on what you want to emulate, or run, and what memory mapping scheme that uses.
Ok I have no idea what im doing lol, this is the first time ive worked with a parallel bus other than an LCD, and im not guite sure how exactly to share the memory between the prop, or get the z80 to page the FULL chip! Im sure figuring out how to get the z80 to page the chip will come in time as I learn more about the CPU, fortunately I have plenty of graphing calculators I can use as an ASM test bed, and I found this excellent basic tutorial http://lateblt.tripod.com/z80proj1.htm. I have also found about 8 old UV EPROMs and own and eraser, the only problem is they take 24v to program, so im thinking I may stik with the NVRAM as the EPROM.
If I were to use the use the prop to program the the NVRAM chip instead of an EPROM, would I do something like connect the appropriate data and address lines to the prop and z80, and use some kind of a switch for programming mode? Im sure the propeller and the z80 can not share access to this chip at the same time? Since all im doing with the prop is programming some of the ram as "ROM" for the z80 im sure using something like i2c expanders (or shift registers) should be just fine no need for full speed access to the NVRAM chip from the prop? This way I could use the rest of the prop to emulate the PIO and clock?
That said, they were fantastic when I started the rollout because I could remotely update the firmware as mods were required. Fortunately they were not that expensive (relatively).
Ive been tearing up all kinds of old MOBOs looking for SRAM chip and can only find DRAM, I wish there was a way to use a battery backup, instead of the battery being built in to the chip.
The Z80 expects to just strobe RDN/WRN, and get some-ns level turnaround.
A Prop alone cannot do that, but you could look at some tight time-domain co-operation.
The Z80 has /BUSAK /WAIT /BUSRQ, and IIRC some designs used those for handshake bus designs.
A SPLD/CPLD may be needed to run a state engine the Z80 and Prop can both work with.
Parallel loaders can be quite small, (< 10 lines ASM) and one pin-saving method would be to have the Prop feed opcodes and data to the Z80, in a tight loop, controlling the Z80 clock to match the Prop feed rate.
Once the RAM is loaded, the Prop can bump the clock up.
For that approach, you would need a CMOS Z80 (static clock compatible)
$3.33, it has data lines and address lines and works on both 3.3V and 5V works well with both the propeller as external ram, and with the Z80.
Only thing is, it does get a bit tricky if you wanted to use a propeller and a Z80 and this ram chip all on a common bus, because the Z80 is 5V. So lots of 2k7 resistors to do the level translation. Ditto using a Z80 and using the propeller as the ram.
Keep hacking - this sounds a fun project
Best to avoid 5V, and use 3.3V everywhere.
I see Mouser claims stocks of CMOS Z8S18020PSG, in DIP60, ( & also PLCC68)
Secondly as I stated above there would be no pins to spare on the propeller, so if I were to communicate to the ram through some 74xx595 shift registers I could save a whole lot of propeller pins, is this a "good" way to access parallel ram with a prop? I mean these SRAM chips you guys are linking to are 55ns, and the data sheet says a 74HC595 is 5.4ns so will there be any significant speed impact especially on an old 4mhz cpu? I mean a prop pin can toggle at 12ns and the shift register is 5.4ns and the ram is 70ns, so were looking at an 87.4ns access time? wouldnt a 4mhz cpu take 250ns to access ram anyways?
Im probably totally wrong about all this, just trying to figure it out so I have some sort of idea if im going down the wrong path here.
Looking at the micro80 schematic I am a little confused about something
http://www.shaels.net/uploads/Media/SiteDownloads/Mini80/Mini80Proto1.pdf
Is he using the shift register to address only the first 8 address lines of the ram chip?
The more I think about this 1M Ram chip the cooler it seems maybe I could somehow load CP/M on to the whole thing and run it directly from RAM that would be pretty quick! Also if anyone could tell me if I'm calculating all the ram timing right in my last post, and if not how would I go about figuring that out?
Re using shift registers to save propeller pins, yes it will work, but it will slow things down 20-30x so that wouldn't be so good. Anything less than about 4Mhz gets a bit tedious waiting for WordStar and compiling C and Basic programs.
Yes, once you get something working with the first 64k of ram, you can think about banked memory. Lots of options there, ranging from switching in 32k blocks, to having 4k blocks of ram all individually movable to anywhere in the 64k space (I did that on a fpga, but it would be quite a few chips to do in real life).
Build something simple first - shael's project looks a great place to start.
I just have one question left, why does addressing the ram with shift registers slow things down so much, as I said the data sheet says they work at 5.4ns that's pretty quick? What is the best way to save prop pins and still talk to parallel ram, without a huge speed hit?