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

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

On Sep 15, 8:35 pm, mdj <mdj....@gmail.com> wrote:
> On Sep 16, 11:01 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
>
>
>
>
>
> > > > I'd like to be sure that we are staying out of each other's "coding
> > > > space".
>
> > > I think you're pretty safe... That said, the acid test is having a
> > > UniDisk 3.5" on the bus to validate it.
>
> > > Unfortunately the documentation on the protocol is sparse. The IIgs
> > > documentation David mentioned shows the 'negotiation' used, which I
> > > covered previously. It's in essence just like a serial port. PH1+3 is
> > > used so that Smartport devices can detect an 'enable'. PH0 is request
> > > to send, and WRPROT is clear to send. Read/write communication then
> > > happens via the read/write lines in a packet format.
>
> > Doesn't that mean that if I raise PH1 + PH3, other devices will be
> > listening
> > and could be confused?  Particularly if I then twiddle PH0 and expect
> > that
> > WRPROT is mine to drive?
>
> If you twiddle PH0, yes, that would case SmartPort devices to assert /
> WRPROT. If you use PH2 instead, they'll leave it alone.

OK--that's pretty straightforward.

> > > Unfortunately the
> > > documentation on the packet format was sufficiently bad that I read
> > > the ROM listing in the IIc reference manual instead. Do you have that?
>
> > Yes, I'll take a look.
>
> > 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.

> > > A possible complication (sorry I'm away from home and don't have many
> > > of my docs with me) is that WPROT is actually /WPROT. If there's a
> > > SmartPort device on the bus, that's going to mean the line will be
> > > high during a PH1+3. I'm not sure whether it's pulled internally high
> > > or low or whether extra circuitry will be needed to compensate for the
> > > devices presence. Should be easy enough, just requires a little extra
> > > investigation....
>
> > Yes, WPROT is pulled high internally, but I can pull it back down when
> > the network is "enabled" so that the network state is read "true".
>
> > The polarity of the WRPROT logic on its way to bit 7 is correct--
> > high = 1 and low = 0.
>
> > As I noted in my reply to Ferdinand, I'm finding the software
> > implications
> > for NadaNet to be pretty distasteful...
>
> > It was designed with a "fully decoded" interface with separate entry
> > points and multiple exit points.  Clumping them all together to do
> > the "setup" code, then dispatch to the separate routines, then
> > force all routines to return to the dispatcher for "takedown" code,
> > is more than a little annoying, and a considerable waste of time
> > and space.
>
> > I suppose I could impose this structure only on the IIc/IIc+ and
> > "full speed" IIgs versions, but that would require more divergence
> > between the eight (!) builds (not counting the two AppleCrate
> > builds for general use and the Message Server) than can be
> > reasonably accomodated by conditional compilation.
>
> > Come to think of it, the Message Server should *also* exist
> > in all four variations (IIc, IIc+, IIgs, and "everything else", so
> > make that 13 builds!).
>
> 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.

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

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.

-michael