Thanks, @zigzagjoe has provided to me the necessary datasheets, so I can have a better overview how the functions are related to each other. I assume that the ROM also defines which video modes are available based on the state of the mode pins of the video connector, correct? (much like a VGA/VESA bios rom?)

Thanks, that’ll give me a great starting point!

As I said, my plan is that I always run the CPU synchronously to the BUS clock of the MAC. In the FPGA itself, I will use the bus clock then to feed its own PLL to generate all subsequent internal clocks.

Which means that, changing the bus clock itself will also change the clock of the CPU and memory. But, on top of that, I can now decide in software whether the CPU PCLK or Memory runs now at 2x, 3x or 4x the bus clock. Accesses to the SDRAM will always use the fastest bus clock option available for the given CPU, while keeping accesses to the mainboard synchronous.

Yeah, sorry for having "hijacked" your thread, but on the other hand, your effort basically gave me now the motivation to do this accelerator design, based on my original effort for the Amiga.

My intention is that everything related to remapping resources during the low-level initialisation is handled by the FPGA. So you can select different physical memory address layouts based on the requirements of the machine, and actual boot process.

Well, that’s why my hardware is designed for both 040 and 060. An 040 already strongly benefits from a high-speed memory interface in "everyday world" application. Its only downside to the 060 is actually, really, mostly the FPU, and the inability to achieve even higher clock speeds, which the last revision of the 060 can handle without issues.

But that’s a general matter of how oneself keeps motivated. As I said, there is a huge overlap in design effort with my Amiga accelerator, so designing the hardware basically comes "for free". As a starting point, the first thing I will do is to plug in a nice L88M 68040 in my accelerator, and going step-by step.

The good thing about using an FPGA for such a design is that I can instantiate a logic analyzer, and basically can trace every single bus access the CPU is doing. So I can specifically trigger on individual accesses to memory and registers, debugging both code and hardware simultaneously.

Thanks, what I am going to start with is, firstly, to get the CPU running, and subsequently bring each function "step by step" to life, firstly on a base of using the rom of my LC475.

The first function I am going to implement is flashing the on-board memory, and then starting to write a small "low level" startup code, which firstly sets-up the accelerator, checks the CPU and machine configuration, copies the ROM to RAM, and then applying patches depending on the makeup of the system, write protecting the mapped ROM, and then kicks-off the cold-/warmstart procedure.

Something doesn’t go well? Then just set the "RECOVERY" jumper on the PCB, which disables most of the accelerator functions, except the access to the Flash-Rom, mapped at a different location so it can be reflashed/written.

And I think this would go very well hand-in hand with your substantial work on the 68060 CPU integration. If you like, I could send you one prototype at some point once I can confirm that the hardware is working on the 040.

The good thing is also that you can completely reprogram the FPGA from the MAC host system - I have implemented the same feature on my Amiga projects.

This is a very good point you are addressing - can I actually snoop DMA transactions from the 68040 socket? On the LC475, it seems that "PRIMETIME" is handling the legacy 68030 bus for the PDS slot and also connects to the 53C96 SCSI chip -> would "PRIMETIME" be responsible to take the 040 "off the bus" and act as a 040 bus master towards MEMC(JR) during DMA?

The problem would be that I very well could catch data being written, but not provide data on my own due to potential bus contention when MEMC(Jr) answers a DMA read request. I still need to understand if and how DMA is used in each MAC model, starting from my own LC475. ;-)

I think it depends on how you treat the assertion of the "_CLKEN" signal in relation to both clock domains. On an FPGA, you can, say, time such kind of logic in a synchronous manner by running the logic at a much higher speed.

I suppose yes, but nevertheless, a 40MHz 040 can push more than 65MB/s using a SDRAM controller design, which minimizes "first access penalty" by running the memory at, say, PCLK speed (80MHz), not BCLK. In this scenario, the 040 actually comes pretty close to the 060 in typical application-related scenarios, and might even surpass it.

The 060 design starts to really pay off in FPU-heavy workloads, and , due to the process technology, running it at actual 100MHz PCLK & BCLK.

Yes, as long as there are no 060 roms, most of the development hast to start on the 040. I could imagine that a small bootloader could run from the roms, which allows to directly load / manipulate memory via a serial interface terminal, so you can have relatively fast "turn-around-cycles".

Usually, ROM-based disk drivers heavily profit from being run from RAM, but maybe that’s already happening here.

WOW! Thanks a lot, for sure I’ll have some reading material now for the next days!

Again, I personally see this as a challenge, and an opportunity to get more "acquainted" with the classic Mac community.