MiSTer FPGA Forum

Would a 68030/040 CPU be possible in the Minimig core?

Possible? Yes. But someone has to write it

It certainly should be possible for a 68030 or 040 Amiga implementation to fit on the FPGA on the DE10-nano, however (having had only the briefest look at this a while back) putting that in the MiniMig on MiSTer is another matter. Wouldn't say never, but there seems to be more interest in hybrid-emulation now also which probably steals any desire for anyone to put in the effort to try.

As discussed earlier, the 68020 implementation in the Minimig core on MiSTer is roughly equivalent to a 68030 at ~50MHz in processing speed.

68030 didn’t really add much on the instruction set front, and I don’t think I’m aware of any software that *requires* the 030 instruction set but does not run on an 020.

The main difference would be to implement an MMU and an FPU (external chips on the 030, included with the high-end model of the 040), that would make certain operations like e.g. raytracing potentially faster. But if you want speed, you’re better served with an emulator running on a modern computer. (Sure, I know there are probably some very late Amiga games — e.g. the Doom clones — that could benefit a little bit from it)

Doesn’t seem worth the effort — and as others already mentioned, the hybrid approach is probably what you want in that case anyway, since the speed-up would be massively more impactful from using the ARM CPU directly.

From what I have been told, the FPGA used for the MiSTer is the same FPGA used by the Vampire 4 stand alone and expansion cards. These run at up to 200 mips. They have their own custom 68080 CPU, not an actual official Motorola CPU, but now owning both a Vampire 2 and a Vampire 4, I must say what they have done is pretty impressive. I generally would have liked them to make it possible to just run it as different cores, especially support for 68000 and 68020, since that has already been implemented in open source code. But what is impressive with the 68080 is that they have implemented all the CPU instructions for 030, 040 and 060. Even the different FPU calls have been implemented into their special FPU implementation.

I must say that one CPU that is (in theory) compatible with all Amiga CPUs does seem more useful than having to jump between CPU types. Having both options though would also be nice.

But my point is even a 060 should be possible on this FPGA. Not sure if its possible on the MiSTer though because it sounds like the many nice features we have on the MiSTer at this point has ended up using half the FPGA, options like filters, scaling and other stuff. But even the PSX core is able to fit using just half the FPGA so, that might not be the main issue as long as the FPGA logic is optimized for size.

But what does a fictional “68080” CPU buy you? You are not talking about timing/cycle accuracy at that point, so why not just make it go as fast as possible by handing it off to a CPU emulator on the ARM? (And I know this isn’t a productive discussion, just pointing out the absurdity of what the Vampire is doing — the question is rhetorical)

limi wrote: ↑Fri Mar 18, 2022 8:03 am But what does a fictional “68080” CPU buy you? You are not talking about timing/cycle accuracy at that point, so why not just make it go as fast as possible by handing it off to a CPU emulator on the ARM? (And I know this isn’t a productive discussion, just pointing out the absurdity of what the Vampire is doing — the question is rhetorical)

That is the case with all CPUs above the... pretty sure its even the 68000. They all rely on following whatever the speed of the CPU is. Which is why on the MiSTer when you go with the 68020 CPU type, it simply goes as fast as possible. Timing is not really relevant, because games that takes advantage of this CPU has to have taken this into account.

Arguably it was always bad coding when a game did not expect/support different CPU speeds, but that is one of the reasons the Amiga ran into compatibility problems when you got an Amiga 1200 and tried running Amiga 500 games.

Timing issues is overall not especially relevant here. Going as fast as possible is quite fine for most the software and games. Its already being looked into to emulate the CPU on the ARM. It would be a relevant speed boost, but mainly because the current core does not run as a 030, 040 or 060 and run it as fast as they might run. Its really only the 68000 that needs running at its exact speed... and only when and because of bad code as I already mentioned.

My point was mainly that 030, 040 and 060 are all possible on the FPGA we have currently, and if the FPGA was used to its fullest, we would not have anything to gain by running the CPU on the ARM CPU using emulation. Currently there is performance to gain that way though.

The reason the 68080 is as compatible as it is, is because timing is not that critical. Especially when using software like WHDLoad. On the MiSTer though, the nice thing is it will always be an option. One example is Amiga CDTV. It can be emulated, but the Amiga CDTV is quite firm about the CPU having to be a 68000, so on an Amiga 1200 even using some Amiga emulation tricks, you cannot run CDTV games, but on the MiSTer when using the 68000 CPU, you can run some of those games. Of course CD32 games does need the 020 CPU.

From what I understand timing is actually important for WHDLoad. That's why many games have problems.

akeley wrote: ↑Fri Mar 18, 2022 9:45 am From what I understand timing is actually important for WHDLoad. That's why many games have problems.

