Address Decoding for Dummies! (was: SPDT Dip Switches...

From: Pete Turnbull <pete_at_dunnington.u-net.com>
Date: Sat Sep 22 19:17:30 2001

On Sep 22, 13:11, Roger Merchberger wrote:

> I did mention that I was primarily a softee-ware guy -- and when
> dealing with chips I have a tendency to think of them *as software* --
> like: if you try to write to a ROM, what happens? Nothing. (duh...)

Well, not unless you use "more interesting" voltages :-)

> I
> looked at the chip specs for the demux, and you have inputs & outputs...
In
> my mind (at first), your suggestion was "ramming 5V down an output port"
> and sometimes I have to stop & think that "those ports are just a bunch
of
> gates jammed together on a chip to serve one purpose" and doing stuff
like
> that is not a "Bad Thing (TM)." :-)


> My board isn't a "complete" board -- it's to be designed to make
> experimenting much easier by having flexible on-board address decoding,
and
> (at least for my purposes) I want "one address per switch", so I'm not
sure
> if the MUX suggestion is what I want. As of right now (but I'm still
> researching CoCo memory maps) I'm looking to have an 8K ROM socket at the
> "normal" location ($C000-DFFF) w/jumper as to whether or not it will
> auto-start (jumpering the Cart signal to the Q line) and I'm looking at
> having the address decoding for my I/O ports at $FF50-3 & $FF60-3, but if
I
> want *just* $FF51 & $FF53 to be decoded & $FF50 & $FF52 to be ignored, I
> want to be able to switch them individually.

> (Originally, my design was just going to have 1 address decoded from each
> "bank", but then I realized that if I wanted to interface "most anything"
> like a PIA, UART or a FDC that it wouldn't work.)

Let's see if I'm interpreting this correctly. I think you want to be able
to decode addresses, but sometimes you want to be able to provide (let's
say) two "enable" outputs, each active for a separate group of addresses
(maybe two different ranges of four addresses each), and sometimes you want
to be able to provide more finely selected enables (maybe responding to
only one address in each range).

I can see why you'd want to that if one day you are using a UART that needs
four addresses and another time you use a a PIO or VIA that needs 8 or 16
addresses.

A couple of ideas that come to mind are using a PROM or PAL to do the
decoding. A PAL or GAL would probably operate faster than a PROM, but it
might be easier to program a PROM (depending on how used you are to
building tables for PROMs, logic rules for PALs, and what programming tolls
you have access to).

For example, suppose you have a PROM with 8 address and 4 data outputs.
 You could fill it with data such that certain data outputs were at the
appropriate "active" level if (and only if) 6 of the address lines were in
a certain state, ie were driven with a certain address(es). By tailoring
the data appropriately, you could arrange it so that the outputs took
account of all 6 address bits, or just (say) four). The other two address
bits I'd use as a function selector: if both are low, the output is active
for a range of addresses (only 4 bits significant); if one is high, respond
to the first two addresses in the range; if the other is high, respond to
the upper part of the range; if both high, respond only to the highest
single address in the range. Or something like that, to suit the job in
hand.

Depending on the exact requirement, you might still be able to do this with
a MUX or two. A multiplexer is a very useful general-purpose logic
element, widely used as a circuit building block, not just for the obvious
"if the clock phase is high, select the refresh/video addresses; if low,
select the CPU addresses" sort of operation.

> For anyone here who does their own hardware designing, what software do
you
> use? I've tried "Protel 99 SE" and CircuitMaker 6 (student version) --
and
> a few others, and I must say that I'm not keen on most anything I've
tried
> compared to "good ol' AutoCad".

I use an assortment. Often I use the drawing package from RISC OS on one
of my Acorn machines. From time to time I've used 'pcb' on a Unix system.

> Oh, I've found a really good site to purchase all manners of circuit
board
> "stuff" w/really good prices, too:
> http://www.web-tronics.com/printed-circuit-board-supplies.html

That's encouraging. Completely home-made PCBs seem to be a relativley rare
occurrence in the US, at least compared to here. Over here, almost every
secondary school, college, and university makes PCBs and there are still
magazines publishing designs which enthusiasts photocopy onto film (OHP
acetates, aka viewgraph foils for you colonials) and then apply to
photoresist copperclad board. In the USA, as far as I can see, most people
tend to pass the artwork or plotfiles to professional PCB houses to be made
up. Lots of people do that here too (I'd probably not try to etch my own
board for a really densely packed device using PGAs, for example) but
there's still a strong tradition of using your own ferric chloride (not in
the wife's best stainless steel sink, though).

While there's nothing at all wrong with either method, I'd caution anyone
trying it, that layout software (or dry transfers) tends to be suited to
one or the other but not both. For the professional house, you are more
likely to want nice round pads and not too many different sizes. You can
use thin tracks, and pads with fairly small margins of copper round the
holes. However, for truly homemade, handetched boards, there's usually
more variation in the quality of the image transferred to the board, so
very fine tracks are not such a good idea. Moreover, they won't normally
have plated-through holes, so it's wise to use larger pads which won't come
unstuck too easily -- often oval pads for ICs, which have a relatively
large copper area yet are still narrow enough to leave a gap to get tracks
between the pins. Lots of PCB layput software isn't capable of doing
anything other than simple round (or square or symmetric octagonal) pads
and is therefore much less useful for home-etched PCBs.

No offence intended Roger, but I think your IC pads on the CoCo board are
smaller than I'd personally be happy with for a home-etched and -drilled
board without plated holes. (See
http://www.dunnington.u-net.com/tmp/coco_pcb.jpg for a modified fragment)
 BTW, did you notice the tracks going through the pins on pins 13 and 14 of
the leftmost LS244?

-- 
Pete						Peter Turnbull
						Network Manager
						University of York
Received on Sat Sep 22 2001 - 19:17:30 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:34:26 BST