Print

[jamesdenton]

Was rummaging through some of the Uniplus source code yesterday, and there are drivers for a 3com Ethernet device known as "EtherBox". It looks to be a self-powered external device that connected to the parallel port(s) of the Lisa and would have provided Ethernet connectivity within the Uniplus UNIX operating system.

Here is a PDF about the EtherBox at Bitsavers that refers to the Lisa: http://bitsavers.org/pdf/3Com/Etherbox_Sep83.pdf

Ran the relevant bits through OCR and tried to edit as best I could:

Code: [Select]

To: Larry Gardner
From:
Date: 27-May-83

Subject: Interrupt problems witn 3COM I/F
cc: Sunny Kirsten, Al Lem, Larry Birenbaum (c/0 3COM)
    K. Okin, J. Davis, F. Jones, D. Offen, J. well, B. Fox

This note sumarizes recent conversations between myself and 3COM engineering -
notably sunny Kirsten and Al Lem -- about problems with to tne E-Box vis-a-vis
interrupts.

Prior to my involvement, Frank Jones had put together a list of interrupt
related problems wnicn he had seen in nis testing of the E-Box. Since I was
mre concerned with the basic transmission aspects of the box, I had not tested
tne interrupt related hardware until recently. In conversations witn sunny
prior to this week, it seetred that the problems could be handled witn proper
software. However. upon looking at the problem earlier this week, we (Sunny, A1
and myself) feel that the problem gust be addressed in the 3COM box. I
suggested a solution over the pnone yesterday which they are analyzing to see if
that's the way they want to solve the problem.

The basic problem stems from the 6522 characteristics and tne manner in which it
must be used in our 2-port card. 3COM had been assuming that our board was
capable of "latching" Interrupt events on the 2-port card. Hence, they do not
latch the BSY line (used for interrupt control). Whenever the A-port of the
6522 Is accessed (as it must for data transfers), the interrupt flag gets
cleared inside of the 6522; this, in turn, prevents the 6522 from generating an
IRQ into the Lisa interrupt system.

Within the E-Box, the EDLC INT line is gated (via the E-Box's system Interrupt
Enable) directly to the BSY line. The EDLC keeps its INT asserted until someone
reads the corresponding status register. For transmits, tne Host (Lisa) reads
the Transmit Status Reg; hence, INT (BSY) will stay asserted. However, tne
E-Box always automatically reads receive status -- storing it into tne receive
buffer -- from tne EDLC. Hence, the INT (BSY) line is asserted for only a brief
instant -- on the order of 1-2 usec. This is just barely long enough for tne
6522 to sense thc edge-triggered CA1 line (coming in on BSY) and "latch" the
interrupt.

However, any activity occurring over the 2-port card (e.g., setting up a
transmit or reading the other receive buffer), will cause the latched Interrupt
condition to be cleared. This causes the interrupt to be "lost". This has been
noted by Sunny and is probably the source of problems noted by Frank.

My suggested solution is to include the RBSA* and RBSB* lines as terms in the
input to the interrupt gate. Thus, the BSY line would be asserted whenever SIE
is true and (the EDLC INT line is asserted or either receive buffer is available
to the Host). This, in effect, latches the receive interrupts within the E-Box.
BSY would go away when the Host (Lisa) reads tne Transmit Status Reg (in case of
a transmit conplete) or gives the receive buffer(s) back to the E-Box (for
receive interrupts).

(11:00, 27-May-83) me 3COM solution (as per conversations witn Al) will be to
actually latch the INT signal within the E-Box. This is the cleanest solution.

There is still a "minor" problem which rust be resolved by software. The BSY
interrupt is edge-triggered. Even with the suggested change, tne leading edge
of BSY could be "lost" due to the 6522 problem; this only happens when a
"driver" is using the I/F to talk to the E-Box. However, the state of the BSY
line is also readable via tne PB1 input. Since tne interrupt is latched
(assuming some change similar to that proposed above is made), the Host can
sense if BSY is asserted before waiting for an interrupt. If it always does
this after using the I/F, and "fakes" an interrupt, the interrupt will not get
"lost" and all will be well.

I talked with Al and Larry Birenbaum this morning. The current assumption is
that we can use the E-Box as currently implemented (using a software kludge
described below), but that they will fix the problem in a future board rev.
Thus, my feeling is that we can accept the delivery of the current design and
assume that the next scheduled set will have tne problem fixed in hardware
(within the E-Box).

The software kludge for existing E-Boxes involves checking, in software, tne
conditions in my suggestion to a hardware fix. I.e., after playing with the
I/F, tne software must poll both PB1 and ASR. If either PB1 is asserted or
either of the receive buffers has been given back to the Host (Lisa), then an
Interrupt must be faked. This is done by pushing a dummy interrupt status onto
the stack and jumping to tne entry of the interrupt handler. (I am enclosing a
copy of my code to do this as a sample.)

As of this note (11:00, 27-May-83), the above software "kludge" seems to be
effective. I have run my ecno test utilizing this interrupt "faking" and it
successfully runs without "dropping" interrupts.

