New Project: Prodigy 040/060 Card

[Oliver_A]

Hello Mac community,

I joined MLA68K 2 days ago, because I recently acquired a Macintosh LC475, which I have started to like a lot due to its compact size, and actually very good performance.

Most people know me in the Amiga community, where I have started several hardware designs ranging from sound card, graphics card and cpu accelerators.

So by using Shapeshifter since almost 30 years, one could call me a "passive Mac user", since I have gotten to really like the Mac OS itself, but also the vast choice of native 68k software I could suddenly use on my Amiga at great speed.

I have recently stumbled across the great efforts made by @zigzagjoe to get a 68060 CPU running in a real MAC, something that Amiga users have been doing since a long time, and sadly never passed back to the MAC community due to the emergence of PPC-based machines.

The most prominent headline of this effort, which actually sparked my interest here, was "The Fastest (68k) Macintosh Might Not Be An Amiga Anymore". So I asked myself: well, why not give something back, and make this a reality. Because, at least that's my perspective, what unites both our communities is the love and passion for the Motorola 68k CPU architecture, which, still to this day, is amongst the best, if not the best, CISC ISA ever been created.


(Some people might even claim it should never have been superseded by PPC..... )

As a lucky coincidence, I have recently started to make my own Amiga 68060-based accelerator design a while back, which I am waiting now for the very first Revision 0 prototype PCB. Lucky, because I can actually re-use most of my design for a classic m68k MAC accelerator. Therefore, as my introduction to this community, I would proudly like to annouce the:

Prodigy 040/060 Card

So what is this card? In short, it is a CPU card for classic 68k-based MACs, which plugs directly into the 68040 CPU Socket.

Here is a rendering of the first prototype:



The card will have the following features:

• Support for 68040 and 68060 CPUs, selectable by jumper setting.
• CPU clock rate: up to 50MHz (68040) and, yes, 100MHz! (68060)
• SDRAM memory controller, which runs at either 1x or 2x bus speed (to minimize first access penalty) - meaning up to 100MHz memory clock
• 128MB on-board SDRAM
• Flexible bus interface: always full speed to SDRAM, selectable 1/2 or 1/4 bus speed to MAC mainboard (no need to overclock SCSI bus in order to run 100MHz!)
• 2 MB Flash Rom, for startup code, 68060 compatibility software layer and patching of MAC OS
• RECOVERY jumper: if set, system starts using the mainboard ram and rom, enabling you to flash the rom via software
• A prominent Amiga feature: MAPROM - copy the MacOS Rom to superfast SDRAM on start-up, and use memory protection/remapping to execute it as if it were a real ROM - withou the need of using the MMU
• Configuration settings can be flashed in FPGA
• FPGA can be software upgraded on the MAC
• Designed to (hopefully) fit in all 68k-based MACs, first prototype will be developed on an LC475

This card will bring significant acceleration even if you keep using your on-board 68040 CPU due to its superior memory interface.

So, what do you think? ;-)

What I would like to ask you is, whether you think this product might be useful to you, and if yes, since I am basically "an Amiga guy", I would appreciate if you could guide me a bit on how these features could be implemented the best way in software to integrate well with MacOS.

So for example, I can design a memory controller very easily, but I have currently no idea how I can make this memory available to MAC OS in the most system friendly way. On Amiga, this is actually quite easy, since the Amiga implements a card resource management system called "Autoconfig", making it very easy to make the OS recognize additional memory and I/O resources (much like PCI).

From what I have gathered so far, the way to go here would be to patch the MacOS Rom to utilize the new resources without getting into conflict with the on-board hardware.

In any case, I shall be looking forward to your feedback and help!

Best regards,

Oliver Achten

 

[Durosity]

This is pretty damn crazy exciting!

 

[eharmon]

Hello Mac community,

I joined MLA68K 2 days ago, because I recently acquired a Macintosh LC475, which I have started to like a lot due to its compact size, and actually very good performance.

Most people know me in the Amiga community, where I have started several hardware designs ranging from sound card, graphics card and cpu accelerators.

So by using Shapeshifter since almost 30 years, one could call me a "passive Mac user", since I have gotten to really like the Mac OS itself, but also the vast choice of native 68k software I could suddenly use on my Amiga at great speed.

