Jump to content

ROM update for full 68060 support on LC475?


Recommended Posts

Hello!

 

I have finished building a 040->060 adapter (same one as used on amigas) and I have a full mmu+fpu 68060 with the intention of upgrading my LC475

sadly this combo does not work due to the 68060 fpu

I have read in some places (like this ad here: http://archive.irixnet.org/apocrypha/nekonomicon/forum/4/16729461/1.html) about a rom update to fully support the 060

Is this knowledge/rom anywhere available?

 

Thanks for any info tips!

Link to post
Share on other sites
  • 68kMLA Supporter

"Fully support" is perhaps a bit overstating the case for what that person looks like they've done: they've wedged a 68k Linux bootloader into the ROM and is then loading Gentoo from it.  If you do that then what you've got really isn't exactly a Mac any more; it won't be able to run or load MacOS, or anything really other than Linux.  It seems an awful lot of effort to go to to get a bad Linux box.

Link to post
Share on other sites
  • 68kMLA Supporter
Posted (edited)

(that thumbnail is not representative of my attitude… it's what auto-populates with this link paste. But on that note, I google searched for '060' site:68kmla.org and you tend to get fewer repeat or extraneous searches than with the forum search)
 

 

My non-trained eye seems to see "instructions" come up a lot in these threads. The instruction set for the 060 must have quite a lot of incompatibilities (perhaps that's an oversimplification) with that of the 040, so a lot of translation might be necessary. So I imagine it's best summed up like this:

 

On 10/31/2010 at 9:02 PM, Dennis Nedry said:

It seems straightforward at first glance but the necessary tweaks begin to multiply as you examine the details.

Edited by jessenator
Link to post
Share on other sites

it seems just like the amiga world a full 68060 will not work as a drop-in replacement due to the fpu and the opcodes it generates and thus keeping the machine in a reboot loop state.

in amiga world this was resolved with either extra rom on accelerator or direct kickstart support ( = the amiga"bios" in a sense, newer versions support fully the 060)

the other solution is to use a 68LC060 - this version has no fpu but retains the mmu and just works

a good friend of mine told me he indeed had a LC475 with a 060 using such an adapter but after I told him the system does not boot and mentioning the LC cpu variant he confirmed that it was indeed the cpu he used

 

I ordered such a cpu and I will update the thread once I receive and try it. In theory it will just work. Else it is just some wasted money+time ::)

Link to post
Share on other sites

I was a bit curious when I had saw this topic in the rightside 'newest post' list and mm well I didn't have a lot to say but for this little thought below...

 

I don't know about anyone else but after a cursory lookup about the 68k cpus and fpus I had to wonder if assuming this worked then maybe one of you project people could try a 50mhz benchmark to see how much difference there would be between a 68LC060+68882 and basically any pre-68060 that had internal or 68882 fpu with it just for to see? :)

(I suspect that at the same 50mhz clockrate for all tests the jump may not be that huge but it may still be interesting?)

Link to post
Share on other sites
On 4/1/2021 at 2:38 PM, bigD said:

Wasn't there some show stopping technical reason why the '060 could never work with MacOS?

 

No. There's no technical reason why it wouldn't work.

 

The m68060 is missing some instructions that the '040 has, so a ROM has to set up exception traps for those instructions. The stack frames are different, too, so the ROM would have to handle this, too. Use of the MMU would require the most work, but since Mac OS defaults to not using virtual memory, this shouldn't be hard.

 

ShapeShifter is an emulator (technically, more of a virtualizer) which runs Mac OS as a task on an Amiga. I used it for years to run Mac OS on my m68060 Amiga. All the code needed to adapt Mac OS to run properly on an '060 is in there, and it's all open source.

 

Mac OS, incidentally, runs absolutely wonderfully on an '060. It flies! It makes many m68k titles run as fast as or faster than PowerPC native apps ran on the first generation PowerMacs.

 

BTW - the '060, like the '040, doesn't put coprocessor instructions on the bus like the '020 and '030, so they can't be made to work transparently with an m68881 or m68882. While the coprocessors can be added as memory mapped peripherals, no software would work with them natively. Anyhow, they were wonderful chips for their time, but their performance was a tiny fraction of what an '060 can do, and I'm pretty sure an '060 trapping FPU instructions with the Motorola FPSP will always be faster than natively running on a 50 MHz m68882.

Link to post
Share on other sites
  • 1 month later...
On 4/1/2021 at 7:16 PM, johnklos said:

No. There's no technical reason why it wouldn't work.

 

So technically all we're waiting for is someone to examine ShapeShifter's handling of the '060 and re-implement it in something like a ROMinator for an '040 Mac.

 

That's great news and it's like we're halfway there already! /s

 

More seriously, I suppose the question is -- does anybody have those skills? Does anybody with those skills want to do it? Do we get anything out of it other than a "oh neat"? If @keropi6k6 was looking for this, specifically, as a project, we found it.

 

If you were looking more for a performance boost, well:

The Mac (compared with the Amiga) has historically had the advantage of having been continued as a platform by its original vendor and each successive generation of Mac also got CPU upgrades basically until the G5. So if you want to run System 7 faster than it goes on an 840av, and faster than it can go on a Mach5 system, you can drop a G3 or G4 into a PCI PowerMac, and if you're willing to run that software on system 9 you get QS'02 and MDD upgrades. Not to mention Classic Mode in 10.4 on a G5 if you can get any meaningful speed boosts out of that. 

 

It would be super neat to have '060s running in old Macs, and it would make a super neat project for whoever wanted to work on it, but I don't know if there's an awful lot in the way of wide appeal for doing that instead of just getting a PCI PowerMac or even a G3.

Link to post
Share on other sites
  • 68kMLA Supporter

Yeah, the reason is a practical one rather than a technical one; the reason it didn't get done at the time was PowerPC, and really the reason nobody's done it since is PowerPC. 

 

4 minutes ago, Cory5412 said:

someone to examine ShapeShifter's handling of the '060

 

That sort of implies adding a supervision layer to the ROM, which sounds like a nightmare waiting to happen.  To do it properly, you'd have to patch the places in the ROM where it makes the assumptions that @johnklos talks about above.  Which ain't impossible by any measure, but is waiting for someone, as you say, to do it for the fun of it rather than because it will produce a faster Mac.

 

(See also my previous posts about modern accelerators...)

Link to post
Share on other sites
  • 68kMLA Supporter
On 4/1/2021 at 10:16 PM, johnklos said:

Mac OS, incidentally, runs absolutely wonderfully on an '060. It flies! It makes many m68k titles run as fast as or faster than PowerPC native apps ran on the first generation PowerMacs.

 

From MacWorld February 1993, page 111 "News" section:

 

"Because the 68060 will be faster than the PowerPC 601, the 601 will be relegated to a midrange Mac, while the 68060 will get the glamour job in a line of high-end Macs in early 1994, according to industry sources."

 

1236402212_Image5-13-21at12_54PM.thumb.jpg.e0d9206ca07c118e02364f125e37d770.jpg

 

What could have been!

Link to post
Share on other sites

My apologies, that was some lazy phrasing on my part: I didn't mean to imply porting SheepShaver to the Mac ROM but document what situations it handles and how it handles them (I suppose you could do this by using '040 and '060 reference docs as well) and how it handles those situations and patching the ROM thusly.

 

I agree, it would be really neat to do and fun to see, even if at this point (or even in 1996 or 2002) the practical use for it is arguably limited -- IME things that need FPU access are trying to frob a 68881 or 68882 directly and even the '040 doesn't really satisfy their requirements unless software shims (SoftFPU IIRC?) can actually resolve that part of the problem and that kind of software to work. (I'm lazy and my solution to that has almost always to get newer software so I've never tried softFPU.)

 

Stuff that had switched over to standard apple numerics (SANE) (that aforementioned "newer software") by '93 or so should run fine on PPCs as well, since that's using APIs instead of directly calling hardware.

 

5 minutes ago, Fizzbinn said:

"Because the 68060 will be faster than the PowerPC 601, the 601 will be relegated to a midrange Mac, while the 68060 will get the glamour job in a line of high-end Macs in early 1994, according to industry sources."

 

Now there's an alt-universe take.

 

On the x86 side of things, "basically a faster 486, as a cheap alternative to a real pentium" continued until the mid-late '90s and on Macs, 68ks remained in use themselves until late 1996 but primarily LC040s and '030s in LC/Performa/PowerBook type systems. Having an '060 or moving more things to the 40MHz '040 (if Apple hadn't already used the "640" number, the 640 family would've been a clever name for a 630 but boosted to 40MHz, same for a 630 but boosted to an '060 for "660".) (*Though I suppose Apple could have done for the 630/580/190 what they did for the 650 and just sold newer revisions with newer specs under the same name, or did what they did on the LC III and tacked a + to the end of the name for an 040@40 or any 060 version.)

 

The problem with PPC as the midrange is a lot of why the 630 exists at all is because Apple wanted to cost reduce an '040 to be able to sell to the even more cost conscious market.

 

One interesting point of meta is whether or not an 040@40 or any 060 put into a PowerBook 190/5300/1400 enclosure could have stemmed some of the losses Apple incurred in 96/96 from not having laptop stock available or if they would have had the same problems with a 68k-based PowerBook. (Though part of the problem is that the PPC did end up being the performance champion and pro users wanted to have that in a to-go size as well, so it's tough to say whether a fast 68060 laptop would have sufficed.)

Link to post
Share on other sites

Here's an interesting note from someone who says they worked at DayStar and were involved in testing presumptive '060 upgrades vs. PPC upgrades:

 

https://www.applefritter.com/comment/840#comment-840 

 

In their testing the '060 was no faster than the '040, clock for clock.

 

The text of the post Submitted by ikrantzler on March 5, 2004 - 2:38am.

Quote

I worked at DayStar for a while and wanted to set the record straight regarding the Turbo 060.

At the time, it wasn't clear how well the PowerPC 601 was going to do performance-wise versus the 68060 when running emulated code. So DayStar did both products in parallel: the '060 version of the Turbo 040, and the PowerPro which was a PowerPC 601-based upgrade.

As it turned out, the '060 was no faster than the '040 at comparable clock speeds, so we killed the product. It had nothing to do with Apple "letting us" do it. The Turbo '040 didn't need a license for the ROMs, and neither did the '060.

It is true that Apple really wanted a smooth transition to PowerPC, but they had no control over what we did. The reality was, the product wasn't compelling, so we killed it.

And the rest, as they say, is history. :mac:

 

Link to post
Share on other sites
3 hours ago, Cory5412 said:

I agree, it would be really neat to do and fun to see, even if at this point (or even in 1996 or 2002) the practical use for it is arguably limited -- IME things that need FPU access are trying to frob a 68881 or 68882 directly and even the '040 doesn't really satisfy their requirements unless software shims (SoftFPU IIRC?) can actually resolve that part of the problem and that kind of software to work. (I'm lazy and my solution to that has almost always to get newer software so I've never tried softFPU.)

 

Apple traps FPU instructions that exist on the m68881 and '882, but don't exist on the '040. Software which uses them transparently works.

 

SoftFPU is a program that emulates an FPU entirely. It works on '020 and '030 by trapping, and on LC040 systems if the mask revision is new enough. Original LC040 CPUs had a problem that would cause FPU emulation traps to fail now and then.

 

2 hours ago, Cory5412 said:

In their testing the '060 was no faster than the '040, clock for clock.

 

I don't believe this at all, as one can see from my response. Even on a CPU card in an Amiga 3000 or 4000, which uses a motherboard memory interface intended for '020s and '030s and is SLOW, the larger caches, the branch prediction and folding, and superscalar execution make the '060 significantly faster than an '040, clock for clock.

 

I have evidence: benchmark results, including Speedometer 4, Norton System Information, MacBench 4 and other results from a real '060 system. User "ikrantzler" offered nothing.

Link to post
Share on other sites
3 minutes ago, johnklos said:

I don't believe this at all

 

Yeah, I mean, based on their post, they had access to this information in the mid '90s and I'm guessing they don't still have the card to re-do this testing. So, in 2004 they would've been ~8-10 years out from when they were working on that. I am inclined to believe the general conclusion they made which was that the '060 upgrade wasn't a "compelling product".

 

Whether that was because of performance or some other factor like software compatibility was poor or the price on the chips was too high or because they figured a whole new computer would cost less than the combined upgrades needed to get to a certain point of performance, I don't know that I think it matters other than when we specifically focus in on splitting hairs about performance which, arguably doesn't actually matter because 1GHz G4s for the PowerMac 7500 exist, if you really want to run 68k system 7 code fast.

 

Anyway, PM me for an account on vtools, we've got a copy of MacBench 4 which should run natively on both PPC and 68k, and a folder of community-collected benchmark results so people can do their own comparisons. I would love copies of your macbench files for that Amiga. I love MacBench as a benchmark in general, the CPU and graphics tests do a fairly robust selection of real application tasks versus, say, a tight loop that can fit in an L1 cache. I also like the disk benches for having some variety built in and testing a couple different scenarios. (e.g. random vs. sequential, read/write, different file/data sizes.)

 

Alternately, pull up the files and make a screenshot, if you can, a regular quadra of any kind, your Amiga, and a PPC Mac or two would be ideal targets to show.

 

For 68k emulation comparisons we also have a version of Norton speed-bench-whatever from 1993, and we've been working on adding various things to that folder. (including speed doubler 8 and non-speeddoubler8 results for certain systems to see how that boosts 68k emulation performance, which, it does, a lot.)

 

I would love to see your Amiga's results on MacBench 4. I have an 840av I can/need to pull out to compare against. I've already got a variety of 6100/66, 6200/75, 8600/300 and beige g3/300 results. (I'm going to get a 6500/300 in the mid future for that specific kind of fun.)

 

 

The other thing is, of course, as you mentioned the platforms for a presumptive new-build 060 mac, an upgraded or adapted 040 -> 060 mac and an 060 upgrade for an older mac and the Amiga are different. The Amiga would appear to be a worst-case scenario (along with, say, an upgrade card for the IIci). There could be something else that they saw and to be honest we don't even 100% know from what that AF user posted that they had an '060 comparable to what you have in your Amiga, which is another thing.

 

Granted, like, because this doesn't exist and the ROM updates/patches needed to do it haven't been authored it we can't really test what a real Mac 060 upgrade would have looked like, we can only kind of speculate, so, all we'll be doing is proving what Amiga+ShapeShifter can do. (Still, that'd be interesting to see.)

Link to post
Share on other sites
  • 68kMLA Supporter
Posted (edited)
8 hours ago, Cory5412 said:

Stuff that had switched over to standard apple numerics (SANE) (that aforementioned "newer software") by '93 or so should run fine on PPCs as well, since that's using APIs instead of directly calling hardware.


I’m not sure what you’re referencing here but pretty sure it isn’t SANE. SANE was Apple’s implementation of an IEEE standard for floating point representations (ie data types) and calculations that was made available as a library as part of the earliest Mac SDKs in 1984. It was “Standard Apple” because the Apple II family supported it, too. 
 

EDIT - I see what you mean on second reading that yes using SANE instead of calling the FPU directly would result in wider compatibility (with any machine lacking an FPU); the part that confuses me is the suggestion that this was “new” or a “switchover” in 1993 as it would in fact have been standard practice in 1984!

Edited by Crutch
Link to post
Share on other sites

I'd wager that an '060 not being a "compelling product" would be based on Apple's wishes more than anything. The amount of money people spent on '040 accelerators was already high, and there were plenty of apps which didn't run correctly on PowerPC for quite a while. What I wrote in that post was a perfect example - special PostScript RIP software that wouldn't run on PowerPC without an upgrade, coupled with a $3,000 price for the upgrade, wasn't uncommon. I overclocked quite a few Quadra 650 / 800 machines for exactly the purpose of running software that couldn't be moved to PowerPC.

 

But there is no "splitting hairs about performance". The performance of the m68060 is known. Compatibility is excellent. The only programs that had issues were specific extensions in Mac OS 8.1, which could easily be circumvented by turning off superscalar mode, booting, removing those extensions (or replacing them with patched / specific versions), then re-enabling superscalar mode. The last version of Adobe Illustrator for m68k also had an issue, but it still ran incredibly quickly with superscalar disabled. That was it - those were the compatibility issues.

 

I don't know what "ikrantzler"'s agenda was, but when someone asserts something in direct contradiction of known facts and reproducible results, without the tiniest of evidence, they lose credibility.

 

My Amiga 1200 with m68060 that used to be my main Amiga / Mac workstation is running NetBSD and is colocated, so I can't run new tests until I finish recapping my Amiga 4000. But I'll happily upload what I have :)

 

15 minutes ago, Crutch said:

I’m not sure what you’re referencing here but pretty sure it isn’t SANE. SANE was Apple’s implementation of an IEEE standard for floating point representations (ie data types) and calculations that was made available as a library as part of the earliest Mac SDKs in 1984. It was “Standard Apple” because the Apple II family supported it, too. It didn’t have anything to do with bypassing direct FPU calls, as it predated Mac FPUs by several years. 

 

The idea behind SANE was that any software which used it would automatically make use of the fastest method. Machines without FPUs would do all math completely in software. Machines with FPUs would use the FPUs to run SANE. And machines with PowerPC would use the PowerPC FPU, and the programmer would be none the wiser, because of using SANE.

 

This was supposed to be preferable to either trapping FPU instructions or having two code paths in programs, one which called the FPU directly, one which did software floating point. Trapping typically has more overhead than running software floating point directly.

Link to post
Share on other sites
  • 68kMLA Supporter
Posted (edited)
14 minutes ago, johnklos said:

The idea behind SANE was that any software which used it would automatically make use of the fastest method. Machines without FPUs would do all math completely in software. Machines with FPUs would use the FPUs to run SANE. And machines with PowerPC would use the PowerPC FPU, and the programmer would be none the wiser, because of using SANE, you had to recompile. 

 

This was supposed to be preferable to either trapping FPU instructions or having two code paths in programs, one which called the FPU directly, one which did software floating point. Trapping typically has more overhead than running software floating point directly.


I don’t think this is correct. SANE stipulated precise layouts of data types down to the bit level, it wasn’t an abstract API. PowerPC Numerics and SANE were mutually exclusive things, and Inside Macintosh: PowerPC Numerics (Appendix A, if you care :) ) describes how to recompile old 68k code that uses SANE to instead use PowerPC Numerics and why one might wish to do so. You didn’t get a PPC speedup automatically by using SANE, you had to recompile. 
 

In the pre-PowerPC era, I don’t know exactly how you would not use SANE without a ton of work... If you wanted to do floating point math in a Turbo Pascal program written in 1986, you were going to include a “uses SANE” call because that’s the only library that had functions like log and arctan. 

Edited by Crutch
Link to post
Share on other sites
14 hours ago, Crutch said:

I don’t think this is correct. SANE stipulated precise layouts of data types down to the bit level, it wasn’t an abstract API. PowerPC Numerics and SANE were mutually exclusive things, and Inside Macintosh: PowerPC Numerics (Appendix A, if you care :) ) describes how to recompile old 68k code that uses SANE to instead use PowerPC Numerics and why one might wish to do so. You didn’t get a PPC speedup automatically by using SANE, you had to recompile. 

 

I remember reading that SANE on PowerPC was native, so that SANE calls from m68k code didn't go through m68k emulation. Is that not the case? I know SANE wasn't meant for native PPC...

Link to post
Share on other sites
  • 68kMLA Supporter
Posted (edited)

It’s likely (though I am not certain) that code to emulate SANE and produce the same results as legacy SANE was indeed written in PPC native code so that applications that use SANE would do their calculations as fast as possible. However the PPC built-in floating point features don’t support SANE and are bitwise incompatible with SANE in many cases, so “running SANE fast on a PPC by using native PPC-coded library support” and “using the PPC’s built-in (faster) floating point routines” are necessarily two different things. Using SANE might get you the former, but the latter requires a recompile. 

Edited by Crutch
Link to post
Share on other sites

This Usenet post by Paul Snively, an Apple employee, says that SANE used an FPU on machines which had it.

 

Gary Davidian's Motorola 68K emulator for PowerPC did not emulate the FPU, thus all SANE operations executed by a 68K application running on a Power Macintosh are emulated as 68K instructions, not as 6888x instructions.

 

Though it is commonly stated that the Motorola emulator emulates a 68LC040, it is actually presented as a 68020 to 68K applications, as the 68020 does not have a built-in MMU or FPU.... neither of which are emulated.

 

The PowerPC CPU had native support for much of SANE's functions, albeit with a different data size, thus native PowerPC applications did not use SANE at all, and instead used corresponding PPC instructions.

Edited by Dog Cow
Link to post
Share on other sites
  • 68kMLA Supporter

Would the MMU-less 68EC060 open up any possibilities or simplify this problem? I'm guessing not, but I haven't seen them mentioned much anywhere, yet I know accelerators like the Carrera040 and Turbo040 support 68EC040s.

Link to post
Share on other sites
  • 68kMLA Supporter
Posted (edited)
17 hours ago, Dog Cow said:

This Usenet post by Paul Snively, an Apple employee, says that SANE used an FPU on machines which had it.

 

Gary Davidian's Motorola 68K emulator for PowerPC did not emulate the FPU, thus all SANE operations executed by a 68K application running on a Power Macintosh are emulated as 68K instructions, not as 6888x instructions.

 

Though it is commonly stated that the Motorola emulator emulates a 68LC040, it is actually presented as a 68020 to 68K applications, as the 68020 does not have a built-in MMU or FPU.... neither of which are emulated.

 

The PowerPC CPU had native support for much of SANE's functions, albeit with a different data size, thus native PowerPC applications did not use SANE at all, and instead used corresponding PPC instructions.

 

Right, this is what I was saying.  I also confirmed (turns out it’s written right there in Inside Macintosh: PowerPC System Software on p. 1-9!) that SANE is indeed implemented on Power Macs in native PowerPC code (I assume that means in the system software somewhere).  So, as I guessed above, you would indeed get a speedup running SANE code on a Power Mac, but you do not get any “free” benefit of full-fledged built-in PPC CPU floating point math without a recompile to native code.

Edited by Crutch
Link to post
Share on other sites
4 hours ago, Crutch said:

I also confirmed[…] that SANE is indeed implemented on Power Macs in native PowerPC code (I assume that means in the system software somewhere).

Thanks for checking that. I didn't have a clear answer for that question about SANE on PPC.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...