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

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

On Sep 19, 4:37 pm, "Ferdinan Meyer-hermann" <ferdinan.meyer-
herm...@a2central.com.remove-kpl-this> wrote:
>   To: mdj
> I've started hacking on it as well....
> There is one problem I came about: you entered lowercase symbol names - My
> merlin Pro assembler converts everything to upper case?
> How did you enter these lowercase names?
>
> 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.

I noticed this, too.  Presumeably this is useful for SmartPort
protocols.

> 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?

I'm away from my reference material for the week, so I can't easily
confirm those sequences, but it looks pretty similar to what I was
envisioning for the IIc  (But not the IIc+).

For the IIc+, it is necessary to play the same disk port tricks, but
"zipslow" must also be referenced, since it is essentially a Zip Chip
accelerated machine.

The time penalty, while annoying, is tolerable.  The latest version of
NadaNet (which I was preparing to publish before this effort) has
reorganized the code around the SENDPKT and RCVPKT pages to
pack them tighter and save significant space (over a page) by
factoring some 16-bit moves and PROTERR out.  This would have
to be reorganized again to allow for these longer sequences,
particularly so if the IIc+ and IIgs were to be similarly supported.

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

Probably true, though there are some compensating savings.

> 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, programs that use solid-Apple see it intermittently pressed
during
network acticity--Program Writer is one such program.  In the same
way,
any program that asserts AN1 will inject noise into the net.

So far, neither of these behaviors has been too much of an issue,
since
few programs sense solid-Apple and even fewer manipulate AN1.  (I do
recall that Appleworks uses solid-Apple, so I guess this tells you
that
I don't use Appleworks while I'm connected to NadaNet.  ;-)

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

But only on the machine on which it is pressed--communication between
other machines is unaffected.  I've occasionally used this for
debugging
purposes.  ;-)

For my purposes, enabling with AN2 would not do the job, since
I use a serial game port clock that uses AN2 for its signalling.  ;-)

The fact is that any use of annunciators or pushbuttons is at the
discretion of the program, and, since they cannot be compatibly
shared by multiple applications, compatibility is more of a
"configuration" issue for which the user is responsible.

So using NadaNet with a game that uses both pushbutton inputs
would be a _de facto_ compatibility problem.

If there were "lots" of pushbutton inputs and annunciator outputs
then this kind of conflict would be rarer (but still possible).  Or
if a NadaNet adapter were based on a more complex state
machine requiring a "dance" to enable and disable NadaNet
access, conflict could also be made less probable.  I regard
both of these approaches as unnecessary unless *lots* of
people start using NadaNet for *lots* of things--a situation
which has not occurred.  ;-(

-michael