Thread
68060 accelerator cards for Mac: Would you be willing?
A few months ago I realized that although Amiga and Atari Falcon have had 060 accelerator cards made for them in the past, no mac or accelerator card for one has used the 68060 chip. This was probably due to the jump to Power PC and all, but can you imagine how awesome your 020 or 030 based mac would be with a Daystar Turbo 060 card inside it? System 6 would scream and run circles around even the fastest win or mactels, OS 8 would run at near PPC speeds, and games that had slowdown on even the fastest of 040 machines would perform like a dream. And to sweeten the deal, it would come with an onboard Kickstart 3.1 rom and 10MB of flash memory to access the Amiga world. It would be compatible with: Macintosh II, Macintosh LC, SE/30, Classic II, all Performa and Centris/Quadra models, Macintosh TV, all LCs, IIx IIci, IIsi, IIvx, Color Classic, basically everything with an 020 and up. So, how does the prospect of this sound? Anyone willing to make this card?
This topic came up in the last forum and we concluded the 68060 was noyt 100% hardware compatible with the 68040 so the OS would have had to be changed to even get a Mac to boot.
The reason an 060 accelerator was designed but never shipped is because of the above plus the fact that it could not compete in speed with the 601 upgrades being planned/sold.
G3's being dirt cheap now has nothing to do with how fast you can get a 68K to run with upgrades. You do see people blowing $100+ just to get an 030/50 for an SE/30 and $100's more to get 256 greyscale on the same machine.
The reason an 060 accelerator was designed but never shipped is because of the above plus the fact that it could not compete in speed with the 601 upgrades being planned/sold.
G3's being dirt cheap now has nothing to do with how fast you can get a 68K to run with upgrades. You do see people blowing $100+ just to get an 030/50 for an SE/30 and $100's more to get 256 greyscale on the same machine.
Not all 060 variants are full 060's, either. The ones with the highest clock speeds, up to 75 mhz are all stripped down models the equivalent to an LC in the 040 line, so to get full functionality, you have to go with a slower chip, I think the 50mhz version was the fastest to have both the FPU and MMU on chip. At that speed, the performance difference over a chipped 040 isn't worth the expense.
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...
Would probably be faster than a real 68k, depending on what sort of PC you could find for the project...601 PPC running vanilla PhotoShop 2.5 -- slower than a 68040 Mac.
601 PPC running PhotoShop 2.5 with PPC plugin -- nippier than any Quadra.
And that is the final history of 68K accelerators. They were never going to be faster than new (competitively priced) PowerMacs and PPC upgrades.
601 PPC running PhotoShop 2.5 with PPC plugin -- nippier than any Quadra.
And that is the final history of 68K accelerators. They were never going to be faster than new (competitively priced) PowerMacs and PPC upgrades.
Ahem:
You might also be interested in this PPCMLA discussion
Then:
I also did ten Google pages digging up links on m68k emulation, and then my browser crashed [xx(] ]'>
You might also be interested in this PPCMLA discussion
Hmmm.... I think I would be very interested in a 300Mhz 68K mac upgrade based on coldfire. So, who's going to make it?
Ther would have to be the coldfire chip and some flash RAM for the emulator code, and it would have to socket into an 040 socket, much like the QuadDoubler accelrator.
Ther would have to be the coldfire chip and some flash RAM for the emulator code, and it would have to socket into an 040 socket, much like the QuadDoubler accelrator.
The first thing to do is to price ColdFire chips of the type you might wish to use. The problem, in my mind, with the 68060 accelerator idea is that the 68060 chip costs (last time I checked) well over $100 per unit. So even if you designed and built such an upgrade, it would cost in the neighborhood of $200 each even if you gave your time away for free and assumed the risk of not getting your money back after building some number of units.
But if fast Coldfire chips are, say, $30 each, then that would be an affordable upgrade.
I haven't looked at Coldfire in a while but are they 32 bit wide processors? How much does the 300 MHz version cost per chip? Which version of the chip is most 68K compatible?
If the processors are down under $30 each I'd say that it is very doable project, although I'm unclear on how you get the board to run 68K code without losing too much performance.
Ideally, you'd want the Coldfire to execute instructions without any other processing, when an instruction is compatible so that you don't lose any CPU cycles. Yet, you need some mechanism for intercepting non-compatible 68K instructions and translating them, otherwise. Perhaps a little FPGA or second microprocessor could sit between the Coldfire and the datastream from the Mac and monitor the instructions as they go by and provide translation as needed. The only problem with this approach is how does the monitor system distinguish between data and instruction transactions?
Ah, I read the link above. If I'm reading it correctly, 68K instructions which are not supported on the Coldfire, should generate an exception, which can then be handled by executing the proper code on the Coldfire to emulate the excepted 68K instruction. Very neat. It's the same mechanism which the Mac Toolbox uses to execute its routines. Now, would that be completely compatible or only mostly compatible? And again, how much to purchase each Coldfire CPU?
Another approach would be to design a 68030 chip into an FPGA. Chips which can do the deed are available for under $20 each now. But I think the magnitude of completely designing a 68030 compatible CPU chip, even with modern Verilog or VHDL would be enormous. Heck, just reading the User's Manual for the 68030 such that you understand what needs to be emulated is a daunting task. There's a ton of stuff going on behind the scenes on that chip.
Beyond properly emulating each instruction, one must make sure that all the control registers, interrupt functionality and supervisory systems operate as expected. That's a lot of stuff.
But if fast Coldfire chips are, say, $30 each, then that would be an affordable upgrade.
I haven't looked at Coldfire in a while but are they 32 bit wide processors? How much does the 300 MHz version cost per chip? Which version of the chip is most 68K compatible?
If the processors are down under $30 each I'd say that it is very doable project, although I'm unclear on how you get the board to run 68K code without losing too much performance.
Ideally, you'd want the Coldfire to execute instructions without any other processing, when an instruction is compatible so that you don't lose any CPU cycles. Yet, you need some mechanism for intercepting non-compatible 68K instructions and translating them, otherwise. Perhaps a little FPGA or second microprocessor could sit between the Coldfire and the datastream from the Mac and monitor the instructions as they go by and provide translation as needed. The only problem with this approach is how does the monitor system distinguish between data and instruction transactions?
Ah, I read the link above. If I'm reading it correctly, 68K instructions which are not supported on the Coldfire, should generate an exception, which can then be handled by executing the proper code on the Coldfire to emulate the excepted 68K instruction. Very neat. It's the same mechanism which the Mac Toolbox uses to execute its routines. Now, would that be completely compatible or only mostly compatible? And again, how much to purchase each Coldfire CPU?
Another approach would be to design a 68030 chip into an FPGA. Chips which can do the deed are available for under $20 each now. But I think the magnitude of completely designing a 68030 compatible CPU chip, even with modern Verilog or VHDL would be enormous. Heck, just reading the User's Manual for the 68030 such that you understand what needs to be emulated is a daunting task. There's a ton of stuff going on behind the scenes on that chip.
Beyond properly emulating each instruction, one must make sure that all the control registers, interrupt functionality and supervisory systems operate as expected. That's a lot of stuff.
The 060 is really quite expensive these days with all the amiga and atari people fighting for them - especially the good revision. It's almost impossible to get them affordably.
Maybe a g3 or g4 card would be better - especially if you could use it just as a co-processor for executing PPC apps (while not giving up the 040 as the main processor)?
Maybe a g3 or g4 card would be better - especially if you could use it just as a co-processor for executing PPC apps (while not giving up the 040 as the main processor)?
You can run 68K apps now on a faster PPC system with little added costs (G3-400 on a Powermac 7500/8500 will run 68K OS 7.5.x+ apps just fine). Amiga and Atari people spend big bucks on slow PPC and fast 68060 processors because their platform died and they have no other choice (outside of emulation) and even they only buy NEW designs by the handfull.
If motorola got bored they could take the old 68040 design, add 2MB of cache to the die and shrink it with new production methods and probably get a 68040/800Mhz that runs without a heatsink. Thing is developers have moved on and few would buy the new chip.
If motorola got bored they could take the old 68040 design, add 2MB of cache to the die and shrink it with new production methods and probably get a 68040/800Mhz that runs without a heatsink. Thing is developers have moved on and few would buy the new chip.
Not gonna happen. The Amiga 060 cards only work with apps that go through the 68060.library that contains the patches required. It was relatively east on the Amiga. I challenge anyone to build a similar library for the Mac that loads at ROM level (which would probably be required). Daystar did it basck in the day with the Turbo040 and Turbo601 cards but I doubt anyone has the documentation, facilities or motivation to do it now.
IMHO the old Mac OS isn't worth building 060 cards for ( many others will disagree, and disagree I will, happily!), 8.1 runs well enough on a 040 for me. That said I *own* an Amiga 060 machine (an A4000 with a Cyberstorm060 Mk1 and 128MB RAM) so I can get an 060 fix anytime I need one.
As I stated above, and in the Amiga vs. Mac thread however one compelling force was the flexibility and expandability of the Amiga platform. Commodore developed the ability to work CPU patches into the system in OS 3.x to allow the 68040 to work with 68030 software reliably on the Amiga Workbench. That meant the 060 was very easy for experience Amiga techs to work into the OS.
If you guys were really serious you would want a Coldfire 68k Mac. It'd give a 601 or mid-range 603e a serious run for its money. Amiga 060s will easily play a 128kbps MP3 with cycles to spare, so I'd imagine a Coldfire machine would be a sight faster still!
Realistically, if you want a faster Classic Mac, Unknown_K is right - use a PPC. A small number of apps don't run well on PPC but they are a really small number, which you could probably run on an old 030 Mac without any fuss anyway. One reason I have done little with the 68k MAcs in latter years is they are a backwater - stuff pretty much dried up for them in the mid-1990s and they have never seen anything exciting since.
IMHO the old Mac OS isn't worth building 060 cards for ( many others will disagree, and disagree I will, happily!), 8.1 runs well enough on a 040 for me. That said I *own* an Amiga 060 machine (an A4000 with a Cyberstorm060 Mk1 and 128MB RAM) so I can get an 060 fix anytime I need one.
At least in the Amiga arena (where I have lots of experience), it created some really great machines at the time, but they are all slow compared to modern machines. PowerPC has never been properly implemented on the Classic Amiga anyway - at best PPC cards use PPCs as co-processors, and most PPC apps are frankly worse than the 68k versions.
As I stated above, and in the Amiga vs. Mac thread however one compelling force was the flexibility and expandability of the Amiga platform. Commodore developed the ability to work CPU patches into the system in OS 3.x to allow the 68040 to work with 68030 software reliably on the Amiga Workbench. That meant the 060 was very easy for experience Amiga techs to work into the OS.
Freescale (who are the present owners of all Motorola's CPU technology that they spun off in 2004) produce a chip called Coldfire, which is a 68k compatible chip that runs at 360MHz or more. Several projects have worked on bringing that to Amiga, but so far non have produced salable item based on Coldfire, partly because of the hurdles interfacing the main system CPU running at 360MHz with a 7MHz chipset, and partly because of significant differences in the code base.
If you guys were really serious you would want a Coldfire 68k Mac. It'd give a 601 or mid-range 603e a serious run for its money. Amiga 060s will easily play a 128kbps MP3 with cycles to spare, so I'd imagine a Coldfire machine would be a sight faster still!
Realistically, if you want a faster Classic Mac, Unknown_K is right - use a PPC. A small number of apps don't run well on PPC but they are a really small number, which you could probably run on an old 030 Mac without any fuss anyway. One reason I have done little with the 68k MAcs in latter years is they are a backwater - stuff pretty much dried up for them in the mid-1990s and they have never seen anything exciting since.
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.
Hah. I forgot the conclusion.
So if this all works we basically end up with a 300 MHz CPU connected to DDR memory running at close to the same speed as the CPU (latency is high, but bursts are good) and USB and ethernet ports close enough to the CPU to run at full speed. The Mac motherboard becomes a peripheral interface, which happens to provide the ROM code as well.
Even with the instructions which will throw execptions I bet this would run at least four times faster than a IIfx and maybe better.
Video performance would still be abysmal though.
So if this all works we basically end up with a 300 MHz CPU connected to DDR memory running at close to the same speed as the CPU (latency is high, but bursts are good) and USB and ethernet ports close enough to the CPU to run at full speed. The Mac motherboard becomes a peripheral interface, which happens to provide the ROM code as well.
Even with the instructions which will throw execptions I bet this would run at least four times faster than a IIfx and maybe better.
Video performance would still be abysmal though.
I don't understand the obsession people have with the coldfire.. it's just incompatible enough to screw everything up and offers little to no benefits as nobody will develop for it.
trag - I know you've done a few nice projects, but an accelerator is a big job. Maybe start with something simpler.. like a nubus USB board perhaps? A flash SIMM board that could hold all 3 iifx/iisi/se30 roms would be welcome development too.
trag - I know you've done a few nice projects, but an accelerator is a big job. Maybe start with something simpler.. like a nubus USB board perhaps? A flash SIMM board that could hold all 3 iifx/iisi/se30 roms would be welcome development too.
You're right. There are 8 and 16 bit PICs. They are fast enough to emulate a slow 32 bit device (eg USB 1.1 client) but not a *fast"* multi function computer.
MAME is an arcade game emulator which runs on many platforms. Install MAME; find the ROM image for the arcade game; play. The emulator includes libraries or modules that translate processor instructions from the arcade game to the host machine. If you can find a way to use the libraries, you don't need to reinvent. Enthusiasts have done that already to emulate computers (see MESS).
Every single other thing on the machine, including the ROM, is expecting a PPC, not a 68k or a Coldfire. Won't work, IMHO.
I could maybe see it working as a PCI card with a set of INITs that patch the ROM to trap all 68k code and redirect it to the Coldfire with some re-interpretation along the way for incompatible opcodes. Maybe.
But then one really does have to wonder why you'd bother when it would be a whoooole load easier and cheaper to stick a 1 GHz G4 in there and run 68k apps on it.
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.
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
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.
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?
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!
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.
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
If Ataris had meaningful preemptive multitasking, then a ShapeShifter / Basilisk type emulator / virtualizer would have already been made. There were ways to run MacOS on Ataris, but as far as I know they all required MacOS to entirely take over the whole OS, so they wouldn't work on the Coldfire board without lots of modification. But the Atari Coldfire-on-a-PCI board is an open project, so all documentation is available, so it's possible for someone with money and time.
Regarding benchmarks, emulators with JIT caching can run noticeably faster than a real m68060, but if you want or need to emulate an MMU, you can't use JIT, so the speed of a very fast x86 is not necessarily faster than a real m68060. I've heard from NetBSD Amiga developers with access to m68060 systems that some things are faster and some are slower - UAE isn't faster overall, but of course a 2+ GHz AMD or Intel system is much easier to find or buy than an Amiga with an m68060.
Emulating an MMU is a non-issue for MacOS so it's perfectly fair to note that even a fairly wimpy PC will run it far, far faster (on the order of hundreds of time faster, for certain tasks) than any Coldfire or 68060 box will be able to. If an MMU were actually vital for running Atari, Amiga, *or* MacOS software then I'm sure someone would be able to get JIT+MMU working together. It's just not a burning issue for anyone not running Linux or BSD, which is the vast majority of the users of these emulators.
(After all, if you want to run Linux or BSD why not just run it on the host? There's nothing particularly special about NetBSD on a Mac or Amiga other than the fact it runs on a Mac or Amiga.)
As an aside, I actually did stumble across a foreign site which had a collection of benchmarks comparing various "real" Atari computers to ARAnyM, and one of the things listed was a Coldfire demo board. It's interesting to note that the 200Mhz Coldfire barely beat the 100Mhz 68060. So... more reason to regard the whole enterprise as pointless?
THE THREAD LIVES!
Just out of curiosity, as a means of settling whether this is even a worthy idea... what was the point in which 68k emulation on PPC overtook 68k code running natively on a 68040?
Ignore for a moment the existance of FAT binaries or recompiling for PPC.
I know the 601s were pretty crap at this (it *is* emulated), but were the 603s or 604s able to match the speed of a real 68040?
Given that Apple wrote a pretty decent emulator, I suspect a 68060, or even Coldfire, would fill only a VERY small need. Thus, the first person that responded to this thread (aeons ago) probably had the most beautifully simplistic answer. Which is to get a cheap G3 or possibly even a lesser PPC.
Just out of curiosity, as a means of settling whether this is even a worthy idea... what was the point in which 68k emulation on PPC overtook 68k code running natively on a 68040?
Ignore for a moment the existance of FAT binaries or recompiling for PPC.
I know the 601s were pretty crap at this (it *is* emulated), but were the 603s or 604s able to match the speed of a real 68040?
Given that Apple wrote a pretty decent emulator, I suspect a 68060, or even Coldfire, would fill only a VERY small need. Thus, the first person that responded to this thread (aeons ago) probably had the most beautifully simplistic answer. Which is to get a cheap G3 or possibly even a lesser PPC.
Right, but you can bet that bird will try to rise from the dead at some point. There have already been several 68060 topics on 68kmla. It would be nice to have a full accounting of why and WHEN it doesn't make much sense.
BTW, with a certain amount of amusement, I note that the later Amiga accelerators used PPC 601 and 603 chips. Kinda makes one wonder.
BTW, with a certain amount of amusement, I note that the later Amiga accelerators used PPC 601 and 603 chips. Kinda makes one wonder.
The original 68K emulator in PPC Mac ROMs was an interpreting emulator and even in a loop, it would reinterpret the instructions over and over. This cost the emulator a lot of performance.
Connectix wrote a caching interpreter which would keep chunks of the interpreted code and reuse them as needed, thus vastly speeding up loop structures and other repetitive chunks of code.
I think that with Connectix's Speed Doubler installed, an 80MHz PPC601 was pretty comparable to the fastest 68040.
In the PCI PowerMacs, Apple copied (or licensed?) Connectix's code and used that as the built-in 68K interpreter so a huge performance boost was seen beyond the improvements brought with faster CPUs, and more efficient memory subsystems.
If you're running a NuBus PPC or a PPC upgrade in a 68K machine, get Speed Doubler and install it. If you're using a PCI PowerMac there's little need for Speed Doubler (though some of the disk management/copy enhancements are nice).
What trag said, plus the more significant speed differences were attributable to the larger caches in the newer PowerPC chips. One interesting tidbit is that there were some low end machines with the 603 (without the e at the end) which were complete dogs running m68k code because the m68k emulator code couldn't all fit in the 603's caches. The 603e was quickly released to address that issue.
So, in a nutshell, there is really no practical reason for such an "upgrade." SpeedDoubler sufficiently boosts 68k emulation on 601s and 603s, and the 603e acheives parity with no additional software.
Thus, a 68060 or Coldfire Mac would only be for bragging rights and the lulz.
About right?
Thus, a 68060 or Coldfire Mac would only be for bragging rights and the lulz.
About right?
From what I've read on this thread, John, I believe that's the message the majority of the members are trying to send out. If the cost of the upgrade were not as expensive as, say, picking up a couple of G3 units, then perhaps there would be a greater demand for this accelerator card. One also has to look at the availability of the card as well.
Not all mods are meant to be.
Nope. You're kind of missing the point. But that's okay. It's well buried and partly composted.
Sure, you can get a newer faster PPC based machine. But it won't run the earlier OS and software.
The point behind speculating about a 68K upgrade is to take older machines, and the OS and software support those older machines provide, and make it much much faster. Preferably in the old form factor as well.
Is there much practical need for that? Probably not. But some folks are attached to the looks of older machines and some folks prefer the older software or just like to run it from time to time, and in many cases it would be nice if that older software on those old adorable machines would run much much faster.
You are presumably referring to having a ridiculously fast System 6 machine. Because I was under the impression most PPCs before the G3 will run System 7 just fine (and do so faster).
I suppose it would be neat, but I just don't see anyone investing the time or money to actually do it.
I suppose it would be neat, but I just don't see anyone investing the time or money to actually do it.