please see imbedded comments below.
Dick
-----Original Message-----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Tuesday, March 30, 1999 4:31 PM
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.
I see what you're saying, but it's not that common to want to do that (if
the CPU doesn't have access to the main memory, it'll execute NOPs or
RST38's depending on how the bus is pulled, for example, which might not
be that useful). Admittedly the PERQ rasterop machine did something
similar (got the CPU to generate addresses and start memory cycles while
the rasterop hardware took over the data bus), but the microcode on that
machine was designed specificially to do that. The Z80 microcode isn't.
If you then drive the bus, it will execute whatever you feed it, provided
you do that during an instruction fetch cycle.
A front panel can certainly be made that takes over the
entire bus and
generates address/data/control lines.
> >
> >>What would you do with the HALT signal, and how would you implement it?
Remember on the Z80 (which is what I assume you're
using based on the
signal names), Halt is an _output_ from the CPU to indicate that the CPU
has executed a halt instruction and is waiting for a reset/interrupt.
Of course! I'd forgotten that it raises that flag when it's halted. My
steel-trap memory is gradually becoming a colander . . . <sigh>
I don't believe I ever used that function on an S-100 . . .
-tony