in case you are interested to test new fpga accelerators for a600/a500

[guest11527]

IIRC it is not possible to boot any Amiga with a 68060 and any published Kickstart version only.

Well, yes and no. You cannot reliably boot the system with the 68060 because the FPU stack frame is different, not because the MMU is diffferent. The little bit of MMU exec uses for its initialization is actually identical between the 040 and 060. The system would (probably) run up to the point where someone tries to use the FPU (and would then crash), but that I do not remember. The boot ROM that disables the FPU until the 68060.library hooks in is currently the savest alternative.

[guest11527]

But AmigaOS has no such abstraction

It does not? Nothing that is coming from CBM, but that is no surprise.  

all tools and utilities that support MMU are third party AFAIK.  

Yes, but there are those parties that try to provide a generic interface to it and care about it, and those parties that provide specialized solutions for single applications and have lost track in updating their software... so make your pick.  

And frankly I personally don't care much about MMU in context of AmigaOS, I just want it for Linux and *BSD. Only exception is paging to disk, which is very useful and almost a must when doing animation work within the limits of 128MB RAM.

That is certainly true, but I wonder why that is a good application for Amiga Hardware, at least nowadays. Honestly, if I want to run Linux (and I am running it right now) there are plenty better alternatives on much faster hardware.

[psxphill]

Which type of functionality do you get with larger pages? They are only larger pages, after all. With typical memory sizes as found in the Amiga, 4K is actually quite good.

The only rational argument I heard for coming up with a different MMU was that the page size was too small. It was a concession, but I don't particularly care. If 4k is fine then it's another argument for keeping the MMU exactly the same.

Why would you? If you do, you program is more or less "bound" to the hardware it runs on. This is quite a bad idea. The MMU is a "system level" tool, and the system provides you with interfaces to abstract from the hardware. Otherwise, you'll have to write your program (currently) at least four times, and run into a lot of compatibilty issues - given that the Os also requires the MMU for DMA or debugging. Hence, if there is an abstraction level to access a feature, use it.

So there is only one operating system allowed and you get to do the MMU code for it? I don't like that kind of lock in, when a compatible MMU would allow you to run BSD or Linux. You might not want to do it, but your arguments seem more about you getting to provide the MMU support.

[psxphill]

Which type of functionality do you get with larger pages? They are only larger pages, after all. With typical memory sizes as found in the Amiga, 4K is actually quite good.

The only rational argument I heard for coming up with a different MMU was that the page size was too small. It was a concession, but I don't particularly care. If 4k is fine then it's another argument for keeping the MMU exactly the same.

Why would you? If you do, you program is more or less "bound" to the hardware it runs on. This is quite a bad idea. The MMU is a "system level" tool, and the system provides you with interfaces to abstract from the hardware. Otherwise, you'll have to write your program (currently) at least four times, and run into a lot of compatibilty issues - given that the Os also requires the MMU for DMA or debugging. Hence, if there is an abstraction level to access a feature, use it.

So there is only one operating system allowed and you get to do the MMU code for it? I don't like that kind of lock in. "bug closed, won't fix, not running amigaos".

Honestly, if I want to run Linux (and I am running it right now) there are plenty better alternatives on much faster hardware.

This is sounding more and more like a dictatorship. I get the impression that you want an incompatible MMU solution so everyone has to run MMULib.

[billt]

May I ask which software you currently use that goes down to the MMU directly?

Enforcer, WHDload

http://www.sinz.org/Michael.Sinz/Enforcer/

http://whdload.de/docs/en/mmu.html

[kolla]

 
That is certainly true, but I wonder why that is a good application for Amiga Hardware, at least nowadays. Honestly, if I want to run Linux (and I am running it right now) there are plenty better alternatives on much faster hardware.

Well, my favourite programs for animating just happens to be Amiga programs, they are your so called "killer apps", I know them, I enjoy using them and I have made money with them both in "entertainment" and scientific work. If you're saying "why that is a good application for Amiga hardware today", we may just as well drop it alltogether, right? As for Linux on m68k, it's a hobby I've had for 20 years now, maintaining Linux distros for old m68k systems, it never made any sense, but I enjoy it and would love to see newer and cheaper hardware, especially with more RAM. It would also broaden the use case for the Apollo core a lot if they make sure Linux and BSD is supported.

