Which is better? OS 4 or Morph OS . . .

[boing]

Maybe the better question is this:

Is there a way to run OS4 and MorphOS on the same box?  By hook or by crook.  I don't give a darn about bending the rules.

[kd7ota]

The Commodore 64 smokes both OS 4 and Morph OS.  :-D  :-)

[Karlos]

boing wrote:

Maybe the better question is this:

Is there a way to run OS4 and MorphOS on the same box?  By hook or by crook.  I don't give a darn about bending the rules.

If you own a classic PPC based system and you have access to OS4, yes. If you own either an A1 or Peg, then for now you are limited to either/or.

[xeron]

AmigaMance wrote:
Workbench 3 (with mcp installed) is much more pleasant and productive enviroment for me, even if it looks uglier. I don't care about that.

Yeah, OS4 has the original Amiga Workbench, but ported to PPC and improved. Also, an OS4 native port of Directory Opus Magellan is due to be released very soon.

[AmigaMance]

@piru

@AmigaMance
You could run Workbench on MOS, if you prefer it over Ambient, see AmigaWBOnPegasos.readme

 Ok, i will try it.

Quote:


Which OS is generally faster?


I haven't seen reliable benchmarking done on the identical hardware, so I can't comment that part. If run on their native systems Pegasos II and AmigaONE, MorphOS and Pegasos II win for sure, since Pegasos II with G4 is faster than any AmigaONE available.

 You're right. My question should have been: "Which OS runs faster on a classic?" But, i guess, only a OS4 beta-tester with a Amiga 1200/4000 can answer that.

Quote:


Which has the fastest 68k emulation?


To my knowlege only MorphOS has transparent JIT compiler available for general public. So, MorphOS 68k emulation is faster.

 I'm getting a little confused here, probably because i'm not familiar with the new systems. How AOS4 is able to run 68k code without a 68k emulator?
 Here is an excerpt from the AOS4 feature list:
"Just in Time (JIT) 68K emulation
Dynamic recompilation or JIT compilation is a technique whereby (in this case) 68K machine code is translated on the fly to PPC machine code which is stored in a temporary buffer to avoid recompilation each time the recompiled code is executed. All 68040 instructions including FPU instructions are fully emulated. Even on a lowly 603e@160 Mhz the recompiled code reaches and in some cases surpasses the speed of a 68060@50 Mhz."


@xeron
 Excellent!

[Karlos]

@AmigaMance

OS4 has a 68K interpreter built in. There is also a JIT implementation available for it called Petunia but this is currently restricted to betatesters. I am a bit behind the current release as I have had no time to spend on my system, but at the last test it was fast enough. Depending on the code at hand, my 240MHz 603 could interpretively emulate many 68K applications at a speed comparable to my real 68040 @ 25MHz, which was pleasently surprising. The JIT, suffice to say, was a lot faster.

-edit-

Clarification to avoid any misunderstanding about the general availablity of petunia.

[TheMagicM]

If you own a classic PPC based system and you have access to OS4, yes. If you own either an A1 or Peg, then for now you are limited to either/or.

Really?  I didnt think you could run OS4 on a classic Amiga w/PPC..from what I saw only MorphOS runs off of both PPC (Pegasos and Classic + PPC)


-Alex

[itix]

Remember, a parent class never does have any knowledge of any of any of its childrens' unique methods or properties. Consider an actual C++ class heirarchy. If your parent class is HouseholdPet, and you have sublcasses of GoldFish, Cat, Dog, Budgie, etc, *only* the interface defined by HouseholdPet is common to all. Each implements the HouseholdPet interface and adds some unique methodst too. Dog might add a method chasePostman() to the existing set of methods it inherited from HouseholdPet.

I'm not sure: would every class have its own interface structure or would subclasses inherit its parent interface structure and extend it. If so, how?

In this regard, interfaces are no different to classes. I can't realistically call a method of a sub interface via a handle to the parent that the parent does not already advertise.

In BOOPSI you can. It is just ignored by super class. Either way interface (as in struct Interface) cant replace Intuition objects at all.

The second issue is polymorphism. Customising methods of the parent interface to suit the specific child so that different instances of an interface might perform the same method call differently. This is perfectly doable. Remember, the methods are really just embedded function pointers within the interface structure and can be changed. If I cloned an instance of IKarlDevice, I can provide my own function to handle the Initialize() method specifically for that one instance (similar to SetFunction() on a library).

That could be an advantage sometimes.

If you prefer doing this type of thing with 3.x style library bases and the 3.x source compatible ways of calling their code, that is entirely up to you. I personally find it much less cumbersome to accomplish this type of thing with the interface syntax.

In my opinion 3.x style is just fine. I've used it so many years already :-O

[Karlos]

