FC0-FC2 680x0 Bus Signals Needed?

[trag]

In a few idle moments (well waiting for tests to finish running) I was reading up on the 680x0 bus in the 68030 User's Manual. I've read the description of the Function Code (FC) pins several times now, and I cannot imagine what a peripheral is meant to do with them. It's great that they indicate whether the computer thinks it's pointing at User or Supervisor space and Data or Program space, but in the end, it's still all the same 32 bits of address space.

So, anyone know if there's some reason why a peripheral for the SE/30 actually needs to decode the FC pins, or can it safely ignore them?

If a read or a write to a particular address shows up on the bus, and that address is within the peripheral's address space, what affect would the FC signals have on how the peripheral processes it?

 

[Trash80toHP_Mini]

< WAG alert! >

Ask if anyone has the drivers a/o a ROM for spelunkin' from one of the Gemini '020 - '030 Accelerators for the SE. I'm positive they must have broken just about every single Apple guideline for the 68000's use. They were running those things with gonzo RAM in a Silicon Disk VRAM lash-up . . . on machines never intended to do anything of the sort.

It might be interesting/enlightening to see how they hacked that . . . :?:

. . . or not! :

 

[bbraun]

As best I can tell, it would probably be used to implement memory protection. A user program cannot read or write to/from memory regions designated as supervisory, and no one should be writing to user/supervisor program space once it has been loaded. A simplistic MMU would just give a bus error if one of these invalid accesses were performed.

 

[Gorgonops]

I would suggest reading the original Motorola data sheets for the 68k CPU family. I've looked at it a little and it sort of made my head hurt. The answer to whether those pins are important or not in a given hardware design seems to be a great big fat "It Depends". Function codes are an integral part of how the m68k handles distinctions between user and supervisor mode, and it appears from skimming the manual it would in theory be possible to design a 68k computer which used up to *eight* separate 32 bit address spaces for different priority software and use the output of those function pins in any number of ways to enforce security.