I have recently stumbled across the great efforts made by @zigzagjoe to get a 68060 CPU running in a real MAC, something that Amiga users have been doing since a long time, and sadly never passed back to the MAC community due to the emergence of PPC-based machines.

The most prominent headline of this effort, which actually sparked my interest here, was "The Fastest (68k) Macintosh Might Not Be An Amiga Anymore". So I asked myself: well, why not give something back, and make this a reality. Because, at least that's my perspective, what unites both our communities is the love and passion for the Motorola 68k CPU architecture, which, still to this day, is amongst the best, if not the best, CISC ISA ever been created.


(Some people might even claim it should never have been superseded by PPC..... )

As a lucky coincidence, I have recently started to make my own Amiga 68060-based accelerator design a while back, which I am waiting now for the very first Revision 0 prototype PCB. Lucky, because I can actually re-use most of my design for a classic m68k MAC accelerator. Therefore, as my introduction to this community, I would proudly like to annouce the:

Prodigy 040/060 Card

So what is this card? In short, it is a CPU card for classic 68k-based MACs, which plugs directly into the 68040 CPU Socket.

Here is a rendering of the first prototype:

View attachment 93907

The card will have the following features:

• Support for 68040 and 68060 CPUs, selectable by jumper setting.
• CPU clock rate: up to 50MHz (68040) and, yes, 100MHz! (68060)
• SDRAM memory controller, which runs at either 1x or 2x bus speed (to minimize first access penalty) - meaning up to 100MHz memory clock
• 128MB on-board SDRAM
• Flexible bus interface: always full speed to SDRAM, selectable 1/2 or 1/4 bus speed to MAC mainboard (no need to overclock SCSI bus in order to run 100MHz!)
• 2 MB Flash Rom, for startup code, 68060 compatibility software layer and patching of MAC OS
• RECOVERY jumper: if set, system starts using the mainboard ram and rom, enabling you to flash the rom via software
• A prominent Amiga feature: MAPROM - copy the MacOS Rom to superfast SDRAM on start-up, and use memory protection/remapping to execute it as if it were a real ROM - withou the need of using the MMU
• Configuration settings can be flashed in FPGA
• FPGA can be software upgraded on the MAC
• Designed to (hopefully) fit in all 68k-based MACs, first prototype will be developed on an LC475

This card will bring significant acceleration even if you keep using your on-board 68040 CPU due to its superior memory interface.

So, what do you think? ;-)

What I would like to ask you is, whether you think this product might be useful to you, and if yes, since I am basically "an Amiga guy", I would appreciate if you could guide me a bit on how these features could be implemented the best way in software to integrate well with MacOS.

So for example, I can design a memory controller very easily, but I have currently no idea how I can make this memory available to MAC OS in the most system friendly way. On Amiga, this is actually quite easy, since the Amiga implements a card resource management system called "Autoconfig", making it very easy to make the OS recognize additional memory and I/O resources (much like PCI).

From what I have gathered so far, the way to go here would be to patch the MacOS Rom to utilize the new resources without getting into conflict with the on-board hardware.

In any case, I shall be looking forward to your feedback and help!

Best regards,

Oliver Achten

Great to have more hardware developers in the community!

Overall I think you'll find the Mac ROM is much, much less auto-configurable (more like Kickstart 1.x than 2.x+). Using your memory example:

