Could this be used to select a $8000 to $8FFF (4k) for devices as CIAs, VIAs, etc ?
Thanks for advices

That does decode $8 into a low pulse for CS\. However, CIAs and VIAs etc. have their own Ø2 inputs so you don't normally need to include the clock in your address decoding for them.[1]

Here are some articles you might find useful:

http://wilsonminesco.com/6502primer/addr_decoding.html <- Garth's famous primer
https://www.atarimagazines.com/computeii/issue3/page15.php <- an old but still good article

Note that, in Garth's circuit (about halfway down the page), the chip select for RAM and ROM is qualified by Ø2 but *not* the chip select for the interface adapters. Also note that Garth's circuit has simplicity as a design goal, and is intended for use in systems of this type:



If you're trying to eke every last ounce of speed out of your 6502, you might need a slightly different circuit.

[1] Edit to add in this pertinent quote from the Primer:

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

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

Thanks for answers, phi2 out of grid and direct to 6522s and 6551s

Easy now:

/RAM_CS with (A15)
/ROM_CS with (NOT A15)
/DEV_CS with ((NOT A15) OR A14 OR A13 OR A12)

Hi agsb,

It *is* easy (or it can be!)

Just be sure that ROM_CS\ and DEV_CS\ can't both be low at the same time.

One other thing you might want to think about is that 6522s and 6551s have two chip-select lines each, an active high one and an active low one. Depending on the complexity of your system, you might not need to decode them much at all. You could, e.g., connect A4 and A5 to CS1 and CS2\ of your VIA, and then connect them the other way round to CS0 and CS1\ of your ACIA.



This works kind of like XOR: your IO devices will activate on A4/A5 = 10 and 01, so you still have A4/A5 = 00 and 11 for RAM and ROM addresses. This kind of decoding will mirror your IO devices throughout your entire address space (all those 'don't care' x's), but depending on what you're building that might be OK! There are some areas of the address space you probably don't want to mirror your IO in, though. How would your address space look if you used A5 and A6 or some other pair of address lines instead of A4 and A5?

Another way is to use your DEV_CS\ signal to drive both the VIA/ACIA active low selects (CS2\ for the VIA and CS1\ for the ACIA), and then use A4 and (NOT A4) to select between them. Depending on how you generate your DEV_CS\ signal, this can give you a more fully decoded address space. (You could use a 74x138 to generate your DEV_CS\ and park your IO at $8000 like you mentioned in your first post.)

Some useful logic chips often used for address decoding are:

74x30 8 input NAND gate, 74x688 8 bit magnitude comparator, 74x139 2 to 4 line decoder / demux, 74x138 3 to 8 line decoder / demux.

The traditional way of fully decoding an address space was to use cascading 74x138s. This will still work fine if you're building a slow system, but propagation delay will add up quickly!

One last thought: to me, setting aside 8k for IO is wasteful. That's room for *hundreds* of VIAs and ACIAs! Depending on your project, there might be tradeoffs that make that waste acceptable. However, if you're building a kind of "standard" system with a 32k SRAM and 32k EEPROM, your address space is already totally full of RAM and ROM. It's not like in the old days where your system might come from the store with 4k or even 2k of RAM. In this scenario decoding IO is a problem of *stealing bytes* from the RAM or (in your case) the ROM area of your address space. If you haven't already, I'd again suggest reading the two articles I linked in my previous post. Garth's page has a good discussion of why you might or might not care about mirroring your IO, and the COMPUTE II article talks about IO decoding as byte stealing.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

> wasteful

Just to note, this is often a mistaken way to think, in my opinion. Whatever it is, it may be inefficient in some resources, but it might be the right tradeoff for the project.

An example might be using just 32k of a 128k RAM chip, or using anything less than the whole capacity of a RAM or a ROM. Yes, you have unused RAM, in a sense, but maybe that's the chip you have, and maybe that's the memory map that makes sense for your project.

In many cases, the glue logic will offer more space for I/O than is strictly needed. That's not too important, so long as there's enough RAM and ROM to do what the project wants to do.

As I said:





However, if you're already using a 2-chip solution then since there are fast 2-chip solutions that let you plant a small IO window anywhere in the address space, it seems to me that you can often have your cake and eat it too.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

Ah, yes, so you did!