I know this is going to be heavily dependent on the chips used, clock speed etc, but I wonder if the greybeards here have any rule of thumb about how many layers of decoding one can allow? Or, to put it another way, how many propagation delays.

My current design uses a 74HC138 to decode an 8K region of the map into eight 1K sections. One of the inputs to this already goes through an inverter – the others are direct from the address lines.

But I'd like to split up some of those areas further. I have a vague for how I might do it, but it would involve a couple of the signals coming from the 138 going through a NOR gate and then another 138. So that's four layers in total. And there might be a fifth, but I'm saving that for another question.

This is 1MHz 65C02 project. Is that too many layers?

(I know a diagram might explain it better – I'm working on that.)

_________________
I like it when things smoke.
Blog – Zolatron 64 project

It might be worth a look at the BBC Micro's decoding - that uses 138s, runs at 2MHz, and has a relatively fine-grained decoding for I/O.
See https://tobylobster.github.io/mos/mos/S-s25.html for example.

I think you just answered your own question. I'm not aware of any Rule Of Thumb, and to me the idea seems silly... because such a rule would have to contain baked-in assumptions about the chips used, clock speed etc.

Two comments, though. #1: It's a common tendency for some hobbyists, particularly novices, to concoct overly-elaborate decoding specifications. That is, the memory map could be simplified but isn't. But that's fairly harmless, although arguably not the best way to direct one's effort.

#2: On the bright side, even a deeply multi-layered logic scheme may be viable, speed-wise, if you use 74AHC series logic.

Yes. It'll be good to see what you have in mind.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

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

In general, I agree, but we should note that it's a 1MHz design that's being discussed. I'm tempted to say that'll impose very little by way of difficult constraints, although the usual advice about having a clean clock and adequate decoupling will apply.

Thanks for all the input (pun intended).

I'm aware of the newbie trap of wanting too much granularity in the memory map. For the Mk.I version of my machine, I have eight 1K sections mapped for I/O, which is plenty.

But as this whole project is about learning, I just wanted to find out how one might increase the number of addressible slots. My approach with the Zolatron is to attempt to work stuff out for myself first, as an intellectual exercise, before giving up and calling on the wisdom of experience here.

And so what I came up with was what you see in the attached image. That gives 16 256-byte slots in the top 4K of the 8K I'd reserved for I/O.

I'm not sure about the need for the PHI2 signals. I already have clock-qualified 'read enable' and 'write enable' signals in my design. I figured I might be able to just tie the connections marked PHI2 here via pullups.

_________________
I like it when things smoke.
Blog – Zolatron 64 project

Alright -- I assume you mean something like this; am that right?

It will depend on the devices you intend to activate. For example, in the case of a 6522 VIA, the Chip Select signal you send it must not be qualified by Phi2. (It and other 65xx peripherals have a Phi2 input pin, and they manage clocking internally.) But for some other devices the Chip Select signal you send it does need to be qualified by Phi2. An example would be if you wanted to use a 74_374 or '574 as an output port you can write to.

So, in the diagram you should let us know what devices get activated by the various select lines.

I have not closely analyzed your diagram (reproduced below) but my first question is, what else is in the memory map? Specifically memory, I mean. You need to ensure that memory is not activated simultaneously with I/O. You haven't shown us enough of the schematic to determine if that's the case. But let's ignore that for now.

Except for the issues noted, the upper half of your diagram looks reasonable. I haven't had my second coffee yet but to me it appears to decode 8 regions in the space from $B800 to $BFFF.

The lower half of your diagram needs a re-think. The signal to pin 6 of the '138 will go high if A14 is low OR if A11 is low (or both). That's unexpected, because the usual policy for decoding a device select is to require that the required state for one address line gets ANDed (not ORed) with the required state for the other address lines. I hope I've explained that in a way that makes some kind of sense!

Edit: here's a different take. You've labeled the Y0 output on U4 as "$B000." In other words, A14 and A11 both low. But that output will also go low for the region starting at $B800 (A14 low, A11 high) and the region starting at $F000 (A14 high, A11 low).

Right... and it's back to the drawing board for you! We'll look forward to seeing what you come up with!

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

You’re right. Looks like I need to replace that NAND with a NOR.

As for the clock qualification stuff - things aren’t that advanced yet. I’m just working out the logic of decoding these addresses as an exercise in itself. What I actually DO with them is ‘reserved for future expansion’.

_________________
I like it when things smoke.
Blog – Zolatron 64 project

This is the version with the NOR gate.

The memory map is:
$0000-7FFF 32K RAM
$8000-9FFF 8K optional ROM/RAM (more of that in a future question).
$A000-BFFF 8K I/O block. Originally as 8 x 1K blocks, but the upper 4K could be replaced with the scheme I'm talking about here.
$C000-FFFF 16K ROM

_________________
I like it when things smoke.
Blog – Zolatron 64 project

Have you thought of using programable logic?

Something like a GAL (or more modern equivalent) will allow you to put together arbitrarily complex decoding schemes (within the ability of the chosen chip) and offer a short propagation delay, often faster than a single 74AHC138. I use NOS or previously used Lattice GALs that have delays as low as 7ns. I know a lot folks bridle at this suggestion as these chips are no longer manufactured, but they are readily available nonetheless and I don't ever pan to go into mass production of my personal toys. eBay is my usual source. Microchip still manufacture functional equivalents of the Lattice chips.

If you ever do design a marketable product these days PLDs will likely be incorporated. So, as this is a learning exercise, it might be a good path to take to use some form of PLD as a part of that process. There are lots of other advantages over the lessons learned too, such as faster decode, reduced chip count, lower power consumption, additional 'glue' logic, flexibility in PCB layout, ability to make logic changes after the boards have been produced, etc..

Just a thought. As for me, to borrow the words of a little old lady - I put that s#!t in everything.

_________________
Bill

A couple of observations which might be helpful:

1. You will get lower propagation delays (and so your system will work at higher clock rates) if you put the PHI2 signal into the active high enable of the 138 (as you have done for U3). This is because the address becomes valid some time before the rising edge of PHI2, so the propagation of the address through the gates happens during the time interval between address valid and PHI2 high. If you put PHI2 on a gate, it has to propagate through that gate before reaching the 138.

2. It might be an idea to have one of the 138's gated with PHI2 and the other not gated with PHI2. If you use 68xx or 65xx peripheral devices, their chip selects mustn't be gated with PHI2 since they understand the the 6502 bus cycle and expect the address lines, R/W line and chip selects to become valid/active while PHI2 is low.

Actually, yes. But that’s another learning curve I’m scrambling up at the moment. I haven’t been able to decide which chip family to use for learning. Any suggestions?

_________________
I like it when things smoke.
Blog – Zolatron 64 project

Very useful - thanks.

_________________
I like it when things smoke.
Blog – Zolatron 64 project

I use NOS or used Lattice GAL devices. They seem to be fairly plentiful and I regularly find them in the 7ns type. Last time I d did find them I bought large amount. They are also supported by alost any cheap programmer out there.

Microchip offer quite a range of more modern devices that include the functionality of the Lattice devices and a whole lot more if you need more. You might have took a bit harder for and pay a tad more for a programmer that will program them.

https://www.microchip.com/en-us/products/fpgas-and-plds/spld-cplds

_________________
Bill