Dominant future AmigaOS? MOS vs OS4 vs AROS

[Hammer]

mahen wrote:

Right now MOS lacks a few details, but has new feature and is very compatible and stable.

Relative to what (e.g. AmigaOS 3.9 or AmigaOS 4.0)?
IF your reference is AmigaOS 4.0, how did you obtain a copy of this operating system?

"Very compatible and stable" doesn't quite jive with OSnew’s reviews regarding Pegasos and MorphOS (i.e. Eugenia Loli-Queru’s review(2003-05-19)?

PS; My point of reference in regards to AmigaOS usability and stability is a Birdie/VisualPref/AmiStart/StackAttack/Executive enhanced AmigaOS 3.9**.

**Running on WinUAE-JIT .8.22.R7, Athlon 1800+ (Tbread core) @1.9Ghz(o/c), ASUS nForce II 400 (with MCP-T Southbridge), 512Mb PC3200 DDR SDRAM, nVidia Geforce 4 TI VIVO.

[Hammer]

There's plenty of software out there that appears to be system friendly and some of it varies on just how system friendly it is.

Of course.

The CIA's aren't there and as such neither are the resources.

Can they create a virtual device emulator (e.g. nallepuh) ?

There is no audio device redirector either.

What about nallepuh?

[Hammer]

Warface wrote:
Eugenia expected  memory protection.

That’s one issue…

Stability for the time being is similar to an Amiga system,

Not without the missing devices and services. Virtual devices could help the overall application compatibility.

Note that I’m not referring to memory protection issues. I’m referring to application compatibility and the stability to run them. Missing services will reduce the overall stability to run legacy applications.
This unknown factor (i.e. will this run or will this not run) doesn’t help MOS’s cause.

[Hammer]

MOS has something similar to Birdie/Visual Prefs. Last time I tried, AmiStart failed to work. StackAttack isn't needed.  

That was not the issue. Note that I’m well aware of MOS's 2D GUI texturing/skinning capabilities. The statement was a brief summary of my current AmigaOS 3.9 set-up and patches.

The issue is; Can MOS 1.3 ecosystem replace AmigaOS 3.9 ecosystem?

**AmigaOS 3.9 based set-ups can cover from Amithlon/Berniethlon, WinUAE-JIT and Classic Amiga HW.

[Hammer]

AmiGR wrote:
Nahlepuh and stuff like it are mostly MMU hacks.
Such MMU hacks are not even considered, as they
will slow down everything significantly.

Did you forget 68K CPU emulation? One could use sound blaster emulation within WinXP’s dos box as another example.

Every poke to Paula would produce MMU exceptions that would have to be handled with multitasking disabled. Such stuff have no place in a clean OS.

What about newbaer.lha (Paula-to-AHI redirector for AMIthlon)?  

The goal with both solutions is not only to produce a
compatible and extended OS but to clean it up as well.

Nice goals but how does one reach that goal in a realistic fashion?

[Hammer]

 For example, MorphOS uses emulation traps instead.

It that for audio (Paula compatible) or the 68K CPU?

Newbaer uses the mmu stuff outside of the emulation box, on the linux side.
It still slows stuff down, but on a 2ghz machine it's not visible.

In regards to speed, it’s fine on 1.33Ghz Athlon model 4. Also, it can’t be slower than WinUAE-JIT, i.e. emulates the entire Amiga Classic ecosystem.  

Amithlon was tested from the following AMD boxes
1. 1.13Ghz Athlon (Thunderbird) MSI VIA KT266
2. 1.33Ghz Athlon (Thunderbird) MSI VIA KT133A or/and MSI VIA KT266
3. 1.53Ghz Athlon XP(Palomino), ASUS nForce II or/and MSI VIA KT266
4. 1.90Ghz Athlon XP(Thoroughbred) ASUS nForce II 400 (@333Mhz FSB)

All has at least 512 MB RAM. Video cards ranges from Geforce 2 MX/400 to Geforce 4 TI.
 

[Hammer]

Well, as I said, on Amithlon, it's done externally afaik.
Such stuff have no place in a cleanly made OS.

That would be a point of contention i.e. a bias for legacy (investment protection, boat anchor) VS a bias for pure clean OS.  

That's not how it could work on a native OS.

What about midi softsyns** (virtual midi wave table)? Also, what about software channel audio mixing, software audio reverb and chorus?  

I don’t think PowerPC G3 @800Mhz is a slow processor; it’s definitely not a Celeron/Duron Class CPU.  

**With Windows, example of softsyns is Yamaha's Soft XG50 (approximation of  Yamaha's XG-50 HW). This software can at least consume the entire 150Mhz Pentium MMX’s processing power.  But the result is very good. It beats SBlive's HW midi wave table's results. It’s not a problem when you have at least full L2 cache equipped 800Mhz CPU. This virtual device can also be use as the primary wave device (one could apply Soft XG’s reverb and  chorus).

Just like Soft XG50, virtual devices can give the user options. I’m not for one-size fits all dogma.  

[Hammer]

Well, the problem is that all Paula using proggies, just bang it directly, without going through audio.device.

It’s a matter of the current implementation.  Unlike X86 world, skill sets, manpower and financial support is in short supply within the Amiga land.

To make them work, you need a way to find out when a proggie tries to access the Paula registers,

I recall, AmigaOS 4.0 reserve some address space for this kind of problems? It’s probably incomplete at AmigaOS 4.0 state.

Well, the problem is that all Paula using proggies, just bang it directly, without going through audio.device.
 

Does MorphOS 1.3/1.4 handles any audio.device issues? Does MorphOS 1.3/1.4 handles any CIA resources issues?  

[Hammer]

AmiGR wrote:

Well, the problem is that all Paula using proggies, just bang it directly, without going through audio.device.
To make them work, you need a way to find out when a proggie tries to access the Paula registers,
this can be done via the MMU, by setting us a virtual
paula register setup there. Any access there would
cause a nice MMU exception, disabling the multitasking
for a while, that would have to be
passed to the emulator. That would slow down the
system a lot if it's not done in a careful and sufficiently dirty and hackish way.

Would that be a problem for IPC bias PowerPC G3@800Mhz? The slower CyberStormPPC users may not have to worry about these issues since they usually equipped with classic Amiga hardware.  

PS; I’m factoring Motorola/IBM’s roll out of their new PowerPC CPUs, thus making the older PowerPCs cheaper.  

[Hammer]

Actually there are quite some skilled people in here.

One may need more them.

The problem is that such stuff take time and it would require strict understanding to do such tasks with big teams.

To reduce time for R&D, one may have to throw in money and manpower at the problem. These factors wouldn’t be abundant for any of the Amiga related companies.

Yep, but we'll have to see how it works. It sounds that it will slow the system down, but we'll really have to see that in practice.

What about in X86 world? Note that, this particular feature is just an option (it's a user's choice).

There's an audio.device replacement but the
problem is that most apps that open up the audio
device, allocate the channels and then just bang
paula. No Paula emulation is there and it's not planned.

That would answer most of the questions on which product would be the dominant. If Windows is anything to go by (i.e. best legacy bias while moving forward).

Forced** to buying new/replacing existing applications feels like going to yet another platform.
**Lost of application collections due incompatibilities. People generally wants to migrate slowly (i.e. obtaining new software at their own time). Only the 'new' applications (with 'new' capabilities and features) open up new possibilities.