Macintosh 68060 Redux

[zigzagjoe]

A Quadra 650 should theoretically be somewhere between 30-40mb/s of memory bandwidth with line transfers. Scaling for clockspeed that'd give BFG 58 mb/s of bandwidth with the full speed bus @ 64mhz, seems to correspond nicely with the observed results of BFG managing ~2x blockmove performance.

That "slow" half speed L2 cache can supply data at 85 MB/s with similar latency to what BFG's RAM timings probably are; it makes sense that the cache would bring the read-heavy Tree, Sort and Search benchmarks to a similar range as the BFG. Real world performance of the cache is going to depend on data locality, though, cache thrashing wrecks performance.

If this page is to be believed Cyberstorm MK3 uses a mix of interleaving and what PC manufacturers today call dual channel RAM, two 32 bit modules supplying a 64 bit bus. Initial access latency is going to be limited by technology of the time but burst reads should be ridiculously quick as each ram access supplies two longwords and the interleaved access supplies the other two making up the 4 longwords of each 68040/68060 RAM access. It'll be complex to sequence and shuffle the extra longwords around, but performance should be very good. This would be a practical implementation of what @eharmon was speculating about.

 

[Trixster]

Bustest score for CSMk3 at 75Mhz (I don’t think they can clock much higher than this due to board limitations) gives 72MB/s for long word read.

 

[zigzagjoe]

Not much new to report here. Working at a 256KB cache board that incorporates the 060 adapter, hopefully I'll get that routed over christmas break. Just something to play with. Two findings of interest, though:

Turns out the early revision 060s like additional voltage. A lot. Previously 65mhz was the razor edge for stability but bringing VCC to 3.6v changed that to 83mhz. A bit of airflow across the heatsink is required at that speed as otherwise it becomes unstable once hitting ~60 degrees C die temp. Maximum supply voltage is specified as 4v so we're still fine there. As far as I'm concerned that frequency is ideal since wombats do well at 40mhz bus.

I've added the ability to customize the MEMC timings to the ROM and purchased some 40ns 64mb SIMMs to play with. Not easy to come by, and the modules I found I had to add a regulator as they were intended for 3.3v systems though the DRAM is 5v tolerant. I was able to tighten the memory timings considerably - to the minimums supported by MEMC - with a corresponding performance increase in performance in memory-bound tasks. What's more interesting is while I added the option to soft-disable the onboard RAM as I've got a mix of 70ns and 80ns, it will still operate with the onboard RAM (and no simms) at the tightened timings. At some point I'd like to work through the timing diagrams in the MEMC datasheet and figure out what "safe" parameters would be for 40/50ns RAM.

The custom memory timings / onboard RAM disable can be used if building the ROM in an 040 version also - there's a single config option that controls that.

 

[croissantking]

Not much new to report here

On the contrary, your voltage and ram timing tweaks are pretty impressive!

Getting the best results from an 060 on a wombat clearly require a lot of experimentation and refinement, throwing the cpu in and getting it to work is just the beginning.

 

[MacItalia]

Hi all !
Please, some users could send me the assembled file, or an URL to download ?

Thank you

 

[Oliver_A]

Hi,

firstly, congratulations on getting the 68060 running on a native Macintosh.
I'm coming from the "other"side (Amiga), but recently acquired an LC475 which I am currently getting familiar with.

One hint regarding the patching of the Mac Roms to get them fully working with the 68060: have you considered looking at the Shape Shifter source code, which is available here: https://aminet.net/package/misc/emu/ShapeShifter_src

Since many decades, Amiga people have been booting classic MacOS using Shapeshifter on a 68060, and I'm sure that the information contained in the sources could be proven to be helpful here.

Keep up the great work!

Oliver

 

[Oliver_A]

Btw, if you ask me, disabling access to the on-board RAM and, instead, implementing the SDRAM controller directly on the add-on board could be a much more easy and faster way.

Does every Mac locate its Ram at the same base? Or is it fragmented in a way to provide "24-bit" addressing support?

 

[zigzagjoe]

Hi,

firstly, congratulations on getting the 68060 running on a native Macintosh.
I'm coming from the "other"side (Amiga), but recently acquired an LC475 which I am currently getting familiar with.

One hint regarding the patching of the Mac Roms to get them fully working with the 68060: have you considered looking at the Shape Shifter source code, which is available here: https://aminet.net/package/misc/emu/ShapeShifter_src

Since many decades, Amiga people have been booting classic MacOS using Shapeshifter on a 68060, and I'm sure that the information contained in the sources could be proven to be helpful here.

Keep up the great work!

Oliver

I'm aware of it, though I used Basilisk II more as a touchpoint. I believe they were both written by the same person.

