Apple Ethernet NB - does it deliver?

[olePigeon]

Ooo, that's cool.  If you were running a web server off a vintage Mac, I could see this card being pretty darn useful.

Or for network games.

Or distributed computing.

 

[Trash80toHP_Mini]

Interesting, I'll have to check mine. Has anyone seen documentation on implementing the ZIP DRAM?

 

[IIfx]

Interesting, I'll have to check mine. Has anyone seen documentation on implementing the ZIP DRAM?

Are you talking about the small amount of DRAM on the card? AFAIK that DRAM is dedicated to the card's 68000 for running the networking microkernel.

I did some heavy work today on the IIfx, scanning old photos with an Epson ES-600C tri-color lamp scanner. The resulting files were fairly large* but moving them over the LAN was fairly painless and surprisingly fast for 10BaseT.

*Around 8-15mb

 

[Trash80toHP_Mini]

I can't quite read it, looks like 4x 256K x 4 on board that you're using, but there are open ZIP sockets for an additional 4 TC514400 1M x 4 DRAM ICs.

 

[IIfx]

I had no idea that those are even called ZIP sockets! Thanks for sharing. I wonder if the card would even use the extra memory if equipped? It's not mentioned in the rather thick user manual.

 

[Trash80toHP_Mini]

Heh! It's a mystery so I can't help myself. I thought I had a couple of these cards, but they're not in the NIC box. Wonder if one might be in the pet IIfx?

Dunno, the card's a computer. My first guess was that it'll likely "just work" when the quintupled(?) memory is tested at boot time if it's going to work at all but now I'm really curious.

< snip >

LOL, forgot the CPU was SMT Quad-somethingorother and was thinking it was that socketed ROM. =8-/ Only on my second mug of coffee, but here's what I got:

-  are there other(later?) versions of what I'm assuming is that DeclROM/CPU ROM combo?

-  -  there may or may not be support for the ZIP DRAM on board?

-  revisions of A/Rose could well override the stock ROM and add needed support for upgraded memory?

What's the designation on those fuzzy lookin' memory chips?

I've got fleeting visions of using A/Rose as the driver for PDS shenanigans bouncing around in my noggin  .  .  .  but I'm beginning to wake up  .  .  .

 

[IIfx]

What's the designation on those fuzzy lookin' memory chips?

I will report this next time I have the IIfx apart, they are Okidata brand chips. Perhaps it's listed in the manual for the NB, I will check that too.

As for newer CPU/DeclROMs I doubt it. I haven't seen many different revisions of the Apple Ethernet NB. There is a much newer version from around 1994 that lacks the 68000 CPU and memory, making it a plain SONIC chip Nubus card with dedicated bus transceiver chips. That card would have different ROM's but it's a completely different product with the same name tacked onto it.

Your assumption about the networking microkernel OS just using the additional memory is probably right, as those ZIP sockets likely are hanging off of the 68000 memory bus. We have no visibility into the workings of said microkernel OS. Perhaps there is a way to query the microkernel via A/ROSE?

We need to dig up the A/ROSE developer documentation to know for sure.

 

[Trash80toHP_Mini]

Yep, gotta check the docs. My ludicrous WAG for yesterday involved using A/ROSE as the driver for 030 PDS I/O cards. Wedging a "networked" RAM disk a/o SCSI 2 controller on that I/O channel in all its 16MHz-40MHz flavors would be wicked fast. No NuBus MUX or 10MHz throughput complications/limitations.

The pet IIfx has SCSI 2 on board already, but lacks a card for its PDS. Mine's a skunkworks SR-71 Blackbird. h34r:

 

[CharlesT]

It's been very interesting following this thread. I was involved in a design using the Sonic in the mid 90's. While a fine chip, it's main shortcoming is it only has a 16 byte buffer. So it would generate an interrupt once for every 16 bytes of your typical 512 byte packet, each of which of course your main processor would have to service via an ISR. So your main processor is spending a major chunk of it's time just servicing these interrupts and doesn't have much time left for anything else.

So with this A/rose design, if the interrupts are reduced to, say,  just once per packet (and it could even be less than that) you can imagine how much more responsive your main CPU would be. This works both ways because for outgoing data the main CPU as to keep that tiny 16 byte buffer filled as well. So the benefit isn't really in increasing overall data transfer rates, although it does help, but in increasing your overall system responsiveness, as your observations above clearly demonstrate.

 

[Gorgonops]

It's been very interesting following this thread. I was involved in a design using the Sonic in the mid 90's. While a fine chip, it's main shortcoming is it only has a 16 byte buffer. So it would generate an interrupt once for every 16 bytes of your typical 512 byte packet, each of which of course your main processor would have to service via an ISR. So your main processor is spending a major chunk of it's time just servicing these interrupts and doesn't have much time left for anything else.

Are you sure you're not thinking of a different chip? (16 bytes sounds a lot like the buffer size of the common 16550A UART.) For laughs I tracked down and downloaded the SONIC datasheet and it confirms my suspicions that it uses DMA to external RAM for packet receive/transmit. (It does have 32 byte tx/rx FIFOs to deal with asynchronous access to said RAM.) Said RAM can be either a dedicated SRAM on the interface card or a buffer carved out of main memory; the datasheet actually includes an example for interfacing with a motorola 68020/30 system bus.

(Honestly I doubt your typical late-80's-early-90's computer could keep up with sending an Ethernet packet in real-time using programmed I/O, or it would at least have a very difficult time of it.)

