Motorola 68060 upgrade

[redrouteone]

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.

 

[ClassicHasClass]

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?

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.

 

[trag]

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.

 

[AeSix]

Depends on how you define shove. You can shove an '060 in an LC, but it won't do anything except take up space.

There are lots of threads on 68kmla where we lead the horse to water, try to make it drink, kill it, beat it after it's dead, try to ride it again, try to make it drink again, flog it some more, put on some techno and dance around it, et cetera. Just do a search for 68060.

I just did a search for 68060 on google, and this post is the second result...

 

[Phipli]

I just did a search for 68060 on google, and this post is the second result...

Its also 12 years old!

 

[cheesestraws]

I just did a search for 68060 on google, and this post is the second result...

And we've been around the cycle at least ten more times since then!

 

[Jockelill]

I think we would be better off doing an FPGA softcore with something like this:

GitHub - AmicableComputers/wf68k30L: A pipelined 68030 softcore in VHDL

A pipelined 68030 softcore in VHDL. Contribute to AmicableComputers/wf68k30L development by creating an account on GitHub.

github.com

I know that @Melkhior has invested a lot of time in the FPGA rabbit hole, and has also investigated the soft core option, but there are many issues before something "ready" would be available. The linked 68030 softcore is also missing both FPU and MMU.

In regards of the 68060, it's definitely a dead end .

 

[ArmorAlley]

And we've been around the cycle at least ten more times since then!

I sometimes wonder if such topics would make for great Ph.D. theses: bringing old chipsets to life either through updating/rewriting old OSs or for new ones. The latter would require a massive investment in resources but the former might just be doable.

 

[Snial]

Its also 12 years old!

Yay for Zombie Threads!

Actually, I have a related idea I'm toying with: The Macintosh CoolBox™. It's a bit like AMS, but aims to be a full reimplementation of the Macintosh Toolbox in 'C' for a host processor, starting with support for the entire 64kB ROM so that it can function as a genuine ROM substitute.

I have two implementation concepts:

1. The Macintosh CoolBox™ sits under a 68K emulator and traps unpatched 0xa000 and 0xf000 instructions, mapping them to equivalent functionality and properly so that when APIs are patched by an OS, the 68K emulator kicks in.
2. The Macintosh CoolBox™ is ported to a (probably ARM Cortex MCU) and paired with a partially decoded pair of Flash chips containing enough 68K code to invoke the MCU to perform the API. So, basically, here the 68K code performs memory copies.

The nice thing about this is that it means we can work around ROM © issues and also 68K reverse engineering performance issues, because 'C' on a 68K emulator will be so much faster that even fairly inefficient implementations would be more than fast enough. It'd be quite interesting to see a genuine Mac 128K with CoolBox™ ROMs running faster than the original.

 

[akator70]

^That's a cool idea... which is I guess why it's called "CoolBox."

As far as the FPGA solutions go, part of the problem is the capabilities of the FPGA used. The Cyclone V in the DE10-Nano used in MiSTer has ~110K logic elements. So far a 68020 is the largest 68K that has been squeezed into it, and there has been a lot of debate whether or not a 68030 is possible — if it is, it would be a very tight fit. It's fair to say that a 68040 isn't possible without far more LEs, meaning a much larger and more expensive FPGA. A 68060 would be even more demanding.

Without the Intel educational and development subsidies that bring down the costs of these FPGAs, the DE10-Nano would be 3-4x more expensive than the current price of $225. So while it may eventually be possible to emulate a 68040 or 60, the hardware requirements may prohibit use except in very high budget projects.

It's definitely something that is possible in the future, but whether it will ever be a reasonable solution is hard to say.

That's one reason why the PiStorm solution(s) for Amiga acceleration have gained so much traction. Even though a RPi is only being used to emulate the 68K and FPU, it's reasonably priced and performant compared to FPGA solutions.

Edit: On a side note, I was really excited to use the Mac Plus core when I first assembled my MiSTer. I was surprised at how buggy it was. The general consensus has been, "If you want to emulate a Mac on MiSTer, do it through the Amiga core." I've tried it and it does indeed work nicely with improved stability, but I haven't been able to embrace it because having to boot an Amiga to then launch Mac software just doesn't sit right with me...

 