However, most of what Basilisk and Shapeshifter are doing is specifically in regards to paravirtualization/emulation of mac IO space & devices rather than 060 specific changes. On amiga the host OS provides FPSP and IPSP also so most of the other problematic cases are avoided outright since IO is emulated or virtualization of vectors allows for handling them transparently (ie. bus error stuff). Though, seeing how they treat the FPU stack change issues that I've not bothered with may provide a path forward for that.

Btw, if you ask me, disabling access to the on-board RAM and, instead, implementing the SDRAM controller directly on the add-on board could be a much more easy and faster way.

Does every Mac locate its Ram at the same base? Or is it fragmented in a way to provide "24-bit" addressing support?

RAM is typically located at virtual address 0 though that may be either via MMU or DRAM controller registers. Stiching banks is done by the DRAM controller configuration at least on wombat and memc.

Ultimately it wouldn't be easier or faster, IMO: a DRAM controller is not trivial to implement (in hardware) and would require significant tweaking of the ROM. Given the original controller has significant headroom given appropriate DRAM it makes more sense to just tweak those timings. I'd still like to spend some time doing it in a more scentific manner (rather than tweaking and seeing if it works) but it seems that something like a 50% improvement in bandwidth/latency is on the table here.

That improvement is enough that I'm not even sure there's a point in a bus speed cache anymore, but I plan to do so anyways just as it'd be fun to see the difference between 128K and 256K.

 

[Oliver_A]

I'm aware of it, though I used Basilisk II more as a touchpoint. I believe they were both written by the same person.

However, most of what Basilisk and Shapeshifter are doing is specifically in regards to paravirtualization/emulation of mac IO space & devices rather than 060 specific changes. On amiga the host OS provides FPSP and IPSP also so most of the other problematic cases are avoided outright since IO is emulated or virtualization of vectors allows for handling them transparently (ie. bus error stuff). Though, seeing how they treat the FPU stack change issues that I've not bothered with may provide a path forward for that.

I have looked at it, and there seems to be code which is related to adjusting the stackframe handler for 68060, and also FPU related code.

Otherwise, yes, the incompatibilities on instruction set level should be handled by the FPSP/IPSP code from Motorola, which on Amiga, is part of a specific CPU library which loaded on start-up (68060.library).

Does MAC OS handle the MMU in any dynamic way, or is it just for Cache Handling and perhaps static Memory Remapping?

RAM is typically located at virtual address 0 though that may be either via MMU or DRAM controller registers. Stiching banks is done by the DRAM controller configuration at least on wombat and memc.

Thanks, I'm just about getting into the topic of MAC memory handling / system architecture. Are there any datasheets available for Apple's custom chips such as MEMC or MEMCJR?

The idea would be that, similar to the "skip memory test", to skip the MEMCJR initialisation, and just tell the OS: here is XXX amount of RAM located at YYY. Shapeshifter is also doing this, obviously.

Ultimately it wouldn't be easier or faster, IMO: a DRAM controller is not trivial to implement (in hardware) and would require significant tweaking of the ROM.

Well, as it happens, I am actually in the process of designing a new 68060 accelerator board for the Amiga, and I thought to myself: how about using a larger portion of the design, such as the DRAM controller, as a base for a new CPU card for the MAC, which supports both 68040/060, but also a very fast SDRAM interface, just like e.g. the BFG.

Here is a photo of the PCB, revision 0 prototypes will be arriving the next 2 weeks:



(It's a 6 layer PCB)

What do you think? ;-)

Given the original controller has significant headroom given appropriate DRAM it makes more sense to just tweak those timings. I'd still like to spend some time doing it in a more scentific manner (rather than tweaking and seeing if it works) but it seems that something like a 50% improvement in bandwidth/latency is on the table here.

That improvement is enough that I'm not even sure there's a point in a bus speed cache anymore, but I plan to do so anyways just as it'd be fun to see the difference between 128K and 256K.

Sure, that would be the "time period accurate" approach, which is another completely valid approach.

In such a thing as a retro hobby, there is no "right or wrong" just what we like and what inspires us.

Seeing the video on hackaday that "The fastest Macintosh might not be an Amiga anymore", well, perhaps the Amiga community can help here to actually make that happen. I really DO like the LC475, it's a very slick design, and especially the VRAM framebuffer memory is very fast!

 

[Oliver_A]

Something like this:

• Supports 68040 / 68060 CPU (selectable via jumper)
• 128 MB SDRAM, up to 100MHz (either 1x or 2x bus clock)
• CPU clock up to 100MHz (060), 50MHz (040)
• Bus clock to mainboard can be 1/2 or 1/4
• 2MB flash rom for early boot code / patching of MAC OS rom
• "RECOVERY" jumper, if set, system boots normally, but you can flash the flash rom
• Amiga feature: MAPROM - runs MAC OS rom from SDRAM, hardware memory protection & banking

Is this something the classic Mac community might be interested in?

 

[Nixontheknight]

Something like this:

View attachment 93900

