Thread
68060 accelerator cards for Mac: Would you be willing?
I wonder ... if this is a PDS card, could we redirect the excepted instructions back over to the original 680x0 for execution? Or build the card with a 68k co-processor onboard?
In short, one wonders if a fast 68k copro would help ...
... and an FPU.
As well, if we're going to use this an accelerator, it has to be able to interface to the Mac at its original CPU bus speed, and cache instructions and data between accesses.
Again:
and the follow-one, more technical discussion at Applefritter.
Have you ever run a Mac emu on the 060 Amiga and compared? Just curious.
Excuse me guys: I'm just catching up with this thread.
It occurs to me that my idea of using 68k copros is just making everything more than twice as complicated.
one could always read the thread before posting
So they are probably the same apps which would break under Coldfire too :-/
I didn't notice Coldfire had already been mentioned - I guess I'll just blame bad eyesight or the fact it was getting late or something lame. I think more coffee is in order...!
There are code differences between 68000, 68020/030 and 68040 strains inside the 680x0 family that stop code written for one running on the others, but it's not caused any issues in Mac OS because the OS was programmed or amended to run on the later 68k chips.
I see no reason why the same would not apply to CF68k chips, given the correct intermediary, possibly on the form of a FPGA, between the computer and the CF68k chip. It'd not be ideal but the commands that are mentioned in the FAQ are well documented so they could be trapped and redirected or re-coded to legal routines if you had an experienced programmer on the case. Either that or you need a pre-boot patch ROM that loads the necessary patches to 'patch' the Mac OS ROM. Daystar's Turbo cards do this, so it's possible.
IMHO that would be required to use either a 68060 or a Coldfire as both vary slightly from earlier models and there's no way to patch the OS at a low enough level as to sort it out before code execution takes place, short of loading it from ROM at power-on otherwise.
Of course this is all pretty moot as it's never going to happen, but it makes for interesting speculation
There are code differences between 68000, 68020/030 and 68040 strains inside the 680x0 family that stop code written for one running on the others, but it's not caused any issues in Mac OS because the OS was programmed or amended to run on the later 68k chips.
I see no reason why the same would not apply to CF68k chips, given the correct intermediary, possibly on the form of a FPGA, between the computer and the CF68k chip. It'd not be ideal but the commands that are mentioned in the FAQ are well documented so they could be trapped and redirected or re-coded to legal routines if you had an experienced programmer on the case. Either that or you need a pre-boot patch ROM that loads the necessary patches to 'patch' the Mac OS ROM. Daystar's Turbo cards do this, so it's possible.
IMHO that would be required to use either a 68060 or a Coldfire as both vary slightly from earlier models and there's no way to patch the OS at a low enough level as to sort it out before code execution takes place, short of loading it from ROM at power-on otherwise.
Of course this is all pretty moot as it's never going to happen, but it makes for interesting speculation
No problem, SVP. With enough coffee, anything is possible!
The nice thing about Coldfire is that they are the only chips around which are (almost) compatible with the 68K instruction set and are available for $30 and less in speeds an order of magnitude faster than are in the original machines. I don't think any other chips come that close to providing an affordable speedup for 68K based systems.
As I mentioned above, the problem with 68060 upgrades is that the 68060 chip costs about $300 each from Freescale. You could build an accelerator for them, but at those prices three people will be able to afford them.
Heck, I had an idea about building a copy of the PowerCache030 for SE/30s until I priced 68030 chips. The original 68030 chip is priced around $100 each depending on the speed. Building new accelerators around those chips isn't practical either, at those prices. That's not even counting the FPU chip to go with it.
You're correct. It is incompatible or, at least, not fully compatible. But, if one wrapped the hardware and software around it to make it compatible it doesn't matter if anyone develops for it. It would look like a fast 68K to the host Macintosh. Old and new 68K software would run on it. That's the dream. More about dreaming below.
The big attraction of the Coldfire is that presumably, most of the code would not be emulated. That depends on the actual instructions used in 68K programs, but it would be nice to have an accelerator which is mostly running object code natively without emulation.
Yeah, my previous projects are not in the same ballpark, neighborhood, nor municipality as an accelerator. But I did mention in my post (see paranthetical comment) that it was a more of a fantasy and that for there to be any realistic chance of realizing such a dream I'd need a bunch of software guys to help.
On the other hand, in my experience, the trick to doing large complex projects is to rob them of their complexity by breaking them into smaller doable chunks. That's part of what I was trying to do in my previous post. We don't know how to make an accelerator, but we could compare the list of signals in two datasheets (680030 and target Coldfire). We can also compare instruction sets from two different datasheets. Those things are simple, though the latter would be tedious.
Once we had documented the differences, I'm pretty sure we could check the documentation of that 68K emulation library to see if it makes up the difference.
I know how (in theory) to map out the functions of the GAL chips on an old Daystar accelerator card. Translating it to functions it's performing on an active IIci or SE/30 bus would be more daunting, but mainly because one would need a strong understanding of how the 68030 runs its bus and communicates.
Once we knew all those things, we would (roughly) know how to connect the host Macintosh bus to GLUE logic (probably in an FPGA) which would perform the functions that the old GALs did, plus any new Coldfire specific logic, and connect that to the pins of the Coldfire chip. I've done FPGA programming so I'm pretty sure I could program a chip to perform as the GLUE.
I certainly know or can find from documentation how to connect a boot ROM (programmable Flash) to a Coldfire chip. I'm not as certain that all the unsupported 68K instructions can be made to generate exceptions. But that will be apparent from the chip's documentation and the comparison of the instruction sets.
Hooking up the USB and 10/100 ports is trivially easy. Connecting the DDR memory is more difficult because all the traces need to be the same length and mostly insulated from noise, which probably means on interior layers with power or ground layers between them and the outside world. This may create a need for a six layer board, blech. Prototypes with 4 layer boards are cheap (<$200 per three) Prototypes with 6 or more layers are much more expensive.
So, from my hardware point of view, I think it is doable. It would take a lot of time.
It is also possible that the initial documentation studies would cause one to conclude that it isn't practical. Perhaps the Coldfire I/O busses are just too different from the 68K. I'm assuming at this point, that they're fairly similar with 32 address and 32 data lines, plus similar or identical bus arbitration signals.
That is mainly a software problem.
There are USB chipsets which interface directly with a CPU bus rather than to PCI. So it would be fairly trivial to get one of those chipsets onto a NuBus card. It would need an FPGA (or at least a CPLD) to provide the GLUE between the NuBus and the USB chipset. In many ways it'd be easier to just build a PDS to USB board. There's a lot less translation from bus to USB chip that way but some kind of hardware interface between the USB chipset and the PDS slot would probably still be needed.
How do you write a USB driver after that though? Ideally, one would write it as a SCSI SIM so that the USB bus would be bootable. Know any 68K Mac developers who are bored and need a large software project? Writing USB drivers would probably be pretty large, I think. But if you can come up with some serious 68K/USB programmers, I'm willing to team up and support the hardware side. They're also going to need to write a SCSI Manager 4.3 type XPT so that the host machine can handle having more than one SCSI bus.
Discussion of XPT and SIM can be found fairly early in Chapter 4 of "Inside Macintosh, Devices" which is downloadable from Apple as a several PDFs (one per chapter, chapter 4 is titled "SCSI Manager 4.3).
What I'd really like to do is build an IDE board for 68K Macs. That's been kicking around in my head too. It'd be cool to have an interface for laptop IDE drives in the old 68K models. I just haven't made the time for it and now I've started a new job and have even less time.
I've been telling myself that when I finish assembling the last few IIfx SIMMs I have laying around here I'll start on the next new project, but the blank PCBs are still sitting on my bench. Sigh.
I already have a (non-writable) board design drawn for the ROM SIMM. I've never had it fabricated because it doesn't appear to make economic sense. I also think that I may need to revise it to put two chips on each side, instead of four chips on the same side. If one is hand soldering the chips onto the SIMM, one needs space between the chips for the soldering pencil.
It would cost about $600 just to have 200 SIMM circuit boards made. That's not counting the cost of chips. After that the SIMMs can be built one at a time as needed at a marginal cost of about $4 for the chips. It seems unlikely to me that there are enough folks wanting ROM SIMMs to make up the $600 plus $4 per SIMM even at $20 or $30 per SIMM, assuming they would pay that much. And that's not even considering the time involved. While fewer than 200 boards could be made, the total cost doesn't actually drop much or at all, the unit price just goes up.
And there's the issue that such a board would violate Apple's copyrights, though why any sane person would care at this point... Still, makes it kind of hard to advertise and sell.
If you want the board flashable as well, that would require hooking up the Write_Enable signal (assuming it's even present in the ROM socket) and the then coding up a software routine which can massage the Flash chips into writing their contents. That's software again, at which I am marginally competent, and more importantly, just not that interested. I can connect the wires. Writing the routine which will properly massage the Flash chips into being written does not interest me.
More importantly, it makes it too expensive.
The very first thing we need to look at in any concept is the cost per unit, I think. 68K CPUs cost about $100 each depending on the model. If you can live without the MMU and at low speeds, they get cheaper.
68060 and 68040 are also too expensive.
Coldfire chips are cheap enough (~$30) but I see your post about them lacking an FPU. So, we either live without an FPU in accelerated systems, or....
If we're going to try to implement an FPU in an FPGA, then I'd say we're better off just going all the way back to the emulate the 68030 in an FPGA. Besides, the CF doesn't have a built-in interface to an FPU the way the 68030 does, does it? That would make providing an external FPU much more daunting.
FPGAs with about twice as much logic as found in an actual 68030 cost under $20 and run at 200 MHz.
The 68030 contains about 273,000 transistors. The 68040 contains just under 1,200,000 transistors.
If we assume that there are about 4 transistors per gate (this is very conservative from the point of view of this estimate) then the 68030 contains about 70,000 gates and the 68040 contains about 300,000 gates.
The Xilinx XC3S500E contains about 500,000 gates and costs $20.75 when purchased individually from Digi-Key. I'm not sure how FPGA gates translates to CPU transistors or even CPU gates though.
There are at least 4 transistors in each real world gate, except inverters which only have two. If we assume an average of four (which should be low) we get the numbers above for total gates in the target CPUs. I would assume that one needs many more gates in an FPGA to get the same functionality found in a CPU, because we're not custom designing the logic. But how much more?
The XC3S500E has 7 times as many gates as a 68030. Is that enough? Is it too much?
Does a 200MHz FPGA run non-optimized logic at a speed faster than 40MHz 68030 with custom logic.
I'm not sure if I'm interpreting your comment correctly, but there is no NuBus UW SCSI card. The fastest SCSI card made (or shipped anyway) was Fast & Wide with max transfer rates of 20 MB/s theoretical. UW is 40 MB/s theoretical maximum and was the next step up and the last one before LVD hit the scenes.
Most non-OEM'd UW drives work fine on a Fast Wide card. I know - I've done it many times
I'm only throwing ideas out of my head here, but would it make any more sense to build a faster 68030/6882 combo in FPGA? It's something that's been mooted in the Amiga community to create a system-on-chip Amiga 68k machine. You'd need a decent number of gates on the chip to do it but from what I've read there are plenty of FPGAs from companies like XILINX that will do it easily, you just need a good FPGA programmer and plenty of time to work out how.
I have no idea what production costs would be like on something like that, but if the FPGAs are cheap them all you need is a socket or PDS interface for it, and a pre-load system using something like a SD card to load the code to the chips. If you improve the code at any stage you can dump a new file to the SD card and that's your CPU improved. It's a novel idea. It'd also allow you to incorporate patches for the Mac OS ROM if you were really cunning - BSD/Linux/A/UX boot loader in ROM anyone?
I'm only throwing ideas out of my head here, but would it make any more sense to build a faster 68030/6882 combo in FPGA? It's something that's been mooted in the Amiga community to create a system-on-chip Amiga 68k machine. You'd need a decent number of gates on the chip to do it but from what I've read there are plenty of FPGAs from companies like XILINX that will do it easily, you just need a good FPGA programmer and plenty of time to work out how.
I have no idea what production costs would be like on something like that, but if the FPGAs are cheap them all you need is a socket or PDS interface for it, and a pre-load system using something like a SD card to load the code to the chips. If you improve the code at any stage you can dump a new file to the SD card and that's your CPU improved. It's a novel idea. It'd also allow you to incorporate patches for the Mac OS ROM if you were really cunning - BSD/Linux/A/UX boot loader in ROM anyone?
One final comment on all the updated interface card ideas...
The problem with NuBus cards is that the maximum theoretical performance of a NuBus card is 10MHz X 4 bytes = 40 MB/s. And the reality is quite a bit slower with bus overhead. For example, on the NuBus, the data and address pins are multiplexed, which means that addresses and data are transmitted on teh same wires, sequentially. A PDS bus has separate address and data busses as well as running faster than 10 MHz.
Apple's guidelines for cards for PDS slots are very similar to NuBus cards, so there's actually not that much difference in developing one or the other.
With FPGAs it's not that difficult to build a card which will work regardless of which PDS slot it's plugged into. Although making it autodetect that might be a bit of a trick. It'd be nicer if the user set a jumper.
Of course, there's only one PDS slot in each machine. So a multi-function card such as IDE/USB mentioned above becomes attractive.
At this point one starts thinking about all the things that would benefit from faster performance and is quickly contemplating a card wtih IDE, USB, video, and 10/100 ethernet all rolled into one. Then, if one assumes that a machine wtih such a card installed would also be one with a fast CPU upgrade, one starts thinking, "hey, the upgrade is running at 40 or 50 MHz, why am I limiting my peripheral upgrades with a 16 MHz bus speed? If I put them all on the same card, they could all run at 40 or 50 MHz bus speeds.
And then one start comptemplating a total 68K computer upgrade that just uses the host motherboard as an I/O interface....
The problem with NuBus cards is that the maximum theoretical performance of a NuBus card is 10MHz X 4 bytes = 40 MB/s. And the reality is quite a bit slower with bus overhead. For example, on the NuBus, the data and address pins are multiplexed, which means that addresses and data are transmitted on teh same wires, sequentially. A PDS bus has separate address and data busses as well as running faster than 10 MHz.
Apple's guidelines for cards for PDS slots are very similar to NuBus cards, so there's actually not that much difference in developing one or the other.
With FPGAs it's not that difficult to build a card which will work regardless of which PDS slot it's plugged into. Although making it autodetect that might be a bit of a trick. It'd be nicer if the user set a jumper.
Of course, there's only one PDS slot in each machine. So a multi-function card such as IDE/USB mentioned above becomes attractive.
At this point one starts thinking about all the things that would benefit from faster performance and is quickly contemplating a card wtih IDE, USB, video, and 10/100 ethernet all rolled into one. Then, if one assumes that a machine wtih such a card installed would also be one with a fast CPU upgrade, one starts thinking, "hey, the upgrade is running at 40 or 50 MHz, why am I limiting my peripheral upgrades with a 16 MHz bus speed? If I put them all on the same card, they could all run at 40 or 50 MHz bus speeds.
And then one start comptemplating a total 68K computer upgrade that just uses the host motherboard as an I/O interface....
Interesting thoughts, trag. Here's a few of mine.
Other thoughts:
Use some of the DDR RAM as VRAM and add a VGA controller chip.
Ah, so you're that guy. Eeeexcellent.
I've added a post to the Applefritter thread, with these thoughts:
Does the above make some kind of sense? If I'm thinking right, it means breaking up the task further, to the chip subsystem level. Emulate the data and instruction caches in hardware, and only build the ALU and FPU in the FPGA.
Other thoughts:
Use some of the DDR RAM as VRAM and add a VGA controller chip.
Yeh, that's what the Amiga has got to - people have cloned the chipset to FPGAs and are working on replacement motherboards for the existing, and a new machine.
And then one contemplates a Coldfire SBC that just thinks it's a Mac... which saves you all the problems of interfacing to the '030 PDS etc
BTW Eudimorphodon at the Applefritter thread suggests another possible plan of attack:
... to recreate a PDS upgrade like the Apple 601 cards, but packing a G3/G4 or two, and running the Apple 68k emulator in PPC code.
So... 68k PDS to ZIF socket, anyone?
There are G3 upgrades available cheaply for the 6100 ... so what about a Turbo601 clone or adapter with a 6100 PDS slot on it?
Sorry to dig up an old thread, but isn't the Coldfire very 68K compatible? There are Amiga Coldfire upgrades that run with no issues...
And the reasons why were covered earlier here.
I do note that while playing with the sources of Basilisk II, there are ROM patches to make the Mac ROM work on a 68060 CPU. Why? Basilisk II has a native execution mode where it passes the 68k instructions through to the host 68k CPU when it's running on a 68k Unix/Linux platform. Said host can be a 68060, so it patches the ROM to make things behave.
So it's not impossible in software. However, in hardware, good luck
Can go one better- FreeDOS running with FUSION from http://www.emulators.com... wicked fast 68k. When I tried it Apple System Profiler was reporting speeds of 300mhz '040s. It also has very little overhead due to DOS being so lean.Or find an old PC, install Windows 95, change the boot screen to look like the MacOS splash screen, set Basilisk II to run on startup, and put it all inside a IIfx case!Would probably be faster than a real 68k, depending on what sort of PC you could find for the project...
crazy! I need to find a free PC now...
UW drives work as a narrow drive if you terminate (preferably) or disregard the wide bits - you get a converter to do this.
You could probably get PCB manufacture/assembly a bit cheaper. I think olimex were the people to go to for a while - not sure now. The CFFA guy gets things assembled and is still able to sell for a reasonable price - maybe ask him? Oh yeah the real prize in the ROM project would be to be able to use the iici ROM simm.
Just thinking.. didn't the macpicasso have a nubus-pci implementation? I know the picasso card on the amiga had a local pci bus for expansion (which had a few expansions made for it). There is also a device for the amiga called a mediator (made by elbox) that performs a similar role (actually think it piggybacks some of the chips?) .
Though it would probably cost a bit, perhaps a nubus or pds PCI "bridge" is the way to go as software drivers exist already for many PCI devices under classic OS.
You could probably get PCB manufacture/assembly a bit cheaper. I think olimex were the people to go to for a while - not sure now. The CFFA guy gets things assembled and is still able to sell for a reasonable price - maybe ask him? Oh yeah the real prize in the ROM project would be to be able to use the iici ROM simm.
Just thinking.. didn't the macpicasso have a nubus-pci implementation? I know the picasso card on the amiga had a local pci bus for expansion (which had a few expansions made for it). There is also a device for the amiga called a mediator (made by elbox) that performs a similar role (actually think it piggybacks some of the chips?) .
Though it would probably cost a bit, perhaps a nubus or pds PCI "bridge" is the way to go as software drivers exist already for many PCI devices under classic OS.
Hm. PDS to PCI maybe. Nubus to PCI sounds like pain.
Drivers, sure, but you've still got to get the 68k Mac to recognise the existence of the PCI controller. Or fool it into thinking it's something else. And then get the device drivers for your PCI card to load onto a 68k Mac, and run on a 68k CPU. Considering there were no 68k machines with PCI, I'd be willing to bet all the drivers are written for PPC.
Drivers, sure, but you've still got to get the 68k Mac to recognise the existence of the PCI controller. Or fool it into thinking it's something else. And then get the device drivers for your PCI card to load onto a 68k Mac, and run on a 68k CPU. Considering there were no 68k machines with PCI, I'd be willing to bet all the drivers are written for PPC.
I've been surfing FPGA sites today.
Turns out you can develop your prototype adapter on an FPGA, and then make a "write once" copy of it on a much cheaper CPLD (programmable logic device). Exact same code goes in. So that makes the end product a load cheaper than the prototype, as far as I can tell, especially if you can squirt the CPLDs at home.
NB somewhere on that site there's a mention that their FPGAs are PCI compliant, whatever that means
Turns out you can develop your prototype adapter on an FPGA, and then make a "write once" copy of it on a much cheaper CPLD (programmable logic device). Exact same code goes in. So that makes the end product a load cheaper than the prototype, as far as I can tell, especially if you can squirt the CPLDs at home.
NB somewhere on that site there's a mention that their FPGAs are PCI compliant, whatever that means
What I meant here was using the existing '030/'040 CPU from the host Mac and providing a socket for it on the upgrade, or, if the upgrade is in the PDS socket, some other way of trapping non-Coldfire instructions and shuttling them back over to the host CPU. Run compatible instructions at Coldfire speeds, and what's left over at '030 speeds.
So the issue of cost of the 68k goes away, but the extra complexity remains.
Agreed.
Again, apologies for waking the dead.
Not entirely sure what's going on here, but this guy seems to be doing, uh, something, with 68k emulation on an FPGA. He shows his board mounting a real 68000 to check the accuracy of the emulation (Wednesday, April 28th, 2010), and then something going on with an '030 (Tuesday, July 21st, 2009) and an '060 (Saturday, June 13th, 2009) attached.
FPGA Arcade
FPGA Arcade
You people should take a survey and see how many people would be willing to dish out real money (probably $200 USD without the CPU) for an adapter board and ROM, then contact the guy who makes these:
http://www.powerphenix.com/
and see if he'd be interested in building 3.3 volt -> 5 volt, m68060 to m68040 adapter boards and patched ROM SIMMs for Macs. He knows tons about m68060s and especially about using them with older systems and designs.
http://www.powerphenix.com/
and see if he'd be interested in building 3.3 volt -> 5 volt, m68060 to m68040 adapter boards and patched ROM SIMMs for Macs. He knows tons about m68060s and especially about using them with older systems and designs.
Except I thought we'd moved on from '060s to Coldfires and/or FPGAs?
/eta/ Yes, he has done a remarkable job on those upgrades.
/eta/ Yes, he has done a remarkable job on those upgrades.
Making an m68060 work in an m68040 system is MUCH more feasible than adapting a Coldfire. The m68060 and m68040 are very similar, but the Coldfire is completely different - clocking, interrupts, booting, voltages, and the whole bus would all need to be adapted. That's why the Atari Coldfire people made a whole new computer.
Wow, this is a fun zombie. You've got to love the "tech threads" that have such a high speculation-to-action ratio... ;^)
It's all been hashed to death, of course, but here's a really ignorant take on the "could we run MacOS on Coldfire?" question... why not just do it, for crying out loud? It seems that this thread is just hopelessly bogged down with minutia such as how one could somehow adapt the Coldfire CPU so it could physically be used as an upgrade CPU for an existing Mac, which is putting the cart *way ahead* of the horse. Why not prove out the concept on existing hardware (like a PCI slot-equipped Coldfire demo board) first? That's what the Atari Coldfire people did, and got a version of the Atari TOS patched and booting on a demo board well before any of their custom hardware was available.
It's been mentioned in one of these threads before, but one of the beautiful things about the classic MacOS when thinking about a project like this is its level of device independence. Emulators such as BasiliskII run MacOS in a virtual environment which has very little in common with a real 68k Macintosh simply by patching the ROM image appropriately. It seems to me that the simplest way to do Mac-On-Coldfire would be to incorporate the "direct-execution" core of BasiliskII (as utilized on Amiga and other 68k platforms) into a "New World 68k" bootloader/kernel, incorporating the CK68Klib binary compatibility layer and with low-level drivers for disk and I/O devices borrowed from Linux/uClinux sources. All the software tinkertoys are there, and I imagine a competent and very knowledgeable hacker (IE, one of the maintainers of BasiliskII or Sheepshaver) could put them together in a few man-months of work.
The real question is whether the end result would really be workable. There are certain edge-case conditions of existing 680x0 code that CK68Klib doesn't handle, and whether MacOS uses them and if so whether it's practical to patch around them are all open questions. But clearly it should be possible to deduce the answers before running off deep into the fantasy land of constructing a 680x0 socket-compatible accelerator for existing Macs.
A suitable Coldfire demo board isn't cheap, mind you. You're probably looking at a couple thousand bucks. Ironically a better approach might be to use an Atari Coldfire board. It's not cheap either, at 599 Euros, and availability is a problem, but it might be the best game in town. Of course, it's probably worth pondering that fact for a while. Any product based on this "research", whether it be an accelerator board or a complete new PCI-equipped Coldfire psuedo-Mac, is unlikely to end up much cheaper than that.
$600-ish dollars is a lot of money for a 300Mhz computer. Such a thing might well run 68K Mac programs at speeds comparable to a 1Ghz+ G4 or 2Ghz Pentium running an emulator, but... either of those options costs a heck of a lot less. (I can't find any benchmarks, but I'd be *seriously* surprised if the Atari Coldfire boards run EmuTOS faster than even a semi-modern PC running ARAnyM.) So clearly, the *only* reason to do this would be for love. Are there really enough people out there with undying love and nostalgia for *specifically* 68K Macs that isn't satisfied by emulators to support such a project? I have no idea. The Amiga and Atari people were faced with the complete extinction of their platforms so sketchy and uneconomical low-volume-production hardware wizardry was the only option the hardcore fans had to keep their love alive. Macs didn't die, they evolved, so... is there a point? Eh, who knows. All I know is there's an awful lot of talking and very little action. ;^b
It's all been hashed to death, of course, but here's a really ignorant take on the "could we run MacOS on Coldfire?" question... why not just do it, for crying out loud? It seems that this thread is just hopelessly bogged down with minutia such as how one could somehow adapt the Coldfire CPU so it could physically be used as an upgrade CPU for an existing Mac, which is putting the cart *way ahead* of the horse. Why not prove out the concept on existing hardware (like a PCI slot-equipped Coldfire demo board) first? That's what the Atari Coldfire people did, and got a version of the Atari TOS patched and booting on a demo board well before any of their custom hardware was available.
It's been mentioned in one of these threads before, but one of the beautiful things about the classic MacOS when thinking about a project like this is its level of device independence. Emulators such as BasiliskII run MacOS in a virtual environment which has very little in common with a real 68k Macintosh simply by patching the ROM image appropriately. It seems to me that the simplest way to do Mac-On-Coldfire would be to incorporate the "direct-execution" core of BasiliskII (as utilized on Amiga and other 68k platforms) into a "New World 68k" bootloader/kernel, incorporating the CK68Klib binary compatibility layer and with low-level drivers for disk and I/O devices borrowed from Linux/uClinux sources. All the software tinkertoys are there, and I imagine a competent and very knowledgeable hacker (IE, one of the maintainers of BasiliskII or Sheepshaver) could put them together in a few man-months of work.
The real question is whether the end result would really be workable. There are certain edge-case conditions of existing 680x0 code that CK68Klib doesn't handle, and whether MacOS uses them and if so whether it's practical to patch around them are all open questions. But clearly it should be possible to deduce the answers before running off deep into the fantasy land of constructing a 680x0 socket-compatible accelerator for existing Macs.
A suitable Coldfire demo board isn't cheap, mind you. You're probably looking at a couple thousand bucks. Ironically a better approach might be to use an Atari Coldfire board. It's not cheap either, at 599 Euros, and availability is a problem, but it might be the best game in town. Of course, it's probably worth pondering that fact for a while. Any product based on this "research", whether it be an accelerator board or a complete new PCI-equipped Coldfire psuedo-Mac, is unlikely to end up much cheaper than that.
$600-ish dollars is a lot of money for a 300Mhz computer. Such a thing might well run 68K Mac programs at speeds comparable to a 1Ghz+ G4 or 2Ghz Pentium running an emulator, but... either of those options costs a heck of a lot less. (I can't find any benchmarks, but I'd be *seriously* surprised if the Atari Coldfire boards run EmuTOS faster than even a semi-modern PC running ARAnyM.) So clearly, the *only* reason to do this would be for love. Are there really enough people out there with undying love and nostalgia for *specifically* 68K Macs that isn't satisfied by emulators to support such a project? I have no idea. The Amiga and Atari people were faced with the complete extinction of their platforms so sketchy and uneconomical low-volume-production hardware wizardry was the only option the hardcore fans had to keep their love alive. Macs didn't die, they evolved, so... is there a point? Eh, who knows. All I know is there's an awful lot of talking and very little action. ;^b