From: Spiro Trikaliotis (ml-cbmhackers_at_trikaliotis.net)
Date: 2004-05-13 08:35:34
Hello,
* On Thu, May 13, 2004 at 07:47:56AM +0200 Baltissen, GJPAA (Ruud) wrote:
> > (just check ATN when you start clocking the byte in),
>
> The ATN signal triggers the 15x1 to start clocking in the data.
> Without ATN the 15x1 doesn't do anything at all. The rest of the
> transfer is based on the protocol.
Hm, well, no. The ATN is used by the controller to tell the the
peripheral that it needs their attention.
Upon reception of an ATN, each peripherel sets the DATA line almost
immediately to tell the controller that it needs some more time. In
fact, in the 1541, this is done with an XOR gate, so there is no need
for the processor to process the ATN itself.
As soon as the peripheral is ready, it unsets the DATA line. When the
last one has done so, the control recognizes this and is able to put the
appropriate command (LISTEN, TALK, ...) on the serial bus.
In fact, ATN is used for a LISTEN, TALK, the secondary address after a
LISTEN or TALK, and for the UNLISTEN and UNTALK. For each other byte,
ATN is unset.
Since a peripheral needs to set DATA immediately after ATN is set by the
controller, especially in a multi-tasking environment, it seems to be
reasonable to implement it via an interrupt.
On the other hand, for the controller, it is necessary to detect the
DATA line to see a "ready to receive". The controller has to check that
line and react on it with a latency not more than 100 us. So, if you
want to implement a controller, the DATA line needs an interrupt. For
more details (and source code) for this, have a look at the cbm4linux [1]
project. That's the reason why a XE1541 cannot be used with cbm4linux,
but a new XM1541 was introduced.
So, to summarize: The controller needs the DATA line to be able to
generate an interrupt (or to poll it very fast), the peripheral needs
the same for the ATN line (or needs some hardware help, or very fast
polling).
> Here you can have a problem: the moment you are receiving/sending a
> byte from/to the IEC-bus, an IRQ is out of the question otherwise you
> mess up the whole timing.
It depends on the speed of the processor and of the interrupts.
Something like a "fast IRQ", as available on a 6809, *might* help.
OTOH, for a Windows NT machine, I completely disable multitasking and
interrupts while transferring a single byte (more technically: The IRQL
is raised to HIGH_LEVEL).
> But IMHO there is nothing against pausing the transfer between two
> bytes to poll the RS232 register to see if something has happened and
> maybe even serve a request.
Exactly, as it is not allowed to stop multitasking and IRQs for much
time on a NT machine, or you run the risk of crashing the machine,
that's the way to go. Depending on the speed of the serial bus, you
might not need to poll after every byte, but after n bytes, with n being
determined appropriately.
Kind regards,
Spiro.
[1] http://www.lb.shuttle.de/puffin/cbm4linux/cbm4linux.html
--
Spiro R. Trikaliotis
http://www.trikaliotis.net/
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.