• Hello, Guest! Welcome back, and be sure to check out this post for more info about the recent service interruption and migration.

New CPU Accelerator options for 68K Macs?

Phazmatis

Member
There's on-board RAM. The bus is going to be the bottle neck
This might be problematic for Macs, since the video circuitry in the BBU expects to find the framebuffer in the DRAM chips, not on the other side of the BBU, in the CPU socket. Maybe it'll need special pass-through RAM regions.

 

Frobozz

Active member
Huh. This is actually kind of a nutso project (in a good sense). One thing that's interesting, is that the CPU is configurable via software apparently, including the ability to control the speed, control whether the onboard 32 byte RAM is available to the host computer, etc.  Take a look at the developer's blogs, especially the one about "Amiga-ness". 

https://www.buffee.ca/home/

If your existing 68000 can do it, then Buffee can do it. Just some 2000 times faster. But I did say that Buffee is not “Amiga specific” and that we cannot support things like Autoconfig, didn’t I? Well, I meant that the memory and peripherals INTERNAL TO BUFFEE cannot be automatically enabled and used by AmigaOS. Or EmuTOS. Or Mac System. Because they all do this differently and they all expect memory and peripherals in different locations.

What this means is that from a default state, Buffee will operate in “ultra compatible mode” and will require that the user or retailer preconfigure Buffee before hand. This includes such things as

  • Enable CPU local RAM in 32-bit memory (disabled by default)
  • Set the location and amount of this RAM
  • Enable data and/or instruction caches for any memory block (by default only the instruction cache is enabled in 24-bit memory, all caches are enabled for 32-bit memory)
  • Enable PJIT instruction cache for any memory block (by default, PJIT ICache is enabled only on 32-bit memory)
  • Set the CPU base clock PLLs (presets for 275 to 1000 MHz)
  • Set the CPU clock divider (from 1 to 1/256th of the base clock)
  • Select between 68000 or 68030 instruction set (68000 default)
  • Select between No FPU, 68882, 68040 or fast 68040 FPU modes (No FPU is default)
  • Enable 68K MMU emulation
  • Preload and remap up to a 2MB ROM image (with or without 68K MMU enabled)

None of these settings need to be set by a CLI utility on each boot (though they can be); these can be saved into the EEPROM memory which will be retained while powered off 


I'm probably just projecting wishes here, but I'd be really happy with something I could put into a Mac Plus, tune it to say 50mhz, use the existing Gemini extensions/control panels, and not have spent $1500 on that 030 Mac Plus on eBay. 

 

Renegade

Well-known member
Not sure how many people have Macs with socketed m68000, but there's this:

https://github.com/captain-amygdala/pistorm

Since it can run on a pure m68000 machine, it should be easily adaptable to use in a Mac.

I'm sure it's just a matter of time before it, or projects like it, are extended to 32 bit CPUs for m68020 / m68030 / m68040 sockets.


Posts about the PiStorm experiments with Macs have been lost in The Great 68krash of 2021...
@AlexCL posted about his experiment here IIRC.

Here's what Claude Schwarz posted on twitter about Alex's experiments :
 

moving2

Member
Hi Frobozz,

there is a great interest and it's being done, thanks to people reverse engineering Mac-specific accelerators - see threads on here by @Bolle and (potentially?) @maceffects.

I have FPGA experience and I'm just now digging in to the "Designing Cards and Drivers for the Macintosh Family 3rd ed" and "Guide to MAcintosh Family Hardware 2nd ed", with the eventual goal of developing an FPGA-based CPU accelerator for the Mac IIfx PDS slot. Some questions:

1. Can someone point me to the existing work of @Bolle and @maceffects in reverse engineering existing accelerators? I'm curious how far this work has gone, and if anyone has managed to produce a working prototype?

2. Are there any other references I should look at in the early stages of designing a PDS CPU accelerator?

3. Are there any FPGA based proto-boards available with Nubus/PDS connectors on them ala those I've seen on ebay for the Apple II series?
 
Last edited:

trag

Well-known member
3. Are there any FPGA based proto-boards available with Nubus/PDS connectors on them ala those I've seen on ebay for the Apple II series?

I think you're going to have to roll your own.

Even if there were FPGA proto-boards available back when they were relevant, they would use FPGAs which are so outdated you might not even be able to find development environments for them. And no one is going to produce such a proto-board now, for such old machines -- except this community.

The NuBus/PDS connectors are still easily available. Digikey and others still stock the mini-DIN connections. Heck, I probably have a few hundred in my attic.

And printed circuit boards are relatively cheap now days.

The biggest obstacle is going to be laying out the board, and getting the FPGA soldered to it successfully. If you use a QFP that's not as difficult. If you use a BGA package (typically more IO pins) it gets harder -- though there are folks in the hobbyist community who can do that too. Or if you have the money, you can pay to have it done professionally.

Also, deciding what you want on the board.

I have considered designing one for the SE/30 PDS several times, but there's a giant backlog of other projects in the way.

