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?