Hi,
I have a question about Address Decoding, what is the best way?
I was under the impression that a simple 3-to-8 line decoder chip tied to A13, A14 and A15 woulld suffice. (from: http://www.geocities.com/SiliconValley/ ... rj1pic.htm) I have now been informed that, this method is prone to problems.
What other methods are there? and Could you explain how they work?
(I'm brand new to this)

Thanks,
Dan

_________________
---
iMac therefore I am.

Hello Daniel,

There are many ways to implement Address Decoding with the
65xx family. The '138' decoder just might be the most popular of
the implementations.
I would like to suggest looking for a couple of used books which
can help you debunk some of the myths about address decoding
and other not so obvious hardware arrangements that you sometimes see when looking at 65xx designs.
They are :

'Programming & Interfacing the 6502 with experiments'
by Marvin L. DeJong
Blacksburg press, 1980
ISBN 79-67130

' Introduction to 6800/68000 MicroProcessors'
by Frederick F. Driscoll
PWS Publishers, 1987
ISBN 0-534-07692-0

- Although this book is targeted at the 6800/68000 the 6800 is
close enough to the 6502 that it is still relevant. This book also
gives an excellent explanation as to why we gate Phase2 with
R/W. ( Which you will see alot )

And Lastly :

' MicroProcessor Systems Engineering '
by R.C.Camp, T.A.Smay, C.J.Triska
Matrix Publishers, 1978
ISBN 0-916460-26-6

- Believe it or not this book is readily availible through Used_Book
networks. It treats the 8080,6800 & 6502. And does an
engineering review of the AIM-65 by Rockwell which used to be
a popular development platform for the 6502.

Although I would suggest getting all them, any one of these will
answer your present & future questions. Plus you will have a tangible reference.

Try looking for these through www.alibris.com, I have had very
good luck with them, with NO problems.

Good Luck & Stay with it !

-Wally

Thanks for that, I am starting to get a nice list of reference books to aquire, the only problem is that there is a distinct lack of used book stores here...actually, come to think of it, we only have book store here! and it is all new stuff, rows of shiny and expensive ones!
However, having just said that, there is allways somewhere they can be found.

Anyone else got any suggestions for memory decoding?

Dan

_________________
---
iMac therefore I am.

Dan,

How you decode can depend a lot upon what and how many devices you want.

I use an 8-input NAND gate and two 2-input NAND gates to decode my system. I use an inverted A15 (one 2-in NAND) for the EEPROM 32k from $8000-$FFFF. I also send the inverted A15 to the 8-in NAND along with A8-A14. This decodes page $7Fxx for I/O with an Active Low signal. I then send the output of the inverted A15 and the output of the 8-in NAND to the other 2-in NAND to decode the RAM. 32K (minus 1 page) from $0000-$7EFF. This gives a single gate delay for the EEPROM (the slowest device), two gate delays for the I/O, and three gate delays for the RAM (which is the fastest device).

Depending on your I/O, you can use these signals plus address lines A4-A7 to decode your I/O. I chose to add a 74LS138 to decode eight 16-byte blocks to allow for several 65C22's and/or 65C51's.

If you want a fast page decoder, the a 74HC688 8 bit comparator can be used. The bonus here is you can use DIP switches to select the page address without having re-wire anything. The down side is that it is a 20 pin package (if board space is an issue).

Another method I've seen is to use PAL/GAL's to do all of the device/memory decoding. These offer small propagation delays (6-10ns) and can be re-programmed to change mappings. The down side is that you'll need a way to program these devices, increasing expense. This is the method I would use if I had a programmer.

If you want high speed access to your 65XX I/O chips, then I've seen some decoded in part of page Zero. This allows the 6502 software to use zero page addressing modes which are much faster than the absolute addressing modes.

So many choices, so many successful solutions!

Hope this helps.

Daryl

Hi Everyone,

Don't forget the 74LS139. Quite handy.

Cheers,

Paul

I E-mailed this info to Dan, but here it is for everyone's benefit. My workbench computer has 32KB of EPROM, 16KB of RAM (using half a 32Kx8), 3 65c22's and 3 65c51's. The extremely simple and fast address decoding scheme leaves room for 4 more similar I/O ICs. The diagram is posted at http://www.6502.org/users/garth/project ... chematic=2

The inverter here is a Schmitt-trigger type only because it's in the same IC where I wanted one of the other inverters in the computer to be Schmitt trigger. Actually you could replace that one with another NAND (connecting the inputs together) and do the entire decoding in a single 74AC00 or 74HC00 and still have one gate left over. The inverter that points off to the left is extra, so ignore it. I scrapped whatever plan I had for that one, and now I can't even remember what it was. Its output is not connected.

The (E)EPROM may be the slowest device, but does not need to be gated by phase 2 like RAM should, since the computer will only be reading it, not writing to it. That gives a benefit because the address lines come valid before phase 2 goes up. In the diagram referred to above, the delay from phase 2 rising edge to RAM select, as well as the delay from A15 valid to ROM select, is only 8ns/15ns typ/max with a 74HC00, or 4ns/6ns with a 74AC00. Compare that to 28ns/35ns for a 74HC138 and 27ns/41ns for 74LS138, according to my data books. If you only want to run at 1MHz, none of these is enough delay to matter; but if you want to pour on the coal, you'll have to start paying attention to propagation delays. (BTW, my first home-made computer did use a '138.)

Make sure the CS and CS\ for the 6522's and 6551's are valid before phase 2 rises, or these ICs won't work.

The 74HC688 Daryl mentioned is a nice IC, and fast considering what it does. An alternate number for the same thing is 74HC521.

Garth

I'm not sure what PAL/GALs are but since you mention a programmer it makes me wonder, could I use a PIC Chip to decode?
Currently I am looking for any option.

I only have two options so far, the 3 to 8 decoder and a series of NAND gates. I may be doing it all wrong but as far as I can tell, if I went with the NAND option then I would need a new set of address decoders for each chip/device, and I don't like that prospect.

Dan

_________________
---
iMac therefore I am.

Dan,

A PAL/GAL is a set of flipflops gated by an array of programmable inputs which allow for a "custom" truth table to be generated for each output, based on any combination of input and/or output logic levels. Datasheets are available from the Jameco.com web site. Do a search on "16V8" and choose a part from the list.

I have already created the JEDEC map file for a 20 pin 16V8 device that will decode my 32K RAM, 32K ROM, 2 65C22's and 2 65C51's. All I need now is a programmer.... The address map looks like this:

0000-000F - CIA0
0010-001F - CIA1 or VIA2
0020-002F - VIA0
0030-003F - VIA1
0040-7FFF - RAM
8000-FFFF - ROM

This will put my I/O in the first 64 bytes of zero page to allow faster access. I plan on placing a slower speed I/O bus behind one of the VIA's, similar to Garth Wilson's descriptions found in other topics.

I don't think a PIC microcontroller is suitable as an address decoder simply because it couldn't respond fast enough to the changing states of the 6502 address bus.

Daryl

Programmable logic opens up some nice possibilities, but may be beyond the beginner. I have found that with a little creativity to do the non-obvious with off-the-shelf standard logic ICs, I have had little need for programmable logic.

Putting the I/O in ZP like Daryl mentioned is nice prospect that I seriously considered for my next workbench computer. Without looking back at my notes right now, I think the reason I decided against it may have partly been because the propagation delays compared to simpler logic would have been long enough to force me to slow the clock down, nullifying the performance gain.

A PIC would be far too slow. PIC performance is not what Microchip would have you think. PICs are a nice solution for several problems; but their decrepit processor core is the only thing I absolutely hate about them. What some people have done in place of programmable logic (for combinatorial logic only-- no registered functions or state machines) is to use an EPROM. The address inputs become the logic inputs, and the 8 data outputs become the logic outputs. It's kind of slow at generally 70ns min (or 55ns if you can find the faster ones), but still quite a bit faster than one Dan showed me yesterday where someone had a 74LS138 followed by a 74LS154 followed by three more 74LS00 logic levels.

> I may be doing it all wrong but as far as I can tell, if I went with the
> NAND option then I would need a new set of address decoders for each
> chip/device, and I don't like that prospect.

No, actually the entire address-decoding circuit is in the sketch I gave the link to. There are no hidden address decoders and no hidden logic. It's very fast and simple. The only discreet logic ICs on my workbench computer (shown at http://www.6502.org/users/garth/projects.php?project=1) are a 74AC00, '14, and '74. Only one gate of the '14 is used in address decoding (and that one could be transferred to the '00 anyway), and one of the flip-flops in the '74 is used to get around the 6522 shift register bug that shows up when using an external clock that's not sync'ed with phase 2. About half of these three ICs remains unused. Four of the small ICs you may be able to see on the board are A/D and D/A converters and line drivers and receivers for RS-232. The pictures, BTW, are outdated now. I've added quite a lot to the computer since they were taken.

Garth