Adding 512Kx8 or 128Kx8 external SRAM to the Prop (for emulations, etc)
Cluso99
Posts: 18,069
I was web surfing last night - I should have been programming my prop :-(
Anyway, I was thinking that for the PropAltair and similar emulations, that ram is always the problem. So, I thought about using 2 props as follows...
One prop would be the standard prop running VGA (or TV) and keyboard (and maybe mouse) and Serial (FullDuplex) and running a terminal emulation (VT52, VT100, etc). This is basically what OBC has done with PropComm (without the propdos). Nothing complex here. It can communicate serially to another prop. It may also use the SD card as a disk emulation to the second prop.
The second prop would have a serial connection to the first prop, and would load from eeprom as normal. It would then boot the emulation or load from the other prop. This prop would have its io pins connected directly to a 128Kx8 sram. This takes 17 pins for address, 8 for data and 3 for ce, oe and we, totalling 28 pins. This plus the 2 serial and 2 I2C makes the total 32 io pins the prop has. The sram has 10-15nS, so the prop will be slower than this.
Would a pcb with just the second prop built like this sound interesting, or should a pcb have both props on it including vga, tv, keyboard, mouse, etc?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Post Edited (Cluso99) : 1/22/2009 9:47:40 AM GMT
Anyway, I was thinking that for the PropAltair and similar emulations, that ram is always the problem. So, I thought about using 2 props as follows...
One prop would be the standard prop running VGA (or TV) and keyboard (and maybe mouse) and Serial (FullDuplex) and running a terminal emulation (VT52, VT100, etc). This is basically what OBC has done with PropComm (without the propdos). Nothing complex here. It can communicate serially to another prop. It may also use the SD card as a disk emulation to the second prop.
The second prop would have a serial connection to the first prop, and would load from eeprom as normal. It would then boot the emulation or load from the other prop. This prop would have its io pins connected directly to a 128Kx8 sram. This takes 17 pins for address, 8 for data and 3 for ce, oe and we, totalling 28 pins. This plus the 2 serial and 2 I2C makes the total 32 io pins the prop has. The sram has 10-15nS, so the prop will be slower than this.
Would a pcb with just the second prop built like this sound interesting, or should a pcb have both props on it including vga, tv, keyboard, mouse, etc?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Post Edited (Cluso99) : 1/22/2009 9:47:40 AM GMT
Comments
I've been trapped before by trying to get everything onto one board and get it all working all at once. Sometimes it is better to build things in modules and get each module working, and maybe down the track an obvious solution will come up that puts it all on one chip. The propterminal is a great standalone device but it may well be pushing the limits of the prop. The problem here is IO pins and the prop simply doesn't have enough. All the fixes are all fudges and end up using more and more glue chips to the point you may as well build it as a non prop solution.
So yes, a little board with a prop and just serial and/or I2C and a 128k ram chip. Don't try to do anything else at this stage. Put all the data storage on the other board eg the working terminal/sd projects. Before you build a board though, this sounds almost simple enough to breadboard and test that way. Just a 32 pin and a 40 pin chip after all. I presume 1k resistors if you are using a 5V ram chip? I've been using lots of SIL/DIL arrays for resistors and they certainly beat soldering in lots of individual resistors.
heater might be able to answer this one - will there be enough space for emulating all the instructions for a range of micros? Including but not limited to Z80? Enough longs etc. Given a micro will only use 64k, will the other 64k be useful in some clever way for the prop to use?
Sounds interesting. It could be a neat 3 chip computer. And no doubt someone will work out a cunning way of decreasing that chip count!
Post Edited (Dr_Acula (James Moxham)) : 1/22/2009 7:03:59 AM GMT
There might be a few more points. You tell about parallel connection in address and data, right? That's fast, but needs many pins. What about serial addressing? The simplest case is to put in a shift register that takes the addres. Would only need two prop pins, could be clocked rather fast, and you could use the cheap memory chips. You could even put a counter after the shift register that is automatically incremented at memory read. This would increase speed on block reads. If you invest some time in software development you could use this approach even to connect to DRAM of arbitray size! A propeller pulling 4GB or more...
There is also code around to access SPI / I2C memory and currently several threads on interfacing Microchip serial SRAM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Airspace V - international hangar flying!
www.airspace-v.com/ggadgets for tools & toys
I·am suggesting·parallel access and no·multiplexed address lines or latches/counters. This simplifies the software and speeds up the access. :-)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I'm not an expert on maximum speeds on the prop but heater only managed to get about a 4Mhz emulation on an 80Mhz propeller. Doing any data transfers in serial is going to slow things down ? by up to 16x further meaning an emulation speed in kilohertz rather than megahertz. I think it has to be parallel ram unless there is some very fast serial code out there. If you leave all the vga stuff as a seperate terminal project, set it to one side, and just consider a 40 pin prop and a 32 pin ram chip, this does become rather beautiful in its simplicity. I'm looking at the sort of board this replaces - it replaces an eprom, a microprocessor, a uart, two crystal oscillators and 9 74HC glue chips. Plus it can emulate any number of micros - 8080 6502 8085 8051 Z80, maybe even PICs?
The OE pin can be tied low, so for the 512Kx8 device 19 address + 8 data + CE + WE = 29 pins. Obviously the 128Kx8 device is fine with 27 pins. So, if the 512Kx8 is used (and it would be nice to be compatible for both chips)·the question is which pin to use for the 29th pin (SCL or SDA) so I need to look at the specifications to see which is best. I am thinking either the SCL or SDA would be tied to the WE pin. An eeprom is actually not required as it could be loaded via the serial pins (just like it is loaded by the·PropLoader now).
I also want to check out the SD card interface, as with no eeprom, there would be another pin available, so it may be possible to add an SD card interface to this board to emulate the disk.
Imagine a 2 chip Altair/Z80/8080/6502/6800 etc retro computer with 512KB of ram plus 2GB SD card connected to·another prop doing tv/vga/keyboard and any extra I/O or peripherals.
Postedit: The SRAM is 55nS.·Successive reading can be done by leaving CE permanently enabled (which prevents the SRAM entering standby and therefore uses a lot more power) and just changing the address and reading. However, the prop would require a nop in between setting the address and·reading the data (because between 2 successive prop instructions is 50nS). A write requires the WE line to be used.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Post Edited (Cluso99) : 1/22/2009 9:45:25 AM GMT
I'm a bit tired to absorb all the ideas here but as usual in any design there are many ways to go and many trade offs.
A parallel RAM bus connections must be the fastest possible, but uses too many pins. Fine for speed, not so fine for a single Prop solution with SD cards and VGA and keyboard etc etc.
Serial RAMS are going to be slower, but perhaps not so slow if a "memory controller" COG is fetching instructions in parallel with emulator cog opcode execution. This may be slower but is dead simple for people to add to a Prop demo board for, say, just running up an emulator for a lark. And of course useful for many other less speed demanding tasks.
So which way to go? Well it seems that both solutions are going to be designed and implemented depending on individual priorities. If anyone gets as far as producing a batch of boards for a parallel RAM solution for sure I want one and will be adapting PropAltair to run on it [noparse]:)[/noparse]
Just now I've been contemplating the idea of adding two old 32K RAMS (I have many in my junk box) and using Intel's trick of multiplexing the lower 8 bits of address with the 8 bit data. Only requires an external latch and an address decoder (just an inverter) This gets the pin count down to 19. Leaves pins for SD card etc. Looks like I could add it to my home made demoboard. If only I wasn't living away from my workbench and components just now.
Next up for me is to get CP/M 3 running which will require bank switched memory. I've come to the conclusion that the bank switching is best done in external hardware, otherwise some software always has to check which bank is supposed to be active at any moment and then fix up offsets into a linear external RAM space, slow.....
@Dr_A: I have not looked into emulating other CPUs much. There is someone working on a Z80 emulation for a ZX81 clone. No report as to how far that has come yet. There are others working on multi COG 6502.
The Z80 has twice as many opcodes as the 8080. It has more than twice as many registers. It has more addressing modes. This leads me to believe that it will require 4 or more times the effort to develop it and require multiple COGs. Could be done in one COG and LMM, I guess, but very slowly. Personally I'm not up for that but will keenly follow any developments that go on there.
BTW. PropAltair speed is probably worse than that. 350,000 instructions per second. Just like an original 8080[noparse]:)[/noparse] Without going to multiple COGs I don't see much improvement coming there.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Parallax, if you are listening? Has any progress been made on the B version Prop1? Since a year later we are still thinking another year for PropII, has the priority for the B version chip changed at all?
Thanks,
Doug
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I don't think the eeprom and 512Kx8 can co-exist, but the 128Kx8 and eeprom are ok. I have added an SD-Card also
Proposed Propeller / SRAM / SD Card PCB By Cluso99 22 Jan 2009 All parts 3V3 Propeller Eeprom Serial SRAM-512Kx8 SD-Card PullUps --------- ------ ------ ----------- ------- ------- P31 Sin P30 Sout P29 SDA A18 (nc 128Kx8) 10K P28 SCL A17 (nc 128Kx8) 10K P27 A16 P26 A15 P25 A14 P24 A13 P23 A12 P22 A11 P21 A10 P20 A9 P19 A8 P18 A7 P17 A6 P16 A5 P15 A4 P14 A3 P13 A2 P12 A1 P11 A0 P10 -CE 10K P9 -WE P8 -CS (1) 10K P7 D7 SCLK(5) 10K P6 D6 P5 D5 P4 D4 P3 D3 Din (2) 10K P2 D2 D2 (9) 10K P1 D1 D1 (8) 10K P0 D0 Dout(7) 10K -Reset -Reset -OE=Gnd▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· 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
Well the board above from Cluso99 looks pretty simple. As for old chips, well I've got drawers of 6264 8ks, and sooner or later, I've got to face up to the fact they may never get into a project [noparse]:([/noparse] A single 128k 3V3 is just so much simpler.
What else does such a board need to make it work? The download bit - is that a max3232? And it could talk to any terminal (propterm or hyperterminal etc) via good old RS232 so that would use all 4 gates in a max3232. 3 chips? Plus the SD socket?
Making boards is pretty easy (btw has that board arrived yet heater?). What I'm not clear about is how *useful* the other 64k of ram could be. I could see it being very handy to expand the prop's memory in theory, and decrease reads back and forth to the sd card. Maybe store emulations of lesser used instructions. But I'm not up with the prop to understand the details of how that might work. But if you want a board with sd and 128k ram and a max3232 that would be pretty simple. Let me sleep on the idea...
Post Edited (Dr_Acula (James Moxham)) : 1/22/2009 1:18:23 PM GMT
8 data
11 low address + 8 high address latched
1 address strobe
1 CS
1 WE
TOTAL MEMORY LINES = 22
To interface to the other Prop couldn't we use the 8Mbps Prop-to-Prop technique? Anybody try this yet?
I'm not really interested in emulation (maybe a little) but I would like to have the extra RAM for video and applications in general so I look forward to Prop II as everybody does. However, the current prop is excellent for many embedded tasks just as it, after all it is designed as a single-chip microcontroller in a friendly DIP or QFP pack. I have my pick of any umpteen micros that have external memory buses in 144+ lead QFPs (if I'm lucky) but mostly BGAs. As much as I would like the memory I'm not that interested to steer away from the Prop.
*Peter*
I am also with Kwinn to lach the data bus externally to provide more chip selects to several rams or other paralel IC; but I am against the address latching since this will page the memory and somehow limit the horizons.
As for the serial, this is still open. I think it should be unbuffered, but am thinking about if I will put an FT2232 onboard (USB to dual serial 3V or 5V). This would allow use with the cheaper Proto Board (without USB). I want to share the power supply between boards, so not sure if I will supply or take power to the other prop. Using a direct link to the other prop will allow the 8Mbps technique (untried). The reset line will also be connected because the booting may need to be done by the other prop.
BTW The other prop need not be a prop. COuld just be a pc (maybe via the PropPlug?)
The only other issue I can think of is whether to use SMT or DIP parts.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· 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
If you multiplex the data lines with the address ones you half the throughput BUT you can recover it with no penalties widening the data (so two cycles: one for address the other for the data BUT double the data 16 bits)
1MB (64K*16) = 16 addresses lached + 16 data
*Peter*
@Cluso
That suggested board not only looks simple to build, (and prototype!) but also uses parts
that everyone should be able to get their hands on. All we need is some parts and some
spin to glue this together!
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
My understanding wife asked me once if I had to choose between her and the "computer", which would I choose. I told her that was a silly question and not to ask it.
OBC, the timestamps give us away, we don't talk prop shop because we have to, we do it because we love to.
*Peter*
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· 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
dMajo, I am glad you liked the idea of latching the chip selects, but I agree with Peter Jakacki that it will not make much of a difference in speed. Profiling software has shown that most software program and data access is fairly localized. Look at how much time is spent in loops and subroutines. I also agree with Peter that all 16 address lines do not need to come directly from the prop. If we used an 8 bit latch ( like the 74xx373) we could use 2 bits to select one of 2 memory chips (or 1 of 4 with additional decoding) and the remaining 6 bits for the high address bits.
While this is not quite the arrangement Peter suggested it allows addressing 2 chips ( 1ram 1 eeprom? ) of 128K each with 22 prop lines:
8 data
11 low address + 6 high address latched
1 address (latch)strobe
1 OE
1 WE
TOTAL MEMORY LINES = 22
Using 2 more prop lines allows addressing 2 chips of 512K. Picture having several instances of CPM running at one time and being able to switch between them. The alternative is to use a second latch and free up some more prop lines. The down side of all this is it complicates a simple and elegant idea.
Is anything gained by freeing up the prop lines that are now used for more than one function (P0, P1, P2, P3, P7, P28, P29)?
16 address + 16 data
1·· address strobe
1·· WE
1· CS for lower 8 data latch (not the address latch) giving 8 CS/CE to up to 8 devices
TOTAL 19 lines for up to· 8 IC (ram/eprom/special parallel hardware/SD cards) addressable up to 64K*16 (1MB) with no latch penalties compared to 8 bit parallel; just 3 external 8bit latches (or one 8bit and one 16bit)
... and on P28/P29 it will be very nice to find a FM31L278 in place of the standard eeprom
I must admit I like the cleaner more orthogonal design it gives, but for emulating an 8 bit micro I feel it is not a good choice. It would be interesting to compare the two choices for the range of applications possible. Perhaps we could agree on some specific tests to run, write the code, and compare the results.
@Dr_A, sadly your board has not arrived here yet. I'm checking the post like a little boy at Christmas for the past couple of days. Only yesterday I found out where you are, via the vintage computer forum, it's a long way.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Re a board, I'd suggest DIP rather than surface mount. When I was younger I built a lot of circuits for small robots etc and tried to get everything as small as possible. But for computer boards, it doesn't matter if it is larger, at least for prototyping and proving concepts. SMD is so fiddly to make. It can always go surface mount once it is proven.
It is always tempting to add a latch here or a transistor there, but there are plenty of pins so there is no need to try to save pins. I like the clean and simple "no extra parts" solution.
Re boards, the biggest cost with small runs is the setup cost and the shipping. The number of boards and the size of the boards are less relevant. So making a board a bit bigger does not change things much. I'm just thinking that you could put a pad on the board for a 128k ram and you could also put one for a 512k ram and you could install which one you wanted. Ditto the max3232 - you could have a small header for digital comms (0-3V) and that signal can go to a max3232 and D9 pcb mount socket. If you only want digital comms eg to another prop board, then just install the header and leave out the max3232 and D9.
Re the download circuit, what is the vibe from the forum on the transistor circuit vs the max3232 circuit vs the prop adaptor board? Which one is most popular? Would you put pads for more than one (all) of these options and let the user install the components that suit them?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
-Phil