68LC060.library update

[SpeedGeek]

68LC060.library update

INTRODUCTION:
This 40.3 version of 68LC060.library is partly based on the
40.37 version of Carsten Schlote's library. It has all of
the FPU support code removed which makes it much smaller and
also LC060 specific. However, it is still very much a
"Generic" library.

Updates (by SpeedGeek):
40.1
- Removed all FPU support code
- Removed Store/Load Bypass fix code (not needed for LC060)
- Removed EC/LC060 detection code
- Replaced library code with simpler code (Thanks to
Peter K.)
- Changed revision number to one digit (to separate LC
versions)

NOTES:
A3000 and A4000 owners may need to replace the
mathieeesingbas.library (FPU version) found in the Kickstart
ROMs. It works very well with TurboMMU040+ and FastCache040+!
Please understand a "Generic" library does NOT offer support
for all the features of proprietary 3rd party accelerator
cards.

REQUIREMENTS:
- Amiga with 68LC060 CPU
- Non_FPU versions of math#?.libraries

DISCLAIMER (For updates):
Use at your own risk. No warranty expressed or implied, etc.

USAGE:
- Copy to LIBS:
- OS3.1 Setpatch loads the "Dummy" 68040.library first
- OS3.9 Setpatch (BB2) directly loads the 68060.library
- OS3.1.4+ utility.library is no longer patched (no other
support or testing is provided)

HISTORY:
v40.1 - First release (see Updates)
v40.2 - CPU Performance improved with Superscalar mode
finally working!
v40.3 - Minor changes
- Added code to skip Mult64u/s patch for v45+ utility.library
- Changed longword function table to word function table
- Removed Allocpatchport code from MMU setup code

[PeterK]

Originally Posted by SpeedGeek

- Replaced library code with simpler code (Thanks to
Peter K.)

Hmm, what?

Be careful, I've never seen a 060 CPU or touched a 060.library in my life!

But thanks a lot for your hard work, even if I always use a 020 in WinUAE.

[SpeedGeek]

Originally Posted by PeterK

Hmm, what?

Be careful, I've never seen a 060 CPU or touched a 060.library in my life!

But thanks a lot for your hard work, even if I always use a 020 in WinUAE.

The reference to the library code was just a simple description of your Test library example posted on EAB a few years ago. Devpac complained about the DC.W so I changed it to DC.L. I also increased the private data space because Carsten's MMU setup code stores a few variables there. Don't worry the library has the code needed to keep an LC060 system working just fine (so long as you forget about FPU dependent code).

EDIT: Devpac doesn't like white spaces. So I finally got the DC.W to assemble.

[kuculin]

Hi Guys

I'm looking for help and i guess that this is the right place.

Short story first:
I built a few A3660 CPU cards .... they work ok on A4000 with fullscale CPU .... But the prices and availability of these have gone to the ridiculous realm, so i bought a few LC versions ... they are working and tested..... and here we go.
3.1.4 rom and OS - red software failure after boot, with different CPU libs the system starts, but except sysspeed, everything crashes. Sysspeed reports 68040 on 41 mhz.
3.1 rom and os .... the same +-

After a week of finding answers on net i'm on the verge of throwing the miggy out of the window as it's just mess of completely different advices.

So i found this post - and i hope i'll get a bit further.
the questions:

1 mathieeesingbas.library nonfpu - can i download it somewhere or do i have to go the long way to extract it from A600 ROM ??
2 is there any way how to inject custom rom (from file on HDD)using the MAPROM function on the A3660
3 is there any way how to switch this library by software after boot ??? I found that Loadmodule can do it, but it's for os 3.5 and 3.9 only - would it work on 3.1 and 3.1.4 ?

4 Non_FPU versions of math#?.libraries - are these on WB 1.3 or 2.0 or any older OS version floppies or they are dwnldable somewhere ???

Hmm ... that's all i can think of after a few days of descent to Amigasoftmadness, so once again ...HELP

-> SpeedGeek - deep respect for your work and knowledge mate .....

