The demo scene has changed somewhat since the old days. One could argue it's pointless to write them for modern HW without constraints because of the insane processing power and graphics capabilities available. And maybe that's true but the other angle is to appreciate such things as a piece of performance art.

The PC demo scene tends to focus on artificial limitations like restricting to extreme size constraints. Doing so allows coders to flex their skill still. When Elevated came out in 2009 and showed a fully 3D ray marched procedural arctic landscape in 4KiB, complete with software synthesised soundtrack it was amazing.

Did that mean that farbraush's high end Magellan demo in 2010 was lame because it wasn't subject to any restriction? No. The crowd went wild all the same.

_________________
Doing stupid things for fun...

If you're not a multi millionaire or not an experienced programmer, then no, you can't help the community/platform.

_________________
Rock lobster bit me. My Workbench has always preferences. X1000 + AmigaOS4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." -Seymour Cray

@Tomppeli

Quote:

If you're not a multi millionaire or not an experienced programmer, then no, you can't help the community/platform.

Is this true?

In my experience to make something new on Amiga, lets say a game. You need several skills:

- coding
- some gfx talent painting
- a music talent
- someone spending time on level design
- good playtesters

Very important is intensive playtesting not only to find all bugs
but also to set the game difficulty and speed to a good level, so that
the game is not boring but also not to hard.

When my son did his last game, a very very important part was playtesting
and without Tolgod and many other good playtesters the game would not be what it is.
In my experience many people can help the community - also without any coding skills.

@Tomppeli

Quote:

an experienced programmer

Yes for making something new coding is often very important.
But how good and experienced does a coder really need to be.
Can only very experience coders make something?


In my experience many of todays Amiga games are actually ports.
There are two types of ports.
1) Ports where you rewrite the whole game yourself optimized to the new target.
For this you need to be an experienced coder.

2) Ports which recompile an existing C source.
For this you actually not need to be a experienced programmer.
Sometimes you can even do a game recompile without any programming at all.


Also with tools like SCORPION ENGINE, can you not make a game without being a code at all?

And in my experience coding on 68K is intuitive and easy to learn.
I have seen people that just started learning to code on Amiga making a nice fun game, while learning to code.

Last edited by Gunnar on 25-Feb-2024 at 06:58 AM.

@Gunnar

Quote:

Gunnar wrote: @cdimauro Quote: the context was x86 MMU Was the real topic not "AMIGA and 68K"? And is this forum not called AMIGAWORLD ? I find it very irritating that Hammer always tries to use x86 as smoke candle if he lack 68k knowhow. Lets us not do the same?

As you know, on a forum you can start discussing something and you can easily start other, parallel, "sub-discussions" on topics which are not exactly the same of the original one.

This is exactly what happened, and chronological looking at the comments you can clearly see that I jumped-in only when the discussion was talking about the x86 (P)MMU. And I've gave the proper answers on that.

If you want to switch back to the Amiga, I've absolutely no problem.
Quote:

I think the original topic was - That the 68040 MMU was designed in the 80th, - at a time when one floppy did hold a complete OS. - And when many computer had 512KB memory. The Apollo Machines today have thousand times more memory. today programs want to use a lot more memory than in the 80th. This means the use case did change. Therefore taking an 68040 MMU 100% as it was designed in the 80th but with not matching the circumstances. I think we can agree that it makes sense to evolve the MMU to match the amount of memory.

