Comparator as IO address decoder

[PianoMatt]

Evening everyone

I've been thinking about different ways to do the address decoding for peripherals, because my RC is getting a bit crowded. I've heard of people using comparators to decode the address lines and it makes sense. I've not tested this design because I don't have the parts, but this seems to be one way to do it on a Z80-based system. Let me see if I understand this right.

The 74HCT688 compares two 8-bit inputs and outputs an active low if both sets match. There's also an enable pin that needs to be low. If one set of inputs is connected to the address lines of the computer and the other to VCC via a DIP switch then you can basically dial in what address you want your peripheral to be enabled on. By tying the lowest three input bits to VCC you can address 64 different 3-bit windows - ideal for the ADC chip I'm using, which has the ability to read 8 different inputs. If I use MREQ as the enable line for the 688 chip then it's only ever activated when IO calls are being made.

The output of the 688 provides an active low signal, which is useful for many chips. The ADC I'm working with has to be written to to be told to make a measurement and set the input and then read to put that measurement on the data line. By using two NOR gates with one input of each tied to the 688's output and the others being connected to RD and WR you should be able to independently decode IO reads and writes to the specific address. These give active high signals, but you can use the two remaining NOR gates as inverters if you need active low.

TL;DR version - do you reckon this thing will work?

P.S. I know I missed the pull-down resistors on the DIP switches

[Mike, K8LH]

Hi Matt:

I hope to use a similar circuit for my I/O cards and to map I/O into the 64K address space on my RC2014 65C02 card.  

I came up with a design (see below) that uses two rows of jumpers to select a start address and a third row to select the size of the decoded block.  So for an 8-byte block you would jumper row 2 to row 3 in the A2, A1, and A0 columns and set the address ($00, $08, $10, $18, up to $F8) with jumpers between row 1 and row 2 in the A7-A3 columns.  A jumper in those columns is a '1' and lack of a jumper is a '0'.  This scheme may require a lot of jumpers but I thought it was a relatively simple and elegant solution for mapping even a single address into the 256 byte I/O address space.

Cheerful regards, Mike 

[Jay Cotton]

I'd have to prototype it and test it out.  But on paper it looks good.  If I get time I will build it up and let you know.

jc

[Søren Amtorp]

If you use pull-up resistors then won't the lines always get pulled to high unless you connect the line to ground?  I mean that is what pull-up resistors is there for? 

[Eric Matecki]

I suggested using a '688 for this purpose some time ago in another thread.

I didn't have time to test it, but there is no reason it won't work, if you fix these issues :

- check if M1 is high : tie M1 to P0, R0 is already tieded to high.

- the resistors are pull-DOWN, obviously.

A personal choice is to replace the dip-switches and pull-down with 'three way' jumpers.

I don't change address often, and without pull-downs it will use less power.

[PianoMatt]

Is there a reason I'd need to use the M1 signal?

[PianoMatt]

Mike, could you share the schematic for how that works? Being able to change the window size with jumpers is a cool idea

[Mike, K8LH]