[HardStep]

Originally Posted by kuculin

Hi Guys

I'm looking for help and i guess that this is the right place.

Did you come across Apollo 1260 75Mhz version, it is supposed to be LC version? If there is a driver/install disk for that, I wonder what kind of libraries does it contain.

[SpeedGeek]

Apparently, some of the Terriblefire people have some issues with this library:

Originally Posted by chucky

by chucky » Sat Aug 08, 2020 1:32 pm
there is a 68LC060 lib that uses the math libs.. emulating FPU instructions..

so with that you can use a LC cpu like as if it is a RC.. but just somewhat slower.

by chucky » Sat Aug 22, 2020 11:22 am

but in short: 68LC060 works.. but forget demos and games.. the fpu emulator FEMU works as 040 code.. SLOW as hell and buggy (but as it is V0.10 do not expect else )

That's exactly why this library does not attempt to emulate the FPU!

BTW, this library is the smallest (9 KB) 68060.library currently available (libraries with emulation code are typically very big).

Originally Posted by pipper

by pipper » Mon Aug 31, 2020 5:12 am

FYI The only reason any Doom port would need an FPU is because it lacks the 030’s 32x32->64bit integer multiplication and the author is instead using the FPU to perform this in floating point and convert back to fixed point right after.
I can probably produce an 060 optimized version that is not using the FPU.
As for ScummVM, there should not be any FP calculations in there. Why it would need an FPU is a complete mystery to me.

The solution is already provided with this library:

- Added optimized Mult64u/s ISP patch to utility.library
functions (Much faster than exception trap code)

[SpeedGeek]

** NEWS UPDATE **

v40.2 released!

- CPU Performance improved with Superscalar mode
(finally) working now!

[SpeedGeek]

Once again, the most ignorant of the Terriblefire group have some issues with this library:

Originally Posted by alenppc

Yes, totally pointless. It does not emulate an FPU, simply removes the FPU management code so even Femu crashes. Avoid.

The point of this library was never about emulating the FPU! It was about supporting one of many non_FPU classic Amiga systems such as:

Stock A500, A600, A1000, A2000, CDTV, A1200 and CD32... and how did Commodore do this? They provided a diverse choice of Math Libraries!

... and why did Commodore do this? Floating point emulation performance runs at only a fraction of performance of the Hardware FPU and with lower precision too! But it get's Much Worse when you add the exception trap overhead and useless code to emulate FPU control instructions on top of the already slow emulation code!

Now regarding the FPU management code (From the 060 manual):

For instance, a system using the MC68EC060 or MC68LC060 has no use for the floating point related modules.

Now, the very obvious reason for this is that the FPSP is in fact FPU dependent code!

Finally, regarding "Pointless" - there is quite a good list of missing features from various TF accelerator cards which could be used to characterize them as "Pointless" but I really don't care to stoop to that level.

Originally Posted by terriblefire

Dont use any speedgeek libraries. You cant use them with MMULib as they basically do the same thing.

Thank goodness you can't use them with MMULib, but basically doing the same thing? I suppose ignorance is bliss until someone throws a bucket of cold water in your face.

Some features not available with MMULib:

- Small single library with reduced memory usage and faster loading time.
- Support for significant MMU performance optimizing tools.
- Support for 1MB and 2MB Kickstart ROM remapping tools
- Simple set up and installation instructions

On the other hand, I'm very pleased that Vampire team (without even realizing it) created the perfect complimentary tool (FEMU) for MMULib:

SLOW as hell FPU emulation + SLOW as hell virtual memory + SLOW as hell CacheDMA API - FAST as heaven 8K page mode support. Thanks guys!

[Thomas Richter]

Originally Posted by SpeedGeek

Stock A500, A600, A1000, A2000, CDTV, A1200 and CD32... and how did Commodore do this? They provided a diverse choice of Math Libraries!