Yes, it is. Its why I wrote "not that critical". Tricks are used to try to make it more compatible despite the games requiring and expecting a much slower CPU. There is a lot of compatibility software that uses tricks like disabling CHIP RAM, CPU cache and other things. But with those games there is no good solution other than going with an original 68000 CPU set at the exact speed these games expect it to have.

For the majority of the WHDLoad games though, they do not care whether the Amiga is 7mhz or 120mhz. Or whether its CPU a 040, 060 or 080. I have seen many argue 060 is the least compatible of the actual Amiga CPUs, I am not well versed in exactly what makes 020 or 030 more compatible, but I suspect it might just be down to how its more likely to slow down these CPUs over slowing down an 060 for these special cases of old Amiga games that cannot handle when the CPU is too fast.

With the MiSTer we have the luxury of not having to chose one or the other. We can have all the Amiga CPUs... or at least there should easily be room for 1 or 2 more Amiga CPUs being supported.

I have to say that Mister minimig core gives me less troubles than my two real Amiga

Real big box Amigas were expensive in their day, and increasingly rare to find in a decent condition. Just for conservation's sake I'd love an accurately represented A3000 on MiSTer. Sure they're an obscure niche, but isn't that what MiSTer is about?

I'm more interested that Motorola 68030 would be a step in the road towards Atari Falcon.

..and some early SGI gear, and other old UNIX stuff.

I'm all up for having all the possible Amiga configs, but I'd rather see the "bottom" ones perfected first. It's the same as with ao486, not a question of "one or the other" (of course we want it all) but general priorities. I think it's better to have one thing as perfect as possible first, instead of many which are "mostly" accurate.

In this context, I'm not sure how much better A1200 side could be improved because I don't know much about its innards...it goes back to that accurate-timings issue, whih many will say is not relevant, buit I have a strong suspicion it maybe actually is. There are games such as Trolls which are definitely affected by that, and also other examples keep popping up (eg Dynamite Dux) though how much is that related to Minimig itself and how much a general WHDLoad problem is an open question.

There's also CD32 which I'd rather see sorted before any high end Amigas. The latter, from what I see being talked about, could be a real rabbit hole re compatibility and accuracy, due to so many configs and quirks present.

akeley wrote: ↑Fri Mar 18, 2022 12:05 pm I'm all up for having all the possible Amiga configs, but I'd rather see the "bottom" ones perfected first. It's the same as with ao486, not a question of "one or the other" (of course we want it all) but general priorities. I think it's better to have one thing as perfect as possible first, instead of many which are "mostly" accurate.

In this context, I'm not sure how much better A1200 side could be improved because I don't know much about its innards...it goes back to that accurate-timings issue, whih many will say is not relevant, buit I have a strong suspicion it maybe actually is. There are games such as Trolls which are definitely affected by that, and also other examples keep popping up (eg Dynamite Dux) though how much is that related to Minimig itself and how much a general WHDLoad problem is an open question.

There's also CD32 which I'd rather see sorted before any high end Amigas. The latter, from what I see being talked about, could be a real rabbit hole re compatibility and accuracy, due to so many configs and quirks present.

For CD32 there are some emulation options for the Amiga, which is obviously not optimal and the compatibility varies. But its just worth keeping in mind because it is possible to get a pretty good CD32 experience with the MiSTer core.

When it comes to the timing issues, the 020 on the MiSTer is not trying to have the original Amiga 1200 speed, its running as fast as possible, so to get the most correct timings for games, it should be the 68000 CPU that is used.

I do think it might be relevant to a speed option for the Amiga cores, making it possible to run each CPU option at different speeds, like its possible with the AO486 core to select different CPU speeds. But not sure what exact games and such might make it relevant, but that is something that would be easier to test once it was an option.

Duffygag wrote: ↑Fri Mar 18, 2022 10:42 am I have to say that Mister minimig core gives me less troubles than my two real Amiga

Yeah... I have an Amiga CDTV, CD32 and 1200 with various expansion cards, but the MiSTer still just makes it so much simpler to do Amiga stuff in many ways. Not needing to use different SD or CF cards, but instead just having HDF images. WinUAE is also useful when it comes to running Amiga stuff in a simple way, but the MiSTer does it even simpler and I do think it might be more compatible in some ways and with some of the settings on WinUAE like setting up RTG it has to be very specific how you do that. With the MiSTer there are simple floppy disks with the drivers needed to have RTG and such. Also that Shared folder is very useful.

Caldor wrote: ↑Fri Mar 18, 2022 12:18 pm For CD32 there are some emulation options for the Amiga, which is obviously not optimal and the compatibility varies. But its just worth keeping in mind because it is possible to get a pretty good CD32 experience with the MiSTer core.

When it comes to the timing issues, the 020 on the MiSTer is not trying to have the original Amiga 1200 speed, its running as fast as possible, so to get the most correct timings for games, it should be the 68000 CPU that is used.

