@Gunnar

Quote:

Gunnar wrote: @Hammer Quote: BFG9060 and TF1260 include 128 MB RAM while Warp1260 includes 256 MB RAM. Your post show always that you absolutely not understand what we talk about. We not said that its impossible to add more memory to an old 68K. We explained that the old MMU is not optimal for managing huge amounts of memory and that you can get a better running system with adding some improvements to the MMU. Do you understand the topic now?

I know what you are talking about. NeXT box with 68040 and 64 MB to 128 MB RAM handles graphics UI workstation Unix just fine.

You're talking crap.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

Quote:

I know what you are talking about.

No you dont have a clue!

You attack me for saying that 040 could not attach more memory.
I never said this.

What I said was that the 040 MMU has disadvantages in managing big amounts of memory.
In the last 30 years a lot good inventions were made - which allow to make a better MMU.


Hammer I think your problem is that you want to talk to topics that you not understand.
You lack understanding how MMUs works internally and what challenges or problems certain MMU design have, without this knowledge you not understand my point that modern MMUs have many design advantages.



Have you ever coded an MMU yourself?
No

Have you coded the 68040 MMU?
No

Do you know how many memory access the 68040 needs to make for loading its MMU page entry?
you don't know

Do you know how many KB (its kilobyte) the 68040 MMU can map max without needing to reload entries from RAM?
You dont know

Do you know what delay the MMU reload causes, how many cycles?
You dont know

Do you know what modern features the 040 the MMU lacks?
You dont know

Do you think INTEL would still use the unchanged 386 MMU in its modern chips?
Or do you think they maybe invented some improvements in the last 30 years?

You have no knowledge about the topic!
And talk nonsense because you not understand the topic.


Please be so kind and try to educate yourself before you post more nonsense

Last edited by Gunnar on 19-Feb-2024 at 09:10 AM.
Last edited by Gunnar on 19-Feb-2024 at 07:59 AM.

@Gunnar

Lots of people do know, why don’t you share with them?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Gunnar

Quote:

Gunnar wrote: No you dont have a clue!

NeXTSTEP runs fine on 64 MB to 128 MB RAM equipped 68040-based NeXT unix-based boxes.


Quote:

You attack me for saying that 040 could not attach more memory. I never said this.

That's not my argument. You claimed 68K MMU is "optimal" for up to 8 MB of RAM.

Again, NeXTSTEP runs fine on 64 MB to 128 MB RAM equipped 68040-based NeXT unix-based boxes.

68060 is faster than 68040.

Quote:

What I said was that the 040 MMU has disadvantages in managing big amounts of memory. In the last 30 years a lot good inventions were made - which allow to make a better MMU.

You claimed 68K MMU is "optimal" for up to 8 MB of RAM.

We have up to 100 Mhz FSB 128 MB and 256 MB equipped 68060 Rev 6 accelerator cards and they are faster than yesteryear's 68040-based machines.

