Hello out there,
I think I have now the final draft of the address decoding for my MOUSE project, moving from the breadboard to a PCB.
The plan is to have 32k SRAM from 0x0000 to 0x7ffff and also 4 x 8k blocks for different use. Two blocks (0x8000 and 0xA000) can be used by external modules, 0xC000 is the I/O area with one RIOT, one VIA and two MC6850 ACIAs. The upper 8k block is mapped to the internal ROM. The pictures shows the underlaying logic, using only one quad 2-input NAND (one quarter as inverter) and one 74HC139 to decode the 4 8k blocks. By using the different chip-select inputs of the I/O devices no further logic seems to be needed. Here's the "masterplan":




It would be great if somebody could take a look at this and tell me if I'm totally wrong or have missed something.

Thanks,
Mario.

_________________
How should I know what I think, until I hear what I've said.

I don't see anything that would keep it from working as planned. I had to look up the 6850's select and enable (like phase 2) lines to verify, since I'm not that familiar with it. I do hope WDC gets their bugs out of their 65c51. It's a bummer not having a baud-rate generator on the 6850. Other manufacturers' 65c51's were bug-free (unlike the NMOS '51) and I've never had any trouble with them in all the 20+ years I've used them.

If you don't need an inverter for other things on the board and you have an extra NAND section, you could replace that inverter with a NAND (with one input tied high), and get rid of one IC. To take it further, you could replace both the inverter and the NAND with the other section of the '139, further reducing the chip count. Replacing the 74HC's with 74AC139, you'd even get less overall propagation delays.

Your RIOT addressing will go to up $C0FF, not just $C09F.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Mario, before you go looking, Reichelt doesn't have the 74AC139, it seems that will have to be Mouser. I can send you one over, I won't be needing it until the final build, and that will require another Mouser order anyway.

Thanks for the feedback. I think the 74HC139 is fast enough for this circuit and I already own some of those. The mainclock runs with 1.8432MHz to get a proper baud rate with the 6850 (28.800 with a prescaler of 64). Maybe I switch to 1.2288MHz if I'm facing problems. According to the datasheet of the MC6850 the "E" cycle time should be 1 µs which means 1MHz Rx/Tx clock frequency. So it seems I'm driving my ACIA far beyond the specification. 1.2288MHz is much closer (but still beyond) to the specification. At the moment it works, But in case of any problems I can easily use a binary counter to divide the serial clock by 4 and use the prescaler of 16 instead of 64. The result is the same baud rate but with a much slower clock.

@Garth: What exactly do you mean with " To take it further, you could replace both the inverter and the NAND with the other section of the '139"? Thats not clear to me.

Mario.

_________________
How should I know what I think, until I hear what I've said.

Oh, I've got a "flash of inspiration"
The '139 has two 2-to-4 decoder. I could use phi2 und A15 as input for the second decoder and the output to drive the RAM /CS, but how do I get the /E signal for the first decoder with interfering with phi2?

_________________
How should I know what I think, until I hear what I've said.

Ok, proofed
I have completely re-wired MOUSE, starting with an empty breadboard, with now a 62256 32k SRAM, my 28C64 EEPROM and the MC6850 using 1/2 of the 74HC00 quad NAND and 1/2 of the 74hc139 for the decoding logic. Forcing the 6850 to 0xC000 in a first step, so I needed no changes in the current OS for the ACIA base address. And it worked on the first attempt without any bug in the mess of wires

_________________
How should I know what I think, until I hear what I've said.

How about using A15 as input to /E, phi2 as I1 and pulling I2 low? That way, you should be able to get the RAM enable signal O1 (I think).

Consider me ignorant/daft, but how can /OE be on the same line as /CS? Surely /OE needs to be low only when the MPU is doing a read cycle?

I've not done much with the 6502, but that is how 6809 machines are wired.

Can someone explain how this works?

Lawrence

_________________
8 bit fun and games: https://www.aslak.net/

When /WE is asserted, the /OE becomes a don't care for the SRAM.

Oh! Is that common to all SRAMs? What about EEPROMs, eg. 28C256?

_________________
8 bit fun and games: https://www.aslak.net/

I don't know if all SRAMs do that, but I assume the RAM used in the design works like that. A device like the AT28C256 does not work like that. With /OE asserted, the device goes into a Write Inhibit state, and the /WE becomes a don't care.

That's not true in all cases. Unless the data sheet says /OE is a don't-care during a write cycle, you cannot assume that something untoward won't happen if /OE and /WE are simultaneously asserted. Assumptions of that nature can lead to a DOA unit.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Agreed, you should always look at the datasheet for the device you intend to use. Even though there are many common characteristics between different vendors and types, there is always opportunity for minor differences. Not just in the use of /OE, but also regarding timing, voltages and other parameters.

In this case, I had assumed that the OP already consulted the datasheet before making the design.