@Raffaele: do you really think that a new Amiga/like o.s. should be 32-bit only? On 2014?

Even smartphones have reached 3GB of RAM, and soon they will exceed it...

It doesn't make sense to be constrained by the 2GB limit of a 30 (THIRTY!) years old o.s..

64-bit should be the next big thing, and it's easier to achieve. AROS already supports it, and without horrible "first '80s bank-switching" patches, fortunately.

Last edited by cdimauro on 11-Oct-2014 at 07:10 AM.

@cdimauro

Quote:

AROS already supports it, and without horrible "first '80s bank-switching" patches, fortunately.

Without compatibility, unfortunately.

@Raffaele

Quote:

Make new OS 32 or 64 bit with all modern features and let old utilities being automatically loaded into an emulator that will run 68k software into a well protected crash-proof sandbox!

That's what Apple did but do we have the resources? As long as we're able to use multiple cores with the launch of the X5000 that seems all the progress on the core OS4.x we can expect other than 3D acceleration. The File system and core OS kernel seems locked due to lack of developers. Sad but true.

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@BigD

Is there not a new filesystem api ?.

http://blog.hyperion-entertainment.biz/?p=1044

Quote:

BigD wrote: @Raffaele Quote: Make new OS 32 or 64 bit with all modern features and let old utilities being automatically loaded into an emulator that will run 68k software into a well protected crash-proof sandbox! That's what Apple did but do we have the resources? As long as we're able to use multiple cores with the launch of the X5000 that seems all the progress on the core OS4.x we can expect other than 3D acceleration. The File system and core OS kernel seems locked due to lack of developers. Sad but true.

_________________
Sam460ex : Radeon Rx550 Single slot Video Card : SIL3112 SATA card

@Spectre660

Quote:

Is there not a new filesystem api ?

Interesting! I was not aware of that.

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@Samurai_Crow

I've actually found what memory protection OS4 has to be a blessing when programming. It can be quite useful in catchihg you out. I was working on a program a few days ago that did some math on a table. It took numbers from another table and combined them into another. Now the source table was larger than the desination and I found out in my main loop that my index counter was four times too big. Then I found it was again too big, by two times. Had OS4 not crashed I'd be none the wiser and I am wondering now about older code that worked fine on 68K.

I then found a load file routine I wrote had a bug and freed the lock passed to OpenFrom Lock(). It's funny that since discovering what happens when you do that I've been caught myself and in other code. Now I'm suspicious of what UAE is doing when crashes during a file system write.

So I'm an advocate for memory protection. It crashes when something is wrong. And I can know about it.

@Hypex: but Samurai_Crow suggests to use managed code to avoid your problem. So, he's correct from this point of view: the underlining runtime of a managed platform permits to avoid exactly the issue that you had.