The primary storage (C= PIO 0 IDE suck, I miss my A3000's SCSI) and graphics (X Window System) performance have a higher impact when running with Amiga's Linux 68K.

Quote:

Hammer I think your problem is that you want to talk to topics that you not understand. You lack understanding how MMUs works internally and what challenges or problems certain MMU design have, without this knowledge you not understand my point that modern MMUs have many design advantages.

Again, NeXTStep runs fine on 64 MB to 128 MB RAM equipped 68040-based NeXT unix-based boxes.

Up to 100 Mhz FSB 128 MB and 256 MB equipped 68060 Rev 6 accelerator cards are faster than 68040-based platforms.

Quote:

Have you ever coded an MMU yourself? No

Red herring. Again, NeXTStep runs fine on 64 MB to 128 MB RAM equipped 68040-based NeXT unix-based boxes.

You don't have Linux 68K on AC68080! LOL

Quote:

Have you coded the 68040 MMU? No

Red herring. Again, NeXTStep runs fine on 64 MB to 128 MB RAM equipped 68040-based NeXT unix-based boxes.

You don't have Linux 68K on AC68080! LOL

Quote:

Do you know how many memory access the 68040 needs to make for loading its MMU page entry? you don't know

Red herring. Again, NeXTStep runs fine on 64 MB to 128 MB RAM equipped 68040-based NeXT unix-based boxes.

You don't have Linux 68K on AC68080!

Quote:

Do you know how many KB (its kilobyte) the 68040 MMU can map max without needing to reload entries from RAM? You dont know

Red herring. Again, NeXTStep runs fine on 64 MB to 128 MB RAM equipped 68040-based NeXT unix-based boxes.

You don't have Linux 68K on AC68080!
Quote:

Do you know what delay the MMU reload causes, how many cycles? You dont know

Red herring. Again, NeXTStep runs fine on 64 MB to 128 MB RAM equipped 68040-based NeXT unix-based boxes.

You don't have Linux 68K on AC68080!

Quote:

Do you know what modern features the 040 the MMU lacks? You dont know

Red herring. Again, NeXTStep runs fine on 64 MB to 128 MB RAM equipped 68040-based NeXT unix-based boxes.

You don't have Linux 68K on AC68080!

Quote:

Do you think INTEL would still use the unchanged 386 MMU in its modern chips?

Absurd. Pentium MMU is fully backward compatible with i386 MMU and with a performance boost.

Windows NT 3.x i386 runs from i386 to the latest X86-64 CPUs.

Both Zen 4's and Raptor Lake's MMUs are fully backward compatible with i386 MMU and with a large-scale performance boost.

You can't say the same with your AC68080 since you disrespect 68K MMU legacy support. https://www.youtube.com/watch?v=QiZNSzWIaLo
You're supposed to be different from Motorola's 68K ISA cut-and-paste BS.

What's the shame of running out of transistor budget for a faster and fully backward-compatible 68K MMU?

Did you run out of transistors with Vampire V2's FPU (missing FP64 and FP80)?


Quote:

Or do you think they maybe invented some improvements in the last 30 years? You have no knowledge about the topic! And talk nonsense because you not understand the topic. Please be so kind and try to educate yourself before you post more nonsense

The real nonsense comes from you.

Again, Pentium MMU is fully backward compatible with i386 MMU and with a performance boost.

NeXTStep's usability on 68040 with 64 MB to 128 MB RAM is real and it has reasonable performance given its 486-era hardware.

Last edited by Hammer on 20-Feb-2024 at 06:11 AM.
Last edited by Hammer on 20-Feb-2024 at 06:06 AM.
Last edited by Hammer on 20-Feb-2024 at 06:01 AM.
Last edited by Hammer on 20-Feb-2024 at 05:58 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hans

Quote:

We really should have kept MooBunny running so that the "super armchair critics" would be able to spout their bile over there instead of here...

Honestly. I think it is good that moo is gone.
That picture of OS4 super-fan #1, Atheist2, showing his toilet and where he had written messages on his toilet ring using his own feces as a crayon is still burned into my mind.

Why do os4 people do this kind of shit (see what I did there?)

@Hammer

MMU is a complex topic.
It helps a lot if you understand how an MMU works.

Let me explain you what an MMU is and how it works, this will help you to understand it.


The MMU is a hardware unit which for each memory access will automatically checks the internal ATC registers. This ATC register will translate the address and will provide information if the page is allowed to be READ/WRITE.

In main memory a treestrucure list of all values for all memory pages is stored.
This list can be huge. As you can have 1 entry for each 4 KB of memory.


The 68K like 040 have technically 2 MMU.
One for instructions access and one for Data access.
The MMU has internal ATC register per memory PAGE.
The 040 MMU has 64 ATC register. With a page size of 4 KB this means that the 040 MMU can at one time manage 256 KB memory

If you work with more memory as the MMU ATC has mapped,
then the ATC access will fail and the MMU will automatically
go to memory walk the tree list in memory and load the missing ATC -
your CPU will stop during this and wait.


Let me sum this up again for you.
* The MMU has internal ATC register
* For each memory access, either Instruction or Data the MMUs will check the ATC value.
* The MMU has a limited number of ATC register this means only limited number of pages can be remembered by the MMU. Its only 256 KB with 4K pages on the 68040.

* When the translation is not in the ATC, the MMU will search the translation tables in memory for the translation information = load it from memory
During this ATC reload the CPU will wait.
This means you system will slow down.
Depending on your system and memory work pattern the slowdown can be significant that you can measure it.


Lets make some simple examples to help you understand it fully.

A 4KB page in todays world is very small.
Lets say you have a workbench in truecolor= 32bit.
Lets say your Screenmode is FullHD = 1920 × 1080 Pixel

One screen row is 7660 Byte long.
This means one Screen row is already 2 MMU pages.

Lets say you do something very simple you point on screen on vertically line.
Where you paint 1 pixel in each row.
Your screen is 1080 rows.
You need to write 1080 pixel ....

As you probably already see the MMU will to load 1080 ATC values for this
This means each of your pixel writes will stutter and be very slow.


You see already that with this design you can NOT even manage 1 simple picture in memory
without having constant MMU misses and suffering a constant slowdown.


Lets look at DOOM game for example.
Amiga DOOM game has a screenbuffer in memory and there it paints the screen in columns.
This means the game always draws vertical lines. Many game work like this.
They paint one pixel in each row.

You see already the problem here.
The MMU will constantly fail - the MMU will constantly search the translation tables in memory for the translation information


You all see and understand the problem now.

There are several solutions and ways to improve this.

1) Having bigger pages.
Modern MMU not only support 4KB pages but JUMBO big pages of 1MB or 16MB size.
Its easy to understand that JUMBO pages easily solve our Workbench paint and DOOM game problem.