[Snial]

^That's a cool idea... which is I guess why it's called "CoolBox."

Thanks, I figured it might be fun to have a play on words on ToolBox™. But also, it's fun to type Shift+Option+2 to get the '™' symbol !

That's one reason why the PiStorm solution(s) for Amiga acceleration have gained so much traction. Even though a RPi is only being used to emulate the 68K and FPU, it's reasonably priced and performant compared to FPGA solutions.

That is really cool! I guess it's a bare-metal implementation. Does it use the Cyclone emulator?

Edit: On a side note, I was really excited to use the Mac Plus core when I first assembled my MiSTer. I was surprised at how buggy it was. The general consensus has been, "If you want to emulate a Mac on MiSTer, do it through the Amiga core." I've tried it and it does indeed work nicely with improved stability, but I haven't been able to embrace it because having to boot an Amiga to then launch Mac software just doesn't sit right with me...

Indeed. I work in a very PC-orientated company. A couple of the older members had told me about how they'd got their Atari-STs (or Amigas, but I think STs) to run Classic Mac OS via a... I think... ROM patching app (maps the ROM to a new address along with some patches for the VIA and generating a 640x400 display instead of 512x342) and then claimed it was better than having a Mac.

But it always made me wonder, if it was really better than a Mac, why didn't you stick with it? And the reason I guess was because it was more inconvenient and perhaps not 100% compatible, so after a while, they'd just give up. They played with a fake Mac, the way people play with Hackintosh PCs and then dump them because of the poor experience.

 

[akator70]

It seems I was incorrect, PiStorm has developed quite a bit since I last read about it.

• The PiStorm itself is an adapter board intended to be paired with a Raspberry Pi Model 3A+. It goes in the DIP socket on and acts in place of the CPU, but functionality can be extended beyond simple CPU emulation.

• While the PiStorm should work with any DIP socket 16-bit 68000-powered system, the FC lines are currently not properly handled and no guarantees can be made for it working on anything except an Amiga 500, 500+, 1000 and 2000. It does work to some extend in a CDTV, but the lack of bus arbitration signal handling in the CPLD firmware will mean that the CD-ROM drive either does not work at all, or only works sporadically when the timing stars align.

• General Performance with the current use of Musashi as the 68k CPU emulator is somewhere around a 100-125MHz 68030.

What I didn't know about was that it does a lot more on the Amiga including Kickstart ROM mapping, using the RPi RAM as fast RAM, and PiSCSI access to storage devices connect to the RPi. The reason these are so interesting is that those things can be done on the Amiga, there's somewhat of a chance they could also be done on a Mac.

Indeed. I work in a very PC-orientated company. A couple of the older members had told me about how they'd got their Atari-STs (or Amigas, but I think STs) to run Classic Mac OS via a... I think... ROM patching app (maps the ROM to a new address along with some patches for the VIA and generating a 640x400 display instead of 512x342) and then claimed it was better than having a Mac.

But it always made me wonder, if it was really better than a Mac, why didn't you stick with it? And the reason I guess was because it was more inconvenient and perhaps not 100% compatible, so after a while, they'd just give up. They played with a fake Mac, the way people play with Hackintosh PCs and then dump them because of the poor experience.

Emulating Mac on Atari ST hardware was definitely a neat idea back in the day. IIRC one of the solutions required getting a Mac ROM and installing that into an external peripheral attached to the ST. Because it used a real Mac ROM things were pretty reliable. It seems insane now, but when Macs were priced in the thousands, the STs were much more affordable so you could buy the ST + a Mac ROM (~$800) still for less than buying a Mac.

I don't recall if there was a similar hardware solution for the Amiga, but the ShapeShifter Mac emulator on Amiga was pretty impressive. It is also impressive to see that running well on a FPGA Amiga. Running a software emulator on a hardware emulator speaks to how well developed the Amiga core has become.

My primary issues with this solution are that it doesn't feel like a true Mac experience, just the same way as running Basilisk II on modern macOS doesn't. All issues of emulation accuracy aside, the host OS diminishes the experience of the emulated device. If you want the experience of using classic hardware from any manufacturer, the host OS makes that experience less "pure." I know this is splitting hairs, but that's my takeaway since my first emulator use in the 1980s. Emulation is incredible and I love it, but there are many times I want a more "pure" experience.

 

[eharmon]

A few folks have gotten PiStorm working, to a degree:

Help Needed for ROMINATOR ROM MOD for Macintosh SE for PiStorm Booting

Greetings, I've gotten the PiStorm to boot on my Mac SE with a softROM file of the Mac SE FDHD base ROM. Floppy and SCSI are not fully functional and since I can make the ROM bigger than stock I am attempting to implement the "ROMINATOR I" driver in the Mac SE ROM to allow me to add a ROM Disk...

68kmla.org

https://twitter.com/i/web/status/1466833770988949508

Quite exciting, but it's never gone anywhere than some quick tests, as far as I've seen.

 

[Snial]

A few folks have gotten PiStorm working, to a degree:

Help Needed for ROMINATOR ROM MOD for Macintosh SE for PiStorm Booting

Greetings, I've gotten the PiStorm to boot on my Mac SE with a softROM file of the Mac SE FDHD base ROM. Floppy and SCSI are not fully functional and since I can make the ROM bigger than stock I am attempting to implement the "ROMINATOR I" driver in the Mac SE ROM to allow me to add a ROM Disk...

68kmla.org

https://twitter.com/i/web/status/1466833770988949508

Quite exciting, but it's never gone anywhere than some quick tests, as far as I've seen.

"We have a small corner on our discord server dedicated to 68k Mac and Atari. Especially the Atari folks made huge progress in recent times. I think Mac can benefit from this progress too."

 

[akator70]

I read through quite a bit of the Discord posts about Mac and ST progress. It looks promising.

To my knowledge there hasn't been much progress in developing open source FPGA recreations for Mac hardware after the initial work was done a decade ago. There were some fixes when the Macintosh Plus core was ported to MiSTer (which are greatly appreciated) but the current state of Macs on FPGA is far behind other systems . In contrast, the Amiga community has accomplished a lot, enough that many users wouldn't notice a difference from original hardware except the added conveniences of USB, Ethernet, WiFi, modern storage, HDMI, and analog video output options. The Atari ST cores are not as developed as the Amiga, but still significantly farther along than Mac.

Last year I decided to learn more about FPGAs by buying some additional hardware and throwing myself into it. I studied and did hands-on with the hardware. I did indeed learn a lot more but also discovered my abilities were greatly lacking and there was little chance for me to make any meaningful contributions — it's a good thing I wasn't in the classroom because I would have struggled to even get a C. I wish that I could be one of the people contributing to better Mac FPGA cores, but I'm simply not up to the task.

The high quality of ShapeShifter Mac performance running on the Amiga core means that a lot of the underlying work has been done. Perhaps one day some brave souls with skills exceeding my own will accomplish it. The results could then also be applied to FPGA replacements, upgrades, and integrations in the real classic machines.

 

[CircuitBored]

"We have a small corner on our discord server dedicated to 68k Mac and Atari. Especially the Atari folks made huge progress in recent times. I think Mac can benefit from this progress too."

I was able to get the PiStorm to "work" with a Macintosh Classic, in that it was able to boot up from a floppy disk and putter around the OS. It took about two day's worth of time spread over an entire year to get to this point.



I had to use an early version of the Atari firmware due to the current main branch completely lacking any form of bus arbitration, which the Atari and Macintosh depend upon heavily. SCSI didn't work and the machine was very crash-happy. None of PiStorm's fancy RAM and ROM overlaying features work at present. There have been reports of people getting PiStorm to "work" in the Macintosh Plus and SE but the community as a whole (honestly, myself included) has done a terrible job of keeping good notes of what they are doing with which hardware in which systems.

Besides the geometric issues of cramming Pi+FPGA onto a logic board with near-zero wriggle room, the overriding problem with trying to get PiStorm into the Classic in particular is power. When powered by the Classic's logic board as pictured, the Pi 3 constantly complains about low voltages, even when undervolted and underclocked (a counterproductive measure when trying to build a performance upgrade). Stepping up to the even more power-hungry Pi 4 to try testing the newest Atari firmware jeopardises the whole Mac, which I am not keen on doing at all. This issue with power delivery will be shared by all the compact 68000 Macs that do not have discrete PSUs, namely the 128K, 512K, and Plus.

