Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Information about the Apollo CPU and FPU.

Apollo Vamp V4 Mmu Bounty - How To?page  1 2 3 4 

Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
21 Sep 2019 08:33


Real bounty needs
- clear goal
- clear amounth of prize, preferably no set date but paid 50-50 or all on completion
- skilled coder that accepts it
- web platform
We have 1) - 040 mmu active on v4 vamps and last one - few great bounty websites


Samuel Crow

Posts 424
21 Sep 2019 09:02


Vojin Vidanovic wrote:

Real bounty needs
  - clear goal
  - clear amounth of prize, preferably no set date but paid 50-50 or all on completion
  - skilled coder that accepts it
  - web platform
  We have 1) - 040 mmu active on v4 vamps and last one - few great bounty websites

Bad idea.  The separate memory protection unit and current MMU have wildly different page sizes from one another.

Memory protection needs small page sizes to work well and the current design offers byte-level precision.  '040 offers 4k byte precision minimum.

RAM usage by all other MMU functions benefit from larger page sizes so that the number of page table entries are smaller.  Vampire is fixed at 128k page size.  '040 has 8k as maximum and that is even one-size-fits-most compromise that prevents it from using different page sizes than the memory protection needs.

Having an unconventional MMU could be what gives the Apollo 68080 the advantage over x86 in the long run.  What we really need is an AROS bounty to support the Apollo memory protection hardware independently of the MMU.


Gunnar von Boehn
(Apollo Team Member)
Posts 6197
21 Sep 2019 09:04


Samuel Crow wrote:

Bad idea. 

Its not a bad idea.
It depends on your goal.

If your goal is "enable Vamp" to run Linux 100% unchanged - then this Bounty makes 100% sense.


Samuel Crow

Posts 424
21 Sep 2019 09:06


Gunnar von Boehn wrote:

Samuel Crow wrote:

  Bad idea. 
 

 
  Its not a bad idea.
  It depends on your goal.
 
  If your goal is "enable Vamp" to run Linux 100% unchanged - then this Bounty makes 100% sense.

That's not my goal and I'm pretty sure it's not yours.


Gunnar von Boehn
(Apollo Team Member)
Posts 6197
21 Sep 2019 09:11


Samuel Crow wrote:

That's not my goal and I'm pretty sure it's not yours.

 
For running AMIGA OS / AROS an MMU is not needed at all.
Actually its often more harm than good.
 
Virtual memory today with Flash Disks is frankly also not a good idea.
It will result in a much lowered live expectations of your CF and SD drives.
 
Surely the people asking for the bounty can explain what their goal is.


Michael Borrmann

Posts 140
21 Sep 2019 10:50


Samuel Crow wrote:

Bad idea.  The separate memory protection unit and current MMU have wildly different page sizes from one another.
 
  Memory protection needs small page sizes to work well and the current design offers byte-level precision.  '040 offers 4k byte precision minimum.
 
  RAM usage by all other MMU functions benefit from larger page sizes so that the number of page table entries are smaller.  Vampire is fixed at 128k page size.  '040 has 8k as maximum and that is even one-size-fits-most compromise that prevents it from using different page sizes than the memory protection needs.
 
  Having an unconventional MMU could be what gives the Apollo 68080 the advantage over x86 in the long run.  What we really need is an AROS bounty to support the Apollo memory protection hardware independently of the MMU.

Form what I read most people using Amiga MMU need this to work with existing Amiga MMU tools.
So they'd prefer an MMU that is compatible with existing ones...




Gunnar von Boehn
(Apollo Team Member)
Posts 6197
21 Sep 2019 10:59


Michael Borrmann wrote:

Form what I read most people using Amiga MMU need this to work with existing Amiga MMU tools.
So they'd prefer an MMU that is compatible with existing ones...

If you have a Streetsign pointing to "Paris" but pointing in the wrong direction  - is it now easier to turn the street sign into the right direction - or is it easier to move the city of Paris to another place?

Patching the old AMIGA tool using the new MMU is magnitudes less work than changing the MMU.


Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
21 Sep 2019 12:20


Gunnar von Boehn wrote:

  Actually its often more harm than good.
  Surely the people asking for the bounty can explain what their goal is.
 

 
  I see just good.
 
  Min
  - enable 040 mmu for AmigaOs - in enforcer like sw and apps that can use it for vmem (e.g. image fx)
  - enable error free boot of 040 mmu Linux kernel. 040 Lin kernel is way newer and advanced then ucLinux MMUless one
  High end
All previous plus
  - have mmu Atari and Mac m68k compatibile as part of future full Mac/St/tt compatibility
  - enable vamp pmmu for documented use in future Aros or AmigaOs
 
  Could Apollo team do coding and size of bounty?
 

P.s. speed penalty when mmu is on is ok, but th n Make vcontrol on/off


