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

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

On Sep 18, 12:38 am, mdj <mdj....@gmail.com> wrote:
> On Sep 18, 2:41 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
>
> > > > BTW, doesn't this mean that SmartPort capability is just a matter of
> > > > software?  Could a little software/firmware make any Dx-19 disk
> > > > controller SmartPort-capable?
>
> > > That's a good question. I suspect yes, but the IWM has an additional
> > > mode register to allow a higher encoding rate. SmartPort doesn't seem
> > > to use it, but the relationship between this mode, SmartPort, Macs,
> > > and 3.5" media just isn't really understood or documented yet.
>
> > Curious.
>
> Indeed. If Santa had bought me a digital storage CRO (I only have a
> basic model) for Christmas I would know by now. For the moment the
> idea is stalled until I can come up with another way ...

Is it a "receiver-clocked" protocol, or does the receiver have to eat
data at the rate the transmitter clocks it?

> > > Does the IIgs handle slowdowns differently to other machines?
>
> > The IIgs is completely unique, with a "speed control" bit in
> > a register.  All the accelerators I have used slow down (either
> > by default or by setting) when the slot 6 /DEVSEL space is
> > addressed--usually for 50 miliseconds or so.  This means that
> > a single 4-cycle instruction issued before each timing-sensitive
> > loop (including send and receive packet) is all that is required.
> > Notably, *no* action is needed to restore the fast speed when
> > done!
>
> > I've previously expressed my astonishment that the IIgs does
> > not support this simple, compatible protocol.
>
> Alas it's not an Apple supported protocol. The other issue is it
> assumes there's always a slow mode disk ][ device in slot 6, and
> there's really no guarantee that's the case. Even the Zip Chip and
> Transwarp allow you to disable slowdown for any slot (though it is the
> default behaviour for the Zip)

Actually, when Apple adopted the Zip Chip logic for the IIc+, they
essentially blessed it an an Apple protocol.

You are, of course, correct about the slot settings--but that wouldn't
bother me.  I'd just have to determine which slot was slow (of course,
it would be a pain to discover there wasn't one!  ;-).

> There's a defacto-standard protocol that's implemented by both the Zip
> and Transwarp that requires hitting a register to slow down, then
> another to speed up. Perhaps if you switch to this method it will be
> simpler to support both machine types, since only the location and
> value of the relevant STA will differ...

Unfortunately, to hit that register on the Zip requires a lengthy
"magic" sequence--the cost of inventing a soft switch without
having design control over the platform.

> > > > When faced with a choice between two unpalatable directions,
> > > > my inclination is to wait for the light to dawn.  ;-)
>
> > > Why not push it up to the presentation tier? You could have &NADAON
> > > and &NADAOFF, and only invoke OFF/ON when Nada applications do disk
> > > activities. Other than that, it can be left set up. It'd be pretty
> > > inefficient to do setup/takedown for every tx/rx
>
> > That is actually an approach I've been thinking about, while wondering
> > how often people would get into trouble by not using is appropriately.
>
> > Still, I like it best because it has no impact on the performance or
> > complexity of the "normal" cases, and it completely "wraps" all
> > the timing dependencies.
>
> It's always the way with an API - trying to anticipate the ways its
> users will mess it up :-) I don't think the 'wrong' case can actually
> cause any harm... it would be obvious to the application designer that
> something was amiss when their transmissions ceased working.

But it would mess up arbitration, so a wrongly "fast" machine
would disrupt all communications on the net.

> Of course, you can always drop a command intercept into BASIC.SYSTEM
> that throws an error if &NADAON, and make the other commands error if
> &NADAOFF. It's just a question of how idiot proof you want the API to
> be. Error/sanity checking is always a pain.

Right--expensive insurance...

> > Interestingly, on the IIgs, the issue is not disk I/O (for which the
> > IIgs
> > slows down), but speeding up for the non-NadaNet parts of the
> > computation.  I'll have to take a look at space implications--I think
> > separate versions may still make sense, but I'm considering some
> > alternatives.
>
> Drop DOS3.3 support and halve the number of configurations
> perhaps? :-)

Always possible, but I sort of hate to do it.  NadaNet is one
of the few things that works smoothly across the environments.

Frankly, it's a lot easier to not support the IIc/IIc+ and support
the IIgs only in slow mode!

-michael