CBM provides one set of math libraries, with all code integrated into one library for the ease of handling. They did this so people cannot install things wrongly. Just put the math libraries in place - off you go. This is the correct design as a system will continue to work if you upgrade or downgrade the CPU, or move the installation to a different system. The same design principle holds for the CPU libraries. Install them, upgrade or downgrade the system - it continues to run. The code will find out itself about the host CPU, and what support needs to be loaded.

Originally Posted by SpeedGeek

But it get's Much Worse when you add the exception trap overhead and useless code to emulate FPU control instructions on top of the already slow emulation code!

There is no FPU exception trap overhead if you use the math libraries, for quite a while now. At least since Os 3.9.

Originally Posted by SpeedGeek

- Small single library with reduced memory usage and faster loading time.

Measure please the "reduced loading time". Fractions of a second, most likely.

Originally Posted by SpeedGeek

- Support for significant MMU performance optimizing tools.

As in "they are no longer available" with your code?

Originally Posted by SpeedGeek

- Support for 1MB and 2MB Kickstart ROM remapping tools

As in "you are wrong?"

Originally Posted by SpeedGeek

- Simple set up and installation instructions

As in "use the installer, or place two libraries to LIBS:"? Where is the complicated part? I probably should not ship the installer because it confuses people...

Originally Posted by SpeedGeek

SLOW as hell FPU emulation + SLOW as hell virtual memory + SLOW as hell CacheDMA API - FAST as heaven 8K page mode support. Thanks guys!

FEMU is not a FPU emulation, it cannot. It is just a "last resort" software for those cores that do not come with a (reduced) FPU and software that can get away with a partial FPU implementation. The math libraries of the system do not offer many services of a real FPU, and as such, cannot replace one if you need one. But there are cores that come with a FPU, with double precision only. In how far its emulation is complete I do not know, but your statement as such is not correct.

[SpeedGeek]

Originally Posted by Thomas Richter

CBM provides one set of math libraries, with all code integrated into one library for the ease of handling. They did this so people cannot install things wrongly. Just put the math libraries in place - off you go. This is the correct design as a system will continue to work if you upgrade or downgrade the CPU, or move the installation to a different system. The same design principle holds for the CPU libraries. Install them, upgrade or downgrade the system - it continues to run. The code will find out itself about the host CPU, and what support needs to be loaded.

I don't have only one "Integrated" library on my OS3.9 system. I have many separate libraries. Some are found in the Kickstart ROMs and some are found in LIBS:. Also, the "Upgrade/Downgrade" system doesn't work for A3000 and A4000 owners as explained in the documentation provided with this library.

Originally Posted by Thomas Richter

There is no FPU exception trap overhead if you use the math libraries, for quite a while now. At least since Os 3.9.

But FPU dependent code doesn't use the math libraries and some of the Terriblefire guys obviously want to use FPU dependent code....

Originally Posted by Thomas Richter

As in "they are no longer available" with your code?

As in "you are wrong?"

IIRC FastCache040+ and TurboMMU040+ were never available with your code.

If You = Terriblefire guys then you are correct and you appear to concur on some of the points.

Originally Posted by Thomas Richter

As in "use the installer, or place two libraries to LIBS:"? Where is the complicated part? I probably should not ship the installer because it confuses people...

FEMU is not a FPU emulation, it cannot. It is just a "last resort" software for those cores that do not come with a (reduced) FPU and software that can get away with a partial FPU implementation. The math libraries of the system do not offer many services of a real FPU, and as such, cannot replace one if you need one. But there are cores that come with a FPU, with double precision only. In how far its emulation is complete I do not know, but your statement as such is not correct.

The installer probably confuses users less than the instructions but has little to do with the complexity of the instructions.

I don't expect FEMU has to be 100% complete (or bug free) to qualify as an FPU emulator. Nevertheless, the Terriblefire guys are using it as such with your MMULib so I would suggest you take up the issue with them. Danke!

[Thomas Richter]

Originally Posted by SpeedGeek

I don't have only one "Integrated" library on my OS3.9 system. I have many separate libraries.

