LC PDS card design -- FC0/1/2?

[dougg3]

Hey everyone,

I've been experimenting with designing an LC PDS card that has a ROM SIMM socket on it in order to use the right half of the UI in Apple's Flasher app in my LC 475. Just for the fun of it! This has been an entertaining foray into programmable logic and is exactly what I needed for a simple starter project for understanding the 680x0 bus cycles.

I've been looking at the various LC series devnotes and also Designing Cards and Drivers for the Macintosh Family. One thing that is common to all of them when referring to the LC PDS slot is they all mention this or something similar:

Your expansion card must generate its own card select signal. Figure 14-2 shows a typical example of the required logic. Notice that a function code of 111 (CPU space) disables the card select signal. This action is important because it prevents the card from being selected during interrupt acknowledge cycles.

It goes on to show a diagram of simple selection logic that makes sense. I don't think I've ever seen a NAND gate represented as an OR gate with all negated inputs before, but maybe there's a reason to show it that way (closer to what a PAL/GAL can actually implement?)



By the way, they made a typo and accidentally referred to A23 through A20 as FC23 through FC20. The LC 475 dev note shows it correctly:



Anyway, I'm ignoring the 24-bit mode selection logic for now because as far as I can tell, in the LC 475 I should only need to deal with 32-bit mode. It seems kind of silly to me that all of this logic would have to be replicated on every card, but I guess it makes sense because the original Mac LC didn't have an MMU so it couldn't easily remap 24-bit mode's 0xExxxxx to the corresponding 32-bit address space under the hood.

I'm not sure why the LC 475 devnote even mentions the 24-bit stuff -- maybe just for compatibility reasons with older Macs (would you ever see a bus cycle with FC3 = 0 in the LC 475?)

Now for the real reason I made this thread: I'm confused about something. And I'm hoping that someone with more experience might be able to help me understand what I'm missing. All of the info they say about making sure FC0 through FC2 isn't 111 makes sense to me. But with that in mind, why is it that I can't find FC0, FC1, and FC2 going anywhere on my Apple Ethernet LC Twisted Pair card? I thought for sure I'd see it going into the GAL on the card or something. But it seems like Apple didn't follow their own advice. I don't see any of those 3 signals going anywhere on the board. I've probed all over the place with my multimeter. I see plenty of other signals that make sense hooked up to the GAL: /AS, A31, FC3 (the 32-bit mode bit), /DSACK1, and the /OE pin of the card's onboard ROM.

Farallon's EtherMac LC NSC card does bring FC0-FC2 into the big ASIC on that card. So at least I know I'm not going crazy and other cards do pay attention to them...

How was Apple able to get away with ignoring FC0-FC2 on their card? The only thing that jumps to mind is that maybe they were clever with the card's address mapping and their GAL is looking at A19 and A18 to determine if it's an interrupt acknowledge cycle instead? Because A19 and A18 do go into the GAL, and interrupt acknowledge cycles have A19-A16 = 1111. So as long as all legit accesses to the card have A19 or A18 = 0, it could use that as the rule instead...

Thank you for any insight! I thought I was understanding everything and then this Apple card kind of threw me a curveball.

 

[dougg3]

I'm not sure why the LC 475 devnote even mentions the 24-bit stuff -- maybe just for compatibility reasons with older Macs (would you ever see a bus cycle with FC3 = 0 in the LC 475?)

Apparently I'm an idiot and the LC 475 does support 24-bit addressing, so nevermind on that!

 

[dougg3]

The only thing that jumps to mind is that maybe they were clever with the card's address mapping and their GAL is looking at A19 and A18 to determine if it's an interrupt acknowledge cycle instead? Because A19 and A18 do go into the GAL, and interrupt acknowledge cycles have A19-A16 = 1111. So as long as all legit accesses to the card have A19 or A18 = 0, it could use that as the rule instead...

This doesn't appear to be what they did. If I try to dump memory at 0xE00C0000, which is in the PDS card's super slot space and has both A19 and A18 = 1, I read back data. I believe if the card behaved based on the guess I described above, I would get a bus error instead...

Edit: In fact, the data I read back at that address (and 0xE0080000, and other repetitions) is actually the content of the 341-0740 chip which seems to contain the DeclROM.

 

[dougg3]

So I played around some more with the various address bits, and it seems like if I try to do a read from any 0xExxxxxxx address with A24 = 1, the system hangs. And sure enough, A24 is one of the address pins that goes into the GAL.

This sounds slightly crazy, but I'm starting to wonder if maybe they simplified the logic on this card so that A24 = 1 means it's an interrupt acknowledge cycle and used that instead of FC0/FC1/FC2? Probably fits much easier into the GAL...

 

[ymk]

If your card has a small address space and can dodge the three FC==7 modes above on address alone, then you don't need FC.

 

[dougg3]

Thank you @ymk. That makes perfect sense. I've been studying the 68020 manual and now that you've pointed it out, I see the 68020 manual has a similar diagram. It also has access level control as another CPU space cycle similar to the first two. Thank you for pointing out that page and providing some insight!

I think that fully explains what's going on with this card. Breakpoint acknowledge and coprocessor comm. are already guaranteed to be ignored because A31 through A20 would have to be 0, and some of those bits are guaranteed to be 1 during PDS accesses. I think this card is using A24 to detect interrupt acknowledge cycles. It's good to know that it can be detected that way if you don't need the full address space. That's a lot simpler to implement than looking at FC0-2.

I installed MacsBug, played around, and confirmed that with this Ethernet card installed, any accesses to the card space with A24 = 1 end up as a bus error (likely because it never responds with /DSACK0 or /DSACK1 and the 45-90 us timer expires). Now it all makes sense. Thank you!