When I think about it, I lean towards getting an existing development board that has features I want, such as on-board memory, blinken-lights, perhaps VGA out, maybe ethernet, and copying that development board design, while bringing out additional I/O to fully connect to the SE/30 PDS.

Lights, because at the beginning of development it's nice to try the equivalent of "Hello world" and just see if you can get one I/O to go low or high.
 

cheesestraws

Well-known member
@moving2:

I believe both @maceffects and @bdurbrow have projects in-flight involving designing repurposable FPGA-based PDS cards for various machines. You should probably compare notes with them.

Personally I have reservations about this approach, but I wouldn't want that to prevent anyone from trying it, especially since I know little about FPGAs.

You will not find any prototyping boards for PDS cards out there, especially not for IIfx PDS. You're going to have to come up with your own. I agree with @trag that starting from an existing development board layout at least would probably be a better plan that starting from a PDS card design.

As far as I know, the reproduction accelerators that @Bolle has made use the original bitstreams with the original FPGAs from the period. Nobody around has the tools or experience to convert those back into any kind of high-level representation so they can be transferred to newer FPGAs. Either way, those are mostly dealing, as I understand it, with bus gubbins.

Also, it is probably a good thing to know for you that the (only?) known IIfx PDS accelerator also required the replacement of a PAL on the logic board. I don't know why, but you should probably find out earlier rather than later, in case whatever it is doing is necessary for your case, also.
 

bdurbrow

Well-known member
I don't have any experience building an accelerator per se; but I am (slowly) working on a FPGA project for PDS, NuBus, and PCI slots.

My design involves several Lattice FPGA chips and a Xilinx CPLD (XC9572, or for PCI, XC95144) to do the bus interfacing. The Lattice chips are mounted on a second card which attaches to the main card where the bus logic is.

I don't have any files available yet; and in any case they would only be finished gerbers ready to be sent off to some PCB house like JLC, PCBWay, SEEED, etc. The reason I'm not releasing the original source files is that they are in a format that nobody but me can read; because I use a PCB layout program that I wrote myself and as it's still rather a bit rough around the edged, has not been released for the general public to use.

As for other references, I would read the users manual/datasheets for the 68030; as that's the bus you will be working with. Also, read the IIfx Developer's Note.

My understanding is that basically, either the accelerator card puts the main CPU into a halted state, and then takes over execution; or the INIT that starts the accelerator leaves the main CPU running to handle some tasks, but never returns to the OS, instead starting the accelerator CPU at the return address given on the stack. In either case, accessing the motherboard from the accelerator is basically done via DMA; which is reasonably well documented.

As for replacing a PAL on the IIfx motherboard, while I have no specific knowledge I wouldn't be surprised if the reason that needed doing was to enable the main CPU to be held in a halted state. If you take the second approach above (leave both CPUs running, but on the main processor never return from the INIT), I think you shouldn't have to do that.
 

moving2

Member
I don't have any experience building an accelerator per se; but I am (slowly) working on a FPGA project for PDS, NuBus, and PCI slots.

My design involves several Lattice FPGA chips and a Xilinx CPLD (XC9572, or for PCI, XC95144) to do the bus interfacing. The Lattice chips are mounted on a second card which attaches to the main card where the bus logic is.

I don't have any files available yet; and in any case they would only be finished gerbers ready to be sent off to some PCB house like JLC, PCBWay, SEEED, etc. The reason I'm not releasing the original source files is that they are in a format that nobody but me can read; because I use a PCB layout program that I wrote myself and as it's still rather a bit rough around the edged, has not been released for the general public to use.

As for other references, I would read the users manual/datasheets for the 68030; as that's the bus you will be working with. Also, read the IIfx Developer's Note.

My understanding is that basically, either the accelerator card puts the main CPU into a halted state, and then takes over execution; or the INIT that starts the accelerator leaves the main CPU running to handle some tasks, but never returns to the OS, instead starting the accelerator CPU at the return address given on the stack. In either case, accessing the motherboard from the accelerator is basically done via DMA; which is reasonably well documented.

As for replacing a PAL on the IIfx motherboard, while I have no specific knowledge I wouldn't be surprised if the reason that needed doing was to enable the main CPU to be held in a halted state. If you take the second approach above (leave both CPUs running, but on the main processor never return from the INIT), I think you shouldn't have to do that.
Thanks for the info, @bdurbrow! You mention you don't have source files and they wouldn't be useful, anyway; what I'm really interested in seeing is your FPGA and CPLD source files, which I would assume are written in some type of HDL (or a remote chance at schematic capture). Are you willing to make these available to the community (or at least to me)? Would definitely give me a head start on PDS/Nubus interfacing, and always nice to see an example of a homebrew design, as well.

Also, how are you handling the level shifting required, if any, to interface the FPGA with NuBus?
 

bdurbrow

Well-known member
Verilog sources for the FPGA/CPLD firmware will be available once I've tested them to be sure they actually work. Note that this may be a while!

