68060 accelerator cards for Mac: Would you be willing?

[SiliconValleyPirate]

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?

 

[trag]

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....

 

[Bunsen]

Interesting thoughts, trag. Here's a few of mine.

/ I know how (in theory) to map out the functions of the GAL chips on an old Daystar accelerator card. / Once we knew all those things, we would (roughly) know how to connect the host Macintosh bus to GLUE logic (probably in an FPGA) / I've done FPGA programming /
So, from my hardware point of view, I think it is doable. It would take a lot of time.

/ when I finish assembling the last few IIfx SIMMs

Ah, so you're that guy. Eeeexcellent.

Coldfire chips / lacking an FPU. So, we either live without an FPU / 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.

I've added a post to the Applefritter thread, with these thoughts:

For reference, here's a block diagram of the 68040:

At the very minimum / "Bus Controller" / duplicate that in the FPGA. / also provide some hardware to streamline the instruction fetch and write-back stages / The *really* hard part of this is going to be emulating the instruction and data cache units. / If you end up running your cache in software that's going to seriously impact the cycles left over for executing code.

So would it be possible to combine the "streamline" fetch/write hardware you mention and the pseudo-cache? I mean what you're talking about is essentially a real cache before the pseudo cache if I'm reading this right.

So emu the cache stages on the FPGA, or use physical RAM (DDR perhaps) with a DMA chip as cache, and emulate only the ALU and FPU in software? [ / or in the FPGA]

There seems to be a lot of documentation available for the 68030; I haven't looked for much on the '040 yet. As the cult machines people want to overdrive (eg SE/30) are often '030 based, maybe this is a better target than the '040.

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.

 

[SiliconValleyPirate]

And then one start comptemplating a total 68K computer upgrade that just uses the host motherboard as an I/O interface....

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.

 

[Bunsen]

By URL editing, I found the '030 block diagram

 

[Bunsen]

/ At this point one / is quickly contemplating a card wtih IDE, USB, video, and 10/100 ethernet all rolled into one. / And then one start comptemplating a total 68K computer upgrade that just uses the host motherboard as an I/O interface....

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:

/ would be to use one of the FPGA/CPU core hybrid chips. (Something like a Xilinx Virtex-II Pro, which has an embedded PowerPC core.)

... 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.

Virtex-4 Multi-Platform FPGA
Up to two 450MHz embedded IBM PowerPC 405

SelectIO™

Ultimate Parallel Connectivity

* 1+ Gbps differential I/O

* 600 Mbps single-ended I/O

* ChipSync™ source-synchronous interface

* 16 I/O banks

RocketIO™

* connect or bridge "anything to anything" with up to 24 serial transceivers, 622 Mbps to 6.5 Gbps, full duplex

Integrated 10/100/1000 Ethernet

That's much more what I was thinking / replicating the non-CPU parts of Apple's 601 upgrade cards in the FPGA, hacked to support the dual 405 CPUs.

You'd be better off using a stand-alone FPGA and a G3/G4 CPU. / The 405 core lacks an FPU, has a somewhat different MMU / and has some instruction/hardware extensions that could all pose difficulties / Duplicating the Apple PPC upgrade card is probably very doable, but figure spending several thousands of dollars / and a lot of reverse engineering /

So... 68k PDS to ZIF socket, anyone?

 

[Bunsen]

the Turbo601 upgrade from Daystar actually had a set of 6100 ROMs on board.

There are G3 upgrades available cheaply for the 6100 ... so what about a Turbo601 clone or adapter with a 6100 PDS slot on it?

 

[Phreakinus]

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...

 

[Bunsen]

And the reasons why were covered earlier here.

 

[t3h]

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.

d) 68060 systems are a small problem because there is no Mac that everused the 68060 and MacOS doesn't know about this processor. Basilisk II

reports the 68060 as being a 68040 to the MacOS and patches some places

where MacOS makes use of certain 68040-specific features such as the

FPU state frame layout or the PTEST instruction. Also, Basilisk II

requires that all of the Motorola support software for the 68060 to

emulate missing FPU and integer instructions and addressing modes is

provided by the host operating system (this also applies to the 68040).

So it's not impossible in software. However, in hardware, good luck

 

[iMac600]

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...

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.

 

[wood_e]

crazy! I need to find a free PC now...

 

[kreats]

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.

 

[Bunsen]

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.

 

[Bunsen]

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

 

[Bunsen]

It occurs to me that my idea of using 68k copros is just making everything more than twice as complicated.

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. / 68060 and 68040 are also too expensive

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.

I'd say we're better off just going all the way back to the emulate the 68030 in an FPGA.

Agreed.

Again, apologies for waking the dead.

 

[Bunsen]

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

 

[johnklos]

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.

 

[Bunsen]

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.

 

[johnklos]

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.

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.