Michael Borrmann

Posts 140
21 Sep 2019 13:18


Gunnar von Boehn wrote:

  Patching the old AMIGA tool using the new MMU is magnitudes less work than changing the MMU.

Wondering, though, why you decided against being compatible with the old standard here, when you were so keen on being compatible with all the rest of the native Amiga software cosm.



Samuel Devulder

Posts 248
21 Sep 2019 13:41


Probably because there is no standard concerning the MMU in the m68k family, contrary to the FPU for instance.


Gunnar von Boehn
(Apollo Team Member)
Posts 6197
21 Sep 2019 13:54


Michael Borrmann wrote:

  Wondering, though, why you decided against being compatible with the old standard here,
 

 
Simply, because there is no old standard.
 
The CPU instructions of the 68K are a standard.
 
But the memory interface and the bus protocol of each 68K chip did change.
And this makes absolute logical sense - as the memory chips on the market did change over the years.
As the memory interface did change - also the MMU did change over the time - which also makes sense as the MMU is in the middle between CPU and the memory controller.
 
As you certainly know the memory chips from the 80th and 90th are not available anymore on the market today (and also not legal anymore because of harmful substances laws).

Therefore obviously APOLLO does have to have a complete new memory interface - and you all know this, I assume.
 
And as you know the MMU being in the middle between CPU and Memory should ideally also be adapted on the new conditions.
 
  Makes all sense now?


Samuel Crow

Posts 424
21 Sep 2019 19:21


Vojin Vidanovic wrote:
 
  Min
  - enable 040 mmu for AmigaOs - in enforcer like sw and apps that can use it for vmem (e.g. image fx)
  - enable error free boot of 040 mmu Linux kernel. 040 Lin kernel is way newer and advanced then ucLinux MMUless one
  High end
  All previous plus
  - have mmu Atari and Mac m68k compatibile as part of future full Mac/St/tt compatibility
  - enable vamp pmmu for documented use in future Aros or AmigaOs

Enforcer doesn't work on AROS as far as I know.  AROS has its own MMU control independent of AmigaOS.

The best thing that can be done now is to get Kalamatee a stand-alone Vampire, pay him to update the AROS kernel and use the new memory protection unit to find more bugs than Linux kernel catches with its old-style memory protection.


Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
21 Sep 2019 19:44


Linux kernel that would use V4 PMMU (V2 too!) or anyhow boot on V4
    and AROS update that would enable vmem/debugging in AROS (or any use of PMMU) would be great goals,
    fully replacing current or leaving it to someone else.
 
  Nice PA Semi/Freescale Linux kernels is best development for A-x1000/x5000 so far :)


Samuel Crow

Posts 424
21 Sep 2019 22:11


Vojin Vidanovic wrote:

Linux kernel that would use V4 PMMU (V2 too!) or anyhow boot on V4 and AROS update that would enable vmem/debugging in AROS (or any use of PMMU) would be great goals...

A better goal would be to ditch the Linux kernel in favor of Haiku or something lightweight.  NetBSD?


Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
21 Sep 2019 22:21


Haiku, BeOS whatever you like, but please include Linux.
  From pure console, LXDE, KDE, XFCE to MATE etc. it can only offer more. Plus the apps in accordance to kernel version and GUI.

AROS acceleration for sure :)


Samuel Crow

Posts 424
22 Sep 2019 00:02


Vojin Vidanovic wrote:

Haiku, BeOS whatever you like, but please include Linux.
  From pure console, LXDE, KDE, XFCE to MATE etc. it can only offer more. Plus the apps in accordance to kernel version and GUI.
Ubuntu doesn't support 32-bit architectures any more and for good reason.  Linux is a memory hog.  Besides, Qt works well enough on Haiku that it doesn't need the Linux kernel slowing it down.  KDE won't run on a half gig PC so I assume you meant LXQT?

I use Linux all the time.  It would not seriously fit well on a Vampire.


Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
22 Sep 2019 00:11


OK; remove the Linux idea (even it is investment for the future). Let goals be:
  - Enable use of PMMU in AmigaOS 3.x
  - Enable 040 MMU Compatibility in AmigaOS 3.x

    Optionally

  - Patch AROS m68k use PMMU for VMem and Memory Allocation
  - NetBSD whatever you say, lightweight Vamp kernel
  - Patch FreeMINT and Fusion/Basilisk/Mac emulator to use MMU


Stefano Briccolani

Posts 586
22 Sep 2019 01:22


Everyone can run Linux on pc as well as windows.
Linux on Vampire is a no-sense affair. Hobby computing is a different thing than mainstream needs. Hobby computing it's a sweet passion. Having a crawling Debian distribution on Vampire would raise attention on the qualities of Amiga? I don't think so..


Samuel Crow

