Dr Jefyll wrote:
Alright, I'm back -- sorry for the delay!
No worries - been distracted myself.
Quote:
From the look of this I guess you intend each I/O device to be activated by a gate (located on the I/O card -- added in color).
Yes, that's the idea. In most cases there will only be a singe device on an I/O board, at least initially, then I could add them on as required. However, experiments have shown some trouble with my I/O bus scheme. The problem is not too much propagation delay, but rather the opposite. Using a 74ATC245 to drive the data bus is not allowing enough data hold time for some slower devices I want to use. Using a 74LS245 might help the slower devices, but may cause issues on the processor side of the bus ans I try to speed things up.
Quote:
The gate would require a Device Select in addition to the Slot Select for that slot. And the gate's output would activate the I/O device (also on the card, of course). I can see advantages to this arrangement, although to some extent it's a tradeoff due to the speed penalty of a third layer of logic. Presumably the tradeoff is something you judge to be worthwhile, according to priorities you've established for the project.
Using fast gates should make this work. Just have to solve my data hold time problem. Of course I could solve that by latching data for slower devices at the I/O board.
Quote:
[Edit:] Can you tell us about how the 3 signals from the ROM Page Register get fed through the GAL before being applied to A16,15,14 of the ROM's? Does the GAL have a mapping function?
The GAL uses the higher processor address lines and the ROM page register lines to map to actual ROM addresses. The CUPL code is here:
Code:
Name OMS-01_MMU_V2 ;
PartNo X00 ;
Date 2/20/2018 ;
Revision 01.1 ;
Designer Bill O'Neill ;
Company BOP ;
Assembly OMS-01 ;
Location ;
Device g20v8 ;
/* *************** INPUT PINS *********************/
PIN 1 = A15 ; /* */
PIN 2 = A14 ; /* */
PIN 3 = A13 ; /* */
PIN 4 = A12 ; /* */
PIN 5 = A11 ; /* */
PIN 6 = A10 ; /* */
PIN 7 = M2 ; /* Rom Page select 2 */
PIN 8 = M1 ; /* Rom Page select 1 */
PIN 9 = M0 ; /* Rom Page select 0 */
PIN 10 = Phi2 ; /* */
PIN 11 = RW ; /* */
/* *************** OUTPUT PINS ********************/
PIN 15 = RD ; /*Read - active low */
PIN 16 = RAM_WR ; /*RAM Write - active low */
PIN 17 = ROM_A14 ; /*ROM A14 */
PIN 18 = ROM_A15 ; /*ROM A15 */
PIN 19 = ROM_A16 ; /*ROM A16 */
PIN 20 = IO_CE ; /*IO Select - active low */
PIN 21 = ROM_CE ; /*ROM Select - active low */
PIN 22 = RAM_CE ; /*RAM Select - active low */
/* Intermediate values */
a = A15 & A14;
b = A10 & A11 & A12 & A13 & A14;
/* Output definitions */
RD = !RW;
RAM_WR = !(Phi2 & !RW);
RAM_CE = A15 # b;
ROM_CE = !A15;
IO_CE = A15 # !b;
ROM_A16 = M2 # a;
ROM_A15 = M1 # a;
ROM_A14 = M0 # a;
Quote:
Here is an interesting speedup, useful when decoders are cascaded. The diagram below shows how an 'AC139 can be replaced by a 'CBT3253. (A fast one-of-eight decoder is also possible, using a 'CBT3251 instead.) Parts from the CBT family (and other low resistance FET switch products) have near-zero propagation delay for a signal passing through the switch itself. The same can't be said for the S1 and S0 select inputs, which incur some delay in establishing the desired connection, but that delay is hidden because it's concurrent with the delay of the GAL producing its output. IOW when the GAL output eventually goes low, the CBT output will go low at virtually the same instant. This basically eliminates one gate-delay from the overall path.
They look like nice devices Jeff! I may incorporate them into this design - but I've spent a lot of time on the layout so far and would hate to have to begin again at this point. However, anything can and will happen. Nonetheless I'll have to pick some up to have a look see. Thanks for bringing them to my attention.