Well, I can have a "pretty good" - or more - CD32 experience anytime using emulation. It's the same in regard to high end Amigas. But that's not what we're all about here...

I know about using 68000 but tbh that's a bit of half-measure (if the game in question would behave ok on original 1200), and also in specific cases, like the aforementioned Trolls, it's the AGA version of the game is affected. I agree about having some sort of speed-limiter could maybe be a good idea, perhaps it'd help with at least some of these problematic cases.

As for using Minimig vs real Amigas, well, of course the former method is more convenient, it's a given. Which is why my A500 is mostly shelved these days (the ol' girl with ACA500+ sticking out of the side takes a lot of space too). But convenience is not really what we're discussing here...

akeley wrote: ↑Fri Mar 18, 2022 12:40 pm

Caldor wrote: ↑Fri Mar 18, 2022 12:18 pm For CD32 there are some emulation options for the Amiga, which is obviously not optimal and the compatibility varies. But its just worth keeping in mind because it is possible to get a pretty good CD32 experience with the MiSTer core.

When it comes to the timing issues, the 020 on the MiSTer is not trying to have the original Amiga 1200 speed, its running as fast as possible, so to get the most correct timings for games, it should be the 68000 CPU that is used.

Well, I can have a "pretty good" - or more - CD32 experience anytime using emulation. It's the same in regard to high end Amigas. But that's not what we're all about here...

I know about using 68000 but tbh that's a bit of half-measure (if the game in question would behave ok on original 1200), and also in specific cases, like the aforementioned Trolls, it's the AGA version of the game is affected. I agree about having some sort of speed-limiter could maybe be a good idea, perhaps it'd help with at least some of these problematic cases.

As for using Minimig vs real Amigas, well, of course the former method is more convenient, it's a given. Which is why my A500 is mostly shelved these days (the ol' girl with ACA500+ sticking out of the side takes a lot of space too). But convenience is not really what we're discussing here...

I think you misunderstood. I meant on the MiSTer you can run some Amiga software that helps run CD32 games. Obviously if you go and use WinUAE, you can do pretty much anything. I have actually made a boot disk that can load CD32 games based on simply selecting a CD32 CD image from the shared folder.

Given the CD32 is based on Amiga 1200 hardware, its mostly not emulation being used. Still enough to be a problem though obviously and as I said, I only mention it to let people know this is an option.

Caldor wrote: ↑Fri Mar 18, 2022 12:44 pm I think you misunderstood.

Could be. I was able to run some CD32 games on MiSter using hdfs, but without CD sound I think... Anyway, I guess this is something for another thread.

68040 is causing lot of compatibility issue for the 68000 software.
so better 68000 or 68030 then 68060

pepito wrote: ↑Mon Mar 21, 2022 7:11 am 68040 is causing lot of compatibility issue for the 68000 software.
so better 68000 or 68030 then 68060

Anything wrong with the 68000 as it is? I think the only FPGA 68k CPU I have heard about being in development is the 68030, but not sure if it was on the MiSTer or not. It probably does not matter much. I wonder if its possible to code the FPGA logic so that it does not have to take up a full CPU logic space for each CPU or if its possible to just enable or disable parts of it. I guess that might be part of why Apollo made their 68080 CPU so that its one CPU that supports all the CPU calls.

With FPGA logic one of the things I do know about it, is that you have to take the physical space of it into account. When you code it, you select an actually area of the physical chip to place it, and there has to be connections between the different parts that makes sense for a chip. But I am thinking it ought to be possible to code it so that there is a 68030 register part that is on top of the 68000 part, but which is possible to disable or enable based on the CPU type selected. Otherwise, a lot of space could end up being wasted. I guess another option would be to make different cores. One that focuses on 030, one that focuses on 040, 060 etc. etc. It would just be a bit less user friendly.

Caldor wrote: ↑Mon Mar 21, 2022 7:41 am With FPGA logic one of the things I do know about it, is that you have to take the physical space of it into account. When you code it, you select an actually area of the physical chip to place it, and there has to be connections between the different parts that makes sense for a chip. But I am thinking it ought to be possible to code it so that there is a 68030 register part that is on top of the 68000 part, but which is possible to disable or enable based on the CPU type selected. Otherwise, a lot of space could end up being wasted. I guess another option would be to make different cores. One that focuses on 030, one that focuses on 040, 060 etc. etc. It would just be a bit less user friendly.

The problem there is, that any runtime configuration option lengthens combinatorial paths and therefore decrease the maximal clock frequency of the design. That's why you usually have thousands of configuration options on an emulator, but only a few on FPGA implementations. At some point, it is more efficient to do mayor configurations at compile time (elimination all unused code) and spread them over multiple cores, e.g. minimig0X0.