The "official" Macintosh mode of PiStorm is all but non-existent. It is not being actively developed and the "Mac" stuff you get when installing main branch PiStorm does not work in any system as far as I have seen.

PiStorm as a project and as a community is fairly chaotic. Scope creep and a predominant interest in Amiga systems have turned a general-purpose 68000 hardware emulator into what is essentially an Amiga-specific upgrade with absolutely anything unnecessary trimmed off at the CPU emulation level (and a bunch of Amiga-specific enhancements crammed in at the user end). Most PiStorm versions for non-Amiga systems have fallen off main branch and landed in their own forks by now. There is not currently a fork for Macintosh, although I am very slowly working toward it.

There are myriad combinations of various PiStorm boards, PiStorm firmwares, PiStorm emulator versions, host Pis, and adapters with absolutely no central database or webpage detailing the differences and expected behaviours therein. Getting up to speed with the project involves reading a backlog of thousands of Discord messages.

All this is not to be construed as an outright criticism of PiStorm itself, as I have had many positive interactions with the folks behind it and think that the project is itself still impressive and worth exploring further. That said, those who are hoping for anything PiStorm-related in their Mac any time soon can expect a good, long wait. The pieces are all there, they just haven't been pieced together yet and doing so will take a long time. If an expert were to rock up intent on building a fully-fledged Mac version of PiStorm it would probably not take them very long to put all the pieces together and build a drop-in replacement for 68000-based Macs. Sadly, I am a rank amateur when it comes to programming and all that I have achieved with is project has been from standing on the shoulders of giants.

I'm currently in the middle of a month-long effort to get my workspace back into a usable state, which has been hampered by my frankly awful mental health. Hopefully some time soon I will get back to this project and give it a little bit of momentum.

TL;DR: PiStorm has been developed in ignorance of the 68000's specification in order to more quickly get it working for Amiga. There is no stable or usable PiStorm for Mac and there will not be any time soon.

 

[CircuitBored]

I read through quite a bit of the Discord posts about Mac and ST progress. It looks promising.

It is promising. Like a jigsaw puzzle without the lid of the box it came in is promising.

 

[cheesestraws]

Any fast, modern 68k emulator masquerading as hardware is going to be competing in the market with G4s that are cheaper, faster, and run more software.

You're looking for someone who will do it for the sheer magnificent fun of it. You might find someone. Good luck.

 

[Phipli]

Something these projects sometimes overlook is the need for ROM patches. Macintosh hardware uses the CPU to control timing critical hardware. Actually, isn't this product using a JIT emulator? Is it possible to get the timing right with a JIT emulator?

That and the need to present RAM contiguously when ROM is memory mapped 4MB in. Fixable, but... I don't know how Compact Virtual does it

I hope it all gets sorted some day.

 

[akator70]

I was able to get the PiStorm to "work" with a Macintosh Classic, in that it was able to boot up from a floppy disk and putter around the OS. It took about two day's worth of time spread over an entire year to get to this point.

Wow, thanks for that info. It's a nice summary, and thanks for your work on it. As someone who has contributed to different open source projects over the years, I completely understand where you are coming from.

Any fast, modern 68k emulator masquerading as hardware is going to be competing in the market with G4s that are cheaper, faster, and run more software.

You're looking for someone who will do it for the sheer magnificent fun of it. You might find someone. Good luck.

True on both accounts, but it's nice to have more options. Open source can be a wonderful thing — I'm sure lots of people do it for the sheer fun of it, for the challenge, and for the idealism of making something they thing should me made.

The power requirements are one area where FPGAs often beat RPis. Perhaps one day someone with expertise will tackle that area.

 

[mg.man]

one of the solutions required getting a Mac ROM and installing that into an external peripheral attached to the ST.

Yes, one of those was the Spectre GCR

Spectre GCR - Wikipedia

en.wikipedia.org

I have one I bought from new - for the very reason stated - the Atari ST (mine was a STfm boosted to 4Mb) was much cheaper than a real Mac. The 'GCR had the added advantage that thanks to some wizardry, it could read and write Mac (GCR-encoded) diskettes. I even had HDs attached to my "AtariMac" with bootable Mac partitions. Pretty amazing stuff back in the day.