-
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
Trash80toHP_Mini
NIGHT STALKER
Dunno if there's a speed or bus contention/overhead hit over the very slow SCSI bus, but driver development would be a more serious problem I would think.
techknight
Well-known member
See that still does not answer my question. the card has to know how to decode and know where it is on the bus.
Lets say I write a small program to peek/poke the address space for Slot E. the card is going to respond in that address space. The only way that is possible is if Slot E has an address strobe that comes prior to the card, or the card itself decodes the address bus.
However I know PDS doesnt have slot-based address strobes. IRQs have nothing to do with addressing when selecting to speak to a peripheral on the bus. Its meant to grab the processors attention so the card can do its thing.
Last time I checked the the address strobe and data strobe on the PDS slot is global. so the card itself has to decode what the address is on each strobe so it can respond if the bus transfer is in the correct slot space.
THATS where I am confused here.
jamesmilne
Active member
I would be very interested in collaborating on this. I have been wondering exactly the same thing over the last couple of weeks.
I recently acquired another SE/30 which I have recapped and it's running great, but I don't have working Ethernet yet. I have a Technology Works SE/30 PDS Ethernet card, which I have tried in the SE/30. TattleTech reports it as present, it shows up in MacTCP etc but I can never get a link on it. Ethernet cards for the SE/30 appear to be fairly rare, and some people are charging silly money for them on eBay.
I'm sure you've read this already?
http://dec8.info/Apple/Designing_Cards_and_Drivers_for_the_Macintosh_Family_2ed_May90.pdf
I was thinking about using a Lattice FPGA to do the PDS bus interfacing, and either sourcing another 10BaseT Ethernet chip, implementing Ethernet on the FPGA, or maybe interfacing with something more powerful like an ARM microcontroller to also do other stuff: USB? HDMI out? Mass storage that's as fast as the PDS bus?
If one were to use the 8390 we could reuse the existing Ethernet drivers. Alternatively we'd have to write our own. I'm a software engineer and quite fancy the challenge, and the company I work for has several electronics & FPGA engineers I could probably lean on for some assistance
I recently acquired another SE/30 which I have recapped and it's running great, but I don't have working Ethernet yet. I have a Technology Works SE/30 PDS Ethernet card, which I have tried in the SE/30. TattleTech reports it as present, it shows up in MacTCP etc but I can never get a link on it. Ethernet cards for the SE/30 appear to be fairly rare, and some people are charging silly money for them on eBay.
I'm sure you've read this already?
http://dec8.info/Apple/Designing_Cards_and_Drivers_for_the_Macintosh_Family_2ed_May90.pdf
I was thinking about using a Lattice FPGA to do the PDS bus interfacing, and either sourcing another 10BaseT Ethernet chip, implementing Ethernet on the FPGA, or maybe interfacing with something more powerful like an ARM microcontroller to also do other stuff: USB? HDMI out? Mass storage that's as fast as the PDS bus?
If one were to use the 8390 we could reuse the existing Ethernet drivers. Alternatively we'd have to write our own. I'm a software engineer and quite fancy the challenge, and the company I work for has several electronics & FPGA engineers I could probably lean on for some assistance
Trash80toHP_Mini
NIGHT STALKER
Not at all sure it works the way you're looking at it, but not wedded to the way I'm looking at it either.
Dunno, but there may be a way to test what's going on. I think the driver is the key to decoding, not the NIC.
Still not sure where this is going. The IRQ connected to the NIC tells Slot Manager where the card's located. The address bus is common to all cards, PDS or NuBus, the LC PDS only has /SLOTIRQ.E and the card is detected there at startup. Slot Manager handles the addressing to Slot $E. I could be wrong, but I don't think the card cares or needs to know which slot it's in. That theory could be tested by buzzing the jumper connections on an 030 NIC. If all the three jumpers do is provide /SLOTIRQ info to the CPU a/o gate the connection to the proper pin on the 030 PDS that's one thing. That's my guess.
Address and Data are simple buses, but the CPU/Slot Manager chooses which address range to map a card based upon where it's detected at startup per its slot/irq encoding. Is a NIC really that intelligent? I was figuring that the drives would be what does any decoding, tossing the ball to the card and configuring the NIC to toss it back within parameters specified by the driver?
You're in good company there! :lol: We got any Inside Macintosh wizards to chime in here?
We're sticking the NIC on an adapter that's hooked up to any of three /SLOTIRQ locations and hoping the drivers for the NIC will handle it in the manner the Mac and Slot Manager handle NuBus Slots, but at the PDS level.
techknight
Well-known member
None of it makes any sense to me. the card has to have some address decoding level built in or otherwise the card would swamp the bus on every call and it would never boot. The card has to tri-state itself until it becomes active in whatever address space its designed for.
What I cant seem to get through my thick head is how the address range of the card gets assigned, or if its hard coded to the card. Otherwise if the card isnt listening at all on any address space if its not been assigned, then you have a chicken and the egg problem. you cant talk to the card to set its address space.
my brain hurts. What I have learned about computer architectures over the years means that in a memory mapped IO system, each peripheral card has to know where its existence is on the bus otherwise it cant decode the address space, and it cant listen to any commands.
Toggling an IRQ doesnt help here. Last time I understood IRQs is its a 1-way system. the card itself toggles the IRQ when its ready to send or recieve something across the bus. So the interrupt vector handler calls the address space thats mapped to that IRQ, and once the bus gets to that address space, the card has to decode it for its "chip select" in order for it to DO anything.
What I cant seem to get through my thick head is how the address range of the card gets assigned, or if its hard coded to the card. Otherwise if the card isnt listening at all on any address space if its not been assigned, then you have a chicken and the egg problem. you cant talk to the card to set its address space.
my brain hurts. What I have learned about computer architectures over the years means that in a memory mapped IO system, each peripheral card has to know where its existence is on the bus otherwise it cant decode the address space, and it cant listen to any commands.
Toggling an IRQ doesnt help here. Last time I understood IRQs is its a 1-way system. the card itself toggles the IRQ when its ready to send or recieve something across the bus. So the interrupt vector handler calls the address space thats mapped to that IRQ, and once the bus gets to that address space, the card has to decode it for its "chip select" in order for it to DO anything.
Last edited by a moderator:
techknight
Well-known member
Interestingly, I found this:
http://www.textfiles.com/bitsavers/pdf/national/_appNotes/AN-0752.pdf
And then https://www.ebay.com/itm/ASANTE-TECH-09-00024-05D-MACLC-III-MAC-NUBUS-ETHERNET-ADAPTER/282956389535?_trkparms=aid%3D222007%26algo%3DSIM.MBE%26ao%3D2%26asc%3D50999%26meid%3Dfbc783d966f34849bc877076ea5f9062%26pid%3D100005%26rk%3D1%26rkt%3D2%26sd%3D183214747945%26itm%3D282956389535&_trksid=p2047675.c100005.m1851
Same ethernet IC used in alot of the LC ethernet cards. Studying that appnote pretty much proves my line of thinking. the IC cant decode any addressing, however it has registers that need to be addressable. So it shows in a system diagram the address decoders necessary to select the chip for access for the PC architecture specifically, but it shouldnt be any different for any other system. So you need address decoding PALs for Slot E or whatever slot necessary.
true nubus cards have an extra chip. Chances are that chip has software configurable address decoding.
http://www.textfiles.com/bitsavers/pdf/national/_appNotes/AN-0752.pdf
And then https://www.ebay.com/itm/ASANTE-TECH-09-00024-05D-MACLC-III-MAC-NUBUS-ETHERNET-ADAPTER/282956389535?_trkparms=aid%3D222007%26algo%3DSIM.MBE%26ao%3D2%26asc%3D50999%26meid%3Dfbc783d966f34849bc877076ea5f9062%26pid%3D100005%26rk%3D1%26rkt%3D2%26sd%3D183214747945%26itm%3D282956389535&_trksid=p2047675.c100005.m1851
Same ethernet IC used in alot of the LC ethernet cards. Studying that appnote pretty much proves my line of thinking. the IC cant decode any addressing, however it has registers that need to be addressable. So it shows in a system diagram the address decoders necessary to select the chip for access for the PC architecture specifically, but it shouldnt be any different for any other system. So you need address decoding PALs for Slot E or whatever slot necessary.
true nubus cards have an extra chip. Chances are that chip has software configurable address decoding.
Last edited by a moderator:
techknight
Well-known member
This should help as far as how drivers work for the once so common DP83902
http://www.osdever.net/documents/WritingDriversForTheDP8390.pdf
For people like me who really dont understand mac programming hardly at all, it would be far easier for me to emulate a DP83902 instead of writing custom drivers for something new.
http://www.osdever.net/documents/WritingDriversForTheDP8390.pdf
For people like me who really dont understand mac programming hardly at all, it would be far easier for me to emulate a DP83902 instead of writing custom drivers for something new.
Trash80toHP_Mini
NIGHT STALKER
Could be built into the LC NIC, but that's not really necessary as there's but the one PDS/Slot ID in that architecture, so it might assume it's where it's supposed to sit.
Good point, the NuBus transceivers probably do that housekeeping depending on slot assignment coding detected at startup.
I thought it was the CPU and Slot Manager that loaded info from any card into the correct memory space. AFAIK cards don't access memory directly in 68k Mac architectures, wouldn't that be DMA?
Cool, sorry I didn't say welcome to the insanity in here earlier, I was on my lunch break, no time.
Yep, been studying the bound paper volumes for freakin' evah! Still clueless . . . :blink:
A SCSI 2 HDD controller/NIC would be a rockin' SE/30 project. :approve:I was thinking about using a Lattice FPGA to do the PDS bus interfacing, and either sourcing another 10BaseT Ethernet chip, implementing Ethernet on the FPGA, or maybe interfacing with something more powerful like an ARM microcontroller to also do other stuff: USB? HDMI out? Mass storage that's as fast as the PDS bus?
If one were to use the 8390 we could reuse the existing Ethernet drivers. Alternatively we'd have to write our own. I'm a software engineer and quite fancy the challenge, and the company I work for has several electronics & FPGA engineers I could probably lean on for some assistance
techknight
Well-known member
There in lies my point. the CPU cant access the card if the card isnt setup to decode addresses where it is sitting on the bus. On a PDS card for the LC at least, it would have to be hard-coded to see addressing in slot E space. If the CPU/Bus cant see the card because the card isnt decoding addresses, then the machine wont know its there.
Same deal with the DeclROM. it has to be sitting within that address space so Slot Manager can see it. That is where the address decoder comes in. Nubus cards it would be better explained because its address is determined on which slot its in. each slot has a select line to identify its addressing space by the NUCHIP. So when the CPU's ALU lands in say Slot A, the NUCHIP decodes this and enables the correct slot so whatever is in that slot can respond so the NUCHIP does the decoding and not the card itself.
PDS is a different animal and its gotta be defined at a low level hardware level of the card itself. Otherwise none of it makes sense.
Last edited by a moderator:
Trash80toHP_Mini
NIGHT STALKER
By definition, the LC PDS card already "knows" it's in Slot $E because that's the ONLY slot supported in the LC's hardware/architecture. Neither CPU nor Card needs to be informed of the Slot Manager/system state.
Pretty sure your NuBus select line is implemented in the setup as described below. I'm thinking you may be seeing this more in terms of the ISA slot setup? EISA was kludged to mimic the flexibility of NuBus.
Single card LC PDS and triple card SE/30/IIsi 030 PDS implementations are very different animals in this regard. That low level hardware state is defined on the card using the configuration jumpers on the card itself. That's the mechanism we're trying to implement on the LC Slot to 030 Slot adapter.
Pretty sure we're both talking about the same thing from two different perspectives. You're looking at it at a much higher level and I see it in terms of electron plumbing. A toilet simile or metaphor would work well on an earthy level here.
In this exchange, you're helping me see how the addressing works on PDS. I can elaborate on how the NuBus interface is plumbed. You're helping me visualize the setup from the output standpoint of the card.
NuChip/CPU/Slot Manager setup knows what address range it's polling for DeclROMs in each slot in succession. The NuBus card is informed in which of sixteen slot locations in which it sits by four bits set at the slot level on the motherboard. This diagram represents how to change the IIsi NuBus adapter's Slot $9 into Slot $A on my twin slot IIsi NuBus Adapter hack.
View attachment 11017
The jumper setup on this adapter diagram is more complex than it needs to be because I'm using the same board (the wire wrap protoboard is sitting next to me with its Futura IISX VidCard/NIC daughtercard in the lower NuBus Slot as I type
h34r: ) to test adding a fourth slot to the IIcx for shiggles and gits. [] The adaptation will be done in traces on the next iteration of the design.The three bit 030 PDS equivalent would be the two slot configuration jumper setup on each card which enables PDS to daisychain where NuBus provides multiple slots. The IIsi NuBus Adapter constricts this architecture to a single slot implementation, which just cannot remain unchallenged, even if it's been simmering on the back burner for six years. [}
] In this thread, we're exploring the possibility of moving the three bit PDS equivalent on a NIC for that architecture onto an adapter for the LC NIC which has no need for such configuration due to the LC architecture itself.
My contention is that we can interject that pair of jumpers into the I/O setup of the LC NIC at the adapter level.
My theory is that the LC NIC would be nondenominational in terms of I/O because the architecture itself is monotheistic by design. To insert an LC NIC into the polytheistic architecture of the 030 PDS, the equivalent of the NuBus setup above needs to be set on the adapter and the LC NIC won't even be aware it's been converted to the polytheistic paganism that is the SE/30/IIsi 030 PDS . . .
. . . and the driver priesthood won't have a care in the world.
Last edited by a moderator:
techknight
Well-known member
All I know is the address has to be rejiggered on the LC card so it works on the SE/30 PDS.
The card's PALs think its decoding in slot "E" but the system sees it as otherwise because of a couple switched address lines.
thats all Im sayin.
The card's PALs think its decoding in slot "E" but the system sees it as otherwise because of a couple switched address lines.
thats all Im sayin.
Trash80toHP_Mini
NIGHT STALKER
I've started buzzing the address jumper setup on the Pivot II/IIsi to find out where the lines go to see if we can figure out what they do. Here's a link to a paper describing the address decoding you've been talking about on a DIO card designed for the LC: Data Acquisition System for Macintosh. I've had a copy in the LC floder with only the Service Source forever, still haven't found the infamous missing LC DevNote. Does anyone have that one? Might it be on a developer CD?
Very curious now about the possibilities of dumbing a 68020 PDS LC NIC down to the SE's 68000 PDS level.
Very curious now about the possibilities of dumbing a 68020 PDS LC NIC down to the SE's 68000 PDS level.
techknight
Well-known member
Thanks for the article but its a TL;DR. too much blah blah blah and not enough pictures :-(
Trash80toHP_Mini
NIGHT STALKER
YEP! Academics! :lol: One thing I took away from it was that one of the chips involved was a transceiver with a select line. WAG would be that the PAL(?) that's activating that line is hooked up as SLOT $E by default, but might be addressable as any of several Slot IDs by yanking on some other lines in its current form or replaced by one that's programmed with formulas to produce the three ID variable results we're suggesting?
LC 020 PDS NICs post date SE/30 030 PDS developments by 21 mos. given introduction dates. I figure it's reasonable that LC NICs might be 020 compatible subsets of existing SE/30 NICs. Why emasculate a time tested, shipping design unnecessarily by changing PAL parts or formulas? The decoding setup for the more capable SE/30 030 NIC could work just fine inan 020 function subset environment. If necessary at all, a Slot ID tweak might be trivial given the product timeline scenario?
All WAGS BTW. :blink:
LC 020 PDS NICs post date SE/30 030 PDS developments by 21 mos. given introduction dates. I figure it's reasonable that LC NICs might be 020 compatible subsets of existing SE/30 NICs. Why emasculate a time tested, shipping design unnecessarily by changing PAL parts or formulas? The decoding setup for the more capable SE/30 030 NIC could work just fine inan 020 function subset environment. If necessary at all, a Slot ID tweak might be trivial given the product timeline scenario?
All WAGS BTW. :blink:
Last edited by a moderator:
Bolle
Well-known member
How would I go about detecting what addressing mode the SE/30 is in from monitoring the address lines?
Ready to wire up something on my breadboard and have a GAL invert address lines 26 or 22 depending on which mode the SE/30 is operating to shift the card to slot $A
Interrupt is going to be wired to /IRQ2.
Ready to wire up something on my breadboard and have a GAL invert address lines 26 or 22 depending on which mode the SE/30 is operating to shift the card to slot $A
Interrupt is going to be wired to /IRQ2.
Trash80toHP_Mini
NIGHT STALKER
Not sure what you mean? Could you derive the information you need from the slot memory map ranges in the docs w/o the need to do any monitoring?
techknight
Well-known member
He means whether the machine is operating in 24-bit mode "dirty" or 32-bit clean mode.
Trash80toHP_Mini
NIGHT STALKER
Hrmmm, it never occurred to me to consider operation in 24bit mode? Target machines are 24bit capable, but I don't think anyone would want to run in 24bit?
techknight
Well-known member
True, but its something to think about especially when it comes to the card and how it handles the addressing.
Honestly I never thought about it.
Biggest reason I am following how and where this thread goes is I want to make my own peripheral cards eventually.
Would be nice to have an accelerator card with an ARM processor on-board that brings ethernet, wifi, USB, etc expandability to the Mac as well as a Webkit or Gecko rendering engine on-board to assist in browsing the web with ease.
Honestly I never thought about it.
Biggest reason I am following how and where this thread goes is I want to make my own peripheral cards eventually.
Would be nice to have an accelerator card with an ARM processor on-board that brings ethernet, wifi, USB, etc expandability to the Mac as well as a Webkit or Gecko rendering engine on-board to assist in browsing the web with ease.
Last edited by a moderator:
