Re: New pmap module for m68k
Romain Dolbeau <[email protected]> Thu, 13 Nov 2025 19:06:06 +0100
| Newsgroups | gmane.os.netbsd.ports.m68k |
|---|---|
| Message-ID | <CADuzgbpLVs=onQ+mA_CQim-Ee3RWe1DxaSHG6kS1Hu0WYoco7Q@mail.gmail.com> |
Le jeu. 13 nov. 2025 =C3=A0 18:47, Jason Thorpe <[email protected]> a =C3=A9cr= it : > Yah, I spent a little time looking at the 68040=E2=80=99s arbitration and= cache coherency protocols for another project (I have a series of 68k home= -brews in the works), but I haven=E2=80=99t 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=E2=80=99re 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 te= rribly 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, --=20 Romain Dolbeau