If you use the CBM libraries, there is one library for all cases. FPU, no FPU, 68020, 68040.... all just one code. Move from 68020 with no FPU to 68060? Just works.

Originally Posted by SpeedGeek

Some are found in the Kickstart ROMs and some are found in LIBS:. Also, the "Upgrade/Downgrade" system doesn't work for A3000 and A4000 owners as explained in the documentation provided with this library.

It does. A system with all libraries in LIBS:; a decent kickstart and a decent SetPatch can simply be cloned and will work CPU-independent just fine.

Originally Posted by SpeedGeek

But FPU dependent code doesn't use the math libraries and some of the Terriblefire guys obviously want to use FPU dependent code....

FPU dependent code *may* use the math libraries without problems, and then will use the FPU, and - with any decent version - without emulator trap overhead. And, in fact, it is a good idea to go through the math libraries if that is sufficient as it makes your code independent of the machine configuration.

Originally Posted by SpeedGeek

IIRC FastCache040+ and TurboMMU040+ were never available with your code.

And MuFastRom and MuFastZero never with yours. Now what? You provide functions that do half of the job - sure that is simpler and faster. I like correct solutions. That takes a bit more care. Didn't we have that already? The missing logical to physical translation? The missing fragmented memory support?

Originally Posted by SpeedGeek

The installer probably confuses users less than the instructions but has little to do with the complexity of the instructions.

So what is the complexity in "put two libs into LIBS: instead of one"? Because this is all you need to do for typical systems. Exception: P5 - but they require system specific tweaks anyhow, and that is beyond my control.

Originally Posted by SpeedGeek

I don't expect FEMU has to be 100% complete (or bug free) to qualify as an FPU emulator. Nevertheless, the Terriblefire guys are using it as such with your MMULib so I would suggest you take up the issue with them. Danke!

If they consider that good enough for their customers, that's their choice. If code uses the FPU directly, rather than going through the mathieee abstraction, there should be reasons, as in "the libraries were not sufficient". Well, if you emulate an FPU with these libraries then, I guess this kinna defeats the purpose of having FPU code in first place.


Then again, there are too many authors that simply do not know better, "let's use the FPU because it is 0.5seconds faster on my system" for purposes for which it would really not make a difference at all, just by being lazy, without knowing that this may exclude parts of their potential user base.



My advice: Stick to the libraries. Unless you really really have to, as in "numerical stability", "speed" or "IEEE-aware processing". I guess none of that is really important enough on the Amiga to justify an FPU, but many authors just do not care. So it is a compatibility hack that apparently works "well enough". As such, it is a hacky "best attempt" solution.



I see more responsibility here at the software authors than the hardware or firmware vendors. Clearly, they have to provide some kind of workaround for lazy software, given that full CPUs are hard to accquire and getting expensive.



So, where exactly is now the problem? I don't see one.

[SpeedGeek]

Originally Posted by Thomas Richter

If you use the CBM libraries, there is one library for all cases. FPU, no FPU, 68020, 68040.... all just one code. Move from 68020 with no FPU to 68060? Just works.

It does. A system with all libraries in LIBS:; a decent kickstart and a decent SetPatch can simply be cloned and will work CPU-independent just fine.

I don't know how you get "One" library for all cases. My "Decent" Commodore A3000 3.1 ROM's had an FPU version of mathieeesingbas.library built into them. Also, the choice of Non_IEEE single precision, IEEE single precision and IEEE double precision libraries and their basic and transcendental variants appears contrary to "One" library for all cases.

No, it doesn't work for all systems and it was in fact the very first problem Mathesar encountered on this thread:

http://eab.abime.net/showthread.php?t=96904

Originally Posted by Thomas Richter

FPU dependent code *may* use the math libraries without problems, and then will use the FPU, and - with any decent version - without emulator trap overhead. And, in fact, it is a good idea to go through the math libraries if that is sufficient as it makes your code independent of the machine configuration.

