To simplify things even further, I suggest:

0000-BFFF: RAM [48K]

C000-CFFF: I/O (including TIA)  [4K]

D000-FFFF: ROM [12K]

Now, if we assume standard address lines A0-A15 with A0 = LSB,

RAM enable = ~(A15 & A14)

IO enable =  (A15 & A14 & ~A13 & ~A12)

ROM enable = (A15 & A14) & (A13 | A12)

[Note: In most cases the Chip Enable input is inverted, so these would have to be inverted]

This can be trivially implemented with a PROM, PAL or GAL, or with jelly bean logic chips if you prefer.

You can further decode the I/O space with something like a '138 connected to A9-A11.  This allows 8 I/O devices (one of which is the TIA), each of which can have up to 512 registers...  If you need more I/O devices, then decode more of the address bits.  You could of course shrink the I/O space to allow more ROM at the expense of a little more complicated decoding.

I opted for TIA in page 0 because I assumed that Blair wants to access TIA frequently, e.g. for animation, and that initially he had put TIA there for that reason. If that assumption doesn't hold, I concur with your proposal.

Edit: as @matseng noted, segment 0100 - 01FF is reserved for stack in 6502 and I/O can't reside there!

The first rule of address space allocation is: use boundaries which are at power of two numbers. Don't try to eliminate gaps when you have devices which take locations in chunks which are not powers of two.

I would recommend allocating base addresses with ample ones in it, because then the decoder or part of decoder can be simple multi-input NAND gate.

Therefore, I propose following address map:

0000 - 00BF || RAM (zero page for compiler's virtual registers file)

00C0 - 00EF || TIA write (optionally w. shadow RAM)

00F0 - 00FF || TIA read

#0100 - 01FF || I/O 256B (strike this)

0200 - BFFF || RAM (48K - 512B)

C000 - FFFF || ROM (16K)

The RAM is selected by default, unless masked by another address decoder. There is a decoder for ROM, a decoder for 

Edit: 

[lowest 512B, and decoders within the lowest 512B for upper 256B general I/O, for] (ignore this)

TIA in the top of lowest 256B and within TIA space additional logic to discern between write and read portions. TIA write decoder can allow RAM to be selected too, so that the copy of last data written in TIA would also land in RAM, and could be read back from same address (that's shadow RAM). However, in TIA read portion, RAM must be strictly deselected to avoid bus collisions.

Edit:

Additional decoder for not super-fast I/O should decode addresses somewhere on the RAM/ROM boundary. Again, I favor the segments in the top of existing segments, but @Steve Toner's proposition is even better.

@salec You can't have I/O in the full 0x0100 page. On a 6502 the stack must  reside somewhere in there.

Oh, I didn't know that, I assumed 6502 was more similar to M6800. After you pointed this out I googled for it and you are right. Sorry. I acted irresponsibly, yet again :-( .

@salec It was just sheer luck I knew about that...  My first three computers ba in the late 70's and early 80's used a 6502 and the first two I mostly wrote assembly code for.  KIM-1, AIM-65, Apple ][ 

But it's a strange optimization to lock the stack to page 1 - I mean that with just some handfuls of more transistors it could have been fully flexible as in any other CPU....

hey everyone, thanks for the replies.

i have never done address decoding before.

is there any reading anyone can point me to?

Just for fun I decode the address space. Not nice! 42 NAND gates with up to 23 inputs.

Here is the "Espresso" results:

.i 16
.o 5
.p 26

0-----------11-1 10000
0-----------111- 10000
01------00111-11 00110
01------001111-- 00110
0----------1---- 10000
00000000000----- 01111
01000001001----- 11101
01000000-11----- 11101
010000001-1----- 11101
0-000000001----- 11011
01-----1-11----- 11110
01-----11-1----- 11110
01----1---1----- 11110
01---1----1----- 11110
01--1-----1----- 11110
01-1------1----- 11110
011-------1----- 11110
00----1--------- 11011
00---1---------- 11011
00--1----------- 11011
00-1------------ 11011
001------------- 11011
00-------1------ 11011
00------1------- 11011
00-----1-------- 11011
01--------0----- 11011
.e

This may seem meaningless but the first 16 digits are A15..A0 (the address space) and the last 5 digits are WR, RD, RAM, IO and ROM (your decoded address lines).

A "0" is a low, a "1" is a high and a "-" is I don't care.

A quick estimate for the (maximum) number of gates is 16 inputs (=16 inverters), 26 lines (=26 NAND gates of up to 16 inputs) and 5 outputs (=5 NAND gates of up to 26 inputs).

It is actually not quite that bad (i.e. 42 gates of up to 23 inputs).

When faced with this level of complexity you can either use a 64k ROM or a PLA.

But sometimes it is "fun" to build a logic gate structure. Here is an example of a DIT keyboard (https://cdn.hackaday.io/images/2506091471413125482.jpg).

I hope I did not bore you with this!

AlanX

hey! thanks for your help. i have never done address decoding before, and i don't fully understand it, is there a tool i can use to work on it?

Use an existing address mapping from a real working project.

I rather like the "Compukit UK101" but it depends on if your going to try and use existing software (like the operation system!).
I played with a simple design a while back (https://cdn.hackaday.io/images/2587411471860103279.png), the address mapping I used is on the diagram along with my address decoder.

There is an error on the schematic (the power plug is hooked up the wrong way - nasty!).

It does not really matter if your address decoder does not have a unique address for your IO.
Best of luck, AlanX

thanks so much for all your help!

48K RAM,

256B IO + TIA graphics,

and slightly less than 16K ROM!

Yes it puzzles me as well. Matseng is right, the decoding logic for this address mapping will be expensive. Just to decode the first 256 bytes of the address space required 11 gates (using Logic Friday). So I would expect 2 to 3 times that for the full address space.

Again Matseng is right. The address space should be aligned with 16k (or some other 2^n, where "n" much greater than 8) boundaries.

Address space decoding is not meant to be this hard!

Yeah, why isn't the TIA just in IO space?

Does 6502 even have I/O space? Its ancestor, Motorola M6800, has only single address space and the I/O is memory-mapped.

I'm not familiar with the details of the 6502, but I assume I/O is memory mapped.  So there is a section of the address space that can be referred to as "I/O space."  The OP even shows such a space in the original post ("C03B-C13A || IO (256B)").  So the TIA looks like an I/O device to me and therefore it doesn't look like it needs its own address space.

Also (to @Blair Vidakovich ): I'm not familiar with the TIA, but it's probably not necessary to separate out the read and write addresses.  In most cases they can overlap, and the R/W signal from the processor indicates whether you're reading or writing.

Why would you want to destroy the (very important) zero-page of the 6502 by putting the TIA-chip in it?  And why not simply start the IO region at C000 and end it at C0FF?

Decoding addresses down to least-significant-bit level like you want will require a lot hardware.