My MiSTerFPGA Macintosh Cores

[danifunker]

Hi Everyone! I wanted to provide a bit of an update on my emulation journey.

After several months of deep development cycles and a lot of use with AI and other research tools, I've released a couple of working Classic Macintosh color cores and a couple of cores that don't seem to be working properly (I may or may not continue them).

If you have a MiSTerFPGA and are interested in looking at these cores, I've crossposted the threads from the MiSTer FPGA forum:

Macintosh II Core - https://misterfpga.org/viewtopic.php?t=10456 (currently unstable due to many issues)
Macintosh LC Core - https://misterfpga.org/viewtopic.php?p=109320 (Most mature core)
I did try creating the LCII core, but that system doesn't perform as well as the Original LC from the video perspective, so I used the CPU to make the last core, but am not actively working on the LC2 core anymore.
Macintosh IIvi Core - https://misterfpga.org/viewtopic.php?p=109750#p109750 (works but seems not performant at the time of the post)

Thanks for all the help 68kmla! I wouldn't be as far without your support.

 

[Melkhior]

Nice. AI seems to be helping push the hobby further - though the implementation you use (I think this one) is targeting functional implementation, and does not implement a clean MC68030 bus unfortunately (... as I wondered if I could use it as a core in the IIsiA7 Mini to replace the onboard MC68030, which would be the ultimate test for a core).

I need to figure out how to leverage AI to help with my own stuff...

 

[demik]

Nice progress! @Melkhior it is not cycle accurate as well IIRC. But that's the best we got for now

 

[Melkhior]

Nice progress! @Melkhior it is not cycle accurate as well IIRC. But that's the best we got for now

As a post-68000 Mac & workstation guy, I *don't* want cycle accurate (when it comes to instruction timings). Cycle accurate is great for platform with timings-dependent software, like 8/16-bits systems & arcades, but it's not required for machines with more abstracted software layers. Also it might limit the clock speed - the 68K30L from Suska doesn't clock much beyond 20 MHz. It's likely it could be clocked faster with only a small number of instructions made to use more cycles - cycle accuracy imposes sever limitations on what you can achieve.

What I want are functional replacements that can be timing-accurate at the boundary - AFAICT, the 68K30L respected the bus timings so in theory could be a drop-in replacement for a MC68EC030 (but w/o MMU, useless in a Mac). The idea being that if you replace just the one chip in a real system, it still works. For not the CPU used in those projects doesn't have the proper bus that I can see (at least bus mastering is missing, which is a no-go for more complex machine), but it's a great proof-of-concept.

BTW, there's a full-blown MC6888[12] now apparently - and it looks like what I want, but it appears to big to fit in the current IIsiA7 Mini :-( AI is enabling a lot of new hardware, but an unfortunate side-effect is that it makes the efforts of those writing by hand a bit pointless...

 

[demik]

Thanks for the explanation, very insightful as always.

I do agree with it, maybe not with the pure 68000s, a lot of embedded stuff relies on well placed nops. FX68k is just awesome work in that regard.

Does TG68k has MMU support now ? (Sorry, just following FPGA stuff from a distance). Last time I looked at it it was limited to a 16bit bus as well

@danifunker I'm guessing it's only 24bit mode for now ?

 

[Melkhior]

Does TG68k has MMU support now ?

Upstream doesn't (yet that I found - I'm not even sure if upstream is maintained formally?), but there's a ton of AI-assisted work to add MMU and even FPU (which is a bit redundant as a FPU already exists as I linked... not going to complain about choice )