• Supports 68040 / 68060 CPU (selectable via jumper)
• 128 MB SDRAM, up to 100MHz (either 1x or 2x bus clock)
• CPU clock up to 100MHz (060), 50MHz (040)
• Bus clock to mainboard can be 1/2 or 1/4
• 2MB flash rom for early boot code / patching of MAC OS rom
• "RECOVERY" jumper, if set, system boots normally, but you can flash the flash rom
• Amiga feature: MAPROM - runs MAC OS rom from SDRAM, hardware memory protection & banking

Is this something the classic Mac community might be interested in?

Hell yeah, if something like this can be done for any 68040 or 68030 Mac, that would be awesome

 

[Oliver_A]

Well, then let's make it a real project now. I start a new thread.

 

[zigzagjoe]

The MMU is mostly used for 24/32 bit mode, cache management, and one or two machines to make memory contiguous or handle framebuffer in DRAM. The MEMC (650/800) is foundational to the system so initialization can't be skipped. Same for the other 040-class machines. You would need to step in somewhere in the sizemem process after it's initialized. Not impossible, but a complication.

I would however gently suggest that you may want to slow roll the hardware in favor of working the 060-centric software challenges first that I've laid out in this thread. Solvable issues, I think, with some difficulty, but I'd recommend tackling those first as otherwise you may end up with some nice hardware that can't be used. Not trying to tell you how to work your projects or implying that's what will happen here but from experience it's been a reoccurring pattern (myself included) where it's "easy" to build some hardware but the software side never happens as it turns out more difficult than anticipated.

What trips folks up is the relatively complex (and ill-documented) software environment and monolithic ROM / OS design. I'm still particularly concerned about the vector table being manipulated by "user" and OS code. If you have some interest in working on the ROM you may want build one of my ISP-SIMM as it supports loading ROM code via USB to an installed ROM module for quicker iteration. It was foundational to the work I did getting the IPSP/FPSP and other ROM modifications developed for this as well as other development work.

On the hardware: you should be able to quiesce the built in RAM controller by pulling on /MI at the appropriate times, but keep in mind these systems do use DMA at least for onboard ethernet and often nubus so DMA / bus arbitration must be appropriately handled by your logic on the card. I've been idly curious if an 060 would have a fit if you set up a 1/3 multiplier, while it's not explicitly supported, I think there's a chance it may work. For a "simple" 040 to 060 adapter that'd provide the best-case as you could pretty easily get max performance out of the CPU while not crippling DRAM/VRAM/ROM accesss as badly.

Onboard DRAM would help 060s but it's less essential as the memory situation on the 68040 macs is far less dire than Amiga with the native 040 bus and performant memory controller supporting bursts/interleave. For a drop in 060 accelerator built-in ROMs as you did would be best as the ROM slots are not typically populated in 040 macs, but you'll have difficulty in that these machines are unable to boot an 060 without modified ROMs. ROM in RAM is not a bad thing to have either - it's been implemented in a few vintage designs. It provides some benefit though it's not mandatory as the hottest ROM routines fit in the 040 caches.

Attached are a number of relevant datasheets/schematics you might find interesting. In my github repository a number of useful software sources are linked including the supermario dump which contains a significant amount of ROM code from the end of the 68K machines (840av).

 

[luRaichu]

What about the 68080?

APOLLO 68080 - High Performance Processor

Apollo Core 68080 is a cisc CPU which is code compatible with the Motorola M68K and ColdFire families.

www.apollo-core.com

 

[CC_333]

What about the 68080?

APOLLO 68080 - High Performance Processor

Apollo Core 68080 is a cisc CPU which is code compatible with the Motorola M68K and ColdFire families.

www.apollo-core.com

Does anyone notice the '8080'?

c

 

[Daniël]

What about the 68080?

APOLLO 68080 - High Performance Processor

Apollo Core 68080 is a cisc CPU which is code compatible with the Motorola M68K and ColdFire families.

www.apollo-core.com

Unless they have developed it in the meantime, I believe the Apollo core does not have a functional MMU.
From what I understand, that's not a problem on the Amiga platform, but it's a dealbreaker for the Macintosh.

I also wouldn't be surprised if there are more idiosyncrasies on that core that present no problems for Amiga use, but would absolutely be a roadblock for Macintosh use.
It is being developed with the sole purpose of accelerating Amigas, after all.

 

[cheesestraws]

It is being developed with the sole purpose of accelerating Amigas, after all.

it's basically bad 68k fanfic, let's face it

 

[Oliver_A]

The problem with the Apollo Core is that it neglects compatibility where necessary, and adds features which do make sense from an FPGA implementation POV, but will always remain proprietary. It is aimed at creating a new platform, using a previous OpenSource recreation of the AmigaOS as a base.

But, what you actually can do is running Shapeshifter on the Vampire V4 FPGA boards and boot MacOS.