I don't know much about either the Amiga or what they're trying to intend to do, but isn't that going to be bottlenecked by... everything else?
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.There's on-board RAM. The bus is going to be the bottle neck
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
Not sure how many people have Macs with socketed m68000, but there's this:
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.
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?
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.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.
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.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?
On my side, 74CB3Ts are hopefully adequate, NuBus is 5V TTL like SBus and the 74CB3Ts work perfectly for SBus.Also, how are you handling the level shifting required, if any, to interface the FPGA with NuBus?
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.which I would assume are written in some type of HDL