@itix

I really think we should open another thread for this, but...

itix wrote:

I'm not sure: would every class have its own interface structure or would subclasses inherit its parent interface structure and extend it. If so, how?

For simple extensions, where you only need to change a method or two, cloning an instance of the parent and changing the function pointers for the methods you need would be sufficient.

When you need an extended structure, every class having its own interface structure is likely simplest as there simply is no way in C to extend a structure. Otherwise you do what you would to in a library and have the parent structure as the first member and remember which cast you are using. This is a limitation of C itself, not interfaces or library bases.

When you need an extended structure, you have

In BOOPSI you can. It is just ignored by super class. Either way interface (as in struct Interface) cant replace intuition objects at all.

Of course it can't replace BOOPSI directly (that is making existing boopsi fit interfaces and remain compatible), or at least without a lot of effort.

It can, however easily replace boopsi as a fondation. I've already experimented a little in this area, a simple inteface definition with event handler / render methods implemented as one of three simple objects (this was a direct adaptation of my C++ framwork's unfinished guilib idea).

A future GUI framework not based on boopsi but upon interfaces is entirely possible, it just would have no backwards compatibiliy with boopsi at any level.

In my opinion 3.x style is just fine. I've used it so many years already :-O

Entirely your choice. Have you tried any of the types of OO construct design discussed here using only 3.x style and library bases? I have and it is quite frustrating compared to the interface approach.

[Piru]

@Karlos

There is also a JIT implementation available for it called Petunia.

It is? Damn, I must have gotten some wrong information then. My source claimed it wasn't available outside of betatesting (that is, that it wouldn't be available for mere mortals).

[SamuraiCrow]

I guess Karlos is a betatester or knows one because the classic versions of AOS 4 and Petunia aren't going to be released until the final release.  The main advantage of Petunia over MOS' JIT is that Petunia will be supported under EUAE.  (Of course if you wanted to download the source to EUAE and splice it together yourself you could.)

[Piru]

@SamuraiCrow

The main advantage of Petunia over MOS' JIT is that Petunia will be supported under EUAE.

Says who?

I have some serious doubts this could work. At least not without some massive rewriting and slowdowns to the JIT (all memory accesses would need to be trapped etc etc).

This is what the Petunia author says:

Do you plan any support for UAE?
I don't know yet. There will be a possibility of reaching the emulation from the "outside", so theoretically UAE would even go on with Petunia's engine, if somebody does a special version. I don't intend to do it, but I would help gladly to anybody in this work.

"Theoretically" is far from "will", I'd say.

(Of course if you wanted to download the source to EUAE and splice it together yourself you could.)

Uh?


Anyway, speaking of advantages: At some point MorphOS Trance was something like 3X faster than Petunia. I doubt this is the case anymore, though. It'd be interesting to see some fresh benchmarks.. *hint hint*

[SamuraiCrow]

@Piru

Fair enough.  The author of EUAE, Rich Drummond, had expressed an interest in using Petunia in conjunction with EUAE but it wasn't finallized.

[X-ray]

@ Piru and Karlos

For my A4KT, with PPC and PIV am I correct in saying I could run OS4 for classic machines when it comes out, but in order to run MorphOS I would have to get a CybervisionPPC graphic card?

It seems to me (if I understand this correctly) that I could have 3 boot devices and run the 3 main OSes like this:

1) 3.X by means of onboard AGA or PIV, and the 060 on my Cyberstorm.
2) OS4 by means of the PPC and the PIV.
3) MorphOS by means of a Cybervision PPC and the PPC itself (assuming I get a Cybervison PPC).

That would be quite nice. I suppose there won't be a problem with me having the PIV and the CybervisionPPC installed simultaneously as long as I only have one set of drivers active per boot?

[itix]

It can, however easily replace boopsi as a fondation. I've already experimented a little in this area, a simple inteface definition with event handler / render methods implemented as one of three simple objects (this was a direct adaptation of my C++ framwork's unfinished guilib idea).

But would it give a significant performance boost compared to BOOPSI? Calling a method in BOOPSI is not very expensive after all. There is some extra overhead in dispatchers but I think current BOOPSI is quite good.

Surely interfaces have some flexibility to be used like this. And I know few cases where I could take an advantage of interfaces.

Entirely your choice. Have you tried any of the types of OO construct design discussed here using only 3.x style and library bases? I have and it is quite frustrating compared to the interface approach.

I have used only C++ and Java but there I dont have to care about low level details.

Btw it seems in Windows you have interfaces too (in COM objects, I guess).

[Piru]

@X-ray

That should work, however you'd still need to figure out how to switch the monitor input (manually move the monitor cable, have a monitor switchbox, have two monitors or have a monitor with multiple inputs).