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

["Ferdinan Meyer-hermann" <ferdinan.meyer-hermann@a2central.com.remove-3ad-this>]

  To: Michael J. Mahon
Michael J. Mahon wrote:

> 
> 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.
As long as the Zip Chip just needs a slot 6 access to slow down, then it
will get 3 slot slot 6 accesses before any timing critical code! 

> 
> 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.  ;-(
So that means that a configurable PB/AN how it is now is a good idea, If I
don´t like the configuration I can just change some defs in NADACONST.S and
reassemble.
As long as only a few people are using it, this is going to be ok.

@Bill:
I don't like abusing the disk port either, but I have to when I want to hook
it up to NadaNet.


Ferdinand
--- 
bbs.a2central