Re: Handic VIC-Switch

Den Wed, 1 Nov 2017 09:46:20 -0500 skrev Jim Brain <brain@jbrain.com>:
> On 11/1/2017 9:30 AM, Baltissen, GJPAA (Ruud) wrote:
> >
> > Hallo Jim,
> >
> >
> > > And, for the record, ATN is *NOT* the start of BURST mode, which
> > > is 
> > the issue. ...
> >
> > I didn't know that at all, thanks for this info.
> >
> > Reading the rest of your explanation just only one idea pops up in
> > my mind: what about reacting to a change of any signal? OK,
> > switching an attached computer on or off will cause to block the
> > switch for the other computers but that is only for a limited time.
> 
> The problem is that you may not be able to immediately switch to that 
> computer using the bus, so you need to "buffer" and retransmit the 
> received data.  Thus, your idea will work (in general) only if you 
> record all activity on the 4 lines from all computer ports at all
> times, and then replay them back to the bus right before you connect
> that computer to the bus.  Simple, but requires basically 8 low speed
> logic analyzers, and does not address the issue that you need ot know
> enough of the protocol in use to "fake" the "someone is here at the
> other end of the bus, hold on a minutes while I prepare a response
> for you".  As well, some protocols, if they assume they own the bus,
> don't implement such a "holdoff" feature at all, so they cannot be
> told to wait.

Will a computer send this FF command even when the VIC-Switch pulls DAT
low?

Is anything else than FF ever sent before ATN? If not, then the switch
just needs to remember if burst mode were requested or not, and send FF
to the device before connecting it to the computer. This assumes that
the computer can handle the delay.

Btw for how long will a computer wait if DAT is held low? Indefinitely
or a few seconds?

-- 
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

       Message was sent through the cbm-hackers mailing list