As for your MMU libs, by all means, it's a cool project, and I am probably not the only one who is mostly unaware of tools using them. Is there paging functionality available that use them?

[guest11527]

If you're saying "why that is a good application for Amiga hardware today", we may just as well drop it alltogether, right?  

Not exactly. I mean, most Linux applications are Open Source anyhow, and nowadays in much more modern versions available than in the Amiga days, so it's really simple and easy to migrate. The same does not go for native Amiga applications IMHO. Fore example, I'm still missing a "pixel-paint" program for Linux that is worth using (and no, gimp is not the right answer for this type of problem. It's just too complex for many simple tasks, and rather designed with another application in mind - photo editing namely).  

As for your MMU libs, by all means, it's a cool project, and I am probably not the only one who is mostly unaware of tools using them. Is there paging functionality available that use them?

As in "paging memory"? Yes, certainly. There is the "memory.library" which gives you all that, including to "mmap" files or create "virtual memory on demand". There is no "automatic virtual memory" basically because that simply cannot work, and I don't like programs that "cannot work", so I did not write one. But all the higher paging functionality is surely available.  For example, all the "VMM" stuff for Amiga is simply "broken by design", no chance to get that working reliably.

[guest11527]

This is sounding more and more like a dictatorship. I get the impression that you want an incompatible MMU solution so everyone has to run MMULib.

Actually, I want a solution that is easy to integrate into an FPGA core. The current MMU design of the 68K cores is pretty much "high level" and calls for microcode, but that's exactly what FPGAs are not designed for, so I understand Gunnar's hesitation to exactly re-implement that. All I'm trying is to find a way out and offer a bridge for that.  

Another design would be to use a software-emulation of the MMU table walk, and this way the FPGA MMU could emulate a 68K MMU, with software support. That would pretty much work like the integer instruction emulation that is now in the simple Phoenix core for the first generation of Vampires. This design would also work, though it is necessarily requiring more complex software and is necessarily less performing.  

For me, the easiest would be if I wouldn't have to touch any code, but that's unlikely to happen given the complexity of the task at hand and the performance and hardware implications. But calling it a "dicatorship to make you use my code" I find rather harsh. Just to remind you, all the other "system authors" no longer support anything of their stuff, so thanks for the flowers.

Your friendly dictator,  Thomas

[guest11527]

Enforcer, WHDload

http://www.sinz.org/Michael.Sinz/Enforcer/

http://whdload.de/docs/en/mmu.html

Enforcer is now called MuForce. Yes, it really is the same code. Mike offered the code, and I only removed the low-level stuff. All the high-level stuff is still Mike's code, so you don't loose anything, and gain compatibility - and future development and improvement. I would not run Enforcer nowadays anymore, or rather, would recommend its revised version.

WHDLoad I may accept as a possible application. Actually, personally consider this a rather bad hack, but I probably understand that some people want to continue to run badly written games. Note, however, that the MMU is probably your least problem with WHDLoad when running on the Phoenix. This core is *just too fast*, and I would not be surprised if a lot of games simply refuse to work because the timing is not at all the same anymore.

Thus, I would believe that the FPGA-solution is probably not quite right for just running this type of software in first place, i.e. it does not address the use case. If you want to run such games that simply go directly to the hardware, I believe you would require the old hardware directly, or rather, would disable the FPGA, and *then* run WHDLoad.

[Kremlar]

Thus, I would believe that the FPGA-solution is probably not quite right for just running this type of software in first place, i.e. it does not address the use case. If you want to run such games that simply go directly to the hardware, I believe you would require the old hardware directly, or rather, would disable the FPGA, and *then* run WHDLoad.

Wow!  That's quite a statement.

I do believe most people buying FPGA hardware are looking to run old games.  Switching off the FPGA is not a solution for people wanting standalone FPGA hardware to replace aging Amigas.

[asymetrix]

It would be really cool if we could pause the fpga via Amiga Amiga then an option to switch A500/A600 68000 mode, A1200/68020 mode etc

then the system just continues in this mode seamlessly would be nice for debugging asm.

- user friendly the Amiga way ..

[psxphill]

The current MMU design of the 68K cores is pretty much "high level" and calls for microcode, but that's exactly what FPGAs are not designed for, so I understand Gunnar's hesitation to exactly re-implement that.

I'd like to see a technical explanation of why you can emulate a CPU but not an MMU with an FPGA. AFAIK his hesitance to adding an MMU was the latency. Using a MIPS (and apparently PPC) style MMU is not going to do much for latency when you run out of registers. But the exact same cache could be done using an MMU that is compatible and the slow path would still be faster than using the CPU.

[kolla]

Not exactly. I mean, most Linux applications are Open Source anyhow, and nowadays in much more modern versions available than in the Amiga days, so it's really simple and easy to migrate.

That makes no sense considering that latest kernels and toolchain compile and work fine on Amiga today - Linux on old Amiga hardware is way more modern than AmigaOS on same hardware can ever be.

I don't run Linux on 68k because I "must", I have all kinds of hardware and architectures running Linux, 68k is just one of many, and as long as it works fine, I don't see any point in stopping.

The same does not go for native Amiga applications IMHO. Fore example, I'm still missing a "pixel-paint" program for Linux that is worth using (and no, gimp is not the right answer for this type of problem. It's just too complex for many simple tasks, and rather designed with another application in mind - photo editing namely).

