@Jose

While the 68K Family in general supports MMU.
Each 68k MMU works differently and needs be programmed in its "own" way.

As you will know a MMU is not meant to be used/programmed by any software or program.
The MMU is a tool that only the operating system is allowed to use.

As the MMU is used for managing Memory, the design of the MMU changed the same way a Memory Chips changed many times over the year.

This means that the MMU of the 68030 made after some years not much sense ..
and the 68040 has therefore a different MMU.

Of course also the design of the 68040 made after some years not much sense ...
And today a useful MMU would be done differently of course.

You will recall the first Amiga was first sold with 0.25 MB only ...
This was quickly doubled to 0.5 MB ..
And later Amigas had 1 MB or 2MB and you could of course upgrade them.

Today our Amiga comes with 512 MB..
Maybe we will have models with 2028 MB at some point.

I think its very easy to understand that an MMU which was designed to manage 1-8 MB
might do a very bad job when you have 100 MB or 1000 MB memory.
As you know AMIGA OS does not use MMU.

The Apollo 68080 CPU has a modern MMU which is designed for modern amounts of memory.
You can use it for debugging on Amiga too.
We have a tool named "ApolloShield" which provides debug/memory protection similar to Enforcer

@Gunnar

Its almost as if you’re advocating for system friendly coding.

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

@Gunnar

I haven't coded anything in a few years, it just downed on me that my comment is not totally correct in the sense that one doesn't actually need an MMU to run CodeProbe... But it helps.. From the manual: "The debugger automatically detects Enforcer hits caused by your program and halts your program at the location of the hit. "
So I guess the correct question should be, can ApolloShield work together with CodeProbe the same way Enforcer does ?
I guess people are ditching SASC these days but I like it, you can also code and debug on it and have the final executable made on VBCC / GCC, which is what I used to do.

_________________

José

@Jose

Quote:

I haven't coded anything in a few years, it just downed on me that my comment is not totally correct in the sense that one doesn't actually need an MMU to run CodeProbe... But it helps.. From the manual: "The debugger automatically detects Enforcer hits caused by your program and halts your program at the location of the hit. " So I guess the correct question should be, can ApolloShield work together with CodeProbe the same way Enforcer does ?

I have not used CodeProbe - therefore I would need to guess.

As the mechanism of how the Apollo 68080 MMU reports a hit and with what information, and how the previous, older MMU models reported a hit and with what information - is the same.
The Apollo 68080 MMU is here fully backward compatible.

Therefore it sounds like it could work to me.

@Jose

The MMU can be used for detection of bugs as you say.

MMU can provide virtual memory objects like in AmigaOS4.x.
(Moves high memory into low memory for a short time.
Ideal for disk cache or temp files, etc.)

MMU can provide virtual memory, for systems with not a lot memory installed.

It can be used for stack enlargement, but then stack will need to be virtual. (Like on UNIX where stack program is always in same address spaces.), the drawback on that is that local variables can’t be shared, as they are on stack. but it can be possible with a little sacrifice.

Currently its used for red zone detection, if stack grows above allocated size, it brings up Grim Reaper, before it can do any harm.

I have thinking that if stack was not linear, but more like a table, (with rows and columns) it solves stack enlargement issue, can perhaps be solved without, a MMU. But can require different compilers.

The MMU can be used for exceptions, and emulation, like NallePuh does.

Last edited by NutsAboutAmiga on 17-Feb-2024 at 11:47 AM.
Last edited by NutsAboutAmiga on 17-Feb-2024 at 11:46 AM.
Last edited by NutsAboutAmiga on 17-Feb-2024 at 11:44 AM.
Last edited by NutsAboutAmiga on 17-Feb-2024 at 11:34 AM.
Last edited by NutsAboutAmiga on 17-Feb-2024 at 11:32 AM.
Last edited by NutsAboutAmiga on 17-Feb-2024 at 11:28 AM.

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

NutsAboutAmiga Quote:

The MMU can be used for detection of bugs as you say.

A Memory Protection Unit (MPU) can be used to protect memory and detect bugs.

NutsAboutAmiga Quote:

MMU can provide virtual memory objects like in AmigaOS4.x. (Moves high memory into low memory for a short time. Ideal for disk cache or temp files, etc.) MMU can provide virtual memory, for systems with not a lot memory installed.

A MPU is not adequate for virtual addressing and virtual memory which requires a MMU. The virtual address to physical address translation has overhead and uses resources so any performance improvement from translating addresses to the lower address space to use shorter absolute addressing modes (improving code density) is partially offset.

NutsAboutAmiga Quote:

It can be used for stack enlargement, but then stack will need to be virtual. (Like on UNIX where stack program is always in same address spaces.), the drawback on that is that local variables can’t be shared, as they are on stack. but it can be possible with a little sacrifice. Currently its used for red zone detection, if stack grows above allocated size, it brings up Grim Reaper, before it can do any harm. I have thinking that if stack was not linear, but more like a table, (with rows and columns) it solves stack enlargement issue, can perhaps be solved without, a MMU. But can require different compilers. The MMU can be used for exceptions, and emulation, like NallePuh does.

A stack needs to appear linear to programs or there are multiple stacks. Non-linear stack memory can appear linear by using virtual addressing which is not possible with a MPU. It is possible for a MPU to detect stack overflow before memory corruption but a MMU is likely needed to enlarge the stack. With an AmigaOS stack, multitasking would need to be turned off to enlarge the stack where it is using shared memory. It wouldn't be compatible to change this behavior.

Speaking of using shared memory (MEMF_SHARED in AmigaOS 4), it may be possible to add a MEMF_SHARED bit into MMU pages like read-only and no execute bits. When a shared memory page is accessed, the CPU core could set a dirty bit in a per core register. If the dirty bit is set, the pipeline of the core would need to be flushed/synced when the core is stopped for a SMP Forbid() but otherwise would not need to be flushed/synced. With a little more logic in cores, cores could continue to access MEMF_PRIVATE memory but stalling when trying to access MEMF_SHARED memory. Allowing cores to execute code accessing MEMF_PRIVATE memory during Forbid() could improve the efficiency of SMP while retaining AmigaOS compatibility. Custom hardware could also increase the efficiency of SMP core communication with signal lines to cores to flush and sync if they are dirty with MEMF_SHARED memory accesses before continuing to execute code with MEMF_PRIVATE memory accesses. While 68k AmigaOS 3 software does not use MEMF_PRIVATE flags, some memory could be optionally upgraded like memory allocations not using the old MEMF_PUBLIC flags and some executable hunks. AmigaOS 4 software ported to the 68k AmigaOS would require minimal changes.

AmigaNG FPGA hardware for the 68k Amiga should have used a larger and more expensive FPGA with more than 4 GiB of memory. This could have allowed at least 2 CPU cores for SMP and 64 bit ISA testing. The V4/AC makes the same mistake as AmigaOS 4 hardware which was failing to develop and test important modern CPU features. The V4/AC doesn't have access to the AmigaOS but they could develop NG features for AROS like I suggested above. A larger FPGA is typically used in CPU development for an ASIC as well. I pushed for larger FPGAs and ASIC planning as part of the AC team. I also suggested a more business like organization, finding business partners that could help with ASIC development and/or share costs and raising funds toward that goal. Some things are too hard, especially in Amiga land.

Last edited by matthey on 18-Feb-2024 at 10:14 AM.
Last edited by matthey on 17-Feb-2024 at 10:18 PM.

@Gunnar

Quote:

Wouldn't it be nice if the Amiga community would work together and we all do our part to make Amiga great again?

I swore to myself, if I will ever make something specific for "Amiga" it must be X-Platform compatible.

But to be honest, SDL2 isn't the best solution for 68k AGA systems.

Last edited by OneTimer1 on 17-Feb-2024 at 11:46 PM.

@matthey

MPU or Micro Processor Unit, similar to CPU’s but they often contain flash memory. nice small simple CPU for dishwashers.

https://www.globalspec.com/learnmore/semiconductors/microprocessors_microcontrollers/microprocessors

Last edited by NutsAboutAmiga on 18-Feb-2024 at 12:05 AM.

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

@matthey

Quote:

A stack needs to appear linear to programs or there are multiple stacks.

That’s what I’m suggesting. if you have Y list of stacks, your can have x array of data.
Y stack can grove as nothing points to it (so it can easily be replaced by larger stack allocation list). so, you always add more data, if you need it.
the growth of the stack is predictable, by the number of local variables in a function, etch you call a function, the stack can need to grove. There are other cases like local variables inside code blocks, or if’s.

Last edited by NutsAboutAmiga on 18-Feb-2024 at 12:21 AM.

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

@Gunnar

Yes

My impression is that often people talking about MMU have very unrealistic ideas and believes.


Maybe it helps to clarify a few items upfront.

Can an MMU help debug programs?
Yes, a MMU can help to find very bad Pointer bugs.


Will it find all coding errors?
No, the MMU only find some bugs, we talk here about a very low percentage of bugs.
There are more tools that also help, e.g. Mungwall not needs and MMU and also helpts to find Pointer bugs.

