You've hit most of the important signals. One I'd add, however, is a data
bus disable, and perhaps an address bus disable as well. This would allow a
front panel or other bus mastering device to steal cycles under certain
circumstances.
What would you do with the HALT signal, and how would you implement it?
There's some debate about how one should signal the beginning of a new bus
cycle. This should be at the earliest moment at which addresses are
stabile.
If you have separate strobes for memory and I/O, then either of them could
do it, or if you generate separate strobes for read and write, that could
work as well. The question comes up, however, of how to generate the write
strobe, which is often shorter than the read signal from the processor, if
there is a separate read strobe at all. On a read, it's generally desirable
to time the read strobe so the strobe at the processor goes away, signalling
that the data has been sampled, before the memory or I/O device is disabled,
making the data go away. Likewise, it's desirable to make the write strobe
during processor write cycle go away before its data becomes invalid at the
target. What's more, some peripherals don't like having data change once a
write cycle begins, so it's necessary to have valid data before signalling a
write. This is complicated by the fact that some processors initiate a
write cycle before the data is valid, while others do not. Many schemes for
generating these signals end up making the processor operate relatively
slowly with respect to the memory bandwidth in order to satisfy these
conditions. Circuits which latch the data or otherwise fiddle with the
cycle length in order to avoid slowing the processor down will increase the
parts count and complicate the timing, while those that accomplish this fit
by using faster memories and peripherals will cost more due to the higher
and not as effectively used bus bandwidth.
If you'll start with the model you've suggested, consider the types of
devices you anticipate attaching to the bus, and decide how each can be
accomodated, you'll eventually settle on a good approach.
Dick
-----Original Message-----
From: Arfon Gryffydd <arfonrg_at_texas.net>
To: Discussion re-collecting of classic computers
<classiccmp_at_u.washington.edu>
Date: Tuesday, March 30, 1999 9:49 AM
Subject: Computer busses....
>Anyone have any idea what was/is the best bus design?
>
>I'm thinking a stripped down Z-bus (without the M1 signal and etc). What
>else should be on a bus besides:
>
>ADDRESS
>DATA
>RD/WR
>MEM/IO
>BUS REQ
>BUS ACK
>INT
>INT ACK
>WAIT
>HALT
>RESET
>CLOCK
>
>
>----------------------------------------
> Tired of Micro$oft???
>
> Move up to a REAL OS...
>######__ __ ____ __ __ _ __ #
>#####/ / / / / __ | / / / / | |/ /##
>####/ / / / / / / / / / / / | /###
>###/ /__ / / / / / / / /_/ / / |####
>##/____/ /_/ /_/ /_/ /_____/ /_/|_|####
># ######
> ("LINUX" for those of you
> without fixed-width fonts)
>----------------------------------------
>Be a Slacker! http://www.slackware.com
>
>Slackware Mailing List:
>http://www.digitalslackers.net/linux/list.html
Received on Tue Mar 30 1999 - 11:45:06 BST