Port-m68k archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: New pmap module for m68k



Le jeu. 13 nov. 2025 à 18:47, Jason Thorpe <thorpej%me.com@localhost> a écrit :
> Yah, I spent a little time looking at the 68040’s arbitration and cache coherency protocols for another project (I have a series of 68k home-brews in the works), but I haven’t spent much time working out all the details, even for my simple use case.

Well, same here, but I did try to figure out how I should wire it all
up. It's not obvious.

My target is simple: real silicon for the CPU(s), and a FPGA on the
bus handling everything else to minimize design issues - if everything
is gateware, everything is fixable :-) And I already have tested the
CPU bus protocol in a FPGA with device-oriented boards (e.g.
<https://github.com/MelkhiorVintageComputing/QuadraFPGA> connects to
the '040 bus.). Hence my choice of MC68040V, the lack of an FPU is
minor compared to the simplicity of 3V3 everywhere. The PGA version is
also not sought after, so can be had at a decent price - the socket is
not readily available, but can be made with a normal 68040 socket, a
dremel and three extra pins.
Downside of this approach is memory read latency is not great, needing
to cross from the CPU clock domain to the highest clock domain
handling the DDR3 controller, and back (write can be fire-and-forget
in a FIFO). Also true for reading from any device registers to the
CPU, though DMA entirely inside the FPGA is faster than on vintage
systems.

> Well, the major downside of 68060s is that they’re pretty hard to come by, comparatively.

Yes, the Amiga crowd is driving the cost way up - and they were
uncommon to begin with. However, MC68LC060 are still somewhat
affordable. My understanding is that NetBSD supports FPU emulation on
the MC680LC040/MC68040V (though of course not on the buggy XC68LC040)
and on the MC68LC060, so they are enough for a SMP proof-of-concept.

> It is a functional model.  Adding dual-CPU support to it should not be terribly difficult if the goal is to prep software.

I'd say having true (as in, using mt-tcg to get more performance)
dual-CPU (or more!) support in QEmu and working by NetBSD would first
help for rebuilding software. If it can be made to work, then it would
motivate people like me (and you, apparently :-) ) to do a 'real
silicon' variant just for the fun of it (and bragging rights, maybe
;-) ).

Cordially,

-- 
Romain Dolbeau


Home | Main Index | Thread Index | Old Index