In fact using programming languages like Pascal or Modula instead C for coding
will avoid more coding bugs than the MMU can find on Amiga.


Will an MMU create a 100% stable system?
No, MMU can not provide this on Amiga.
The Amiga OS by design allows programs to talk to each other and to share data.
As program on Amiga are allowed to each other.
Most bug finding capabilities of the MMU is effectively nullified on Amiga.
And of course the MMU can not protect a programs from killing itself.
A CPU MMU will not protect the system from Blitter DMA or Zorro DMA
killing the system.

What drawbacks has virtual Memory?
Virtual memory copies memory to from harddrive.
As you will know harddrives have million times higher latency than memory.
This means "emulating" memory by copy memory to from harddrive
will make your system slower. This slow down can be very significant.
A normal CPU MMU can only emulate more memory if you do NOT allow DMA to access it. This manes the AMIGA design with Amiga chip doing DMA would need an extra IOMMU for this work fully.

Has using the MMU drawbacks?

Yes there are a lot drawbacks.

Using an MMU means you extra memory access of the MMU are needed to load MMU pointers and values. This can slow down the system by some percent.

The ideo behind the Unix like memory protection is not compatible with the Amiga OS design. On Amiga programs can talk directly to Joystick button and also to Blitter. Trying to enforce a protection here means you would break all existing Amiga software. 100% incompatible.

NutsAboutAmiga Quote:

MPU or Micro Processor Unit, similar to CPU’s but they often contain flash memory. nice small simple CPU for dishwashers.

Micro Controller Unit (MCU) https://en.wikipedia.org/wiki/Microcontroller
Micro Processor Unit (MPU) https://en.wikipedia.org/wiki/Microprocessor
Memory Protection Unit (MPU) https://en.wikipedia.org/wiki/Memory_protection_unit

It is a MCU which contains CPU core(s), SRAM for memory and sometimes flash memory although external flash is becoming more common. Sometimes the difference between a MCU, MPU and SoC are blurred. For example, some of the SiFive SoCs with U74 CPU cores have 2MiB SRAM that can be configured as main memory like a MCU or L2 cache like a MPU. This provides extraordinary versatility with a minimal cost increase from a more specialized chip.

NutsAboutAmiga Quote:

That’s what I’m suggesting. if you have Y list of stacks, your can have x array of data. Y stack can grove as nothing points to it (so it can easily be replaced by larger stack allocation list). so, you always add more data, if you need it. the growth of the stack is predictable, by the number of local variables in a function, etch you call a function, the stack can need to grove. There are other cases like local variables inside code blocks, or if’s.

I do not recommend physically non-sequential stacks using virtual addressing to join them. There is not enough of an advantage to increase complexity, increase memory requirements and potentially reduce compatibility. Optional stack overflow detection would be nice although it would use more memory to place a read-only page below the memory for the stack (stacks grow down in memory). Some compilers can produce executables with optional stack overflow detection so there is already an option for developers.

@Gunnar

Quote:

Gunnar wrote: My impression is that often people talking about MMU have very unrealistic ideas and believes.

My impression is you misunderstood the whole MMU issue in a rather strange way.

Fact: The Apollo cores are the fastest *68k compatible silicon* you can put in an Amiga.

You: We made the fastest and most enhanced 68k ever, we can beat everything else, especially PPC and the whole AmigaNG bunch with or 68080 SAGA and everything.

Critics: Your 68080 isn't as advanced, it doesn't even have a proper FPU and no MMU so there are some things that doesn't work ...

You: {triggered} ... we will have a much better FPU and a new designed MMU is on its way ...{/triggered}

Fact: It doesn't matter on 99% of software if you have an MMU or not, only a fraction of Amiga user ever used it and if there is a developer needing it, he can still take an existing 68030 driven Amiga or UAE and use it for his development.

----

Gunnar: Don't get triggered, stay real, keep compatibility as high as possible, try to deliver advanced stuff for GFX, Sound and UAE, make good prices and try to find out what your customers are really want ... that's all.

Last edited by OneTimer1 on 18-Feb-2024 at 02:57 PM.
Last edited by OneTimer1 on 18-Feb-2024 at 02:51 PM.
Last edited by OneTimer1 on 18-Feb-2024 at 02:50 PM.

@OneTimer1

As you correctly said some people here post false information to attack


Fact is that the APOLLO 68080 CPU already has an MMU
and there are also tools available to use it.


You can use the program ApolloShield to activate a memory protection and memory failure report.
In a way like Enforcer does.


Fact is the previous 68K MMU were incompatible to each other for good reason.