No schematic, yet, Matt.  Sorry.  Perhaps the drawing below will help, a little?  The third row is connected to the address line ('688 Pn line) associated with that column.

Cheerful regards, Mike

[Mike, K8LH]

Basically, when you place a jumper on row 2 and 3 in a particular column, you're feeding both the 'P' and the 'Q' inputs with the address line associated with that column.

I'm really terrible at explaining things.  

[Mike, K8LH]

A couple quick jumper configuration examples using my 3 row jumper design...

[Eric Matecki]

Le vendredi 14 juillet 2017 13:04:58 UTC+2, PianoMatt a écrit :

Is there a reason I'd need to use the M1 signal?

IOReq and M1 low at the same is an interrupt acknowledge, not and I/O operation.

See the Z80 datasheet here : http://www.zilog.com/docs/z80/UM0080.pdf

At page 12 (26 in the pdf) you'll find the explanation.

[PianoMatt]

So as I understand it I'd only have to use the M1 signal if I want to use interrupts with the device I'm decoding. Is that right?

[Eric Matecki]

No, as soon as one device uses interrupt, the acknowledge sequence will take place.

Unless you design all your modules to not use interrupts, and are the only one to use them, you must check M1 because you never know what modules other users will use beside yours.

To be absolutely exact, it depends on the interrupt mode used.

I *think* in mode 1 this does not take place, but I'm still learning the subtleties of the Z80...

Read the datasheet starting page 17(30).

[PianoMatt]

I was under the impression that under Mode 1 there's no interrupt acknowledge, but I don't know for certain. The easiest way would be to test it using a logic analyser and Dr Baker's single stepper board.

I can put all of this speculation to bed tomorrow anyway - the chips arrived.

[Eric Matecki]

I was under the impression that under Mode 1 there's no interrupt acknowledge, but I don't know for certain.

Same for me, i *think* there is none, but not totally sure. 

But now that we have an "official" SIO/2 board, it's just a matter of a few month (maybe less) until mode 2 is used on the RC2014.

Well, not sure either, now that I think more about it, there is no provision for the interrupt priority daisy-chain on either backplane...

Anyway, there are three unused bits on the '866, why not use one of them for M1 and be future proof ?

[PianoMatt]

Yeah I've modified the design to send M1 to one of the unused lines. I'm not 100% sure if it matters for devices that aren't using interrupts. Even if Mode 2 is in use the original design wouldn't interfere. Once I get it hooked up I'll have a look with my logic analyser (if the software will work anyway)

[Mike, K8LH]

Slightly off topic, but...  qualifying memory access with the /M1 signal on my RAM/ROM board design probably isn't a bad idea, yes, no?

[Eric Matecki]

My understanding is that MReq is enough for memory.

M1 indicates it's the op-code fetch of an instruction, and you certainly want to read it from memory !

Again, there are people here who are better qualified for the 'definitive' answer.

I too am learning, and my prototype board isn't working right now, so I don't understand everything either ...

[Eric Matecki]

Le samedi 15 juillet 2017 17:59:40 UTC+2, PianoMatt a écrit :

Yeah I've modified the design to send M1 to one of the unused lines. I'm not 100% sure if it matters for devices that aren't using interrupts. Even if Mode 2 is in use the original design wouldn't interfere. Once I get it hooked up I'll have a look with my logic analyser (if the software will work anyway)

I think it *will* interfere.

When a mode 2 interrupt occurs, the CPU will send the acknowledge on the bus, and the device responds.

If by chance the address matches your board, it will take the response from the device as data... certainly not what you wanted !

[PianoMatt]

The vector is placed on the data bus though, not the address bus. As far as I can see the address bus doesn't matter during an interrupt acknowledge cycle.

[Eric Matecki]

Yes, but there will be "something" on it, even if it is three-stated.

And that something can match (will match according to Murphy) one of the addresses of your board,

while the interrupting device will try to put its vector on the databus, and your board will put something else on the data bus because it sees a 'read'.

Chaos ! Crash ! 

[PianoMatt]

According to the diagram on page 13 (pdf 27) the read line never goes low during an interrupt acknowledge cycle, so not all of the conditions would be met for a decode. Only if the read line goes low does the chip being addressed put anything on the data bus.

[Eric Matecki]

Somewhere must lie the explanation why everybody uses M1 in address decoding...

But it may not be justified in every case, just intellectual lazyness ...

So remove M1 again and prove it works without it, at least in some cases.

[PianoMatt]

I'm going to use M1 in the decoding scheme because it's what everyone else does. It does no harm and doesn't make the circuit any more or less complex so I've got no issue doing it, I just don't like not fully understanding something before I commit it to a PCB

[Jay Cotton]

Just got some of these chips.  WIll bread board a circuit and report back...

[PianoMatt]

Got some coming in today from Mouser. Race you? ;)

[PianoMatt]

It works! I've got it working on a breadboard and it decodes reliably at all of the addresses I've tested. I've attached my updated schematic if anyone wants to use it.

[Mike, K8LH]

Congrats', Matt.

Since you've got that on a breadboard, any way I con talk you into connecting the P0-P2 and Q0-Q2 inputs together along with the A0-A2 address lines just to confirm that would work for my circuit (where I have 'size' jumpers)?  I don't have a 74HC688 on hand to test yet...

Cheerful regards, Mike

[Thomas Riesen]

Very nice Matt

But why do you mix LS and HC 74er types?