What FPU dependent code "May" do and what it typically does do is all to often a very different case. I think many Software developers opted to use the Hardware directly for obvious performance reasons since the Commodore supplied libraries essentially traded compatibility for performance.

Originally Posted by Thomas Richter

And MuFastRom and MuFastZero never with yours. Now what? You provide functions that do half of the job - sure that is simpler and faster. I like correct solutions. That takes a bit more care. Didn't we have that already? The missing logical to physical translation? The missing fragmented memory support?

So what is the complexity in "put two libs into LIBS: instead of one"? Because this is all you need to do for typical systems. Exception: P5 - but they require system specific tweaks anyhow, and that is beyond my control.

If they consider that good enough for their customers, that's their choice. If code uses the FPU directly, rather than going through the mathieee abstraction, there should be reasons, as in "the libraries were not sufficient". Well, if you emulate an FPU with these libraries then, I guess this kinna defeats the purpose of having FPU code in first place.

So, where exactly is now the problem? I don't see one.

MapRom040+ and TurboRom040+ are both available for download on this forum. Since they were developed for use with other libraries as well, it makes good sense to have them available separately for download. I never considered remapping the Zero page to be worth the effort. I always considered it better to use the VBR for it's intended purpose and throw away the "Brain Dead" Software. Nevertheless, RemapZero is also available for download on this forum.

I thought you had to put three libs into LIBS: (unless there was special non-virtual memory version I am not aware of).

I see no reason to repeat (time and time again) explanations why your MMULib needs Logical to Physical address translation code and all the other libraries don't need it.

Regarding what's good enough for customers, again you should take this matter up with your Terriblefire customers. That's the real problem here.

[Thomas Richter]

Originally Posted by SpeedGeek

I don't know how you get "One" library for all cases. My "Decent" Commodore A3000 3.1 ROM's had an FPU version of mathieeesingbas.library built into them.

mathieeesingbas in 3.1 was a problem case because CBM run out of ROM space in 3.1. That was fixed in 3.1.4, and it is the only library with this problem. It is a design bug, and one that has been adressed. Luckely, the library is rarely used. Actually, I have only a single program in my collection that uses it.

Originally Posted by SpeedGeek

Also, the choice of Non_IEEE single precision, IEEE single precision and IEEE double precision libraries and their basic and transcendental variants appears contrary to "One" library for all cases.

The "cases" are the hardware variants. Not the precisions. As math models, the Amiga has three. FFP, IEEE single, IEEE double, with mathematical accuracy increasing in this order, and speed decreasing in this order. Compilers may offer additional models (SAS/C has a bulit-in model, for example.)

Originally Posted by SpeedGeek

What FPU dependent code "May" do and what it typically does do is all to often a very different case. I think many Software developers opted to use the Hardware directly for obvious performance reasons since the Commodore supplied libraries essentially traded compatibility for performance.

For which definition of "many"? I guess you can could count the numbers of software that depend on an FPU, and even more so would require a FPU for performance reasons by the fingers of one hand. The CBM versions of the math libraries only add minimal overhead in the FPU case. Actually, just moving registers around between CPU and FPU. Hard to make it any faster without a kludgy solution.

Originally Posted by SpeedGeek

MapRom040+ and TurboRom040+ are both available for download on this forum. Since they were developed for use with other libraries as well, it makes good sense to have them available separately for download. I never considered remapping the Zero page to be worth the effort. I always considered it better to use the VBR for it's intended purpose and throw away the "Brain Dead" Software. Nevertheless, RemapZero is also available for download on this forum.

The VBR is not the problem, or only part of the problem, and what you have there are isolated solutions without a common API. You neither cannot remap VBR in all cases, without some compatibility issues. Then your solution has problems such as "who allocates MMU pages" "how is their memory maintained"... and so on remain unanswered. Zero page remapping helps more than just relocating the VBR. Sysbase gets out of chip mem for some systems, and MacOs globals are moved out of chip mem as well if you run emulators.


