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

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

On Sep 19, 10:17 am, "Michael J. Mahon" <mjma...@aol.com> wrote:

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

It's self synching, like disk read/write activity. Smartport packets
are preceeded by the sync-byte sequence and apparently the other end
is supposed to hop in and start decoding...

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

The Transwarp can slot down by writing a 1 to $c074, and a 0 to speed
back up. I thought the Zip supported this too, and the magic sequence
was only necessary for custom speeds?

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

Right... I was only considering the implications for the disk port...

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

I hear you... The Apple II's are more different than they
superficially appear :-(

Matt