New improved intuition.library version from the Kickstart 3.1

[guest11527]

No : we need only one direction, and all together... And the RIGHT direction (success), not the many dead-ends...

But it's impossible for many reasons (money, old fight PUP/WOS, big melon...)

It's really kind of ironic. On one hand, you're requesting that we go into the right direction all together. On the other, you are exactly preventing that by avoiding any type of coordination. I'm not even caring how you want to coordinate - either with the owners, or with the folks that attempt an Open Source rewrite. One way or another, you cannot define the direction yourself, you need other people. You can try to work on the original sources and avoid a fragmentation by talking to Hyperion. Or you can try to create an OpenSource look-a-like where your creativity is not hindered by management decisions, but community decisions.  

Yet, you want to do your "own thing", and don't even see that you are perverting exactly these goals...

Well, anyhow. "You" is not "we all together". Maybe you'll understand later... I can't help it anymore.

[Heiroglyph]

As Wawa said we need people that contribute to Aros 68k. You do not contribute because of the direction it takes? What direction do you mean?

I mean working on x86 first, then eventually trying to port that back to 68k. That's just insane from simplicity,  testing and performance standpoints.

If you go from 68k to x86, the growing pains aren't so bad. You have a reasonably stable 68k codebase and add the required hardware support. If it was fast enough on 68k, then it's going to be stupidly fast on x86.

Stripping out the x86-isms to make a 68k port will in many cases be worse than starting from scratch.

We only needed about 2MB of 68k binaries to have accomplished something, but because of the development process they chose, it's taking literally decades with no clear end in sight.

Keep in mind, these were just my personal reasons. I signed up to contribute, then quit after I got a feel for the project.

I've got nothing against AROS at all, I hope like hell they get it to work, but my gut instinct is that I won't see worthwhile results for the time I would invest.

The thread is about 68k so we do not talk (or be in interested in) the direction X86 takes.

We can't help but talk about x86 AROS when AROS is mentioned, that's their main platform and we're getting PC code ported to 68k.

It is very compatible already, it runs most of the newer applications, many games, WHDLoad and many others. You can replace almost everything easily by copying 68k files, I do that extensively on my distribution. I use Magellan as desktop, I use MUI38 instead of Zune, I have added tons of components from 68k world, original are of course basic libs like dos.library, gadtools, intuition, AHI and CybergraphX 3.

That's interesting, I didn't realize that you could mix and match to that extent.

On UAE it runs very well, what still needs more love is supporting classic hardware (expecially optimizations that it runs faster). I do not more know what I can do additionally to persuade people what big chances it offers. I think of making a survey and perhaps a bounty for that, then people will have a chance to show interest, if not I personal will concentrate on Aros 68k on emulation.

If it doesn't run fast on UAE, there are some serious problems. The last time I tried a complete AROS 68k in WinUAE, even it was extremely sluggish and crashed easily, but that was over a year ago.

Is the code stable enough to optimize yet? It's easy to miss obvious optimizations when writing for fast x86 CPUs, so there may be some easy targets, but if it's still as buggy as I remember, making the code less readable would be a huge mistake.

Honestly, I'd think a lot of the drawing code shouldn't even be shared with x86 and that seemed to be one of the worst offenders when I last tried it.

[Minuous]

You can try to work on the original sources and avoid a fragmentation by talking to Hyperion.

Not sure how that would help as it is well known that they don't have the source code.

[biggun]

First of all.

Congratulations Cosmos you invested a lof of time in improving this.
This is great.

I wonder one thing - are your improvement available as source too?

[psxphill]

I'm not forcing to make copies. I'm requiring that devices provide the data where the user requested them.

And the user cannot allocate memory in the most optimal way, so you are forcing devices to make copies.
 
 If the user allocates memory then for performance you need to make it the applications responsibility to allocate the correct memory, which is what we have now.
 
 Saying it's broken because it doesn't work like Windows is a rather odd stance.

[psxphill]

I mean working on x86 first, then eventually trying to port that back to 68k. That's just insane from simplicity, testing and performance standpoints.

I don't think they planned to port it back, or they would have done 68k first.
 
 From what I can tell it's mostly the graphics HID that is the problem, as well as sub optimal compilers.

[guest11527]

Not sure how that would help as it is well known that they don't have the source code.

Where did you get this nonsense from? Of course they do.

[guest11527]

Saying it's broken because it doesn't work like Windows is a rather odd stance.

It's not broken "because it doesn't work like windows". It is broken because correct operation requires additional parameters that cannot be obtained by an API. In other words, with the current state of affairs, the *end user* has to enter correct parameters *manually*, and into a system component that is probably one important user of the device, but not the *only* user of a device.

