• 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

Melkhior

Well-known member
As a basic sanity check, with that SVF, pin 34 of the CPLD (brought out to test point TP6 on my board layout) should go high on any access to the card's address space (/AS going low with A31..24==F9 or whatever slot address you've chosen)
Unfortunately, I'm terrible at hand-soldering anything non trivial (which is 2.54mm through-hole, and 1.27mm through-hole at a push), and I seem to have burned or somehow damaged the actual testpoint that I did faithfully reproduce ;-( I should have just added a LED in there for JLCPCB to do for me.

I might attempt again if I solder a second board, but meanwhile...

Still waiting on a couple more parts for my logic analyzer breakout board, then I'll dig into my IIfx and see why it's not working on that.
I think that would be of interest to me as well, following the tests I've done (see below).

Another thing to check: does poking at the card's address space in MacsBug give you a bus error, or does it return data? There should be 24k of RAM starting at the card base address, and read-write registers at base+7e00 to base+7eff.
So with the 'full' SVF, that doesn't work - I get bus error everywhere. I just patched programRom [2] slightly rather than dropping into MacsBug, because I couldn't remember how to drop into MacsBug and it's easier to do in modern C anyway :)

So I decided to go back to basics, and redo the original CUPL code in a much simpler version (attached) that will just ACK any request, without bothering with details like ROM, Ethernet or anything else. Whenever /AS is asserted, it asserts a byte-sized ACK (/DSACK asserted) until the end of /AS and keep the OE enabled until the next /AS, as your design does [1].

With my simplified design, where I only ACK for standard slot $9, then the patched programRom see the slot $9 as OK. There's no bus error there. Bus errors are still present for other slots. That's the intended behavior of that test code, which is a good sign for the CPLD itself.

That's my current state. I've yet to figure out why i get bus error when using the full design, but with a seemingly working CPLD I can program, I'm more hopeful to get somewhere, if only to the reason of the failure. If it's timing-related, then it might be the same issue as you see with a IIfx.

[1] BTW I don't think the comment in the code that say DSACK are open-collector is correct. They have to be actively driven high ('negated') at the end of the cycle as per the manual of the MC68030. "In this manual, assertion and negation are used to specify forcing a signal to a particular state" ; "The device must remove its data and negate DSACKx within approximately one clock period after sensing the negation of AS or DS."
[2] I think there might be a bug in there; currently the induction variable in the loop in probe_slots() isn't used, so the code repeatedly probe the same address at offset DECLROM_OFFSET. I think the offset is meant to be the induction variable instead.
 

Attachments

  • test-u3.txt
    4.1 KB · Views: 6

halkyardo

Well-known member
I've had a chance to sit down and play with my logic analyzer tonight, and of course now I can't reproduce the issues that I was having with the card in my IIfx - it works just fine, I think I might have just forgotten to change the slot-ID jumpers when I said it wasn't working. Oops!

Looking at your working test CUPL, the main difference that jumps out to me is that the timing logic is removed - this logic is clocked from the CLKOUT pin on the ENC624J600, which is 4MHz at power-on and is configured to 25MHz by the driver. I wonder if the ENC624J600's input clock is missing and the timing logic is getting stuck and never allowing DSACK to be asserted.

[1] BTW I don't think the comment in the code that say DSACK are open-collector is correct. They have to be actively driven high ('negated') at the end of the cycle as per the manual of the MC68030. "In this manual, assertion and negation are used to specify forcing a signal to a particular state" ; "The device must remove its data and negate DSACKx within approximately one clock period after sensing the negation of AS or DS."
Indeed. I thought I'd got rid of all the mentions of DSACK being open-collector, but that one must have escaped.

[2] I think there might be a bug in there; currently the induction variable in the loop in probe_slots() isn't used, so the code repeatedly probe the same address at offset DECLROM_OFFSET. I think the offset is meant to be the induction variable instead.
Good catch. I think in the specific case of the SEthernet/30 card, it will still do the right thing (justg probing the lowest address of the declrom instead of the highest), but it's definitely not the generally-correct or intended behavior. programROM is a mess right now. I threw it together when I built my first board and didn't really look at it again once I'd got it to the point where it could program the flash successfully. I should really rewrite it as a nice GUI tool at some point...
 

Melkhior

Well-known member
it works just fine
Excellent news. So it should work on mine at 20 MHz.

Looking at your working test CUPL, the main difference that jumps out to me is that the timing logic is removed
That and the ethernet/rom selection, but as that's just combinatorial from apparently working addresses, I also guessed it was the clock.