Unfortunately, managed code has a cost, and it isn't trivial for more complex cases. For sequential accesses it has very good performance, but aside that the cost of comparing the bounds of an array for every element access is too high. That's why some technologies were developed both in software (AddressSanitizer by Google, for example) and in hardware (Intel's MPX) to solve the problem reducing as much as possible the impact of such checks.

I'm a big fan of managed code (Python is my favorite programming Language!), but not everything can be managed, unfortunately. So I think that both philosophies can co-exist.

@pavlor

Quote:

pavlor wrote: @cdimauro Quote: AROS already supports it, and without horrible "first '80s bank-switching" patches, fortunately. Without compatibility, unfortunately.

AROS hadn't and hasn't this goal. AROS's goal is to be binary compatible for 68K / Amiga platforms, and source compatible for other architectures.

Compatibility for 68K / Amiga applications in the latter case is handled through a special integration with UAE.

@Spectre660

Quote:

Spectre660 wrote: @BigD Is there not a new filesystem api ?. http://blog.hyperion-entertainment.biz/?p=1044

The Amiga o.s. had "Filesystem(s) in Userspace" from day one. So it has never need of anything like FUSE, as a concept.

FUSE is only useful because there are several filesystems working / ported using it. That's all.

@cdimauro

FUSE and new filesystem API in OS4 are two different things.

@cdimauro

Quote:

Yes, but then you don't have the protection mechanisms that the managed code infrastructure provides you.

Protections are only one reason to use managed languages.

Anyway, managed languages are no replacement for memory protection. One reason is lack of software. It must be ported or at least use existing libraries because it is not possible write everything from scratch.

Btw when talking of essential OS features in modern computing you should also add power management.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@pavlor

Quote:

pavlor wrote: @cdimauro FUSE and new filesystem API in OS4 are two different things.

Weren't the new filesystem APIs developed to easier the porting of FUSE?

@itix

Quote:

itix wrote: [quote]Btw when talking of essential OS features in modern computing you should also add power management.

Sure, but I put it as a second order features list. It's important, but not like the others that I reported, IMO.

@cdimauro

Quote:

Quote: Btw when talking of essential OS features in modern computing you should also add power management. Sure, but I put it as a second order features list. It's important, but not like the others that I reported, IMO.

I expected that to confirm my belief. I mean, you are inserting technical merits before user experience.

Users dont ask how many gigabytes OS can access. They dont ask what CPUs it supports. They dont ask is there virtual memory support or is it POSIX compliant. But they will complain if 3D graphics is slow or there is no support for WLAN or your laptop can't automatically hibernate when it runs out of battery.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

What I think is that all these should be built on top of the features above.

@cdimauro

You are obviously a technician, not meant negativ

I am more economic orientated. Answer a simple question... why should any developer or software company invest in this new wonder-platform if there is Linux/Windows/Mac? Even Linux struggles to get applications. 68k (back to my thesis) is different/creating curiosity and you have a huge software base and lots of documentations you can start on. People will look at it very different to a "modern OS" you are asking for, they will of course compare NG with the big platforms. That is a race we cannot win.

Last edited by OlafS25 on 12-Oct-2014 at 11:23 AM.

@cdimauro

[quote]
Weren't the new filesystem APIs developed to easier the porting of FUSE?
[/quote[

No, they are nothing to do with FUSE at all. They were developed to enable the easier creation of new files systems in general. To avoid the nightmare of undertsanding DOS packets etc etc. Much of the standard functionailty is now handed off to DOS simplifying it further.

packet support remains via DOS's packet emulator, so that older filesystems may run seamlessly.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@OlafS25

Quote:

OlafS25 wrote: @cdimauro You are obviously a technician, not meant negativ

Technicians are users, as well.

Do you like to see that an application can get the entire system down? Do you like to see that your multicore system has only one of them active and stressed, making the system sluggish? Do you like to see that a file, screen, or window, etc. is left in the system after the application is closed (or died)? Do you like to close tabs on your browser to free memory, because you consumed almost all of it, even if you've 8GB or more?

All of this hurts the user experience. And for technicians / coders it's even worse (for example: bug -> system reset. ARGH!!!!)
Quote:

I am more economic orientated. Answer a simple question... why should any developer or software company invest in this new wonder-platform if there is Linux/Windows/Mac? Even Linux struggles to get applications.

Amiga and post-Amiga are basically constrained to be and rest hobbies, so I don't think that something will change from this point-of-view, even when some modern feature will be implemented. The road to the future was already marked: we lose the chance to have a role in the mainstream market (which doesn't mean also Windows: I put OS X and Linux as well, because they are known to the people, or at least people use them).
Quote:

68k (back to my thesis) is different/creating curiosity and you have a huge software base and lots of documentations you can start on.

We can use it though UAE, or some new FPGA project.

However I don't think that a 68K platform can supplant the others, albeit there are some common things (68K software).
Quote:

People will look at it very different to a "modern OS" you are asking for, they will of course compare NG with the big platforms. That is a race we cannot win.

Absolutely. See above.

However I think that something can and should change in the post-Amiga niche, but it requires a new mindset and the awareness that continuing to patch the existing o.ses is a dead binary.


@broadblues

Quote:

broadblues wrote: @cdimauro Quote: Weren't the new filesystem APIs developed to easier the porting of FUSE? No, they are nothing to do with FUSE at all. They were developed to enable the easier creation of new files systems in general. To avoid the nightmare of undertsanding DOS packets etc etc. Much of the standard functionailty is now handed off to DOS simplifying it further. packet support remains via DOS's packet emulator, so that older filesystems may run seamlessly.

Thanks for the clarification. That's a very, very good thing, since the DOS APIs were one of the weakest point of Amiga o.s. (albeit from 2.0 version the situation was much improved).

@cdimauro

"Amiga and post-Amiga are basically constrained to be and rest hobbies, so I don't think that something will change from this point-of-view, even when some modern feature will be implemented. The road to the future was already marked: we lose the chance to have a role in the mainstream market (which doesn't mean also Windows: I put OS X and Linux as well, because they are known to the people, or at least people use them)."

So you say these features should be implementend even though they will not change anything? That is exactly what I see, your "modern OS" will not change anything. We will not get just one application or game more because we have 64bit. So you agree to me there . Then why doing all the efforts at all? When one strategy obviously not works then it is better to go a different route.


"Quote:68k (back to my thesis) is different/creating curiosity and you have a huge software base and lots of documentations you can start on.
We can use it though UAE, or some new FPGA project.
However I don't think that a 68K platform can supplant the others, albeit there are some common things (68K software)"

I disagree there. UAE and all FPGA projects should support AGA and besides if you create applications or games they should use the OS and not hack hardware. If they do that the OS is responsible to support the environment. Aros 68k runs on emulation and will run on FPGA based solutions. As long as a developer uses the OS he is on the safe side. So both emulation and real hardware (FPGA) are supporting each other.

Quote:

broadblues wrote: (New filesystem API) were developed to enable the easier creation of new files systems in general. To avoid the nightmare of undertsanding DOS packets etc etc. Much of the standard functionailty is now handed off to DOS simplifying it further. packet support remains via DOS's packet emulator, so that older filesystems may run seamlessly.

It's funny. AROS developers decided, in its infancy days, that AmigaOS DOS packets were basically evil and decided to go for a IO device based approach instead, leaving compatibility to a packet emulator. After many years that quite nobody wrote any reliable FS that wouldn't use packets, they almost changed mind. History does not lack of irony.

Quote:

OlafS25 wrote: @cdimauro "Amiga and post-Amiga are basically constrained to be and rest hobbies, so I don't think that something will change from this point-of-view, even when some modern feature will be implemented. The road to the future was already marked: we lose the chance to have a role in the mainstream market (which doesn't mean also Windows: I put OS X and Linux as well, because they are known to the people, or at least people use them)." So you say these features should be implementend even though they will not change anything? That is exactly what I see, your "modern OS" will not change anything. We will not get just one application or game more because we have 64bit. So you agree to me there . Then why doing all the efforts at all? When one strategy obviously not works then it is better to go a different route.

They will change the user experience, as I was talking before. Again: do you like that a bug in an application raises down the entire system? I, as a user, don't like it.
Quote:

"Quote:68k (back to my thesis) is different/creating curiosity and you have a huge software base and lots of documentations you can start on. We can use it though UAE, or some new FPGA project. However I don't think that a 68K platform can supplant the others, albeit there are some common things (68K software)" I disagree there. UAE and all FPGA projects should support AGA and besides if you create applications or games they should use the OS and not hack hardware.

Please: 99% of AGA games killed the o.s.: it was almost the only way to get good performance.

And if you want to run an old game, whatever is OCS or AGA, UAE is very good solution, and it's already doable with every post-Amiga platform.

Having an FPGA doesn't change a comma in this case.
Quote:

If they do that the OS is responsible to support the environment.

I think that NEW games designed for FPGAs should pass through the o.s., but for old stuff see above.
Quote:

Aros 68k runs on emulation and will run on FPGA based solutions. As long as a developer uses the OS he is on the safe side. So both emulation and real hardware (FPGA) are supporting each other.

Sure, but for old software it's different. And, as you know, currently there's almost only old software...

@paolone

Quote:

paolone wrote: Quote: broadblues wrote: (New filesystem API) were developed to enable the easier creation of new files systems in general. To avoid the nightmare of undertsanding DOS packets etc etc. Much of the standard functionailty is now handed off to DOS simplifying it further. packet support remains via DOS's packet emulator, so that older filesystems may run seamlessly. It's funny. AROS developers decided, in its infancy days, that AmigaOS DOS packets were basically evil and decided to go for a IO device based approach instead, leaving compatibility to a packet emulator. After many years that quite nobody wrote any reliable FS that wouldn't use packets, they almost changed mind. History does not lack of irony.

Very interesting. I hope that AROS coders just changed the mind, but left the new I/O device model.

Re: AROS 68k
I just wish that the OS routines were more complete. Especially in the realms of Copper coprocessor support. There has been the ability in AmigaOS 2.x+ to have multiple buffers of Copper instructions but lacking a macro and a subroutine to actually advance to the next buffer! If somebody knew the OS well enough, it would take less than an afternoon to add it.

Maybe if I write a proof-of-concept in an executable, the AROS team would be more likely to adopt the code. The only affected subroutine besides the new one would be MrgCop() and anything that calls it.

Re: Memory Protection and Managed code
I agree with cdimauro. Memory protection is limited by the page size of the MMU while managed code has byte-level granularity. Neither is a catch-all. I consider managed code to be a higher priority because of that granularity issue. All that's needed is a 68020+ CPU and a CHK opcode for each array access that isn't a constant. That's cheaper than an MMU+all the memory needed for the page tables.

One thing I would accept as a substitute for the large page tables required by some MMUs is a minimal MMU that doesn't support address translation. All it would need to do is mark some regions as read-only and so on. This would still allow the simple flat memory model that Amigans have long known and loved while providing protection for memory at the same time.