Oh that's right, they built that weird custom IIfx-based server thingy, didn't they? Makes sense, I suppose.
-
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.
SEthernet and SEthernet/30: A new take on PDS Ethernet
- Thread starter halkyardo
- Start date
Also, while I'm here, a bit of an update! I have a kinda-sorta working driver!
It gets detected and loaded as it should, and the system doesn't crash at its mere existence, so that's very promising.
Using the card with MacTCP, all seems to work as it should, it sends and receive packets and generally behaves like an Ethernet card ought to. I've had it displaying a bunch of simultaneous Telnet sessions without a hitch.
AppleTalk is a bit trickier, however. At boot it does the initial address-setup exchange of packets quite happily, but if I try to actually do anything meaningful with it (e.g. open AppleShare in the Chooser or start an application that uses Appletalk), the program counter goes off into the weeds and I get all sorts of exciting and novel crashes. I'm assuming that my ReadPacket/ReadRest callbacks are misbehaving in some kind of way - they involve some extremely specific and convoluted register-passing conventions, but I've stared at them for hours and can't figure out where I'm going wrong. I'm sure that it'll be blatantly obvious once I see it through...
If anyone wants to look at my code andpoke fun at review it and see if you can see what I'm doing wrong, I've pushed my latest WIP up to github at https://github.com/rhalkyard/SEthernet. The ReadPacket implementation in particular is at https://github.com/rhalkyard/SEthernet/blob/main/software/driver/readpacket.S.
I've also discovered another hardware bug, and it's a really annoying one: the ENC624J600 has no hardware reset input - the only way to reset the chip is either to power-cycle it, or by writing to a register. This means that if you reboot the machine while it's active, and a packet happens to come in before the driver is loaded again, you'll get a spurious interrupt causing a Sad Mac or a crash. I've mitigated this somewhat by disabling receive interrupts if all protocol handlers are unloaded (as seems to happen during shutdown), but that won't help if the reset button gets pressed.
I think the only way to properly get around that issue would be in hardware. The somewhat inelegant solution I'm contemplating is to gate the interrupt line from reset, until the glue logic sees two write accesses to the chip, which would indicate that the driver has done the right register-poking to initiate a reset and put the chip in a 'safe' state.
It gets detected and loaded as it should, and the system doesn't crash at its mere existence, so that's very promising.
Using the card with MacTCP, all seems to work as it should, it sends and receive packets and generally behaves like an Ethernet card ought to. I've had it displaying a bunch of simultaneous Telnet sessions without a hitch.
AppleTalk is a bit trickier, however. At boot it does the initial address-setup exchange of packets quite happily, but if I try to actually do anything meaningful with it (e.g. open AppleShare in the Chooser or start an application that uses Appletalk), the program counter goes off into the weeds and I get all sorts of exciting and novel crashes. I'm assuming that my ReadPacket/ReadRest callbacks are misbehaving in some kind of way - they involve some extremely specific and convoluted register-passing conventions, but I've stared at them for hours and can't figure out where I'm going wrong. I'm sure that it'll be blatantly obvious once I see it through...
If anyone wants to look at my code and
I've also discovered another hardware bug, and it's a really annoying one: the ENC624J600 has no hardware reset input - the only way to reset the chip is either to power-cycle it, or by writing to a register. This means that if you reboot the machine while it's active, and a packet happens to come in before the driver is loaded again, you'll get a spurious interrupt causing a Sad Mac or a crash. I've mitigated this somewhat by disabling receive interrupts if all protocol handlers are unloaded (as seems to happen during shutdown), but that won't help if the reset button gets pressed.
I think the only way to properly get around that issue would be in hardware. The somewhat inelegant solution I'm contemplating is to gate the interrupt line from reset, until the glue logic sees two write accesses to the chip, which would indicate that the driver has done the right register-poking to initiate a reset and put the chip in a 'safe' state.
Last edited:
And after a LOT of head-scratching, victory! I was able to mount a share and copy files over the network, using a card I designed, and a driver that I wrote! Naturally, the very first thing I copied was an updated build of the driver.
Turns out, the convoluted receive logic that I'd spent weeks scrutinising was is just fine (at least once I'd gone over it with a fine-toothed comb and fixed a bunch of bugs along the way). The real bug was in my handling of asynchronous driver calls for transmitting packets. I'm still not entirely sure *what* I'm doing wrong there, but on a hunch I rewrote the transmit routine to just busy-wait until the chip signals completion (rather than return immediately and call IODone when the interrupt handler sees a transmit-complete interrupt) and it more or less started working!
I still want to get async transmit working, since from what I can gather it's the Right Thing To Do for various performance and stability reasons (it's possible for the transmit routine to take a receive interrupt, which queues another transmit, which then gets interrupted, queues another transmit, and so on and so on until the stack crashes into the heap and everything explodes), but hey, I'm calling it a win!
Still got a way to go before it's ready for prime time - it's got a tendency to lock up the system under heavy load (potentially due to that stack overflow scenario), a few features aren't implemented yet, and performance is definitely suboptimal, but I am absolutely over the moon with this progress - especially coming right at the point where I'd run out of ideas and thought I was going to have to step away from it for a bit to clear my head.
Turns out, the convoluted receive logic that I'd spent weeks scrutinising was is just fine (at least once I'd gone over it with a fine-toothed comb and fixed a bunch of bugs along the way). The real bug was in my handling of asynchronous driver calls for transmitting packets. I'm still not entirely sure *what* I'm doing wrong there, but on a hunch I rewrote the transmit routine to just busy-wait until the chip signals completion (rather than return immediately and call IODone when the interrupt handler sees a transmit-complete interrupt) and it more or less started working!
I still want to get async transmit working, since from what I can gather it's the Right Thing To Do for various performance and stability reasons (it's possible for the transmit routine to take a receive interrupt, which queues another transmit, which then gets interrupted, queues another transmit, and so on and so on until the stack crashes into the heap and everything explodes), but hey, I'm calling it a win!
Still got a way to go before it's ready for prime time - it's got a tendency to lock up the system under heavy load (potentially due to that stack overflow scenario), a few features aren't implemented yet, and performance is definitely suboptimal, but I am absolutely over the moon with this progress - especially coming right at the point where I'd run out of ideas and thought I was going to have to step away from it for a bit to clear my head.
Attachments
zigzagjoe
Well-known member
You've come a long ways very quickly. Fantastic work!
Lack of a reset pin does seem like a silly decision.... You probably could (ab)use the chip's power on reset, though. Use a voltage regulator with a /shutdown pin and feed the system /reset into that. Or use a FET to switch power to the chip. Feels bad, but should work....
twelvetone12
Well-known member
This is so cool, well done!
cheesestraws
Well-known member
*applause* :-D
cheesestraws
Well-known member
SE - no slot manager = no declrom
zefrenchtoon
Well-known member
Hi everyone 
I'm interested by your work on SEthernet for my SE and there is something that I would like to understand if one of you know ...
If I correctly understood, because the SE has no slot manager, the SEthernet can not have a DeclROM and so, it can't be "daisy-chained" with another expansion card.
So, how Radius did its trick to daisychain an accelerator with a video card or a KanjiTalk card ?
I know that another accelerator maker (Interware ?) did the same thing on some of their accelerator (give access to a daisychain port)
Sorry if my question is stupid, I'm new to many of this.
I'm interested by your work on SEthernet for my SE and there is something that I would like to understand if one of you know ...
If I correctly understood, because the SE has no slot manager, the SEthernet can not have a DeclROM and so, it can't be "daisy-chained" with another expansion card.
So, how Radius did its trick to daisychain an accelerator with a video card or a KanjiTalk card ?
I know that another accelerator maker (Interware ?) did the same thing on some of their accelerator (give access to a daisychain port)
Sorry if my question is stupid, I'm new to many of this.
Phipli
Well-known member
Not having a declROM just means you have to know, or test for, what is there. There isn't anything stopping you have a dual or more function card, it just doesn't use Slot Manager to automatically detect things. It's a manual process for the developer and likely that only setups designed to be mutually compatible will reliably work.Hi everyone
I'm interested by your work on SEthernet for my SE and there is something that I would like to understand if one of you know ...
If I correctly understood, because the SE has no slot manager, the SEthernet can not have a DeclROM and so, it can't be "daisy-chained" with another expansion card.
So, how Radius did its trick to daisychain an accelerator with a video card or a KanjiTalk card ?
I know that another accelerator maker (Interware ?) did the same thing on some of their accelerator (give access to a daisychain port)
Sorry if my question is stupid, I'm new to many of this.
It also means no magic drivers that load early in the boot process... Well, I think I remember there was some way you could hook things in but not as well as with Slot Manager.
The only thing is you have to make sure things don't clash, mostly in address space. Some accelerators provide RAM, video, ethernet and SCSI on one board for things like the 512k Mac or Plus (improved SCSI over the Plus' offering).
cheesestraws
Well-known member
About the same way you'd do it with the slot manager, it's just a more manual process. The accelerator needs not to collide with the resources that the other card is using. The Radius MagicBus slot specifically doesn't pass through some signals: I'm unclear whether these are signals that the accelerator uses so aren't available to the downstream card, or whether it's just so that their connector will fit through the hole in the chassis, but you get what I mean. What not having the slot manager means is that you can't just use two arbitrary cards.
edit: @Phipli beat me
Last edited:
zefrenchtoon
Well-known member
Thanks @Phipli & @cheesestraws ! 
So I can definitely abandon the idea to stack multiple cars in my SE as some do in their SE/30
@cheesestraws I will try to check precisely the board that came with my Radius video card to use it without the accelerator to see if there are signals that are not passed through it. (Maybe someone has already done this check)
So I can definitely abandon the idea to stack multiple cars in my SE as some do in their SE/30
@cheesestraws I will try to check precisely the board that came with my Radius video card to use it without the accelerator to see if there are signals that are not passed through it. (Maybe someone has already done this check)
Phipli
Well-known member
I don't think that is what either of us said, the cards just have to not conflict with each other. Usually by design.
Unless you actually mean car, in which case I don't think even a single Peel P50 would fit in an SE.
cheesestraws
Well-known member
If it's the magicbus, I already did it - search for magicbus pinout here
Let's not derail this thread though, if you want to talk about this we should create a new thread for it
Yeah, it's a real pain! I suspect they just ran out of pins. I don't think there's a single pin on that package that I'm not using!
I've thought about the power-cut approach too, my big concern about it would be making sure that power stays off for long enough to fully reset the chip - the datasheet is rather vague on the relevant specs there, so it'd probably be a case of having to figure it out experimentally.
Disabling the chip's interrupt line in the glue logic until the driver has signaled that it's ready feels pretty bad too, although Macs pull a similar trick to temporarily map ROM into RAM during early boot, so I don't feel *too* guilty about using it.
Funny you mention that, I threw together a PrimaryInit routine to try that as an experiment, but I've been too lazy to pull the ROM out and reprogram it
. It's not clear to me exactly when in the boot process the Sad Mac happens relative to when PrimaryInit code runs, so I'm not quite sure if it would help, but it'd be an interesting experiment.For now, I've written a brute-force Shutdown Manager routine that resets the chip. It's not going to do any good on a system that's hung, but it does the job for a normal restart.
I still need to actually build the SE version of the card and get that working - just need to get my SE working first, as it suffered a hard disk failure the day before the boards arrived! As it turns out, the IIfx has been the ideal test mule for hardware bringup - much easier access to the PDS slot than on a Compact Mac, and its tighter timing specs have brought to light a few issues that I'd probably not have noticed otherwise.
I just took a look at the MagicBus pinout, and from what I can tell, a MagicBus version of the card is absolutely viable. If folks are interested, and someone with a suitable accelerator could assist with the development and testing, I'd be happy to collaborate. I'd like to get Revision 1 of the regular SE and SE/30 boards out of the way first, but keep reminding me about it!
That actually brings me on to another thing I've been thinking of - the issue of licensing. Right now I'd strongly recommend that against building or basing designs off of the Revision 0 design, just because it's not finished and Revision 1 will likely introduce some incompatible changes. But once that's done, I'd like to officially release the project under some kind of open hardware license. Based on interest, I'll likely do a small production run to sell, but if people want to build it themselves or adapt the design for their own projects, I'd like to encourage that. This is all new territory for me, so if anyone's been through this already with a hardware project, I'd really appreciate any wisdom or pointers - at this point I'm not even sure which license to choose.
For my *FPGA I picked CC BY-NC-SA 4.0 for the hardware (SW is straight GPL). The non-commercial part is not so much to avoid third-party making and selling the design, but as a safety net against being asked to support subpar copies sold by third-parties. If someone wanted to make and sell them, they'd have to ask for a license first so you'd know who and what you're dealing with. I don't really have that problem has the cost of the combined FPGA board + carrier is prohibitive anyway but better safe than sorry
zigzagjoe
Well-known member
Datasheet says if voltage drops below Vpor, a power on reset would be generated. So you could use two transistors to push-pull the vdd input either to vdd or ground (via a low ohm resistor) to discharge the bypass capacitor quickly. Some math give how long that takes.Yeah, it's a real pain! I suspect they just ran out of pins. I don't think there's a single pin on that package that I'm not using!
I've thought about the power-cut approach too, my big concern about it would be making sure that power stays off for long enough to fully reset the chip - the datasheet is rather vague on the relevant specs there, so it'd probably be a case of having to figure it out experimentally.
Disabling the chip's interrupt line in the glue logic until the driver has signaled that it's ready feels pretty bad too, although Macs pull a similar trick to temporarily map ROM into RAM during early boot, so I don't feel *too* guilty about using it.
Funny you mention that, I threw together a PrimaryInit routine to try that as an experiment, but I've been too lazy to pull the ROM out and reprogram it
For now, I've written a brute-force Shutdown Manager routine that resets the chip. It's not going to do any good on a system that's hung, but it does the job for a normal restart.
I still need to actually build the SE version of the card and get that working - just need to get my SE working first, as it suffered a hard disk failure the day before the boards arrived! As it turns out, the IIfx has been the ideal test mule for hardware bringup - much easier access to the PDS slot than on a Compact Mac, and its tighter timing specs have brought to light a few issues that I'd probably not have noticed otherwise.
I just took a look at the MagicBus pinout, and from what I can tell, a MagicBus version of the card is absolutely viable. If folks are interested, and someone with a suitable accelerator could assist with the development and testing, I'd be happy to collaborate. I'd like to get Revision 1 of the regular SE and SE/30 boards out of the way first, but keep reminding me about it!
That actually brings me on to another thing I've been thinking of - the issue of licensing. Right now I'd strongly recommend that against building or basing designs off of the Revision 0 design, just because it's not finished and Revision 1 will likely introduce some incompatible changes. But once that's done, I'd like to officially release the project under some kind of open hardware license. Based on interest, I'll likely do a small production run to sell, but if people want to build it themselves or adapt the design for their own projects, I'd like to encourage that. This is all new territory for me, so if anyone's been through this already with a hardware project, I'd really appreciate any wisdom or pointers - at this point I'm not even sure which license to choose.
cards and drivers for mac II/se says this for timing.
A bit hacky but should be cheap to implement.
If you have pins on the glue logic that could be cleaner, as stateful logic isn't a new thing as you said. Though having to count multiple writes would rapidly expand number of IOs required.
