FPU for the MiSTer Minimig core

[Caldor]

I have been looking into FPU options for a long time. Overall it does not seem to be that important on the MiSTer, because even if we implement FPU for the Amiga of AO486 core, the CPU speeds are not fast enough to run the types of games or software that makes use of FPU.

But I might be wrong and either way its still interesting if we could get FPU support, just for the sake of it. Many MiSTer cores are based on emulators, especially open source emulators. So my idea is that looking into software FPU emulators, we could probably find a way to add FPU support to the Minimig core in some way.

It could probably be put directly in the core, but first I hope to look into using the existing ARM FPU. I found an Amiga software FPU solution that is open source:
https://github.com/nonarkitten/femu

I am thinking it should be possible to then implement this into MiSTer Main, making it capable of translating Amiga FPU calls to ARM FPU calls.

FEMU is written in Assembly and I already had some trouble learning C given how my main programming language is C#, but the main thing to understand about C coming from C# is pointers and I got some help with that on the MiSTer Discord. MiSTer Main is written in C. Assembly is quite different though from C and C#. It was never meant to be humanly readable, I think its even called machine code. Otherwise it at least is very close to machine code, which also is why its as effective and fast as it is. If you want code to be highly optimized and with a small as possible footprint, Assembly is the way to go.

FPUs have always been problematic though. Whether its x86 or 68k, there are several different types of FPUs and each of them having different calls and operations that does thing differently. Same with ARM for that matter... well, at least an ARM FPU is different from x86 and 68k FPUs, but I am pretty sure different ARM FPUs also have different calls and operations.

I am making this post because I hope to find others interesting in following progress for this and hopefully also helping in some way?

I hope to find some Amiga software that is used to test FPUs, that might help test things. But another shortcoming for me is I am not experienced with FPGA cores and how to develop them, or how to make them communicate with MiSTer Main. I have begun looking into it though and have done a few experiments already. I helped a bit with the PSX and AO486 core. Well, with the PSX core it was on the MiSTer Main side, but I did get a change added to the AO486 core as well. It probably could not be any simpler than the change I added, but it worked and made a meaningful change adding support for more disk image types. But still I have next to no experience on the core side and I hope someone might be able to help add a way for the 020 core to have a special version of it that supports FPU calls. The 020 supports the MC68882 CPU expansion, so if the hardware sees it as that, that ought to be a good starting point.

If no one can help do that, it will probably be a long time before I can begin the work in any way. I will try to keep building up my knowledge of MiSTer development both on the Main and the FPGA side and eventually I might be able to do something like this. First I think I will look into CD audio support. That is what I helped with on the PSX core a bit.

[CeeDeeVee]

Quick reply as I need sleep and this could be a long convo. Assembly language is absolutely designed to be humanly readable, although you may find many people using the terms ASM and machine language/code interchangeably it's not the same. However, it is close because ASM is a low level language that is 'assembled' (rather than compiled) directly to machine code. WARNING, programming in assembly is incredible rewarding and addictive, start this journey at your own risk! In all seriousness ARM asm is actually really nice, as it's the spiritual successor to 6502.

On the other point, having FPU on minimig is very interesting. I'm sure it would have practical uses for current users as well as preservation value, but I'm not sure whether it would be best in the FPGA. Not trying to start that whole political argument, just questioning whether it needs to be on the ARM.

[LamerDeluxe]

I've programmed a lot of 68K assembly (NOT, as it is often misnamed, 'assembler', that is the application that converts your opcodes to machine code). I've also programmed some 6502 (VIC-20 machine code and Atari Lynx in assembly).

I enjoyed it a lot, you are really controlling the CPU directly and preferably the custom chips as well. For me the trick is to add a lot of comments behind the opcodes so the code is easier to read.

I think the Amiga hybrid emulation project also includes the FPU. Not sure if the FPGA is too slow, as the Vampire cards are apparently quite fast (assuming they include the FPU).

[Neocaron]

WIth the recent 50% OC on the ARM which I now use in my daily build, I'm sure using the arm for that purpose could be a great experiment!

[Caldor]

I've programmed a lot of 68K assembly (NOT, as it is often misnamed, 'assembler', that is the application that converts your opcodes to machine code). I've also programmed some 6502 (VIC-20 machine code and Atari Lynx in assembly).

I enjoyed it a lot, you are really controlling the CPU directly and preferably the custom chips as well. For me the trick is to add a lot of comments behind the opcodes so the code is easier to read.

I think the Amiga hybrid emulation project also includes the FPU. Not sure if the FPGA is too slow, as the Vampire cards are apparently quite fast (assuming they include the FPU).

Yes, the hybrid emulation project does include FPU. I was thinking of a solution that only did the FPU in the emulation. The hybrid emulation project is really nice but it does slow down the UI of the workbench for some reason. I am not sure why, but I guess its because latency is added, possibly between the ARM emulated CPU and the chip RAM that I think connects to the FPGA. Or just overall it might add a bit of latency between the ARM emulated CPU and all the other chips.