I agree, but you can also see that similar systems evolved as well but their code is still usually running with 4kB pages, even when they have several GBs (I've 32GB each on my two top PCs).

Here if you want to have a bit more flexibility, you can ALSO introduce large pages (4MB, like x86? But they are too much to me and mostly useful for server applications) while keeping the 4kB ones. That's how the current mainstream systems work: the Page Directory/Table entry have a bit where only this page is signaled to be large (4 or 2MB in size), while all others stays the same (4kB).

Especially on the Amiga, I don't that it's a good using only large pages.
Quote:

The game DOOM/ Wolfenstein/ HERETIC/ Comanche .. are very simple examples of how you can very easily create a situation that will overload the MMU. Do we all understand this? Is it all clear to all here, how the DOOM example with higher resolution does create an problem for the 040 MMU?

Well, it's also clear that DOOM is an example of the past, where most of the systems (386) where without data cache and the PMMU wasn't enabled.

As you stated before, we should know how the system works for writing an applications which squeezes the most from it.

This MIGHT be the case with DOOM when running on a modern system which doesn't allow anymore to just store values in memory without being forced to read the entire data cache line. Better to rewrite it from column to row-based.

@Gunnar

Quote:

Gunnar wrote: @cdimauro Quote: I don't think that he hates. The opposite: he recognize your value and he would like you have you supporting his ideas about a new, better for the future, Amiga platform. My goal is to revive Amiga. So giving the Amiga a better future is absolutely what will support. Matthey I'm open to leaving the past in the past - and to look forward to do what can be done for Amiga.

Wise decision. I don't think that you'll find someone more motivated, passionate and competent to help on that.


@CosmosUnivers

Quote:

CosmosUnivers wrote: @Gunnar Quote: Did anyone here wonder why Matthey hates me so much? Gunnar, your are the MOST evil guy in our community : you fragmented a first time our machine with your junk PPC with the help of your friends Phase5... Was not enough for you, you strike back with the AMMX many years later... You have some technical knowledge with a low IQ : you are the perfect stupid, you believe you can fool all of us with your lies : no, you can fool only the idiots like you ! You are incapable to understand this evidence : YOU CANNOT FOOL THE CLEVER PEOPLE ! So, all your team is a bunch of stupids, a clever guy will never work with you because he see you are only an actor : you will never save anything in your life, only sink deeper our machine... Buy a brain, really !

Projection? Cosmos, you're a clear example of much toxic is the fanatism.

You're a blind die-hard Taliban of 68k and you want to keep it as it. Which COULD make sense if there's no plan to evolve it. But, if you've read some comments here, this is NOT the case, right?

I suggest you to do NOT exit from your cave and live prosper with your unmutable 68k system.

@cdimauro

Quote:

when running on a modern system which doesn't allow anymore to just store values in memory without being forced to read the entire data cache line. .

You misunderstand this.

You can always on any System write to memory without loading the whole cache line first.

If you think about it, then you will immediately see that a System
that could not write without reading could NEVER even boot from harddrive.

You always need to be able to poke some register without reading them
this is needed for any IO device, CDrom or Hardrive, this is needed for Network card, or Amiga chipset.
And if you can do this on your Harddrive then you can do the same on memory.

@cdimauro

Quote:

Well, it's also clear that DOOM is an example of the past, where most of the systems (386) where without data cache and the PMMU wasn't enabled.

DOOM was a simple example

No, this is not a thing of the past.
The situation that I tried to highlight can be triggered today too


One thing shows very clear in this discussion about MMUs :
= people argue here without any understanding what we talk about!
No one here has any experience in how to code an MMU.



I do not understand why some people like to talk BS about areas they have zero clue about.

This house of cards falls immediately apart as soon a single person with experience participates.

@Gunnar

Quote:

Gunnar wrote: @cdimauro Quote: when running on a modern system which doesn't allow anymore to just store values in memory without being forced to read the entire data cache line. . You misunderstand this. You can always on any System write to memory without loading the whole cache line first. If you think about it, then you will immediately see that a System that could not write without reading could NEVER even boot from harddrive. You always need to be able to poke some register without reading them this is needed for any IO device, CDrom or Hardrive, this is needed for Network card, or Amiga chipset. And if you can do this on your Harddrive then you can do the same on memory.

There's no misunderstanding from my side, rather you should pay more attention about what poeple write.

What's no clear to you about this:

This MIGHT be the case

?

The word was in upper cases to make it more evident.

Besides that, I've already asked you a question about that and you never give a feedback.

However this doesn't stop you to randomly complaint instead of taking your time to READ and UNDERSTAND what the people write.

Last but not really least, if you don't want to give any feedback on proper questions then at least have the decency to shut yourself the mouth and don't write again the same things like a parrot on the same topic...
Quote:

Gunnar wrote: @cdimauro Quote: Well, it's also clear that DOOM is an example of the past, where most of the systems (386) where without data cache and the PMMU wasn't enabled. DOOM was a simple example No, this is not a thing of the past. The situation that I tried to highlight can be triggered today too One thing shows very clear in this discussion about MMUs : = people argue here without any understanding what we talk about! No one here has any experience in how to code an MMU. I do not understand why some people like to talk BS about areas they have zero clue about. This house of cards falls immediately apart as soon a single person with experience participates.

I don't know now if you are another one which suffers from function illiteracy, because I've to quote again myself:

where most of the systems (386) where without data cache and the PMMU wasn't enabled

What's not clear to you about that? Do you understand that there was NO MMU (neither cache) involved on this part of the discussion.

However and not only about, what's not clear to you about this:

we should know how the system works for writing an applications which squeezes the most from it

and this:

Better to rewrite it from column to row-based.

?

Since you've serious problems on your own, let me rewriting it a much simpler way.

IF the processors work differently NOWADAYS and this causes problems with legacy applications (read: performance loss), then maybe their code needs to be adapted to better fit how the systems work now.

Last but not really least, I've also written how to minimize the impact of such a case on system with an active MMU:

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.

Is it clear now or should I've to draw some pictures like at the elementary school?

@cdimauro

Quote:

Is it clear now or should I've to draw some pictures like at the elementary school?

Cesare about every post you made in this thread has one or several misunderstandings/nonsense content in it.

I did not care to correct them.
But there are tons of misunderstandings and mistakes in your posts.


This looks to me like you not understand anything about the topic.

What I not understand is why you continue to post trying to create an impression you know to topic?

Because everytime you post a mistake and this is pointed out.
You post a new post with more wrong assumptions and more misunderstandings and more mistakes.

As more you wiggle around as more nonsense you post and as more clear is that you not know the topic.

Why do you have this need to do this?

@Gunnar

Quote:

Gunnar wrote: @cdimauro Quote: Is it clear now or should I've to draw some pictures like at the elementary school? Cesare about every post you made in this thread has one or several misunderstandings/nonsense content in it. I did not care to correct them. But there are tons of misunderstandings and mistakes in your posts. This looks to me like you not understand anything about the topic. What I not understand is why you continue to post trying to create an impression you know to topic? Because everytime you post a mistake and this is pointed out. You post a new post with more wrong assumptions and more misunderstandings and more mistakes. As more you wiggle around as more nonsense you post and as more clear is that you not know the topic. Why do you have this need to do this?

Repeating the same things like a parrot will not make them true.

In the previous comment I've already answered point by point to your false accusations.

In this post I don't see any rebuttal of what I've written, rather your classic: "you are wrong". So, people should believe you only because you've written it. But you should understand that this doesn't work, right?

Anyway, my previous comment has shown that you've functional illiteracy problems. You don't get what I write, and start writing non-sense.

But do you know what? It's not my problem...

@cdimauro

Quote:

Repeating the same things like a parrot will not make them true.

You say pretty much everyone who do not agree with you is a parrot,
does not make any statements untrue.

Last edited by NutsAboutAmiga on 25-Feb-2024 at 04:19 PM.
Last edited by NutsAboutAmiga on 25-Feb-2024 at 04:19 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@cdimauro

Quote:

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.

This is nonsense. As this is not possible.
That you propose this, shows again that you not know how an MMU works. :-/


Even if this would be possible (which is not)
It would not solve the performance problem that we spoke about.
That you think it would solve anything - shows us again that you not understand the topic.

Cesare, I could go over 20 or 30 nonsense post from you and rip them apart.
Please lets stop here.
Or do you really want that we proof you wrong 30 times?


Cesare, you remind me on a guy on a party pretending he could speak a foreign language which in fact he can not speak a single word.

Why do you want to be the guy pretending to speak Italian by making funny non existing words that sounds like Italian?

Why do you continue this - even when native Italian speakers are at the party?

@cdimauro

Quote:

Here if you want to have a bit more flexibility, you can ALSO introduce large page

Could it be that you misunderstand what we talk about?

Cesare the topic was that I explained the people here
why the the Apollo 68080 MMU did implement certain improvement and changes.
E.g. Why the Apollo MMU supports larger pages.

If you want to give me now "ideas" like adding large pages - then you are 10 years to late for this.
The Apollo 68080 MMU already supports this since ages!
Cesare please understand this is not a brainstorming!


Cesare you way of talking is tiring.
You want to "discuss" even when you not fully knowledgeable.
And when you not really know that to say then you "take detour" and talk about INTEL ..
and when people point out that you talk nomnsense , then you take another detour and talk more nonsense

For every mistake that you get pointed to, you reply with another detour post with 3 mode things you misunderstand. This is a never ending nonsense.

Last edited by Gunnar on 25-Feb-2024 at 06:48 PM.

@Gunnar

Quote:

where most of the systems (386) where without data cache and the PMMU wasn't enabled What's not clear to you about that? Do you understand that there was NO MMU (neither cache) involved on this part of the discussion.

No, the DOOM game example was selected on purpose to explain the MMU problems that an 68040 can face with higher game resolution and this game.

Now you derail the topic and try to talk about the PC,
and you claim DOOM would be a game for PC without cache,

Is this correct?
No

DOOM was released in DECEMBER 1993.
This means DOOM did come out nearly 1 year after the Pentium!

The games written like DOOM are Heretic and HEXEN.
These are games from 1994 and 1995.

Claiming that this software was written before CPUs had caches - as you said
is of course not correct.

Doom did target 486 and Pentium.
And of course they have both MMU and caches.
And even the i386 had an MMU with 32 TLB entries.
Mind that even i386 System had Caches - the Caches of the i386 were external on the mainboard.


DOOM,HERETIC,HEXEN and so on, are just examples to help to visualize a very simple problem.

There are technical solutions even to this. You use the DTTR/BAR registers for example.
You can hardwire the Expansion space to set the NoCacheFlag.
Of course none of them does solve this perfectly.
But that you not see this but instead try to argue DOOM was for CPU without caches ..
Seriously?

Last edited by Gunnar on 25-Feb-2024 at 07:53 PM.

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @cdimauro Quote: Repeating the same things like a parrot will not make them true. You say pretty much everyone who do not agree with you is a parrot, does not make any statements untrue.

That's wrong, "nuts". You added a false condition that need to be satisfied: "who do not agree with you".

In fact, I've said that someone is acting as a parrot "just" because he repeats the same things. Dot.

As usual, you face severe logical problems. Which, again, isn't my problem.

I understand that many times I've rebutted your statements and you might be upset with me, and you want your childish revenge now this post, but... sorry for you: you've to wait another opportunity (if it ever comes).


@Gunnar

Quote:

Gunnar wrote: @cdimauro Quote: 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. This is nonsense. As this is not possible. That you propose this, shows again that you not know how an MMU works. :-/ Even if this would be possible (which is not) It would not solve the performance problem that we spoke about. That you think it would solve anything - shows us again that you not understand the topic. Cesare, I could go over 20 or 30 nonsense post from you and rip them apart. Please lets stop here. Or do you really want that we proof you wrong 30 times? Cesare, you remind me on a guy on a party pretending he could speak a foreign language which in fact he can not speak a single word. Why do you want to be the guy pretending to speak Italian by making funny non existing words that sounds like Italian? Why do you continue this - even when native Italian speakers are at the party?

Gunnar, actually YOU have shown that you don't know how a (modern) MMU works, right? The above statement is true, and if you still don't understand it then I give you an example here.

Let's assume that we've 256 colours (that's what DOOM used to have) FullHD framebuffer which was allocated and that the processor (a x86, of course. Since that's what I was talking about all times in this part of the discussion) with the MMU enabled.

This takes 2073600 bytes of memory, which means 507 4kB pages that need to be mapped by the MMU. Since the x86 MMU uses 4kB pages for its Page Directory and Page Table and each entry on those data structure takes 4 bytes, then they can hold up to 1024 entries each. So, it means that a page table is able to hold the entries of the entire framebuffer (507 pages are needed). It also means that just one entry of the Page Directory (the topmost structure in the page hierarchy) just needs a single 4 byte entry to keep the pointer to the used Page Table.
If you need more details on that you can take a look at Intel's System Programming Guide, Chapter 4 (Paging) where there's the nice Figure 4-2 ("Figure 4-2. Linear-Address Translation to a 4-KByte Page using 32-Bit Paging") which shows it in details.

So, if you "touch" all pages in the framebuffer, then you've preloaded (pay attention to this word) in the data cache (the one which is used for mapping such memory. As usual) the needed 4 byte of the Page Directory and all entries of the Page Table which are needed for the translation from the virtual to the physical address.

Now do you finally understand my statement above? Let's see, albeit I've serious doubts, because you also don't pay attention to precise WORDS (I highlighted) that I've written.
Quote:

Gunnar wrote: @cdimauro Quote: Here if you want to have a bit more flexibility, you can ALSO introduce large page Could it be that you misunderstand what we talk about? Cesare the topic was that I explained the people here why the the Apollo 68080 MMU did implement certain improvement and changes. E.g. Why the Apollo MMU supports larger pages. If you want to give me now "ideas" like adding large pages - then you are 10 years to late for this. The Apollo 68080 MMU already supports this since ages! Cesare please understand this is not a brainstorming!

No, I was perfectly in THIS part of the discussion and now you've shown again that you miss to understand what people are writing. Again, functionally illiterate issues? You're badly aging, eh!

Yes, I know that you have only implemented large pages on the 68080 MMU (because it's easier for you).

Yes, I know that you're advocating such large pages AND you clearly are NOT inclined to introduce 4kB pages (because it complicates your implementation and slows down the execution).

But on that part of the discussion I was repeating (I don't know how many times now) that 4kB pages is the page size normally used and which is best and expected to be implemented on a processor (whatever) and, ON TOP OF THAT, you can ALSO (that's why I've highlighted this word) add the large pages.

That's because having only page pages on a systems is NOT recommended for ALL applications. They are useful only on some cases, like for server applications.

Is it finally clear now?

Could I kindly ask to be more focused on how the discussion goes, what people are writing, and WHY they are writing some statements?

I mean: it's not Oxford English neither a philosophical debate which requires high level of attention, right? The average Joe should be able to follow and reply according...
Quote:

Cesare you way of talking is tiring. You want to "discuss" even when you not fully knowledgeable. And when you not really know that to say then you "take detour" and talk about INTEL ..

Ehn, no. YOU were the ARMCHAIR QUARTERBACK (I used your words) that talked about x86's MMU reporting FALSE and MISLEADING information them.

Let me quote YOU again:

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.

AFTER that I've replied clarifying that no, even nowadays x86's MMU work the same way as the 386. Yes, using 4kB pages and have two levels fo indirection when translating the virtual addresses.

Here you've shown that you don't know how a modern x86 processor and OS work.

And not only that, since after that I've written this:

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.

then you've stated also this:

You misunderstand this.
We are talking NOT about Data Cache misses.
We are talking about ATC-misses. ATC are NOT Data-cache.

Which have shown that you don't know how a modern x86 processor works. In fact, I've reported this:

4.10.2.3 Details of TLB Use
Subject to the limitations given in the previous paragraph, the processor may cache a translation for any linearaddress, even if that address is not used to access memory. For example, the processor may cache translations required for prefetches and for accesses that result from speculative execution that would never actually occur inthe executed code path.

from the above System manual, and then you've stopped replying (guess why).

Is it too much asking to do NOT talk about things that YOU, Gunnar, don't know?

Why are you acting like an ARMCHAIR QUARTERBACK for x86 processors, that you clearly have shown that you've no knowledge about them?
Quote:

and when people point out that you talk nomnsense , then you take another detour and talk more nonsense For every mistake that you get pointed to, you reply with another detour post with 3 mode things you misunderstand. This is a never ending nonsense.

See above, then please shut your mouth then instead of talking of things that you've no clue.
Quote:

Gunnar wrote: @Gunnar Quote: where most of the systems (386) where without data cache and the PMMU wasn't enabled What's not clear to you about that? Do you understand that there was NO MMU (neither cache) involved on this part of the discussion. No, the DOOM game example was selected on purpose to explain the MMU problems that an 68040 can face with higher game resolution and this game. Now you derail the topic and try to talk about the PC, and you claim DOOM would be a game for PC without cache, Is this correct? No DOOM was released in DECEMBER 1993. This means DOOM did come out nearly 1 year after the Pentium! The games written like DOOM are Heretic and HEXEN. These are games from 1994 and 1995. Claiming that this software was written before CPUs had caches - as you said is of course not correct. Doom did target 486 and Pentium. And of course they have both MMU and caches. And even the i386 had an MMU with 32 TLB entries. Mind that even i386 System had Caches - the Caches of the i386 were external on the mainboard. DOOM,HERETIC,HEXEN and so on, are just examples to help to visualize a very simple problem. There are technical solutions even to this. You use the DTTR/BAR registers for example. You can hardwire the Expansion space to set the NoCacheFlag. Of course none of them does solve this perfectly. But that you not see this but instead try to argue DOOM was for CPU without caches .. Seriously?

Here, again, you show to do NOT read what people write or, even worse, that you've serious functionally illiterate issues.

WORDS (highlighted) are important and you should CAREFULLY pay attention on what was written.

First of all, DOOM is a PC game. Yes, after some YEARS it was also ported to different platforms, Amiga / 68040/68060 included, but that wasn't part of what I was talking on.

Let's examine my previous sentence, which I report here for COMPLETENESS, since you artificially extracted just one part, so LOSING ITS CONTEXT:

Well, it's also clear that DOOM is an example of the past, where most of the systems (386) where without data cache and the PMMU wasn't enabled.

I "translate" it for YOUR convenience, explaining its meaning.

First of all, DOOM is an old application (game) which was targeting the PC (again: PCs!) of those days. So, PCs was the reference platform for their developers (and the software house which published it). This a FACT. Target = PC (of THAT time). Right?

AT THE TIME we know that MOST OF THEM ("most of the systems") were 386s. Yes, 386. Because newer systems were EXPENSIVE. Yes, you can use 486s and even Pentium running DOOM, but this doesn't change the fact that MOST OF PCs (where DOOM was played) were 386. This is another FACT. MOST PCs were 386s. Right?

We (at least me) also know that 386s were... without data caches. This is another FACT. 386 had no data caches. Right?

Yes, some 386 had also EXTERNAL caches. However those were NOT data caches, rather general-purpose caches: they kept both code and data. This is another FACT. 386 had no DATA (pay attention: DATA) caches. Right?

Now, we know that there were 486s and Pentiums, but this doesn't change my sentence which reported that MOST OF PCs were 386s and that was the target for games (not only DOOM) in general. That fact that they were available is and was irrelevant, because I've talked about the situation of the time, where MOST OF PCs were 386s.
Yes, I know: I've written many times but this is for YOUR convenience, since you aren't able to understand what people write. So, I need to repeat you several times in the hope that if finally fits in you brain.

However and regarding the main topic, I've also reported the most important information: "the PMMU wasn't enabled".

In fact, DOOM was running on a DOS Extender (if you don't know what it is and how it works, you can search around and you should find plenty of information. If you're lost, just ask me and I'll do this for you, since I know very well such things), so in 386's protected mode, but... WITHOUT paging enabled, since the OS running there was the old, 16-bit, DOS and there's no need of virtual addresses (not even for DOOM itself).
This is another FACT. The PMMU was DISABLED. Right?

OK, that's all. You should have understood yourself (hopefully, but you seem to be hopeless since you continue to repeat the same things like a parrot) the meaning of my previous (FULL, not cut!) sentence, right?

Now that everything should be clarified, dear ARMCHAIR QUARTERBACK which don't know how games like DOOM were developed at the time and how they effectively were working, do you care to CAREFULLY READ AND UNDERSTAND what people write BEFORE replying again with the same non-sense? Many thanks...

Last edited by cdimauro on 26-Feb-2024 at 07:48 AM.

@cdimauro

Cesare the topic was how certain applications or games using a lot memory can trigger problems with MMU mapping.


DOOM, HERETIC was just taken as simple example.


DOOM and HERETIC are very good examples as they write the screen not sequential
and this movement puts more stress on the MMU.


Sequential memory access run usually good with MMU tables.
A simple memory copy, that copies 1 MB of data.
It would for every for every 4096 Byte it writes, need to load 1 time the MMU entry.
This is a very minor overhead = no problem.


Writing in columns means that you touch a lot more pages.
In our example with screen size 1024 - the CPU would need for every 3 byte it writes to load a new MMU entry = this overhead is killing the system.

1 ATC load for 4096 byte versus 1 ATC load for 3 byte
= 1300 times more overhead because of the order the memory is accessed.

Very simple example, that should be very easy to understand.

And this was only an example, we can talk about drawing Windows decorations on Workbench Screen...
Drawing Scrollbar, there are many use cases triggering the same problems.


Looking here for a solution to improve and help all these application - makes in my opinion a lot sense.

Whether you believe DOOM and HERETIC and HEXEN were in 1995 coded for i386 - makes no difference.

@Gunnar

Quote:

Gunnar wrote: @cdimauro Cesare the topic was how certain applications or games using a lot memory can trigger problems with MMU mapping. DOOM, HERETIC was just taken as simple example. DOOM and HERETIC are very good examples as they write the screen not sequential and this movement puts more stress on the MMU. Sequential memory access run usually good with MMU tables. A simple memory copy, that copies 1 MB of data. It would for every for every 4096 Byte it writes, need to load 1 time the MMU entry. This is a very minor overhead = no problem. Writing in columns means that you touch a lot more pages. In our example with screen size 1024 - the CPU would need for every 3 byte it writes to load a new MMU entry = this overhead is killing the system. 1 ATC load for 4096 byte versus 1 ATC load for 3 byte = 1300 times more overhead because of the order the memory is accessed. Very simple example, that should be very easy to understand. And this was only an example, we can talk about drawing Windows decorations on Workbench Screen... Drawing Scrollbar, there are many use cases triggering the same problems. Looking here for a solution to improve and help all these application - makes in my opinion a lot sense. Whether you believe DOOM and HERETIC and HEXEN were in 1995 coded for i386 - makes no difference.

And I've no problem to accept it. That's why I've written that those are old games coded when platforms (PCs) were different and, hence, different decisions were made. And this is exactly the reason why I've written this:

we should know how the system works for writing an applications which squeezes the most from it
[...]
Better to rewrite it from column to row-based.

So, if there's an old game (or an application, in general) that suffers from not being able to squeeze the most from the current systems, then maybe it's better to review it (at least the "offending" part).

In fact, at the time the MMU wasn't used even if it was there. So, there's no point on discussing about how badly the MMU impacts on games like DOOM, since this game (and many others) were developed and running on an OS/platform which had paging disabled.

But if you take its code and wants to run on it on a modern platform which has paging/MMU enabled, then it's a completely different thing now. And here comes my suggestion: it's better to rewrite its relevant part.

I how that it's more clear now.

@Gunnar

Quote:

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. (SNIP)

It's the end user that determines the platform's performance acceptance.

I hated IBM's 286 holdouts with their IBM-led OS/2 development, hence IBM deserves to lose the PC market during the 386 era.

Any PC with the 386 CPU has the potential to run PMMU-enabled OS such as Linux, BSD, Mach, Windows NT 3.x, and Xenix 386.

Windows NT 3.1's recommended minimum system requirements on x86 systems include a 25 MHz 80386 processor, at least 12 MB RAM, 75 MB of hard drive space, and a VGA graphics card.

Windows 3.1 Enhanced Mode uses 386's MMU features e.g. virtual memory. Windows 3.1's 32-bit hard disk access mode is self-sufficient from DOS.

Windows 3.x gradually added 32-bit capabilities (e.g. 32-bit hard disk access, Win32S, WinG, virtual memory) to its 386-only “Enhanced Mode�, progressively paving the road to Windows 95.

The 1st Linux release was programmed on an Intel 386-based PC. IBM has purchased Red Hat Linux in 2019, LOL. How the mighty has fallen.

Linux won on its low entry price on commodity X86 and ARM hardware.

Intel 386 is the cornerstone for Windows NT i386 and many Unix i386 clones.

X86-64's long mode wasn't initially used when it was introduced, but it builds the install base to make important investment software business decisions, hence beating IA-64 Itanium and PowerPC 64bit during the 64-bit desktop transition phase.

Guaranteed 386 MMU is important for building Wintel's 386 MMU capable install base.

If the hardware's performance is slow for the given software, then there are faster X86 CPU models on the horizon.

For modern desktop computers, it's useless to have hyper-fast AmigaOS 3.x on a hyper-fast CPU when it's unstable.

https://www.youtube.com/watch?v=6P7-HuD3urg
NeXTcube 68040 25Mhz, 40 MB RAM, and 660 MB hard disk. This workstation was used to develop Wordperfect. NeXTSTEP on the 68040-based system is real.


https://www.youtube.com/watch?v=9Phk3qVUPqw
Apple's A/UX Unix with MacOS's UI on Quadra 700 with 68040 @ 25 Mhz.

https://www.youtube.com/watch?v=3-q2lLWrW-0
HP Apollo 9000/400t, booting HP-UX 9 (big endian Unix) with XWindows UI with 68040 @ 25 Mhz and 24 MB RAM.

https://www.youtube.com/watch?v=-SNJHjkvl2E
Amiga 3000 running AMIX (Amiga Unix, 1992) with XWindows GUI

https://youtu.be/VcpSMY1qkVQ?t=399
RedHat 5.1 m68k on Amiga 2000's Blizzard 2060 with 68060, lots of FAST RAM, and CyberVision64 3D (S3 ViRGE 3D).


I'm aware of slow MMUs that can impact users' use cases, but 68040 seems to be fast enough for HP-UX 9 and 24 MB RAM. The problem is HP's asking price for their 68K Unix machines.

Modern X86-64 CPUs have sizable TLB caches e.g.
AMD's Zen 4 has 3072 entries for the L2 TLB cache.
Intel’s Golden Cove also has 2048 entries for the L2 TLB cache

Last edited by Hammer on 26-Feb-2024 at 08:36 AM.
Last edited by Hammer on 26-Feb-2024 at 07:58 AM.
Last edited by Hammer on 26-Feb-2024 at 07:46 AM.
Last edited by Hammer on 26-Feb-2024 at 07:35 AM.
Last edited by Hammer on 26-Feb-2024 at 07:20 AM.
Last edited by Hammer on 26-Feb-2024 at 07:13 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)

@Hammer

HAMMER THIS FORUM IS AMIGAWORLD

Your post is not related to Amiga at all.