Thomas

[PianoMatt]

I tested it with 1, 2, 3 and 4 inputs tied high and it worked fine.

[PianoMatt]

Looks like I need to update my schematic. Good spot.

[Scott Lawrence]

Oh yeah? Well I can do it with just one chip!  (well, a CPLD... And I say i can do it, it's all theoretically... I've never actually worked with a CPLD.  Actually, now that I think about it, I could probably do it with one really specifically crafted EPROM to work as a logic decoder... ;)

Seriously though, I've been totally loving reading through this thread... THIS is exactly why I love this hobby! :D

Y'all are awesome!

-s

On Mon, Jul 24, 2017 at 4:31 AM, PianoMatt <mattyb...@gmail.com> wrote:

Looks like I need to update my schematic. Good spot.

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+unsubscribe@googlegroups.com.
To post to this group, send an email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/3df12e9b-c1eb-4f4a-85d3-caa00aa59d75%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Scott Lawrence
yor...@gmail.com

[PianoMatt]

Be careful using an PROM as decoding logic. There was a popular mod for the C64 to replace the glue logic chip with one, but if it goes bad or is mis-programmed you can end up creating paths that should never be connected.

PAL and GAL chips are absolutely ideal for address decoding and glue logic, but they're also fiddly.

On Monday, 24 July 2017 14:38:20 UTC+1, Scott Lawrence wrote:

Oh yeah? Well I can do it with just one chip!  (well, a CPLD... And I say i can do it, it's all theoretically... I've never actually worked with a CPLD.  Actually, now that I think about it, I could probably do it with one really specifically crafted EPROM to work as a logic decoder... ;)

Seriously though, I've been totally loving reading through this thread... THIS is exactly why I love this hobby! :D

Y'all are awesome!

-s

On Mon, Jul 24, 2017 at 4:31 AM, PianoMatt wrote:

Looks like I need to update my schematic. Good spot.

--

Scott Lawrence
yor...@gmail.com

[Eric Matecki]

Still thinking about this for my own boards (using a '688 as address decoder)...

@Mike

At first I found your idea very clever for setting the size with jumpers.

But now I can't see any practical use for it.

I mean, the size depends on what peripherals I put on the board, and is fixed for a given board.

So I can spare some of the jumpers and route directly the pins for the needed size (all to ground, not to A0..Ax). And use only two rows of pins for the address jumpers. Saves space on the board and prevents errors.

This will also remove the pull-downs from the low address lines (which are introduced by the jumpers in the 'size' position), which will reduce the load on these pins from the Z80.

But I will probably build a 'proto board' with your full design, because I still find it the most flexible address decoding I have seen until now, and flexibility is great for prototyping.

Just not on 'production' boards.

@Matt

I would route M1 to only one input of the '688, to avoid overloading the M1 output of the Z80 when many boards are used.

(I don't know the 'fan out' limit of the Z80 (I know, it's CMOS, and fan-out is a concept from the TTL world...), but less load is always better)

[PianoMatt]

That opens up a whole can of worms...how many gates can the Z80 signal lines drive?

[Thomas Riesen]

Matt,

Do you provide the KiCAD schematic file?

Thomas

Am Montag, 24. Juli 2017 00:05:08 UTC+2 schrieb PianoMatt:

[PianoMatt]

I can do, I'll post when I get home. Don't get too excited, the layout is horrible!

[PianoMatt]

There's that KiCAD project. The Schematic is in there as well as the layout I did the other night. Just rename the extension back to zip

[Peter Fielden-Weston]

PianoMatt,

I've just had a look at your KiCAD project. It looks very good. I think I'll steal the comparator addressing side for my projects. :) With your permission of course.

Peter

[PianoMatt]

It's there to be shared. I have no issue with people using it. I'm going to share the board on OSHPark too when I tweak the layout if anyone wants an ADC board.

[Thomas Riesen]

PianoMatt,

Thank you for sharing, great!!

Thomas

Am Donnerstag, 27. Juli 2017 23:07:33 UTC+2 schrieb PianoMatt:

[PianoMatt]

I changed the project to only route M1 to one input on the '688, and used Spencer's template for the PCB layout. I'm looking forward to receiving the board and seeing if it actually works!