Re: NadaNet for the //c - just an idea

Ferdinan Meyer-hermann wrote:
To: Michael J. Mahon
Michael J. Mahon wrote:

Ferdinan Meyer-hermann wrote:

Sorry this reply is so late--Teranews doesn't seem to want to post
my replies... ;-(

There is good news:
My //c doesn't disable the state machine when no disk is selected - it is
possible to read the WPROT line even then. With the Disk ][ controller
card this is impossible.
Right, I found this on the IIc+ as well.

For all those various versions: I thought about sort of self-modifying
code: A (Applesoft?) program that pokes the correct softswitch locations
into the code when initializing, depending on the current machine.

And: is it really so bad to just enable/disable the interface/zip
chip/etc before/after each packet to be sent/received?
I think we would need
LDA $C0E3 ;3
LDA $C0E7 ;6
LDA $C0ED ;9
* Send/receive routine
LDA $C0E2 ;12
LDA $C0E6 ;15
* The "Zipslow" access can be omitted, so we have 12 extra cycles per
packet.
If we need about 100 cycles per byte then the shortest possible packet
will at least take 800 cycles. Is twelve more cycles really that bad?

The time is quite tolerable. The problem arises when viewed as a way to
adapt to the IIgs, which requires speedup and slowdown transitions. The
sequences are longer (maybe) and all "exits" must be caught. (For
example, CALLSRV transfers control to the called routine, and so would
need its own "finish" code.)

There is going to be a major problem with that.
There is the drive turn-off delay that will keep the drive on after it has
been turned off by software. And if we turn on two stepper phases and take
control over write protect with the drive still running, strange things
will happen.

Indeed. Code much like RWTS's must be added to verify that any
previously selected drive is actually disabled.

So we need to ensure that there really is no drive running, which takes a
very long time. And it would really slow down my disk copy program.
But with the drive 2 replacement approach I got NadaNet running on the //c.
We don't even need to turn off the drive on exit since ProDOS will select
the correct drive when it needs it.

So using any disk port is going to require keeping track of the last
"drive" used--if it's a real disk, a long wait is required, but if the
last use was NadaNet, then no wait is needed to reuse it.

If history is "cached" in this way, the performance problem is averted,
but the code required to enable the network becomes large enough that
it should be called as a subroutine, not inlined.

The problem with controlling the speed is that it must be controlled
properly *throughout* a whole request. It is important, for example,
that a sender serving a request not start a send before the receiver
is waiting to receive.

All of these delays are currently properly accounted for, but they
require that machines be running at 1MHz *during* a request protocol,
not just during sends and receives.

I've already described the structural issues this causes.

And I expect it to be shorter than common entry/exit routines and so on.

It's also necessary to enable the network for ARBTRATE (which must be
able to write to the net to assert its lock). GETMSGSRV and PUTMSGSRV
(in NADA.MSERVE) also lock the network to allow them time to do table
searches without breaking protocol time limits. (These locks are
released as a normal side effect of the subsequent send.)

Actually there will always be an ARBTRATE before a SENDPKT. So we just need
to turn on the adapter in ARBTRATE and forget about the rest. And I assume
that there is always some data transfer before the message server routines
place a lock, so the adapter will be enabled then.

No, there is only an ARBTRATE before sending an initial request control
packet. All packets internal to a protocol are "protected" and do not
require further arbitration. Any state set by ARBTRATE will be released
by the first subsequent send, and any other accesses will not find the
network enabled.

And the data transfer prior to a GETMSGSRV lock is a RCVCTL, which will
release the network (PH1 off and PH3 off) before the lock is asserted.

The point is that the network enable/disable functions cannot be placed
only in the send and receive routines, since the network must be enabled
to both sample its state and to lock it. (For a IIc, sampling the state
isn't a problem, but it is if speed must be controlled.)

The only level at which a complete request or request service is known
is at the level of the request or the service--and there is not common
entry point or exit point for requests, nor common exit point for
services (SERVER is a common entry point).

After considering several possible approaches, I'm not happy with the
alternatives I've looked at for centralizing entry and exit points. Nor
am I happy with the idea of planting calls to "setup" and "takedown"
code in each request's code (and changing SERVER to catch most service
exits and planting "takedown" calls in the rest). I haven't given up
on finding a way that doesn't consume lots of space and some time, but
I no longer consider it a "must have", either.

On a separate but not unrelated topic, I'm planning to release a new
version of NadaNet (v3.0) which will make a number of changes, including
a change in on-the-wire control packet format.

Network stress tests (enabled by the AppleCrate II) and a fortuitously
peculiar choice of test parameters revealed a "synchronous" mode of
packet collision which I had not foreseen, and which, under certain
circumstances is not detected by the checksum.

The failure occurs when two machines *both* apparently win the
arbitration (which can only occur within an 11-cycle window), and
then send data (which is actually within a 4-cycle bit timing
window), resulting in the ANDing of their packets. There are some
cases which result in a good checksum on corrupted data, with a
valid "sender" ID, allowing a protocol to complete with mangled
parameters!

Since ANDing can only result in changing 1 bits into 0 bits,
this failure can be eliminated by including both the true form of
the sender's ID and its binary complement, and checking for this
relationship in SERVER.

Fortunately, the coding of the "request" and "modifier" bytes is
loose enough that they can be easily combined into a single byte
with lots of room to spare, allowing the control packet to remain
8 bytes long.

NadaNet v3.0 has been tested under severe congestion and any
synchronous collisions are now detected, counted, and rejected.

I've also added &RUN and &BRUN commands to simplify running
programs on remote machines, and have added a &BCAST command
to provide support for more general uses of broadcast data
transactions.

In the process, support for the old "active boot" protocol of
the AppleCrate I has been removed (and the AppleCrate I ROMs
will be upgraded to support the shorter "passive boot" protocol).

These changes do not make your modifications much more complex,
but they introduce a couple of new requests--&RUN and &BRUN (which
shares code with &CALL)--that result in a transfer of control
out of SERVER at the receiving end.

-michael

AppleCrate II: An Apple II "blade server"!
Home page: http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."
.

Relevant Pages

  • Re: locking objects
    ... >> when dataset is filled i am putting a lock (in case a next request). ... Yes it is connected with 3rd party control. ... the lock statement itself doesn't have a timeout. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: ioctl serial port and SIOCGSTAMP
    ... *socket IO control* request, giving you access to timestamp information ... for a packet. ...
    (comp.lang.c)
  • Re: Different POST encoding format
    ... you have total control of what is sent in the post request. ... packet size of the request. ... server side (of which I have no control or debug information. ...
    (comp.lang.perl.misc)
  • Re: MV-database independence & PHP
    ... packet file into the request queue, ... File polling means that load balancing can be achieved by multiple DBs, ... A FIFO tree is established in the local FHS: ...
    (comp.databases.pick)
  • Re: remote port unlocker - does such a thing exist??
    ... authentication processes are performed on an arbitrary packet. ... UDP or any other protocol can be used to deliver the request. ... HolePunch should prevent flaws that cannot be easily audited in many ...
    (comp.security.firewalls)