The one succinct explanation I did see about the workings of those pins implied that normally they were used by the MMU and that the physical memory subsystem doesn't necessarily need to care about them. (IE, the MMU will do the job of comparing the function codes to the translation tables it maintains and allow or deny access at that level.) It *may* be that the only reason the 68030 has the pins brought out despite having a built-in MMU is to allow the chip to be used to upgrade older designs with proprietary memory management systems. (At first glance the pins appear to be absent on the 68040 family.) But, really, I have no idea whether a Mac cares about them or not. To my knowledge the classic MacOS uses supervisor mode exclusively so I don't know under what circumstances those pins would even change state. (Under A/UX or NetBSD it's another story.)

 

[trag]

I would suggest reading the original Motorola data sheets for the 68k CPU family. I've looked at it a little and it sort of made my head hurt.

I have been too, and ditto about the pain.

from skimming the manual it would in theory be possible to design a 68k computer which used up to *eight* separate 32 bit address spaces for different priority software and use the output of those function pins in any number of ways to enforce security.

I noticed that too. It looks like with care, one could use the FC pins as the equivalent of address pins (except one must change modes to change them, instead of writing them into addresses explicitly) and actually have an address space of 32 GB in a 68030 machine. I think the MMU enforcing security restrictions might be inconvenient though.

The one succinct explanation I did see about the workings of those pins implied that normally they were used by the MMU and that the physical memory subsystem doesn't necessarily need to care about them. (IE, the MMU will do the job of comparing the function codes to the translation tables it maintains and allow or deny access at that level.)

That was my reading as well, which is why I was puzzled that...

It *may* be that the only reason the 68030 has the pins brought out despite having a built-in MMU is to allow the chip to be used to upgrade older designs with proprietary memory management systems.

That makes sense. I was having trouble imagining why, if the signals are really just relevant to the MMU, why are they on the external bus. For that matter, why are they in the PDS slot? But I guess putting them in the PDS slot allows third party developers to build security conscious add-ons or something.

Or we're both overlooking the same thing. I even went and dug around in the 68020 and 68851 datasheets for answers, but didn't get any different ones; in the 68020/68851 combination, the diagram of |Logical bus <--> 68851 <--> Physical bus| doesn't seem to propagate the FC pins to the physical bus side of the diagram, supporting our conclusions.

I wonder if this is addressed at all in "Inside Macintosh". Perhaps I'll skim through DCADFTM this weekend to see if it mentions the FC lines. Probably not, since it is oriented on NuBus and I don't believe that NuBus propagates the FC lines.

It makes a three pin difference in how many FPGA pins I need to interface with the PDS slot in the SE/30 and I'm hurting for pins. The FPGA I'm eyeing has 372 I/O pins, but the Xilinx Starter Kit with that chip on it, which I want to use, doesn't have very many unused pins readily available.

There are 43 in the 100 pin connector (huh?, why aren't there at least 50?). And there are three 6-pin headers where I can get four I/O pins each. And a couple of differential headers where I can grab another 24 total. So that's 43 + 12 + 24 = 79 and the Starter Kit is out of readily available pins.

Everything else is being used for expansion components built into the Starter Kit, or isn't brought out from the main chip. By my count, the Starter Kit board uses 283 I/O pins, so there should still be 89 pins available. I don't know why they didn't bring more of them out to usable connectors. Probably board routing issues, I guess.

A rough count of the PDS slot says I may need as many as 86 pins to interface properly. If I can ignore FC, that's down to 83, only four more to go!

 

[johnklos]

FC0, FC1, and FC2 can be used for supervisor-only memory access, but the primary use is for selecting coprocessors. A typical setup has just one m68881 or m68882, but it's entirely possible to have several. Some custom accelerator boards did exactly this.

 

[Gorgonops]

On Google Books there's some preview pages from a book called "Microprocessor Theory and Applications with the 68000/68020 and Pentium" that seems to have a reasonably good explanation of the workings of those pins in two different chapters. Google "FC0 68881" and you'll find it. Visible in the preview is both a table of what various combinations of FCx codes translate to, and at least a brief explanation of how the FCx pins are used in concert with some of the address pins during a "CPU space cycle" to select between up to 16 different co-processors. (Motorola considered both the 68881 and the 68851 MMU as "co-processors".)

So, yeah, I guess that's why the 68030 would have them despite having the equivalent of a 68851 internally.

 

[trag]

Thanks guys. So I guess the FC signals are present in the PDS slot to support the possibility that someone would build a coprocessor board of some kind. That makes sense. And it also seems that I can ignore them.

Unless there's some situation where the FC pins would indicate a 68881 transaction, but the address pins would be indicating the address space my card is decoding.

Hmmm. Better go double check that...

Okay, I was starting to worry that I would have to decode the three FC lines in the FPGA, or at least set up a little external logic to create a sort of anti-chip select when FC = 111. However, in the MC68030UM, section 10, I found this:

Bits A20 - A31 and A5-A12 of the MC68030 address bus are always zero during a coprocessor access.

Since the address space I'll be using are always going to have some non-zero value in bits A31-A30 or in A24-A23, I can decode just the address bus and be assured that I'm not interfering in a transaction which was meant for a coprocessor.

I need to check some more details to confirm that there isn't some detail that will get me, but I think it's safe to ignore the FC lines.

 

[Trash80toHP_Mini]

I don't know if this is relevant to your project, trag, but . . .

. . . I was wondering . . . is there any way you can make use of the three "Reserved" pins on the IIsi/SE/30 PDS?

Hacking those babies could open up some interesting possibilities for those two machines. :approve:

Methinks that Apple has "Reserved" them just about long enough! }

 

[trag]

. . . I was wondering . . . is there any way you can make use of the three "Reserved" pins on the IIsi/SE/30 PDS?Hacking those babies could open up some interesting possibilities for those two machines. :approve:

Methinks that Apple has "Reserved" them just about long enough! }

