It's pretty common to install a 32KB device in one half of the address space - the low half for RAM, or the high half for ROM - and to break up the other half for the other type of memory and I/O.

A close examination of, say, the 74HCT138 datasheet will show that it doesn't just have 3 bits of address input (A0, A1, A2), but also three selector inputs, two of which are active-low (/E1, /E2) and the third active-high (E3). This improves its flexibility considerably, not only because it allows cascading two or more to decode multiples of three bits and ever smaller chunks of address space, but also because you can feed address lines directly into the enable pins and thus decode four or more bits in one go. Meanwhile your memory devices, occupying large chunks of address space and thus requiring only minimal decoding, can use simpler devices for that purpose.

Chip Select inputs tend to be active-low, for historical reasons involving the characteristics of TTL drivers. A 32KB RAM can therefore use A15 directly as its chip select, and will then occupy the low half of the address space. A 16KB ROM can use a spare NAND gate to test when A14 and A15 are both high, to occupy the top quarter of address space, and such a spare gate naturally results from using three-quarters of a 74HCT00 to convert Phi2 and R/W into /OE and /WE. So you've effectively got super-fast address decoding for your two biggest devices for free.

This leaves a 16KB chunk for I/O devices. You can divide this into 2KB pieces using a single '138, by connecting A15 to E3 and A14 to both /E1 and /E2, and A11-13 to the A0-2 inputs. Or you can divide the bottom half of it into 1KB pieces by connecting A15 to E3, A14 to /E2, A13 to /E1, and A10-12 to the address inputs. To similarly decode the top half, use a second '138 and an inverter on A13.

If you want to be particularly frugal with address space for some reason, observe that many I/O devices occupy a block of 16 bytes. You can select such an address block using an 8-bit equality comparator, cascaded into either a '138 or a 4-to-16 decoder.

Look again at the diagram ttlworks posted from the 6502 primer's address-decoding page. With nothing but a quad NAND, you can decode RAM, ROM, and up to ten I/O ICs, as long as the I/O ICs have two chip-select inputs like the 6522 and 6551 have. One select of each of these ICs is fed from the output of one of the NAND sections as shown, and the other is fed from an address line. I/O goes in the second 16KB space, between the 16KB RAM and the 32KB ROM. No 138's necessary.

_________________
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?

What I've "settled on" over the last week is something like the following:

Half (*1) a 139 to manage Phi2 and R/W into /OE and /WE.
A15 to /CS of a 32kx8 SRAM (I have a CMOS one someone gave me years ago - that'll work with an old NMOS 6502?).
A15 to G1 of a 138, with A14-A12 decoding the top 32k into 8x4k (*2).

(*1 Later, maybe the second half of the 139 could cut a 4k into 4x1k, and the VIA's and two more "future" IO could be there.)
(*2 Making that instead 2x4k and 3x8k was what led to my original question. I've dropped the idea, thanks.)

Giving:
4k ROM
4k VIA
4k VIA
4k "future" x 5
32k RAM
... with just 2 cheap chips of glue. Simple for now, room to grow.

Making a clock was the next question, but I found a thread on the Arduino forum which gave a nice routine to divide the 16MHz clock of the Arduino by 16 and give a nice square wave ... I have a bunch of Arduino's so that will be an easy temporary solution. (With the Arduino's (including bare Atmel IC's) I'd been thinking of ways to use them with this, e.g. as an "IO processor" to handle I2C and SPI ... but that kind of feels like cheating so this Arduino-as-clock will hopefully only be temporary.)

What I will be using an Arduino for, is EEPROM programming. I have the I/O expanders I need, and have ordered some AT28C64B-15PU to try.

Thanks everyone.

Most SRAMs will work with either CMOS or TTL inputs. To be certain of that, look up the datasheet by part number, and examine the DC Characteristics table, in particular the "input high/low" entries with VCC in the vicinity of +5V. Entries like "input low: 0.8V" and "input high: 2.2V" indicate TTL compatibility. An entry like "input high: VCC * 0.8" should give you pause, because that's a CMOS spec which a TTL output will have difficulty meeting.


A '139 demultiplexer is likely to propagate the Phi2 signal slower than the single NAND gate in the recommended 74HC00 configuration. For an NMOS CPU (which specifies an "Address Hold Time" of 30ns at the beginning of Phi1) it may well still be fast enough, but it's vital that the address lines from the CPU don't change before the /WE signal to the RAM goes high, otherwise a spurious write may occur. The 74HCT139 is *just* fast enough in its maximum propagation at +5.5V to avoid this hazard, and its "typical" specs are faster, but I would still prefer to use a plain NAND gate here - not least because it allows fitting a modern CMOS 6502 later.

_________________
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?

The rules of thumb I work with on the 65xx bus:

1: Address decoding doesn't need to be very fast, because it changes only once per cycle and the relevant inputs are valid by the end of Phi1. Many devices respond relatively slowly to chip-select and address signals, too. So you can use those handy 3-to-8 and even 4-to-16 decoder chips.

2: Data transfer occurs precisely during the Phi2 cycle; reads must be valid at the end of it, writes must complete at the end of it. You therefore need your device's access time (from the read strobe) to be less than the length of the Phi2 phase. This is the bit that gets easier with slower clock speeds, and/or by adding wait-states.

3: Clock management, and its conversion into read and write strobes, is the most critical timing element, even at low clock speeds. The governing timings are typically those of setup and hold times, which are usually much shorter than access latencies for even relatively fast devices, and crucially they do not get better when you reduce the clock speed. Hence you only want 1 gate delay between Phi2 and strobes, which happily is easy to achieve.

Something I studiously avoid is using the Ø2 clock to qualify chip selects. Doing so will cost part of the Ø2 high period. I only use Ø2 to qualify read/write.


In the case of the 65C816, qualification of a read must occur due to the bank bits being present on the data bus during Ø2 low. An alternative (and more complicated) solution to this potential contention issue would be the use of a bus transceiver to isolate the data bus from the '816 during the Ø2 low period. Qualification of a read is optional with the 65C02, as the data bus is not driven during Ø2 low.

I should note (has been mentioned in the past by both Garth and me) that the MPU's RWB output should directly connected to the RWB inputs on 65xx peripherals and not qualified in any way. These devices "know" about the 65xx bus cycle and require that chip selects and RWB be stable before the rise of Ø2 in order to function.

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