1: add a hardware switch to diconnect the /WR line from the ram for hardware write-protect (software write protect could be disabled by software bugs or a crash of the Zeddy, e. g. during each power-down)
2: I would not use the adress decoder output to enable also the memory data output (/OE). I would instead use the /RD or /RD & /RFSH signal for that.
Why: otherwise during write cycles, while the address is valid, the ram AND the Z80 would both drive the data bus. The ram releases the data bus only, when /WR gets active. But (depending on the data bus load) that could be to late to allow the Z80 output data to stabilize! Thus wrong data could be written into ram.
This problem occurred in some ZX96 systems even with buffered address/data bus and was solved by the modification described above.
I'd wait until the dust has settled.
1. Thanks! - a manual write protect switch is a good idea which I have added to the schematic. Also consider adding an under-voltage monitor chip such as the TI 7705 to auto-reset and write protect during power down.
2. No thanks! I have noted your concern in the text but that's only a problem for sytems with a buffered data bus, like the ZX96. Besides, more than a million Zeddies with RAMCS connected to CS and OE can't all be wrong.
what is the advantage of a 251 versus a 138? Would'nt it have been sufficient, to feed "/MREQ AND /RFSH" to the 138 to get the same result?
And one more question: what is the diode at the write-protect switch used for? IMHO it will always conduct when the switch is closed to +5V and never, when it is open. So the switch itself does the same ...
And one hint for large Zeddy systems: when I added a mmc-interface card to my Merker-Zeddy (has drivers for the data/address bus, feed via a cable bundle to a 6 slot bus backplane), the mmc-cardselect latch (corresponds to "U3") often "forgot", which mmc was selected. The problem was solved, when I added a 100 nF capacitor to it's /RESET-intput (-> pin1 at U3). There were some spikes on my /RESET line in this (big) Zeddy, which resetted nobody except the card-select latch
No problem at small zeddies with "clean" /Reset line ....
thanks again for your questions/suggestions.
To answer your second question first: Right on! The diode in series with the write protect switch is not required and has been removed.
The answer to your first question, "which of the 74HC138 or 74HC251 is better for this application", is a split decision when only using an 8K page size.
However for larger page sizes and more complex configurations the 74HC251 version can be used with fewer additional components.
The similarities for this 8K application are:
They have the same 1 of 8 select inputs connected to A13-A15. Both use an enable input connected to MREQ. Both use a second enable input to disable the ROMCS line when POKING the Page Register.
The differences for this 8K application are:
The 74HC138 has 3 enable inputs and 8 active low outputs, one for each block of 8K of the 64K memory map. This makes it particulary useful for enabling multiple 8K chips.
The 74HC251 has 9 enable inputs, one for each block of 8K of the 64K memory map, and a true and inverted Y output that are normally tristated. This makes it useful to enable one or two memory chips in 8K blocks and particularly suitable for memory mapping 32K and up chips.
If 32 pages of 16K are require between 32K and 48K then the D4 and D5 input pins of the 74HC251 are grounded with all other Dx inputs connected to Vcc.
The 74HC138 version would require an AND gate or two diodes and a pull up resistor to enable the SRAM CS/OE.
How about 31 pages of 16K between 32K-48K plus 16K of BASIC RAM between 16K and 32K?
How about 15 pages of 24K between 32K and 56K plus a single page of 24K always present between 8K and 32K? Want to add ROM overlay to that?
These options are relatively easy to add with the 74HC251 which is not to say it couldn't be done with a 74HC!38. Perhaps it's a matter of taste.
With respect to the RFSH timing, the 74HC251 is faster to enable the ROMCS line when fetching video patterns from the ZX ROM. This old ROM has slow access time and requires an early enable for the ROM data lines to be stable when loaded into the video shift register. In fact, the MREQ or RFSH components are not be required for the 74HC251 version to enable ROMCS . On the other hand, the 74HC138 version ROMCS timing is probably marginal even with these components installed.
The reason is that the 74HC251 leaves the ROMCS line normally enabled . This means that ROMCS enable depends on the normal ULA timing.
On the other hand, the 74HC138 leaves the ROMCS line normally disabled. This means that ROMCS enable depends on the 74HC138 timing.
If the SRAM will be used for HRG then the MREQ or RFSH components should be added and the timing will be adequate if the SRAM chip is 120ns or faster.
know the HC251 will work because I have used it several similar applications including the ZX97.
RAMPAGER as configured for 8K between 8K-16K together with a 16K RAM pack is a practical memory system for the ZX81.
thanks for the detailed explanations. Indeed I preferred the 138, because I often was happy (during the next winter and the next project), that there were additional decoded outputs availabe to add more chips later
But the 251 is a nice thing and you prooved that in your 32 KB (or more) internal and external memory expansion ideas ..
The HC27 decodes A13, A14,and MREQ, and disable the ROM at the appropriate time, while enabling the HC139 and A11 A12.
I have personally used the HC27 segment of this circuit to "rescue" the disabled RAM in my old TS1000. I am currently using a derivative of the circuit in my TS1500 Expansion Project.
Hope this helps.
Fussy, aint I
Would I need 2 /oe signals which would be combined or routed with the switch?