Heh. It depends on what they're connected to on the host side.

But at this point, I don't want to make use of more pins. I want to connect to the fewest possible number of pins.

 

[Trash80toHP_Mini]

That's what I thought, just thought i'd mention it.

If you're building an '030 PDS card with more pins than you can deal with, why not pre-multiplex the data lines between the PDS and your targeted microcontroller?

BTW . . . SNIP!!!!! . . . WHAT connection at the host side? }

 

[trag]

That's what I thought, just thought i'd mention it.
If you're building an '030 PDS card with more pins than you can deal with, why not pre-multiplex the data lines between the PDS and your targeted microcontroller?

That would defeat the purpose of making the data transfer as fast as possible.

Plus, it isn't more pins than I'll be able to deal with ultimately. It's more pins than the ^#%$^% Development Kit has easily available.

The FPGA chip I want to use has 372 I/O pins available. But I don't want to start my project by developing a board for the complicated FPGA and then experiment with soldering it and the other components down. I want to buy a Development Kit which already has the FPGA soldered down, and which has a DDR2 chip, parallel flash, 10/100 enet phy, 2-line LCD screen, two serial flash, and various pushbuttons and LEDs connected to the FPGA. The Development Kit also has demonstration code reference designs which makes all those things work, especially the DDR2 memory and the etherent phy.

All that stuff, plus the 100 pin connector, the three six pin connectors and the two 24 pin connectors use up about 282 of the 372 pins, but in all those connectors there are only ~79 pins available to connect to things off the board -- and to get those I'll be running little twisted pair pigtails from various connectors (six different headers) instead of just plugging into a single port.

So, to begin with, I want to get the Development kit. Play with the demos. See that the FPGA interface to the DDR2 works. See that the FPGA interface to the enet PHY works. Put data in the Flash. Pull data out of the Flash. See the lights light, and the buttons push. Etc.

Then, I just want to build a board that connects the SE/30 PDS slot to the available I/O pins on the Development Kit. And with the SE/30 connected to the FPGA Development Kit, I can write really simple FPGA code at first, so that the SE/30 writing to an address in the slot space makes an LED come on or some such. Or pressing a button on the FPGA Development Kit causes a bit in memory in slot space to change, which the SE/30 can read. That kind of thing.

From there I can work up, until I can interface the SE/30 software/firmware to the demos on the Development Kit. Ultimately getting to the point where read and write commands for the Development Kit DDR2 Demo software are coming from the SE/30 PDS slot, instead of from the Test Bench code in the Demo.

 

[Gorgonops]

Call me a pessimist, but... if you're buying the development kit to get familiar with FPGAs might it be a better idea to try interfacing it to something a little slower/better documented than the SE/30 PDS first? (Apple II, maybe an an ISA slot... how about a clip or socket-adapter to tap into an SE or Plus' 68000 bus?)

I'm sure you already know this, but based on your other post:

viewtopic.php?f=29&t=16653

it seems that your plan is to map RAM into one of the Nubus slot spaces and try to remap it with the MMU? I seem to recall vaguely that 32-bit 68k Macs *already* do some fairly complicated memory mapping in order to paper over the differences between their native memory maps and those of the "24 bit" Macs. I can't find the Developer Note for the SE/30, but the one for the IIci specifically talks about how the 68030's MMU is used to remap the "small" NuBus I/O spaces (the 1MB ones, not the wide "Superslot" spaces) into the lower 8MB, in addition to shoving the location of the ROMs and built-in I/O devices. It appears the mappings for these are embedded in the ROMs. That's certainly not to say that it wouldn't be possible to add additional mappings which would take a block of memory located at 0x60000000 and append it to the end of motherboard memory, but at the least it's going to take something like a patched version of MODE32 to do it.

(Just thought I'd mention that the MMU was already used for something at bootup in these machines. The 68020 based machines are the magical exception in that they don't have the full MMU but they do have a custom Apple ASIC that papers over the differences instead. In the MacII's case you pull that out of the 68851's socket if you later add a PMMU.)

 

[Trash80toHP_Mini]

There's no SE/30 DevNote available, AFAIK. It's just in GttMFH2E . . .

< wonders if an image of the SE/30 MemMap might be available . . . somewhere . . . >

. . . would defeat the purpose of making the data transfer as fast as possible.

IDK, but . . .

. . . IF you're building an '030 PDS Card later on . . .

. . . AND you're using the SDK as a learning experience for later use on said card . . .

. . . THEN building a memory multiplexing converter card for the SDK's I/O headers (?) . . .

. . . on the SuperMac Adapter's existing SIP interface . . .

. . . by using a microcontroller that you're familiar with already . . .

. . . would be the quickest, down-n-dirty, work around that comes to mind . . .

. . . AND running your twisted pairs straight <-> that SIP daughtercard's SE/30 PDS (or MoBo :?: ) . . .

. . . would be the cleanest (fast enough for the learning process) path that I can think of . . . :?:

 

[trag]

Call me a pessimist, but... if you're buying the development kit to get familiar with FPGAs might it be a better idea to try interfacing it to something a little slower/better documented than the SE/30 PDS first?
(Apple II, maybe an an ISA slot... how about a clip or socket-adapter to tap into an SE or Plus' 68000 bus?)

Nah. I've already had a class on VHDL and FPGA programming. It was about seven years ago... But this won't be my first shot at FPGAs. I probably know them as well as I do microcontrollers.

And interfacing them on the SE/30 or the Apple II looks about equally complicated to me because I'm not that familiar with either one. Neither the SE nor the Plus is 32 bit clean so I'd rather not try that.

The idea behind the baby steps isn't to make learning the FPGA simpler. It's to minimize the number of variables while I'm learning the SE/30 interface. If I try to get the SE/30 to command the FPGA to do something, I don't want to be left wondering whether the "something" is wrong, or the interface is wrong. I want the "something" to be as simple as possible so I can focus all my initial attention on the interface.

Starting out on an Apple II or ISA slot would just mean I was debugging interfacing with one of those computers first. That wouldn't help me any when I'm really trying to interface with an SE/30.

it seems that your plan is to map RAM into one of the Nubus slot spaces and try to remap it with the MMU? I seem to recall vaguely that 32-bit 68k Macs *already* do some fairly complicated memory mapping in order to paper over the differences between their native memory maps and those of the "24 bit" Macs. I can't find the Developer Note for the SE/30, but the one for the IIci specifically talks about how the 68030's MMU is used to remap the "small" NuBus I/O spaces (the 1MB ones, not the wide "Superslot" spaces) into the lower 8MB, in addition to shoving the location of the ROMs and built-in I/O devices. It appears the mappings for these are embedded in the ROMs. That's certainly not to say that it wouldn't be possible to add additional mappings which would take a block of memory located at 0x60000000 and append it to the end of motherboard memory, but at the least it's going to take something like a patched version of MODE32 to do it.

My first plan is to build a video card using DDR2 memory as the frame buffer. Once I get that working, I'll do the memory mapping stuff. But I don't want to get to the memory mapping part and discover that I needed a signal on my interface board that I didn't include, so I'm doing some conceptual design up front.

If all that ever works is the video card, that will still be a big accomplishment.

As to the memory mapping, I'm not so sure that will all work through the MMU. I've been doing some more pondering prompted by my recent reading in GTTMFH.

I'm going to have to spend some time with Inside Macintosh or something to figure it out. It seems to me, from what little I've read, that the Macintosh OS uses a bunch of Global Variables like ROM_base and VIA_base (not sure those names are exactly right) and probably one called RAM_base.

I would bet that it is possible to simply rewrite one of those base address globals in order to tell the OS that the RAM starts at 0x6000 0000 instead of 0x0000 0000. One might also need a little routine to copy any stuff that already exists in RAM to the proper relative addresses in the new RAM space.

Of course, with the SE/30 booting up in 24bit mode until Mode32 loads, that is a problem. I'm going to have to explore exactly what problems that causes and how expansion cards are informed of changing from 24 bit mode to 32 bit mode.

Honestly, I'm a little hazy on exactly what that 24 bit mode and 32 bit mode means down in the details. That's going to need some exploration.

But you're right, I might have to do something like put a variation on Mode_32 into the firmware of my card, or something. Or disassemble it and see what it does. Or just put a copy of the IIci ROM on the card and remap the SE/30 ROM space to the address of the IIci ROM on the card. Or put a IIci ROM on the card, program the FPGA to map the normal ROM address to the IIci ROM, and leave the SE/30 ROM socket empty so there's no contention.

 

[Gorgonops]

And interfacing them on the SE/30 or the Apple II looks about equally complicated to me because I'm not that familiar with either one. Neither the SE nor the Plus is 32 bit clean so I'd rather not try that.

The Apple II is *much* slower, narrower, simpler, and better documented than the SE/30, and has a quite straightforward memory map. The SE and Plus are also fairly simple machines (Somewhat arcane memory management aside, of course. The 68000 CPU actually has some specific support built into its bus to make it easily backwards-compatible with slow 8-bit peripheral chips like the VIA. That sort of thing takes glue on the 68030.) So I dunno, personally I could see some value in using something like that as a testbed for making a FPGA act like a peripheral. (In the case of the Apple II, hey, make the first ever 512MB DDR "Slinky" RAM card!) But hey, whatever works.

As to the memory mapping, I'm not so sure that will all work through the MMU. I've been doing some more pondering prompted by my recent reading in GTTMFH...
(snip)

But you're right, I might have to do something like put a variation on Mode_32 into the firmware of my card, or something. Or disassemble it and see what it does. Or just put a copy of the IIci ROM on the card and remap the SE/30 ROM space to the address of the IIci ROM on the card. Or put a IIci ROM on the card, program the FPGA to map the normal ROM address to the IIci ROM, and leave the SE/30 ROM socket empty so there's no contention.

I would strongly recommend looking at the work the MESS developers have done in documenting the Mac hardware:

http://mess.redump.net/mess:driver_info:mac_technical_notes

(There are many useful links off that page as well, and there's probably more useful information in the source code of the emulator itself.) and at the old Mac II-era hardware tech notes, like the IIsi, IIci, Classic II, etc. They don't go into that much detail but several of them do at least have some helpful diagrams of how the physical address space is mapped into the 24 and 32 bit logical address spaces depending on how the machine is configured. It's all done with the MMU. (Although, it's also worth remembering that in addition to the PMMU there's a hardware page-flipping device that on initial startup maps a section of ROM to 0x00000000 for IPL. You can probably ignore that for the most part but when you're reading about the boot sequence it's probably good to remember it exists so you don't get confused by it.) At boot-time mapping tables are compiled and loaded into it the PMMU... I have the IIsi DevNote open now and it shows how the PMMU is even used to paper over the physical gap between the first and second RAM banks. (This mapping happens even in 24 bit addressing mode.) Unless the "Dirty ROM"-based Macs behaved fundamentally differently, which I don't see a whole lot of evidence for, then I'd assume the SE/30's ROM does similar things with the PMMU. (Or the Apple-proprietary "HMMU" in the original Mac II's case.)

