please see imbedded comments below.
Dick
-----Original Message-----
From: Tony Duell <ard_at_p850ug1.demon.co.uk>
To: Discussion re-collecting of classic computers
<classiccmp_at_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
>
Received on Wed Mar 31 1999 - 00:36:38 BST