zigzagjoe
Well-known member
Presenting the first time a Macintosh has booted natively on a 68060, to the extent of my knowledge.
Source for the ROM modifications and supporting documentation may be found here.
This has been floated many a time but I believe this is the first time a 68060 has actually booted Mac OS outside of an emulator. @ivelegacy some years ago modified a LC475 ROM in order to boot Linux directly but this came at the expense of being able to boot as a Macintosh. I wanted to replicate something similar; enough to boot NetBSD or Linux natively to play with the 060 as I've no interest in getting an Amiga.
@stepan has an open source design for the 68040 to 68060 socket adapter which can be found here. He also has a nice series of blog posts about building them. It's a clever design but definitely not for the faint of heart to build. This adapter also uses the handy CLKEN function of the 060 to allow running the 68060 at twice bus speed. 66 mhz for my test machine.
To make the software changes possible I designed the ISP-SIMM and ROM blinkensimm in late 2023 as I expected to need the ability to debug and rapidly iterate on ROM changes. The ISP-SIMM provides the capability to push a new ROM image in 10 seconds or so and the interposer serves to give both a visual indication of the CPU state and to allow capture of an execution trace with a logic analyzer. The ROM work I anticipated to be a pain so I've kind of let this project go by the wayside for a few years after proving I had basic code working on the 060.
A Quadra 650 will actually sad chime with a 68060 installed (hits an unimplemented instruction) which shows the ROM is at least trying to do something. Thankfully, apple provided mostly-complete ROM maps which indicate what function lives at what offset so it's possible to get an understanding of what is being accessed in ROM (and follow along in IDA) even as I can't see the exact state of the CPU with a debugger. I finally hooked up that LA a few days ago to begin capturing execution traces such as seen above.
So that does it for the hardware preqrequisites. Here's a quick recap of the major difficulties of using a 68060 in an existing 68040 system.
Motorola cut down some of the lesser used instructions in order to keep the die size under control. However, to remedy this they made available an ISP (Integer Support package) and FPSP (Floating point support package). These packages when installed to the appropriate exception vectors (and other integration tasks) give the 68060 nearly complete instruction set compatibility with 040 & 68882 from a user code perspective. The packages are provided as binary code with source for reference; they have a fixed entry point table and you provide a table of call-outs to your code for functions like reading/writing memory or soft exception handlers. The 040 introduced the concept of FPSP due to the differences between the 040 FPU and the MC68882, and the 060 is an extension to that concept.
So: The 040 FPSP package must be replaced with the new bigger 060 FPSP. The 060 ISP must be added to the ROM and added to the exception tables at appropriate times to handle most of the unimplemented instructions. These packages are happily in the public domain with Linux, NetBSD, and Amiga implementations out there to consult.
A significant miss in the emulated instructions above is the lack of the PTEST instruction. This is used to get the physical address used by hardware which corresponds to a virtual address (used by code); the 060 replaced it with the PLPAR/PLPAW instructions which perform the same function in a much more direct manner. It would be possible to emulate this - the motorola port guide mentions the existance of sample code for this - but for now I have modifications in the ROM-based cache flush routines to use the new instruction instead. It's a pretty rare instruction since you only need it when you need to deal with cache coherency; only the ROM/OS should deal with that instead of any user code.
The bus error stack frame for the moment I just hacked around, it's not properly implemented. As it sits this is just enough to boot an unmodified System 7.1 install on a 68060. There are many known issues that preclude any kind of actual use, it's a happy accident that it gets this far as it is. System 7.5 hangs during boot due to any number of possible causes.
I don't intend to go too much farther and it will probably never reach something that is complete & tested. If you have interest in finishing the job, please by all means go for it!
Just to re-iterate, though: This is in no way something that's practical to use, it is an experimental proof of concept only!!!
Thanks to @stepan for the socket adapter design, @Jockelill for supplying code to map 8MB of ROM space, and @rabbitholecomputing for sending me a couple of scrap 68060s to play with.
FAQs
Is it faster? How much faster?
- Yes. But it is too early to say definitively as implementation is incomplete and suboptimal. Seems to be 2-3x in CPU heavy benchmarks, but let's refrain from counting our chickens before they hatch.
It doesn't work, will you fix it? Will you be doing this for other ROMs?
- No.
Where can I download it? How do I use it?
- Without offense, if you don't know the answer to these questions you probably aren't ready You will at a minimum need a CPU, CPU adapter, Quadra-compatible ROM SIMM, and means to program it.
Will you be building/selling adapters? Where can I get one?
- No. The adapter I used not my design to sell and it's also not fun to build. It's open source, good luck!
Source for the ROM modifications and supporting documentation may be found here.
This has been floated many a time but I believe this is the first time a 68060 has actually booted Mac OS outside of an emulator. @ivelegacy some years ago modified a LC475 ROM in order to boot Linux directly but this came at the expense of being able to boot as a Macintosh. I wanted to replicate something similar; enough to boot NetBSD or Linux natively to play with the 060 as I've no interest in getting an Amiga.
@stepan has an open source design for the 68040 to 68060 socket adapter which can be found here. He also has a nice series of blog posts about building them. It's a clever design but definitely not for the faint of heart to build. This adapter also uses the handy CLKEN function of the 060 to allow running the 68060 at twice bus speed. 66 mhz for my test machine.
To make the software changes possible I designed the ISP-SIMM and ROM blinkensimm in late 2023 as I expected to need the ability to debug and rapidly iterate on ROM changes. The ISP-SIMM provides the capability to push a new ROM image in 10 seconds or so and the interposer serves to give both a visual indication of the CPU state and to allow capture of an execution trace with a logic analyzer. The ROM work I anticipated to be a pain so I've kind of let this project go by the wayside for a few years after proving I had basic code working on the 060.
A Quadra 650 will actually sad chime with a 68060 installed (hits an unimplemented instruction) which shows the ROM is at least trying to do something. Thankfully, apple provided mostly-complete ROM maps which indicate what function lives at what offset so it's possible to get an understanding of what is being accessed in ROM (and follow along in IDA) even as I can't see the exact state of the CPU with a debugger. I finally hooked up that LA a few days ago to begin capturing execution traces such as seen above.
So that does it for the hardware preqrequisites. Here's a quick recap of the major difficulties of using a 68060 in an existing 68040 system.
- 68060 uses 3.3V VCC, not 5V, though the IOs are 5V-tolerant
- 68060 uses IPL lines as configuration straps latched at reset for new features
- 68060 has a reduced integer and floating point instruction set
- Bus error stack frames have been changed significantly
- A whole mess of errata in early 68060 chips
- Lack of secondary supervisor stack pointer
Motorola cut down some of the lesser used instructions in order to keep the die size under control. However, to remedy this they made available an ISP (Integer Support package) and FPSP (Floating point support package). These packages when installed to the appropriate exception vectors (and other integration tasks) give the 68060 nearly complete instruction set compatibility with 040 & 68882 from a user code perspective. The packages are provided as binary code with source for reference; they have a fixed entry point table and you provide a table of call-outs to your code for functions like reading/writing memory or soft exception handlers. The 040 introduced the concept of FPSP due to the differences between the 040 FPU and the MC68882, and the 060 is an extension to that concept.
So: The 040 FPSP package must be replaced with the new bigger 060 FPSP. The 060 ISP must be added to the ROM and added to the exception tables at appropriate times to handle most of the unimplemented instructions. These packages are happily in the public domain with Linux, NetBSD, and Amiga implementations out there to consult.
A significant miss in the emulated instructions above is the lack of the PTEST instruction. This is used to get the physical address used by hardware which corresponds to a virtual address (used by code); the 060 replaced it with the PLPAR/PLPAW instructions which perform the same function in a much more direct manner. It would be possible to emulate this - the motorola port guide mentions the existance of sample code for this - but for now I have modifications in the ROM-based cache flush routines to use the new instruction instead. It's a pretty rare instruction since you only need it when you need to deal with cache coherency; only the ROM/OS should deal with that instead of any user code.
The bus error stack frame for the moment I just hacked around, it's not properly implemented. As it sits this is just enough to boot an unmodified System 7.1 install on a 68060. There are many known issues that preclude any kind of actual use, it's a happy accident that it gets this far as it is. System 7.5 hangs during boot due to any number of possible causes.
I don't intend to go too much farther and it will probably never reach something that is complete & tested. If you have interest in finishing the job, please by all means go for it!
Just to re-iterate, though: This is in no way something that's practical to use, it is an experimental proof of concept only!!!
Thanks to @stepan for the socket adapter design, @Jockelill for supplying code to map 8MB of ROM space, and @rabbitholecomputing for sending me a couple of scrap 68060s to play with.
FAQs
Is it faster? How much faster?
- Yes. But it is too early to say definitively as implementation is incomplete and suboptimal. Seems to be 2-3x in CPU heavy benchmarks, but let's refrain from counting our chickens before they hatch.
It doesn't work, will you fix it? Will you be doing this for other ROMs?
- No.
Where can I download it? How do I use it?
- Without offense, if you don't know the answer to these questions you probably aren't ready
You will at a minimum need a CPU, CPU adapter, Quadra-compatible ROM SIMM, and means to program it.Will you be building/selling adapters? Where can I get one?
- No. The adapter I used not my design to sell and it's also not fun to build. It's open source, good luck!
