Aren't PICs something like small 8 bit processors? Are there 32 bit PICs? In my opinion there's no point at all in trying to emulate a 32 bit processor (68030) in a narrower architecture, e.g. 16 bit or 8 bit.
You'll have to refresh my memory about MAME. I've heard of it but cannot remember a thing about it at the moment.
The Coldfire to 68030 idea has actually been stealing my brain's CPU cycles this past week. It's an intriguing idea. I don't think I'll ever do anything with it as there are too many hurdles which must be solved in software and I'm just not a software guy. Now if I could get a team of five or six dedicated 68K/assembly software folks to work with me on hardware I produce, then I could see it happening--and maybe kick in some of the proto-type costs.
Here's what I'm thinking. If one builds a Coldfire (hereafter CF) board, one should put the system memory on the upgrade. Also, some of the CF chips have DDR controllers built in, USB2 built in and 10/100 ethernet built in.
So, what I propose is that we build (or fantasize about) a Coldfire board with an SODIMM socket for a single Laptop style DDR DIMM, a USB2 port and a 10/100 ethernet port on board. One or two MB of fast Static RAM L2 cache would be nice, but it probably isn't manageable, because the DDR controller is built into the chip. It's worth looking into though. There may be a way to do it.
At boot time, the CF should interface with the host motherboard (hereafter the 'host') and copy the ROM contents to local memory so that it will not be slowed down by toolbox calls which need access to the ROM. The only time the CF should need to wait around for the host is when it's accessing the peripheral systems. The worst performance hit is going to be the video systems/cards for the various hosts. They can't be ignored or bypassed and they need frequent attention.
The main hardware problem I see is how to avoid contention between the built-in memory controller and the motherboard memory controller. It should be possible to map the CF memory space into the proper place in the Mac Address Map so that it will be compatible with the scheme built into the Mac ROMs. But something needs to prevent the host memory controller from responding to memory operations.
For example, if the code being executed calls for a Read to memory to go out on the bus, we want the DDR memory to respond to that, but not the host's memory controller. Otherwise, the CF will get the Read data from DDR memory, go speeding along and twenty cycles later the host memory controller either delivers up other data, or throws an error, either way, clogging up the host bus with unexpected data.
One way to deal wtih this is circuitry on the CF board which would simply block any transactions to the host board which take place in RAM's address space. This is fairly easy and cheap, provided that the CPU is the only device which originates writes and reads to RAM. Are there any DMA devices which write directly to or read directly from RAM in the Mac II family? The built-in video on the IIci and IIsi?
Is there a signal the CPU can issue to disable the motherboard RAM controller?
So the first things to do would be to get the 68030 datasheet and User's Guide (got those) and compare them to the CF documents to confirm that they really are signal compatible. One wouldn't want to find that there's some obscure but essential bus arbitration signal, e.g., present on teh 68030 and missing on the CF or vice versa.
Then an instruction by instruction comparison of the instructions sets would be a good idea. We know that a bumch of 68030 instructions and addressing modes are missing from the CF, but it is good to nail down which ones. Then compare the missing instructions/modes with the documentation for that library (mentioned on Freescale's site) which is supposed to emulate the missing instructions and make sure everything is there.
If it is, then one can probably produce boot code for the CF card which will cause it to power up, do a memory test, load a set of exception vectors that point at emulation code for the missing 68K instructions, copy the Mac ROM from the host bus to the local memory and then begin executing the Mac ROM to boot as a Macintosh.
Drivers would have to be written for the built-in 10/100 Enet and the USB 2.0 port as well, but that might not be too hard (for software types). Once written it would be easy enough to incorporate those into the boot code of the CF card stored on a Flash chip on the card.
So the USB port could be bootable and conceivably, the 10/100 port could make the machine net bootable. as well.
I'd really like to get some kind of disk controller on the CF card as well, but can't think of a good way to do it. The reason is that going out to the host for ssslllloooowww SCSI access is punishing. One could connect storage to the USB 2.0 port, but it's kind of clunky to got USB 2.0 to IDE inside the Mac. Works fine for external drives, but the user should be able to use internal drives without taking a performance hit.
Oh, while we're writing a special boot ROM for the CF, it should also patch the SCSI Manager--well replace it with a version which is SCSI Manager 4.3 compatible. This is discussed in some (but is it enough?) detail in the Inside Macintosh books. This would allow the USB2.0 bus to appear as a second SCSI bus to the Mac Device Manager and/or Slot manager. Then the USB 2.0 driver would be written to appear as a SCSI SIM.
So, we need POST and exception handling code in the boot ROM, SCSI Manager 4.3 patch, USB2.0 and 10/100 drivers, and some code to copy the ROM to local memory. We may also need a software solution to possible contention wtih the motherboard memory controller but that can probably be handed in hardware.
I would like to reverse engineer a PowerCache030 some time to see what it is doing to interface the faster CPU to the slower host machine. Daystar had some smart people and I'm sure that they dealt with some issues in that interface that I would never think about and might never find in a million years of looking. That would mainly consist of removing the Gal16V8 chips and trying to determine what their programming is.
After that the place to start is with a Coldfire development board. Most CPUs have Development Boards available for them. The chip is mounted on a board which provides many of the support functions and interfaces oen needs in order to get started working with the chip. There is also usually a programming interface and debug interface to a host PC so that one can write programs to run on the chip, and then debug them.
Then an interface board between the CF development board (there are usually connectors which bring out most of the CPU I/O pins on development boards) and the first target Mac would be needed.
After that I'm a little hazy about how to proceed. How do you incrementally develop the thing. In other words, how can you tell if any part of the emulation is working, until you get the whole thing (or most of it) working properly. Perhaps pull the Mac ROMs and substitute simple ROMs with just a few instructions to execute and then put test code in teh faux ROMS during development, adding progressively more complex code until one is ready to try operating with the actual Mac ROMs... Hmmmm.