There is a "RAM BASE" global variable, but I'm skeptical that just changing it to point to a bank of memory "somewhere high" would do what you want. (The one reference I saw for it said something about the variable being used by the Trap Dispatcher, which is possibly the scariest and most obscure piece of code in Mac OS.) MacOS is designed around using fixed places in low memory for global variables, and while I suppose it's possible you might be able to use that RAM-BASE global to open a "hole" above the low memory area for some purpose (drivers?) I'd be really surprised if you could set it and move the whole OS to some arbitrary place not mapped by the MMU into what MacOS considers "RAM space".

I'm pretty sure what "Mode32" mostly does is fix some bad/missing MMU maps so the early machines operate properly in 32 bit mode. If that's the case then it may well be possible to make a custom Mode32 that can operate as an OS patch with stock SE/30 ROMs, although it may almost be simpler to make a custom ROM upgrade based on the IIsi/ci 32-bit clean ROMs that natively supports discovering and mapping "high" memory.

Or I could be *completely* wrong about everything. Your mileage may vary.

 

[Trash80toHP_Mini]

----WARNING---- )

Don't bother messing with MODE 32, there's no other way around their PATENTED software process. Which just happens to be the reason it's available as freeware . . . if there had been any other way to clean out the dirt in the SE/30's ROMs, Apple would have found it. There were legions of Mac II, IIx & SE/30 owners waiting for Apple's "32 bit" Macs to actually "work," lining up for a class action suit and Mode 32 was the key to Apple's "Crown Jewels!"

