Phipli
Well-known member
An inline resistor and small cap to gnd might use less space if you want to keep it simple?
SEthernet and SEthernet/30: A new take on PDS Ethernet
- Thread starter halkyardo
- Start date
Yeah, I need to do a bit of thinking and experimentation here. It doesn't have to be too precise a delay, but if it gets too long, it will start to impact timing of the rest of the bus cycle. I haven't done the math yet, but I think 1-10ns is what I'm aiming for. I was thinking along the same lines - the 74LVC2G17 dual non-inverting buffer looks to be a good candidate - I'll need two channels anyway for the two byte strobes, and its delay characteristics are pretty much exactly what I want.Can't you just the same trick and connect the /CS output of the CPLD to an input pin of the same and use that to add an extra delay? Or would that be too long with a full CPLD pass-through delay?
Alternatively, you can probably make do with a single inverter, the CPLD can do the first inversion internallyOr a non-inverting driver like the 74LVC1G07, which has a better worst-case latency than the 74LVC1G04.
I'm planning on using the Atmel ATF1502AS. This will be my first foray into CPLDs so I'm not sure how they stack up against the XC9500XL family, but it's cheap, available, works at 5V, and while it doesn't have many macrocells, my glue logic fits just fine.
I thought about using an otherwise-unused interrupt priority level, but with how the SE assigns them, only higher priority levels are available (1=VIA/SCSI, 2=SCC, 3=Unused, 4=NMI switch, 5-7=Unused). I want the ENC624J600 to have a relatively low priority, since its large receive buffer means that there isn't too much urgency in handling incoming data, and the design of the Mac OS network stack means that a lot of potentially time-consuming protocol-handling work happens at interrupt time. Having a higher priority than the NMI switch would make debugging a nightmare, and even the thought of using level 3 made me concerned about the SCC's tiny buffers and the consequences of missed interrupts if serial and ethernet were being used at the same time.
So what I ended up doing, was 'hijacking' level 1 to create a "level 1.5." The ENC624J600's interrupt output is connected to /IPL0 along with the VIA and SCSI chip. When the driver is opened, it saves the level 1 vector at 0x64 and replaces it with its own routine. When a level 1 interrupt comes in, my routine tests the interrupt bit in the ENC624J600's status register, and depending on its state, dispatches to my ethernet interrupt handler, or the handler that the vector was pointing to previously.
This does mean that the spurious-interrupt bug in my revision 0 hardware can play havoc with the machine, but software mitigations mean that it's not too much of a problem (and when it does happen, all you need to do is power-cycle the machine), and I'll fix it properly in the next revision.
Yep, that's about where I'm at, too. My main desktop computer is actually a MacPro3,1 tower, but I don't really consider it a 'Mac' any more since Apple dropped support for the NVidia graphics card I installed in it a few years ago (right after I bought the card too!), so it just runs Windows now
demik
Well-known member
Intersesting thanks. Very clever as well. Too bad you cannot use the SCC for that (IEI / IEO) from the PDS slot, or in any mac really, because it can do the same thing (in hardware) and maybe avoid spurious interrupts.
The BBU having no provision for that doesn't help either
Haven't had much to update this thread with recently, but after boards and parts for another hardware revision arrived the other day, things are progressing nicely!
The hardware bugs that I mentioned earlier in the thread were going to necessitate another board revision anyway, so I took the opportunity to make a few other improvements along the way - both the SE and SE/30 boards now use an ATF1502 CPLD for their glue logic - this is cheaper than the three GALs that would have been otherwise required for the SE/30 board, and allowed me to make some subtle timing optimizations specific to read and write cycles, rather than assuming the worst-case timing for both scenarios. I've also redesigned the SE/30 board to accommodate a pass-through PDS slot.
There are still a couple of physical-fit issues to sort out, and I need to put some finishing touches on the driver installer and general user experience in setting up a new card, but this is getting remarkably close to being a "real" product! I'm not in a position to commit to a price and timeline just yet (remember, I'm doing this all in my spare time on a shoestring budget), but there will be a production run of these one way or another when I've got the last of the issues ironed out.
The hardware bugs that I mentioned earlier in the thread were going to necessitate another board revision anyway, so I took the opportunity to make a few other improvements along the way - both the SE and SE/30 boards now use an ATF1502 CPLD for their glue logic - this is cheaper than the three GALs that would have been otherwise required for the SE/30 board, and allowed me to make some subtle timing optimizations specific to read and write cycles, rather than assuming the worst-case timing for both scenarios. I've also redesigned the SE/30 board to accommodate a pass-through PDS slot.
There are still a couple of physical-fit issues to sort out, and I need to put some finishing touches on the driver installer and general user experience in setting up a new card, but this is getting remarkably close to being a "real" product! I'm not in a position to commit to a price and timeline just yet (remember, I'm doing this all in my spare time on a shoestring budget), but there will be a production run of these one way or another when I've got the last of the issues ironed out.
Ouch, that's one massive board for the SE/30 !
I see that in addition to the ATF1502, you switched the Flash from PLCC to TSOP - which means, it can't be socketed for out-of-board programming. I also see the write enable pin is connected to the CPLD; is the intention to do in-place programming from the Mac? Something like
(a) assemble/solder the whole board
(b) connect to +5V and program the CPLD via JTAG
(c) put in the Mac and program the ROM
(d) install the SW
(e) enjoy
Also, what JTAG programmer do you use for the CPLD? The pinouts is different from the 7-pins connector on my Xilinx-oriented Waveshare, which I'm not sure would work anyway (Im trying to cram all of that in a really small PDS board to fit in a IIsi alongside a IIsiFPGA...).
I see that in addition to the ATF1502, you switched the Flash from PLCC to TSOP - which means, it can't be socketed for out-of-board programming. I also see the write enable pin is connected to the CPLD; is the intention to do in-place programming from the Mac? Something like
(a) assemble/solder the whole board
(b) connect to +5V and program the CPLD via JTAG
(c) put in the Mac and program the ROM
(d) install the SW
(e) enjoy
Also, what JTAG programmer do you use for the CPLD? The pinouts is different from the 7-pins connector on my Xilinx-oriented Waveshare, which I'm not sure would work anyway (Im trying to cram all of that in a really small PDS board to fit in a IIsi alongside a IIsiFPGA...).
Yeah, I made it taller so that it could reach the card retainer on the SE/30 chassis - with the extra weight of a card in the pass-through slot on top, I wanted the additional mechanical support. It's still smaller than the "legal" minimum size for an SE/30 card though
That's correct; I've written a tool to do the programming in-system - it looks for card address spaces that are not known to the Slot Manger but don't return a Bus Error when accessed, then probes for the ENC624J600 to see if it's a 'blank' SEthernet/30 board (it'll also reprogram SEthernet/30 boards that are known to the slot manager). It's an extremely barebones console application right now, but it does the trick. Tidying it up into a nice GUI app is on the to-do list.I see that in addition to the ATF1502, you switched the Flash from PLCC to TSOP - which means, it can't be socketed for out-of-board programming. I also see the write enable pin is connected to the CPLD; is the intention to do in-place programming from the Mac? Something like
(a) assemble/solder the whole board
(b) connect to +5V and program the CPLD via JTAG
(c) put in the Mac and program the ROM
(d) install the SW
(e) enjoy
I have to confess, I'm not using a "real" JTAG programmer; I'm using a Glasgow Interface Explorer, which just happens to have a JTAG mode, but doesn't have a conventional JTAG cable. I just made the pinout up as something that looked reasonable to me; I felt that a 2-row connector would have taken up a bit too much space anyway.
Any 5V JTAG programmer that's supported by OpenOCD or otherwise can replay a .SVF file should be suitable for programming it (Atmel's tools produce a .JED file that is only understood by their ATMISP software, but ATMISP has an option to generate a generic SVF file)
I see that you have betas on the way, do you consider the GitHub schematics "final"? As mentioned, I'm considering a much smaller form factor that could fit with a IIsiFPGA on a custom dual-PDS adapter (or stand-alone!). Current WiP looks like this:Yeah, I made it taller so that it could reach the card retainer on the SE/30 chassis - with the extra weight of a card in the pass-through slot on top, I wanted the additional mechanical support. It's still smaller than the "legal" minimum size for an SE/30 card though
The 5V plug on the left is to power up the board for JTAG (standard 2x6 headers) programming. I still need to double-check some mechanical measurements to make sure both the 5V and the large Ethernet plug (integrated transformers...) won't cause issue on an hypothetical dual-PDS adapter and/or standalone.
I'm also using a 25 MHz oscillator instead of a crystal, and mechanical switches for the slot selection.
Oh that looks fantastic!!
Unless some major issue comes up, then yes, the schematics currently on github should be final. I've had that version of the board running in my SE/30 (now with a @zigzagjoe accelerator too!) for several weeks of heavy use without any issues.
I might shuffle the layout around and tidy up the schematics at some point, but the netlist should be more or less frozen.
I did, however, make a couple of changes in the past week or two that might impact you, depending on when you started work on your board:
- The footprint of the SST39SF010 should be 12.4x8 TSOP32, not 14.4x8. I ordered my boards with the incorrect footprint, and while it was still possible to solder to the wider footprint, it was an enormous pain and I suspect that it wouldn't work at all for automated assembly.
- The pulldown resistor on the ENC624J600 SPISEL-/INT pin should be 100K, not 10K as I had in my schematics. Functionally this seems to make no difference, but the datasheet calls for 100K, and I must have misread it at some point.
croissantking
Well-known member
Nice - I am interested in a small form factor with an onboard RJ-45 socket as I currently run my SE/30 board outside its case.
Is your modified design just for a IIsi?
OK thanks! I started from scratch in KiCad 5.1, where my PDS adapter was, so I redid the schematics there - still need to double-check them thouroughly... The footprints are also from from scratch, I'll also have to double-check but that should be OK, and JLCPCB's 2D/3D view provides a "final check" when doing asssembly there. I have a 100k on /ETH_INT already, you must have pushed that update some time ago.
It should be compatible with the SE/30 and maybe the IIfx as well (the CPU clock is not used, it's on a different pin on the IIfx), as most of the critical signals are the same between those 3. The goal is also for it to be firmware- and software- compatible with @halkyardo 's design, by using the same chips and the same pins for all the critical stuff. So it should be compatible with the same list of machines.
It'll be pushed to GitHub once I have a working example, that could take some time but I'd rather not push an untested version.
Turns out, space is really constrained - that 5V plug wouldn't fit, and I'm not sure an ethernet would would on the other side... so as not much power is needed, go for a micro-usb instead of the bulky plug, and rotate the Ethernet 90° so the cable has space inside the machine.
@halkyardo Are those bodge wires and resistors something that needs fixing in the current version ?
@halkyardo Are those bodge wires and resistors something that needs fixing in the current version ?
cheesestraws
Well-known member
Now I've played with the card properly, I want to say this is great. It really feels like installing a "finished" product, with the Installer and driver and so forth. It worked plug and play for me in some rather demanding circumstances, and I like it a lot. Well done.
Dumb question - what's the speed grade of the ATF1502AS on those board? That's the one number I didn't double-check before ordering my variant, and now I'm worried I made a stupid assumption. The schematics mentions a -25 [AU44], but that could just be the for the schematics/footprint, where the speed grade is irrelevant...
Thank you so much! I've spent a lot of time fussing over whether it's 'finished enough' to release, so hearing that definitely puts me at ease.
I've been using a 25ns ATF1502ASL-25AU44 and a 70ns SST39SF010A-70-4C-WHE without issue - pretty sure those are the slowest currently-available grades of those parts. In a few days I should have all the necessary bits together to hook it up to my logic analyzer and exhaustively analyze timings, but for now it seems to work as-is.
Last edited:
OK, thank you! So I have the 'right' one, provided the 20 MHz clock of the IIsi doesn't cause issue. IIRC, you tested in a IIfx as well? That should also default to a 20 MHz clock, so odds are good, if I didn't mess up something else.
I did manage to run WinCUPL under Wine (GUI doesn't look great but it works so...) and produce a JED, and I did manage to convert that to a SVF using prjbureau's tool, so far so good. Could you share the 'known to work' version of those two to simplify bring-up? The more reliable bits in the process, the easier to figure out ubgs in other parts
Thanks in advance.cheesestraws
Well-known member
What you sent me is extremely Finished, it's one of the nearest things to a coherent product I've ever received in the "stuff that plugs into old computers" category.
I actually recently discovered that the current hardware/gateware revision *doesn't* seem to work properly in my IIfx - it was only the early GAL-based version that I'd tested on there.
I haven't had a chance to dive into it properly, but I've built up an interposer board that will let me look at the whole bus at once with my logic analyzer; hopefully that will shed some light on the issue. Just waiting for some connectors to arrive and then I'll dig into it. I suspect it's more likely something I've done, than the speed of the CPLDs, but we shall see.
Of course, here's the SVF that I used for the beta cards that @cheesestraws and @zigzagjoe have. I used the ATMISP software rather than prjbureau to generate it, but glad to hear that it works that way too. Isn't WinCUPL fun?I did manage to run WinCUPL under Wine (GUI doesn't look great but it works so...) and produce a JED, and I did manage to convert that to a SVF using prjbureau's tool, so far so good. Could you share the 'known to work' version of those two to simplify bring-up? The more reliable bits in the process, the easier to figure out ubgs in other parts
So far my variant isn't doing great. The CPLDs are proving to be an issue, I've posted some questions on the EEVBlog forum.
After force-feeding @halkyardo 's SVF into one of those not-quite-ATF1502ASL, the board isn't seen by programRom (I did successfully rebuild all software) - the IIsi behave as if it wasn't there (but doesn't crash or anything). Could be the CPLD, could be some other issues; to be continued.
After force-feeding @halkyardo 's SVF into one of those not-quite-ATF1502ASL, the board isn't seen by programRom (I did successfully rebuild all software) - the IIsi behave as if it wasn't there (but doesn't crash or anything). Could be the CPLD, could be some other issues; to be continued.
oh no! That's odd - I sourced all my parts from Digikey and hand-assembled them rather than using JLC, but the parts I used programmed without any issues, so presumably they had the ID that the SVF file was expecting.
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). If that's happening, then there's a good chance the CPLD is OK and my logic is at fault.
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.
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). If that's happening, then there's a good chance the CPLD is OK and my logic is at fault.
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.