I'm curious if the implementation of SONIC on Mac ethernet cards used DMA to main memory or if they used a small SRAM; if it was the latter the computer may well be spending a lot of time filling and emptying that buffer, which would roughly amount to the same problem. MacOS was *bad* at using DMA for anything.

 

[CharlesT]

Well, it's been 20 years, and you have the data sheet, so it must be 32 bytes. But it was definitely the Sonic, and yes it can DMA the buffer contents. I'm sure I've since forgotten the finer details of it's operation. Our application was as a series of embedded controllers powered by a TI DSP and we designed the local bus using the Motorola bus protocol solely to use the Sonic.

 

[Gorgonops]

One of my favorite pieces of trivia from the NetBSD website is the little gem about how a common Ethernet card for the Sun2 (which is in the running for the weakest platform the OS runs on) had only 4K of buffer RAM on it, enough for only 2 maximum-size packets. This creates all sorts of lovely possibilities for a faster partner computer to overrun the buffer while the poor, slow Sun is emptying it. I wonder if something like that is the limiting factor for non-A/ROSE Nubus ethernet cards. (If nothing else the 512k of RAM on the A/ROSE card is *plenty* of buffer space for packets to pile up in. I am really curious exactly how much protocol offload, if any, the card is capable of on top of that.)

 

[CharlesT]

That's a very good question. It can't just buffer up a bunch of packets and just DMA them occasionally because the TCP/IP protocol requires ACKs and all sorts of other attention to the data stream which is handled by the TCP/IP stack. That is, unless the stack is fully implemented on the A/ROSE card, which could certainly be done with 512K of RAM. If that were the case there would be minimal bus traffic with the main CPU. Then it would just have to DMA big chunks of data as needed. But that would imply the TCP stack on the main board would be totally bypassed, and the A/ROSE would have to be configured with all the IP settings.

Splitting the stack between the two processors would be problematic (I'd prefer "nightmare"), so it seems to me it must just be providing a bigger buffer, but as you indicated earlier, you don't need a processor for that, just some memory and a DMA capability. So what is the 68K actually doing?

 

[Gorgonops]

That's a very good question. It can't just buffer up a bunch of packets and just DMA them occasionally because the TCP/IP protocol requires ACKs and all sorts of other attention to the data stream which is handled by the TCP/IP stack.

I wonder if it could be doing something "half-smart" where the 68k is running code that doesn't amount to a full networking stack but still offloads some analysis of the incoming packet headers, enough to distinguish data payload packets from those requiring immediate responses, allowing the system to let certain packets pile up in the buffer to be transferred to main memory "when convenient" while still responding in a timely manner with ACKs, etc...

Actually, that's an interesting point. The test IIfx specifically calls out when saying the card made the system more responsive was with AFP, not TCP/IP. olePigeon claims a small improvement for FTP (about 10 seconds faster over 2 minutes, which is less than 10%), but lacking more rigorous testing I wonder if the card does a lot better with AFP, which would be much easier for Apple to offload, than it is with TCP/IP.

 

[Trash80toHP_Mini]

YAY, I found one of my cards! Now to hunt down the elusive ZIP DRAM. h34r:

 

[eschaton]

To my knowledge, the card doesn’t accelerate the networking stack itself (though it could conceivably do so), it just handles buffering/DMA so the host CPU doesn’t have to do as much work. The System Software is still responsible for the AppleTalk and TCP/IP stacks.

This could conceivably be different for the Token Ring and SNA (3270) A/ROSE cards; it would have freed Apple from having to implement those protocols in the System Software.

 

[eschaton]

I have a number of the Apple Ethernet NB cards and recently purchased some ZIP RAM that *should* work with them. Unfortunately, at least in my Mac IIfx running System 6.0.8, the card just leaves its error light on with the RAM installed and never comes up. Unless the RAM itself is bad—it is old stock—something may need to be tweaked for the card to actually use it. The first batch I got was too slow, so for the second batch I tried to match the speed of the onboard RAM, but that still didn’t work. (Hope I didn’t do something stupid like put it in backwards…)

Has anyone disassembled its ROMs or otherwise reverse engineered the card? It should have both a declaration ROM and a ROM for its onboard CPU. (These could be combined via clever address decoding, of course.) That could tell us an awful lot about it.

 

[eschaton]

Just deciddd to double check in case I had put the RAM in upside down, and you know what? I had! When I inserted the ICs in the correct orientation the card came right up and worked to browse AppleTalk and IP ping another system from my IIfx.

I used four Toshiba TC514400AZ-60 512Kbit (1Mx4) chips, since the board has 514400 on its silkscreen and the onboard RAM is 70ns. They cost a couple bucks each on eBay, and got me 2MB of additional RAM on the card for 2.5MB in total.

 

[Trash80toHP_Mini]

Cool, have you noticed any difference yet? Got linkage to that ZIP DRAM?

 

[eschaton]

I’ve only spent about 5 minutes using it, I just did it in the middle of other stuff. I also just looked up the part number on eBay and found a seller, there are plenty (as well as the usual IC vendors).

 

[jeremywork]

I can't quite read it, looks like 4x 256K x 4 on board that you're using, but there are open ZIP sockets for an additional 4 TC514400 1M x 4 DRAM ICs.

I followed @eschaton's tip a couple years ago and bought these; they're still available: https://www.ebay.com/itm/362962163404

Then last week for posterity I also snagged the OEM kit: