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

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

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.

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

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

> 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

Matt