New improved intuition.library version from the Kickstart 3.1

[Heiroglyph]

I see both sides of the argument around here.

First and foremost, don't break the existing API. We don't get much new software, so the old stuff needs to continue working.

Realistically, we even need a few of the bugs if the original author won't or can't update the software to be compatible with fixed versions of the library. Obviously this needs to be evaluated on a case by case basis, but you get my point.

If there was actual movement by the software owners, then I'd be protecting them, but it's effectively, if not legally, abandoned.

If any of the owners still care, they really need to speak up and tell us who owns what, how to submit bugs and where to send money if needed. If you're inaccessible or invisible, don't complain when someone patches your code behind your back. Maybe someone should start a page for that kind of contact information.

If they don't care to accept bug reports and continue development, then I have no sympathy for their copyright protections. Morally I'm completely fine with whatever happens to abandoned code, including my own.

Beyond that, I'm all for what Cosmos is doing.

When you've got no C source, the disassembly is the only source available and he's making it readable.

While the speedups are good, assuming they translate to real world benchmark proven results, I think the most important and measurable improvement he's making is optimizing the size. We've only got so much ROM space so the more we can pack into there, the better. Removing C translation cruft is an easy way to reduce the size.

If he fixes some bugs without side effects, that's even better.

With the language barrier it's a little hard to tell if we're interpreting him correctly, but clearly his heart is in the right place and he's actually contributing to the community.

I applaud anyone who actually contributes, but damn we're an angry, uncooperative group of people.

[Heiroglyph]

Or get new bugs because the new, ehem, author doesn't understand why particular choices were made, or at least, cannot read the sources...  

I was referring to legitimate bugs. There's always the possibility that some software was written not against the API as documented, but rather to the observed behavior.

It may not be an issue, but that's the only reason I can see for breaking existing applications.

No. Worse. Actually, most of the stuff should be *removed* from the ROM. Or are you suggesting that every time somebody makes an update users should burn a new ROM? RAM is cheap enough these days, even for Amiga. Loading the code into RAM costs nothing, it loads fast enough, and it is extremely simple to update it there. You can even write-protect the code in RAM if you want to. (MuProtectModules) So, there is absolutely no advantage of placing code in ROM.  

I go back and forth on this issue but I tend to agree with you.

You can either try to put more in ROM or provide a more complete disk loading mechanism. (probably a few other options I'm not thinking of)

For a while he's been trying to get a few more items available early in the boot process, such as working RTG, and packing more into the ROM is one valid way of getting there.

With the lack of development in general, having the libraries in a ROM starts to look appealing too.

In the end, it's no improvement - the reverse engineered code does not loose its copyright just because it was reverse engineered, so it cannot be published, on a legal basis. Thus, whether anyone publishes the original source, or Cosmos puts his sources hack onto a public server is no difference. The difference is only *who* takes the risk, but not *why* or *if*. The problem remains the same problem, either way.

It's still risky, but I think fewer and fewer people care. Leaving it alone isn't getting us anywhere either because the owners don't seem to care about the code until they can litigate over it.

The only way to *solve* the problem is to make a clean-room implementation of the AmgiaOs code in first place. Yes, AROS does that. Thus, why not contribute there?

I can't speak for why he doesn't work with AROS.

I don't contribute because I don't like the direction they took. It seems like they work backwards from x86 while adding third-party features, making it a massive, untestable, never ending ordeal.

IMHO, they should have replaced one library from the ROM at a time on 68k before they even started on disk libraries.

That ROM replacement would have given us a start on owning the OS as a community and the ability to legally make the changes you mentioned such as loading from disk.

One way or another, I think it is a completely superfluous undertaking, only fragmenting AmigaOs further, without actually offering the chance to resolve any single problem the platform has.

He's not saving the platform, but he's having fun and quite a few people are interested in it. No more of a loss than playing a game or reading a book, yet a few people will enjoy using his changes.

[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.