Thread
Motorola 68060 upgrade
ROTFLMAO!!!!!!!!!!!!! :lol:
Going back on my last post...
Oh God, I HAVE started a convention! xx(
Oh God, I HAVE started a convention! xx(
http://www.gnu.org/fun/jokes/know.your.sysadmin.html
I'm mostly under thug, with a dash of fascist. }
I totally should see if I can get SheepShaver to compile ...
I'm mostly under thug, with a dash of fascist. }
I totally should see if I can get SheepShaver to compile ...
OMG - I had no idea you could compress processes! Genius!
My first good laugh of the year!
Can't believe you've never seen that before, it's been around for decades now. 
Of course, I do use flat files and grep for phone numbers.
Of course, I do use flat files and grep for phone numbers.
Is it a personal machine or a work machine? I would like to get one for use at home, but they are too rich for my tastes.
I have a POWER 7 machine at work. Holy Crap it is fast.
Back to the topic.
Is the 68060 microcoded? If it is you could reprogram the microcode to work around the problem instructions.
It's a personal box mostly. My long-suffering Apple Network Server is finally exceeding my tolerance for flakiness, and I need another small-iron server. I still got almost 13 years out of it, though, and I expect to get the same or more from this 520. The ANS isn't being disposed of, just demoted to a playbox. They're a real collector's piece anyway, and it's certainly served me well.
Nope. The m68060 is not microcoded.
Just curious - what kind of flakiness have you been seeing? I'm still using a PowerMac 9600 (which is only slightly younger than the ANS), and while it is currently 100% stable (uptime of a year before moving datacenters while staying pretty busy), I'd like to keep my eye out for any warning signs.
I suppose you were running AIX on your ANS?
Just FYI, even if the 68060 were microcoded *very few* microcomputer CPUs allow the microcode to be modified by the user. ("Writable Control Stores" were fairly common in old CISC mainframes and some Minicomputers, however.) Nearly all eight and sixteen-bit CPUs are fully microcoded, but to change anything in almost every possible instance you'd be looking at having to modify a mask ROM on the CPU die itself.
And yeah, I know Intel CPUs since the Pentium Pro can be loaded with runtime microcode patches, which is a fairly unique ability, but even in that case I don't think you could use that facility to, say, force a Pentium 4 CPU to recognize some hardware-specific instruction unique to the Pentium III series. Only Intel knows for sure (Intel's updates are encrypted and highly obfuscated to prevent them from being exploited or even accidentally loaded on the wrong CPU.), but the little research I've done seems to indicate that the Intel microcode table is essentially a breakpoint *after* the instruction decoder which allows a sequence of RISC-like "micro-ops" to be substituted for an existing operation sequence. (Usually the replacement string bypasses some hardware acceleration feature found to be buggy, thus trading off some performance for reliability.) Whether you could actually trap an "illegal" instruction and make it valid with a Microcode update *alone* on an an Intel CPU is something only they know, but it would probably be a non-trivial exercise.
In a purely theoretical sense I've wondered if it would be possible to modify a Transmeta VLIW CPU to run Motorola 68k code. In principle a Crusoe or Efficeon with appropriate code-morphing software could probably easily outperform *any* real 68k CPU, even the fastest Coldfires. Of course, Transmeta never released the tools or documentation you'd need to write your own code-morphing microcode so... that's that. We'll never know whether a 68k-morphing Efficeon would be able to outperform a conventional Intel or AMD CPU running a "normal" 68k emulator or not.
Now you are onto something with the Transmeta CPUs.
Back in college I had a professor that updated the microcode on a Pentium III as part of his research. It has been about 10 years, but IIRC he change the processor mode that an instruction was available in. As you said it is a non-trivial exercise.
I'm wonder what the performance of a ARM core would be while emulating 68k code. If the performance is good enough it might be possible to use it to build a drop in replacement.
Of course now we are entering the world of the incredibly complex. A much simpler way would be to patch the ROMs to work around the offending instructions.
Back in college I had a professor that updated the microcode on a Pentium III as part of his research. It has been about 10 years, but IIRC he change the processor mode that an instruction was available in. As you said it is a non-trivial exercise.
I'm wonder what the performance of a ARM core would be while emulating 68k code. If the performance is good enough it might be possible to use it to build a drop in replacement.
Of course now we are entering the world of the incredibly complex. A much simpler way would be to patch the ROMs to work around the offending instructions.
Yes, AIX 4.1.5 with my own security patches. I shouldn't be too hard on it, it's a pretty busy server, considering (the web server handles around 10,000 transactions a day -- not bad for a vintage server).
Part of the problem is probably the RAM. It uses the parity FPM option, and when it heats up, a bit probably flips somewhere and AIX MCHKs since it doesn't do ECC. The system stays up, but it forces a reboot and kicks me off. This happens a couple times a week and it's enough to finally annoy me sufficiently. However, NSDU can't handle more than 256MB of RAM and the RAM always passes the ROM-based Long RAM test because nothing's hot yet, so I've never been able to track it down (and try finding parity FPM RAM today!). Cache had also occurred to me, but I would have expected more than just an intermittent fault for that, and it kernel-panics with a stock PCI Power Mac cache stick so I'd have to wait around for another 700 1MB cache.
By comparison, the Power Mac 7300 that runs my Gopher server is rock-solid, but there's no parity RAM (let alone ECC), and it's got a G3 card and I've got plenty of spares for that (I bought lots of Sonnet's CPU cards when they were blowing them out so I would have parts). I think the issues I'm seeing are more specific to the ANS, because after all it was intended as Apple's "big iron."
At one time trag was looking at designing a CPU card for the ANS, but he never was able to get far enough with it, and I think there would be exactly two people who would buy it (he and I). I'm sure there are people still using ANSes in production environments, but very few, and I'm the only one I know of that still runs AIX.
I actually built a card for it, but it didn't work. However, it gave me a bunch of ideas of things to try, which I (mostly) never did. It would be an interesting project to go back to just for interest's sake, but there are so many other projects in the queue ahead of it... It was pre-offspring.
With no components installed: http://www.io.com/~trag/PCB/ANSCPU_blank.jpg
With connectors and clock magic chips installed: http://www.io.com/~trag/PCB/ANSCPUw_parts.jpg
The bottom of the board is an edge connector that plugs into the ANS CPU socket. The brown connector is a standard x500 style CPU socket meant to take any (604(e)) CPU card that will work in a Macintosh, and possibly G3s as well. Those sockets were already mostly unobtainium when I started the project. I managed to get two samples from AMP/Tyco. But no distributor had stock, so building the upgrade in any number would have required ordering 1000+ of them at $8+ each and there might have been a market for 100 upgrades back then.
The various jumpers are there because while I had most of the 300+ pins figured out, there were some for which I was not absolutely certain of the proper connection. I suspect that many of them were actually don't cares. But I put in jumpers just in case. But then I calculated that in the worst case (i.e. every signal mattering) there were 1024 possible combinations of jumper settings.
However, I'm pretty certain that the worst case did not apply as I had some email help from one of the engineers at XLR8 and he had answered my questions about those last few questionable signals. So the jumpers were really there in case the XLR8 guy got something wrong, or just to cover the possibilities.
But it did not work. My next experiment was going to be to see whether I could clock chip the ANS bus down to 10 - 20MHz from 50MHz. If that worked with a stock CPU card, then I would retry my card, which might have noise issues at higher speeds. If that did work, then I would consider laying it out again as a four layer board. If it didn't work, I'd either invent some other experiments, or perhaps just lay it out again in four layers anyway, because the two layer layout probably is never going to work. I also needed to take an oscilloscope to the clock signals to make sure I got them in phase properly. But I didn't have an oscilloscope until near the end of the project, and I'm not sure the one I got even works (came from a coworker) and cheap PC based O'scopes weren't available back then.
I did have to create a pinout list for the x500 Mac CPU socket so at least that came out of it. The pinout for the ANS socket is in the ANS Hardware Developer Note. In the course of learning about the X500 CPU socket, I also learned some things about the Catalyst CPU socket and the PowerBase CPU socket and why those machines (from Power Computing) had the upgrade issues that they had.
But this was all back around 2001.