But given that emulator should be open source, I guess it also has FPU code. But I am thinking if it is to emulate the FPU that supports the 68020 then I need the code for that FPU. Vampire does include FPU now, so it certainly should be possible in the FPGA, I am just more of a software developer so I think its more feasible for me to do it on the ARM side, but also I am thinking it wont even really be emulation as what I hope to do is map the different FPU calls to the ARM FPU calls.

Quick reply as I need sleep and this could be a long convo. Assembly language is absolutely designed to be humanly readable, although you may find many people using the terms ASM and machine language/code interchangeably it's not the same. However, it is close because ASM is a low level language that is 'assembled' (rather than compiled) directly to machine code. WARNING, programming in assembly is incredible rewarding and addictive, start this journey at your own risk! In all seriousness ARM asm is actually really nice, as it's the spiritual successor to 6502.

On the other point, having FPU on minimig is very interesting. I'm sure it would have practical uses for current users as well as preservation value, but I'm not sure whether it would be best in the FPGA. Not trying to start that whole political argument, just questioning whether it needs to be on the ARM.

Well, with humanly readable I mean that its based on words. Like in C you say "int C = 3" or "if(variable is not null) dosomething(); else dosomethingelse()". Otherwise you could just as well argue machine code to be humanly readable. Some coding languages goes even more into using words for their code than C and C# does.

I do think it would be best making the FPU in the FPGA. Its just that my experience with coding the FPGA is less than minimal.

[LamerDeluxe]

I've programmed a lot of 68K assembly (NOT, as it is often misnamed, 'assembler', that is the application that converts your opcodes to machine code). I've also programmed some 6502 (VIC-20 machine code and Atari Lynx in assembly).

I enjoyed it a lot, you are really controlling the CPU directly and preferably the custom chips as well. For me the trick is to add a lot of comments behind the opcodes so the code is easier to read.

I think the Amiga hybrid emulation project also includes the FPU. Not sure if the FPGA is too slow, as the Vampire cards are apparently quite fast (assuming they include the FPU).

Yes, the hybrid emulation project does include FPU. I was thinking of a solution that only did the FPU in the emulation. The hybrid emulation project is really nice but it does slow down the UI of the workbench for some reason. I am not sure why, but I guess its because latency is added, possibly between the ARM emulated CPU and the chip RAM that I think connects to the FPGA. Or just overall it might add a bit of latency between the ARM emulated CPU and all the other chips.

But given that emulator should be open source, I guess it also has FPU code. But I am thinking if it is to emulate the FPU that supports the 68020 then I need the code for that FPU. Vampire does include FPU now, so it certainly should be possible in the FPGA, I am just more of a software developer so I think its more feasible for me to do it on the ARM side, but also I am thinking it wont even really be emulation as what I hope to do is map the different FPU calls to the ARM FPU calls.

I didn't know about the UI slow down problem, I hope that can be solved somehow.

Interesting idea to have the ARM CPU just act as an FPU co-processor. I used to have an 68882 in my Amiga, if the communication interface it used could be replicated in FPGA and relayed to the ARM CPU, that would be an interesting option.

Good to know a fast FPU would be possible on the FPGA. It would probably be a massive job to create it and might take up a lot of space.

[Caldor]

I didn't know about the UI slow down problem, I hope that can be solved somehow.

Interesting idea to have the ARM CPU just act as an FPU co-processor. I used to have an 68882 in my Amiga, if the communication interface it used could be replicated in FPGA and relayed to the ARM CPU, that would be an interesting option.

Good to know a fast FPU would be possible on the FPGA. It would probably be a massive job to create it and might take up a lot of space.

Yes, that is part of the benefit I think, if the ARM FPU could be used, it would probably also save quite a bit of FPGA space. Although from what I hear, space should not be that big a problem for the Minimig core.

[kolla]

TG68 doesn’t support FPU, so software emulation aka FEMU it is (and FEMU already works). You first need a way to execute native ARM code from the Amiga side, and then replace the math lib stuff in FEMU with ARM code. And how the RAM access would be taken care of, I don’t know.

[Caldor]

TG68 doesn’t support FPU, so software emulation aka FEMU it is (and FEMU already works). You first need a way to execute native ARM code from the Amiga side, and then replace the math lib stuff in FEMU with ARM code. And how the RAM access would be taken care of, I don’t know.

Well, my idea was to use FEMU to know what FPU calls are expected to be supported by the Amiga hardware, and then try to see if I could put this into MiSTer Main, and have it translate the calls that would come from the Amiga core to MiSTer Main, have it translate these calls to the ARM FPU, get the response from the ARM FPU and translate those responses back to Amiga FPU responses.

So its not that I mean to use FEMU as emulation software on the Amiga side, but to use it to help figure out how an FPU is supposed to work on the Amiga side.

Most FPGA cores start out using open source emulators as the basis because they already describe the hardware in code. One thing that is probably a problem is how FEMU seems to have moved towards using its own libraries optimized for its own specific emulation of FPU. Which I suspect means its not going to support the official FPU libraries. But older versions of FEMU might have the more correct FPU implementations before it was optimized.