2) Different Table layout in memory.
With changing the layout of the translation structure in memory you can do optimizations
depending on your needs and this can results in much faster loading of the ATC values


The Apollo 68080 MMU support JUMBO pages and has a different table layout which allows faster loading of ATC values. The jumbo pages are very important for managing bigger memory

The Apollo 68080 MMU also supports new informationbits like "page is EXECUTABLE".
This means you can cleanly separate both DATA and Code segments.
And forbid to execute instruction in a DATA segment.
This helps to find bugs and improves system security.




The 68040 MMU is not bad. Its OK.
Or course you can with the 040 MMU also manage gigabytes of memory.
But the MMU has limitations and you easily suffer performance problems.

The DOOM game is simple example of where the 68040 MMU already fails.
As the MMU can not "map" enough pages for even the memory draw buffer.
This means you have constant MMU reloads for every pixel the game paints that make you slow.



I hope the examples where easy and clear.
And I hope this helps you to fully understand what I mean.

In my opinion its a very good idea to improve the MMU design as I did on the 68080.
The 68080 can manage todays memory amounts and screenbuffer without suffering performance problems.
The 68080 supports an faster data layout of the MMU information and it offers improved security features.

@Hammer

I assume to much and take to much knowledge for granted.
Sorry for that. I understand I need to explain stuff in more detail.


Quote:

You claimed 68K MMU is "optimal" for up to 8 MB of RAM.

No, I did not say this.
What I tried to say is that the 040 MMU was developed at a time when Computer had not much memory common was 1-8 MB memory, at a time when programs were often small
and when normal screen resolution was 640 pixel.
And in the condition of that time the 040 MMU is good.

Using 4k pages the 68040 MMU can manage 256 KB memory at one time.
If you work with more memory, then the MMU will need to do reloads.



Today we work with different amounts of data.
Today a truecolor FULLHD picture (e.g. game or workbench) is 8 MB size.

This means that the workbench screen is already 32 times bigger than the MMU can manage without needing to reload.


