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

[mdj <mdj.mdj@gmail.com>]

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

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

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

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

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.

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

Matt