SEthernet and SEthernet/30: A new take on PDS Ethernet

[Melkhior]

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.

 

[halkyardo]

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]

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:

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).

 

[cheesestraws]

Argh and dammit!

 

[Melkhior]

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]

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]

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]

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.

 

[cheesestraws]

This sort of thing is why Radius had magicbus, of course ;-)

 

[Melkhior]

Next step, checking if it works in my own-made PDS adapter

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


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]

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, 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).