Hallo Martijn, 1) Can I safely gateway ATN across IEEE and IEC? I mean: If a byte is > transmitted under ATN over IEEE, does this mean that it has to be > (or can be) sent under ATN on the IEC bus as well (and vice versa?) If you mean sharing ATN ie the same signal for two busses, my first impression was to say NO. But writing down this answer plus comment, I found out that there is no harm in it. > 2) Re-reading old discussions, I stumbled across a comment by William > Levak, claiming that untalk is used as a substitute for EOI on the > serial bus. Somehow, I don't really understand this comment, unless > my ideas about untalk and EOI are off. However, I browsed through > the sources of Ruud's PCDISK, and they seem to correspond to my ideas. EOI is replaced by another timing of the CLOCK- and DAT-signals. UNTALK is a IEEE-protocol and, as you know, not hardware related. > Related to this: What is the use of UNLISTEN? Isn't that exactly > the same as doing an EOI? UNLISTEN means the device cannot expect data anymore. Assume you open a SEQ for storing a textfile. The PUT# command stores the first string. This string ends with EOI, as every other string will. After sending the last string, closing the file will generate a UNLISTEN to tell the FD it can close the file as well. > 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. > 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 :) Groetjes, Ruud http://Ruud.C64.org/ - 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.