Quote:

bobson wrote: Could memory protection be introduced - with a sandboxing for the classic Amiga stuff? else the whole exercise is pointless...

Yes, I believe full memory protection and resource tracking could be added to the AmigaOS with major changes to the API. Classic Amiga software could then run safely in a sandbox.

The AmigaOS works much different than Linux/BSD/Windows. The CPU instructions generate an effective address (EA) which the AmigaOS usually has mapped directly to a physical address (PA) in a flat shared memory model. Linux/BSD/Windows CPU instructions generate an EA which is mapped to a virtual address (VA) which is mapped to the PA with the aid of a memory management unit (MMU). Each task/process has its own virtual address space which remains separate and isolated from others. The CPU uses translation lookaside buffer (TLB) caches which quickly translate virtual to physical addresses. Programs usually start at low virtual addresses and often historically at the same address which is poor for security (AmigaOS programs have always loaded and started anywhere in physical memory). Task switching involves slower swapping of virtual address spaces which the AmigaOS has no concept of. CPUs have grown to support the virtual address spaces and paging concepts of these popular OSs despite their performance handicap, especially on less than high end CPUs. Despite multi-levels of TLB caches, TLB misses can easily cause double digit and sometimes as much as 50% performance losses (worse with 64 bit and SMP). The AmigaOS can easily create MMU pages with protections for memory but isolation of process address spaces is difficult without breaking compatibility. To make matters worse, the AmigaOS being a microkernel places almost everything in user space for best performance (Linux/BSD/Windows started as monolithic kernels with practically the whole OS in supervisor space). Separating the address spaces likely needs some kind of privilege based system like capability based security or a protection ring (needs hardware support but may be able to give the AmigaOS efficient security with the fewest changes). Embedded systems struggle with the same decision between better security with the overhead of modern CPU "virtual" support and better performance, lower jitter and better energy efficiency without it. It's possible the responsiveness, efficiency and small footprint of the AmigaOS we like would disappear when fully assimilated.

Quote:

I thought thats what AROS was - an Amiga OS compatible api, running in a sandbox + some enhancements?

AROS does not have full memory protection so it can't provide a sandbox. It may be possible to run hosted in another OS's sandbox or using hardware assisted virtualization.

Quote:

So how much work would be involved in porting OS4 to RPi / ARM? or are we better off binning it all, and starting again?

I expect a simple port with no modern enhancements would be moderately difficult if big endian was enabled (the difficult parts being everything in supervisor mode, the drivers and the 68k and possibly new PPC JIT). Unfortunately, we don't know what condition the source code is in.

I'm not sure Hyperion would be interested anyway as they passed up the chance to proliferate the AmigaOS on the PS3 and PPC Macs. They seem to have a different business model that looks snobbish and arrogant to me but maybe the rumors about their financial situation are wrong.

USB works now. There will be an image for us to test very soon :)
This is great and exiting. This could realy boost AROS development.

https://www.patreon.com/posts/fight-with-usb-23357589?utm_medium=post_notification_email&utm_source=post_link&utm_campaign=patron_engagement

Hope to see Janus-uae for arm or some other 68k emulator.

Last edited by nikosidis on 16-Dec-2018 at 11:29 PM.