With your opinion concurring, I spent some time trying to figure out the problem - and somehow figuring out the problem despite screwing the test :)

My (last, after wasting time refining and refining) test was to simply forward the clock to an output pin, and see if that was working out-of-Mac using the USB 5V. It wasn't. However, I didn't realize at first that having picked IRQ1 (easily accessible), I was guaranteeing the test wouldn't work... what with IRQ being explicitly an open-collector in the CUPL! Of course it was always low, nothing was ever pulling it up... bad test, yet somehow thinking I didn't have any clock I recheckd everything in the design and on the board - continuity, etc.

Turns out the issue has nothing to do with the schematics or the PCB routing. It as everything to do with this:
x2_bug_highlight.jpg
That's the 25 MHz oscillator, rotated 90° from how it's supposed to be. On that one board out of five. That one board I did solder everything on and used for all my tests. The other four board appear to have a properly soldered oscillator... Just bad luck, I guess. Now to see if I have enough leftover part to do another one or if I will have to wait for Mouser...

(I did file a complaint for that to JLCPCB, just to see what happens, as I never had cause to file one before).
 

Melkhior

Well-known member
TL;DR: I now can mount my 'netatalk' share on my IIsi via Ethernet :)

Well, I had the parts :)

Once I could program the CPLD and had soldered all the parts on a board that looked completely OK, still had to figure out why I couldn't program the ROM. I had optimized my routing on the PCB by bit-reversing the Flash ROM. No impact on data going in and out. However, the actual programming of the ROM requires 'command bytes' to be written to the Flash - in, but not out. Those need to be in the proper order, otherwise it doesn't work... So the design cannot be programmed directly by 'programRom', a minimally patched version that bit-reverse the 'command bytes' (three lines in flash_3byte) is needed. Oups.

Other than that, I got the polarity wrong on the silkscreen for the switches. Not a major bug.

For those interested, the design is now public on GitHub. One of the useful feature is that the USB micro-B is dual-function: outside the Mac it's a power input to be able to program the CPLD; inside the Mac it's a power output (tied to the 5V rail) that can be used to power a SCSI-replacement board (in my case it's a MacSD via a simple micro-B to mini-B cable).

And I second that the installer @halkyardo made for the software is very convenient, it feels like deploying hardware back in the day with a proper install disk.

Next step, checking if it works in my own-made PDS adapter, and then add the IIsiFPGA to get all of 100 Mbit Ethernet, a 1920x1080 display, and an extra 240 MiB of RAM in the poor IIsi :)
 

mousehouse

Well-known member
Really impressive what you’ve accomplished! Maybe one day I’ll try to build one!

Out of curiosity, would there be a technical limitation to get both the Ethernet and the MicroMac Performer (which also uses the SE slot) both in the same SE? As I’ve understood it so far the SE does not have real slots, it’s just all the CPU/ bus signals on a connector, right?
 

halkyardo

Well-known member
TL;DR: I now can mount my 'netatalk' share on my IIsi via Ethernet :)

Well, I had the parts :)

Hooray! Glad that's all it ended up being!

If you don't mind, would you be able to run Helios LanTest and let me know what your read and write performance looks like? Just trying to gather more performance data for various machines.
And I second that the installer @halkyardo made for the software is very convenient, it feels like deploying hardware back in the day with a proper install disk.
Thanks! That's exactly what I was aiming for with the installer - now I just need to print up some period appropriate disk labels and a user manual! I'm glad that's working smoothly for everyone.

Maybe one day I’ll try to build one!
Hopefully at some point in the near-ish future you won't have to build one to get one - I'm still planning on putting these in production, life has just got in the way a little bit as it tends to do!

Out of curiosity, would there be a technical limitation to get both the Ethernet and the MicroMac Performer (which also uses the SE slot) both in the same SE? As I’ve understood it so far the SE does not have real slots, it’s just all the CPU/ bus signals on a connector, right?

I'm not familiar with the workings of the Performer, but so long as it do anything with the 32k of memory at 0x800000-0x807fff, the two should coexist just fine - and if it does, then it wouldn't be too difficult to relocate the ethernet controller to a different unoccupied block of memory. I very much doubt that there'd be enough room to fit them in the SE chassis as two separate boards, but given that the design has been reverse-engineered, it'd be fairly straightforward to build a version with onboard ethernet. I can't say it's high on my priority list, but I'd put my full support behind anyone who wanted to give it a try!
 