Note, some problems noted by Frank may not be solved by this problem. This
solution addresses only those of "lost" Interrupts. That is, cases where the
E-Box correctly generates status but where the associated interrupt is not being
"caught". I suggest that Frank change his tests to include the kludge and test
the boxes again. Any problems not directly related to the "interrupt problem"
must be treated independently.

Anyway, what a neat piece of Lisa history!

[Lisa2]

Thanks James!
This type of post is exactly the kind of information LisaList2.com was created for.

While this implies that Lisa UniPlus may have had some support for ethernet at the frame level, did you see any evidence of higher level protocols they where using (I assume it was not TCP/IP)?

Rick

[jamesdenton]

Hi Rick,

There is evidence of greater Ethernet support as well as TCP/IP.

I've copied the source files from Bitsavers to GitHub and fixes the line feeds along the way:

https://github.com/arcanebyte/uniplus/tree/master/v1.5/sys

The TCP files are prefixed with 'tcp_'. The "net" headers are missing from the published source. There are also other header files missing from the published source, which leads me to believe that Apple-specific stuff was overlaid onto the base SysV source code UniSoft was working with. So I'm not able to recompile the kernel on an existing UniPlus install, yet.

James

[rayarachelian]

Yeah, if we can get a full TCP stack implemented, even over SLIP/PPP it would be really neat. I know there was one for SCSI on the MacWorks side, but that would need the SunRem SCSI card.

I wouldn't put too much consideration for ethernet over parallel, it would be pretty slow, though much faster than PPP, and much harder as it would require rebuilding that ethernet box, and then it would only work with UniPlus which is a very limited use case. But worth it only if there's a TCP stack. TCP/IP certainly did exist, the question is was there an implementation for UniPlus? They might have implemented other protocols instead, like Novell's IPX/SPX, depending on what was available in the late 80s, which would mean you'd have roll your own implementation instead, not very easy, though stealing from NetBSD might help.

I do recall that PC Parallel port ethernet devices did exist, I might even have one somewhere, and it's likely it's very similar, though the signals on those and the pinouts are much different. They can't get very close to 10MBps, not that ethernet was efficient enough to get anywhere above 50% - this was the era of HUBs not switches and high collision rates.

If they implemented MAC filtering on the chipset, it might work ok, and likely they had to - (the alternative would be that it would run in promiscuous mode which would send every packet to the driver for inspection and discard the ones not meant for it which would create a very high load on the kernel.)

Off the top of my head, I think the VIA6522s top out at about 650KBps or is it 650Kbps (~10x difference so the case of the B matters), so maybe that might be good enough to reach 50% of the bandwidth of 10BT or 10B2 which would make it workable.

There's a good discussion here, looks like it became available ~1989: https://www.cisco.com/c/en/us/about/press/internet-protocol-journal/back-issues/table-contents-55/151-25-years-ago.html
UniPlus has an interesting history, and it was likely also the basis of A/UX. (see: https://en.wikipedia.org/wiki/A/UX where it mentions UniSoft ported it for Apple) So if we can find the source code to a later Unixen than was related closely enough to UniPlus or A/UX, its TCP/IP stack will likely work out of the box. Otherwise early versions of NetBSD (which did support 68k) and the like are the best bets, but it will be an uphill battle. Sadly this doesn't show its full lineage: https://web.archive.org/web/20170831042833/http://www.graphviz.org/Gallery/directed/unix.svg

A word of warning though, please do not put any Unix enable Lisa directly on the internet whether UniPlus or Xenix, whether via ethernet or PPP or just a tty- there are likely security bugs in these old kernels that would easily allow someone to get root easily. At minimum there should be proxy infront of it, and a NAT for outbound traffic. tty access should be proxied via ssh running on another more secure box.

[rayarachelian]

"There is evidence of greater Ethernet support as well as TCP/IP."

Awesome!

[rayarachelian]

Actually since there is ethernet driver source code in UniPlus, it should be possible to use that and the bitsavers doc to build a driver for MacWorks, that would be really cool, and something like a modern day etherbox would be far more useful for Lisa owners, than if its just for UniPlus.

Chapter 11 of this will be very useful in writing drivers: https://archive.org/details/mac_Inside_Macintosh_Networking_1994
as will some of this: https://archive.org/details/Inside_Macintosh_CD-ROM_1995

I think there was an Inside Macintosh Drivers volume somewhere too, but I don't see it on archive.org (that's the 2nd generation of Inside Mac after Vols I-IV where they were distinct topics per books, like the above networking volume.) The original 4 vol set can be found here, which may have the needed info: https://www.pagetable.com/?p=50
This might help too: http://macintoshgarden.org/apps/designing-cards-and-drivers-the-macintosh-family
Looking at my physical dead tree books, I do have "Inside Macintosh Devices" (1994) which could be helpful as well as a ~200 double-sided page binder "Developer University Mini Course: Writing and Using Device Drivers Tutorial" (Oct 1994) - if someone can replicate the etherbox and gets close to being able to write a MacWorks System 6/7 ethernet driver, these would be very useful. I'll see if I can get these scanned in as they don't appear to be available online.

