Hi there! Ruud Baltissen wrote: > > > 3) Consider a serial talker, to an IEEE-listener. The talker happily > > starts transmitting data, which I gateway to the IEEE bus. If, at a > > given time, the controller had enough, and asserts ATN, this will > > probably be in the middle of a byte being transfer on IEC. How should I > > handle this? In a 'best case scenario' :), this will result in the IEC > > talker 'talking' one byte too much. > > This scenario only happens if you program two FD's to exchange data. > > The situations we know of the Controller, the computer in this case, is > always either the talker (SAVE, PUT) or listener (LOAD, GET). As Talker > it can stop transmissions and send a UNLISTEN. This means the file > won't be complete but the FD doesn't know. As Listener it could not > respond to the handshake signals causing the FD to terminate the > process. Then the computer could send a ATN. > > Writing the above the thougfht occured to me: what reason could the > computer have to send an ATN in the middle of a normal proces? The > only system doing such things is a multi-tasking one. > Almost. As the _Controller_, it can send UNLISTEN. The controller may very well facilitate a data transfer between two other devices (Yes, that works in reality, too!). The controller can issue a command at any time, and if the controller is not a listener or a talker, this may just as well happen in the middle of a transfer (It's actually up to the application or user issuing OPEN/CLOSE). The transfer will probably mess up, but this is not handled in current implementations, so there's no need for you to handle that in any special way either. > > > I want to keep the thing as simple as possible, preferrably even stateless. > > May be a blunt thought: what does it matter! You only have to convert > things, not to interprete them :) > Exactly - unless you'd want to translate device addresses, etc, you could just hose everything without further interpreting the contents of the data stream or the sequence of events. -- Christer Palm - This message was sent through the cbm-hackers mailing list. To unsubscribe: echo unsubscribe | mail cbm-hackers-request@dot.tml.hut.fi.
Archive generated by hypermail 2.1.1.