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.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)
I might attempt again if I solder a second board, but meanwhile...
I think that would be of interest to me as well, following the tests I've done (see below).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.
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 anywayAnother 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 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.