Thus, it is not only because the system doesn't know its parameters, and they are registered at the FFS by the user (who is typically not knowledgeable enough to provide such information in first place), it is also that they are registered at wrong component. Now maybe the FFS knows (via the user, by pure chance) what it has to do. But any other program still doesn't, and has to second guess from the FileSystemStartup Message - for which we have neither a well-documented interface as for how to obtain it. (Note well that a lot of other stuff can be linked into the startup code of the a DOS DeviceNode, it's really handler-private information).

[wawrzon]

I don't think they planned to port it back, or they would have done 68k first.

the aros team might not initially consider it a priority but it has advantages to x86 platform as well, researching and improving compatibility, directly comparing behavior and performance of critical parts and so on. from my rather regular contact with aros devs about it and i know they usually care, only they are also limited on time. unfortunately i know only of olaf reporting back to them on 68k subjects. if more people got involved or at least gave it some time and attention it could take off a little, still it looks like ppc emu on uae gets even more attention. not exactly encouraging.

[bloodline]

I don't think they planned to port it back, or they would have done 68k first.

 

When AROS was started, AmigaOS had "official" support... Whatever that actually turned out to be... It wasn't the intention of AROS to get in the way that.

 From what I can tell it's mostly the graphics HID that is the problem, as well as sub optimal compilers.

Compilers tend to make the code a bit larger than hand coded ASM (naturally), and you correct about the graphics, no one has actually written an "Amiga Driver" yet, it still just does all graphics operations as readPixel/writePixel (the emergency fallback gfx mode of AROS), fix that and you will have sorted the major bottleneck.

[itix]

And the user cannot allocate memory in the most optimal way, so you are forcing devices to make copies.
 
 If the user allocates memory then for performance you need to make it the applications responsibility to allocate the correct memory, which is what we have now.

Please tell me how to do it. Lets say, I want to create generic trackdisk based copier that copies data from drive A to drive B. Source drive could use trackdisk.device and destination drive could use usbtrackdisk.device.

What is the most optimal buffer type application should use? And how to find it out? Ask user for correct memory type?

[warpdesign]

Compilers tend to make the code a bit larger than hand coded ASM (naturally), and you correct about the graphics, no one has actually written an "Amiga Driver" yet, it still just does all graphics operations as readPixel/writePixel (the emergency fallback gfx mode of AROS), fix that and you will have sorted the major bottleneck.

I thought someone was working on it (Tony) ? Now I understand why it's so slow.

[OlafS3]

AROS is no solution, it is still missing functionality that was in OS3.5 15 years ago...

What exactly is missing? And again if you talk about 68k you can (almost) replace everything with original 68k libraries. By this I have f.e. added MUI38 (and removed Zune). That almost works for everything.

[OlafS3]

I thought someone was working on it (Tony) ? Now I understand why it's so slow.

Toni did something lately but now he is busy with PPC. And Jason has changed to Arix a long time ago.

[OlafS3]

I mean working on x86 first, then eventually trying to port that back to 68k. That's just insane from simplicity,  testing and performance standpoints.

If you go from 68k to x86, the growing pains aren't so bad. You have a reasonably stable 68k codebase and add the required hardware support. If it was fast enough on 68k, then it's going to be stupidly fast on x86.

Stripping out the x86-isms to make a 68k port will in many cases be worse than starting from scratch.

We only needed about 2MB of 68k binaries to have accomplished something, but because of the development process they chose, it's taking literally decades with no clear end in sight.

Keep in mind, these were just my personal reasons. I signed up to contribute, then quit after I got a feel for the project.

I've got nothing against AROS at all, I hope like hell they get it to work, but my gut instinct is that I won't see worthwhile results for the time I would invest.



We can't help but talk about x86 AROS when AROS is mentioned, that's their main platform and we're getting PC code ported to 68k.



That's interesting, I didn't realize that you could mix and match to that extent.



If it doesn't run fast on UAE, there are some serious problems. The last time I tried a complete AROS 68k in WinUAE, even it was extremely sluggish and crashed easily, but that was over a year ago.

Is the code stable enough to optimize yet? It's easy to miss obvious optimizations when writing for fast x86 CPUs, so there may be some easy targets, but if it's still as buggy as I remember, making the code less readable would be a huge mistake.

Honestly, I'd think a lot of the drawing code shouldn't even be shared with x86 and that seemed to be one of the worst offenders when I last tried it.

I agree with you that they should have started on 68k first and then port it to new platforms, that would have added lots of users and made development much easier but that is past.

As far as I know it is no problem to add/replace code in a branch, I can remember that Amiblitz compiled software did not run but after some devs were interested and looked at it they found a specific solution so I think it must be possible. The graphic part is certainly the most critical part so if someone with enough experience would look at it the biggest problems would be solved. That is of course the biggest problem for "real hardware", on fast platforms like UAE you do not see anything.

[eliyahu]

What exactly is missing? And again if you talk about 68k you can (almost) replace everything with original 68k libraries. By this I have f.e. added MUI38 (and removed Zune). That almost works for everything.

olaf: would you or one of the other AROS 68K users be interested in creating a guide on which libraries and tools we can use from AOS on our AROS installs? that would be hugely helpful to us noobs.

-- eliyahu