Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ucsd!swrinde!zaphod.mps.ohio-state.edu!ncar!umigw!mthvax!wb8foz
From: wb8foz@mthvax.cs.miami.edu (David Lesher)
Newsgroups: sci.electronics
Subject: Re: Address decoding circuitry
Message-ID: <1990Oct9.214649.6258@mthvax.cs.miami.edu>
Date: 9 Oct 90 21:46:49 GMT
References: <1115@cameron.egr.duke.edu>
Reply-To: wb8foz@mthvax.cs.miami.edu (David Lesher)
Distribution: usa
Organization: NRK Clinic for habitual NetNews Abusers
Lines: 25

I once built a decoder out of a 256k EPROM. This case would not be that
big, but here is the idea. Use the data lines for output, and the
address lines for input. Burn the PROM such that when the desired
address is input, the appropriate output line is {high, low}. When the
second address is input, the next output line is..... etc. This proved
to save lots of chips in this specific case.

In my case, several address lines were mode selectors, and the rest
came from a difference counter that indicated how much {available}
memory was left in a large data buffer. The outputs were various levels
of panic (empty, >10%, =50%, >50%, >95%, and OH_SHIT--Data lost) for
other systems to respond to.

It was a bit of pain to come up with an input file to feed to the
Data_I/O burner. I used a large mainframe editor, and wrote 64k lines
of "db_xxxxH" statements. In my case there were only 5 or 6 different
kinds of lines, so I used LOTS of linecopy commands.  It took the
Perkins-Elmer that had the 232 line to the burner forty minutes each
time I ran the 8080 cross-assembler.

-- 
A host is a host from coast to coast.....wb8foz@mthvax.cs.miami.edu 
& no one will talk to a host that's close............(305) 255-RTFM
Unless the host (that isn't close)......................pob 570-335
is busy, hung or dead....................................33257-0335