obsolete

Well-known member
Out of curiosity, would there be a technical limitation to get both the Ethernet and the MicroMac Performer (which also uses the SE slot) both in the same SE? As I’ve understood it so far the SE does not have real slots, it’s just all the CPU/ bus signals on a connector, right?
I'm not familiar with the workings of the Performer, but so long as it do anything with the 32k of memory at 0x800000-0x807fff, the two should coexist just fine - and if it does, then it wouldn't be too difficult to relocate the ethernet controller to a different unoccupied block of memory. I very much doubt that there'd be enough room to fit them in the SE chassis as two separate boards, but given that the design has been reverse-engineered, it'd be fairly straightforward to build a version with onboard ethernet. I can't say it's high on my priority list, but I'd put my full support behind anyone who wanted to give it a try!

I believe later SEs have the window in the metal chassis for a vertical PDS card; the same as an SE/30, basically. If you have one of those, you could build your Performer with a wire-wrap female PDS connector like this one, then build the SEthernet with a right-angle male PDS connector so it can sit vertically, perpendicular to the Performer. I haven't tried this, of course, so YMMV.
 

Melkhior

Well-known member
Next step, checking if it works in my own-made PDS adapter
Well, that raised some interesting questions... first here is the assembled contraption:

combo.jpg
Home-made dual-PDS adapter w/ PGA FPU (20 MHz '882 here) at the back (upside-down).
IIsiFPGA on the 'normal' slot (bottom).
IIsiSEthernet in the middle, with a micro-to-mini USB cable to power the MacSD from the Mac's 5V rail.

Turns out, this is causing / increasing some signal integrity or timing issue (I'm not too sure). With my standard gateware it mostly works, but colormaps are all messed up on the IIsiFPGA. Turns out, that's because the self-increasing index to the colormap lookup table (CLUT) is increasing too fast, so the color data in the CLUT are all wrong. And this appear to be because some writes are handled more than once! Specifically:
(a) IIsiFPGA on its own: appear OK, unit CLUT tests OK
(b) IIsiFPGA on a single-slot PDS adapter: appear OK, unit CLUT tests OK
(c) IIsiFPGA on a dual-slot PDS adapter, but no IIsiSEthernet: appear OK, unit CLUT tests show some minor issues (1-2% duplicated writes)
(d) The contraption above with all the bells and whistles: psychedelic colormaps, unit CLUT tests show something like 30% to 50% duplicated writes

Don't know the exact reason, but I presume the added capacitance/integrity issue is causing the /STERM acknowedgment to not be recognize by the '030, so the signals stay and the write cycle succeeds on the second (or later...) tries. This seem confirmed by the fact that if I change /STERM to fast slew, 16mA drive (default is slow/12mA), then the problem appear to disappear - the display appear OK and so do my unit CLUT tests. Probably not the right solution (I should try to understand how to tell the FPGA to improve the timings for /STERM vs. the CPU CLK), but it makes things usable for now.

If you don't mind, would you be able to run Helios LanTest and let me know what your read and write performance looks like?
Terrible is what they look like, at least compared to the numbers you've shared before... I might have an issue somewhere?
Either LanTest 1.1 or 2.01 are giving me in the 20-25 KB/s range for reading from a 3MB file, and seems all over the place for writing a 3MB file - i've seen anything from 25 to 200 KB, and once 1250 KB/s (which looks suspiciously like a cap to 10MB ethernet link speed rather than a proper result...). Similar results on its own and in the contraption above, BTW.

Could the clock to the CPLD be stuck at 4 MHz somehow? It seems to be the only thing that could affect performance but not functionality. What kind of performance should I get from memoryTest? Right now (with ROM and driver) for reads I get about 256/502/918 KB/s (byte/word/long).
 

demik

Well-known member
Always impressive, nice job !

Shooting ideas
- I've had capacitance issue with some level shifters. They get noisy on all the bus, not sure you have some in there
- weak pulldown on /STERM ? (like 10-47k ?). How low is the voltage going ?

Maybe some EMI issue ? The IIsi developer notes states this :

Some important factors should be considered when using existing processor-direct slot expansion cards or designing new cards for the Macintosh IIsi computer.
  • The fact that the ribbon cable from the expansion card to the connector card must travel the entire length of the main logic board this could have EMI implications for third-party cards. Therefore, at very least, cards should be tested to make sure that they still comply with FCC guidelines. In some cases, cables may need to be shielded or include ferrite sleeves in order not to violate the FCC specifications. At worst, the layout or design of an expansion card may need to be modified.
  • Apple strongly recommends against designing cards to fit directly into the 120-pin connector on the main logic board (without an adaptor card) because the vertical position of the expansion card may cause EMI or thermal problems.
 

halkyardo

Well-known member
Well, that raised some interesting questions... first here is the assembled contraption:

View attachment 73327
Home-made dual-PDS adapter w/ PGA FPU (20 MHz '882 here) at the back (upside-down).
IIsiFPGA on the 'normal' slot (bottom).
IIsiSEthernet in the middle, with a micro-to-mini USB cable to power the MacSD from the Mac's 5V rail.
That certainly is a contraption, I love it!
Turns out, this is causing / increasing some signal integrity or timing issue (I'm not too sure).
A signal integrity issue would not surprise me; I was having bizarre display corruption issues with a video card attached to the pass-through slot on mine, and it turned out to be ringing on the C16M clock line upsetting the video controller chip. I'm planning on adding an optional buffer to the clock lines on the next revision to try and mitigate that.

Terrible is what they look like, at least compared to the numbers you've shared before... I might have an issue somewhere?
Either LanTest 1.1 or 2.01 are giving me in the 20-25 KB/s range for reading from a 3MB file, and seems all over the place for writing a 3MB file - i've seen anything from 25 to 200 KB, and once 1250 KB/s (which looks suspiciously like a cap to 10MB ethernet link speed rather than a proper result...). Similar results on its own and in the contraption above, BTW.

Could the clock to the CPLD be stuck at 4 MHz somehow? It seems to be the only thing that could affect performance but not functionality. What kind of performance should I get from memoryTest? Right now (with ROM and driver) for reads I get about 256/502/918 KB/s (byte/word/long).
Well that's very interesting, from the performance figures that I've collected, I'd guess that you should be seeing something around 350-400KB/s in LanTest - the network stack appears to be CPU-bound rather than IO-bound. It's been a very long time since I ran memoryTest and I never recorded the results, but those memoryTest figures look about reasonable to me.

Those wildly varying LanTest figures make me suspect that there's intermittent data corruption going on - AppleTalk packets failing their checksum and being retried. Wonder if it's the same source of corruption that's affecting the video card (although SEthernet doesn't use /STERM).
 

Melkhior

Well-known member
That certainly is a contraption, I love it!
Having so much weight off-center is probably not very good for the DIN connector. I should add some support. But as a prototype, it does the job :)

the network stack appears to be CPU-bound rather than IO-bound
Not surprised, so is QuickDraw on such machines. 68030 were very nice in their days, but they aren't fast by any modern standard... BTW, in my case, it's connected to a gigabit switch, and there's probably four of those between it and the actual netatalk server (I have a rather complicated setup at home...). Shouldn't matter for bandwidth , but it might add some latency.

Those wildly varying LanTest figures make me suspect that there's intermittent data corruption going on - AppleTalk packets failing their checksum and being retried. Wonder if it's the same source of corruption that's affecting the video card (although SEthernet doesn't use /STERM).
Is the number of failed packets stored somewhere it can be (somewhat) easily retrieved? Such as a hardware register that could be read w/o interfering with normal operations. Or is there some other mechanism to help identify where the problem could come from?
 

halkyardo

Well-known member
Is the number of failed packets stored somewhere it can be (somewhat) easily retrieved? Such as a hardware register that could be read w/o interfering with normal operations. Or is there some other mechanism to help identify where the problem could come from?
Not in the driver, unfortunately - any packets that come off the wire with a bad checksum are rejected in the ethernet controller without the driver ever being aware of them. And on the transmit side, the ethernet controller calculates the ethernet checksum at transmit time. This is convenient (and faster than doing it in software), but it does not guard against data being corrupted on the host-bus side of the ethernet controller.

What I suspect is happening here, is that the packet is being received into the ethernet controller's buffer correctly, but then getting corrupted during the copy from the controller's buffer into system memory. DDP (the base-level Ethernet encapsulation for AppleTalk packets) has its own checksum indpendent of the ethernet checksum, and I suspect that the packet is getting rejected after the driver has passed it off to the network stack, rather than in the driver or ethernet controller itself.

If you look at a packet capture with Wireshark during the LanTest read and write tests, you'll see a bunch of Appletalk Transaction Protocol activity - typically a 'request' packet followed by 5 or so 'response' packets with the same transaction ID, with the transaction ID increasing every time. If you see the same set of response packets getting re-sent, or a request with the same transaction ID as the last transaction, that's a sure sign that retries are occuring. Packet activity also slows down noticeably when this happens.
 

halkyardo

Well-known member
Well, I suppose it's been a while. Sorry for the radio silence. In all honesty, after the frenetic pace of getting SEthernet working and building the beta cards, I kind of burned out on it for a while there and needed to take a break. Combine that with the summer weather making me less inclined to spend time in my windowless basement workshop, and not much has happened with SEthernet for a while.

However, recovery from a recent surgery has had me cooped up inside the house, not able to do much but with plenty of mental energy buzzing away. So, I've been revisiting SEthernet, and I thought I'd share a quick update on where I'm at and where things are going.

First off: sorry, I still don't have any cards for sale. There were a few minor issues with the beta SEthernet/30 cards involving the positioning of connectors and mounting holes, and signal-integrity issues when used with pass-through cards. I'd started work on a redesign to address these when the burnout hit, and I haven't yet got back to it. As it stands, the design in the Github repo does still work if you want to build one yourself, but I wouldn't recommend using additional cards with it. Once I get the revised design sorted out, I'll probably do a small run of cards and offer them for sale, but I wouldn't count on that happening until later this year.

Secondly, I've been working on an A/UX driver for the SEthernet/30! It's not ready for prime time yet - while it works wonderfully on the Unix side of things, the Macintosh environment does not seem to want to talk to it, for reasons that aren't entirely clear - but I'm continuing to chip away at the issues and am hopeful it'll all come together given some more time and effort. I'm *very* excited about this, as the lack of A/UX support was a major downside in the "build a whole new card" approach of SEthernet (as opposed to replicating the A/UX compatible MacCon). If I can get it fully-supported under A/UX, I'll be very pleased.

One interesting thing I noticed when writing my A/UX driver was how overengineered my Mac OS driver ended up being. When I wrote the Mac OS driver, I had no familiarity with either the hardware or the Mac OS network stack, so I ended up builiding the driver with a bunch of abstractions between the network stack and the hardware. This helped me reason about what was going on, but in the end, I ended up having to break a bunch of those abstractions to get correct behavior and acceptable performance. For a number of reasons, the A/UX driver ended up being a from-scratch rewrite, and this time around I did away with those abstractions in favour of interacting with the hardware directly. The net result is that while the Mac OS driver is ~2000 lines of C plus even more assembler, the A/UX driver is closer to 1000 lines. At some point I'd quite like to go back and revisit the Mac OS driver and give it a similar treatment - hopefully getting a bit more performance out of it as a result!

Finally, and while this isn't really Mac-related, a couple of my friends on here (you know who you are) recently talked me into trying to do something SEthernet-like for Acorn Archimedes computers, so now I've got an A3000 sitting next to my Macs on my workbench, and I'm figuring that out. A bit of a distraction from working on the Mac side of things, but the change of scenery has been helpful. Since Acorn's RISC OS uses a BSD-derived network stack, similar to A/UX's, I'm hopeful that there will be some useful crossover between the two driver development efforts.

Anyway, sorry if this has been a bit of a letdown, I know there are people out there who are really excited to get their hands on an ethernet card, and I'm really appreciative of the enthusiasm and support this project has brought out. Even if things have been a bit quiet lately, I haven't forgotten about it!
 
Last edited:

nightingale

Well-known member
Creating something new, especially something as ambitious as this, takes time! I'm so impressed with all the new projects that are coming along for classic macs these days, and this is no exception! I'm eagerly following your progress on this, and I hope it makes it to production, but if not it's still cool that you did it.
 

halkyardo

Well-known member
Well, that was surprisingly straightforward! The issues with the Mac environment boiled down to a permissions issue on the /etc/master.d file that describes the driver (which the Mac environment has to read in order to map slot numbers to Unix interface names). After fixing that and a bit of general tidyup, it mostly seems to work!

It's not 100% yet, last night I saw a kernel panic while running iperf against it, but I haven't yet been able to figure out whether I'm doing something wrong there or if it's just A/UX being fragile (since I was bitten by a similar issue on the Mac side, which turned out to be a Mac OS bug!). Source code is available at https://github.com/rhalkyard/SEthernet-AUX for the 4 of you or so who have SEthernet/30 cards if you want to give it a go 😅.
 

Attachments

  • Picture 2.gif
    Picture 2.gif
    9 KB · Views: 25
Top