There are reasons why complete solutions are more complex than simple ad hoc solutions. Don't hit the MMU directly if the mmu.library is in place. Don't hit the MMU directly if any other CPU library controlling its table is in use, such as the P5 CPU libraries. Use its interface.For the former, its interface is documented, the latter is a closed interface. There are even example programs out there, including sources, you can use. If you touch the MMU under the feet of another library, for examplle the mmu.library, or also the P5 libraries which may also modify its own MMU tables, you may get undesired side effects if the code does not find the tables where it expects them or in the state it excepts them.

Originally Posted by SpeedGeek

I thought you had to put three libs into LIBS: (unless there was special non-virtual memory version I am not aware of).

Two for a single-CPU target only. The CPU library, and the mmu.library. And that is it. If you want a portable system, put all four CPU libraries to LIBS:

Originally Posted by SpeedGeek

I see no reason to repeat (time and time again) explanations why your MMULib needs Logical to Physical address translation code and all the other libraries don't need it.

Because the system documentation says so. Because you want DMA to work if you remap memory. As for example the zero page, or the kickstart, or for any other reason memory is remapped.

Originally Posted by SpeedGeek

Regarding what's good enough for customers, again you should take this matter up with your Terriblefire customers. That's the real problem here.

Huh? Did I miss something? These are not "my customers". I am not affilated with them in any particular way.

[SpeedGeek]

Originally Posted by Thomas Richter

mathieeesingbas in 3.1 was a problem case because CBM run out of ROM space in 3.1. That was fixed in 3.1.4, and it is the only library with this problem. It is a design bug, and one that has been adressed. Luckely, the library is rarely used. Actually, I have only a single program in my collection that uses it.

The solution for running out of ROM space is supporting > 512KB ROMs when it is practical to do so and ONLY when not practical loading modules from the boot drive. My S-S fails @ SYS:System/REXXmast >NIL: when the FPU is disabled unless I replace mathieeesingbas.library. I don't know why Mathesar's system crashed (probably caused by some buggy code).

Originally Posted by Thomas Richter

The "cases" are the hardware variants. Not the precisions. As math models, the Amiga has three. FFP, IEEE single, IEEE double, with mathematical accuracy increasing in this order, and speed decreasing in this order. Compilers may offer additional models (SAS/C has a bulit-in model, for example.)

<sigh> Now, models don't count as cases according to your definition. Well, my definition is quite simple. One library = One case that's all.

Originally Posted by Thomas Richter

For which definition of "many"? I guess you can could count the numbers of software that depend on an FPU, and even more so would require a FPU for performance reasons by the fingers of one hand. The CBM versions of the math libraries only add minimal overhead in the FPU case. Actually, just moving registers around between CPU and FPU. Hard to make it any faster without a kludgy solution.

It's not just the FPU cases in the definition of many, game developers and demo coders like to use the hardware directly for performance reasons too. It's faster just to avoid the library function calls and how much faster depends on the number of iterations.

Originally Posted by Thomas Richter

The VBR is not the problem, or only part of the problem, and what you have there are isolated solutions without a common API. You neither cannot remap VBR in all cases, without some compatibility issues. Then your solution has problems such as "who allocates MMU pages" "how is their memory maintained"... and so on remain unanswered. Zero page remapping helps more than just relocating the VBR. Sysbase gets out of chip mem for some systems, and MacOs globals are moved out of chip mem as well if you run emulators.

If you use the VBR for it's intended purpose then you don't need to worry about "Who allocates MMU pages". It's the Zero page MMU remaps which create the problem in the first place. I don't care a damn about Shapeshifter or MacOS globals. You are very welcome to monopolize any non_AmigaOS support with your MMULIb.

Originally Posted by Thomas Richter

Because the system documentation says so. Because you want DMA to work if you remap memory. As for example the zero page, or the kickstart, or for any other reason memory is remapped.

Huh? Did I miss something? These are not "my customers". I am not affilated with them in any particular way.

All the other 040-060 CPU libraries have ignored the documentation from the very beginning... and by remarkable coincidence they work fine with DMA and mirror image remapping tools. BTW, THIS IS THE VERY LAST TIME I WILL REPLY TO THIS TOPIC!