And again the Apollo 68080 MMU is incompatible.
And this is VERY GOOD this way.


Why is this good?
Because the 68080 can do more than previous MMU.
I offer better protection and better debug possibilities and it offer Jumpo pages.
All these are useful improvements.

@OneTimer1

The 68080 MMU is already busy at work, without it, the Vampires wouldn’t work. To expose the MMU fully in AmigaOS is pointless because whatever you would do with it, it would break the system. So instead only a few less harmful bits are exposed and used via dedicated tools.

If you were to build a different system using 68080, not targeting AmigaOS, then exposing the MMU would make much more sense.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Gunnar

Hi Gunnar,

I want to learn to code as I would like to make software for my Amiga.

I think one of the biggest problems is the fracturing of the community into different camps and the fierce loyalty people have to these different Amiga communities can and does affect the sharing of new developments etc.

I am enjoying the revival of Classic Amiga hardware and software development ie, Apollo accelerators, PiStorm, Warp by CS Labs, Terrible Fire etc to name a few of the hardware achievements. On the software front we have seen AmigaOS 3.2, the recent new games and new demos have been exciting also.

I was thinking the other day that it seems when there are new things happening people start using their Amigas more and that encourages development, the trick it seems is to keep people engaged and using the Amiga.

So how do we keep people using their Amigas? I think the problem is we live in an internet-connected world and Amigas don't have fully capable browsers so people turn off their Amigas and use modern devices then return for their retro hit when a game or new bit of hardware becomes available.

I know we have newly updated iBrowse, Netsurf and AmiFox for 68k but they are poor substitutes for modern device browsing. on the PPC front, there is Oddysey for AmigaOS 4.1 and The best available of any Amiga Platform is Wayfarer for MorphOS.

I know this has been raised many a time even by myself in the past and I have read all the arguments about what the roadblocks are for why it will not eventuate. Who will create it? who will maintain it? keeping up with changes is a full-time job, who will pay for it? who will make the dependencies? the hardware is not powerful enough, there are not enough developers etc.

I don't have the answers to all these concerns but I know that if people can turn on their Amiga and do most internet-related tasks rather than go to their PC, Mac or Phone they are more likely to be motivated to stay and develop for the Amiga.

I think a browser targeted at high-end 68K Amiga accelerated by hardware like PiStorm, Apollo and Emulated Amiga would be a good starting point. Maybe Wayfarer is the answer if the dependencies could be ported and the code optimised for said platforms?

_________________
Amiga A1200T - TF1260 - R9200 - Indivision AGA MK3
Amiga A500 - PiStorm EMU68
Pegasos 2 G4 - AmigaOS 4.1 FE / MorphOS 3.16

@Gunnar

Quote:

Gunnar wrote: My impression is that often people talking about MMU have very unrealistic ideas and believes. Maybe it helps to clarify a few items upfront. Can an MMU help debug programs? Yes, a MMU can help to find very bad Pointer bugs. Will it find all coding errors? No, the MMU only find some bugs, we talk here about a very low percentage of bugs. There are more tools that also help, e.g. Mungwall not needs and MMU and also helpts to find Pointer bugs. In fact using programming languages like Pascal or Modula instead C for coding will avoid more coding bugs than the MMU can find on Amiga. Will an MMU create a 100% stable system? No, MMU can not provide this on Amiga. The Amiga OS by design allows programs to talk to each other and to share data. As program on Amiga are allowed to each other. Most bug finding capabilities of the MMU is effectively nullified on Amiga. And of course the MMU can not protect a programs from killing itself. A CPU MMU will not protect the system from Blitter DMA or Zorro DMA killing the system. What drawbacks has virtual Memory? Virtual memory copies memory to from harddrive. As you will know harddrives have million times higher latency than memory. This means "emulating" memory by copy memory to from harddrive will make your system slower. This slow down can be very significant. A normal CPU MMU can only emulate more memory if you do NOT allow DMA to access it. This manes the AMIGA design with Amiga chip doing DMA would need an extra IOMMU for this work fully. Has using the MMU drawbacks? Yes there are a lot drawbacks. Using an MMU means you extra memory access of the MMU are needed to load MMU pointers and values. This can slow down the system by some percent. The ideo behind the Unix like memory protection is not compatible with the Amiga OS design. On Amiga programs can talk directly to Joystick button and also to Blitter. Trying to enforce a protection here means you would break all existing Amiga software. 100% incompatible.

