Subject: Re: serial mouse emulation for macs w/o adb...
To: M.R. Zucca <mrz5149@cs.rit.edu>
From: Bill Studenmund <wrstuden@loki.stanford.edu>
List: port-mac68k
Date: 05/23/1996 13:00:39
> True, but if you leave the mouse plugged into a particular port all the
> time, the tty's will come in at the same place. If you're one of those people
> that changes your setup often -> plug your mouse in the last possible tty and
> nothing gets shifted.

Or just hardcode the port. Though it might be a bit displeasing, it
is (AFAIK) how the i386 folks work, w/o much difficulty..

> Actually, I haven't had a chance to look. If I have to program at that low
> a level then I hope it's an SCC since that's the same chip I delt with
> when I made an OS for the Sun 2/50 (*barf*). I could prob. figure out the
> Z8530 from the source in NetBSD, though.

The z8530 is the SCC. The deal is, if it has an SCC which iss
wired up similarly to the ones on the motherboard (what you'd
normally expect, but with  CTS backwwards as in the mac), then
you don't need to write drivers. Just get new attach code, and
hand it off to the M.I. code. That's one reason we've gone to
it (the others being it's cleaner, and a better base for enhancements).

> > If so, you could
> >write code to handle probing, a slightly-different attach routine, and
> >a few different routines, and be set. Presto, zsaenb controller (zs Applied
> >Engineering NuBus).  Basically you'd need to replace a few of the
> >routines in zs.c. Everything else should be set. Hopefully they did
> >things like Apple did.
> 
> Actually, thank the lord for NuBus. The AE card has it's own drivers in ROM.
> Given the video mrg code, I could glue in the drivers for each port. I've had
> a look at the driver code and it doesn't seem to call any strange A-Traps.
> It's a great idea but I haven't been able to figure out how I can do
> interruptable I/O with the stinkin' thing. Anybody know how NuBus interrupts
> get installed/handled under NetBSD?

This idea doesn't strike me as being very easy. Getting the drivers off
of the card should certainly doable, but then you've got to write
translation code to go between  NetBSD's tty layer and the MacOS drivers.
Since they (AFAIK) have different philosophies about  IO support,=
life mightn't be easy. Though if they have  on-card CPU's, this
way might be the only one, save getting tech info from the 
manufacturer.

> Anyway, if this doesn't pan I'll have to nose through the drivers and find
> out where the control addresses are on the card and what chips are used.

A quick peek could tell you the chips. If they're  8530's or so,
and there aren't any obvious CPU's on the card,  direct access
might be easier. I'm interested in this as the modularity of this
new driver makes adding a card like this easy, if it's just a question
of chip addresses.

> This project will have to wait, though. I'd like to work on getting internal
> video working and then making a fuel-injected color dt. :)

Cool!!!!!!

> >If too many things are different, these drivers would need to be a different
> >character device type. You could still name them tty02, tty03, etc,
> >but they couldn't use the current drivers.
> 
> tty0 at zsc0
> tty1 at zsc0
> tty2 at nubus0
> tty3 at nubus0
> tty4 at nubus0
> tty5 at nubus0

Not quite. tty00, tty01, etc are all names of special files in /dev.
zstty0, zstty1, othertty0, othertty1, etc are names of device
drivers configured in the kernel. These different devices each
would have different major numbers (12 for zstty, something else for
othertty), and minor numbers corresponding to their sequence
number:

/dev/    Major #  Minor #    Implied driver

tty00     12       0         Modem port on motherboard
tty01     12       1         Printer port on motherboard
tty02     12       2         Serial port using chip just like on
				motherboard, just with registers
				somewhere else.
...

ttyn0     34?      0         Port 0 of a tty type with its own open,
				close, read, write, ioctl, start,
				stop, etc. routines.
ttyn1     34?      1         Port 1 of above tty type

...

ttyb0     35?      0         Yet another tty type with its won routines

It would probably be best to reserve tty0# for zstty devices (devices
with major # 12). Oh, 34 and 35 were arbitrarily chosen.

> I wonder how multiple cards would work? Heck, with all three of my NuBus
> slots filled with these cards I could have 14 tty's! Who needs this many
> serial ports? :)

You could become an ISP!

Take care,

Bill