As I tried to explain in the DOOM example, make games access memory in patterns like e.g. writing column on the screen.
A memory write is normally fast - it can be ~ 1 cycle
If your MMU fails to "map" the DOOM game screen - Because its bigger than the MMU can manage.
Then the MMU will do automatic memory reloads.
Loads are slow.

This means your DOOM 1 pixel write which took 1 clock cycle, with activated MMU and the screen being bigger than the MMU can cache - you get MMU reloads. A reload can take maybe 30 cycle.
I hope you understand the huge effect a too small scaled MMU can have.



Quote:

You don't have Linux 68K on AC68080

Correct.

Our goal is to run AmigaOS, Atari OS and MacOS.
You can run on V2/V4 any AmigaOS version from 1.1 on to 3.9 , you can run Atari/Emutos, and MACOS.
This is exactly what we want.

@Hammer

Quote:

Again, NeXTStep runs fine on 64 MB to 128 MB RAM equipped 68040-based NeXT unix-based boxes.

Of course the 68040 can access more memory.
But this was not the topic.

The topic was the 68040 MMU is designed to have 100% performance with 256/512KB memory
You can always work with more memory, but depending on your memory access pattern you can suffer performance problems.
Even a simple games like DOOM can already trigger significant performance degradation.

You can clearly measure these performance issues.



Hammer please understand that the question was NOT if the 040 can access more than 8MB.

The topic was that its a smart idea to improve the MMU so that it can work with more memory with less performance issues.

@Hammer

Quote:

Again, Pentium MMU is fully backward compatible with i386 MMU and with a performance boost.

You misunderstand the question.
The question was NOT if the MMU can run in backward compatible mode.


The topic was "Does it make sense to use today an unchanged 30 year old MMU ?"
Does INTEL use the MMU of the 386 unchanged today?
They not use the 30 year old MMU.

INTEL greatly enhanced, improved the MMU and added new modern features.
This is good and helps to manage todays big amounts of memory in a good way.
This makes total sense.



The Apollo 68080 MMU is also designed to have signifant improvements over old 040 MMU.
We think this is the best solution.


You might ask why we not tried to catch both goals.
Making the MMU better and being 100% legacy compatible.
This is a fair question to ask.

Of course trying to do everything better and being 100% compatible is very difficult.
This would make the MMU a lot more complex.
Is it worth it? I dont think so.

On Amiga we have the situation is that we have like 5000 games and 5000 demos and many programs and none of them uses MMU.
Also the AMIGA OS not needs the MMU.


You posted that Shapeshifter can use MMU. True but useless.
The MMU hack is a tradeoff that only to help reduce chunky 2 planar conversion
And this "hack" is only useful if your computer have only PLANAR screens.
So for our systems this is useless as we can run MAC ON on their native format
and not need to do slow Chunky2Planer conversion.

MMU on Amiga is very little used.
Having a new and better MMU is not a problem on Amiga.
MMU is sometimes used for debugging sometimes on Amiga
and we also cover this usecase with our own tool APOLLO SHIELD.

Last edited by Gunnar on 20-Feb-2024 at 11:15 AM.

@Gunnar

The standard resolution Doom renders at (320*200), there are only 16 pages needed.

Anyone trying to run doom SW renderer on a 1080p 32-bit display on a 68040 is surely going to run into more immediate performance issues than translation cache misses.

Last edited by Karlos on 20-Feb-2024 at 11:11 AM.

_________________
Doing stupid things for fun...

@Karlos

Quote:

The standard resolution Doom renders at (320*200)

This is exactly my point.
The 68040 was designed at a time
when a Full Operating system did fit on 1 floppy disk,
when games used 320 screenmode,
and when the Workbench was 640 screenmode with 4 colors.

The 68040 MMU works good in this scenario of 80th/90th.



But the scenario has changed.
Today people want to run much bigger programs.
Workbench in 640 and 4 colors is not what people want today.

Today people run their Workbench in truecolor and in high resolutions like 1280x720 or 1920x0180
And today people also want to run games in higher resolutions like 640 or 848 or 960 screenmodes.

