From: ulan@ee.ualberta.ca (Dale Ulan)
Subject: Re: 68008 address demultiplers?.is it this simple?
Organization: University Of Alberta, Edmonton Canada
Date: Tue, 12 Jan 1993 00:58:08 GMT

steveh@tasman.cc.utas.edu.au (Steve Howell) writes:



>ok.. its been somewhat confirmed that a 6809 is not avail in a SMD package, so
>i guess the time has come to go 68k at long last.

Congratulations on the step up. You should find the 68k quite versatile for
your needs, if not overkill...
I still like the 6809, but the 68000's registers are too huge... great if
you are used to a smaller processor...

>just a few questions before i dive in...
>can i do the following with a mc68008?
 
 Great choice.... 68008 is a great starting point

>1) can i use the upper address lines thru say a 74ls138 (3-to-8) decoder
>to create the enable signal for each pheripherial?.. or do i need some
>complex PAL or something (like everone elses uses that ive seen!)

Yes, you can demux the lines, but provide pullups on the address lines so
that the 68008's hi-z mode does not cause false triggering.
I used the 74154 16 line demux, but the 74138 should work fine.
I am addicted to HC logic, but LS will work fine. I usually use HCT
for mixing NMOS and CMOS circuitry, but only because of power consumption.


>2) the E timing signal on the 68000. is it on the 68008?

Yes, but it is often easier NOT to deal with the E signal. Simply use
the 8 MHz clock, giving a 4-cycle access time equal to 2 MHz (easy
to get 8-bit peripherals for it), tie /AS and /DTACK together for 
maximum memory throughput, and you can use /AS and /DS as inputs to your
demux as INVERTED E signals. They should probably be combined (via OR),
then inverted (use a NOR gate), and that will give you a quick and dirty
E signal. With this, you can use the /AS and /DTACK to single-step the
processor, one bus cycle at a time, providing you build a bit of extra
logic. (it usually is not necessary, but it can be handy when debugging
hardware-software interactions... better to have the facilities there).
I am assuming that you want to have the lowest-parts-count system, yet
not limit throughput by using low-speed peripherals.
If you need different wait states, then you will probably need to use some
PALs (EP600 does the job) to generate wait states. 

You can use the E clock if you do something with the /VPA and /VMA lines
(similar to my /AS and /DTACK solution) The disadvantage is spped. You will
have to check the timing specs on the 68008 to see how much slower it 
would be.

My solution is not the best, but I think it is the easiest and highest
throughput solution I have seen.
Maximum throughput is supposed to be somewhere in the 2 MHz rate (I think).
I don't have the timing diagrams right here...

What I am doing is using the 68008's internal delays to generate the data
transfer ack signal straight from the address strobe signal. This is as fast
as the 68000 bus will operate. The pseudo E signal (obtained from the strobes)
is not going to be perfect in frequency, so timers should be run off of the
processor's E clock. If you need timers, you may want to use the /VPA and /VMA
lines to get constant 6800 peripheral access cycles. They are slower, though.
For the price of complexity, you can run the timers on E (6800 cycle), but
the rest on 68000 cycles. You have to decide.

>3) what is the base address for RAM ($0000 is what a 6809 is at, but i hear its
>not this simple with 68k devices?.. is this right)

Vectors start at $000000. For a low parts count system, put EPROM there.
The first locations should be the SSP and the reset Program Counter.
Check the book for this...
Most systems use some PAL stuff to substitute EPROM for RAM, and put the 
vectors in RAM. This requires a 8-cycle counter to allow the first
two 32-bit words to be loaded, then go to the normal memory map. This
is handy, but it has too many parts. Since I ususally write embedded
controllers, having RAM for vectors only means that I have to copy a
table from ROM to RAM.  It is easier for me, then, to just run EPROM there.

I would suggest starting ROM from $000000, and RAM from whatever address is
handy from the decoder. I usually had EPROM from $000000 to $03FFFF, which
is very large for EPROM, and run the RAM right above that. It really does
not matter, since the stacks are set up by your program.

The way I usually see this done is to put ram at $000000 and rom at a
very high location, but I don't like this approach, mainly because of the
added circuitry required.

>4) Can i put ROM anywhere i like in the address map? (as long as its big enough)

See comment #3. Like I said, put it in the BOTTOM, so you don't need any
fancy switching circuitry... The alternative, if you need RAM vectors, but
don't want the switching circuitry, is to hard-code the vectors to a JUMP
table in RAM. This allows the advantages of changable vectors, and a simple
design.

----------------------------------------------------------------------------
Dale Ulan  VE6DAU        ulan@ee.ualberta.ca   Computer Eng. Undergrad
Newsgroups: comp.sys.m6809