A separate core for A500, A1200, A3000 etc. wouldn't feel unfriendly to me. I'd rather have that than a single core with many toggles.

I do really hope someone integrates Red Book Audio into the core so that CDTV games can be loaded with sound, and pave the way for CD32. It would be nice to thus have the core consolised for playing the disc games. I am still surprised nobody has added Red Book Audio support yet, especially with it being in other cores which can be used as a reference.

I have two Vampire cards that haven’t received significant updates for years, and compatibility issues are plenty. If I could easily just swap out 68080 and "SAGA" on those with tg68 and Minimig, I’d use them a lot more.

I’d love more work put into a faster 680x0 core. Hybrid is all well and good, but the latency and timing on a real core will be much tighter. I also prefer real logic.

kolla wrote: ↑Fri Mar 25, 2022 2:35 am I have two Vampire cards that haven’t received significant updates for years, and compatibility issues are plenty. If I could easily just swap out 68080 and "SAGA" on those with tg68 and Minimig, I’d use them a lot more.

Does seem like it would be nice to have the option, but given the Vampire cards does not have an ARM component, I am not sure it will ever be easy to swap out. Although I guess a full core could be made that supports 68000 or 68020 and you would then have to use the Vampire tools to load that core from the SD card or something every time you wanted to move back and forth between the two.

But I guess there would not be much left of the Vampire card after making this switch. What does tg68 or Minimig provide? It does not seem like Vampire is meant to do floppy drive or such on the core and Minimig is not designed to integrate with the hardware.

The MiSTer is overall still the most useful Amiga to me, because it has so much going for it. Its so easy to use different HDF files, doing different Amiga setups while the Vampire 4 f.ex. is getting a lot of development just to get "multiboot". Its nice to have one Amiga configured to boot several different Amiga OSes, but... it feels a bit silly how complicated that is for the developer to setup if it could instead be made possible to boot from HDF files and just select which ones to boot from. Only problem I have with using the MiSTer as an Amiga is its lack of support for real floppy disks or copy protected floppy image types. But the support for RTG, the shared folder and such makes it very nice to work with I think.

foft wrote: ↑Fri Mar 25, 2022 8:09 am I’d love more work put into a faster 680x0 core. Hybrid is all well and good, but the latency and timing on a real core will be much tighter. I also prefer real logic.

Yeah, would be nice if maybe there was a way to improve that latency. I have not seen it affect games, but it certainly affects the Workbench UI. If the Vampire cards are any indication it does seem like it should be possible to get the MiSTer to run Amigas faster. I do think we will need 030, 040 or 060 to make it run faster... and I am also unsure what they did to get 080 to run this fast... it might be that part of the reason this happens is because they made changes to the chip in the FPGA logic. It does seem pretty certain that a 68000 or 68020 would not run at 080 speeds if a core was made to for those CPU types.

It's probably important to point out that the reason the 060 was faster than the 040 was faster than the 030 was faster than the 020 was down to significant changes in both architecture (multipipelining/branch prediction, cache, etc.) and faster clock speeds (thanks to improved fabrication processes).

None of that is remotely important anymore in terms of raw speed - it is trivial to clock a virtual 68000 to achieve performance levels 100x the fastest hardware 68060 these days. The only time processor _architectures_ matter in the modern world comes down strictly to instruction set, and given the '020 was a) the lowest common denominator in terms of the A1200 and b) there's virtually zero *useful* additional instructions in the 030/040/060 (again in terms of modern parlance), there's just no reason at all to go beyond an (insanely fast/overlocked) 020. There just isn't enough software available with 030/040/060-specific instructions to bother with, and what very little there is can be recompiled or patched as needed for compatibility.

No reason? Please do speak for yourself when you express such sweeping qualifications as fact. Apart from big box Amiga, there are Macs and Atari systems that would be brought much closer to a MiSTer implementation with a fully featured 68030 or 68040, preferably at realistic period appropriate speeds.. but that's just my take.

Caldor wrote: ↑Fri Mar 25, 2022 10:01 am the Vampire cards does not have an ARM component, I am not sure it will ever be easy to swap out.

No need for ARM, there’s the FPGA and it can run another 68k core for the Minimig firmware, take care of I/O, menus etc. This is how it works on the TC64 already

kolla wrote: ↑Fri Mar 25, 2022 6:52 pm

Caldor wrote: ↑Fri Mar 25, 2022 10:01 am the Vampire cards does not have an ARM component, I am not sure it will ever be easy to swap out.

No need for ARM, there’s the FPGA and it can run another 68k core for the Minimig firmware, take care of I/O, menus etc. This is how it works on the TC64 already

Fwiw the Vampires 080 core is multi threaded already .. just the OTHER thread is reserved for internal uses.. (ie. memory management etc)..