This means you today have much bigger images you draw in memory.
This amount of memory that you work is more than the 040 MMU does handle internally.
This can cause the MMU to reload constantly translation buffers.
This makes your system slower.

The memory access topic can very easily be understood with using the game DOOM as example.

Of course the memory management is a general issue affecting every program that you run - including Workbench painting, Databases, games, browsers, compiler ....
The DOOM game was just 1 simple example, we could talk about thousands of programs.


I think its smart to improve the MMU to better handle the memory amounts that programs have today.
Do you agree?

Last edited by Gunnar on 20-Feb-2024 at 03:26 PM.
Last edited by Gunnar on 20-Feb-2024 at 11:40 AM.

@Gunnar

Quote:

Gunnar wrote: @Hammer Quote: Again, Pentium MMU is fully backward compatible with i386 MMU and with a performance boost. You misunderstand the question. The question was NOT if the MMU can run in backward compatible mode. The topic was "Does it make sense to use today an unchanged 30 year old MMU ?" Does INTEL use the MMU of the 386 unchanged today? They not use the 30 year old MMU. INTEL greatly enhanced, improved the MMU and added new modern features. This is good and helps to manage todays big amounts of memory in a good way. This makes total sense.

Well, Intel's 32-bit MMU got some enhancements (2M and 4MB pages, NX), but it's still being used more or less how it was introduced with the 80386: with 4kB pages and 3 levels pages.

4kB pages are used even with x64 (which supports 1GB pages), with 4 or 5 levels pages.