I agree, I keep using DPaint for all such work.

As in "paging memory"? Yes, certainly. There is the "memory.library" which gives you all that, including to "mmap" files or create "virtual memory on demand". There is no "automatic virtual memory" basically because that simply cannot work, and I don't like programs that "cannot work", so I did not write one. But all the higher paging functionality is surely available.  For example, all the "VMM" stuff for Amiga is simply "broken by design", no chance to get that working reliably.

Well, question is really, can I set up a 1-2GB partition to use as raw swap to increase the ammount of system "Fast RAM", which Lightwave, DPaint etc can benefit from when I do longer high-res animations? It's really all I want and need, and why I use VMM.

[kolla]

Wow!  That's quite a statement.

I do believe most people buying FPGA hardware are looking to run old games.  Switching off the FPGA is not a solution for people wanting standalone FPGA hardware to replace aging Amigas.

Wow, why?? Have you been paying attention? If all you want is to run old games, then there is already _plenty_ of cheap and compaible hardware around, an FPGA accellerator is total utter overkill for that. On the other hand, if insisting on running ports of 15-20 year old PC games on your Amiga is your interest, them FPGA accelerator is perfect choice. Hopefully it will also make sense to use FPGA accelerator for legacy productivity software.

[Crumb]

Thus, I would believe that the FPGA-solution is probably not quite right for just running this type of software in first place, i.e. it does not address the use case. If you want to run such games that simply go directly to the hardware, I believe you would require the old hardware directly, or rather, would disable the FPGA, and *then* run WHDLoad.

Fusion also used MMU directly IIRC (You could run MacOS 8.1 with swapmemory enabled).
ArtEffect IIRC offered some kind of swap memory but I don't know if it used MMU.
ADoom too IIRC (to perform c2p&refresh just the changed gfx)
Didn't StormC offer some option to use MMU for debugging?
VMem and other swap memory tools.


I think that using smaller pages (e.g. 256bytes is more effective for c2p and emulators/virtual machines) but I may be wrong.

[Kremlar]

Wow, why?? Have you been paying attention? If all you want is to run old games, then there is already _plenty_ of cheap and compaible hardware around, an FPGA accellerator is total utter overkill for that. On the other hand, if insisting on running ports of 15-20 year old PC games on your Amiga s your interest, them FPGA accelerator is perfect choice. Hopefully it will also make sense to use FPGA accelerator for legacy productivity software.

One of the biggest driving factors of FPGA hardware will be replacing aging Amiga systems.  Accelerators are nice but won't help fix failing Amigas due to leaking batteries, failing capacitors, careless users, etc...

How popular would WinUAE be if it didn't handle old misbehaving software so well?

Why is WHDLoad so popular?

A standalone FPGA solution should have excellent compatibility options (even different cores would be OK), or it's popularity will be limited.