Address decoding upgrade with 74HC139

[AndersNielsen]

I'm not super happy with my result here as I don't actually manage to "save" a whole IC but only manage to gain two logic gates, some RAM address space and to make sure my output only register doesn't write on read.

Memory map:
$0000-5FFF: RAM (OE is activated with ~RAMOE)
$6000-7FFF: 6522 VIA (Selected with ~IO_SEL)
$7000-7FFF when ~RW low: Output only register - selected with ~LDCTRL (74xx273).

$8000-FFFF: ROM

Will this work as intended? Can I slim down the address space for the 6522 VIA even further with the '139(maybe by throwing one of my saved OR gates at it)? Or another single decoder?

[gfoot]

~RAMOE will be active (low) for the ROM address range (A15 high) as well as for the RAM address range you quoted above. That may be OK so long as you're also gating the RAM's CS line with A15. Writes to the whole range of low addresses will then go to RAM. Note that writes also need to be gated with PHI2 at some point, so you never write data when PHI2 is low.

The setup of the bottom unit doesn't seem quite right though. As it stands, when A12 is high ($7000-$7FFF), or during a write operation (or when A15 is high, or either A13 or A14 is low), O1 will remain high, and so ~LDCTRL will be high and ~IO_SEL will be low. If A12 is low and it's a read operation, then ~LDCTRL will go low, and ~IO_SEL will go high. It feels unlikely that this is what you wanted as it looks like your write-only register will only be selected on reads, and it's not clear whether the VIA might be selected for too many addresses (~IO_SEL is exactly the inverse of ~LDCTRL so it'll be active for most of the address map). So a lot depends on what is being used to activate the VIA's other chip select input.

[AndersNielsen]

gfoot wrote:

~RAMOE will be active (low) for the ROM address range (A15 high) as well as for the RAM address range you quoted above. That may be OK so long as you're also gating the RAM's CS line with A15. Writes to the whole range of low addresses will then go to RAM. Note that writes also need to be gated with PHI2 at some point, so you never write data when PHI2 is low.

Ouch! Missed that ~RAMOE will also be active when A15 is high. I have WE gated though.

gfoot wrote:

The setup of the bottom unit doesn't seem quite right though. As it stands, when A12 is high ($7000-$7FFF), or during a write operation (or when A15 is high, or either A13 or A14 is low), O1 will remain high, and so ~LDCTRL will be high and ~IO_SEL will be low. If A12 is low and it's a read operation, then ~LDCTRL will go low, and ~IO_SEL will go high. It feels unlikely that this is what you wanted as it looks like your write-only register will only be selected on reads, and it's not clear whether the VIA might be selected for too many addresses (~IO_SEL is exactly the inverse of ~LDCTRL so it'll be active for most of the address map). So a lot depends on what is being used to activate the VIA's other chip select input.

I have A0 and A1 swapped XD

Attached update - that should be more like what I intended, but cost another gate since I can't gate RAM CS with A15... Or "maybe" I can - I'm a bit fuzzy on that. I'll have to pass A15 through my tristate buffer as well and have a pulldown on it as well as the other lines.. I think..?

[gfoot]

AndersNielsen wrote:

Attached update - that should be more like what I intended, but cost another gate since I can't gate RAM CS with A15... Or "maybe" I can - I'm a bit fuzzy on that. I'll have to pass A15 through my tristate buffer as well and have a pulldown on it as well as the other lines.. I think..?

Hmm. You'd need the RAM's chip select active whenever phi2 is low (for the video side to read from it) and also when phi2 is high so long as A15 is also low. Then the RAM's ~WE is only low if RWB is low while phi2 is high.

To be clear, I think your first diagram still has this problem - the RAM will have its WE enabled whenever the CPU is writing to something, and writing to $8000 will cause writes to $0000.

In fact you probably want to delay WE bit beyond the start of phi2, because at the point phi2 goes high, you enable those transceivers and start giving the RAM a new address to be written to; you need a little time to let that settle before the RAM actually starts writing, otherwise it can corrupt other unrelated addresses. I think we discussed that a bit recently elsewhere!

Another point is that you ought to provide some definite signal to U11 pin 9 - it's an input pin on a CMOS IC, so even if you don't care what value it passes through, you need to pull it one way or the other. Connecting it to pin 8 or pin 10 would be an easy fix.

For the second diagram, ~IO_SEL is still the inverse of ~LDCTRL - so one or the other is always active. Writes to $7000-$7FFF will set ~LDCTRL low; and any other operation (any read, or a write to a different address range, including ROM) will set ~IO_SEL. So the way you've set the other 6522 pin becomes pretty important there.

[AndersNielsen]

gfoot wrote:

AndersNielsen wrote:

Attached update - that should be more like what I intended, but cost another gate since I can't gate RAM CS with A15... Or "maybe" I can - I'm a bit fuzzy on that. I'll have to pass A15 through my tristate buffer as well and have a pulldown on it as well as the other lines.. I think..?

Hmm. You'd need the RAM's chip select active whenever phi2 is low (for the video side to read from it) and also when phi2 is high so long as A15 is also low. Then the RAM's ~WE is only low if RWB is low while phi2 is high.
To be clear, I think your first diagram still has this problem - the RAM will have its WE enabled whenever the CPU is writing to something, and writing to $8000 will cause writes to $0000.
In fact you probably want to delay WE bit beyond the start of phi2, because at the point phi2 goes high, you enable those transceivers and start giving the RAM a new address to be written to; you need a little time to let that settle before the RAM actually starts writing, otherwise it can corrupt other unrelated addresses. I think we discussed that a bit recently elsewhere!