In short: 4kB are the standard on x86/x64, despite bigger page sizes are possible (but you need to compile the specifically), and the performances are still still stellar (because on modern processors there are more TLBs entries AND the data access patterns aren't purely random).

@cdimauro

Quote:

and the performances are still still stellar

MMU usage needs translation tables in memory.
The MMU needs to load this from memory.
Loads take time.
This means you loose system performance.

How much performance do you loose?

This varies from case to case.

In a very good case, you might loose 1%
In a bad case maybe you loose 5%
In a very bad case like our DOOM example maybe you loose 10%


Its very hard to "feel" or notice this loss without detailed measurement.


As you will know: IBM sells very big computers, where 1 system cost over 100,000,000 USD.
IBM did detailed researches how much those System loose in MMU misses on varoius workloads
The losses are in the millions of USD.

@Gunnar

Quote:

Gunnar wrote: @cdimauro Quote: and the performances are still still stellar MMU usage needs translation tables in memory. The MMU needs to load this from memory. Loads take time.

You can image how much it can take on a 64-bit system with the usual 4kB page and 4 or even 5 page levels. However... those are the systems which we're using and they are pretty fast.

And we have also NVMes which allow to load data extremely fast (several GB/s and with access time in the ballpark of nanoseconds).
Quote:

This means you loose system performance. How much performance do you loose? This varies from case to case. In a very good case, you might loose 1% In a bad case maybe you loose 5% In a very bad case like our DOOM example maybe you loose 10% Its very hard to "feel" or notice this loss without detailed measurement.

Yes, because it also depends on the specific context / application and, also, on what components that you've on your system (see above).

For example, I don't think that Doom could have so much impact even using an 8k display. That's because it renders line by line, from the start of a line to its end. And lines are located on sequential locations. Here even a simple hardware prefetch logic does a great work.

Of course, accessing the textures is a different thing but, again, many times those are "local" to the specific part of the scene. But we also have much more TLB entries (and the prefetch logic that help).
Quote:

As you will know: IBM sells very big computers, where 1 system cost over 100,000,000 USD. IBM did detailed researches how much those System loose in MMU misses on varoius workloads The losses are in the millions of USD.

NVMes? More TLB entries? There are solutions for that.

@Gunnar
Amigaworld.net is not a good measuring stick.
There are likely more people being productive with working on Amiga thingies than ever before right now.
I suggest you take a look at eab or amigans or various facebook groups for example.
Of course most of these projects are targetting OCS / ECS / AGA, because apparently and in stark contrast to your asumption most people seem to like playing around with PAL lowres and 1-256 colors.
On top of that there are countless current hardware projects around classic hardware, e.g. Pistorm, TF, various joysticks, you name it.

"How could people be motivated to do something positive?"

Probably it would be a good start to not launch and participate on topics like this.

@cdimauro

Quote:

For example, I don't think that Doom could have so much impact even using an 8k display. That's because it renders line by line, from the start of a line to its end. And lines are located on sequential locations. Here even a simple hardware prefetch logic does a great work.

No - this not how Doom and similar games are coded.
DOOM renders all the Walls vertically in columns.
From top of screen to bottom of screen.
This means every pixel it writes, is in another row.


The wall render loop of DOOM and similar games is pretty fast.

For rendering 1 pixel on screen the game
has to read 1 texel from memory, - here the CPU-Dcache is useful
The Dcache it will reduce the needed memory reads a lot.
And it the game will write 1 pixel.
Memory writes are fast ..
And therefore the DOOM engine is fast.


But if you play DOOM in bigger resolution like 1024
and you use the MMU and the following will happen:
every 2nd or 3rd pixel of the Walls that the game paints will be in another memory page.

The MMU will need to load the translation of this page.
This has a huge performance impact.

Back to the discussion of the 68040 MMU we explained this
The 68040 can map 256 KB max at the same time - using 4K pages.
A game screen with 1024x768 (256 color) is already 3 times bigger than the MMU can map.
This means that such a game, on this MMU would trigger a worst case scenario
in which the MMU will do several memory reads by itself for every 3 rd pixel or so the game renders.

This is a simple to understand - very bad case - where suddenly in the order of 25-50% of the CPU time is eaten by the MMU.

This "nasty" worst-case MMU effect can be triggered by many programs being them many applications, database, games or demos.


Using the MMU has always a cost, as the MMU needs to make memory reads which are slow.
"Normally" the MMU costs are relative small, being just some percent System cost.

But if you trigger a "nasty case" like this DOOM example - then the MMU cost can explode and the MMU can cost you up to even 50% time of your system


I selected DOOM as example to discuss this before I thought
that this is very easy to understand and most people would know how DOOM and similar games render.

Last edited by Gunnar on 22-Feb-2024 at 08:14 AM.

@Gunnar

Quote:

Gunnar wrote: @cdimauro Quote: For example, I don't think that Doom could have so much impact even using an 8k display. That's because it renders line by line, from the start of a line to its end. And lines are located on sequential locations. Here even a simple hardware prefetch logic does a great work. No - this not how Doom and similar games are coded. DOOM renders all the Walls vertically in columns. From top of screen to bottom of screen. This means every pixel it writes, is in another row. The wall render loop of DOOM and similar games is pretty fast. For rendering 1 pixel on screen the game has to read 1 texel from memory, - here the CPU-Dcache is useful The Dcache it will reduce the needed memory reads a lot. And it the game will write 1 pixel. Memory writes are fast .. And therefore the DOOM engine is fast. But if you play DOOM in bigger resolution like 1024 and you use the MMU and the following will happen: every 2nd or 3rd pixel of the Walls that the game paints will be in another memory page. The MMU will need to load the translation of this page. This has a huge performance impact. Back to the discussion of the 68040 MMU we explained this The 68040 can map 256 KB max at the same time - using 4K pages. A game screen with 1024x768 (256 color) is already 3 times bigger than the MMU can map. This means that such a game, on this MMU would trigger a worst case scenario in which the MMU will do several memory reads by itself for every 3 rd pixel or so the game renders. This is a simple to understand - very bad case - where suddenly in the order of 25-50% of the CPU time is eaten by the MMU. This "nasty" worst-case MMU effect can be triggered by many programs being them many applications, database, games or demos. Using the MMU has always a cost, as the MMU needs to make memory reads which are slow. "Normally" the MMU costs are relative small, being just some percent System cost. But if you trigger a "nasty case" like this DOOM example - then the MMU cost can explode and the MMU can cost you up to even 50% time of your system I selected DOOM as example to discuss this before I thought that this is very easy to understand and most people would know how DOOM and similar games render.

OK, but even a column-based rendering doesn't change much the situation.

First of all, you've several TLB entries that can be used for mapping the pages of the single lines.

Second, hardware prefetchers can easily intercept those memory accesses regular patterns. If not, you can always use prefetch instructions to load in advance the pages that will be processed.

Third, you don't swap pages if you've enough memory (which is the case). So, you only have to map physical pages to the specific virtual pages.

Fourth, you can preload all pages used in the framebuffer, so that the pages used on the first two levels of indirection are already loaded when the rendering starts. This way only the pages at the last level need to be mapped each time, when the rendering happens.

Fifth... if you've full control of the system, then you can carefully manipulate the MMU descriptors in advance while the rendering happens, so that the impact becomes basically neglegible.

So, there are ways to improve the performance even when the MMU is enable with the regular 4k pages. At least for the normal cases, where the access to the memory is NOT totally random, rather quite regular.

Last edited by cdimauro on 23-Feb-2024 at 05:37 AM.

@Gunnar

Rumour has it that you, since I pointed out the joys of having a less than expected precise FPU, spent DAYS and HOURS figuring out how the heck to improve the precision in 68080 FPU used in V2 cards, and that you are now "polling" for interest, if you should put those DAYS and HOURS of extremely hard work... into the cores for V2 system? But perhaps for a little sum of money? Like maybe 7 8... ten euros? Any interest? Huh?

As someone who has struggled with this, also because the ability to turn off the FPU alltogether has randomly been not available through core updates...

No? Wtf? Pay again for what you first pretty much promised, said was ready and just needed testing, then said we never need anyways, then claim it will be impossible to fit, then manage to fit but in reduced form, and now - years later, say you can fit anyways, just DAYS and HOURS of work? So.... full effin circle? No, I'm not paying for that - if you have a "full" FPU (I understand 64bit, not 80bit extended precision) - after ALL these YEARS of nonsense DRAMA? Nah, not interested. Let those DAYS and HOURS be a waste!

Last edited by kolla on 22-Feb-2024 at 11:57 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

There is no question a MMU is useful for reliability but there is also no question that jitter goes through the roof. The 4 year newer 68060 did not add anymore ATC entries but then it was an embedded CPU.

1990 68040 ATC entries: 64+64
1994 68060 ATC entries: 64+64

The 64 entries was not much with 4kiB pages but they do support 8kiB pages. There are advantages and disadvantages of fixed size 4kiB pages, fixed size 8kiB pages and variable sized pages. A L2 ATC/TLB is a big improvement to reduce table walks in memory but jitter is still a problem. A lower clocked MCU with a MPU is a better choice for real time deterministic embedded systems. This is where optional modular MMU support for the 68k AmigaOS could be an advantage instead of requiring a MMU in AmigaOS 4. There could be 3 MMU AmigaOS settings.

MMU no support
MMU partial support (protect zero page & read only hunks, improve performance where possible)
MMU full support (maximum memory protection, process isolation where possible)

I expect "MMU partial support" would be a popular choice. I believe this would describe the AmigaOS 4 support as well?

Last edited by matthey on 23-Feb-2024 at 01:33 AM.
Last edited by matthey on 23-Feb-2024 at 01:32 AM.
Last edited by matthey on 23-Feb-2024 at 01:25 AM.

@matthey: full support isn't possibile with the Amiga OS, because it requires a complete redesign of its foundations.

Regarding the rest, the MMU is useful, but yes: you've a price to pay. Adding much more TLB entries help to reduce this cost.

However, it can still be used on real-time system if you "lock" the TLB entries of the code and data pages which are needed by the critical routines.