"Customers" was your choice of words not mine. Since, I am not aware of any Vampire MMULib customers, Terriblefire MMULib customers was the only remaining choice. If you don't want to consider them as customers, perhaps you could consider them as "Cases" or "Models"?

[rzookol]

Does this library also support 68EC060, or EC 060s are not supported?

[SpeedGeek]

Originally Posted by rzookol

Does this library also support 68EC060, or EC 060s are not supported?

EC060s are NOT supported with this library. I personally don't think an EC060 is a practical CPU for Amiga users.

[jbbolcato]

Ordered my A3660 for my A3000 today, with 68LC060. What is the score with Roms3.2.1?
Which lib should I copy, VS which one is in rom? (vs 3.1.4 or 3.9 that's mentioned above or in other forums). Thx!

[SpeedGeek]

I don't know the score with OS (3.1.4 - 3.2.1). I can only test the 68LC060.library with the OS versions I have (3.1 - 3.9).

IIRC the size of the ROM based mathieeesingbas.library is approx. 1 KB (FPU version) and 5 KB (Non_FPU version).

The disk based mathlibs from Commodore, H&P and Hyperion should all be Non_FPU versions.

[Crumb]

Originally Posted by SpeedGeek

EC060s are NOT supported with this library. I personally don't think an EC060 is a practical CPU for Amiga users.

Shouldn't a EC060 be enough for Amigas without z3/PCI slots? So you can disable caches for <=24bit addresses and enable them for >24bit? E.g. An A1200 with fastram, an A2000 with a 32bit accelerator... There are plenty of EC060 cpus too and in certain cases it could work I guess.

@Thor
A MuRedox+femu tool for LC cpus that replaces FPU code by the emulated equivalent would be great now that 060s with FPUs are getting rare.

[Thomas Richter]

Originally Posted by Crumb

Shouldn't a EC060 be enough for Amigas without z3/PCI slots? So you can disable caches for <=24bit addresses and enable them for >24bit?

That depends on what else is in the system. As soon as you DMA into 32-bit memory, you need to disable the copy back cache, either selectively at DMA boundaries if they are misaligned to line boundaries, or entirely, which is probably not such a great idea. It also means that the kickstart is entirely uncached, and cannot be remapped, i.e. "quite slow". Remember that a board-specific memory mirror (such as found on many GVP boards), would not help you here as the kickstart mirror still appears within the 24-bit area, and thus would remain uncached.



So, well, you can "do it in a sense", but as we say in Berlin, you can also sew a knob to your cheek and hang a piano on it if you like, but it's still a bad idea.


Anyhow, if anyone wants to test a new version of the MuLib 68060.library or 68040.library, send me a PM. It takes now less memory for the LC CPUs because it can now unload the then unneeded fpsp code. Probably a tiny improvement that releases around 64K of memory for the LCs. It just needs testing as I don't have such CPUs here.

Originally Posted by Crumb

A MuRedox+femu tool for LC cpus that replaces FPU code by the emulated equivalent would be great now that 060s with FPUs are getting rare.

Again, I don't think this is such a wise idea. Remember, the slow part here would not become the exception trap (unlike with the regular fpsp), but the slow part will be the floating point computation within the CPU. Thus, if you expect that this could run your average FPU based demo well, then I afraid you are wrong, it will be pretty slow, if it works at all (because such software overtakes usually the whole system, including the vector base register, so bad luck).



Thus, what I want to say is that the number of applications that require a FPU, and become then usable due to such a construction, is rather limited. E.g. a ray tracer with an emulated FPU will be still low, and actually much slower than doing the math in the CPU in first place without emulation.



If you want to use math in a serious application, please consider using mathieeedoubbas, which will pick the math implementation that is most suitable for your setup no matter what your setup is.



The Os 3.2 JPEG datatype is a good example as it branches internally between FPU and CPU implementation and picks the one that suits your system.