Jump to content
bestobothworlds

68060 accelerator cards for Mac: Would you be willing?

Recommended Posts

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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. / plus the fact that it could not compete in speed with the 601 upgrades
Ah. Well, it seemed like a good idea at the time... [:I]]'>

Share this post


Link to post
Share on other sites

Get an Amiga with an '060 upgrade and run a MacOS emulator on it. Then stick it in a IIfx case :D

Share this post


Link to post
Share on other sites

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! :p Would probably be faster than a real 68k, depending on what sort of PC you could find for the project...

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

 

Try using Speed Doubler. It really gives a huge boost to 601's trying to emulate 68k code.

Share this post


Link to post
Share on other sites

Ahem:

 

The Freescale ColdFire is a 68k / for embedded systems / not entirely object code compatible with the 68000. /

 

Newer models of ColdFire are compatible enough with 68k processors that it is now possible to create binary compatible Amiga clones. The Debian project is currently working on making its m68k port compatible with the ColdFires / They can be clocked as high as 300MHz / without overclocking.

 

Then:

 

CK68KLib: 68K Emulation for ColdFire

 

Key features /

 

* Emulation library / to implement 680x0 / instructions and addressing modes missing from the ColdFire architecture. /

* Runs code written in any language, typically with no modifications /

* / specify which 680x0 family processor you wish to emulate /. The utility then generates ColdFire assembly-language source code /

 

CF68KLib is available for download free of charge!

 

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

Share this post


Link to post
Share on other sites
not entirely object code compatible with the 68000.

 

ie It's not a true 68k ...

 

... yet }:)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Why? When it would be even harder* than doing one for a 68k machine, and you can easily stick a G3 or G4 in there.

 

*or perhaps impossible. Remember the Coldfire is kinda-sorta 68k compatible, and not even remotely related to the PPC.

Share this post


Link to post
Share on other sites

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)?

Share this post


Link to post
Share on other sites
Another approach would be to design a 68030 chip into an FPGA.

 

This stuff is way past my abilities but I'm intrigued. There was a similar thread on 'Fritter about emulating a 68000 on a PIC.

 

Is there anything that can be learned about 68000/68030 implementation on an FPGA/PIC from projects like MAME?

Share this post


Link to post
Share on other sites
Why? When it would be even harder* than doing one for a 68k machine, and you can easily stick a G3 or G4 in there.

 

*or perhaps impossible. Remember the Coldfire is kinda-sorta 68k compatible, and not even remotely related to the PPC.

 

Why? So you can run your 68k apps on a machine with a faster bus, more memory, bigger hard drive, better video, etc.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

 

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.

 

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.

 

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.

 

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.

Share this post


Link to post
Share on other sites
Is there anything that can be learned about 68000/68030 implementation on an FPGA/PIC from projects like MAME?

 

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×