Is this address decoding circuit correct?

[MrOmnos]

I found this circuit in one of my notes that our TA gave us. The problem is to design an address decoding circuit for two 4Kx8 RAM chips at the 2050H . We have 16 address lines. So, for 4Kx8 RAM we need 12 address lines to address the memory. Remaining can be used for deriving CS' (chip select) signal.

Here, For RAM 1 we have

Starting address 2050H : 0010000001010000
Ending address   304FH : 0011000001001111

For RAM 2 we have

Starting Address 3050H: 0011000001010000
Ending Address   404FH: 0100000001001111

Bold = A12

So, if we use a 1x2 decoder as in the picture, and A12 is the input, it will work fine until ending address is used. What happens when someone tries to use the ending address to store or fetch something?

[edp]

You may have an error (typo, transcription?) in your question.

Typically you would map your 4K RAM to a 4K boundary - in this case probably 0x2000.
In that case, a11-a0 will be 000000000000 when you attempt to access the first byte, 111111111111 when you read the last, and all is good.
So your first RAM would map to 0x2000-0x2FFF and second to 0x3000-0x3FFF.
In that case the logic shown in your diagram should work.

As it is, trying to use 0x2050, (you have noticed all doesn't seem well) a11-a0 will be 000001010000 when attempting to read first byte, and 000001001111 when attempting to read last byte. Bad things will happen.

[tatus1969]

you want to use A12 to select one of the two memories, when [A15 A14 A13] = [001], right?

If that is your plan, your circuit will work like that. But your address ranges are confusing me, it will be like that:
RAM1 start = 0010000000000000
RAM1 end  = 0010111111111111
RAM2 start = 0011000000000000
RAM2 end  = 0011111111111111

If your CPU reads from an invalid address, then the behavior depends on the CPU's bus interface. In most cases the data inputs are hi-z, and then the result is unpredictable. Can be all zeros, all ones, a mix, can also be the last value that was on the bus. If you need a certain value (like for example, some "BREAK" instruction, you can add some pullups or pulldowns that reflect that code.

[amyk]

Maybe they really wanted you to decode 2050-304f, in which case you would need to add a subtractor (or would that be subtract an adder...)

I've actually had to do that once, it was an expansion ROM for an existing matured system where there was enough address space but it couldn't be aligned because of existing peripherals.

[rstofer]

So what if the data range doesn't start at 0x0000 in the RAM?  As long as we eventually wrap around and fill up the first 50h bytes, everything should be fine.  But this only works if addresses are somehow constrained to 2050H .. 404FH.

Select RAM0 with A14 or (A13 and A12') => 1xx or x10
Select RAM1 with A13 and A12 -> x11

This way we use all 8K but the last 50H bytes wrap around and fill in the low 50H bytes of the low RAM.

I don't even want to think about addresses that aren't in the range of interest.  Nobody in their right mind would try something like this.

[Brumby]

Nobody in their right mind would try something like this.

Not in a practical situation - but you never know what insidious motives might drive a teacher to pose such a scenario....

[rstofer]

I have scrambled address lines when trace routing was simplified.  There is no reason that the address space needs to be used in a strictly linear fashion.  As long as addresses are unique, it doesn't make any difference to the RAM chip where you put stuff.

[MrOmnos]

Maybe they really wanted you to decode 2050-304f, in which case you would need to add a subtractor (or would that be subtract an adder...)

I've actually had to do that once, it was an expansion ROM for an existing matured system where there was enough address space but it couldn't be aligned because of existing peripherals.

So how do I account for this 50H offset?

[rstofer]

Maybe they really wanted you to decode 2050-304f, in which case you would need to add a subtractor (or would that be subtract an adder...)

I've actually had to do that once, it was an expansion ROM for an existing matured system where there was enough address space but it couldn't be aligned because of existing peripherals.

So how do I account for this 50H offset?

You don't!  The assumption being that there will never be accesses below 0x2050 or above 0x404F.  An access to 0x2050 actually addresses RAM at 0x2050 but, due to the wrap-around addressing, an access to 0x404F actually addresses 0x204F.  And, yes, an access to 0x4050 will overlap and actually access 0x2050.

Every access goes exactly where it belongs except those addresses in the 0x4xxx space which are remapped into RAM0.

But it solves the unreasonable question as long as access are limited to 0x2050..0x404F and that seems to be the game being played.

It would be worth mapping out some addresses using a pencil and paper (something I didn't do) to see where things land.

[Kilrah]

More detail about the original question is needed.

Namely, are there other devices in the probelmatic ranges e.g. between 2000 and 204F that need to be accessible correctly or not?
If not you can simplify, if yes you need to make a complex decoder that takes the exact ranges into account.