-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
Macintosh 68060 Redux
- Thread starter zigzagjoe
- Start date
Well done. I've always said that we'd only get an 060 working in a Mac if someone clever put in the work. You are clever and you have put in the work. Nice one.
One day, it may be possible to get a 68LC060FE inside the PowerBook 500 series. It would take a lot of work, but there's no technical reason it couldn't be done.
It would be very silly though.
Last edited:
Theoretically the resources can be re-ordered without too much difficulty if someone puts in the effort to write a tool to adjust the various list pointers. It’s certainly doable without too much pain. If so I suspect enough resources could be dropped by sacrificing II-series support. There’s quite a bit dead in there in favor of (some) universality.
I would like to see people putting effort into an overclocked 68040 with a few MB of cache that will actually work instead of unobtanium 68060's that never will.
Still cool you can even get it to boot.
I suspect that Daystar canned the 060 because they could not sell it on speed and compatibility while the 601 cards were the future anyway. Daystar wasn't doing that great and having a flood or returns because some software didn't work with an 060 would have buried them.
Still cool you can even get it to boot.
I suspect that Daystar canned the 060 because they could not sell it on speed and compatibility while the 601 cards were the future anyway. Daystar wasn't doing that great and having a flood or returns because some software didn't work with an 060 would have buried them.
@elliotnunn has already done a lot of the hard work. Eg https://github.com/elliotnunn/tbxi
He may have some guidance on the best way to inject the 060FPSP.
How did the Amiga emulators handle it? Did they patch the ROMs, or was it handed externally via Amiga OS?
What’s with the negativity?
You mean like this?
I would agree that I don't see a future in largescale adoption of anything 060 based but the reality is any project I choose to work on is for my own edification first, and happily there's not a requirement for it to be practical or result in a final usable "product". It's educational to me and it's fun to get answers to the 3 + decades of speculation on the topic.
My understanding is they need a particular revision of the Kickstart ROM to get far enough in the boot process that they can load the 060 library which then installs the SPs and patches to OS routines. Mac has the FPSP in ROM and wants to check the FPU function in extremely early boot so updated ROMs would be a requirement.
For the time being I've just added a modification to force the ROM always into 32 bit mode at MMU initialization, combined with the modified MMU tables to map the full 8MB of ROM address space this avoids the need for dramatic changes to the ROM structure.
If one would like to see something done, one really has two options: one can learn to do it oneself, or one can incentivise other people to do so, either with money or with something else they would value; which may just be encouragement or cheering. Glumly telling people who have just done something impressive that they should have been working on something else because that's what you want doesn't count as incentivisation, I'm afraid.
Im pretty sure no one is using an 040-powered machine for productivity anymore. Unless its in some industrial equipment or something, in which case its very doubtful you'll be throwing some weird third-party upgrade into it. Especially doubtful its a Mac too, anyway.
I'm actually excited because this is a neat idea someone is actually working on, someone with the skill to see it through. I want to see benchmarks though with numbers, to see how much bigger the 060's numbers are.
I'm actually excited because this is a neat idea someone is actually working on, someone with the skill to see it through. I want to see benchmarks though with numbers, to see how much bigger the 060's numbers are.
You say this but there was someone on IRC recently still using one as a control system for chemical synthesis over LocalTalk (!). Really fascinating. You're right, though, I just thought you might enjoy that little bit of information.
Anyway, back to the thread...
Sorry, maybe I should not post when I am half asleep.
I didn't mean to shit on the effort. Nobody here is buying 68K Mac gear to do actual work these days, it is all about seeing what makes things tick and playing around with what used to be cutting edge. If somebody wants to invest time in going down the 68060 road as a fun learning process than good for them.
Mostly I was just wondering about cool stuff that actually made it into production hasn't been tinkered with more. Seeing how people are buying reproductions of 68030/68040 upgrades (which must take quite a bit of time and effort to reverse engineer) I was just wondering when people are going to go to the next level and overclock a 68040 and put enough cache in it that maybe most or all of your program fits in it. It would be funny seeing the results of an old benchmark running completely in processor cache.
We all have different areas of interest we explore, that wont change.
Setting expectations again: I don't anticipate finishing this work. I've already gotten further than my goal so this is the bonus round. I may tinker a bit further but there's no guarantees or any expectation of ending up in a truly usable state.
I verified with my other Q650 board that it will boot with the same ROM and CPU so this is reproducible. The first boot after a PRAM reset seems to hang at finder but subsequent boots are fine. Could be a result of my jimmying PRAM to force 32 bit mode too.
By popular demand here are some preliminary benchmarks. Branch prediction does not work at the moment (it causes immediate crashes) so that is going to significantly impact these numbers. FPU results are not present because I haven't got it finishing boot with FPU+FPSP. These will also be somewhat lower as my test board lost half its RAM due to a battery bomb, forcing it to operate in non-interleaved mode reducing memory bandwidth by 10-20% (AFAIK).
Here's additional reading on superscalar execution and branch prediction and why they are important. These are the two big "next generation" features introduced over the 040 beyond simply higher clocks and faster instruction timing. It can definitely be seen that without the branch prediction cache enabled the branch performance is notably worse than an 040. 040 will prefetch both paths, 060 assumes branch-not-taken and only prefetches that path. This is going to hurt performance badly: most of the CPU tests are going to have a lot of branching, so again, take these numbers with a massive grain of salt.
amazing work as usual @zigzagjoe !!! 
ROM Maps at https://github.com/joevt/68k-mac-rom-maps
ROM Fiend at https://github.com/joevt/rom_fiend uses the ROM Maps but also dumps declaration ROMs, Dispatch Tables, Universal Tables, Resources.
ROM Fiend is a template that is used by Hex Fiend at https://github.com/joevt/HexFiend
I suppose one could update
tbxi to do stuff with older ROMs using the info provided by the ROM Fiend template.