68060 in NeXTs?

[Andreas]

as far as i understand this is an adapter for plugging a 68060 into the regular 68040 slot. Is this something useful for the NeXT? It seems to run for Amigas

https://amiga.technology/2021/01/18/68040-to-68060-upformation/

[cuby]

The 68060 only implements a subset of the 68040 instructions - see appendix C in the 68060UM and the Porting software from an MC68040 to an MC68060 document.

Motorola provided a special software package that supported the emulation of the missing instructions, M68060SP, but I can't find this online any more. It was available on the old Motorola BBS.

I think Hatari has a 68060 emulation, so it might also be possible to configure Previous to emulate it? Would be interesting to see how soon the firmware crashes :-).

[cuby]

Motorola provided a special software package that supported the emulation of the missing instructions, M68060SP, but I can't find this online any more.

...but at least there's a modified copy of M68060SP for Amigas on github and a copy of the code in the Linux kernel sources

[andreas_g]

I did not test this in Previous but it should be quite easy to modify Previous to simulate the 68060. Anyway I see no chance to run NeXTstep on such a configuration. It would require to modify the kernel with M68060SP support and maybe some other changes.

[cuby]

Anyway I see no chance to run NeXTstep on such a configuration.

Agreed. The only way this might work would be to implement a  hypervisor that catches and emulates the unimplemented instructions.  This would be quite slow and I'm not sure if this would work for all instructions.

[MrPix]

It should, however, be possible to use the 68060 as a co-processor or DPU in a 680X0-based system.

[MrPix]

I thought on this a little more and came up with the following two options:

Adding a 68060 as a second CPU on an interposer card that goers between the 68040 and the mainboard. It could /BR and be /BG'd to co-process with the original CPU. Any instruction incompatibilities would have to be dealt with. That said, GCC should be able to use compile flags to target the '060 so specific tasks could be run on it, then control returned to the '040.

This is a fiddly and fraught option, as if the '060 has reason to hang the whole machine will freeze.

The second option is to have the '060 (or ANY '0X0) as a data processing unit, or DPU. In its simplest form this could be a dumb card in a Cube slot, ignoring the 256MB allocation and only using the 16MB space in the top slot for simplicity. The CPU would have its own memory, "ROM" and soft address decoder. A CPLD would hold the guest CPU in reset, and the main CPU could write the address decoder table into a RAM chip, load a boot program into coreN+$0 through dual port SRAM, and have the CPU copy that into private memory in pages. Once the code the CPU is going to run is loaded, the address decoder can be reconfigured to place the "ROM in SRAM" at coreN+$0 by rewriting the decoder SRAM. The CPU can be reset and it will happily run whatever code you give it, and use the dual port SRAM as an IO area to exchange work and results with the main CPU.

This would be abstracted, but an incredibly powerful system. The CPU doesn't even have to be Motorola. Also implied by the "coreN" references is that you could have a 68060/75, or you could have 16x 68SEC000/20 in a 4x4 array. This would have more throughput for certain types of very multi-threaded tasks.

Also, it would be spendy, because Dual Port SRAMs have gotten ridiculous of late.

Thoughts?