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

["Michael J. Mahon" <mjmahon@aol.com>]

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.)

> 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.)

> Another idea:
> Doesn't make network activity while using any program that cares about the
> solid-apple behave strangely? I'm also thinking about games that might use
> both paddle buttons...

Yes, though there are few such programs (that I use ;-).

> I modified by NadaNet adapters to receive only when AN2 is high, so that PB1
> is free at least as long as the net is not used. Pressing Solid-Apple or
> PB1 will lock up network activity, though.

I also use a game port clock, which uses three annunciators and PB1, so
AN2 is off-limits for me.

Since there are so few annunciators and pushbutton inputs, allocating
any of them to a function like NadaNet is almost guaranteed to interfere
with *some* program's intended use.  In practice, it's the user's job
to ensure that the configuration of the total system is consistent.

-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."