• ROMs are "universal", but only in theory. Despite many machines shipping with ROM SIMM slots, upgrades were never provided and compatibility was never really ensured. So while the ROM itself supports earlier machines, it was never debugged for regressions. As a result, some ROMs can be used across machines (IIsi -> SE/30, LC 475 -> Wombat-based Quadra), but not always, and there's often quirks (LC 475 ROMs have the wrong memory timing for instance).
• Most machines have different ROMs (though there's some overlap), meaning offsets are different per machine.
• The ROMs do autodetect the logic board type using resistor matrices, etc, and configure themselves accordingly.
• Combining this, let's look at memory sizing, which I happened to be debugging yesterday:
  • The ROM detects what machine it's running on.
  • It branches to the correct memory sizing routine for the memory controller corresponding to that machine.
  • It builds a table of memory chunks in memory.
  • It returns a pointer to that table for configuration of the rest of the system.

So this might not be too bad in theory, you can patch in your own memory controller routine and jump to it to add those address ranges. But there's a few challenges to think about:

• You need to choose a single ROM and set of machines to support, or build a table of patches per ROM.
• It's possible the OS overpatches these routines itself (unlikely for memory sizing, but common for other routines) which you need to avoid or re-patch.
• It's possible other parts of the ROM or OS size memory on their own; since it wasn't meant to be extended, these quirks may not have been discovered yet by the community.

Despite this, it's definitely doable. The Turbo040 does a large amount of patches for a large amount of ROMs to enable 040 compatibility on 030 machines, for instance. Overall I'd look at targeting the LC 475 ROM, as it has the widest '040 machine support (with a few fix-ups).

For mapping ROM to RAM, here's a relevant discussion on a software utility (w/ benchmarks and more): https://68kmla.org/bb/threads/rom-in-ram-for-quadra-performance-boost.46536/

Were you planning for software configurable clock speeds?

As a real challenge, A/UX support would be very interesting, since it never ran beyond 68k. I'm not sure how it handles 040 compatibility (It mostly doesn't use the ROM, so I'm not sure where its support packages come from -- it might depend on the normal OS boot gluing everything together).

 

[ObeyDaleks]

This sounds great! I have a few Amigas with (your???) accelerators, including the ACA500, ACA1234 (with an FPU upgrade), as well as the AGA MK3.

As the previous poster, I'm also curious how this will work across different models. AFAIK, there's a lot of proprietary trickery that was implemented on the old-school accelerators. Also, there are many different board layouts and while some accelerators worked on multiple "sibling" models, they had to use a variety of adapters to make it work.

Oh, one other thought. I'm wondering how "useful" (LOL) a 100MHz 68060 would be on a Mac. There just wasn't a lot of 68k Mac software written that would need that much speed. Later software was written for the PPC, so there's sort of a cut-off to where speed gains just outpace any software ever written for the platform. It's quite different than the Amiga scene where people are creating demos to this day.

Regardless, it's quite an exciting prospect and I'm sure there would be many people interested in the product.

Following this with great interest.

 

[eharmon]

Oh, one other thought. I'm wondering how "useful" (LOL) a 100MHz 68060 would be on a Mac. There just wasn't a lot of 68k Mac software written that would need that much speed. Later software was written for the PPC, so there's sort of a cut-off to where speed gains just outpace any software ever written for the platform. It's quite different than the Amiga scene where people are creating demos to this day.

You'd be surprised. So much was still emulated on PowerPC, and it was "fast enough" that applications took awhile to transition.

In the same vein, obviously running System 7 on a New World G4 will smoke any '060 anyway, but that's no fun (well it is fun, but differently fun).

That said, I think slow graphics and anemic disk performance will indeed drag down the overall "experience" to make it less impressive than on an Amiga. With graphics running at standard clocks on the 040 bus (or NuBus) and 5MB/s SCSI, I suspect things like Finder won't feel a lot faster.

But any period productivity app should fly, I would think.

 

[Oliver_A]

Hi everyone,

Overall I think you'll find the Mac ROM is much, much less auto-configurable (more like Kickstart 1.x than 2.x+). Using your memory example:

that's what I sort of expected after doing some initial research. I mean, coming originally from the C64, I'm not that unfamiliar in getting "my hands dirty" in delving into low-level bootstrap code, which sort of has an underlying structure, but was never documented or defined in a way to provide standardised interfaces. But I suppose, that's also the fun and challenge here. ;-)

So this might not be too bad in theory, you can patch in your own memory controller routine and jump to it to add those address ranges. But there's a few challenges to think about:

• You need to choose a single ROM and set of machines to support, or build a table of patches per ROM.
• It's possible the OS overpatches these routines itself (unlikely for memory sizing, but common for other routines) which you need to avoid or re-patch.
• It's possible other parts of the ROM or OS size memory on their own; since it wasn't meant to be extended, these quirks may not have been discovered yet by the community.

I was actually thinking about applying patches to the ROM after my initial boot code has copied it to RAM. With the consequence that, for all known and documented ROMs, there are tables which contain the location offsets for each routine that needs to be patched.

The memory controller might perhaps not be the biggest challenge, as I expect that this can be resolved by replacing the memory init routine altogether, but adding the support code for the 68060, including the emulation layer for the unsupported opcodes.

Can you guys recommend me any source on how to get an overview, does a so-called "ROM Kernel Reference" exist for the Macintosh?

For mapping ROM to RAM, here's a relevant discussion on a software utility (w/ benchmarks and more): https://68kmla.org/bb/threads/rom-in-ram-for-quadra-performance-boost.46536/

Thanks, I'll have a look into this. My plan is to implement the memory remapper in the FPGA, so that the Ram-based Rom layer sits "on-top" of the original physical address space.
https://68kmla.org/bb/threads/rom-in-ram-for-quadra-performance-boost.46536/

Were you planning for software configurable clock speeds?

My plan is to go with the BUS clock provided by the motherboard, and use the PLL in the FPGA to generate the Processor Clock and memory clock.

So depending on the CPU, for example, I can have:

25MHz bus clock (provided by mainboard)
50MHz CPU clock (generated by PLL) -> can be used as PCLK and /or BCLK for the on-board memory controller
100MHz memory clock (generated by PLL) -> can be used as PCLK and / or BCLK (060) for the on-board memory controller.

With the clock obviously changing, as per setting of the mainboard PLL.

The initial boot rom code will detect the CPU type, and adjust the settings according to the values provided in the FPGA flash rom.

As a real challenge, A/UX support would be very interesting, since it never ran beyond 68k. I'm not sure how it handles 040 compatibility (It mostly doesn't use the ROM, so I'm not sure where its support packages come from -- it might depend on the normal OS boot gluing everything together).

You mean UNIX? Yes, that definetely would be a great challenge, perhaps even providing the boot loader inside the ROM of the card.

Thanks for your warm welcome and help!

 

[Phipli]

Oh, one other thought. I'm wondering how "useful" (LOL) a 100MHz 68060 would be on a Mac. There just wasn't a lot of 68k Mac software written that would need that much speed. Later software was written for the PPC, so there's sort of a cut-off to where speed gains just outpace any software ever written for the platform. It's quite different than the Amiga scene where people are creating demos to this day.

It would enable us to write more software - newer audio codecs, SSH and SSL working better, games like Marathon, Dark Forces, Doom and Quake, that there are 68k version of, would run better...

We're not limited to existing software.

Even then, Photoshop, Illustrator, ProTools... Premiere... Infini-D Etc... All benefit from better drawing / rendering times.

 

[Phipli]

That said, I think slow graphics and anemic disk performance will indeed drag down the overall "experience" to make it less impressive than on an Amiga. With graphics running at standard clocks on the 040 bus (or NuBus) and 5MB/s SCSI, I suspect things like Finder won't feel a lot faster.

Nothing really stopping us aiming for a 50MHz bus on the LC 475

 

[Phipli]

The memory controller might perhaps not be the biggest challenge, as I expect that this can be resolved by replacing the memory init routine altogether, but adding the support code for the 68060, including the emulation layer for the unsupported opcodes.

Just to keep in mind, the stock Memory Controller will likely still need some initialisation as it is also an integral part of other systems like graphics. (It generates and controls video clocks like pixel clock, hsync, vsync etc).

Can you guys recommend me any source on how to get an overview, does a so-called "ROM Kernel Reference" exist for the Macintosh?

If you aren't aware of this, this is leaked ROM source for the 840av ROM. It is from a similar era to the 475. There are also tools the community has made for the analysis of ROM binaries... But I'm not familiar with them so will leave others to discuss.

GitHub - elliotnunn/supermario

Contribute to elliotnunn/supermario development by creating an account on GitHub.

github.com

With the clock obviously changing, as per setting of the mainboard PLL.

I assume you're aware, the bus speed can be set dynamically on the LC 475. This is super unusual and the only 68k desktop Mac that we are aware it is possible for. On a stock machine they're mostly stable up to 33MHz at which point you have to move a resistor to divide the clock to the SCSI chip by two (some people have trouble even at 33MHz), then they boost to about 40 to 43MHz before they reach the limit of a MC88920 PLL... If you swap in an MC88916DW80, the CPU grade becomes the limit up to about 52MHz. I haven't invested the cause of that limit, not sure if it is CPU, ROM, RAM, VRAM or chipset. Or even board.