[jamesdenton]

The Apple-specific stuff in the Etherbox driver:
https://github.com/arcanebyte/uniplus/blob/master/v1.5/sys/if_eb.c#L741-L949

Maybe someone could build a board with one of these bad boys:
https://www.wiznet.io/product-item/w5100/

Much like the Apple II crowd has:
http://a2retrosystems.com/products.htm

I know Rick has/had one of the SCSI<->Ethernet adapters. I have one that I recently picked up but haven't tested. The problem I see with MacWorks is < System 6.0.3 probably doesn't offer much in terms of *working* PPP/SLiP and/or MacTCP implementations due to resource constraints - namely RAM.

But, if one was really looking for something to do... porting this and running in LOS would be a treat! https://github.com/ep00ch/lwip-contrib-mac

[rayarachelian]

If you can get 6.0.8 working on MacWorks, there is this:http://www.applefool.com/se30/Which says MacTCP 2.0.6 will work, otherwise 6.0.3 will only have MacTCP 1.0
I'm pretty sure it's going to be very hard to add TCP/IP to LOS, neither apps nor drivers, nor TCP/IP support exists for it (yet). But I'm not volunteering to do it.  I doubt it even has AppleNet support as I don't see any filenames for drivers that would indicate it does on LOS.

MacWorks and UniPlus would be the path of least resistance. And I'm even (pleasantly) surprised that UniPlus has a TCP/IP stack.Not sure about Xenix, but I'd lean towards believing that it has no TCP/IP support until it's proven otherwise, though perhaps it might be possible to port the code from UniPlus to it to make it work.

[Lisa2]

If you can get 6.0.8 working on MacWorks, there is this:http://www.applefool.com/se30/Which says MacTCP 2.0.6 will work, otherwise 6.0.3 will only have MacTCP 1.0
I'm pretty sure it's going to be very hard to add TCP/IP to LOS, neither apps nor drivers, nor TCP/IP support exists for it (yet). But I'm not volunteering to do it.  I doubt it even has AppleNet support as I don't see any filenames for drivers that would indicate it does on LOS.

Getting useable internet connectivity going on a common Lisa config (MW+, System 6.03, 1Meg RAM) is something I have been trying to achieve for a long time now.  The big problem (as I see it) is that useable (today at least) Macintosh internet applications did not really start hitting their stride till about the same time System 7 became available.  This (as Ray said) creates a quandary because MW+ is limited to System 6.03.

My understanding is that patching MW+ to support 6.08 is no simple task.  I know this because it has already been done, it's called MW+II!

While I do have SCSI ethernet adapters that work with MW+, I never use them any more, I much prefer using TCP/IP over LocalTalk (MacIP).  It's available on every Lisa, and there are many (low cost) options to deploy MacIP these days.

Rick

[jamesdenton]

Getting useable internet connectivity going on a common Lisa config (MW+, System 6.03, 1Meg RAM) is something I have been trying to achieve for a long time now.  The big problem (as I see it) is that useable (today at least) Macintosh internet applications did not really start hitting their stride till about the same time System 7 became available.  This (as Ray said) creates a quandary because MW+ is limited to System 6.03.

My understanding is that patching MW+ to support 6.08 is no simple task.  I know this because it has already been done, it's called MW+II!

I agree that this is or will be difficult without some new development in this area. The WWW apps that are available for <= 6.0.3 are pretty buggy and hardly usable on today's Internet. Same goes for a lot of early System 7 stuff, for that matter. There is a version of NCSA Telnet that included its own TCP/IP stack and SLIP capabilities. But at the end of the day, you're still using Telnet.

While MacTCP and PPP and the like are certainly doable on the Plus and older system versions, the Plus/SE folks have the benefit of up to 4 MB RAM, which seems to be the difference maker in my experience.

While I do have SCSI ethernet adapters that work with MW+, I never use them any more, I much prefer using TCP/IP over LocalTalk (MacIP).  It's available on every Lisa, and there are many (low cost) options to deploy MacIP these days.

Speaking of... how are you liking the Gatorbox?

[Lisa2]

Speaking of... how are you liking the Gatorbox?

What is not to like about the Gatorbox, it is an enterprise class Ethernet-Localtalk gateway that does all the TCP/IP magic I will ever need. 

My point was that there are many MacIP solutions (many open source or freeware) available today for anyone who wishes to experiment with TCP/IP over localtalk.

Rick 

[D.Finni]

Try MacIP by Tim Maroney. Source is in Lisa Pascal.

MacIP: Macintosh Internet Protocols 1985
MacIP Sources and Applications - download the Zip archive

[jamesdenton]

Try MacIP by Tim Maroney. Source is in Lisa Pascal.

MacIP: Macintosh Internet Protocols 1985
MacIP Sources and Applications - download the Zip archive

Definitely worth a read - thanks for posting!