New 64/128/256K random access memory expansion circuit for the propeller
mahjongg
Posts: 141
As promised, (see the older thread) here is the schematics of a new, completely random access, memory expander for the propeller.
I don't have the time to explain everything about it at the moment, but basically you first latch a 3-bit "command" in the latch in the HC137, using 3 bits of the databus, and strobing the CTRL-A control bit low and high again.
Then you set up the databus for what you want to do, writing an uppor or lower address, or reading or writing data to the ram, and then "execute" the command by strobing the CTRL-B bit low (then read data if its a read command), and returning the control bit high again.
The "commands" are:
0 = read data from ram
1 = write data to ram
2 = set lower address
3 = set upper address
If more than 64K of ram is used, you can add one more chip, a 74HC00, and use the four remaining commands to choose which bank of 64K you want to access.
More than 256K is possible by adding one more HC574 and connecting strobe A to its CLK input.
p.s. the attachment manager refused to upload my .PDF, so I zipped it.
Mahjongg
I don't have the time to explain everything about it at the moment, but basically you first latch a 3-bit "command" in the latch in the HC137, using 3 bits of the databus, and strobing the CTRL-A control bit low and high again.
Then you set up the databus for what you want to do, writing an uppor or lower address, or reading or writing data to the ram, and then "execute" the command by strobing the CTRL-B bit low (then read data if its a read command), and returning the control bit high again.
The "commands" are:
0 = read data from ram
1 = write data to ram
2 = set lower address
3 = set upper address
If more than 64K of ram is used, you can add one more chip, a 74HC00, and use the four remaining commands to choose which bank of 64K you want to access.
More than 256K is possible by adding one more HC574 and connecting strobe A to its CLK input.
p.s. the attachment manager refused to upload my .PDF, so I zipped it.
Mahjongg
Comments
I couldn't figure out how your circuit worked until I looked up the HC137 and found out that it latches the address inputs. I hadn't been aware there was a demux with that capability. Learned something new.
inputs transition at slightly different times? (Note that this chip latches the inputs, not the outputs, so the latches
won't necessarily prevent glitches.)
The SN74HC137 is a "transparant latch", but once the /GL input returns high the A/B/C inputs are internally latched and remain stable.
Thereafter the /G2 input only enables the pre-selected output, so no glitches should occur.
One of the main puzzles was indeed to design a circuit that would not glitch the control lines.
Before this solution, I tried to design a circuit that could decode 3 control bit inputs to one of eight command pulses. But the problem was of course the potential glitching. So I designed a circuit that could deglitch a 3-input to one-of-eight decoder circuit.
Now, with this new design I do not need it anymore, and as a bonus I also only needed 2 input's not 3.
My deglitcher was also a quite complex circuit, I would first connect the three inputs (A/B/C) to a 3-input-NAND to detect "any line going low", then I would feed the output of this NAND to both inputs of an XOR (74HC86), but with a slight delay to one of its two inputs ( a few gates in series). The resulting output of the XOR would be a high going pulse of 50 nanosecond or so whenever any of the three inputs would go low, AND a second pulse if all inputs would return high. These pulses would be used to latch the output of a 3-input to one-of-eight decoder circuit (HC139). the result, a circuit that would remove the glitches, as long as the A/B/C inputs do not change with a too different timing. But when using a single propeller assembler instruction to set all three output bit's that would not be a problem.
By the way, often a small (22pf) capacitor over the output of a decoder (such as the 74HC139) will remove most glitches, as long as they are not too long. Not a "clean" solution, but it often works.
The deglitcher circuit has one advantage over this one, it does not need to use the databus to chose a command, so you do not need a separate "what to do" and "now do it" stage, which could inporove access speed, but I think the speed of my circuit should be fine.
With some smart programming you should be able to improve the access speed of my circuit, one idea is not writing to the upper address latch when only the lower 8-bits of the address have changed. But then, also setting the upper latch takes only a few assembler cycles, so maybe it is not worth bothering, except maybe when you do a block-move or something similar.
Mahjongg
Right that's why the 8255 includes commands to set/reset individual bits of port C, so that you can operate a control bus without glitching it like you would if you wrote 8 bits at a time. Theoretically the demux might glitch it's outputs but I wonder if you ever actually see that in practice? If it does we might be able to get around this problem by adding a 74HC374 latch in between the demux and the control lines, but only if the 374 doesn't itself glitch! And you'd have to control the 374 too. What if you used three 8 bit latches? Instead of the demux you would hang a third latch off the data bus to do control as well. But then you'd need 3 control lines instead of 2.
Btw, what's the difference between the 74HC574 and the 74HC374? I imagine the 574 is an upgraded version?
A 74HC574 is essentially a 74HC374 with all its inputs on one side and all the outputs on the other side, So its a little bit easier to route a PCB for the 74HC574. Of course the 74HC374 would work equally well in my circuit.
Mahjongg.
I have allready done it in my head, just have to write it down.
Mahjongg.
For a 64K design this means you need one more chip, but for 128K and 256K chips the chip count stays the same, and software control of the "bank switching" is even somewhat easier. Note that one more data bit is latched (DQ3) and that DQ2 and DQ3 are now directly used to select a 64K bank, so you do not need two seperate "set bank switch bit" instructions. For 64K memory circuits the old version and this one are completely compatible, so you can use the old version if you only need 64K, but for all circuits that want to address more than 64K I propose you use this one, not the old one, as chip count does not differ, and this circuit is then more easy to program for. Therefore I propose to make this rev 2 circuit the "default" one to developing software for.
Also note there is one halve of a HC139 unused, so mayby you can use it to decode for two (or four) RAM's, if you have two 128K rams, and want to make a 256K system.
For systems beyond 256K ram, you can use the second halve of the HC139 and connect its A and B inputs to [noparse][[/noparse]X] and [noparse][[/noparse]Y] and it's /G input to CTRL-B. Noy you have for more strobes to address aditional 74HC574 address latches, so you can still address a gazillion bytes.
So here it is. Note that the CD4042 (HEF4042, 74HC4042) can also be replaced by any other 4-bit latch, as long as "high" is the inactive state.
If you don't care about the chip size you could even use another 74HC574 (or 374).
Mahjongg
http://forums.parallax.com/forums/default.aspx?f=21&m=76540
I used an SX28, three 74HCT573s, a 74HCT139 to control the latches and used a 512K SRAM. It worked great; I logged GPS data points from hundreds of miles of bicycle rides over several years with this project.
The code is pretty straightforward - you apply each address part in turn and latch it into place, then apply your data then pulse the WR line to write to the RAM. Reading is about the same except you pulse to output enable (OE) to read it back. My SX code is included with the posted project if anyone is interested.
David
my goal was always to use only 2 i/o bits so that it would be possible to put the circuit on the hydra expansion card, (or any other board that had only one 8-bit port free, and where you could "scrape" only two other I.O ports together), thats why i was so "obsessed" with having only two control bits.
But of course if you do not have that limitation then it's perfectly fine to directly control the 3-to-8 mux, at least if you fix the glitching problem by also using the enable input. You have to first set the A/B/C inputs, and then strobe the enable gate of the HC139, I think that is what David did, because it seems he is using four control bit's.
I am still curious, maybe the enable gate is not needed at all, and no disabling levels of glitching will occur if you just ignore the problem, and use "111" as "do nothing" and any other combination as "do something". Perhaps only a few 22pF caps on some of the HC139's outputs would be all that is needed to fix any glitches, no way of knowing before you try. Sometimes you can worry about a potential problem that does not even manifest itself, really "ignorance can be bliss" sometimes.
I just printed out the propeller manual, so I can study it a bit
Mahjongg
If you enable the outputs of the decoder only after the inputs have stabilized you can't get output glitches, independent of which logic you use.
By the way, the circuit will probably work with 5V logic and RAM, mainly because of the current limiting resistors on the data-lines of the RAM, but I purposely used HC and CMOS logic, and a 3.3Volt RAM in my design to avoid problems.
Mahjongg
The local electronics surplus store caries chips with eight 3.3K resistors integrated into one package. I wonder how many ohms resistance you can use before the slew rate of the data lines is too slow?
3K3 resistors will probably work considering the Propeller uses CMOS inputs with weak pull-ups and a trigger level halfway VCC.
Maybe the data will arrive a bit late at the 8-bit input port, but that should be fixable with a single NOP instruction, just after the CTRL-B input is lowered and before you actually read the input port. Also mayby you ned a similar NOP in the data write routine, but that is about it.
Resistor packs can be gotten in all kinds of values, I often use their SMT (surface mount) counterparts, so perhaps you can find some 1K versions.
Well, I promised to write some "pseudo code" examples to explain how to write drivers for my memory expander, and I did just that, and also wrote a bit about what -kind- of drivers you can write. The text is an .RTF document inside the .ZIP file.
Read and enjoy, questions are welcome.
Mahjongg
the resistors degrade the signal lines. For my SD work, I used 150 ohm current limiters initially, but they kept the
assembly language versions of the SPI drivers from working because of the signal degradation. The RC time constant
can be a real pain when you are running at multiples of megahertz.
On the other hand I am using the parallax demoboard breadboard, and that does introduce some additional capacitance.
But let's say you want those signals to have a useful bandwidth of 10MHz (which doesn't mean they are changing that
fast of course). This is 100ns. With 1K, that means the total capacitance should be well under 100pf. Now typically
SRAMs have input capacitance on the order of 10pf or less, so you should be okay at 1K.
Does anyone know what the expected capacitance is of the solderless breadboard?