Please see comments imbedded below.
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 11:59 AM
Subject: Re: Computer busses....
>>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.
>
>Why wouldn't BUS REQUEST work?
>
It would only work if BUS REQUEST were not a request for negotiation. If
you do have a bus negotiation handshake, then it might not work simply to
asser BUS REQUEST because you may want to "jam" data in to certain locations
while the processor is doing most of the work. CPU places addresses on the
bus, you, by means of your front panel, want to put different data there.
You float his data bus, and drive it yourself while he creates the strobes
in his normal timing. Likewise, you might want to redirect his data flow,
hence you float his address bus, driving it yourself, while the CPU
generates normally timed transaction control signals. It's an obscure point
but I've seen it done for whatever reason on several occasions.
>
>>What would you do with the HALT signal, and how would you implement it?
>
>WAIT sould act as a "pause and hold the bus in it's current condition"
>signal. Halt should mean "Stop what you are doing, release the control of
>the bus and wait until the HALT signal is removed". IMHO
>
Now this one seems like it could be accomplished with the BUS REQUEST
signal. I suppose it's arguable, but if you want control of the bus, and
want the processor to more or less disconnect himself from it, it would
require a signal to each processor/master on the bus. If the FP wants to
control the bus, it doesn't have to HALT the processor does it? It just
needs to seize the bus. Whether that stops the processor(s) would depend on
what's on the CPU card. It depends, of course, on whether you have multiple
master candidates on the bus. If not, it's moot, but if so, then you might
not want to halt them, but merely seize the bus for a moment.
>
>>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.
>
>I guess the RD/WR signals should be seperate and only applied AFTER all
>signals on the bus are stable.
>
As I mentioned before, it's quite critical to the operation of the bus, how
you time the WRITE signal. Many processors following the MOTOROLA model,
i.e. with a regular 2-phase clock, with one clock per bus cycle, tell you
when the cycle begins by asserting the "E" clock in the MOT case. If R/W is
true at the beginning, it's a read cycle, else R/W must be low, meaning it's
a write. Most of the older processors of this sort assert the WRITE state,
i.e. R/W LOW quite some time before the E clock (or phase 2) becomes true.
Nevertheless, the data is only held valid for a minimal time after the
falling edge of E, hence some steps have to be taken to hold the data for
some time after end of E so that the data will persist beyond the rising
edge of the nWR signal. On a 6800 or 6502, this is quite straightforward.
The CPU is fed a single phase clock, sometimes called phase 0. It produces
(in the case of the 6502) a pair of non-overlapping complementary clocks,
phase 1 and phase 2. The 6800 required you use a clock generator to produce
those and feed them to the CPU. You could still gate them with R/W to
create nRd and nWr signals, but the results were slightly different.
More recent processors don't give you the two clocks, so you don't have as
many options. Some give you both an address strobe and a data strobe, from
which you can derive appropriately timed nRD and nWR strobes. These often
are needlessly short, however, leaving valuable bus bandwidth unused.
I think a less conservative though still correct approach would be to limit
your statement to signals other than data. Most peripherals require only
that the data be stabile on the trailing edge of the write command. It's
likewise with memories, so I think that's a safe approach. There are
exceptions, though, but I hope they're dead forever.
Dick
>
>----------------------------------------
> 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 - 13:58:15 BST