[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NadaNet for the //c - just an idea
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.
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.
>> 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.
>
Ferdinand