The "dirty ROM fiasco" was the reason the IIx, IIcx-SE/30 launch, the IIci and then the IIfx, along with every (?) Mac shipped until the Q630 and "Road Apple" PPCs had a ROM SIMM connector implemented on the pads that were finally left empty in those machines. Before that, ROM connector provision had only been for expansion, as on the Portable, not boo-boo band aid fixes.

Apple was forced to make the Principals of Connectix VERY, VERY rich individuals to the tune of one of those "undisclosed amounts," just like Microsoft was forced to do for the gang out at STAC Technologies back in the day!

Use the IIsi or IIci ROM approach, much easier! :approve:

 

[trag]

. (In the case of the Apple II, hey, make the first ever 512MB DDR "Slinky" RAM card!) But hey, whatever works.

Heh, heh. I keep seeing those Apple II high speed SCSI cards going for $150+ and thinking, "How hard could that be to clone?"

I would strongly recommend looking at the work the MESS developers have done in documenting the Mac hardware:
http://mess.redump.net/mess:driver_info:mac_technical_notes

helpful diagrams of how the physical address space is mapped into the 24 and 32 bit logical address spaces depending on how the machine is configured. It's all done with the MMU.

There is a "RAM BASE" global variable, but I'm skeptical that just changing it to point to a bank of memory "somewhere high" would do what you want.

I'm pretty sure what "Mode32" mostly does is fix some bad/missing MMU maps so the early machines operate properly in 32 bit mode. If that's the case then it may well be possible to make a custom Mode32 that can operate as an OS patch with stock SE/30 ROMs, although it may almost be simpler to make a custom ROM upgrade based on the IIsi/ci 32-bit clean ROMs that natively supports discovering and mapping "high" memory.

Or I could be *completely* wrong about everything. Your mileage may vary.

Thank you for the pointers. Those are all avenues which will need exploring. Happily, I don't need to explore them right now. At the moment, all I need to do is correctly identify which hardware signals must reach the FPGA in order to be able to do what I want.

At worst, even if I can't map any of the extra memory as RAM, it sounds like dbraun (?) has figured out the basics of how to turn it into a RAM disk. So at worst, I could turn it into a big RAM disk and use it as swap space for virtual memory.

 

[trag]

Don't bother messing with MODE 32, there's no other way around their PATENTED software process.

The patent isn't a problem. It should be just about expired this year....

Use the IIsi or IIci ROM approach, much easier! :approve:

Almost certainly. However, those ROMs cause a few moments of screen artifacts at boot time. It'd be nice to have something a little more elegant. Not necessary, but nice.

Still, all this is far in the future.