The level shifting is handled by the XC9572/XC95144 CPLDs - they output 3.3v levels which are TTL compatible, and are 5v tolerant.
 

Trash80toHP_Mini

NIGHT STALKER
I sent my MicroMac Performer and a couple of PowerCache adapters off to @Bolle today. We'll see what he comes up with when he takes a good look at it. I've always though it was the perfect starting point for recreating accelerators, then the master leapfrogged straight to high end SE/30 accelerator projects.

Let's bring the discussion from the Troposphere back down to sea level maybe?

Performer = no cache, no extra RAM via Virtual Memory, just a bog simple 16MHz 68030/25MHZ(?) FPU accelerator that I found in my Plus upgraded Drexel Branded 128K.

Someone took this 128K up thru what's pretty much a stock SE/30 with 4MB of RAM. For the longest time I've been thinking this was the sweet spot for the entry level accelerator it was for Plus/SE/Classic in the day for the modern day.

 
Last edited:

Melkhior

Well-known member
3. Are there any FPGA based proto-boards available with Nubus/PDS connectors on them ala those I've seen on ebay for the Apple II series?
Making one should not be difficult, if you're willing to be a bit too wide. You just design a NuBus carrier board that takes an existing FPGA board as a daughtercard. I've done it for another kind of vintage system despite never having designed a non-trivial PCB before. The benefit is that you can have a quite recent FPGA where everything will fit just fine, only the level shifters are extra (and the I/Os if you want e.g. USB, micro-sd, ...). I'm currently looking into building a NuBus card with the same FPGA board for my Quadra 650, but it's nowhere near being done.
NuBus was well documented by Apple and was an IEEE standard, there's plenty of way to figure out to talk to the bus. Or you can leverage the attempt available on GitHub (that's what I do anyway :) ). PDS might be a bit more specific, but the 68k bus should be well documented.
For such projects, the difficult part is getting the software right - even a dumb framebuffer will need at least a Declaration ROM (and perhaps an embedded driver as well), and you may have to deal with the annoying addressing schemes of old Macs (24-bits vs. 32-bits). That's the bit that worry me and that I need to figure out before ordering yet another batch of expensive PCBs from Seeed.
Also, how are you handling the level shifting required, if any, to interface the FPGA with NuBus?
On my side, 74CB3Ts are hopefully adequate, NuBus is 5V TTL like SBus and the 74CB3Ts work perfectly for SBus.
which I would assume are written in some type of HDL
For SBusFPGA, almost everything is in Migen as it's basically a CPU-less Litex SoC (there's some verilog and SpinalHDL as well) ; it made development and configurability much, much easier than the original VHDL draft code.
However Litex/Migen don't deal well with falling edges (or at all in fact) which is required for NuBus, so currently planning on reusing the XiBus verilog code and add a Litex wrapper with a NuBus-wishbone bridge. Early simulation in Vivado seem OK, now I need to try out with a small ROM configured in Litex.
 

Byrd

Well-known member
Seems the shortage of “chips” worldwide applies to these developments and in turn makes the whole venture not profitable. I’ve heard nothing about the Buffee or PiStorm (keen for the A1200 model) for many months.
 
I have a Mac 128 here that I need to start working on soon, and it kind of gets me wondering if it's possible to build something like an enhanced repro of the MacSnap - a full 4 MB of ram, SCSI, 128K ROM, the works. Basically turning it into a Plus, but reversible and stealthy. Maybe even with a disable function that switches back to motherboard RAM and switches in the old ROMs?

Shouldn't be that expensive to build (the PCB itself would have to be mostly the size of the original motherboard though). Design could draw from a reverse-engineered MacSnap. The Killy clips would have to go though. Putting a chip or three on the 128 motherboard in sockets shouldn't be too much of a sin since you can just put the originals back if you want.

128s (and to a lesser extent 512s) by themselves are more museum pieces and aren't as much fun as Pluses - this would allow them to stay as original as possible (again, fully reversible other than a couple of sockets) and get enjoyed more.
 
I suppose. We do have people reproducing the Amiga 1000 Rejuvenator, and that's pretty much the Amiga equivalent of the MacSnap - gives the launch A1000 the ability to run software that needs an A500, even though A500s are cheaper today.
 

Trash80toHP_Mini

NIGHT STALKER
Not looking into working on anything earlier than the Plus, but I've had plans for reproducing the MicroMac Performer since not long after I found it in my Drexel branded Plus quite some time ago. Started up on the project in earnest four years ago. Hit the back burner for quite some time in between.

As of December, it's been in Germany where @Bolle has read out the formulas in the 5 GALs on the board. He's checking the near complete schematic I'd done with help early on in the project.

It'll be much simplified to support only the Plus on the first go-round. Nothing fancy, no cache or memory shenanigans, just bog simple 16MHz or 32MHz 68030 CPU socket and those for the FPU and its crystal can.

MicroMac_Performer-x01.JPG


I've got design examples for a Killy Klip workalike so figured out the mounting of it I think.
No ETA, could even be another four years. :p
 
Top