Posts 424
22 Sep 2019 01:37


Vojin Vidanovic wrote:

OK; remove the Linux idea (even it is investment for the future). Let goals be:
    - Enable use of PMMU in AmigaOS 3.x
    - Enable 040 MMU Compatibility in AmigaOS 3.x
 
    Optionally
 
    - Patch AROS m68k use PMMU for VMem and Memory Allocation
    - NetBSD whatever you say, lightweight Vamp kernel
    - Patch FreeMINT and Fusion/Basilisk/Mac emulator to use MMU

You're getting closer to reality now.

Since MMU.library is closed source you'll have to pay Hyperion to command Thomas Richtor to unwillingly add 68080 support to his library and never release source code.  MuForce is basically Enforcer using MMU.library.  All OS3 MMU dependencies should be using MMU.library by now rendering the second requirement obsolete.

Stretch goal one for AROS will render the first required goal totally obsolete as well because AROS already supports MMUs on other architectures anyway and doesn't need closed source code as a dependency.  Not to mention Gunnar and Thomas have a huge disagreement going on and collaboration between them is unlikely.

Stretch goal 2: NetBSD was faster than Linux back in the day but will likely be incompatible with the AROS drivers anyway and Haiku and BSD share many drivers as well.  Perhaps Haiku will fit in memory better.

By fixation on BeOS derivatives stem from Google's experimental Fuschia OS which many former engineers from Be Inc. work on to replace Android's dependency on the Linux kernel.  I'm just riding with the tide of our times.

Last stretch goal won't be reached on closed source targets but FreeMiNT sounds interesting at least.  Maybe.


J.M. Lapilainen

Posts 24
22 Sep 2019 02:26


Vojin Vidanovic wrote:

Haiku, BeOS whatever you like, but please include Linux.
  From pure console, LXDE, KDE, XFCE to MATE etc. it can only offer more. Plus the apps in accordance to kernel version and GUI.

I don't want to sound rude, I appreciate your enthusiasm, but those bloated desktop environments (and bloated toolkits, bloated malware disguised as init and friends, pulseaudio, you name it) are not something that a) would run comfortably or at all b) should be run at all on V4. Libreoffice or Firefox will not run on V4, ever.

Even if we had required raw power available, even if we would have that imaginary, blazing fast dri-driver for (S)AGA, expecting things to compile for m68k just like that is not realistic. We are at the point where x86 support is being dropped because software people want to run wont necessarily even compile anymore without patching and it's just not worth the effort.

Linux kernel however can be somewhat lean and fast enough on slow hardware and outside the usual bloat you're used to seeing in Linux systems there's plenty of software that runs OK on older Pentiums and similar systems, from init systems to shells to window managers. With something like V4, you would realistically be looking at something based on busybox or maybe suckless.org core or similar, a very minimal shell, very minimal window manager, slimmed down xterm or urxvt and your choice of command line applications or simple gtk2 applications at best, to get things done. You'd still be surfing the web with netsurf, most likely a lot slower than you would on AmigaOS, and that's with the assumption you would have a working network with Vamp under Linux. I could go on and on with this but I'm sure everyone gets the point already.

All that said, I would still like to see Linux booting on Vampire, and maybe create a small distro for it. In my not-a-real-developer and not-a-real-engineer mind I see two options:

- 040 MMU (emulation?) which would benefit both those who need it under AOS and those who want to run Linux/NetBSD/Whatever. Also comes with the benefit of feature completeness which would no doubt make at least some Vampire haters lose one of their arguments.

- Something more future proof that would fill the requirements (in context of this topic) of Linux/NetBSD (meaning support in kernel). If it would benefit, for uneducated example, future AROS development/progress some way, all the better.

Somewhat offtopic:
Even though many people in here see Linux/NetBSD support silly and not worth the effort, and I can certainly understand why, I see it only as a positive thing. If we can gather the money and someone delivers and gets paid, isn't it already a good thing itself? I think it's worth noting, that even after all these years, linux-m68k is still there. There may not be many left interested and working on it actively, but I'm quite sure there is interest in a new Amiga (or m68k platform). IIRC Vampire has been mentioned in linux-m68k mailing list already (at least Geert has background with Amiga). I can't speak for anyone else but I'm pretty sure there would be help available with Linux side of things, if that's required.

In general, *n?x world is full of weird people (like me) who love running their choice of OS with esoteric toasters and developing for it. Meaning, potential customers outside the Amiga/Atari scene. While supporting and focusing on AROS is no doubt the most sane thing to do now, having the option of Linux ready when the magical ASIC day comes will certainly be a big positive and it will bring more people in. I'm maybe half joking, half wishing here, but you get what I mean. Who knows, maybe you guys eventually succeed in making m68k great again :)


posts 75page  1 2 3 4