-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
Mac SE/SE/30 Ethernet Card Recreation
- Thread starter IlikeTech
- Start date
techfury90
Well-known member
Basing it on an existing card is a terrible idea. Many of the chips used on those cards are no longer available, nor do they even make sense to use today with the introduction of more integrated Ethernet controllers, e.g. Cirrus CS8900A.
This guy has a goal of emulating cabletron SCSI ethernet + maybe others. Plus the device can probably also act as a disk drive at the same time.
I also mentioned Scuzzygraph emulation and he seemed interested in that as well....
Also basing something on something that already exists is a valid response in many cases... especially if the software/drivers for it already exists.
https://hackaday.io/project/18974-tiny-scsi-emulator
I'm a big fan of the the SCSI2SD but this one might have it's own niche as well... note that this uses a vintage NCR 5380 controller so isn't so much of a SCSI emulator as a multi personality SCSI device emulator...
I also mentioned Scuzzygraph emulation and he seemed interested in that as well....
Also basing something on something that already exists is a valid response in many cases... especially if the software/drivers for it already exists.
https://hackaday.io/project/18974-tiny-scsi-emulator
I'm a big fan of the the SCSI2SD but this one might have it's own niche as well... note that this uses a vintage NCR 5380 controller so isn't so much of a SCSI emulator as a multi personality SCSI device emulator...
Last edited by a moderator:
techfury90
Well-known member
5380? Seriously? Ugh. That chip was crap in 1990, and Apple kept hocking it for several years after the fact.
techknight
Well-known member
Sure the chips arnt available, but you can emulate the command set for those older ICs so you can use the existing drivers. Protocol translator IC.
I think 90% of the ICs these early machines used were NDIS or NE1000/2000 compliant.
I think 90% of the ICs these early machines used were NDIS or NE1000/2000 compliant.
techfury90
Well-known member
You're very close- most used the National Semiconductor DP8390 Ethernet chip. The NE2000 is essentially Novell's build of the DP8390 reference design from the datasheet.
Why not just write new ones? Have you ever looked at an Ethernet driver? I have. The Ungermann-Bass card for my IBM RT is made of pure unobtanium, so I decided to see about making a 3Com 3C509 work in it, since the RT just has normal ISA slots. The first thing I did was find the documentation for the 3C509 to get a feel for how drivers interact with it. It turned out to be quite simple: you basically just used a certain I/O port to send commands to, and another for reading/writing packets out of the controller's onboard buffers, and a few others for miscellaneous things like status. It didn't really sink in to me until I read the manual that Ethernet cards, for the most part, do precisely three things: send a packet, receive packets back, and report problems.
Most of the low level details are handled within the controller itself, you just load its buffer up with the packet you want to send, and then poke the command register to send it. When a packet comes in that matches its MAC, a group MAC, or a broadcast MAC (in normal usage), the controller fires off an interrupt when it receives the packet, you attach an interrupt handler in the driver to receive it, shut off the interrupt, then poll the status register to see what kind of interrupt it is (received packet, packet CRC error, collision detected, etc), then copies the contents of the packet from the controller's buffer into RAM, tells the controller it finished copying the packet, then repeat the status register poll, if no more work to do, switch the interrupt back on and exit the interrupt handler routine.
Most of the actual difficulties are handled further up the food chain by the networking stack, the driver's job is just to take Ethernet packets to/from the controller and the networking stack and report problems occurring (it's not expected to process them or take corrective action, just report them to further up the food chain)
That's it! If you've ever done microcontroller stuff a bit, particularly with interrupts, you pretty much know almost everything needed to write a network driver.
I'm not promising anything right now, but. I mention the CS8900A because I've read the chip's datasheet, it's readily available, and has a native 16 bit ISA interface. Everyone forgets that ISA is just a fairly typical 16 bit parallel handshaking-controlled asynchronous bus, not very far off from PDS at all, just slower. That's okay though, because the 68k bus works like that too, you just use DTACK to insert wait states (or rather, by holding off on DTACK). You just need to sort out a few control lines and decoding logic between the PDS bus and the network controller, plus the driver.
I mention this because I have been toying around with the idea of making new Ethernet cards for 68k Macs for the past two or three weeks.
Edit: also, NDIS is the Windows network card driver API. It's so simple that various open source OSes have "wrappers" that allow NDIS wrappers to run on them. That is how simple Ethernet drivers are.
Why not just write new ones? Have you ever looked at an Ethernet driver? I have. The Ungermann-Bass card for my IBM RT is made of pure unobtanium, so I decided to see about making a 3Com 3C509 work in it, since the RT just has normal ISA slots. The first thing I did was find the documentation for the 3C509 to get a feel for how drivers interact with it. It turned out to be quite simple: you basically just used a certain I/O port to send commands to, and another for reading/writing packets out of the controller's onboard buffers, and a few others for miscellaneous things like status. It didn't really sink in to me until I read the manual that Ethernet cards, for the most part, do precisely three things: send a packet, receive packets back, and report problems.
Most of the low level details are handled within the controller itself, you just load its buffer up with the packet you want to send, and then poke the command register to send it. When a packet comes in that matches its MAC, a group MAC, or a broadcast MAC (in normal usage), the controller fires off an interrupt when it receives the packet, you attach an interrupt handler in the driver to receive it, shut off the interrupt, then poll the status register to see what kind of interrupt it is (received packet, packet CRC error, collision detected, etc), then copies the contents of the packet from the controller's buffer into RAM, tells the controller it finished copying the packet, then repeat the status register poll, if no more work to do, switch the interrupt back on and exit the interrupt handler routine.
Most of the actual difficulties are handled further up the food chain by the networking stack, the driver's job is just to take Ethernet packets to/from the controller and the networking stack and report problems occurring (it's not expected to process them or take corrective action, just report them to further up the food chain)
That's it! If you've ever done microcontroller stuff a bit, particularly with interrupts, you pretty much know almost everything needed to write a network driver.
I'm not promising anything right now, but. I mention the CS8900A because I've read the chip's datasheet, it's readily available, and has a native 16 bit ISA interface. Everyone forgets that ISA is just a fairly typical 16 bit parallel handshaking-controlled asynchronous bus, not very far off from PDS at all, just slower. That's okay though, because the 68k bus works like that too, you just use DTACK to insert wait states (or rather, by holding off on DTACK). You just need to sort out a few control lines and decoding logic between the PDS bus and the network controller, plus the driver.
I mention this because I have been toying around with the idea of making new Ethernet cards for 68k Macs for the past two or three weeks.
Edit: also, NDIS is the Windows network card driver API. It's so simple that various open source OSes have "wrappers" that allow NDIS wrappers to run on them. That is how simple Ethernet drivers are.
Last edited by a moderator:
techknight
Well-known member
Um... You go ahead with that lol...
Driver isnt difficult, its interfacing with the rest of the OS from the driver's point of view which is fun. because MacTCP or Open Transport has to communicate with the driver somehow, so I assume the driver has to be written in such a way to be able to interface with that.
I think it might be easier to reverse engineer one and modify that.
But then again, its just easier to emulate a pre-existing chip so you can use the standard Apple Ethernet driver. Thats more compatible anyways. That way you can pick up the 7.5NAD disk and off you go. no 3rd party junk necessary.
Driver isnt difficult, its interfacing with the rest of the OS from the driver's point of view which is fun. because MacTCP or Open Transport has to communicate with the driver somehow, so I assume the driver has to be written in such a way to be able to interface with that.
I think it might be easier to reverse engineer one and modify that.
But then again, its just easier to emulate a pre-existing chip so you can use the standard Apple Ethernet driver. Thats more compatible anyways. That way you can pick up the 7.5NAD disk and off you go. no 3rd party junk necessary.
Last edited by a moderator:
techfury90
Well-known member
Have you even looked at the relevant documentation?
You don't need to emulate another card if you just shove the driver in DeclROM.
You don't need to emulate another card if you just shove the driver in DeclROM.
Perhaps unrelated -- Just out of interest -- does the 7.5 network access disk work with Ethernet that is not Apple branded or otherwise built onto the motherboard of supported Quadras and Power Macintoshes? Or would you need to add a third party driver to it anyway?
If you'd need to add a driver to it anyway, what does it matter if it's an existing Asante (or other) driver or a new one?
If you'd need to add a driver to it anyway, what does it matter if it's an existing Asante (or other) driver or a new one?
techfury90
Well-known member
It does, if the card has a DeclROM based driver. Not all do. I intend to include mine in DeclROM for this exact reason.
The reason you'd want a new one is that a) Ethernet drivers are NOT complicated (literally 1000-1500 LOC *max* for a simple one like a CS8900A), and b ) new driver development means we are no longer dependent on having to copy hardware that is getting harder and harder to find. This also opens the window to future possibilities. Making something else emulate an existing card adds significantly to the hardware BOM (aka cost), and massively increases the scope of hardware development. The trade-off is the software development requirement, but my opinion (and keep in mind, I write software for a living) is that it would take considerably less time to just build a driver from the documentation. This. Is. Not. Hard.
I for one think that we do not need to be cloning cards, but rather working towards independently-developed designs that can be adapted to changing component availability, etc.
The reason you'd want a new one is that a) Ethernet drivers are NOT complicated (literally 1000-1500 LOC *max* for a simple one like a CS8900A), and b ) new driver development means we are no longer dependent on having to copy hardware that is getting harder and harder to find. This also opens the window to future possibilities. Making something else emulate an existing card adds significantly to the hardware BOM (aka cost), and massively increases the scope of hardware development. The trade-off is the software development requirement, but my opinion (and keep in mind, I write software for a living) is that it would take considerably less time to just build a driver from the documentation. This. Is. Not. Hard.
I for one think that we do not need to be cloning cards, but rather working towards independently-developed designs that can be adapted to changing component availability, etc.
Last edited by a moderator:
techknight
Well-known member
techfury90
Well-known member
Did I not already make the implication that I'm working on it? 
techfury90
Well-known member
Inside Macintosh Volume VI is my friend. I found an electronic copy on an old Apple developer CD from 1990. VI is important because the specifications network drivers conform to start on page 32
Scott Squires
Well-known member
techfury90, this is great stuff. I wanted to do this, but didn't know how to start or learn how. Sounds like you've figured it out. Looking forward to reading about your progress!
Scott Squires
Well-known member
I actually bought a hardcopy of volume IV a week or two ago because I couldn't find it online. I don't know why I didn't think of checking the developer cds! Duh!
Still waiting for the book to arrive... media mail is slow!
Still waiting for the book to arrive... media mail is slow!
techfury90
Well-known member
I need to get a copy of IV for... reasons. There's some non-Ethernet features in my card that I have not revealed yet and probably won't until things move further along.
Right now, I haven't worked out the timeline or anything, but I've got the basic concepts covered- at this point it's a pile of notes on how the thing will work combined with a WIP schematic. Most of the component selection has already been done. Right now, I'm focusing on LC PDS, as that's kind of the lowest common denominator from which the design can be adapted to other slot types like SE PDS, SE/30 PDS, and NuBus. The former two are mainly just a board layout change, NuBus will be the trickier one. I'm also working on a future plan to consolidate LC PDS and NuBus compatibility onto the same board. I think it can be done mechanically with a suitably small card- just put the NuBus connector such that when the card is installed in a LC PDS slot, the NuBus connector hangs off to the right, looking at the front of the machine.
So basically, we're looking at the following left:
Right now, I haven't worked out the timeline or anything, but I've got the basic concepts covered- at this point it's a pile of notes on how the thing will work combined with a WIP schematic. Most of the component selection has already been done. Right now, I'm focusing on LC PDS, as that's kind of the lowest common denominator from which the design can be adapted to other slot types like SE PDS, SE/30 PDS, and NuBus. The former two are mainly just a board layout change, NuBus will be the trickier one. I'm also working on a future plan to consolidate LC PDS and NuBus compatibility onto the same board. I think it can be done mechanically with a suitably small card- just put the NuBus connector such that when the card is installed in a LC PDS slot, the NuBus connector hangs off to the right, looking at the front of the machine.
So basically, we're looking at the following left:
- Finish schematic
- Lay out prototype board and have it fabricated
- Experiment/develop with assembly processes (I have most of this already figured out, just haven't put it into motion)
- Develop device driver
- ???
- Profit!