1. MMU can help with the MuLib-driven ShapeShifter video driver. https://aminet.net/package/misc/emu/MuEVD
https://aminet.net/package/misc/emu/AmigaAGA-EVD12
https://aminet.net/package/misc/emu/CardTrickEVD
https://aminet.net/package/pix/illu/cwbevd
https://aminet.net/package/misc/emu/WinnerEVD

Running retro AGA is like listening to retro LP music.

I formerly have an A3000 with 68030 @ 25Mhz and MMU.

2. Running Amiga's Linux 68K. https://www.debian.org/ports/m68k/

68K MMU is available on WinUAE.

_________________
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)

@Gunnar

Quote:

Gunnar wrote: @Jose While the 68K Family in general supports MMU. Each 68k MMU works differently and needs be programmed in its "own" way. As you will know a MMU is not meant to be used/programmed by any software or program. The MMU is a tool that only the operating system is allowed to use. As the MMU is used for managing Memory, the design of the MMU changed the same way a Memory Chips changed many times over the year. This means that the MMU of the 68030 made after some years not much sense .. and the 68040 has therefore a different MMU. Of course also the design of the 68040 made after some years not much sense ... And today a useful MMU would be done differently of course. You will recall the first Amiga was first sold with 0.25 MB only ... This was quickly doubled to 0.5 MB .. And later Amigas had 1 MB or 2MB and you could of course upgrade them. Today our Amiga comes with 512 MB.. Maybe we will have models with 2028 MB at some point. I think its very easy to understand that an MMU which was designed to manage 1-8 MB might do a very bad job when you have 100 MB or 1000 MB memory. As you know AMIGA OS does not use MMU. The Apollo 68080 CPU has a modern MMU which is designed for modern amounts of memory. You can use it for debugging on Amiga too. We have a tool named "ApolloShield" which provides debug/memory protection similar to Enforcer

BFG9060 and TF1260 include 128 MB RAM while Warp1260 includes 256 MB RAM.

68060 easily handles 8 MB of RAM.

My teacher's 486DX-66-based PC has 16 MB of RAM during the early 1990s. My 1996 Pentium 166 has 16 MB of RAM.

DOS Doom required at least 4 MB of system RAM.
DOS Quake requires 8 MB of system RAM. Quake requires greater than 8 MB of RAM RAM i.e. Windows 95 + WinQuake use case.

Running the PC's graphics extensive professional apps and running Windows NT 3.1 i386 is higher than 4 MB of RAM.

Large fast RAM and fast SSD help Linux 68K.

Full 32-bit 68K with MMU was extensively used in big-endian Unix workstations and servers.

https://youtu.be/kSACfBZKg-4
NeXT with 68040 @ 25 Mhz with 64 MB of RAM running Mach UNIX kernel-based NeXTSTEP in WIMP UI. NeXTSTEP is the ancestor of MacOS X.

https://youtu.be/f_jzpPXAXVM?t=100
NeXT with 68040 @ 33 Mhz with 128 MB of RAM with color NeXTSTEP GUI.

With enough RAM, 68040 runs graphics UI memory-protected Unix OS just fine.

Are you claiming that the 68060 is not a classic Pentium class CPU?

Last edited by Hammer on 19-Feb-2024 at 06:43 AM.
Last edited by Hammer on 19-Feb-2024 at 06:15 AM.
Last edited by Hammer on 19-Feb-2024 at 05:50 AM.
Last edited by Hammer on 19-Feb-2024 at 05:46 AM.
Last edited by Hammer on 19-Feb-2024 at 05:32 AM.
Last edited by Hammer on 19-Feb-2024 at 05:23 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

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?

@matthey

Quote:

matthey wrote: NutsAboutAmiga Quote: MPU or Micro Processor Unit, similar to CPU’s but they often contain flash memory. nice small simple CPU for dishwashers. Micro Controller Unit (MCU) https://en.wikipedia.org/wiki/Microcontroller Micro Processor Unit (MPU) https://en.wikipedia.org/wiki/Microprocessor Memory Protection Unit (MPU) https://en.wikipedia.org/wiki/Memory_protection_unit It is a MCU which contains CPU core(s), SRAM for memory and sometimes flash memory although external flash is becoming more common. Sometimes the difference between a MCU, MPU and SoC are blurred. For example, some of the SiFive SoCs with U74 CPU cores have 2MiB SRAM that can be configured as main memory like a MCU or L2 cache like a MPU. This provides extraordinary versatility with a minimal cost increase from a more specialized chip.

ARMv8-M's MPU is a trimmed-down MMU and it wasn't designed to run Linux-type OS.

FreeRTOS is a popular embedded OS for microcontroller ARMv8-M.

_________________
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)