Re: Does having an AppleShare connection active throw off timing a bit?

[dempson@actrix.gen.nz (David Empson)]

Scott Alfter <scott@alfter.DIESPAMMERSDIE.us> wrote:

> I thought I had seen something in the past that said that if your IIGS is
> connected to a server, some cycles would get "stolen" here and there, which
> could affect timing-sensitive programs.  Is this the case?  If so, it'd
> explain the weirdness described below:

[Wearing my embedded systems programming hat here - I've programmed
SCCs, implemented HDLC and communication protocols, and dealt with
timing critical stuff like interrupts for a long time.]

Not just "connected to a server". If you have AppleTalk enabled at all
you will be getting regular interrupts that will be using up some CPU
time. The IIgs has a regular timing interrupt running while AppleTalk is
enabled (approximately every 250 milliseconds, IIRC).

Active communication over the LocalTalk network (either broadcasts or
messages to/from your computer) will occupy a lot more time. I expect
that while you are connected to a server there will be occasional
packets going back and forth to keep the connection alive, even if there
is no .

LocalTalk runs at 230400 bps, using SDLC/HDLC framing (bit-synchronous,
8 bits per character ignoring "stuff" bits), which means a character is
received or sent every 34.7 microseconds when it is running without
delays.

Data is organised into packets, with a handshake sequence prior to
transmitting data, to check whether the recipient is ready. This
handshake is timing critical: if the receiver doesn't respond promptly,
the sender will try again a few times and will eventually drop the
packet or the connection.

I'm a little hazy as to the details of the handshake, but I think it is
a single byte which triggers a receive error interrupt (FM encoding
clock glitch, or something like that).

Receiving a packet is handled by interrupting the processor when the
handshake is detected, then remaining in the interrupt handler for the
duration of the packet receive. That's up to about 580 bytes, 34.7
microseconds per byte, which is around 20 milliseconds total in the
worst case. Everything else on the computer will be waiting for this
time.

Transmit is similar: it is timing critical, so interrupts are locked out
during a packet transmission.

If a response is required for the received packet, the receive interrupt
might go straight into the transmit response, which could easily double
the time that interrupts are locked out.

The IIgs isn't typically running any server applications, so I expect it
doesn't need to do any heavy duty transmit or receive processing except
at times when it is servicing an OS call which requires communicating
with the file server.

> I've been porting my 1-Wire code from a mix of assembly and BASIC (with the
> former being built with a native assembler) to a mix of assembly and C
> (with both cross-compiled/assembled with cc65).  The Linux box that hosts
> cc65 also has netatalk running on it.  I have a IIGS connected to the home
> LAN through a GatorBox, with my 1-Wire adapter in the 16-pin joystick port.
> 
> The assembly-language bits use timing loops to create the 1-Wire signals,
> with delays ranging from 6 ?s to 480 ?s.  If I'm connected to the file
> server, the reset routine (which checks the 1-Wire bus to see if anything's
> connected) shoots past its window and says nothing's connected.  If I
> comment out that check to get past it, the other routines don't work any
> better.  If I slow down from 8 MHz to 1 MHz and hit Ctrl-Reset, the computer
> disconnects from the server and the 1-Wire routines start working correctly.
> (Interestingly, I can kick the speed back up to 2.8 or 8 MHz and they'll
> still work.  The accesses that the 1-Wire routines make to PB2 (the third
> fire-button input on the joystick port) must slow the machine down to 1 MHz
> for a bit.)

You might be able to lock out interrupts during time-critical parts. The
problem is that if you lock out interrupts for more than about 70
microseconds in one burst, you risk losing receive data on AppleTalk,
which could cause loss of the connection to the server (or at least
require retransmission and affect network performance).

When the LocalTalk handshake arrives, the computer has to get into the
interrupt handler, identify it is an AppleTalk interrupt and send the
acknoweldgement within a few tens of microseconds. I'll have to look up
Inside AppleTalk for more precise timing.

If the interrupt is delayed significantly (in the order of
milliseconds), the handshake response might cause data corruption on the
network (not just affecting your computer).

If you don't care about your server connection, then it is OK to lock
out interrupts for longer, but you should try to spread out your
interrupt lockouts, leaving plenty of time with interrupts enabled so
that the connection can recover. For example, a pattern along the lines
of locking out interrupts for 500 microseconds followed by tens to
hundreds of milliseconds in which interrupts are enabled.

A technique which is often useful is to disable interrupts for the
duration of a critical task, but if there are points within the one wire
communication which have flexible timing, then you can briefly enable
interrupts to "sniff" for AppleTalk (or anything else) which is pending.

Typical code to do this sniffing would be CLI, NOP, SEI. You might be
able to omit the NOP. Some processors will respond to interrupts
immediately after a CLI, while others need a one instruction or one
cycle delay to ensure that an interrupt can be serviced. I don't recall
offhand the beahviour of the 6502 family in this area.

-- 
David Empson
dempson@actrix.gen.nz