Correct - that's not unintentional. I'm aware writing to $8000 will also write to RAM and I don't really mind the compromise.
RAM's OE is low when Ø1(B indicates "buffered" and is Ø0 inverted through an and gate) is low while ~RW is LOW. The two gates phi2 goes through before reaching ~WE is ok.

gfoot wrote:

Another point is that you ought to provide some definite signal to U11 pin 9 - it's an input pin on a CMOS IC, so even if you don't care what value it passes through, you need to pull it one way or the other. Connecting it to pin 8 or pin 10 would be an easy fix.
For the second diagram, ~IO_SEL is still the inverse of ~LDCTRL - so one or the other is always active. Writes to $7000-$7FFF will set ~LDCTRL low; and any other operation (any read, or a write to a different address range, including ROM) will set ~IO_SEL. So the way you've set the other 6522 pin becomes pretty important there.

Also correct, sadly. If I run A15 through the '245 and put a pulldown resistor on the other side like A11-A14 for when it floats, I should be able to use it to disable the RAM when reading ROM/phi2 is low. And also ensure a defined state.
I'm afraid it's too slow though.

I guess it's time to dig through some address decoding examples as what I intended isn't as easy as it seemed.

[AndersNielsen]

I managed to pull together two other options that should do a bit of what I intended.
Top one should leave only one page for I/O, half for the output register, half for the VIA. Rest for ROM and RAM.
Bottom takes $1000 for each I/O and the rest for RAM and ROM.

I have to admit I feel a bit like swapping the 74hc273 for a '373(edit: Oh! I though there was a FF with a clock and a CE - but I see the 373 just had tristate outputs.. hmm) and calling it a day - leaving some empty address space for expansion is also part of the general idea, so is a bit much to allocate all the address space without an easy way to swap something in or out.

[BigDumbDinosaur]

Could you please post those schematics in monochrome?

[AndersNielsen]

BigDumbDinosaur wrote:

Could you please post those schematics in monochrome?

Sure!

[AndersNielsen]

Mmmkay. A 373 did not do what I want but I see a '377 should do the trick. Octal register with a clock enable - easily swapped in.
I wonder if I can just put ~RW on the enable line and address decoding on the clock pin.. (If it will latch if ~RW is shorter than the address decoding).. Datasheet time.

Edit: Might work if I swap clock and ~enable and put the address logic on the enable - looks like it must be enable before latch. That also seems to mean I might have to qualify with phi2.. And then it might be a better idea to simply gate the clock with the ~RW signal. Oh well. No free lunch.

[AndersNielsen]

I think I actually made it work with just the inverters I already have on the board and a single NAND IC.

I also tested running the RAM CS with the buffered A15 and that works perfectly with a reasonably fast pulldown.
On the RAM side I also added a few jumper resistors - desoldering a resistor to swap out some RAM seems reasonable.

0-5FFF: RAM
6000-6FFF: 6522 VIA
7000-7FFF: '273 register
8000-FFFF: ROM

Did I mess it up again? Any obvious optimizations?

[gfoot]

It looks right to me now. Quite deep chains of gates - and in a few places you could use OR instead of NAND and get rid of quite a lot of inverters.

I still worry about the RAM's ~WE being triggered too soon after the address transceivers activate. I try to limit it to the second half of phase 2.

[AndersNielsen]

gfoot wrote:

It looks right to me now. Quite deep chains of gates - and in a few places you could use OR instead of NAND and get rid of quite a lot of inverters.

I still worry about the RAM's ~WE being triggered too soon after the address transceivers activate. I try to limit it to the second half of phase 2.

It is a bit more messy than I would've liked. The inverters were left over from my reset circuit so in a sense they were "free" - I have a feeling the '273 is the first to go in the future. I can almost squeeze in a second 6522 instead - or maybe a PSG.

I did have trouble with phi2 and ~WE previously but that's certainly a thing of the past now - though you do make me nervous enough to bring out the scope.
I seem to remember using phi0 for the transceivers works in my favor instead of phi2 (which is delayed quite a bit). Also - this build won't go faster than 2MHz so that helps too. I always end up staring at Dr. Jeffyls GIF's a few minutes..
https://laughtonelectronics.com/Arcana/ ... iming.html

[gfoot]

AndersNielsen wrote:

I did have trouble with phi2 and ~WE previously but that's certainly a thing of the past now - though you do make me nervous enough to bring out the scope.

The thing to watch out for is random RAM corruption - I used to test for this by filling RAM with a coherent pattern, then executing a loop writing intensively to a small portion of the RAM, then going back and verifying the rest of the RAM was unaffected.

Quote:

I seem to remember using phi0 for the transceivers works in my favor instead of phi2 (which is delayed quite a bit).

Yes, definitely use the input one if you need something prompt - note that WDC changed the names of the pins for the 65C02, so what was known as "phi0" is now called "phi2", and they don't recommend using the other two pins at all.

[Michael]

I wonder if a decoder method using a 'magnitude comparator' IC might be of use? Here's an untested method that comes close to your memory map and I/O requirements. While the method is meant to use a 64K or 128K RAM IC to provide much more than 32K of RAM, you could use a 32K RAM IC for your memory map along with one of those spare inverter gates for the active low chip select.

Stay safe. Have fun. Cheerful regards, Mike, K8LH

[gfoot]

Michael wrote:

I wonder if a decoder method using a 'magnitude comparator' IC might be of use? Here's an untested method that comes close to your memory map and I/O requirements.

That's really neat. The part seems on the expensive side, but there seem to be cheaper options with fewer inputs that would work in a lot of cases.