Amiga.org

Amiga News and Community Announcements => Amiga News and Community Announcements => Topic started by: Cosmos on April 06, 2014, 06:14:31 AM

Title: New improved intuition.library version from the Kickstart 3.1
Post by: Cosmos on April 06, 2014, 06:14:31 AM
Ok folks, new intuition.library now working fine on my real A1200 !

RJ Mical will eat his hat !!

archive = http://cosmosunivers.free.fr/download/intuition_4086b4.lha

.readme = http://cosmosunivers.free.fr/download/intuition.readme



Enjoy !
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Cosmos on April 06, 2014, 08:08:40 AM
The next beta 5 include now SIMPLE_REFRESH : http://aminet.net/package/util/wb/clvrwin
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: psxphill on April 06, 2014, 08:42:46 AM
Quote from: Cosmos;762033
RJ Mical will eat his hat !!

He left commodore in 1986, before 1.2 was released.
 
So you can only be sure that the code in 1.1 was his, which it might well be. I suspect at the time he was purely interested in getting the damned thing shipped :D
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: paul1981 on April 06, 2014, 12:01:21 PM
Quote from: Cosmos;762033
Ok folks, new intuition.library now working fine on my real A1200 !

RJ Mical will eat his hat !!

archive = http://cosmosunivers.free.fr/download/intuition_4086b4.lha

.readme = http://cosmosunivers.free.fr/download/intuition.readme



Enjoy !

Thanks Cosmos. I look forward to having the time to try this new library out. :)

Keep up the good work mate.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Cosmos on April 06, 2014, 12:23:20 PM
Quote from: psxphill;762039
He left commodore in 1986, before 1.2 was released.
 
So you can only be sure that the code in 1.1 was his, which it might well be. I suspect at the time he was purely interested in getting the damned thing shipped :D


Oh, you're right !

All apologies to RJ Mical... Was a little french joke from me...
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: danwood on April 06, 2014, 04:40:15 PM
Looks interesting, does this have any benefits for OS 3.9 users?
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kickstart on April 06, 2014, 06:47:20 PM
@cosmos

My respects for you, some real amiga things, not mouse pads, stickers, pc keyboards...
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: dariusz_wisniewski on April 07, 2014, 02:37:37 PM
Great job :banana: Must change jumper setting in my B1230 to turn on kick mapping and test this new lib.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: polyp2000 on April 07, 2014, 03:32:36 PM
Sounds cool will it make workbench faster?
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Cosmos on April 07, 2014, 03:40:48 PM
A very little bit for the moment...

A friend of mine report me this (BlizzardPPC + BVision) :
"Very interesting patch
Tested it and it seems to be working.
It does speed up some operations up to 2 times!
OpenWin
MoveWin
SizeWin"


:)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: AmigaClassicRule on April 07, 2014, 06:56:10 PM
Quote from: Cosmos;762131
A very little bit for the moment...

A friend of mine report me this (BlizzardPPC + BVision) :
"Very interesting patch
Tested it and it seems to be working.
It does speed up some operations up to 2 times!
OpenWin
MoveWin
SizeWin"


:)

I have a very stock Amiga 4000D here with me, the basic old default stock Amiga 4000D. If I wish to use update my intuition.library with the one you have here how about I do this?

What are the installation tips required to do it? Thanks in advance.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Cosmos on April 08, 2014, 07:28:52 AM
You have to use LoadModule or LoadResident...
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Ancalimon on July 23, 2014, 09:30:42 PM
Reported a problem to Cosmos. He said he will look into it after he finishes something else.

Meanwhile can someone try opening Vinced prefs from the SYS:Prefs drawer?

Here when I use Cosmos's intuition.library, the prefs window open squashed.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Cosmos on August 17, 2014, 07:28:57 PM
Ok, silly bug fixed... Thanks for reporting...

New beta5 maybe tomorrow if I get a good sleep !!




;)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Cosmos on August 18, 2014, 03:53:15 AM
intuition.library v40.86 beta 5 (105 708 bytes)

  - fix R_SizeWindow
  - R_OpenWindow use now smart_refresh mode
  - a lot of tiny subroutines inlined
  - 8828 bytes saved


======> http://leblogdecosmos.blogspot.fr/p/coding.html



(Oups : next beta will include smart_refresh mode (http://aminet.net/package/util/wb/SmartWB105) in R_OpenWindowTagList too)




:)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Cosmos on August 18, 2014, 09:12:50 AM
One bug report about BenchTrash prefs : it's an issue from this proggy, not from my new intuition.library version...

The little fix is ready for download (at the end) : http://leblogdecosmos.blogspot.fr/p/coding.html





:)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 19, 2014, 04:52:46 AM
Quote from: Cosmos;771107
One bug report about BenchTrash prefs : it's an issue from this proggy, not from my new intuition.library version...

With all necessary respect: If you find a bug (or believe to have found a bug, I don't know), please *report it* so it can be fixed upstream. Please remove that patch, (yes, I'm serious!) I don't prefer my programs to be patched except in source code, and except by someone having the source code with my permission.  Thank you.  Thus, what exactly is the issue, what is the observable effect, and what do you believe it may fix. What you made is not a bug report. It's just messing with somebody's others code without even asking first. What's actually so hard about this step?
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Cosmos on August 19, 2014, 05:34:34 AM
When I ask coders for improving something : the answer is always no... Or no answer...

I asked you by email about updating the mmu.library (to make it romable if my memory is good...) and your answer was no some years ago...

So now I do by myself without any permession, I don't care... (I won't reverse your mmu.library, stay cool, ok ?!)

Amiga Classic 68k must evolve by any ways : if no evolution, it's the complete death...


For BenchTrash : it's a missing "moveq #1,d0" just after a "jsr -$72(a6)"... I'll remove my patch only is you release a fixed version quickly...



(PS : I know you will want write 3 pages of silly answer as usual : but not on my thread here... Do no pollute my work here with your well know negativity : open a new thread for that. Thanks for your understanding)



:)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: fishy_fiz on August 19, 2014, 06:08:59 AM
Thanks Cosmos, I'll give it a try later today.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Cosmos on August 19, 2014, 06:48:05 AM
Nobody with his negativity will stop me : beta 6 on the way !

Will include SMART_REFRESH into R_OpenWindowTagList for ECS/OCS/AGA screenmode :

"SmartWB is a little program that will *magically speed up* Workbench's
window   refreshing.    It   forces   to  Workbench  windows  to  open  in
smart-refresh  mode  instead  of  slow, ugly-look simple-refresh.  SmartWB
patches  intuition/OpenWindowTagList  which  Workbench  uses  to  open its
windows.    I   really   don't  know  why  gurus  in  C=  decided  to  use
simple-refresh - it saves some memory, but the speed gain worth that.  Try
to  open something, let's say, about 20 windows on your workbench and then
do,  for  example,  a  depth  rearranging.  And so?  Yes, slow, even on an
A4000!  Try it again with SmartWB..."


A good tip, I will test it shortly :

"Furthermore   if  you  use  Magic  Layers  (aminet/gfx/misc/ML11.lha),
realtime window movement program by Trond Werner Hansen, SmartWB will make
it even better!!"



:)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: thommys on August 19, 2014, 09:35:54 AM
All of your improvements are dirty hacks. If someone have a Problem with a Software that worked correctly for years it's not an Issue of this Software. It's your fault! btw hacking software without permission is illegal.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Cosmos on August 19, 2014, 11:14:12 AM
@StupidGuy

Shut up : you know nothing in coding and you are completly incapable to do what I' have done...

Remember that I don't have any original source, so the only way is reversing... All coders (except one) contacted refuse to improve or update their software...

They believe they are God : the super Amiga elite, have a very very big melon, have reason on anything, think I'm an idiot and don't want to share anything on their super-hyper piece of coding... Ridiculous !



;)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: psxphill on August 19, 2014, 11:44:17 AM
Quote from: Cosmos;771182
They believe they are God : the super Amiga elite, have a very very big melon, have reason on anything, think I'm an idiot and don't want to share anything on their super-hyper piece of coding... Ridiculous !

Your ranting is doing you a disservice.
 
 I personally wouldn't want to run a hacked version of intuition that ignored what type of window the developer wanted, but some of your patches seem ok.
 
 Your attitude puts me off though.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: spirantho on August 19, 2014, 12:23:47 PM
Quote from: thommys;771179
All of your improvements are dirty hacks. If someone have a Problem with a Software that worked correctly for years it's not an Issue of this Software. It's your fault! btw hacking software without permission is illegal.


It is quite common for software to work perfectly will with bugged libraries, and then when that library is fixed, for it to stop working.

As for it being illegal, I doubt anybody cares to be honest...

No-one's forcing anyone to use a third-party modified version of intuition.library, so I say go for it! If you don't like it, don't use it.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 19, 2014, 04:07:42 PM
Quote from: Cosmos;771163
When I ask coders for improving something : the answer is always no... Or no answer...

Cosmos, as always: It depends. We're talking about bugs vs. features, just to give you a hint.  
Quote from: Cosmos;771163
I asked you by email about updating the mmu.library (to make it romable if my memory is good...) and your answer was no some years ago...

The answer was "no" because it is a) not possible without unreasonable hackery, and b) it is not even the right goal. I know we disagree on this, but in my opinion, as much software needs to be *removed* from the ROM as possible, to keep kickstart updates as seemless as possible. It's called "software" for a good reason. This is in good tradition with many other constructions we find in the PC market and elsewhere. Anyhow - Don't you think that if the author and a contributer of software disagree about the target of a project that the author should have the final word?  Anyhow, you can convince me *why* it should be rom-able, but I really don't see it. If it is, you must also make the 680x0.libraries ROM-able, which is equally hard, and - as I say - equally undesirable.  
Quote from: Cosmos;771163
So now I do by myself without any permession, I don't care... (I won't reverse your mmu.library, stay cool, ok ?!)

Amiga Classic 68k must evolve by any ways : if no evolution, it's the complete death...
I don't disagree with the "evolution" part, but please understand that this requires a somewhat more coordinated approach than what you are doing right now. Yes, it costs time and might be anoying, but you need to *talk* to people. You can even talk to Hyperion or Olsen, you know, if you need to get some sources. It is, as always, a matter of how you approach them, and how you can motivate that you want to do what you want to do. It takes longer, but it is the better strategy. It is also a matter of politics and personal engagement, and yes, that's all complicated, but necessary.  
Quote from: Cosmos;771163
For BenchTrash : it's a missing "moveq #1,d0" just after a "jsr -$42(a6)"... I'll remove my patch only is you release a fixed version quickly...
Can you please give me a segment and an offset, to allow me to find the location? Thank you. I'm really not asking for much.  PS: I don't think anything I write here is "silly", or "unreasonable". You've found a bug (likely), which is good. I thank you for that. All I'm asking you is to make that report in proper form to "evolve AmigaOs further", as you put it correctly. The tactics of just patch the stuff is, I afraid, counter productive since then the bug will re-appear next version again. Quite simple, isn't it?
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: buzz on August 19, 2014, 04:17:58 PM
My personal experience in Amiga land is getting sourcecode for closed source Amiga native software is VERY difficult. I have tried in the past to get the source for the Amiga LHA. and for some code related to SFS to no avail (for bugfixes - SFS maintainer wouldn't help because he didn't want Morphos users to benefit from any improvements - madness), as well as other things. Luckily it is not always the case, but the attitude of Amiga developers is very odd (and out of date imho), especially in the case where a developer no longer wishes to make any improvements themselves - they rather have the software and its bugs die with them than allow others to continue.

Don't miss this aspect of Amiga computing at all, and work almost exclusively with open source these days.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 19, 2014, 05:14:57 PM
Quote from: buzz;771206
Don't miss this aspect of Amiga computing at all, and work almost exclusively with open source these days.

It's more complicated, actually. Have you ever tried to get a patch or improvement into open source software? Yes, of course, you can patch yourself, but that typically does not help because in the next release, the patch is gone and you have the work all over again.

In the end, it boils down to the very same answer: Talk to people, don't patch.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: buzz on August 19, 2014, 05:26:42 PM
Quote from: Thomas Richter;771211
It's more complicated, actually. Have you ever tried to get a patch or improvement into open source software? Yes, of course, you can patch yourself, but that typically does not help because in the next release, the patch is gone and you have the work all over again.

In the end, it boils down to the very same answer: Talk to people, don't patch.

It's not complicated. And the simple answer is yes. I have - with ease. I have had patches accepted in many projects from small web based applications to well known large collaborative projects.

People resort to binary patches in Amigaland because the source is not available, the author doesn't care, the software has been discontinued and so on. Had the source been available for your code, you could have received a nice source patch in the mail which would have been considerably easier wouldn't it ? As I have already said, getting the source can be very difficult - it's a lovely idea to talk sure, but not everyone is listening (as I have already mentioned when trying to fix issues with existing software on the Amiga before)

It's your choice to licence your software however you want though of course.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Cosmos on August 19, 2014, 05:48:12 PM
Quote from: psxphill;771183
Your ranting is doing you a disservice.
 
 I personally wouldn't want to run a hacked version of intuition that ignored what type of window the developer wanted, but some of your patches seem ok.
 
 Your attitude puts me off though.

Do what you want, I just say the thruth and tell my story... Nothing more, nothing less...

Coders are a bit special, it's like that : me too I'm special... It's just a fact : it's impossible to talk and trade with coders from my experience... They (hum... we) live on an "another planet" ! lol !!


Anyway, I understand your questions and interrogations about myself and all my reworked libraries : I have some secret goals with them, I cannot explain because Amiga have a lot of and powerfull ennemies...

Follow my works, and little by little all become clear for you...



:)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Cosmos on August 19, 2014, 06:12:25 PM
Beta 6 near finished... Release for tomorrow...

Again a lot of supertiny subroutines inlined and many argstack turned to registers now...

You will get a little speedup : jbsr/rts and the move on the stack (specially on 000/010/020) are slow on every 68k...

Still a gigantic work to do...


This library was compiled by a very bad compilator : Dice ? Aztec ?

If you know, please tell me...



:)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 19, 2014, 07:05:47 PM
Quote from: buzz;771212
People resort to binary patches in Amigaland because the source is not available, the author doesn't care, the software has been discontinued and so on.  
Is that any different for open source? Here APIs are very fragile, and change over time quite rapidly. Thus, any unmaintained source is usually quite worthless.... Anyhow, it's a mixed bag. Every model has advantages and disadvantages. But in one way or another: For intuition, there are people around that would have sources. For BenchTrash, I can ensure you that the author *is* around and happy to fix bugs when reports are made. And I find it openly completely unacceptable to patch around, even *if* I had made a bug. Nobody is perfect.
Quote from: buzz;771212
Had the source been available for your code, you could have received a nice source patch in the mail which would have been considerably easier wouldn't it ?  
The deal has always been like this: You tell me what you want to do, and I tell you what I think about it. If we agree, you get the sources. This model worked well in the past, and yes, I have released sources for developers. I don't think it works any different for AmigaOs. At least it worked like this for me. The difference is simply this: Ask!
Quote from: buzz;771212
As I have already said, getting the source can be very difficult - it's a lovely idea to talk sure, but not everyone is listening (as I have already mentioned when trying to fix issues with existing software on the Amiga before)
If the author is not around anymore, or the maintainer at least, then yes, certainly. What the original intention of the author was, we cannot know. Sell the software maybe? Completely legidimate, if you ask me. What is anoying, of course, if the authors have lost interest, yet do not hand out anything.

But that's not the case here. In none of the cases here. Sources of BenchTrash are around, and sources for intuition are around.
Quote from: buzz;771212
It's your choice to licence your software however you want though of course.

Certainly. As I said already, it's a mixed bag.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 19, 2014, 07:09:47 PM
Quote from: Cosmos;771222
This library was compiled by a very bad compilator : Dice ? Aztec ?

If you know, please tell me...

Greenhill, actually, AFAIK. Pretty ancient beast, and unfortunately, the source of V40, as is, is pretty hard to port to anything other. It uses a couple of features of this compiler that should have better been avoided. No, it's not a particularly good compiler, though I doubt the difference is actually measurable, intuition is pretty much high-level.

Not clear who cleaned up the mess for Os 4.x, but its some major undertaking. It's not that the style is really bad, but the tool dependency certainly is.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: HammerD on August 19, 2014, 09:13:43 PM
Quote from: Thomas Richter;771225
Greenhill, actually, AFAIK. Pretty ancient beast, and unfortunately, the source of V40, as is, is pretty hard to port to anything other. It uses a couple of features of this compiler that should have better been avoided. No, it's not a particularly good compiler, though I doubt the difference is actually measurable, intuition is pretty much high-level.

Not clear who cleaned up the mess for Os 4.x, but its some major undertaking. It's not that the style is really bad, but the tool dependency certainly is.


It's too bad we couldn't organize some official BB3 or BB4 - I know there is unofficial ones, but as you say, it is fairly complex, talking to people, asking, organizing.  With no parent company to do this it makes it rather difficult.

I've had issues with BB3 and BB4 that I can't really explain, for me the most stable release is OS 3.9 BB2.   I can't really tell what other updates and patches can cause issues.  And really even with BB3 and 4 there is not a significant enough difference for me to really notice so even though I want to update I usually regret it if I do, so I always fall back to OS 3.9 BB2.

I do appreciate your recent updates though - and everyone's efforts.   It is very nice to see, as I find myself strangely using OS 3.x more than 4.x or MorphOS these days...
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Oldsmobile_Mike on August 21, 2014, 12:30:18 AM
Thanks!  I'm a bit behind on these but this one is working fine in preliminary testing on my highly patched A2000 system.  Note that I had to stick it behind LoadResident, as for whatever reason it wasn't firing behind LoadModule.  No big deal, it's working now.  :)
 
 Question - whatever happened with that updated graphics.library you were working on a year or two back?  I seem to recall it had a lot of promise then just disappeared?  Hope I haven't already asked you this question, memory's a big rusty these days!  ;)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Cosmos on August 21, 2014, 05:51:21 AM
Quote from: Oldsmobile_Mike;771355
Question - whatever happened with that updated graphics.library you were working on a year or two back?  I seem to recall it had a lot of promise then just disappeared?  Hope I haven't already asked you this question, memory's a big rusty these days!  ;)

Still working on it from time to time... I have a very very low life condition, so it's a bit hard for me to get my mind concentrate for coding well...


No new version of the intuition yesterday : I was working on a new hack CyberStorm MK2 running now at 105 Mhz...

Pictures on my Warp3D blog this day...



:)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 23, 2014, 08:54:11 PM
Quote from: Cosmos;771107
One bug report about BenchTrash prefs : it's an issue from this proggy, not from my new intuition.library version...

Sorry, but that's an issue with your intuition hack. I checked now the source code.  

The corresponding code segment of BenchTrash computes a word-based offset and passes this offset in the form of two 16-bit integers into intuition, namely into DrawImage(). Please check the autodocs, the function takes two *WORDS* and not two *LONGS*, which is a different thing. Only the lowest 16 bits of the arguments are assumed to be valid.  

 Before you're saying that the C "integer promition rule to int" should apply, I suggest that you should familiarize yourself with the calling conventions and the freedoms a C compiler has. An "int" can be both 16 bit (Aztec) or 32 bit (SAS) wide (or, as a matter of fact, even wider if the compiler deems this necessary, though no Amiga compiler picks this choice), thus any type of promition that may or may not take place is the matter of the configuration of the compiler and not in the freedom of the intuition to assume that promotion to 32-bit LONG (and not int) has been performed.  

 I followed a bit the intuition internals, so this problem is not entirely your fault.  

Interestingly, the internal intuition function declares the prototype for DrawImage taking int arguments (!) not WORD (!) arguments, so the problem stems apparently from the fact that the original authors of intuition did not match the external prototype strictly to the internal function, and it seems that the final fix for intuition was only made in an inofficial and non-published version of intuition that was fixed for SAS/C instead of the Greenhill compiler. This version never made it to the 68K's, though. In both versions, however, DrawImage() runs into DrawImageState() which again packs the offsets as two 16-bit entities into a message (intuition aka boopsi aka smalltalk-message, not exec message) and sends this to the corresponding image object (aka, calls its dispatcher). Thus, it remains 16 bit at this point as initially declared, so whether promotion takes place or not is utterly irrelevant *for the original intuition*, despite the fact that the internal prototype does not fit.  If that creates any trouble with your modifications, I suggest that you review your code.  

In one way or another, please remove now the hack of a program you do not own from your pages. At least for my program. Even though I strongly disagree with hacking up intuition like this, especially as it creates problems you have experienced, I'm at least not its owner, so I cannot really complain as the intuition author. I can claim as the BenchTrash author, and that's what I'm doing here. Fix the source at its origin and match your code to the official prototype.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Minuous on August 24, 2014, 06:11:53 AM
Quote from: HammerD;771235
I've had issues with BB3 and BB4

What version was this, some old beta version I suspect?

Quote
that I can't really explain

You could try. I do take bug reports seriously, however "can't really explain" is not enough info.

(BTW just to clarify for readers, Cosmos intuition.library is not part of BB3/4, at least for now.)

Quote
sources for intuition are around.

Do you have a download link? Or I can "just ask" H&P or someone and I will be sent official AmigaOS source code?! I doubt this... :-(
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Cosmos on August 24, 2014, 06:27:08 AM
Quote from: Thomas Richter;771589
Sorry, but that's an issue with your intuition hack. I checked now the source code.  

The corresponding code segment of BenchTrash computes a word-based offset and passes this offset in the form of two 16-bit integers into intuition, namely into DrawImage(). Please check the autodocs, the function takes two *WORDS* and not two *LONGS*, which is a different thing. Only the lowest 16 bits of the arguments are assumed to be valid.  

 Before you're saying that the C "integer promition rule to int" should apply, I suggest that you should familiarize yourself with the calling conventions and the freedoms a C compiler has. An "int" can be both 16 bit (Aztec) or 32 bit (SAS) wide (or, as a matter of fact, even wider if the compiler deems this necessary, though no Amiga compiler picks this choice), thus any type of promition that may or may not take place is the matter of the configuration of the compiler and not in the freedom of the intuition to assume that promotion to 32-bit LONG (and not int) has been performed.  

 I followed a bit the intuition internals, so this problem is not entirely your fault.  

Interestingly, the internal intuition function declares the prototype for DrawImage taking int arguments (!) not WORD (!) arguments, so the problem stems apparently from the fact that the original authors of intuition did not match the external prototype strictly to the internal function, and it seems that the final fix for intuition was only made in an inofficial and non-published version of intuition that was fixed for SAS/C instead of the Greenhill compiler. This version never made it to the 68K's, though. In both versions, however, DrawImage() runs into DrawImageState() which again packs the offsets as two 16-bit entities into a message (intuition aka boopsi aka smalltalk-message, not exec message) and sends this to the corresponding image object (aka, calls its dispatcher). Thus, it remains 16 bit at this point as initially declared, so whether promotion takes place or not is utterly irrelevant *for the original intuition*, despite the fact that the internal prototype does not fit.  If that creates any trouble with your modifications, I suggest that you review your code.  

In one way or another, please remove now the hack of a program you do not own from your pages. At least for my program. Even though I strongly disagree with hacking up intuition like this, especially as it creates problems you have experienced, I'm at least not its owner, so I cannot really complain as the intuition author. I can claim as the BenchTrash author, and that's what I'm doing here. Fix the source at its origin and match your code to the official prototype.

What ??

The bug is from the bsr.w JL_3_1A42 & beq.w JL_3_1A24 !

Since no tst after the bsr, the beq take the CCR from the jsr -$72(a6) savestackmove who is wrong... I have removed these useless savestackmove, so your BenchTrash bug now...

You have to add a CCR Z by yourself (moveq #1,d0 is perfect) at the end of JL_3_1A42 after the jsr -$72(a6) because R_DrawImage return none : it's a bug from you...

No shame to code bug, I code bug too and all coders bug sometimes...


@Thomas Richter

I'm in a rage you cannot imagine : I think you are a satanist who want to destroy my works, my dreams and my reputation...

For this type of issue, private message is available but you want to f**k me in public here...

I really don't like that... Be carefull with me, I can be very very bad...




:(
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Cosmos on August 24, 2014, 09:15:26 AM
intuition.library v40.86 beta 6

  - R_OpenWindowTagList now SMART_REFRESH mode
  - R_GetDefaultPubScreen optimized
  - a lot of tiny subroutines inlined
  - 9256 bytes saved


==> http://leblogdecosmos.blogspot.fr/p/coding.html



:)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 24, 2014, 01:31:23 PM
Quote from: Cosmos;771638

Since no tst after the bsr, the beq take the CCR from the jsr -$72(a6) savestackmove who is wrong... I have removed these useless savestackmove, so your BenchTrash bug now...

Ok, so now I understand. The problem is not that the arguments are not correct, but the return condition is not correct. Why didn't you say so in first place? Finally, thank you. It is a matter of making a proper bug report.  

The "useless stack moves" reserve stack space for a RastPort, and no, it is not "useless". If you don't do that, you trash the stack under the stack pointer.

Anyhow, you created quite a mess. Maybe the most important problem is the wrong copyright. You cannot know this, but BenchTrash is of today *not* (c) Amiga. Copyright went back to me, so IOWs, you are assigning my work to somebody else by this patch... This is exactly the reason why I do not want third parties to redistribute work without permission. You cannot know everything about the tiny details, which is exactly the reason why you shouldn't mess with somebody else's work.  Same goes to intuition: This is a copyrighted work. What you do here is, quite simply, illegal.  
Quote from: Cosmos;771638
I'm in a rage you cannot imagine : I think you are a satanist who want to destroy my works, my dreams and my reputation...
Reputation? I beg your pardon, Cosmos, but you are building a "reputation" by illegally patching somebody else's work and redistributing a reverse-engineered version of intuition, a work you do not have any rights on? What exactly do you expect to happen? Or to put it in a different way, which type of "reputation" do you want to establish? Why don't you just talk to people *before* you start to patch?
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Cosmos on August 24, 2014, 01:42:45 PM
Silly guy as always : the law is a lie to rob the people "legally" : so, I do what I want...

You (and everyone else) can put your rights in your a** very deeply...



:(
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 24, 2014, 03:49:52 PM
Quote from: Cosmos;771650
Silly guy as always : the law is a lie to rob the people "legally" : so, I do what I want...

You (and everyone else) can put your rights in your a** very deeply...

So, I suppose, you then wanted to establish your reputation as a thief and ignorant to begin with? Ok, in that case don't worry - it worked just perfectly fine.

One way or another, the situation is as it is, and no, it doesn't get more legal by Amiga not publishing it or you not willing to talk to them, or anyone. Yes, it is a sad story, but the situation does not exactly improve by activities like the ones you did.

Actually, the whole reason by AmigaOs is in such a sad state is that a lot of people actually just took code instead of asking, which caused a lot of disruption and needless waste of energy. There would have been the chance to help, but instead you keep destroying it.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: thommys on August 24, 2014, 04:02:44 PM
I think i know why Cosmos is banned from eab.
Maybe amiga.org ban him too.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kamelito on August 24, 2014, 05:32:45 PM
To me Cosmos wants to help the 3.x community left behind and he is having fun doing so.
He harms no one so why don't you let him alone? I'm sure that you have better things to do.
"Remember when computing was fun?..."

Kamelito
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kolla on August 24, 2014, 06:02:15 PM
Quote from: Thomas Richter;771649
illegally patching somebody else's work and redistributing a reverse-engineered version of intuition


Excuse me? I do not see anything illegal about what Cosmos is doing, which from what I have seen, is to reverse engineer, do his changes and distribute patches, so that others can apply his patches to their originals. That is not the same as distributing reverse-engineered version of intuition.

Other than that, I am fully with Buzz, in the open source world things are _much_ easier, suggesting that it isn't just displays a whole deal of ignorance and backwards attitudes.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Oldsmobile_Mike on August 24, 2014, 06:29:58 PM
Quote from: kolla;771665
Excuse me? I do not see anything illegal about what Cosmos is doing, which from what I have seen, is to reverse engineer, do his changes and distribute patches, so that others can apply his patches to their originals. That is not the same as distributing reverse-engineered version of intuition.

I think he did a great job of patching & updating TLSFMem, and I will swear by that program. Good stuff! :D
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 24, 2014, 07:24:28 PM
Quote from: kolla;771665
Excuse me? I do not see anything illegal about what Cosmos is doing.

Oh, so he does hold a license on intuition? I do not think so, but if you know better, let me know.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on August 24, 2014, 07:46:56 PM
Quote from: Thomas Richter;771671
Oh, so he does hold a license on intuition? I do not think so, but if you know better, let me know.


so far i see he only distributes patches to the intuition and the other libraries, which i think is legal, since he doesnt provide download to the binaries themselves, isnt it? sources are not open but that doesnt mean you must not rework reverse  engineered asm  guess.

now, i think it would of course be more productive if he provided bug report and you had fixed the bug yourself (if confirmed) in the next update.

on the other hand im not very found of cosmos tone of voice i must admit, especially when being polite might result in actual cooperation.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 24, 2014, 07:53:20 PM
Quote from: wawrzon;771676
so far i see he only distributes patches to the intuition and the other libraries, which i think is legal, since he doesnt provide download to the binaries themselves, isnt it?

I would believe you are right if these are only patches. I don't even ask where owners of any other model than the one the patch depends on take the ROM file from, but that's probably not my problem anyhow.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on August 24, 2014, 08:18:32 PM
Quote from: Thomas Richter;771677
I would believe you are right if these are only patches. I don't even ask where owners of any other model than the one the patch depends on take the ROM file from, but that's probably not my problem anyhow.


i have downloaded the intuition and exec library archives here:
http://leblogdecosmos.blogspot.fr/p/coding.html

and the lhas contain *.pch files. i did not try to apply them but it looks positively like patches.

what concerns where the rom files are coming from there are rom and remus utilities to assemble and disassemble regular rom images from your hardware kickstart. thats how it is done too, i have done it myself on my my main a4000 system. the number of module versions contained in hardware kickstarts is rather limited even if sometimes hardware specific, so you only need few versions of patches. it was handled like this in all official and inofficial but though not illegal patches and "boing balls" for amiga system, you can collect from internet. could not find anything to nitpick on myself.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 24, 2014, 08:41:53 PM
Quote from: wawrzon;771679
it was handled like this in all official and inofficial but though not illegal patches and "boing balls" for amiga system, you can collect from internet. could not find anything to nitpick on myself.

Not for the BoingBags I contributed to, I ensure you. The stuff there was compiled/assembled from official sources. Which is also a considerably more robust approach.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on August 24, 2014, 09:13:08 PM
Quote from: Thomas Richter;771682
Not for the BoingBags I contributed to, I ensure you. The stuff there was compiled/assembled from official sources. Which is also a considerably more robust approach.


i trust you, but since the sources of amiga kickstarts and system libraries are not open we are left with no alternatives as to refrain to patches to keep it legal. its been some time since i fiddled with my a4k setup and, i must say, come up with a very stable improved custom kickstart including power windows functionality, so i dont remember what patches exactly i have applied, still afair the main ones were already included in doobrey's romsplit/remus archives.

i can assure you i have properly read out the roms of my a4k to create that kickstart if you insist;). of course i would prefer all that annoying hackery was unnecessary, the code was open and there was no necessity to reinvent the wheel from the scratch, just to keep it going like in case of aros, but alas it is not the case. i dont think the fans, customers and (be it bedroom) coders are to blame for this situation. on the contrary, from my observations the community behaves sometimes even over-loyal in comparison to rather limited support it can count on from various sources and for various reasons.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kolla on August 24, 2014, 10:25:12 PM
Quote from: Thomas Richter;771671
Oh, so he does hold a license on intuition? I do not think so, but if you know better, let me know.


Apparently I do know better, didn't you read my entire post? Distributing binary patches is perfectly legal and has been done since the dawn of AmigaOS.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kickstart on August 24, 2014, 10:43:41 PM
Anothertime some people talking about illegal things on the amiga world, this people is really stupid... the actal amiga "community" is like a stupid chat of people acting like imaginary CEOS of imaginary companies, inventing projects from nothing and selling just vapor...

Cosmos try to fix some libraries and is criticized... people is stupid.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: psxphill on August 25, 2014, 12:48:37 AM
Quote from: kickstart;771692
Cosmos try to fix some libraries and is criticized... people is stupid.

If you can't handle criticism with dignity then you should avoid the internet. He criticises people and expects them to take it, but criticise him and he launches an attack.

I am not a lawyer but some countries reverse engineering laws might make his patches illegal. Not that I care.

http://en.wiktionary.org/wiki/you_can_catch_more_flies_with_honey_than_with_vinegar
 
 
Quote from: Cosmos;771216
Coders are a bit special, it's like that : me too I'm special... It's just a fact : it's impossible to talk and trade with coders from my experience... They (hum... we) live on an "another planet" ! lol !!
 
 You can overcome your narcissism if you want. You only live on another planet because you chose to.
 
Quote from: Cosmos;771216
I have some secret goals with them, I cannot explain because Amiga have a lot of and powerfull ennemies...
 
 Paranoia is treatable too.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kolla on August 25, 2014, 01:09:34 AM
Quote from: psxphill;771698
I am not a lawyer but some countries reverse engineering laws might make his patches illegal.


Which countries do you have in mind?
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kickstart on August 25, 2014, 01:56:53 AM
Quote from: psxphill;771698
I am not a lawyer but some countries reverse engineering laws might make his patches illegal. Not that I care.


Really you are worried about the laws of patch intuition.library? you are ironic about that.

PS: The wikipedia link is crap.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: TheMagicM on August 25, 2014, 02:37:48 AM
Good job Cosmos.  I'm with ya on this one.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Madshib on August 25, 2014, 03:45:20 AM
Keep up the good work Cosmos. We need more people working on 3.x and it seems you have done a great job! We should all be thanking you....

Maybe someday 3.x will become open source so it can be developed by the community like it should be at this point...
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: TheMagicM on August 25, 2014, 03:48:17 AM
Quote from: Madshib;771704
Keep up the good work Cosmos. We need more people working on 3.x and it seems you have done a great job! We should all be thanking you....

Maybe someday 3.x will become open source so it can be developed by the community like it should be at this point...


What if it was released as open source...  I wonder how much better WB 3.x can actually get.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Madshib on August 25, 2014, 03:54:20 AM
I often wonder that myself, but I've seen the hardware taken to some pretty amazing places for what it is and the age of it....
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: psxphill on August 25, 2014, 08:26:20 AM
Quote from: kickstart;771702
Really you are worried about the laws of patch intuition.library? you are ironic about that

I plainly said that I didn't care.

Quote from: kickstart;771702
PS: The wikipedia link is crap.

Try reading it again.
 
 
Quote from: kolla;771699
Which countries do you have in mind?

 There are various situations where it's illegal in the US and the EU.
 
http://en.wikipedia.org/wiki/Reverse_engineering#Legality
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 25, 2014, 08:50:02 AM
Quote from: TheMagicM;771705
What if it was released as open source...  I wonder how much better WB 3.x can actually get.

From the typical amount of patches you find in Amiga-Land and the amount of ignorance for Os interfaces, I suppose it can only get worse. AmigaOs does not require to get open-sourced. It requires a maintainer. That is missing...
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 25, 2014, 08:56:46 AM
Quote from: wawrzon;771686
i trust you, but since the sources of amiga kickstarts and system libraries are not open we are left with no alternatives as to refrain to patches to keep it legal.  
I don't really think so. I believe if you'd know whom to ask and what to ask for, it should be very well possible to obtain them if you'd want them. Of course, this requires approaching people politely and having a reputation as software engineer (not as hacker), so I would assume that Cosmos is out.  

But anyhow, it's not my problem.  
Quote from: wawrzon;771686
I dont think the fans, customers and (be it bedroom) coders are to blame for this situation. on the contrary, from my observations the community behaves sometimes even over-loyal in comparison to rather limited support it can count on from various sources and for various reasons.

I, however, believe they are. There are always methods to interact and approach the right people to get what you want. Not as open source, for certain. The guerilla type approach of course does not work. It is pretty much a matter of thrust.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on August 25, 2014, 09:13:19 AM
who cares if it even got worse, which i dont see happening. alone the availability of patches, that if carefully chosen leads to vastly improved os from a user perspective proves it right.
if sources along with proper documentation went public it could only improve on blindly and uncoordinated patching bits and pieces. open sourcing would probably at least provide a chance that it gets actively and competently maintained, as aros is. remember, before you became part of the amiga os team at its time you were one of these third party contributors, and neither before nor after proprietary nature of the system prevented it from design flaws and messy programming.

if you see open source as equivalent of coding anarchy btw, you can still build upon it and fork it to an "official distribution", be it closed source, like morphos does with parts of aros code.

however all this is void talk, since there is no chance in hell any sources were going open one way or the other.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on August 25, 2014, 09:31:49 AM
Quote from: Thomas Richter;771715
I don't really think so. I believe if you'd know whom to ask and what to ask for, it should be very well possible to obtain them if you'd want them. Of course, this requires approaching people politely and having a reputation as software engineer (not as hacker), so I would assume that Cosmos is out.  

But anyhow, it's not my problem.  

I, however, believe they are. There are always methods to interact and approach the right people to get what you want. Not as open source, for certain. The guerilla type approach of course does not work. It is pretty much a matter of thrust.

maybe, maybe not. and frankly i dont think that there is anything left as alternative to what you call a guerilla type approach. since that is probably what you, maybe rightfully, consider aros development practices to be. except perhaps in morphos camp, i cant tell how organized that is. but observing the os4 development, it has definitely become guerilla playground by the looks of it. i think, that outsourcing practically the whole development to more or less skilled volunteers, because only a limited number and quality is actually available did not improve on the situation. from my initial even if brief experience as user and what i recall over the years reading forums i  cant defeat an impression my heavily guerilla style patched amiga was more dependable that the official os4 alternatives..
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 25, 2014, 10:08:29 AM
Quote from: wawrzon;771716
remember, before you became part of the amiga os team at its time you were one of these third party contributors, and neither before nor after proprietary nature of the system prevented it from design flaws and messy programming.
Except that I never tried to heavily patch the system. I did not took system libraries and "extended" them in the way Cosmos did, instead I took Os interfaces for granted and programmed against them. That's quite something different.
Quote from: wawrzon;771716
if you see open source as equivalent of coding anarchy btw, you can still build upon it and fork it to an "official distribution", be it closed source, like morphos does with parts of aros code.
You got me wrong. I don't consider "open source" to be anarchy, not at all. You would be astonished how well-maintained and organized the Linux kernel development works. What I was saying is, and I repeat it here, that intuition (and the Os in general) requires a maintainer. Open source plus good maintenance works fine, but good maintenance does not depend on open source. However, what I would consider likely, given the general approach of the Amiga community, that as soon as it becomes open source, maintenance will become impossible - simply because nobody in this camp takes software engineering serious, and would just start to patch around in the sources without much plan and coordination. Thus, I'm afraid that a good maintenance model would not work for an Open Sourced Amiga. It requires discipline from the contributors, but discipline is exactly what is missing.  
Quote from: wawrzon;771716
however all this is void talk, since there is no chance in hell any sources were going open one way or the other.

Maybe, who knows. Its not my decision by any means.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Niding on August 25, 2014, 12:19:22 PM
Im just going to chip in as a non-coder;

I THINK many users (and programmers) consider this platform 100% as a hobby, and approach it as such. A tweak/patch might work in favor for some, speeding the OS up or whatnot.

Or it might make the OS a labyrinth of version numbers of libs/systems file that might make troubleshooting harder if something doesnt work.
This might make it harder for people on this forum to give advice regarding issues since people are running with xxx versions.

So for my own use, I stick with the official versions of Workbench, but I do understand that the more tech savvy can find "unofficial" libs/systemsfile useful for their use.

Cosmos seems to have the best intent behind his efforts. Maybe it could be compared to any hobbist with for example cars. They are often modified by hobbists far beyond the basic factory spesifications. And if the owner/user finds it enhances his expirience I can see why he gets a bit offended when his efforts is not being appriciated.
Espesially since the OS progress appears to be rather slow (understandable considering the manpower), its tempting to use the "if you want it done, you gotta do it yourself!" approach.

Thomas Richters big picture approach makes more sense to me tho from a stability point of view. Keep versions "official" for predictable performance.

Anyhow, thats just my non-tech savvy point of view. I might be talking our of my arse ;)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kolla on August 25, 2014, 01:33:05 PM
Quote from: psxphill;771713
There are various situations where it's illegal in the US and the EU.

But the kind of reverse engineering that is going on here in Amigaland is explicitly legal.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kolla on August 25, 2014, 01:37:09 PM
Quote from: Thomas Richter;771714
From the typical amount of patches you find in Amiga-Land and the amount of ignorance for Os interfaces, I suppose it can only get worse. AmigaOs does not require to get open-sourced. It requires a maintainer. That is missing...


The only way to solve the maintainer problem is to make it open source - sheesh, you are so stuck back in the 90ies rethoric that I am flat out amazed! What rock have you been living under?!
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 25, 2014, 01:48:26 PM
Quote from: kolla;771723
The only way to solve the maintainer problem is to make it open source  
Or to have someone that pays for the work.  
Quote from: kolla;771723
- sheesh, you are so stuck back in the 90ies rethoric that I am flat out amazed! What rock have you been living under?!

That kind of rock where you get actual money for your work as a software engineer, and that kind of rock where clients get a contract for software maintenance, and a guarantee for stability and performance.

Look, I don't know how you make a living, but I myself have to work for it.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on August 25, 2014, 03:13:25 PM
Quote from: Thomas Richter;771724
Or to have someone that pays for the work.  

That kind of rock where you get actual money for your work as a software engineer, and that kind of rock where clients get a contract for software maintenance, and a guarantee for stability and performance.

Look, I don't know how you make a living, but I myself have to work for it.

Thomas. We know you are a serious developer, but you cannot be serious here. For twenty years none could be found to competently maintain and finance amiga, be it understood as the os or hardware or whatever. The situation is not getting any better i am sorry. We are not talking of better choices. We are out of alternatives. Closed or open source will not make better maintenance possible anymore. It will just allow to preserve the code and allow still for an ocassional bug or fix. There is nothing to quarrel about. Serious development has ceased here.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kolla on August 25, 2014, 03:36:21 PM
Quote from: Thomas Richter;771724
Or to have someone that pays for the work.
 

Yeah right. No, I do not pay for Amiga software other than to have sources released  - enough is enough! I have supported my share of software development on Amiga up through times, as has most of us, only to see support vanish because nonsense drama and intrigues. Last I did was to contribute quite a bit to help Directory Opus Magellan become open source. It's a great pleasure to now have it working well, natively on AROS and AmigaOS.

Quote
That kind of rock where you get actual money for your work as a software engineer, and that kind of rock where clients get a contract for software maintenance, and a guarantee for stability and performance.


But may lose all support and guarantees once your company goes belly up, or is bought up by people who do not give a damn. Yes, I do know that part of the IT industry quite well.

Quote
Look, I don't know how you make a living, but I myself have to work for it.


I also work for a living, in the IT business, your way of talking was the mantra 10+ years ago, luckily times have changed.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kolla on August 25, 2014, 03:37:38 PM
Quote from: wawrzon;771727
Serious development has ceased here.


Well put!
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 25, 2014, 04:02:40 PM
Quote from: kolla;771728
Yeah right. No, I do not pay for Amiga software other than to have sources released  - enough is enough!
Whether it is open or closed source I do not even mind. What I would mind is that it is maintained.  

No matter what you think, "Open Source" does not mean unpaid work. I currently participating a little bit in the linux intel driver development (only very minor), yet you find that people there *are* getting paid by the big players that have some interest in the platform.

You seem to believe that everything that needs to happen is to make the source publically available, and the problem will be solved. That's not the case. It will replace one problem by another problem unless somebody "wears the hat" as we say here, i.e. has the final say what goes into the repository and what won't. No, I don't think that the average Amiga hacker is disciplined enough to accept a "no" in case it is a "no".

Then, in the end, it does not matter whether the sources are released or not as long as somebody cares. Currently, they are closed, and I frankly say that nobody cares, at least not for the 68K branch. Sad enough. There are enough things that could be done if there would be a way to do that without actually causing irritiation by anyone.  
Quote from: kolla;771728
But may lose all support and guarantees once your company goes belly up, or is bought up by people who do not give a damn. Yes, I do know that part of the IT industry quite well.
And how does that change with Open Source? It is just the same, as soon as the development team just considers the old software obsolete, you may have the source, cool, but you cannot really do anything about it because it's just a big pile of code you do not know how to work with. Projects got abandoned, and nobody picked them up. Open Source code is very volatile - whether your source still compiles with the latest version of libIdoNotcare.so you never know.

I worked in both ways, each has its advantages and its drawbacks, but just throwing the code into an OpenSource repository is not going to help much - unless somebody really cares about the result.  
Quote
I also work for a living, in the IT business, your way of talking was the mantra 10+ years ago, luckily times have changed.

Not really. In the end, somebody has to pay the party. Even for OpenSource if you care about quality or consistency. Again, I'm not against it. I'm against leaving it unmaintained.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on August 25, 2014, 04:22:33 PM
Quote from: Thomas Richter;771735
Whether it is open or closed source I do not even mind. What I would mind is that it is maintained.  

No matter what you think, "Open Source" does not mean unpaid work. I currently participating a little bit in the linux intel driver development (only very minor), yet you find that people there *are* getting paid by the big players that have some interest in the platform.

You seem to believe that everything that needs to happen is to make the source publically available, and the problem will be solved. That's not the case. It will replace one problem by another problem unless somebody "wears the hat" as we say here, i.e. has the final say what goes into the repository and what won't. No, I don't think that the average Amiga hacker is disciplined enough to accept a "no" in case it is a "no".

Then, in the end, it does not matter whether the sources are released or not as long as somebody cares. Currently, they are closed, and I frankly say that nobody cares, at least not for the 68K branch. Sad enough. There are enough things that could be done if there would be a way to do that without actually causing irritiation by anyone.    And how does that change with Open Source? It is just the same, as soon as the development team just considers the old software obsolete, you may have the source, cool, but you cannot really do anything about it because it's just a big pile of code you do not know how to work with. Projects got abandoned, and nobody picked them up. Open Source code is very volatile - whether your source still compiles with the latest version of libIdoNotcare.so you never know.

I worked in both ways, each has its advantages and its drawbacks, but just throwing the code into an OpenSource repository is not going to help much - unless somebody really cares about the result.  

Not really. In the end, somebody has to pay the party. Even for OpenSource if you care about quality or consistency. Again, I'm not against it. I'm against leaving it unmaintained.


Open Sourcing is not solving everything, you still not only need someone for coordination you need developers contributing at all. There are lots of amiga sources on sourceforge, aminet or elsewhere that nobody develops on (ignition just one example that comes to my mind). But at least it is theoretical possible in opposite to many closed software where developers have vanished and any bugfix or adding features has become impossible. That is what Wawa meant. In my view Aros 68k is the only realistic path for 68k platform because there are people who care, f.e. Aros 68k automatically benefits of changes on the big brothers (X86...) on the other hand these benfit too because Aros can be tested against real working software. So a win-win. AmigaOS 68k will never be developed again because sticking between Hyperion and AmigaInc. and both are not interested in it.

Who will pay developers for coordinating development on AmigaOS 68k?
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: buzz on August 25, 2014, 06:56:12 PM
Quote from: Thomas Richter;771735


Then, in the end, it does not matter whether the sources are released or not as long as somebody cares. Currently, they are closed, and I frankly say that nobody cares, at least not for the 68K branch. Sad enough. There are enough things that could be done if there would be a way to do that without actually causing irritiation by anyone.    And how does that change with Open Source? It is just the same, as soon as the development team just considers the old software obsolete, you may have the source, cool, but you cannot really do anything about it because it's just a big pile of code you do not know how to work with. Projects got abandoned, and nobody picked them up. Open Source code is very volatile - whether your source still compiles with the latest version of libIdoNotcare.so you never know.


opening the source does not guarantee anything, but there are still skilled programmers out there that could pick up the source and contribute improvements, and there are examples of open sourcing stuff being a success on the Amiga. Had the OS3.x sources been released years ago, I am sure I would have got involved (and I know others that would have also)

I work for a living with open source (as well as in my spare time), and it works very well for me. I have also picked up projects that have been abandoned and have continued to develop them (along with setting up a bugtracker and development site etc). It does happen, and is made possible because the source was available.

Your comment regarding some library dependency is not specific to open source. If an old project doesn't compile, you have the opportunity to fix it, which is certainly a lot more useful than trying to get a 15 year old binary running.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: psxphill on August 25, 2014, 07:29:52 PM
Quote from: kolla;771722
But the kind of reverse engineering that is going on here in Amigaland is explicitly legal.

Can you point me to where it is explicitly stated that it's legal?
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 25, 2014, 07:55:58 PM
Quote from: kolla;771722
But the kind of reverse engineering that is going on here in Amigaland is explicitly legal.

IANAL, but the only case where reverse engineering is legal I know about is where you need compatibility of your product with an interface of another product, though that interface is not documented. In such a case, you may reverse engineer the other product for obtaining information how it works, then program against the interface you obtained. Even then, you're safer when following an approach where the engineer that does the reverse engineering is not the same that then finally implements the interface.

Taking the other product, disassembling it, then publishing the result as new work is certainly not legal. Providing patches for a second product... Well, I don't know, again IANAL, but it's at least something that's a bit critical. Problems start when the derived product from the patch violates third party rights. As it happened here for my BenchTrash project. With the patch applied, it says (c) 2014 Amiga, and *that* is certainly not correct. Of course, one cannot know as an outsider the details of the license agreements made back then, and thus cannot know that - in fact - it is again my copyright, and nobody elses, but at least it means that one shouldn't really touch it in first place being not aware of such touchy details.

In the end, I'm not p*ssed because it was assigned to Amiga. Details, maybe. Amiga would have known, and I know, too, so why bother so much... I'm upset because instead of patching it, a bug report would have helped, and that's the first thing that should have happened. Failing that and all other means, one can still try alternative means of resolving a problem.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kickstart on August 25, 2014, 09:57:16 PM
@psxphill

Years of x-copy on amiga land and now you are here crying for non sense, enjoy the library and shut up.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on August 25, 2014, 10:57:46 PM
Quote from: Thomas Richter;771735

Then, in the end, it does not matter whether the sources are released or not as long as somebody cares. Currently, they are closed, and I frankly say that nobody cares, at least not for the 68K branch. Sad enough. There are enough things that could be done if there would be a way to do that without actually causing irritiation by anyone.


but as soon as nobody cares anymore, then its usually too late and the sources will not be released anymore. the project is then abandoned for good.

we know very well that whoever claims to own the sources do not care for 68k. why should that ever change? but maybe its better this way, since none can be completely sure about the legal status of this ip. clean start is imho better to steer clear of the whole torrent of intriques that has plagued the platform.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: psxphill on August 26, 2014, 06:10:30 AM
Quote from: kickstart;771753
Years of x-copy on amiga land and now you are here crying for non sense

 I'm not crying, I'm discussing facts not opinion. I'm not going to ignore facts just because they are inconvenient.
 
Quote from: kickstart;771753
enjoy the library and shut up.

I don't do requests.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Minuous on August 26, 2014, 06:27:32 AM
Quote from: wawrzon;771716
however all this is void talk, since there is no chance in hell any sources were going open one way or the other.


Perhaps we should start a bounty to open source OS3.9? That has happened with various Amiga applications but curiously not with the operating system itself.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: warpdesign on August 26, 2014, 08:50:44 AM
Quote from: Minuous;771769
Perhaps we should start a bounty to open source OS3.9? That has happened with various Amiga applications but curiously not with the operating system itself.


OS3.9 contains various components from various companies (ie: Haage&Partner iirc). I guess you'd better off starting with OS3.x if you would like to open source something.

And seeing it's still been sold by Cloanto I'm afraid you'll have a hard time convincing anyone to open source it.

Releasing for free OS1.x (binaries only, except say/narrator stuff) could be possible though, and would be a good start.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on August 26, 2014, 09:38:21 AM
Quote from: Thomas Richter;771715
I don't really think so. I believe if you'd know whom to ask and what to ask for, it should be very well possible to obtain them if you'd want them. Of course, this requires approaching people politely and having a reputation as software engineer (not as hacker), so I would assume that Cosmos is out.  

But anyhow, it's not my problem.  

I, however, believe they are. There are always methods to interact and approach the right people to get what you want. Not as open source, for certain. The guerilla type approach of course does not work. It is pretty much a matter of thrust.


It would be great if a developer with such experience like you would contribute and help on Aros 68k because I think it is not that far away from fully replacing AmigaOS, in UAE it is already (in my view). I am not more interested in a future with the ghosts of the past who are just doing their own politics and attacking each other instead of cooperating. The old sources should rest in peace we now have a new and open OS and a open Rom. In my view the parties involved have no interest in 68k, why should they support the development and I have no interest to be dependent on the grace of others.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on August 26, 2014, 09:45:42 AM
Quote from: warpdesign;771770
OS3.9 contains various components from various companies (ie: Haage&Partner iirc). I guess you'd better off starting with OS3.x if you would like to open source something.

And seeing it's still been sold by Cloanto I'm afraid you'll have a hard time convincing anyone to open source it.

Releasing for free OS1.x (binaries only, except say/narrator stuff) could be possible though, and would be a good start.


It is a illusion to even think they could open source it. The sources would potentially speed up development on both AROS and MorphOS (regarding compatibility) and that would not be in the interest of everyone. Then the legal situation is (politely) a little "uncertain" so with whom do you want to negotiate? AmigaInc.? Hyperion? Both? And then there is still some money made with it so even if all problems would be solved how much money do you think the bounty should reach? 6000$ would certainly not be enough and the sums I think of are out of any reach today. And I personal think we now have a good replacement already that is open (Aros 68k) so instead of wasting money for old sources it would be better to invest in Aros 68k.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: warpdesign on August 26, 2014, 09:59:50 AM
Quote from: OlafS3;771772
It is a illusion to even think they could open source it. The sources would potentially speed up development on both AROS and MorphOS (regarding compatibility) and that would not be in the interest of everyone. Then the legal situation is (politely) a little "uncertain" so with whom do you want to negotiate? AmigaInc.? Hyperion? Both? And then there is still some money made with it so even if all problems would be solved how much money do you think the bounty should reach? 6000$ would certainly not be enough and the sums I think of are out of any reach today. And I personal think we now have a good replacement already that is open (Aros 68k) so instead of wasting money for old sources it would be better to invest in Aros 68k.
While I agree AROS 68k has made great progress and may now substitue Amiga ROM in some cases (emulation), it still needs a lot of polish, optimisations and stability fixes to really replace it. The small WB replacement app for example (I'm not talking about the MUI one but the one written by Jason) is real slow and is missing lots of functionalities for example (and hasn't been updated for what.. a full year ?).

It seems AROS lacks focus: lots of things are started but never really finished. And it hasn't changed.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: warpdesign on August 26, 2014, 10:01:19 AM
Quote from: OlafS3;771772
It is a illusion to even think they could open source it. The sources would potentially speed up development on both AROS and MorphOS (regarding compatibility) and that would not be in the interest of everyone. Then the legal situation is (politely) a little "uncertain" so with whom do you want to negotiate? AmigaInc.? Hyperion? Both? And then there is still some money made with it so even if all problems would be solved how much money do you think the bounty should reach? 6000$ would certainly not be enough and the sums I think of are out of any reach today. And I personal think we now have a good replacement already that is open (Aros 68k) so instead of wasting money for old sources it would be better to invest in Aros 68k.
It's true for the sources. Releasing 1.x 68k ROM images only for free wouldn't be that impossible though. And seeing how old it should have been released for free for non commercial use for a long time if you ask me.. But I'm not the sharks being Amiga ;)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Minuous on August 26, 2014, 10:14:49 AM
Quote from: warpdesign;771770
OS3.9 contains various components from various companies (ie: Haage&Partner iirc). I guess you'd better off starting with OS3.x if you would like to open source something.


Well, it would be H&P that the bounty would be directed to, of course. AFAIK they are the only ones who actually have the OS3.9 source code. Hyperion certainly don't, and I doubt Amino has it either.

Quote
And seeing it's still been sold by Cloanto I'm afraid you'll have a hard time convincing anyone to open source it.


Well, the OS Cloanto provide is actually OS3.1 with a few bits of OS3.5+3.9 thrown in, it isn't the proper OS3.9, there is a page at their site admitting this. I don't think their permission would be required in any event, they don't hold the rights to OS3.9 source code.

Quote
Releasing for free OS1.x (binaries only, except say/narrator stuff) could be possible though, and would be a good start.


I agree, but that's an entirely different issue and wouldn't solve this problem.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on August 26, 2014, 10:25:13 AM
Quote from: warpdesign;771774
While I agree AROS 68k has made great progress and may now substitue Amiga ROM in some cases (emulation), it still needs a lot of polish, optimisations and stability fixes to really replace it. The small WB replacement app for example (I'm not talking about the MUI one but the one written by Jason) is real slow and is missing lots of functionalities for example (and hasn't been updated for what.. a full year ?).

It seems AROS lacks focus: lots of things are started but never really finished. And it hasn't changed.


What exactly do you mean by "WB replacement app"? You mean the desktop? It has not been updated for years. It is in the process of being updated as far as I know but I do not know when. But (at least on 68k) it is not really important because you can use Magellan and Scalos (Scalos only works with certain older MUI classes so I do not support it). Icaros desktop 2.0 will be using Magellan too.

I must admit that it sometimes lacks focus in development. Priority should have been (from day one) 68k integration, stable and modern desktop, MUI on at least 3.8. and others. The priorities of Aros devs were different so people did not use it. But on 68k you can integrate 68k components like on MorphOS or AmigaOS (propably even better), so I have replaced Zune with MUI38 and Wanderer with Magellan. And that is only two examples. What is missing is optimizations and more support for classic hardware.

Next Icaros desktop sounds very promising but of course 68k still works as a blackbox and that will stay the same in future.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on August 26, 2014, 11:29:07 AM
he was referring to workbook.

what concerns thors involvemwnt with aros, alas its seems definitely better for various reasons he stays out of it. he still might be consulted in need. that should be enough.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 26, 2014, 01:33:11 PM
Quote from: OlafS3;771771
It would be great if a developer with such experience like you would contribute and help on Aros 68k because I think it is not that far away from fully replacing AmigaOS, in UAE it is already (in my view). I am not more interested in a future with the ghosts of the past who are just doing their own politics and attacking each other instead of cooperating. The old sources should rest in peace we now have a new and open OS and a open Rom. In my view the parties involved have no interest in 68k, why should they support the development and I have no interest to be dependent on the grace of others.

You are putting me in a dangerous position, that's the problem. If you want to drive AROS further and want to avoid any possible claim from Amiga, H&P and Hyperion, you should really develop that in a clean room approach. IOW, as soon as I contribute code, you (and I) are running into the danger-zone. What is always possible is that you ask technical questions and I answer them to the best of my knowledge, including internals. *That* is reasonably safe. Letting anyone look into the code, or me touching AROS code is something I would currently not dare. Not for claims from AROS, but for claims from Amiga.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kolla on August 26, 2014, 01:34:38 PM
Quote from: Thomas Richter;771735

No matter what you think, "Open Source" does not mean unpaid work. I currently participating a little bit in the linux intel driver development (only very minor), yet you find that people there *are* getting paid by the big players that have some interest in the platform.


Uhm, you really have been living under a rock! "big players" have been paying for development in open source projects for a long long time. All major software companies are involved in open source projects today, and have been for years. Even Microsoft.
 
Quote
You seem to believe that everything that needs to happen is to make the source publically available, and the problem will be solved.


The main problem would be solved, which is that anyone today can not study the sources and learn from it, today that is reserved to an exclusive club of rather narrow minded people with attitude problems.

Quote
That's not the case. It will replace one problem by another problem unless somebody "wears the hat" as we say here, i.e. has the final say what goes into the repository and what won't. No, I don't think that the average Amiga hacker is disciplined enough to accept a "no" in case it is a "no".


I do not care what you think about this, noone care about whether your so called average Amiga hacker is disiplined or not - the point is that _anyone_ can study the sources, learn from them, ask others, and compile whatever the heck they want from it, to run on whatever hardware they want.

Quote
Then, in the end, it does not matter whether the sources are released or not as long as somebody cares. Currently, they are closed, and I frankly say that nobody cares, at least not for the 68K branch.


Many would care if they were allowed to without all the legal obstruction.

Quote
Sad enough. There are enough things that could be done if there would be a way to do that without actually causing irritiation by anyone.    And how does that change with Open Source? It is just the same, as soon as the development team just considers the old software obsolete, you may have the source, cool, but you cannot really do anything about it because it's just a big pile of code you do not know how to work with.


Here your ignorance and frankly, arrogance, shows - people have again and again managed to pick up old code and do something about it. It may take time, and it may come and go in bursts, but as long as the code is available, it can be done. Look at Directory Opus, both old and Directory Opus Magellan, both are in much better shape now than they were when sources were released. Also, by releasing code, people get a chance to _LEARN_. Closed source is _LOST KNOWLEDGE_.

Quote
Projects got abandoned, and nobody picked them up. Open Source code is very volatile - whether your source still compiles with the latest version of libIdoNotcare.so you never know.


Look, I have maintained two architectures of Gentoo Linux that _noone else_ cared about, one for m68k and one for big endian ARM, I did for the fun of it, for the personal experience, for learning - I also have my own patches to kde3 and qt3 to deal with the problems you mention. Just because you don't know how to update code to deal with changes doesn't mean noone else can.

Quote
I worked in both ways, each has its advantages and its drawbacks, but just throwing the code into an OpenSource repository is not going to help much - unless somebody really cares about the result.


Noone will care when they are never given the chance. Throwing it into open source is a first step, it's about knowledge and heritage, one day someone may have an itch to scratch, a need to satisfy, and then it is much better that the sources are available.

Quote
Not really. In the end, somebody has to pay the party. Even for OpenSource if you care about quality or consistency. Again, I'm not against it. I'm against leaving it unmaintained.


Again, making sources available is a much needed first step for _any_ kind of progress for AmigaOS.

That said - AROS has much more momentum these days, in time AmigaOS becomes irrelevant. And people with your attitudes better wisen up.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on August 26, 2014, 01:44:37 PM
Quote from: Thomas Richter;771782
You are putting me in a dangerous position, that's the problem. If you want to drive AROS further and want to avoid any possible claim from Amiga, H&P and Hyperion, you should really develop that in a clean room approach. IOW, as soon as I contribute code, you (and I) are running into the danger-zone. What is always possible is that you ask technical questions and I answer them to the best of my knowledge, including internals. *That* is reasonably safe. Letting anyone look into the code, or me touching AROS code is something I would currently not dare. Not for claims from AROS, but for claims from Amiga.


ok I understand... that is one of the things I hate, "sh..t" NDA, contracts and so on that are related to both Hyperion and/or AmigaInc., with one person always repeating unproved accusations :( instead of trying to work together in common interest.

Honestly, they can keep both the sources and their NDAs and contracts

H&P will certainly not doing anything, I had contact with Mr. Haage a couple of times in the last years and I think he is not interested anymore in anything amiga-related
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 26, 2014, 01:51:12 PM
Quote from: Minuous;771776
Well, it would be H&P that the bounty would be directed to, of course. AFAIK they are the only ones who actually have the OS3.9 source code. Hyperion certainly don't, and I doubt Amino has it either.

I afraid nobody at H&P today has any idea about what they did back then with Amiga software. You should also understand the type of contracts we got back then. Of course, I can only speak for myself, and I know a little bit how Olsen's contracts looked like, but essentially rights went back to the contributors. Thus, in the long run, you need to speak to Amiga (or Animo, or however they call them today), Hyperion and you need to speak to the inidivual authors. Provided you can reach them. I for my part can no longer reach Heinz, concering SetPatch, FFS, console, exec and RAM-Disk. *Sigh*.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kolla on August 26, 2014, 02:06:02 PM
So you are between a rock and a hard place, tied by legal strings, so you cannot do anything with neither AmigaOS nor AROS, not even if you really want to. Hah, the irony. I suppose there is an opening for you with MorphOS.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on August 26, 2014, 02:15:43 PM
Quote from: kolla;771786
So you are between a rock and a hard place, tied by legal strings, so you cannot do anything with neither AmigaOS nor AROS, not even if you really want to. Hah, the irony. I suppose there is an opening for you with MorphOS.

Why should there be a opening with MorphOS?

@Thomas

It is a pity but I understand
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 26, 2014, 02:22:23 PM
Quote from: kolla;771783
Uhm, you really have been living under a rock! "big players" have been paying for development in open source projects for a long long time. All major software companies are involved in open source projects today, and have been for years. Even Microsoft.
Didn't I say exactly that? Whatever...
Quote from: kolla;771783
The main problem would be solved, which is that anyone today can not study the sources and learn from it, today that is reserved to an exclusive club of rather narrow minded people with attitude problems.
I'd rather say, "legal problems", because that fits the problem better.
Quote from: kolla;771783
I do not care what you think about this, noone care about whether your so called average Amiga hacker is disiplined or not - the point is that _anyone_ can study the sources, learn from them, ask others, and compile whatever the heck they want from it, to run on whatever hardware they want.
Thus, which type of goal do you have in mind? AmigaOs being separated into a pile of unmaintainable junk? Look at the arbitrary discipline of your average Amiga hacker, look at Cosmos. That's exactly the type of problem I do not want - people picking up the code, making changes without even asking, releasing stuff they should have coordinated. If the AmigaOs community would be somewhat more coordinated, disciplined and well-behaived, all fine. But it's in general a very unfriendly environment for stable software. No, I *do not* want five incompatible shells, ten incompable workbenches and six incompatible icon libraries because coder A doesn't like the style of coder B or is even too lazy to write a report.

Linux and the Linux kernel development are pretty resistent against such problems, at least most the time. That's because a good deal of the people that work in this environment are professionals that know how good software is written, and that it sometimes requires unfriendly decisions. Still, if I get a "no" for a patch I want to make to a well-maintained source like the kernel, I take it as a "no", and I can only say for myself that I probably do not yet understand the problem well enough to realize why my solution wasn't correct.

In Amiga-land, it is apparently already asking for too much if you request a bug report before a patch is made. So what's your expectation of how well that's going to work? Mine is "not at all" because even if I would say "No, please do not make this modification because..." people like Cosmos would do it anyhow. The features I see in his intuition patches are pretty bad ideas, but I don't even want to discuss because it's pointless to discuss with people like him - you don't reach them, so I don't even bother. So why would I want even more trouble by giving away sources? I *do* give away sources to people that are professional enough, and to whom I can talk. That worked well in the past, and it will continue to work well. Thus, if you are interested in the stuff I wrote, have an idea what you want to change, come, explain your ideas, if we agree, you get the source. Yes, really.  All provided no legal constraints involved.

Yes, it sounds arrogant, I know. But believe me, with a couple of years of software development behind me, at least I learned a bit about what works and what does not, and Open Source can work, in the right environment, with the right people, and a good project management. We don't have that here, and you see that everyday under your nose. What else does it take than this thread to prove it?  
Quote from: kolla;771783
These days, in time AmigaOS becomes irrelevant. And people with your attitudes better wisen up.

That's good for AROS, and even fine with me. Again, see my answer to Olaf.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kolla on August 26, 2014, 03:33:38 PM
Quote from: Thomas Richter;771789
Didn't I say exactly that? Whatever...
Yes you did, as if it was a novetly, something you have discovered just recently.

Quote
Thus, which type of goal do you have in mind? AmigaOs being separated into a pile of unmaintainable junk?
Is that not what it is today already? The goal I have in mind is just that people can be allowed to do with it whatever they see fit without having all kinds of threats and slander thrown at them.

Quote
Look at the arbitrary discipline of your average Amiga hacker, look at Cosmos. That's exactly the type of problem I do not want - people picking up the code, making changes without even asking, releasing stuff they should have coordinated.

I have no problem with that, over time, quality stands on its own merits, that is exactly how it works for example with Linux.

Quote
If the AmigaOs community would be somewhat more coordinated, disciplined and well-behaived, all fine. But it's in general a very unfriendly environment for stable software. No, I *do not* want five incompatible shells, ten incompable workbenches and six incompatible icon libraries because coder A doesn't like the style of coder B or is even too lazy to write a report.

What you describe, we already have in AmigaOS, 3.5 and 3.9 introduced a whole lot of incompatibility, OS4 is even worse in that regard. Features of both Workbench and shell has come, vanished, reappeared etc. And all this within "official AmigaOS".

The problem is that quality is not allowed to win, again and again the "official developers" have messed things up and created lots of trouble. Trouble that could have been avoided if development could have happened in the open so that _all_ developers and users could have a saying in what what solution we want, in what direction we want to see the OS advance.

Quote
Linux and the Linux kernel development are pretty resistent against such problems, at least most the time. That's because a good deal of the people that work in this environment are professionals that know how good software is written, and that it sometimes requires unfriendly decisions. Still, if I get a "no" for a patch I want to make to a well-maintained source like the kernel, I take it as a "no", and I can only say for myself that I probably do not yet understand the problem well enough to realize why my solution wasn't correct.

Noone stops anyone from forking the Linux kernel and it happens all the time, distributions typically has a whole lot of their own kernel patches that they maintain, the different architectures developers have sets of patches they maintain as they slowly get them merged into main. Those professionals you write about used to be a bunch of happy amateurs too at some point, they were allowed to learn and advance and Linux evolved into what it is today. Just like you are now learning by submitting kernel patches. I have maintained a whole bunch of linux kernel patches for myself (and for the company I work for) up through the times, to deal with things I care about in the kernel (ipv6 autoconf, alsa, drivers for various arcaic hardware etc). Same with software on Linux and BSD.

Quote
In Amiga-land, it is apparently already asking for too much if you request a bug report before a patch is made.
Yes, when most developers ignore such requests, have bouncing email addresses etc. In real world it is quite common to create patches and distribute them, because sometimes getting proper solutions upstream takes time. Why should this be different on Amiga?

Quote
So what's your expectation of how well that's going to work? Mine is "not at all" because even if I would say "No, please do not make this modification because..." people like Cosmos would do it anyhow.

Yes, and why is that a problem? The freedom to tweak and mess around as much as you like is _exactly_ what should happen.

Quote
The features I see in his intuition patches are pretty bad ideas, but I don't even want to discuss because it's pointless to discuss with people like him - you don't reach them, so I don't even bother.

And noone would be forced to use his code, anyone can chose what to use themselves. With code out in the open, you don't even have to discuss with him, anyone can look at the code and there will be concensus about what makes sense and what doesn't. Also people have different needs, for some uses one solution makes a heck lot more sense than "the official" - this is why there in "Linux land" exists so much diversity.

Quote
So why would I want even more trouble by giving away sources? I *do* give away sources to people that are professional enough, and to whom I can talk. That worked well in the past, and it will continue to work well. Thus, if you are interested in the stuff I wrote, have an idea what you want to change, come, explain your ideas, if we agree, you get the source. Yes, really.  All provided no legal constraints involved.

What do you mean "no legal constraints"?

Quote
Yes, it sounds arrogant, I know. But believe me, with a couple of years of software development behind me, at least I learned a bit about what works and what does not, and Open Source can work, in the right environment, with the right people, and a good project management. We don't have that here, and you see that everyday under your nose. What else does it take than this thread to prove it?

There is no difference to open source and closed source when it comes to "the right environment, with the right people, and a good project management" - that goes for any project. Do you have any idea how many Cosmoses there are around in the FOSS world? A LOT! And some of them are backed by Companies with agendas. Just watch the current systemd turmoil. Still it works, because people have options.

Because of legal nonsense and the hostile attitude among certain developers, the Amiga community was never even given the chance. Luckily at least some people realized this so AROS was born.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on August 26, 2014, 03:49:41 PM
@olaf

thats exactly the sort of legal constraints that are most likely intentionally put on people, probably without them noticing till its too late. probably thats the reason too so many contributors must have left completely afraid to switch to the alternatives.

@thor

cosmos is not exactly the representative for everyone who is interested in improving on amiga systems. on the contrary his position is rather known as orthodox and must not be used as example of what would happen if amiga software was open sourced, especially that exactly his approach would then not be necessary anymore.

also i think after some consideration there must be a place for everyone, one just needs to find an appropriate task for the given skills and character. it just takes some effort to align with others..
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: warpdesign on August 26, 2014, 04:17:33 PM
Quote

Thus, which type of goal do you have in mind? AmigaOs being separated into a pile of unmaintainable junk? Look at the arbitrary discipline of your average Amiga hacker, look at Cosmos. That's exactly the type of problem I do not want - people picking up the code, making changes without even asking, releasing stuff they should have coordinated. If the AmigaOs community would be somewhat more coordinated, disciplined and well-behaived, all fine. But it's in general a very unfriendly environment for stable software. No, I *do not* want five incompatible shells, ten incompable workbenches and six incompatible icon libraries because coder A doesn't like the style of coder B or is even too lazy to write a report.

Don't you think he would behave differently if code was available and updated ? I'm pretty sure there are people hacking like him in the Linux world, just because you can, but would you say Linux has become a pile of junk ? I wouldn't say so...
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: warpdesign on August 26, 2014, 04:24:36 PM
Quote from: OlafS3;771777
What exactly do you mean by "WB replacement app"? You mean the desktop? It has not been updated for years. It is in the process of being updated as far as I know but I do not know when. But (at least on 68k) it is not really important because you can use Magellan and Scalos (Scalos only works with certain older MUI classes so I do not support it). Icaros desktop 2.0 will be using Magellan too.

I must admit that it sometimes lacks focus in development. Priority should have been (from day one) 68k integration, stable and modern desktop, MUI on at least 3.8. and others. The priorities of Aros devs were different so people did not use it. But on 68k you can integrate 68k components like on MorphOS or AmigaOS (propably even better), so I have replaced Zune with MUI38 and Wanderer with Magellan. And that is only two examples. What is missing is optimizations and more support for classic hardware.

Next Icaros desktop sounds very promising but of course 68k still works as a blackbox and that will stay the same in future.


I was referring to the "low-end" 68k AROS targeted at Amiga OCS/ECS with very-little RAM, by WB I meant "Workbook" by Jason McMullan which is supposed be a Workbench.

I guess this is quite different if you target higher-end: then you have plenty of ram/power to use bigger desktop apps like Magellan or Scalos.

But be it high end or low end, it seems focus gets lost after some time and lots of things are almost ready, but not yet, and lack polish: Zune, WorkBook,...
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on August 26, 2014, 05:11:46 PM
Quote from: warpdesign;771802
I was referring to the "low-end" 68k AROS targeted at Amiga OCS/ECS with very-little RAM, by WB I meant "Workbook" by Jason McMullan which is supposed be a Workbench.

I guess this is quite different if you target higher-end: then you have plenty of ram/power to use bigger desktop apps like Magellan or Scalos.

But be it high end or low end, it seems focus gets lost after some time and lots of things are almost ready, but not yet, and lack polish: Zune, WorkBook,...

"Workbook" was designed as a kind of minimal desktop as far as I know. Jason has joined Arix and was contributing not much last year because of lack of time (not only for 68k). I have never tested workbook so I cannot say much about it. Do not forget that the project started to bring AmigaOS to X86 so there always were plenty of resources and today even on ARM (the new low-end) you have much more resources than you ever had on Amiga. That meant they never optimized it for classic hardware, for a long time it not even existed on 68k and from Aros devs noone is caring for it at the moment. Toni is doing something and has done some optimizations recently, Jason did do a lot in the past but not some time now. 68k never was really priority or interesting to most Aros devs. Because of that I hoped that there would some of the 68k devs join and help there because it is not that far away. It needs still certainly some optimizations regarding classic hardware and additional support for hardware, nothing impossible and propably only a few months for experienced developers. Up to now I could create some interest in the 68k community but still no developer who helps at the core and that is the place where most has to be done. Lack of direction, yes propably, everyone does what he likes to do but there is no big plan and management like in a company that wants to sell products. It is opensource, that has advantages and disadvantages.

I do not think that "Workbook" will be updated in future, I know there is a updated version of Wanderer in future and you can use Magellan and Scalos as desktop. Bring Zune to at least 38 should have highest priority but it propably is a complicated task. For me personal there is no problem because on Aros 68k you can simply add original MUI38 and replace Zune. The only problem is that the original Prefs do not work anymore, I partly solved that by using other prefs and predefining prefs files.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kamelito on August 26, 2014, 05:26:44 PM
HACKER [originally, someone who makes furniture with an axe] n. 1. A person who enjoys learning the details of programming systems and how to stretch their capabilities, as opposed to most users who prefer to learn only the minimum necessary. 2. One who programs enthusiastically, or who enjoys programming rather than just theorizing about programming. 3. A person capable of appreciating hack value (q.v.). 4. A person who is good at programming quickly. Not everything a hacker produces is a hack. 5. An expert at a particular program, or one who frequently does work using it or on it; example: "A SAIL hacker". (Definitions 1 to 5 are correlated, and people who fit them congregate.) 6. A malicious or inquisitive meddler who tries to discover information by poking around. Hence "password hacker", "network hacker".
Title: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 26, 2014, 06:30:29 PM
Quote from: kolla;771796
What you describe, we already have in AmigaOS, 3.5 and 3.9 introduced a whole lot of incompatibility, OS4 is even worse in that regard. Features of both Workbench and shell has come, vanished, reappeared etc. And all this within "official AmigaOS
What, where? Excuse me, but since when are there incompatibilities? I don't know much about workbench problems since I'm only using it and it works fine -  but as a matter of fact, I maintain the shell. Yes, I do. Thus, speak up open, which incompatibilities are there? I haven't received a bug report for years, and there's a straight line of shells from 3.1 to 3.9 and the various boing bags. Hopefully all compatible to each outher. If not, report a bug. Yes, please do.
Quote from: kolla;771796
The problem is that quality is not allowed to win,  
Quality is not allowed to win if people make stupid patches and somebody has to clean up behind them. It is not that I don't care about my software. Just that there wasn't much request for caring lately. I believe I released a couple of old and older stuff lately, and updated it. So please - I beg your pardon?  
Quote from: kolla;771796
Again and again the "official developers" have messed things up and created lots of trouble. Trouble that could have been avoided if development could have happened in the open so that _all_ developers and users could have a saying in what what solution we want, in what direction we want to see the OS advance.
Thus, once again, if you have a case where you believe that I've messed something up and it requires fixing, say so openly and I'll fix it. As soon as I find some time. But please don't tell me that I leave things unmaintained. Thank you.  
Quote from: kolla;771796
Noone stops anyone from forking the Linux kernel and it happens all the time, distributions typically has a whole lot of their own kernel patches that they maintain, the different architectures developers have sets of patches they maintain as they slowly get them merged into main.
So, apparently, you have not been working on it, right? Yes, you can patch up your own kernel. But there's no benefit. You need to move it into the official branch - and that's the important part where you have to discuss and argue, and will often find yourself in a position that you do not quite understand the sources well enough to produce something that is acceptable. Yet, in Amigaland, this type of crap is thrown untested at people, actually *without* giving the maintainer of the program even a chance to check or argue.  
Quote from: kolla;771796
 Those professionals you write about used to be a bunch of happy amateurs too at some point, they were allowed to learn and advance and Linux evolved into what it is today.
Funny thing. Guess I did the same, but I learned on AmigaOs. Yet, I never did what I see just here - patch up some outside program without actually knowing what it does, and release that to end users. Strange, isn't it?

As a matter of fact, you *don't need* the Os sources to write good programs. You need the interface. Actually, it's one of the core disciplines of software development to write against well-defined interfaces, or to define such interfaces. Yet, such key knowledge is apparently ignored in Amiga-land. Instead, the average Amiga hacker goes "bang-bang" on the hardware and "hack hack" onto the Os. So what do you think will happen?    
Quote from: kolla;771796
 Yes, when most developers ignore such requests, have bouncing email addresses etc. In real world it is quite common to create patches and distribute them, because sometimes getting proper solutions upstream takes time. Why should this be different on Amiga?
Because the audience you get is different. The skilled software engineer has long left the platform.  
Quote from: kolla;771796
Yes, and why is that a problem? The freedom to tweak and mess around as much as you like is _exactly_ what should happen.
No, should not. The problem is that such programs are released into the wild, there causing problems with *my* stuff, and I have the trouble cleaning up behind the lines. The amount of trouble tools like MCP caused and the amount of wasted hours because somebody didn't know better but still hacked the Os are enormous. There's an interface, program against it. If you don't like it, or need something else, talk to the person responsible for it. There are still ways to negotiate cooperation. Just because sources are closed does not mean they are locked away. They are only locked away from the fools, for the better of the rest of the users.  
Quote from: kolla;771796
And noone would be forced to use his code, anyone can chose what to use themselves.  
That's not quite that simple. You do not install such a hack and then say "it works or it does not". It will likely cause disruption elsewhere, with programs that seem to work just fine before. And believe me, in the end its not the author of the patch that gets the bug report. Such nonsense creates a lot of work *for other people* and trouble for the users that are completely unable to resolve the problems. Linux is a paradise for programmers, but its probably hell for ordinary users. Not that I'm not using it and loving it, but writing a program on Linux that still works in two years from now is almost impossible. You have to continuously update the sources because some of the smart developers again considered to change an interface. That's ok for Linux. It's not ok if you want stable products. I'm not a big fan of Microsoft, but there's a reason why they are successful. Their stuff just works. Guess what? It's what most people need: An environment that solves their problems. Not that creates new ones because patch A doesn't work with program B.  
Quote from: kolla;771796
With code out in the open, you don't even have to discuss with him, anyone can look at the code and there will be concensus about what makes sense and what doesn't. Also people have different needs, for some uses one solution makes a heck lot more sense than "the official" - this is why there in "Linux land" exists so much diversity.
For the better or for the worse. Or how does one say? "You never know how the print command is called today". Yes, works ok for me, I know by now enough about the details. Try to teach your granny, and you'll learn what's wrong with it.

That's exactly the type of problem you get without a good project management, or somebody who overlooks the big picture. How many inconsistent user interfaces do we have in Linux? I stopped counting... Again, fine with me - but the hell for the average user.

In Amiga, we even had a user-interface style guide. Completely outdated by now of course, but at least somebody took the time to write down how an Amiga application should look like, which AREXX commands it should support and so on.  
Quote from: kolla;771796
What do you mean "no legal constraints"?
Pretty simple. I can handout the mmu.lib to whomever I want - that's my source. I cannot hand out the latest layers.library, simply because I don't own it. Yet, I can maintain it.  
Quote from: kolla;771796
Because of legal nonsense and the hostile attitude among certain developers, the Amiga community was never even given the chance. Luckily at least some people realized this so AROS was born.

Again, I don't have a problem with AROS, but I *personally* don't really care much. Problem is, time of AmgiaOs is really over, for various reasons, the whole construction of the Os is just upside down, and there is no market for it in first place. Yet, if you want to contribute your time, you are surely welcome. I personally don't see the vision behind all that, i.e. what the purpose of the project is about. But anyhow, who am I to judge...
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: saimon69 on August 26, 2014, 07:19:07 PM
Sometimes i think that,if Amiga Communities would stop thinking about making money, acting like they are still important and simply have fun, things would be soo much relaxed... not gonna happen i know.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: saimon69 on August 26, 2014, 07:35:17 PM
Addition: i personally am an AROS supporter exactly because am tired of all this copyright and ownership crap: i see other retro computer scenes thrive because people simply have fun and they don't care anymore about stepping some old copyright or API problems, and where devs and users simply do what they care, and don't try to police others if the way others do something do not follow the "clear one and only way". In this Amiga scene is very emblematic on showing what happen IMO when a computing ecosystem go awry, and, sadly, is also giving up a glimpse of future concerning what might be - let's assume -  a WII retrocomputing or similar: no way to do anything due to copyrights, lockdowns and such.

So at the end the question is: want we lay our back in the chair and have fun or want we to fight every moment and let this already crippled Amiga ecosystem fade in obscurity due to excessive litigation and micromanaging? If i was me would let people do what they like all the way to the C&D, to the handcuffs and over!!!!

And, by the way, am upset about this state of things! [more to come when i calm down]
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: billt on August 26, 2014, 07:36:23 PM
Quote from: danwood;762058
Looks interesting, does this have any benefits for OS 3.9 users?


I'm also curious if this is useful to 3.9 (and 3.5, plus any boingbags for either) users, or only for 3.1 users.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: TheMagicM on August 26, 2014, 07:52:00 PM
Quote from: saimon69;771810

So at the end the question is: want we lay our back in the chair and have fun or want we to fight every moment and let this already crippled Amiga ecosystem fade in obscurity due to excessive litigation and micromanaging? If i was me would let people do what they like all the way to the C&D, to the handcuffs and over!!!!



People will always fight because some hold on to the belief that "Amiga" is worth something in the real world..that its IP/brand/workbench/old 68k code is worth something.  Its not.  If I was filthy rich I wouldnt buy it.  Its outdated and has no techological value.   Its only valuable to the Amiga community.  If WE had it, we could improve on it.  The only way to improve on the 68k machine would be to replace the OS like AROS 68k is trying to do (I havent read a whole lot on it, but it sounds cool).

Its also true that the Amiga community, alot of the folks in it, are tight asses and would rather spend as little as possible.  I sometimes think that everyone is on welfare.   I read about MorphOS being "too expensive" and it should be "half price" or whatever.  People just dont want to pay for anything.  Anyway..I just enjoy what I have and sit back with a bag of popcorn when the SHTF in the Amiga world.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: saimon69 on August 26, 2014, 08:30:56 PM
@Thomas Richter

Well reading a bit deeper i can see where you come from, engineers are like architects, they need clean structures and APIs, something that a system left essentially on its own like Amiga OS lacks; the maintainer part cannot be solved on the old structure, however imo transiting to AROS would fix this since as open source project can be always - in theory - taken over from people without really dying...
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: saimon69 on August 26, 2014, 10:46:40 PM
@TheMagicM

About people in the community refusing to spend, that is Commodore's Fault: it provided us with a wonderful powerful machine at a very cheap price, so it is in our culture and DNA to expect the best bang for the buck :)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: TheMagicM on August 26, 2014, 11:29:48 PM
Quote from: saimon69;771820
@TheMagicM

About people in the community refusing to spend, that is Commodore's Fault: it provided us with a wonderful powerful machine at a very cheap price, so it is in our culture and DNA to expect the best bang for the buck :)


I wouldnt say it was "inexpensive".  The Amiga for me was expensive.  I was in high school and worked part time to save the $550 to buy an Amiga 500.  It was even more difficult to get an Amiga 2000. LOL
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: TheMagicM on August 26, 2014, 11:33:54 PM
Quote from: saimon69;771810
i see other retro computer scenes thrive because people simply have fun and they don't care anymore about stepping some old copyright or API problems, and where devs and users simply do what they care, and don't try to police others if the way others do something do not follow the "clear one and only way".


Lets compare vs Atari.  They have some fairly modded systems out there like the Falcon.  Have they undertaken a port and moved their OS to a new architecture like MorphOS Devs did?  Or are they still on that ugly old TOS that I remember?   I'm just trying to see which you're comparing.  If its C64, now that is inexpensive...nothing to fight about there.  The "OS" is done..other than new things like Wheels etc..but nothing else to do on that system.  

I am curious to know which other retro systems are going the way Amiga is going though since I dont really keep up with anything but Commodore systems.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Cosmos on August 27, 2014, 06:12:57 AM
I need to explain somethings :

1/ after disassembling, the Kickstart 3.1 is really slow for me
2/ the intuition.library is certainly the slowest
3/ i'm perfectionnist and cannot live using a slow Kickstart on my Classics
4/ i know asm coding but no C/C++
5/ near all coders contacted many years ago refuse to improve somethings on 68k
6/ or give sources to me (except one personn)
7/ so I lost many precious years to learn reverse engeenering
8/ PPC is a complete dead-end, created since the beginning by the ennemies of the Amiga Classics
9/ for of course Atari and Commodore goodbye
10/ with PPC, many Amiga coders loose times & energy for nothing (= no success, only about 5000 AmigaNG users actually versus 5 millions Amiga68k users in the past) : superb trap...
11/ one of my idea is to do what the Amiga's ennemies don't want we do : keep going the 68k evolution...
12/ all my work is hack yes, but not dirty : all my sources and improvements are very clean & clear...

If you are unable to understand theses evidences, it's YOUR problem...


I gave an example at the end of the intuition.readme : on a 68000/010, my code is more than 200 times faster...

(Ok, I wrote "RJ Mical" : was a stupid french joke, all apologies, I'll remove this name. It's a compilator problem, not a coder problem...)


Another example who make coders cry : R_DrawImage

Quote from:
R_DrawImage
   move.l   d1,-(sp)         
   move.l   d0,-(sp)
   move.l   a1,-(sp)
   move.l   a0,-(sp)
   jsr      _DrawImage
   lea   $10(sp),sp
   rts

_DrawImage
   move.l   d2,-(sp)
   move.l   8(sp),d0
   move.l   $C(sp),d1
   move.l   $10(sp),d2
   clr.l   -(sp)
   clr.l   -(sp)
   move.l   $1C(sp),-(sp)
   move.l   d2,-(sp)
   move.l   d1,-(sp)
   move.l   d0,-(sp)
   bsr.w   _DrawImageState
   lea   $18(sp),sp
   move.l   (sp)+,d2     ; make the wrong CCR for BenchTrash 1.73
   rts



Now it's of course :

R_DrawImage
   clr.l   -(sp)
   clr.l   -(sp)
   move.l   d1,-(sp)
   move.l   d0,-(sp)
   move.l   a1,-(sp)
   move.l   a0,-(sp)
   bsr.w   _DrawImageState
   lea   $18(sp),sp
   rts


who is now more than 3 times faster on a 68060...


:)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Duce on August 27, 2014, 10:43:41 AM
Moment you started muttering vague threats at people that did not agree with you, Cosmos - I lost complete interest in your product, as good as it might be.  It's like opening up a flower shop with a sign outside that says "free Typhoid with every purchase!".  Might be the best damned flowers in town, but that typhoid thing, that... that concerns me.

Yes, Coders are a funny breed of people.  Moody, protective, best described as simply "eccentric".  That's a far stretch from uttering threats at another member of the community, which you've done here towards Thomas.

I know neither of you, you or Thomas.  Real world, Amiga "scene" or otherwise. I haven't looked at the CV's of you, nor he.

Not here to pick a fight, but just be aware that I at least first read this thread with great interest, and after you went off the rails making threats I pretty much decided that your product, as good as it may be - wasn't worth the amount of "crazy" I was reading.

Best of luck on your programs.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on August 27, 2014, 10:44:49 AM
all fine and good but who these enemies of amiga may be?
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Joloo on August 27, 2014, 12:39:06 PM
It's faster because you combined the glue-code which was necessary for the used compiler: Green Hill.

The used Green Hill C-Compiler wasn't able at that time to fetch arguments from registers directly; instead, assembler written glue-code had to be provided to move the register arguments into the corresponding C-compiler expected stack arguments, because at that time, two ABIs were used; the Amiga ABI (register arguments) and the m68k ABI (stack frame). While the Green Hill C-Compiler did only support the m68k ABI (as well as later the earlier versions of the Aztec and Lattice compiler) the workaround was at that time to use assembler generated glue-code - till later so called PRAGMAs and AMICALLs were introduced in order to support the Amiga ABI without using glue-code.

If one gets the chance compiling Intuition newly with current compilers (SAS/C, gcc or vbcc) the by you combined glue-codes gets completely removed, just because these compilers support the Amiga ABI. Of course there would be a little speed-up, but honestly, it would be so marginal that no one would notice it.

Rewriting the Layers-library from ground up like THOR did, inclusive a new algorithm, is far more noticeable.

Next, touching and optimising a beast like Intuition requires really deep insights into how this big state-machine works - and frankly, there are only a handful people who I would trust in that they would have the knowledge and skills for this kind of task.
Fortunately for me as user of the AmigaOS 3: No one is allowed to break the functionality of Intuition, because that what I would expect if once it would become unmaintained Open-Source...
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: matthey on August 27, 2014, 01:38:35 PM
"Can we all get along?"

@Cosmos
I agree that there is a compiler problem in the AmigaOS and I too want to fix it. If the problem is compilers then we must improve the compilers. I agree that some developer's attitudes have been less than helpful but a sour and hostile attitude will only make it worse. I don't have a problem with you hacking abandoned software but you should be more respectful of those still developing because they are also fighting against obsolescence of the Amiga. Reverse engineering with micro-optimizations is not the way to further develop the Amiga. Losing the comments while reverse engineering is a major setback in development. Development decisions should not be made solely by one person because humans are too fallible. There are very experienced developers that know what they are doing and need to be listened to and respected. I am one of the developers that has responded to your e-mails and given you code yet I doubt that I am the "one" that gave you sources. You can't "evolve" the AmigaOS by yourself because not enough people will accept your work and methods.

@ThoR
So called "hackers" and "cycle counters" like Cosmos and I have found and (sometimes) reported several important bugs. At times you have been condescending and ignored anything below major algorithm changes. Ignoring the fact that your compiler is generating awful code greatly increases the chances that people like Cosmos and I are going to come along and optimize away half your code even if it only saves some memory. You could at least compile 68020 versions of AmigaOS modules as it takes very little time for these small modules. There is less compiler complexity for 68020 code which might just give better quality code and code optimized for a 16 bit 68000 CPU is not efficient on a 32 bit 68020+ CPU. AmigaOS started requiring a 68020+ and you are still compiling for a 68000. Do you compile your x86 codecs for a 8086? Compilers are made to optimize (and micro-optimize) but you have to choose the correct target. Amiga users still want an efficient AmigaOS today which allows them to continue to use low spec processors with minimal memory. Ignoring the users and possibly better compilers isn't going to help your cause either. Expecting the Amiga community or some rich suitor to come along and start paying you to continue to do what you want to do developing the AmigaOS probably isn't going to happen anytime either. I think you are willing to work for less than you are worth to do what you love to do though. The Amiga is in you just as much as Cosmos whether you are willing to admit it or not.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Cosmos on August 27, 2014, 02:05:30 PM
@Matthey

You and ALL Classics users are agree with me when I want to make an important library romable. Users want simplicity : if Phase5 with the BlizzardPPC and MK3/CSPPC have included
CyberGraphX4, BVision & CyberVisionPPC monitors and Warp3D into their firmware, they have sold many many many more hardware for sure...

It's like Elbox with their FastATA driver & pci.library & Picasso96 software : they will sold thousand Mediators & FastATA if drivers in rom...

Users are bored with complicated software installations, you know that like me... They left Amiga Classics because it's becomed too much complicated...

When I ask for this very small feature (making romable take maximum 1 hour of coding), it was always no or no answer...

When I asked two times Amiga Inc. for a new physical Kickstart 3.9 : no answer...

So what ? You want me cool after that ? No, I cannot stay cool, sorry...


@Joloo

This beta 6 is a WIP : still a lot of work to do to get it really fast, please understand...

And the example in my intuition.readme is not glued-code...


@Duce

Do what you want, I don't care...
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on August 27, 2014, 02:16:45 PM
Quote from: Joloo;771848

Fortunately for me as user of the AmigaOS 3: No one is allowed to break the functionality of Intuition, because that what I would expect if once it would become unmaintained Open-Source...

why do you think that breaking backwards compatibility with some os element would be more accepted by community if it was open source? i feel quite the opposite. as long as it is closed source community has to live with design decisions of a small group, whether they are competent or not. open source involvement discussion and users feedback, i expect the decisions taken would be a good trade of between progress and compatibility, given in contrary to linux amiga depends on a pool of applications that cannot be adopted to random api changes. and even if it happened, someone would fork it for compatibility. as example see aros v0 and v1 and deadwoods work bringing v1 advantages to v0 on trunk where possible.

@matthey

+1
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 27, 2014, 06:57:49 PM
Quote from: matthey;771852
So called "hackers" and "cycle counters" like Cosmos and I have found and (sometimes) reported several important bugs.  
So what's the problem in reporting them? Apparently, it's asking for too much.  
Quote from: matthey;771852
At times you have been condescending and ignored anything below major algorithm changes. Ignoring the fact that your compiler is generating awful code greatly increases the chances that people like Cosmos and I are going to come along and optimize away half your code even if it only saves some memory.  
Why, instead of making such claims, you don't go ahead and make an experiment. Write a small AREXX script that opens and closes a couple of windows, multiple times, and measure the time it takes. Make them overlap, move, resize, whatever. Take the time for the full execution, measure several times, probably 20 times for the same script. Then run the script with the original specs, with the hacked intution, and the replacement layers. Measure the time again. Now check whether there is any substantial difference - substantial = larger than the variance of the measurements.

*After* that, you can argue.  

Currently, I don't see why I should waste my time with that kind of stuff. Actually, it's even worse - you get someting for free, yet complain.  
Quote from: matthey;771852
 The Amiga is in you just as much as Cosmos whether you are willing to admit it or not.

I don't care what they are like - it's time to learn something basic about software and computer science then. It's plain stupid to optimize on the wrong end. It's actually the 101 of computer science.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Thorham on August 27, 2014, 06:58:03 PM
Quote from: Cosmos;771831
Another example who make coders cry : R_DrawImage
Wow, that's some amazing crapz0r code right there :( Compilers that produce such crap should be burned :(
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: TheMagicM on August 27, 2014, 11:40:29 PM
Quote from: Cosmos;771831
I need to explain somethings :
8/ PPC is a complete dead-end, created since the beginning by the ennemies of the Amiga Classics
9/ for of course Atari and Commodore goodbye
10/ with PPC, many Amiga coders loose times & energy for nothing (= no success, only about 5000 AmigaNG users actually versus 5 millions Amiga68k users in the past) : superb trap...



68k is even moreso a dead-end than PPC..but thats another thread for someone else to battle.  I personally dont care for 68k other than for retro gaming.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Thorham on August 28, 2014, 02:20:13 AM
Quote from: TheMagicM;771869
68k is even moreso a dead-end than PPC..
Everything Amiga is a dead end, except for hobby purposes, which is fine with me. I'm not into Amiga because it's going to get up to date, I have a peecee for that.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: olsen on August 28, 2014, 08:15:37 AM
Quote from: Thorham;771862
Wow, that's some amazing crapz0r code right there :( Compilers that produce such crap should be burned :(

Excuse me, this is very little code to judge the compiler by. You're looking at one toenail of the left forepaw of the elephant, so to speak.

Intuition was built with the same 'C' compiler which was used for building the entire original Amiga operating system (Green Hills 'C'). That 'C' compiler was truly excellent, and just to put this into perspective, it took the Lattice/SAS 'C' compiler almost ten years to catch up to it in terms of code quality.

The one big difference between Green Hills 'C', and the Amiga-native Lattice and SAS/C compilers is in how parameters are passed to functions. Lattice and SAS/C could pass function parameters in registers (a0/a1/d0/d1, other registers could be specified as needed), whereas Green Hills 'C' exclusively passed parameters on the stack.

Passing parameters on the stack was not an indication of poor code generation, it was merely how the ABI of the operating system target platform wanted it to be done: Green Hills 'C' was a *Unix* targeted optimizing compiler (back then the focus was on portable 'C' compilers and optimizing 'C' compilers were rare), for the Sun 2 and Sun 3 workstations, which was cleverly reworked into a cross-compiler for the Amiga.

If you want to critique the quality of the Intuition code, please cast your eye on the meat, bones and nervous system of the beast.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Thorham on August 28, 2014, 10:23:51 AM
Quote from: olsen;771880
Excuse me, this is very little code to judge the compiler by. You're looking at one toenail of the left forepaw of the elephant, so to speak.
Okay, perhaps it's crap because it was compiled from crap C code? This crap had to come from somewhere, and if it's the compiler's fault, then that's not good. After all, if such simple code is already crap, then what on earth is it going to do with more complex code?

If it's the programmers fault, then they should've been fired :D

Quote from: olsen;771880
If you want to critique the quality of the Intuition code, please cast your eye on the meat, bones and nervous system of the beast.
That's going to be hard without the source code, isn't it?
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Cosmos on August 28, 2014, 10:42:17 AM
Quote from: olsen;771880
Excuse me, this is very little code to judge the compiler by. You're looking at one toenail of the left forepaw of the elephant, so to speak.

Intuition was built with the same 'C' compiler which was used for building the entire original Amiga operating system (Green Hills 'C'). That 'C' compiler was truly excellent, and just to put this into perspective, it took the Lattice/SAS 'C' compiler almost ten years to catch up to it in terms of code quality.

The one big difference between Green Hills 'C', and the Amiga-native Lattice and SAS/C compilers is in how parameters are passed to functions. Lattice and SAS/C could pass function parameters in registers (a0/a1/d0/d1, other registers could be specified as needed), whereas Green Hills 'C' exclusively passed parameters on the stack.

Passing parameters on the stack was not an indication of poor code generation, it was merely how the ABI of the operating system target platform wanted it to be done: Green Hills 'C' was a *Unix* targeted optimizing compiler (back then the focus was on portable 'C' compilers and optimizing 'C' compilers were rare), for the Sun 2 and Sun 3 workstations, which was cleverly reworked into a cross-compiler for the Amiga.

If you want to critique the quality of the Intuition code, please cast your eye on the meat, bones and nervous system of the beast.

All my intuition.library source is full of examples I gave... This library is the slowest of the Kickstart 3.1 for me...

I'll show you another example for the beta 7 release if you want...

Note : passing args with registers is more 4 or 5 times faster than by the stack, specially on 000/010/020 who don't have datacache... And we don't need the addq/lea after the subroutine...

And making thousand supertinysubroutines (3 or 4 mnemonics) called by bsr/jsr is not a sign of a good compilator... Inlining is MUCH faster, really...


:(
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: olsen on August 28, 2014, 11:25:54 AM
Quote from: Cosmos;771885
All my intuition.library source is full of examples I gave... This library is the slowest of the Kickstart 3.1 for me...

I'll show you another example for the beta 7 release if you want...

Note : passing args with registers is more 4 or 5 times faster than by the stack, specially on 000/010/020 who don't have datacache... And we don't need the addq/lea after the subroutine...

There are, give or take, some 800 functions which make up intuition.library V40, each of which passes parameters on the stack, and that's not counting the function calls made through amiga.lib stubs. This may be a ripe field for peephole optimizations, but my best guess is that the impact any such optimizations could have on overall system performance will be rather low.

Intuition is largely event-driven: its main purpose is capturing user input and routing these events to the clients which consume and react to them. This type of operation is very slow to begin with and typically does not happen more than 60 times per second (e.g. moving the mouse pointer), and more likely happens less than 10 times per second (hitting a key, clicking a mouse button). These operations happen as fast as the user can produce these events.

Aside from the event processing and routing, Intuition also contains API wrapper code which makes interacting with screens and windows, and rendering into them, possible (and nicer, too, from a programmer's point of view). These wrappers connect directly to graphics.library and layers.library, respectively.

Then there's the rest of the code, which consists of utility functions. For example, if you click on a gadget in a window Intuition will need to figure out if the click hit the gadget or the window. Utility functions such as the one which figures out geometric relationships are written in pure 68k assembly in intuition.library V40.

The parts of Intuition which interface to graphics.library and layers.library are more likely to produce improvements if optimized than those parts which merely react to the user's input in his own time.

If the work you are doing in order to optimize code is fun for you, then that's OK, no harm done.

For the record, I would like to point out which scope your optimizations fit into, and where you might want to make specific choices on what to look into.

You could chip away at the code which reacts to user input in user time and you would see no benefit whatsoever (if a mouse click is processed a microsecond faster than without optimization, the user will most definitely not notice the difference), but changes in the interaction between intuition.library and graphics.library/layers.library might have an impact. Assuming that you can measure it, and not just imply that the impact will be there because the number of cycles spent in the modified code is smaller than they used to be.

Quote from: Cosmos;771885
And making thousand supertinysubroutines (3 or 4 mnemonics) called by bsr/jsr is not a sign of a good compilator... Inlining is MUCH faster, really...


:(

The Green Hills 'C' compiler had, for its time, really great data flow analysis capabilities, which allowed it to optimize the operations carried out by a single function. The compiler knew well how the function-local operations were carried out but it did not have an idea of the bigger picture of which function called which.

As far as I can tell Intuition was not written to benefit from function inlining, which would be constrained by the size of the respective function (back then they used preprocessor macros instead). You would have had to mark local functions as being 'static' and let the compiler decide whether inlining them would make sense.

Anyway, as great as the compiler was, it needed help from the programmer to tell it what to do, and this being absent, no function inlining happened. You are asking too much of an optimizing compiler which was a product of its time.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kamelito on August 28, 2014, 12:31:27 PM
Green Hill compiler is still available for 68k.
http://www.ghs.com/products/68k_development.html

I read somewhere that Atari Mint uses a more recent GCC that is producing better code. Maybe we should port it to Amiga?
Kamelito
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: olsen on August 28, 2014, 01:03:24 PM
Quote from: Thorham;771882
Okay, perhaps it's crap because it was compiled from crap C code? This crap had to come from somewhere, and if it's the compiler's fault, then that's not good.
As far as I can tell Intuition is not poorly written. Poorly written code could would lack structure, function and variable names would be poorly chosen and fail to convey their respective purpose, the purpose and intent behind the code as written would be hard to fathom and comments would either be absent, meaningless or wrong. I have seen code like that: I've written it myself.

How could one reasonably hope to measure code quality on such a small scale? The disassembly is of stub code which calls DrawImageState() with two additional parameters (state=IDS_NORMAL, drawinfo=NULL) which are absent in the basic DrawImage() function.

How could the compiler optimize this? Try squeezing blood from a turnip, there is not enough substance here. An optimizing compiler tries to remove redundancies from the flow of control through a function, and how it uses data: it tries to change the implementation of an algorithm without changing the result. There is no control flow to speak of here, it's just reusing function parameters and calling a different function with these. There is no algorithm to change here.

Quote from: Thorham;771882
After all, if such simple code is already crap, then what on earth is it going to do with more complex code?

If it's the programmers fault, then they should've been fired :D
Throw more complex code at the optimizer, and it will get shorter and/or faster, assuming that it can be optimized.

The disassembly of the stub code is a poor example in this context because there is no algorithmic optimization possible (pulling parameters off the stack and pushing them back onto the stack is mandated by how the platform wants this to be done, so this does not count as a fault of the compiler).

Here's the thing: an optimizing compiler allows you to spend more time on getting your code to work correctly and still be readable.

Most of the time, and I'm not making this up, attempting to optimize code is a futile effort. For one thing, optimization requires effort to transform your code, and you need to verify that it still does the job as the original code, just better. This transformation inevitably results in more complex code that is hard to verify as correct.

Put another way, in your attempt to make things better you might not just have to spend a lot of time in getting there, you will probably make things less robust than they were before.

Even if you did succeed, the chances that your change will have any positive impact will be very low. There are rare exception to this, e.g. if the optimization is prompted by prior analysis which exposed the target of the optimization as a bottleneck. The rest of the time you will both have difficulties figuring out which code to optimize and justifying why you spent so much time on trying to optimize it.

Quote from: Thorham;771882
Quote
If you want to critique the quality of the Intuition code, please cast your eye on the meat, bones and nervous system of the beast.
That's going to be hard without the source code, isn't it?
Sure, but so is trying to optimize the code at the instruction level, viewing a translated version of the original 'C' code. At the instruction level the knowledge which would inform the choices the original programmer made in implementing algorithms is hard to fathom.

In this thread the absence of this information was, so far, considered completely beside the point. This thread is more about the challenge and the sport of peephole optimization than about global optimization.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: olsen on August 28, 2014, 01:10:53 PM
Quote from: kamelito;771889
Green Hill compiler is still available for 68k.
http://www.ghs.com/products/68k_development.html

I read somewhere that Atari Mint uses a more recent GCC that is producing better code. Maybe we should port it to Amiga?
Kamelito

Green Hills charges big bucks for the use of the compiler.

Amiga, Inc. (the Los Gatos operation) bought the compiler with complete source code, so that it could be built on the respective workstation (Sun 2 program code does not necessarily run on a Sun 3 workstation, and the other way round).

Incidentally, the Green Hills 'C' compiler used for building the Amiga operating system was written in Pascal.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: itix on August 28, 2014, 01:38:40 PM
Quote from: Cosmos;771831
_DrawImage
move.l   d2,-(sp)
move.l   8(sp),d0
move.l   $C(sp),d1
move.l   $10(sp),d2
clr.l   -(sp)
clr.l   -(sp)
move.l   $1C(sp),-(sp)
move.l   d2,-(sp)
move.l   d1,-(sp)
move.l   d0,-(sp)
bsr.w   _DrawImageState
lea   $18(sp),sp
move.l   (sp)+,d2 ; make the wrong CCR for BenchTrash 1.73
rts

FYI if BenchTrash is assuming CCR is set (unless explicitly documented in autodocs) then it is fault in BenchTrash. (Edit: when reading thread back to beginning it looks like this call was missing return code completely? Or?)

And another note. Now when you have optimized away function setup you still have problem with slow gfx output. What you have achieved is CopyMemQuick() optimization of intuition...
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Thorham on August 28, 2014, 01:54:29 PM
To olsen:

Perhaps you're right, but I'm a 68k coder and when I see crap code like that I can't help but think what I wrote earlier.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 28, 2014, 03:58:40 PM
Quote from: itix;771892
FYI if BenchTrash is assuming CCR is set (unless explicitly documented in autodocs) then it is fault in BenchTrash.  
Yes, it is. There is a new release in Aminet that was fixed. Actually, that discussion is long over, please see above.

Actually, this specific function returns a condition code, not a value.
Quote from: itix;771892
And another note. Now when you have optimized away function setup you still have problem with slow gfx output. What you have achieved is CopyMemQuick() optimization of intuition...

I don't quite understand what you want to say here...
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 28, 2014, 04:01:51 PM
Quote from: Thorham;771893
To olsen:

Perhaps you're right, but I'm a 68k coder and when I see crap code like that I can't help but think what I wrote earlier.

But look, this is exactly the difference between a "coder" and a "software engineer". In essence, the "register-ping-pong" costs pobably like 20-30 cycles per function per call, probably in total around 400 cycles. Consider that in perspective with the amount of cycles you can save by *not* copying a cliprect by an improved algorithm.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kamelito on August 28, 2014, 06:22:42 PM
@Olsen
As they bought it is the owner now being Amiga Inc or Hyperion?
Kamelito
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: itix on August 28, 2014, 07:33:07 PM
Quote from: Thomas Richter;771904
Quote

And another note. Now when you have optimized away function setup you still have problem with slow gfx output. What you have achieved is CopyMemQuick() optimization of intuition...


I don't quite understand what you want to say here...


CopyMemQuick() is perfect example of redundant micro optimization. Assuming that routines are done right, CopyMemQuick() is never faster than CopyMem(). Saving six asm instructions on each CopyMemQuick() call is not worth it.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 28, 2014, 08:16:22 PM
Quote from: itix;771914
CopyMemQuick() is perfect example of redundant micro optimization. Assuming that routines are done right, CopyMemQuick() is never faster than CopyMem(). Saving six asm instructions on each CopyMemQuick() call is not worth it.

No, it depends. The *correct* optimization is to avoid copying memory if you can. Instead, just pass a pointer. However, there are cases where you *must* copy memory, and then of course, the performance impact of the memory copy is dominant in the algorithm. In *that* case, it helps of course to optimize it.

It is really quite simple: Measure where the time is spend in your algorithm. If you have a bottleneck where 80% of the CPU time is spend in 20% of the code, optimize that 20%. If you have to move window on the screen, you have to copy the data - no way around it. You can then either use the blitter (if you can), or use the CPU. Since that's the dominant operation, you should invest your time there to get this specific part fast.

Or to put it into different words: How often are the movem-instructions within CopyMemQuick() called for the average copy? Probably several thousand times. How often is the register-ping-pong used when calling intuition? At most hundred times. See why it makes a difference?

Basic rule of profiling: Measure first. Then optimize.

I've here a super-fast JPEG 2000. Almost everything is in C++. Except the 5% of the code where it really really matters. The code is fast because it is C++ - it allowed constructions where memory is touched as little as possible, keeping the data in cache whenever possible. This required the correct algorithm, and that algorithm was easier to formulate, debug and benchmark in a higher level language. Once that is done, and the hot-spots are understood, the hot-spots that touch a lot of data in a small loop were optimized. The amount of time the code spends in other parts of the code is below 5%, so I don't even bother touching it *except* for getting the data organized correctly so the 95% bottleneck gets its data in an ideal way, namely in the CPU cache.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: olsen on August 28, 2014, 08:25:57 PM
Quote from: kamelito;771911
@Olsen
As they bought it is the owner now being Amiga Inc or Hyperion?
Kamelito

Probably neither... Amiga likely bought the compiler source code under license, and licenses such as these are not necessarily transferrable. If the company ownership changes, or the company goes into liquidation, you might have to talk to the licensor about terms, and you may have to pay a fee in order to continue using the source code.

When ESCOM acquired certain Commodore assets, paperwork and documentation on software licenses, even contracts with publishing companies such as those who made the RKMs and the AmigaDOS manual, were lost. They staid lost, or became more lost when Gateway 2000 acquired patents and stuff from ESCOM.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: olsen on August 28, 2014, 08:31:24 PM
Quote from: itix;771914
CopyMemQuick() is perfect example of redundant micro optimization. Assuming that routines are done right, CopyMemQuick() is never faster than CopyMem(). Saving six asm instructions on each CopyMemQuick() call is not worth it.

You're assuming that CopyMemQuick() was always supposed to leverage an unrolled movem.l loop.

There are notes in the old autodocs which hint that somebody was dreaming about having hardware-accelerated data copying operations available at some point. I take it that this type of hardware actually did exist for 68k Sun workstations, so this wasn't completely unrealistic.

Given how cheap Commodore was, the ambition never resulted in such hardware showing up, though.

I'm speculating: had this hardware existed for the Amiga, it would have hooked into CopyMemQuick().
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: itix on August 28, 2014, 09:02:42 PM
Quote from: olsen;771920
You're assuming that CopyMemQuick() was always supposed to leverage an unrolled movem.l loop.


No, I am assuming CopyMem() is highly optimized just like CopyMemQuick(). If CopyMemQuick() is using better memory copy routine than its CopyMem() counterpart then there is something seriously wrong.

Quote

There are notes in the old autodocs which hint that somebody was dreaming about having hardware-accelerated data copying operations available at some point. I take it that this type of hardware actually did exist for 68k Sun workstations, so this wasn't completely unrealistic.

Given how cheap Commodore was, the ambition never resulted in such hardware showing up, though.

I'm speculating: had this hardware existed for the Amiga, it would have hooked into CopyMemQuick().


I always assumed they meant blitter. DMAing between chip and fast ram could have been nice.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Thorham on August 28, 2014, 09:18:57 PM
Quote from: Thomas Richter;771905
But look, this is exactly the difference between a "coder" and a "software engineer".
Bollocks.

Quote from: Thomas Richter;771905
In essence, the "register-ping-pong" costs pobably like 20-30 cycles per function per call, probably in total around 400 cycles.
I understand that, it's just impossible to look at code like that, and not think how crappy that is, and comment on it.

Quote from: Thomas Richter;771905
Consider that in perspective with the amount of cycles you can save by *not* copying a cliprect by an improved algorithm.
Yeah, the right algorithm. You told me this before, and it was just as obvious then as it is now. You assume again that I don't understand that, while it's an open door of obviousness.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kamelito on August 28, 2014, 09:33:09 PM
Quote from: Thomas Richter;771905
But look, this is exactly the difference between a "coder" and a "software engineer". In essence, the "register-ping-pong" costs pobably like 20-30 cycles per function per call, probably in total around 400 cycles. Consider that in perspective with the amount of cycles you can save by *not* copying a cliprect by an improved algorithm.


I've seen a benchmark of the legacy layers.library vs yours, pretty amazing.
I'm wondering why that library was not optmized like yours back then.
Is all Amiga libraries being profiled and optimized like the layers one?
Is the actual GCC any good at doing optimizations for PowerPC after Apple "departure"?
Kamelito
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kamelito on August 28, 2014, 09:50:49 PM
"You can then either use the blitter (if you can), or use the CPU. Since that's the dominant operation, you should invest your time there to get this specific part fast."

I suppose that in some case you could also use the blitter and CPU in parallel I've seen this for example to clear the screen in some demos. (read demoscene).

"If you have to move window on the screen, you have to copy the data - no way around it."

isn't it possible with the copper to have for each window a copperlist (of course you're limited by the copper resolution for the window positionning/width/height depending on the screen mode used) to avoid copying datas but just changing some values in the copperlist of the moved window?

Kamelito
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: buzz on August 29, 2014, 12:16:11 AM
The arrogant elitism in this thread is really irritating. As though a few think they are the only ones who can develop professionally and know better than everyone else. It links in directly with the out of date attitudes to source too imho. As a retro computing scene, the Amiga scene really stinks sometimes.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: ferrellsl on August 29, 2014, 12:29:37 AM
Quote from: buzz;771934
The arrogant elitism in this thread is really irritating. As though a few think they are the only ones who can develop professionally and know better than everyone else. It links in directly with the out of date attitudes to source too imho. As a retro computing scene, the Amiga scene really stinks sometimes.

Agreed.  And it's a sad commentary about those whom you mention because their egos seem tied to or intertwined with a platform that's been dead for years.  It makes me wonder how they act in person.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 29, 2014, 02:56:02 AM
Quote from: buzz;771934
The arrogant elitism in this thread is really irritating. As though a few think they are the only ones who can develop professionally and know better than everyone else. It links in directly with the out of date attitudes to source too imho. As a retro computing scene, the Amiga scene really stinks sometimes.

None of the knowledge presented here is new, nor my own invention or finding, or in any way over everyone's head. It is really simple, basic stuff, depending on really simple basic math. Actually, one of the first examples that are usually taught is that a super-fast super-optimized bubble-sort will still be slower than a quick-sort in BASIC (or perl, or python) if there is enough data to look at. The "kool koderz" will complain about the slowness of a high-level language, the software engineer will instead understand that the high level code is not even faster, but also easier to maintain, update and bugfix than the super-optimized algorithm. It's a different perspective you take once you have to work "for living" and not just for fun. If there's still time to optimize that, good for you.

Yet, at the same time, I see here people arguing about such elementary truths, and that hurts a lot. It's a matter of education everybody here can simply fix himself, just by making the experiment and taking the experience. I understand that some people here probably haven't, but what I do not understand is the resistance to actually take this as a serious suggestion, not as a matter of arrogance, but as a matter of life experience one still has probably still to make. There is still time to argue afterwards. Actually, I see it pretty much a matter of stubbornness to argue about elementary truths - something that really drives me mad.

If that makes you feel any better: Yes, I started with assembler on the Amiga. However, sooner or later, as your projects grow in size, you'll see that you'll hit a "brick wall" where you create code that requires an amount of maintence to update or improve that you cannot manage anymore. Especially in the "improve" part you'll learn that this often goes beyond micro-optimizations - you'll often find yourself in the position to turn around entire code parts because your architecture did not work as intended.

Once again: Intuition is a very high-level library, with very few elementary calls made a relatively rarely. It really does not matter much how fast or slow that part is. In a sense, you're looking at the wrong end of the picture and should understand instead the high-level  instead of the low level code. I know that's all you see, but I can't help it. Yes, there are probably a couple of things that are wrong in intuition, but nothing seriously so. It's especially not the "register ping-pong" that's wrong. It's a minor annoyance that hurts nobody and that could be avoided by simply recompiling the code, but without giving a measurable benefit. Pronounciation on "measurable". Why do you care about this then in first place?
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 29, 2014, 03:08:53 AM
Quote from: kamelito;771926
I'm wondering why that library was not optmized like yours back then.
Is all Amiga libraries being profiled and optimized like the layers one?
The fact is, that layers *was* actually optimized, that's probably the thing one should understand. It was just optimized for a different goal. That's probably one of the surprises one has to learn, and one of the "take home" lessons from all this discussion.

Yes, surprising, isn't it?

The point is: At the time layers was written, the CPU was slow, the blitter was fast, and chipmem was an expensive resource. Thus, layers was designed with these goals in mind: Use as little buffer memory as possible, probably of the expense of additional data manipulations to be made by the fast blitter. This resulted in an algorithm that uses the double-xor trick to avoid an additional buffer and to copy data between screen and off-screen buffer. Amongst many other decisions, of course. It was the right algorithm.

Nowadays (or rather, ten years ago) things changed: The CPU became fast, the blitter slow, graphics memory was not even reachable by the blitter, so the CPU had to emulate the blitter, and buffer memory became cheap. Thus, it requires a completely different algorithm to make this fast. Avoid double-xor, use extra buffers if necessary to avoid any extra copy operation that would slow down the CPU.

Nobody at CBM back then was overly stupid in creating the slice & dice operation in layers. They just optimized for the "wrong" goal, for today's perspective. The *good* part about layers is that it was written in C, not assembly, so one could take the algorithm apart and replace it by something equivalent, optimized for a different goal.  

That's "software engineering", actually. Consider that you're shooting at a moving target, and that your target might move too fast to make low-level stuff feasible to approach your problem. And within ten years, the hardware was apparently already moving too fast for CBM to take the opportunity to optimize...
Quote from: kamelito;771926
Is the actual GCC any good at doing optimizations for PowerPC after Apple's departure?

I seriously don't know. I don't have enough experience with the PPC to judge. Yes, I did a bit of programming on PPC, but that's not sufficient to make any statements on the compiler quality.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 29, 2014, 03:22:29 AM
Quote from: ferrellsl;771935
Agreed.  And it's a sad commentary about those whom you mention because their egos seem tied to or intertwined with a platform that's been dead for years.  It makes me wonder how they act in person.

Quite nicely actually. Anyhow, it's not about the dead platform I care so much about. I care about engineering practise, or rather, the apparent absence in the minds of some people of it at times. AmigaOs engineering is nothing more than a fairly general example of a wider class of problems you approach when constructing larger projects.

Yes, I'm really serious about "coders" and "engineers". There is a difference, and you should at least try to understand why I'm stressing this difference so much, and what the difference is about. Nothing wrong to start as a "coder", but you should try to conquer new worlds and understand more perspectives as soon as you grow older.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Cosmos on August 29, 2014, 05:18:59 AM
New beta 7 maybe this day...

I removed all 68000/010 support : take a lot of cycles for nothing for me...

There is a big difference between 000/010 and 020+ : I cannot lay good code anymore with all the 000/010 limitations...



:)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: LoadWB on August 29, 2014, 05:40:31 AM
Cosmos, when you talk about being ROMable, can I assume it can be put into flash RAM like on the Deneb?
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Cosmos on August 29, 2014, 05:49:16 AM
Romable = firmwareable = Denebable = epromable = eepromable...

===> http://warpclassic68k.blogspot.fr/2013/01/romability-eng.html (in english)



:)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Thorham on August 29, 2014, 06:30:44 AM
Optimizing that crap code example Cosmos showed is still useful, simply because it's easier to read :)

What would you rather deal with in your source code, this:

Code: [Select]
R_DrawImage
    move.l  d1,-(sp)
    move.l  d0,-(sp)
    move.l  a1,-(sp)
    move.l  a0,-(sp)
    jsr     _DrawImage
    lea     $10(sp),sp
    rts

_DrawImage
    move.l  d2,-(sp)
    move.l  8(sp),d0
    move.l  $C(sp),d1
    move.l  $10(sp),d2
    clr.l   -(sp)
    clr.l   -(sp)
    move.l  $1C(sp),-(sp)
    move.l  d2,-(sp)
    move.l  d1,-(sp)
    move.l  d0,-(sp)
    bsr.w   _DrawImageState
    lea     $18(sp),sp
    move.l  (sp)+,d2 ; make the wrong CCR for BenchTrash 1.73
    rts
Or this:

Code: [Select]
R_DrawImage
    clr.l   -(sp)
    clr.l   -(sp)
    move.l  d1,-(sp)
    move.l  d0,-(sp)
    move.l  a1,-(sp)
    move.l  a0,-(sp)
    bsr.w   _DrawImageState
    lea     $18(sp),sp
    rts
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Georg on August 29, 2014, 07:12:21 AM
Quote from: Thomas Richter;771947

The point is: At the time layers was written, the CPU was slow, the blitter was fast, and chipmem was an expensive resource. Thus, layers was designed with these goals in mind: Use as little buffer memory as possible, probably of the expense of additional data manipulations to be made by the fast blitter.


Don't know. Hidden parts of smart refresh layers may end up being backed up in offscreen bitmaps three times. If there is an installed clipregion and the layer is in BeginUpdate state.
Instead it would have been better to just add some offsetx,offsety fields to cliprect struct so that if layer has clipregion installed and/or is in in beginupdate state the normal "hidden cliprect offscreen bitmaps" can be reused.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 29, 2014, 07:14:33 AM
Quote from: Thorham;771971
Optimizing that crap code example Cosmos showed is still useful, simply because it's easier to read :)

What would you rather deal with in your source code, this:

Nothing. It goes right into SYS:Trashcan. That code is not source code, and its not for reading. I don't maintain code at that level.  
Code: [Select]
 DrawImage(rport, image, xoffset, yoffset)
struct RastPort *rport;
struct Image *image;
int xoffset, yoffset;
{
    D( printf("DI\n") );
    DrawImageState(rport, image, xoffset, yoffset, IDS_NORMAL, NULL);
}
  but at *that* level. That's easy to read, it's not assembly because it is not needed, there are no magic constants, there is even a bit of debugging in it if I should need it, and it's a lot shorter and nicer. Ok, except for the old K&R style C.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Thorham on August 29, 2014, 07:34:15 AM
Quote from: Thomas Richter;771976
Nothing. It goes right into SYS:Trashcan. That code is not source code, and its not for reading. I don't maintain code at that level.
You don't, because you don't write in assembly language. Cosmos is obviously using assembly language, so that shorter, cleaner code is an improvement. Not to mention that he's probably working with a resourced intuition.library. Making the code more readable is important.

Quote from: Thomas Richter;771976
That's easy to read, it's not assembly because it is not needed
Assembly language IS needed when you LIKE assembly language. That's all that's relevant when you're doing something as a hobbyist, that you like what you're doing.

I'll say again: Hobbyists write in assembly language because they like doing that. If you don't like assembly language, then that's perfectly fine.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 29, 2014, 08:20:45 AM
Quote from: Thorham;771977
You don't, because you don't write in assembly language.  
'course I do if have to or want to - if it makes a difference. The mmulib is assembler because it was needed. ViNCEd was assembler because that was what I wanted back then. BenchTrash is also assembler (probably the wrong approach to begin with, given that there was still a bug).  
Quote from: Thorham;771977
Cosmos is obviously using assembly language, so that shorter, cleaner code is an improvement. Not to mention that he's probably working with a resourced intuition.library. Making the code more readable is important.
But as I already said, that's the wrong approach to begin with. If you want to rewrite intuition, you're moving on dangerous ice by taking the disassembly of the original. You don't "remove copyright" by this activity. Instead, reverse engineer from the interface (which is actually well documented). AROS does that - perfectly fine. So why doesn't he contribute there?

You can hardly complain that the code doesn't look like assembler code because that's what it isn't. It is compiler generated code. If you want clean code, start from the sources. If you cannot get the original sources, start from the AROS sources. You're then safe in many perspectives and have the freedom you want. I *really* don't get it, sorry.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: olsen on August 29, 2014, 08:41:05 AM
Quote from: Thorham;771971
Optimizing that crap code example Cosmos showed is still useful, simply because it's easier to read :)

What would you rather deal with in your source code, this:

Code: [Select]
R_DrawImage
    move.l  d1,-(sp)
    move.l  d0,-(sp)
    move.l  a1,-(sp)
    move.l  a0,-(sp)
    jsr     _DrawImage
    lea     $10(sp),sp
    rts

_DrawImage
    move.l  d2,-(sp)
    move.l  8(sp),d0
    move.l  $C(sp),d1
    move.l  $10(sp),d2
    clr.l   -(sp)
    clr.l   -(sp)
    move.l  $1C(sp),-(sp)
    move.l  d2,-(sp)
    move.l  d1,-(sp)
    move.l  d0,-(sp)
    bsr.w   _DrawImageState
    lea     $18(sp),sp
    move.l  (sp)+,d2 ; make the wrong CCR for BenchTrash 1.73
    rts

Or this:

Code: [Select]

R_DrawImage
    clr.l   -(sp)
    clr.l   -(sp)
    move.l  d1,-(sp)
    move.l  d0,-(sp)
    move.l  a1,-(sp)
    move.l  a0,-(sp)
    bsr.w   _DrawImageState
    lea     $18(sp),sp
    rts


Actually, what the DrawImage() stub should do is the following:
Code: [Select]

    include "exec/macros.i"
    include "intuition/imageclass.i"

    section text,code

    xdef    _DrawImageStub

_DrawImageStub:

    movem.l a2/d2,-(sp)
    move.l  #IDS_NORMAL,d2
    move.l  #0,a2
    JSRLIB  DrawImageState
    movem.l (sp)+,a2/d2
    rts

    end

The DrawImage() stub in intuition.library calls the local DrawImageState() function and bypasses the LVO, which means that if you should patch DrawImageState() through SetFunction(), then DrawImage() will not invoke the patched function. I'd call this a bug in intuition.library V40.

Even that bit of code could shortened by taking advantage of the fact that IDS_NORMAL=0, so you could use moveq to fill in d2 and then set a2 to zero by copying d2 into it.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: psxphill on August 29, 2014, 08:43:51 AM
Quote from: itix;771922
No, I am assuming CopyMem() is highly optimized just like CopyMemQuick(). If CopyMemQuick() is using better memory copy routine than its CopyMem() counterpart then there is something seriously wrong.

Why would you assume that? CopyMemQuick() is obviously supposed to be more optimised, because it has the word "Quick" in it.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Thorham on August 29, 2014, 08:51:11 AM
Quote from: Thomas Richter;771978
But as I already said, that's the wrong approach to begin with. If you want to rewrite intuition, you're moving on dangerous ice by taking the disassembly of the original. You don't "remove copyright" by this activity. Instead, reverse engineer from the interface (which is actually well documented). AROS does that - perfectly fine. So why doesn't he contribute there?
That's a good point.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on August 29, 2014, 09:18:26 AM
Quote from: Thorham;771982
That's a good point.

+1

I would integrate any improvements in my distribution, it would help everyone and of course it would be perfectly legal

@Thomas

You see it too much as a engineer but AmigaOS on 68k is completely dead, there will be no development anymore there, noone paying for coordination. AmigaInc. are not interested in it, the same for Hyperion and the old sources sticking legally between both. That developers like you are hindered to help by old contracts just because they have had access to the old sources just show me that this community only has future if we move on with open sources (and there is only Aros) and forget all that were part of the past. For me AmigaOS 68k is dead and future only with Aros 68k. I know that some still think different but I hope people in the 68k community start to change mind in future.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: itix on August 29, 2014, 09:38:00 AM
Quote from: psxphill;771981
Why would you assume that? CopyMemQuick() is obviously supposed to be more optimised, because it has the word "Quick" in it.


Why not optimize CopyMem() ?

Look at this readme (http://aminet.net/util/boot/NewCMQ060.readme) and check benchmarks. Using so called "optimized" CopyMemQuick() only pays off when you are copying small buffers (16 bytes or less) but then if you want really good performance for such small copies it is better inline it.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Cosmos on August 29, 2014, 10:15:01 AM
Quote from: olsen;771980

The DrawImage() stub in intuition.library calls the local DrawImageState() function and bypasses the LVO, which means that if you should patch DrawImageState() through SetFunction(), then DrawImage() will not invoke the patched function. I'd call this a bug in intuition.library V40


There is a lot of "direct" calls with bsr in the intuition.library (R_RemakeDisplay and R_RethinkDisplay for example) and in many other libraries in the Kick 3.1...


Quote from: Itix

Why not optimize CopyMem() ?

Look at this readme and check benchmarks. Using so called "optimized" CopyMemQuick() only pays off when you are copying small buffers (16 bytes or less) but then if you want really good performance for such small copies it is better inline it.


Done since a long time directly in the 68060.library... And better code from Matthey a bit optimized by me (faster lsr instead of btst and only one move16 in the loop...)


:)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 29, 2014, 01:10:32 PM
Quote from: itix;771986
CopyMemQuick() only pays off when you are copying small buffers (16 bytes or less) but then if you want really good performance for such small copies it is better inline it.

Large buffers... But actually, yes, compilers do that. If you run SAS with a high optimization setting, it will inline memory copies if the number of bytes to be copied is small enough. Otherwise, it performs its own copy. gcc does the same. It shouldn't be overly hard to tell the compiler to use CopyMem() if applicable, which again calls CopyMemQuick() when applicable.

For the "generic" type of memory copy you need - copy a structure from A to B - the compiler approach is quite fine. There's not much to be gained to begin with. If your program copies a lot of data, or quite frequently (e.g. you're writing a device and need to copy the user data to a DMA buffer), then you're most likely better off by calling CopyMemQuick() manually (if you can, i.e. proper alignment given) instead of depending on the compiler. Then again, if you *know the size* of the block in advance, you're probably *even better off* to write your own memory copy in a small assembler stub and call this instead.

Thus, after all, CopyMem() and CopyMemQuick() are unfortunately only half as useful as it may seem. If you need a really good memory copy, you're probably writing your own for your specific application anyhow, and if you're happy with the "Ford Escord" of memory copy, just use the one supplied by the compiler.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 29, 2014, 01:20:43 PM
Quote from: olsen;771980
The DrawImage() stub in intuition.library calls the local DrawImageState() function and bypasses the LVO, which means that if you should patch DrawImageState() through SetFunction(), then DrawImage() will not invoke the patched function. I'd call this a bug in intuition.library V40.


I agree. That's at least sub-optimal. Then, however, one shouldn't really depend on patching the function in first place... except if there would be a bug.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: psxphill on August 29, 2014, 01:49:56 PM
Quote from: olsen;771920
Given how cheap Commodore was, the ambition never resulted in such hardware showing up, though.

Commodore poured a load of money into the Amiga before the A1000 launch. They then invested in cost reduction for the A500.
 
 Up until 1987 what they were doing made sense. The problem came in 1988 when AAA was started. It wasn't that they didn't invest any money, what they invested didn't turn into real products.
 
 Finally sense prevailed and AGA was started. While AGA rollout was delayed due to management silliness, the money spent on AAA was wasted with mutually consent.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 29, 2014, 03:15:16 PM
Quote from: psxphill;771990
Commodore poured a load of money into the Amiga before the A1000 launch. They then invested in cost reduction for the A500.

Actually, the Amiga team poured a lot of money into it before it became CBM. The problem is that CBM tried to address the classic "home computer market", and there wasn't much more money to make. They completely failed to establish a business line of computers, something that would have created enough revenue to finance the continuous improvement of their product line. CBM was always short on money because they had only customers that were also short on money - hence the problem.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: buzz on August 29, 2014, 03:22:39 PM
Quote from: Thomas Richter;771943
None of the knowledge presented here is new, nor my own invention or finding, or in any way over everyone's head. It is really simple, basic stuff, depending on really simple basic math. Actually, one of the first examples that are usually taught is that a super-fast super-optimized bubble-sort will still be slower than a quick-sort in BASIC (or perl, or python) if there is enough data to look at. The "kool koderz" will complain about the slowness of a high-level language, the software engineer will instead understand that the high level code is not even faster, but also easier to maintain, update and bugfix than the super-optimized algorithm. It's a different perspective you take once you have to work "for living" and not just for fun. If there's still time to optimize that, good for you.

why are you telling me this ? My point was directly related to the way you are insinuating that you have some sort of exclusivity over being a "software developer", or "engineer" whilst the rest of us are just coders and the way you are delivering your arguments. Also these terms are a little meaningless anyway. There are very poor developers who refer to themselves as "software engineers". I rather like the term coder, and I don't go with your definitions.

Quote from: Thomas Richter;771943
If that makes you feel any better: Yes, I started with assembler on the Amiga. However, sooner or later, as your projects grow in size, you'll see that you'll hit a "brick wall" where you create code that requires an amount of maintence to update or improve that you cannot manage anymore. Especially in the "improve" part you'll learn that this often goes beyond micro-optimizations - you'll often find yourself in the position to turn around entire code parts because your architecture did not work as intended.

I didn't question what language you started with - are you sure you are replying to the right person ? Thanks for the lesson, but I am already aware of maintaining code in large software projects - as are others on this forum.

Quote from: Thomas Richter;771943
Once again: Intuition is a very high-level library, with very few elementary calls made a relatively rarely. It really does not matter much how fast or slow that part is. In a sense, you're looking at the wrong end of the picture and should understand instead the high-level  instead of the low level code. I know that's all you see, but I can't help it. Yes, there are probably a couple of things that are wrong in intuition, but nothing seriously so. It's especially not the "register ping-pong" that's wrong. It's a minor annoyance that hurts nobody and that could be avoided by simply recompiling the code, but without giving a measurable benefit. Pronounciation on "measurable". Why do you care about this then in first place?

I said nothing about this. We of course don't have the source to intuition though (so there is little point in saying it should be maintained from that)

Quote from: Thomas Richter;771943
Yes, I'm really serious about "coders" and "engineers". There is a difference, and you should at least try to understand why I'm stressing this difference so much, and what the difference is about. Nothing wrong to start as a "coder", but you should try to conquer new worlds and understand more perspectives as soon as you grow older.

"Nothing wrong to start as a "coder", but you should try to conquer new worlds and understand more perspectives as soon as you grow older. " - oh do stop it with this cr*p. we are not 14 year olds.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: olsen on August 29, 2014, 03:33:46 PM
Quote from: psxphill;771990
Commodore poured a load of money into the Amiga before the A1000 launch. They then invested in cost reduction for the A500.
 
 Up until 1987 what they were doing made sense. The problem came in 1988 when AAA was started. It wasn't that they didn't invest any money, what they invested didn't turn into real products.
 
 Finally sense prevailed and AGA was started. While AGA rollout was delayed due to management silliness, the money spent on AAA was wasted with mutually consent.

Product development in the Amiga line stagnated and Commodore subsequently began to put more resources into the PC market. At least, this is how it played out in the european market when I was a commercial Amiga developer in the late 1980'ies/early 1990'ies. We were basically ignored by Commodore management, and the scarcity of competetive product in Commodore's lineup made our jobs harder. Well, you know how that turned out: when the PC market contracted, the company was left with little room to make something out of the Amiga technology. In the mean time, the company did a really poor job at promoting their product and developing their market.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: olsen on August 29, 2014, 03:38:45 PM
Quote from: Thomas Richter;771989
I agree. That's at least sub-optimal. Then, however, one shouldn't really depend on patching the function in first place... except if there would be a bug.

Patches do come in handy in the most unexpected ways. For example, the Picasso II, EGS, Retina, CyberGraphX, Picasso96 software made possible what Commodore struggled with for years. SetFunction() can also be very handy for monitoring or performance analysis. However, if the operating system itself does not use the prescribed method for calling operating system functions, it gets harder to make the patches/probes stick...
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 29, 2014, 03:40:32 PM
Quote from: buzz;771995
why are you telling me this ? My point was directly related to the way you are insinuating that you have some sort of exclusivity over being a "software developer", or "engineer" whilst the rest of us are just coders and the way you are delivering your arguments. Also these terms are a little meaningless anyway. There are very poor developers who refer to themselves as "software engineers". I rather like the term coder, and I don't go with your definitions.
I was not implying that *you* were a coder, nor trying to imply that. That was in direct response to somebody calling Cosmos a coder, and it was adequate. I did not intend to make this a statement to the general audience, but only to those that do not understand the difference between an algorithmic optimization, running time, and useless micro-optimizations. If you are an engineer, you'd understand why there's little benefit in performing this art.  
Quote from: buzz;771995
oh do stop it with this cr*p. we are not 14 year olds.

So why do I get then the impression that some persons (ehem) are 14 years old, after all? Look, all the arguing about the register-ping-pong. That is *coder speech*, not developer speech.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Cosmos on August 29, 2014, 03:40:33 PM
Note : I use the word "optimize" but it's not the correct one !

I should use "make simpler" : compilator make (very) complex code, and I just simplify... And it's faster...

After that, most of the time a LOT of "optimizations" must be made for a visible speedup by the users...

It's a very long run...


:)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Cosmos on August 29, 2014, 03:49:16 PM
Upload in few minutes !

 intuition.library v40.86 beta 7 68020+ (101 024 bytes)

  - R_AddClass optimized
  - R_FindClass optimized
  - R_FreeClass optimized
  - R_ObtainGirPort optimized
  - R_ReleaseGirPort optimized
  - R_RethinkDisplay optimized
  - R_RemakeDisplay optimized
  - R_RemoveClass optimized
  - some subroutines called one time inlined
  - a lot of absolute addresses turned relative
  - removed all 68000/010 support
  - 13 512 bytes saved

==> http://leblogdecosmos.blogspot.fr/p/coding.html


:)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 29, 2014, 03:50:52 PM
Quote from: olsen;771997
Patches do come in handy in the most unexpected ways. For example, the Picasso II, EGS, Retina, CyberGraphX, Picasso96 software made possible what Commodore struggled with for years. SetFunction() can also be very handy for monitoring or performance analysis. However, if the operating system itself does not use the prescribed method for calling operating system functions, it gets harder to make the patches/probes stick...

It's a bit delicate, actually. Consider probing, just to make a point. If you patch over DrawImageState() and DrawImage(), the probe would call every call to DrawImage() twice. Is that good or bad? At least, making DrawImage() call back into the intuition interface changes the interface *slightly*. I don't think it is exactly clear whether this is good or bad, it really depends. Currently, V40 does not call back, thus two patches are required. Software might depend on this.

No, I'm not trying to argue against this improvement. I'm just playing the Devil's Advocate why doing so may have some unforseen side effects as it is potentially an interface change.

This being said, I'm not aware of any software that actually does depend on a patch here. All the Gfx patches (shudder) are into gfx, which is pretty much a dirty part of the Os anyhow. The correct approach was ("of course") to replace the entire system right away. It's not that the EGS Spectrum system didn't exist. Just that nobody used it. Backwards compatibility rules in the end.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Oldsmobile_Mike on August 29, 2014, 09:11:09 PM
Quote from: Cosmos;772000
intuition.library v40.86 beta 7 68020+ (101 024 bytes)
 
 Excellent!  Downloading it now.  Thanks for making '020+ version!  :)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: psxphill on August 29, 2014, 10:17:25 PM
Quote from: itix;771986
Why not optimize CopyMem() ?

It can never be as optimised because CopyMemQuick() only works on long word aligned data, while CopyMem() has to work on arbitrarily aligned data.



The following samples show how to use the copying routines.

APTR source, target;

source = AllocMem(1000, MEMF_CLEAR);
target = AllocMem(1000, MEMF_CHIP);
CopyMem(source, target, 1000);

CopyMem() (http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_2._guide/node0342.html) copies the specified number of bytes from the source data region
to the target data region. The pointers to the regions can be aligned on
arbitrary address boundaries. CopyMem() will attempt to copy the memory
as efficiently as it can according to the alignment of the memory blocks,
and the amount of data that it has to transfer. These functions are
optimized for copying large blocks of memory which can result in
unnecessary overhead if used to transfer very small blocks of memory.

CopyMemQuick(source, target, 1000);

CopyMemQuick() (http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_2._guide/node0343.html) performs an optimized copy of the specified number of bytes
from the source data region to the target data region. The source and
target pointers must be longword aligned and the size (in bytes) must be
divisible by four.

Not All Copies Are Supported.
-----------------------------
Neither CopyMem() (http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_2._guide/node0342.html) nor CopyMemQuick() (http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_2._guide/node0343.html) supports copying between
regions that overlap.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: itix on August 29, 2014, 11:33:42 PM
Quote from: psxphill;772029
It can never be as optimised because CopyMemQuick() only works on long word aligned data, while CopyMem() has to work on arbitrarily aligned data.


Only function prologue and epilogue are different. In CopyMem() they are longer, prologue because it must check long word alignment and epilogue because it must check if there are remaining bytes to copy.

 I looked what NewCMQ060 patch does and in CopyMem() patch the prologue is only 6 asm instructions longer than in CopyMemQuick() patch. This is reason why small copies (4-16 bytes) take longer in CopyMem() because it has to execute more instructions before memory copy is started.

But it does not matter because neither CopyMemQuick() is optimal for small copies. It is better than CopyMem() but not the best. It never can be the best.

In fact in general computing it could be better if CopyMem() shared its memcopy routine with CopyMemQuick() to have better chance for L1 instruction cache hit.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: psxphill on August 30, 2014, 06:50:40 AM
Quote from: itix;772032
Only function prologue and epilogue are different. In CopyMem() they are longer, prologue because it must check long word alignment and epilogue because it must check if there are remaining bytes to copy.

You can fall back to CopyMemQuick() in CopyMem() if the data is aligned, but as you say that takes time and you still have to handle the non aligned case.

It should be possible to optimise for small copies too, but identifying the cases for selecting which algorithm has additional overhead. Ideally you should identify the small copy cases first so that the overhead per byte is kept to a minimum. However even calling through the LVO is part of that overhead, so a copy of 4 bytes is never going to be optimal.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 30, 2014, 09:20:30 AM
Quote from: psxphill;772049
You can fall back to CopyMemQuick() in CopyMem() if the data is aligned, but as you say that takes time and you still have to handle the non aligned case.

It should be possible to optimise for small copies too, but identifying the cases for selecting which algorithm has additional overhead. Ideally you should identify the small copy cases first so that the overhead per byte is kept to a minimum. However even calling through the LVO is part of that overhead, so a copy of 4 bytes is never going to be optimal.

It is optimal it is inlined. Actually, any decent compiler will that do automatically for you if the size of the memory block to be copied is known at compile time, including a complete unrolling of the copy if the size is small enough, and probably fall back to a small inlined routine if it is not avoiding the per-call overhead then. At least this is what SAS/C does, and it's quite plausible that this is the best option.  

I'm not clear which programs actually use CopyMemQuick() anyhow - probably the FFS does in case the "Mask" does not fit the target of the memory buffer (i.e. the handling device is "broken" and cannot reach the memory indicated as buffer by the caller). In any event, the impact CopyMem and friends has on performance of your average AmigaOs installation should be quite irrelevant. It would be interesting to see if someone could just set a breakpoint there and measure how often it is used. I suspend "not so often".
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: som99 on August 30, 2014, 11:23:39 AM
Quote from: Cosmos;772000
Upload in few minutes !

 intuition.library v40.86 beta 7 68020+ (101 024 bytes)
:)


Thanks, downloaded and will patch later today :)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: warpdesign on August 30, 2014, 11:31:45 AM
Quote
You see it too much as a engineer but AmigaOS on 68k is completely dead, there will be no development anymore there, noone paying for coordination. AmigaInc. are not interested in it, the same for Hyperion and the old sources sticking legally between both. That developers like you are hindered to help by old contracts just because they have had access to the old sources just show me that this community only has future if we move on with open sources (and there is only Aros) and forget all that were part of the past. For me AmigaOS 68k is dead and future only with Aros 68k. I know that some still think different but I hope people in the 68k community start to change mind in future.
I agree open source is the way. What I don't get is why other Amiga "flavors" do not embrace open source as well. They seem to be so socret & protective, like there were millions to be done with OS4/MOS...
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: matthey on August 30, 2014, 11:48:59 AM
Quote from: Thomas Richter;772058
It is optimal it is inlined. Actually, any decent compiler will that do automatically for you if the size of the memory block to be copied is known at compile time, including a complete unrolling of the copy if the size is small enough, and probably fall back to a small inlined routine if it is not avoiding the per-call overhead then. At least this is what SAS/C does, and it's quite plausible that this is the best option.  

I'm not so sure that "most" compilers will optimize memcpy() for static cases. Most compilers will optimize to some extent small copies implied with '=' which are practically all static sizes. The C memcpy() function is generally optimized for small to medium sized copies and doesn't detect for small static sizes. I have never seen the SAS/C memcpy()  function inlined (and it is poor for the 68040 and awful for the 68060). Vbcc will use assembler inlines by default for memcpy() and the new unreleased version of vbcc has much improved 68000 and 68020 optimized assembler versions of memcpy(). Maybe GCC is smart enough to check for static cases when using memcpy(). Medium to large sized copies are best handled by exec/CopyMem() or exec/CopyMemQuick() if they are patched with CPU specific optimized versions. The new vbcc versions of memcpy() will likely outperform unpatched exec/CopyMem() and exec/CopyMemQuick() for all sizes on the 68040 and 68060. Using an '=' for copies is likely to be the fastest for tiny to small copy sizes with practically all compilers on all 68k processors though.

Quote from: Thomas Richter;772058
I'm not clear which programs actually use CopyMemQuick() anyhow - probably the FFS does in case the "Mask" does not fit the target of the memory buffer (i.e. the handling device is "broken" and cannot reach the memory indicated as buffer by the caller). In any event, the impact CopyMem and friends has on performance of your average AmigaOs installation should be quite irrelevant. It would be interesting to see if someone could just set a breakpoint there and measure how often it is used. I suspend "not so often".

CopyMemQuick() is rarely use by the AmigaOS or any other programs (Scout is one of the few programs). CopyMem() is used extensively by the AmigaOS as well as many programs. The AmigaOS uses many tiny copies (<16 bytes) and it looks like some may be static. CopyMem() may have been used for tiny and small copies because the alignment is unknown and the source originally was for a 68000 where it could crash. It's fastest for tiny sizes to inline unaligned copies on the 68020+. I made a Snoopy (like SnoopDOS) script for CopyMem() and CopyMemQuick() to determine how often, which alignments, which sizes and which programs use these functions. The Snoopy script is available in this archive:

http://aminet.net/util/boot/CopyMem.lha

The script records the uses to memory. Be prepared to break the script after a few seconds from starting or you will run out of memory in less than a minute on the average Amiga. I wouldn't call that kind of use "not so often".
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 30, 2014, 01:37:39 PM
Quote from: matthey;772063
I'm not so sure that "most" compilers will optimize memcpy() for static cases. Most compilers will optimize to some extent small copies implied with '=' which are practically all static sizes. The C memcpy() function is generally optimized for small to medium sized copies and doesn't detect for small static sizes. I have never seen the SAS/C memcpy()  function inlined (and it is poor for the 68040 and awful for the 68060).  
SAS/C certainly inlines memcpy() if you tell it to, but it will not "unroll" it if this is what you mean. I believe it expands into a simple move.b (a0)+,(a1)+ loop, likely non-ideal, but good enough for most cases.  
Quote from: matthey;772063
CopyMem() is used extensively by the AmigaOS as well as many programs. The AmigaOS uses many tiny copies (<16 bytes) and it looks like some may be static. CopyMem() may have been used for tiny and small copies because the alignment is unknown and the source originally was for a 68000 where it could crash. It's fastest for tiny sizes to inline unaligned copies on the 68020+. I made a Snoopy (like SnoopDOS) script for CopyMem() and CopyMemQuick() to determine how often, which alignments, which sizes and which programs use these functions.
Thus, out of curiousity, which programs actually call CopyMem() then after all? It's really nothing that *should* be called if a call can be avoided.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: psxphill on August 30, 2014, 02:04:31 PM
Quote from: Thomas Richter;772058
I'm not clear which programs actually use CopyMemQuick() anyhow - probably the FFS does in case the "Mask" does not fit the target of the memory buffer (i.e. the handling device is "broken" and cannot reach the memory indicated as buffer by the caller).

The device isn't broken if it can't reach all memory. Exec was designed around not copying messages, therefore a device is broken if it does a CopyMem() to get the buffer into ZorroII or chip ram.
 
 It actually sounds like a hardware limitation to me.
 
     Mask=<0xffffffff>  Address Mask to specify memory range that DMA transfers can use at one time with any file system. Use Mask for compatibility with older hard drive systems.
 
 You should be able to achieve what you need with
 
     BufMem Type=<3>  Memory type used for buffers; (0 and 1 = Any, 2 and 3 = Chip, 4 and 5 = Fast).
 
 Although I don't know if you can specify 24 bit fast.
 
 It would make more sense when allocating memory to tell Exec what you were planning on doing with it, so it could allocate memory in the correct range and could also provide protection for it. This would go all the way back to the application that would allocate it's buffers saying it would be passing it to a dos stream, which would make sure the device could access it too.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 30, 2014, 04:05:30 PM
Quote from: psxphill;772066
The device isn't broken if it can't reach all memory. Exec was designed around not copying messages, therefore a device is broken if it does a CopyMem() to get the buffer into ZorroII or chip ram.

Ok, let's be more precise: The *software implementation* is broken if it cannot satisfy the request of the user, or rather, overwrites other memory than the intended one because of a hardware limitation. In the end, the user (or caller) can hardly know all the limitations of the hardware, but the vendor of the hardware can. Thus, any good software implementation of an exec.device which does not know which memory it can reach or not reach, and cannot work around its limitations is broken.

The problem is: You cannot just open a device, perform a DoIO() or SendIO() and expect this to get the data. Now, where do you get the correct memory from to read data into? Answer is: The caller cannot possibly know that. Hence, "broken by design".

CBM fixed that for the trackdisk.device in 2.04. Good devices like the omniscsi are also aware of their limitations and use an additional IO buffer if necessary.

Anyhow, back to topic: Even though this is a possible application of CopyMem(), is that actually where it is used on your system?
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: psxphill on August 30, 2014, 07:51:59 PM
Quote from: Thomas Richter;772072
The problem is: You cannot just open a device, perform a DoIO() or SendIO() and expect this to get the data. Now, where do you get the correct memory from to read data into? Answer is: The caller cannot possibly know that. Hence, "broken by design".

The caller has to know or you'll get terrible performance, hence you provide that when you mount the file system. It's not perfect and should have been handled by asking the devices/libraries/file system what type of memory is acceptable.

By making it not work properly when given incompatible memory it at least forces the developer who is calling the device think about how to solve the problem in the most optimal way (which is likely by allowing the user to specify what type of ram to use as a buffer like the file system does).
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: matthey on August 30, 2014, 11:22:21 PM
Quote from: Thomas Richter;772065
SAS/C certainly inlines memcpy() if you tell it to, but it will not "unroll" it if this is what you mean. I believe it expands into a simple move.b (a0)+,(a1)+ loop, likely non-ideal, but good enough for most cases.


That is possible. I have seen many byte loops like this. It's o.k. for tiny dynamic sized copies only (small static sized copies should be unrolled MOVE instructions). It's not much more costly for small dynamic copies to align the copy and use a longword loop as the vbcc memcpy() inline does (with a byte copy for remaining and unaligned bytes). This is much faster for larger copy sizes at the cost of a little larger code.

Quote from: Thomas Richter;772065

Thus, out of curiousity, which programs actually call CopyMem() then after all? It's really nothing that *should* be called if a call can be avoided.


I believe the biggest use of exec/CopyMem() is the ram disk but I recall the graphics or maybe layers library using it as well. I'm out of town at the moment or I would run the SnoopDOS script and tell you.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: olsen on August 31, 2014, 11:51:36 AM
Quote from: matthey;772087

I believe the biggest use of exec/CopyMem() is the ram disk but I recall the graphics or maybe layers library using it as well. I'm out of town at the moment or I would run the SnoopDOS script and tell you.

"ram-handler" may be among the most effective users of CopyMem(), maybe next to "scsi.device", but if you count the number of calls made to CopyMem() in the source code, "intuition.library" comes out on top. In ROM CopyMem() counts as a space saving measure, whereas on disk the operating system components happily use memcpy(), etc. instead.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: matthey on August 31, 2014, 01:46:43 PM
Quote from: olsen;772111
"ram-handler" may be among the most effective users of CopyMem(), maybe next to "scsi.device", but if you count the number of calls made to CopyMem() in the source code, "intuition.library" comes out on top. In ROM CopyMem() counts as a space saving measure, whereas on disk the operating system components happily use memcpy(), etc. instead.


Yes, I believe there were intutition.library CopyMem() calls also. Maybe even 2nd or 3rd most frequent or most bytes copied. I can't verify or do any statistics right now. Almost all of the AmigaOS CopyMem() calls are less than 1kB with the average size much less. There are calls even when the computer is mostly idle.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Heiroglyph on August 31, 2014, 06:35:28 PM
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.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 31, 2014, 09:20:06 PM
Quote from: psxphill;772083
The caller has to know or you'll get terrible performance, hence you provide that when you mount the file system. It's not perfect and should have been handled by asking the devices/libraries/file system what type of memory is acceptable.

By making it not work properly when given incompatible memory it at least forces the developer who is calling the device think about how to solve the problem in the most optimal way (which is likely by allowing the user to specify what type of ram to use as a buffer like the file system does).

Ok, so let's think this to the very end, will we? If I call a device, I need to know the memory type it is able to handle and allocate that (is there a MEMF flag for every memory type a device needs? As for example, Zorro-II memory on *this* GVP board, or 32-bit memory on the CPU-board?). What if the caller needs the data in other memory regions? For example because it is an audio sample? Or a graphic for the graphics board? Or a program to load into 32-bit board memory? Thus, a caller has to create an off-target buffer, load the data in there and then copy it around.

What if the caller is the filing system? And the target is not in the right memory? Does the filing system has to do the copy? Or does the caller of the dos.library Read/Write routines also have to pass in the right buffer? What if want to read 5 bytes into a buffer I placed on the stack. Do I really need to allocate my own buffer for that and go through an AllocMem?

Or what happens if I want to copy data from device A to device B? Does the copy program have to know the memory requirements of all devices that participate in the copy? And create an off-target buffer in some cases, and not in other cases?  

Either way, you see where I'm getting at. You can't avoid the copy anyhow, and the best place to implement the copy is in the device, which knows *precisely* which type of memory it is able to handle, can obtain such memory by means besides exec (because it maintains the board it handles anyhow), and can perform the copy, in worst case, in the most efficient way since it can allocate the buffer exactly as needed.

Or to put it in a different way: There's a reason why every other operating system I know handles it the way I consider the correct way (off-side buffers for devices that cannot DMA into all regions), only AmigaOs doesn't. The FFS Mask/BufMemType flags are workarounds CBM invented because the trackdisk.device was broken and couldn't work with FFS out of the box. That's really all. Then it became an excuse for lazy device implementations, unfortunately.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 31, 2014, 09:23:18 PM
Quote from: olsen;772111
"ram-handler" may be among the most effective users of CopyMem(), maybe next to "scsi.device", but if you count the number of calls made to CopyMem() in the source code, "intuition.library" comes out on top. In ROM CopyMem() counts as a space saving measure, whereas on disk the operating system components happily use memcpy(), etc. instead.


Thanks, I forgot about RAM: Indeed, it has to copy memory. Strange that intuition uses it such a lot. Yes, I know CBM was tight on ROM space, but not *that* tight. All intuition does is copy a couple of small structures. In the end, a call to CopyMem() costs in best case four bytes (assuming that SysBase is already loaded), whereas a memcpy() costs six bytes (move.b (a0)+,(a1)+,subq.l#1,d0,bne loop). Wow, impressive...

Probably Green Hill C did not optmize this particular case.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on August 31, 2014, 09:32:53 PM
Quote from: Heiroglyph;772126
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.
Or get new bugs because the new, ehem, author doesn't understand why particular choices were made, or at least, cannot read the sources...  
Quote from: Heiroglyph;772126
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.  
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.  

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.

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? Clean room implementation means: Person A will reverse engineer, will provide knowledge (but no code) to person B, who reimplements the interface as found from person A. To my very knowledge, this is a valid and legal approach to my very knowledge (but, IANAL). Actually, intuition interfaces are fully documented, thus not such a big deal. And if you want to ask people about internals, hey, you know where to look for.

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.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on August 31, 2014, 10:31:42 PM
Quote from: Heiroglyph;772126
I see both sides of the argument


welcome back.
;)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on August 31, 2014, 10:48:18 PM
Quote from: Thomas Richter;772136
No. Worse. Actually, most of the stuff should be *removed* from the ROM.

im not exactly in accordance with this statement. yes, a lot of stuff might be moved between rom and disk, but dont forget amiga kickstart plays the role of bios initializing devices available at boot time and sicnce the setups are more various as the genuine it will be the question of flexibility and convenience to have drivers to access at least usb if not sata directly in rom. this as example, since i did that. ;)

Quote

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? Clean room implementation means: Person A will reverse engineer, will provide knowledge (but no code) to person B, who reimplements the interface as found from person A. To my very knowledge, this is a valid and legal approach to my very knowledge (but, IANAL). Actually, intuition interfaces are fully documented, thus not such a big deal. And if you want to ask people about internals, hey, you know where to look for.

exactly.

Quote

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.

not in my eyes, but if so, then its not the community fault. chances were there, for both sides, the enterprises and the consumers. if there was communication it could even actually take off for both. there wasnt. the community takes its path. sorry for those who missed the opportunity.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kolla on August 31, 2014, 11:08:54 PM
Quote from: Thomas Richter;772136
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.


No it isn't "extremely simple". How many times haven't we seen people mess up their setups because suddenly their Amiga booted with old scsi.device and old filesystem? Yes, many of us _do_ build our own updated kickstarts, that we softkick, there are flashable kickstart ROM replacements, we use custom kickstart files for UAE, we use custom kickstart files on FPGA systems. And yes, we do remove things from kickstart too, but certain things just need to go in for the system to be able to boot.

OS3.9 kickstart on my Mimimig, the system is 68000 and there is only 2MB chipram and 1.5MB "slow" RAM available, it's much more efficient to build custom kickstart than to mess around with loadmodule.

(http://kolla.no/minimig-os39.jpg)
(http://kolla.no/minimig-os39-wb.jpg)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Heiroglyph on September 01, 2014, 01:42:04 AM
Quote from: Thomas Richter;772136
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.

Quote

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.

Quote

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.

Quote

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.

Quote

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.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: psxphill on September 01, 2014, 09:26:23 AM
Quote from: Thomas Richter;772134
Ok, so let's think this to the very end, will we? If I call a device, I need to know the memory type it is able to handle and allocate that (is there a MEMF flag for every memory type a device needs?

Generally there is.

Quote from: Thomas Richter;772134
As for example, Zorro-II memory on *this* GVP board, or 32-bit memory on the CPU-board?). What if the caller needs the data in other memory regions? For example because it is an audio sample? Or a graphic for the graphics board? Or a program to load into 32-bit board memory? Thus, a caller has to create an off-target buffer, load the data in there and then copy it around.

I'm not aware that this is a general problem. i.e. a SCSI controller only has ram on it as a convenience to the user for reducing the number of cards required. If there is an additional card that has ram with the same MEMF flag then that is also acceptable (usually 24 bit dma).

I agree that there are some theoretical issues with MEMF and it is also inconvenient as it requires external knowledge and it would have been better if amiga had been forced into providing a better solution. My argument is that having a central system which coordinated memory allocation between components so they are as optimal as possible and only if that all falls down a fallback that allocates buffers is a much better solution than what you propose.

Quote from: Thomas Richter;772134
Or to put it in a different way: There's a reason why every other operating system I know handles it the way I consider the correct way (off-side buffers for devices that cannot DMA into all regions), only AmigaOs doesn't.

AmigaOS is the only one that sends messages without copying them too. I understand your argument, I understand why the other operating systems do it that way. I don't buy that it's the correct way that AmigaOS should work.

Quote from: Thomas Richter;772134
The FFS Mask/BufMemType flags are workarounds CBM invented because the trackdisk.device was broken and couldn't work with FFS out of the box. That's really all. Then it became an excuse for lazy device implementations, unfortunately.

No. The Mask for was a supposed broken hard disk. BufMemType was for trackdisk to avoid copies, not because it was broken. devices not implementing side buffers was on purpose, not because of laziness. AFAIK trackdisk allowing fast ram transfers had more to do with mfm decoding being faster when using the cpus available at the time than with the blitter (due to the number of passes involved with the blitter).

I've been in a similar position to you where I've justified each component doing copies on a framework that I built, but it all ended up being memory hungry and slow. On a further redesign I was able to reverse my decision and the difference was visible.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kolla on September 01, 2014, 09:27:30 AM
Quote from: Heiroglyph;772153

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.


Main purpose of AROS/m68k kickstart really was just to have enough for launching games and demos with WinUAE, and for that it has come a long way.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on September 01, 2014, 10:07:01 AM
Quote from: kolla;772162
Main purpose of AROS/m68k kickstart really was just to have enough for launching games and demos with WinUAE, and for that it has come a long way.


that, and also aros has its own dynamics of development that happen mostly on x86. no wonder, 68k is maintained since not such a long time. it has its advantages, that features of the major platforms become eventually available on 68k, and it has disadvantages since 68k doesnt enjoy so much focus. but generally one gets along with the other, the aros modules improve on the genuine fuctionality while as i observe the developers care very much for backwards compatibility and it has greatly improved since 68k branch become active.

there is still a number of unimplemented features and there is a number of lacking speed optimizations, such as c2p conversions that must take place on planar displays because aros internally handles gfx as chunky afair.

this all will hardly improve if none gets engaged and everybody waits with hands in their pockets. the majority of aros devs is inerested to implement amiga system on fast up to date hardware, which is a reasonable goal, wouldnt try to convince them otherwise. for 68k it was a tradeoff from the start with. so if you want to have regular progress on amiga 68k compatible patform you must contribute to lobby of aros 68k active testers, users and devs. thats it.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on September 01, 2014, 12:23:40 PM
Quote from: psxphill;772161
I'm not aware that this is a general problem. i.e. a SCSI controller only has ram on it as a convenience to the user for reducing the number of cards required. If there is an additional card that has ram with the same MEMF flag then that is also acceptable (usually 24 bit dma).

Unfortunately, that is not true in this generality. For example, there is a batch of A4000 where CBM in their wisdom installed the wrong bus drivers for motherboard RAM (inverting instead of non-inverting). For the CPU, it doesn't make a difference since the data is read and written just "upside down". For DMA, it means that you get all your data inverted from the disk into the RAM. Thus, the only safe destination is really RAM on the card. Yes, surely its broken.
Quote from: psxphill;772161
I agree that there are some theoretical issues with MEMF and it is also inconvenient as it requires external knowledge and it would have been better if amiga had been forced into providing a better solution. My argument is that having a central system which coordinated memory allocation between components so they are as optimal as possible and only if that all falls down a fallback that allocates buffers is a much better solution than what you propose.
Then again, where do you suppose to make the cut? At File system level? At user program level? If you make it at file system level, there is no freaking difference. Wether the FFS copies the data, or the device copies the data makes no difference. The data needs copying anyhow. Broken hardware causes problems. If the user has to copy data, you're putting a lot of burden and responsibility at the user level, and given the general leeway users handle AmigaOs requirements, this does not explicitly help to improve the robustness of the overall system. Leave alone you're also creating problems at interoperability level - POSIX and the C-standard lib do not know anything about memory types, thus any program requiring any type of interoperability would require a C-library layer which performs the copy. One way or another, you cannot get rid of the copy except in exceptionally good circumstances, and *that* is something you could arrange *even though* the device implements a copy if it has to.  

I don't have a problem with a device signalling "oh, by the way, I would work faster if you would align buffers in this specific way". I do have a problem with devices "constructed" the way we find them today "Oh, if you don't allocate memory properly, I will just overwrite some other random stuff and probably hang or crash, depending on my mood..."  
Quote from: psxphill;772161
AmigaOS is the only one that sends messages without copying them too. I understand your argument, I understand why the other operating systems do it that way. I don't buy that it's the correct way that AmigaOS should work.
AmigaOs passes by reference because that's simply the only thing that could reasonably be done back then with the limited resources of the 68K. Other systems had no multithreading at all (Apple, MS) and would require running in circles to create the illusion (MacOs copying entire patch-tables for its system resource to keep programs happy, as in "SetFunction() would be task specific". If you would construct a system nowadays, you would probably just copy the messages from one address space to another, just to make sure that you isolate tasks properly. But that's an entirely different discussion. At least theoretically, message passing by pointers is working. But given that there is not even an interface to query memory requirements of devices makes the current system completely corrupt. The end user simply "has to know" what a device can do, and there is not even a central repository to store such information. It is exclusively used by the filing system, but *other* programs having to access the harddisk somehow have to know the right values "by magic". Or not - and create a disaster.  
Quote from: psxphill;772161
I've been in a similar position to you where I've justified each component doing copies on a framework that I built, but it all ended up being memory hungry and slow. On a further redesign I was able to reverse my decision and the difference was visible.

But we're talking about AmigaOs, and as I already said: At *some* point, the copy has to be made. At file system level, or at device level. The question is just *where*. And the answer is quite obvious: Whoever created the mess must clean up. So it's the device because that's the only point where all the knowledge about constraints and restrictions is known. Hopefully. The filing system or the end user can hardly know all the details.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on September 01, 2014, 04:35:45 PM
Quote from: Heiroglyph;772153
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.



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.



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.



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.



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.


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? The thread is about 68k so we do not talk (or be in interested in) the direction X86 takes. 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. 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.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on September 01, 2014, 04:44:20 PM
Quote from: kolla;772162
Main purpose of AROS/m68k kickstart really was just to have enough for launching games and demos with WinUAE, and for that it has come a long way.


Wawa explained it very good. People (both users and developers) on 68k have to decide what they want, hack around with the old codebase, adding patches that do not really make it better or supporting a new clean platform that makes it easy to integrate patches in the OS (something that already has happened). Of course progress does not happen if people only sit there twiddling thumbs and moan about the situation. If people want future the choice is clear.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Cosmos on September 01, 2014, 05:25:55 PM
Quote from: OlafS3;772187
Wawa explained it very good. People (both users and developers) on 68k have to decide what they want, hack around with the old codebase, adding patches that do not really make it better or supporting a new clean platform that makes it easy to integrate patches in the OS (something that already has happened). Of course progress does not happen if people only sit there twiddling thumbs and moan about the situation. If people want future the choice is clear.

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


:)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on September 01, 2014, 05:32:07 PM
Quote from: Cosmos;772190
No : we need only one direction, and all together... And the RIGHT direction (success), not the many dead-ends...

Yeah, very funny. Do you decide what the right direction is? Or to put it into a different perspective: Consider it becomes open source: Then there is no way to "prevent a wrong direction" because everybody can branch.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: psxphill on September 01, 2014, 06:02:03 PM
Quote from: Thomas Richter;772169
But we're talking about AmigaOs, and as I already said: At *some* point, the copy has to be made. At file system level, or at device level. The question is just *where*. And the answer is quite obvious: Whoever created the mess must clean up.

Your solution is not obvious if you want the best speed. Forcing everything in the system to take copies is the worst solution for performance and for the sanity of the device developers.

A good solution would allow you to stream data from a file on a hard disk into memory on a sound card without any cpu copying involved ever with the hard disk device and the sound card device negotiating how to do it through an exec api. If copying was required then it would be exec that would do it.

Quote from: Thomas Richter;772169
Then again, where do you suppose to make the cut? At File system level? At user program level? If you make it at file system level, there is no freaking difference. Wether the FFS copies the data, or the device copies the data makes no difference.

Why do you need to copy the data? If you're streaming data then buffering it is pointless. If you've told the file system to buffer your file then it makes sense for the file system to take copies, but that should be optional.
 
Quote from: Thomas Richter;772169
Unfortunately, that is not true in this generality. For example, there is a batch of A4000 where CBM in their wisdom installed the wrong bus drivers for motherboard RAM (inverting instead of non-inverting). For the CPU, it doesn't make a difference since the data is read and written just "upside down". For DMA, it means that you get all your data inverted from the disk into the RAM. Thus, the only safe destination is really RAM on the card.

I've not heard about this. Any zorro transfer into motherboard ram (chip and fast) is broken? That definitely would require the type of system I'm proposing as it's the motherboard that is broken and making every device avoid dma'ing into motherboard ram is a horrible idea.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Minuous on September 01, 2014, 06:34:35 PM
Quote from: wawrzon;772164
aros modules improve on the genuine fuctionality while as i observe the developers care very much for backwards compatibility


AROS is no solution, it is still missing functionality that was in OS3.5 15 years ago...
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Mazze on September 01, 2014, 06:37:25 PM
Quote from: Minuous;772197
AROS is no solution, it is still missing functionality that was in OS3.5 15 years ago...

Luckily it's Open Source. That gives everyone the possibility to implement missing features.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on September 01, 2014, 07:47:18 PM
Quote from: psxphill;772193
Your solution is not obvious if you want the best speed. Forcing everything in the system to take copies is the worst solution for performance and for the sanity of the device developers.
I'm not forcing to make copies. I'm requiring that devices provide the data where the user requested them. If the device cannot copy the data into the target (via DMA or otherwise), then it must be copied. But only then. Which option is the best depends on the device.  
Quote from: psxphill;772193
A good solution would allow you to stream data from a file on a hard disk into memory on a sound card without any cpu copying involved ever with the hard disk device and the sound card device negotiating how to do it through an exec api. If copying was required then it would be exec that would do it.
How can it? And why should exec do it? And when should it do it?  
Quote from: psxphill;772193
Why do you need to copy the data?
Because the target memory might not be reachable by the device. Haven't we had this before? If the user requested data in motherboard mem, but DMA into motherboard mem is broken, then on the way from the device through the FFS to the user *some* component must copy the data (but only then). You can put the burden on the user program (bad, because every program has to reimplement the same logic), the filing system (right now, bad, because the filing system does not know the requirements of the device) or the device itself. Take your poison.

I'm not suggesting that everything must be copied. I'm saying that a device should make sure that, by whatever means, the data ends up where the user requested it. And not "depending on the mood of the device" somewhere completely else, like the trackdisk device did. If the only means is to copy the data, so might it be. Another option would be be to fall back to PIO...  
Quote from: psxphill;772193
I've not heard about this. Any zorro transfer into motherboard ram (chip and fast) is broken?
On this specific series, yes. It's documented in the Guru-ROM manuals, if you care. PIO works (CPU pulls from Zorro are ok), DMA does not (if the device initiates the transfer).  
Quote from: psxphill;772193
 That definitely would require the type of system I'm proposing as it's the motherboard that is broken and making every device avoid dma'ing into motherboard ram is a horrible idea.

No, not every device, that's the point. If the device sits on the CPU board, it can DMA into the CPU board memory fine. The Guru-ROM takes such decisions, actually. The CPU can do the rest if required. One way or another, if the target buffer requested by the user is somewhere in chipmem, there is no other way of doing it - some system component has to copy the data on such a system. The only question is: Which? And which component has enough information to initiate the ideal method of getting data from A to B. (DMA,PIO,Copy). If you ask me, it's surely not the filing system that can.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on September 01, 2014, 07:53:51 PM
Quote from: Cosmos;772190
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.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Heiroglyph on September 01, 2014, 10:57:02 PM
Quote from: OlafS3;772185
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.

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

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

Quote
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.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Minuous on September 02, 2014, 01:38:49 AM
Quote from: Thomas Richter;772203
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.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: biggun on September 02, 2014, 05:56:48 AM
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?
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: psxphill on September 02, 2014, 07:07:28 AM
Quote from: Thomas Richter;772201
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.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: psxphill on September 02, 2014, 07:11:39 AM
Quote from: Heiroglyph;772211
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.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on September 02, 2014, 09:44:12 AM
Quote from: Minuous;772217
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.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on September 02, 2014, 09:49:30 AM
Quote from: psxphill;772223
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).
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on September 02, 2014, 10:47:30 AM
Quote from: psxphill;772224
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.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: bloodline on September 02, 2014, 10:54:22 AM
Quote from: psxphill;772224
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.

Quote

 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.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: itix on September 02, 2014, 11:31:00 AM
Quote from: psxphill;772223
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?
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: warpdesign on September 02, 2014, 01:55:10 PM
Quote
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.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on September 02, 2014, 03:55:03 PM
Quote from: Minuous;772197
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.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on September 02, 2014, 03:56:10 PM
Quote from: warpdesign;772237
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.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on September 02, 2014, 04:04:19 PM
Quote from: Heiroglyph;772211
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.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: eliyahu on September 02, 2014, 06:55:52 PM
Quote from: OlafS3;772240
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
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on September 02, 2014, 07:58:49 PM
Quote from: eliyahu;772246
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


I can only document regarding 68k branch, AROS X86, ARM and so on is different. But yes I can (and partly already have). I will try to update that (expecially regarding programmers).
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Minuous on September 02, 2014, 09:33:25 PM
Quote from: Thomas Richter;772226
Where did you get this nonsense from? Of course they do.

I got it from Ben Hermans' mouth. You can read the interview here: https://web.archive.org/web/20041020081420/http://www.swaug.org.uk/int010402.html

The relevant part is:

"SWAUG: Has Haage&Partner given you access to OS3.9 source code to be used in OS 4.0?
BH: No."

Obviously they have OS4.1 source code, which is what I assume you are referring to. However, that is not going to be very useful for people who are targetting Classic Amigas, even if they were willing to share it which I very much doubt. They've also shown no inclination to release the OS3.1 sources which they also hold. AFAICT there is no legal impediment to it but IANAL.

Quote from: OlafS3
What exactly is missing? And again if you talk about 68k you can (almost) replace everything with original 68k libraries.

Last time I checked, it was/is missing the entire official AmigaOS GUI (ie. ReAction), as well as some less important components. I suppose those files can be copied over from OS3.9. But in that case, why not just use the proper OS3.9 instead rather than some mishmash of AROS+OS3.9?
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on September 03, 2014, 07:16:19 AM
Sorry, yes, you are right, the H&P contributions are indeed missing. That was under a different contract, and unless authors contributed individually to Hyperion, the sources stayed at the authors, including 3.9. It is mostly reaction that's missing, and the updated Os components that are based on it (Preferences for example). Unfortunately, some of them are pretty buggy - ScreenPrefs crashed me quite a lot.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on September 03, 2014, 08:38:00 AM
Quote from: Minuous;772249
Last time I checked, it was/is missing the entire official AmigaOS GUI (ie. ReAction), as well as some less important components. I suppose those files can be copied over from OS3.9. But in that case, why not just use the proper OS3.9 instead rather than some mishmash of AROS+OS3.9?

reaction isnt particularly necessary, the only software i can recall testing on aros, that needed its classes was aweb. aros contains few appropriate rewrites of those classes and the rest you can obtain from the internet, afair from the class act download page to be precise.

now, aros doesnt provide everything, for instance proper installer tool is missing in c:, but you can just download the commodore version from aminet and put it there. on genuine amiga aros user has enormous advantage against aros x86, that you can use and fill the gaps with genuine amiga software and libraries. for instance you can just use the missing mui classes under zune. i see it definitely as an advantage, not as handicap. aros provides free and open source base to build an amiga compatible system and run amiga software as well as aros software that is not available for amiga (such as aros owb for  example). even where its still bugy, slow or incomplete, it comes with the sources and can be fixed and improved.

beyond that aros contains a lot of components that were missing from the genuine amiga os, eventualla up till 3.9 out of the box. there is a handy editor, not a memacs, you can move the windows off the screen without patching the rom with loadmodule. it contains a unified cpu library that automatically loads appropriate parts of it with setpatch after recognizing the cpu at boot time, and therefore the same installation will work on every hardware without messing with 060 or 040 libraries that might left an inexperienced user confused with not bootable or instable system, wondering whats up.

seriously, i dont understand all these complaints.. with the genuine amiga you had to get and install even mui separately, in contrary to where you have zune with basic set of libs. the system was at bare minimum after installation, yet nobody bitches about this. but when aros is missing some libs and classes, it is the reason to put it completely down and refuse to use it?
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on September 03, 2014, 05:26:22 PM
Quote from: Minuous;772249
I got it from Ben Hermans' mouth. You can read the interview here: https://web.archive.org/web/20041020081420/http://www.swaug.org.uk/int010402.html

The relevant part is:

"SWAUG: Has Haage&Partner given you access to OS3.9 source code to be used in OS 4.0?
BH: No."

Obviously they have OS4.1 source code, which is what I assume you are referring to. However, that is not going to be very useful for people who are targetting Classic Amigas, even if they were willing to share it which I very much doubt. They've also shown no inclination to release the OS3.1 sources which they also hold. AFAICT there is no legal impediment to it but IANAL.



Last time I checked, it was/is missing the entire official AmigaOS GUI (ie. ReAction), as well as some less important components. I suppose those files can be copied over from OS3.9. But in that case, why not just use the proper OS3.9 instead rather than some mishmash of AROS+OS3.9?


Aweb needs classact not reaction and is easy to include

OS3.9 is suddendly free and the source codes available? Really? Please show me the link? When you are not able to then I do not understand what you are saying. I am a little nerved of such comments, I think most try to find reasons not do anything. The 68k community has the chance to get a successor for AmigaOS, if they are not interested I am fine with it because I can use it very good on UAE, BTW emulated environments will be more important than the "real" ones that many here prefer in my view. So I will see in near future if there is interest, if not I will not push anything in that direction anymore. I am the same opinion as Wawa, the reasons not to do anything on Aros are strange, to say it politely and sound to me more like excuses why people do not want to contribute.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on September 03, 2014, 06:00:51 PM
@olaf
actually its not about doing anything but of a choice of options. minous has chosen the option of inoficial boing bags and asm patching, if im correct. in short therm it is probably more rewarding option, but it is a matter of opinion. once one invested enough effort in something you dont want to resign on it of course.

which brings me to another argument in favor of aros. boing bags are impossible to legally be distributed in one piece and demand experience with patching. people frequently mess up their systems. this disadvantage doesnt exist on aros. you just decompress the iso over to your harddisk and you should be ready to go.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kolla on September 03, 2014, 06:48:50 PM
I rememeber resource.library being rather critical in OS3.9.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Minuous on September 03, 2014, 10:44:11 PM
Quote from: wawrzon;772265
reaction isnt particularly necessary, the only software i can recall testing on aros, that needed its classes was aweb. aros contains few appropriate rewrites of those classes and the rest you can obtain from the internet, afair from the class act download page to be precise.

If you're aiming to do a proper job of replacing an OS, it is indeed necessary to support all the standard functionality of what you are replacing. This should surely be the first priority, before wasting time doing non-standard AROS-only extensions and crapplets such as a new editor when there is already a perfectly functional editor in OS3.9, not to mention dozens available on Aminet. I don't think it's appropriate to make these kinds of value judgements on the necessity of various components which are already official parts of the OS and hence are depended on by third-party applications. The fact is, ReAction is part of the OS, is used by various components of the OS and third-party applications. (Not just AWeb either.) Certainly more necessary than an unofficial one that was never part of the OS and which isn't used by OS components.

BTW ClassAct files are generally earlier versions than the corresponding ReAction files, and are missing functionality that is offered by the ReAction files. So just downloading them from Aminet is not necessarily enough.

Quote
now, aros doesnt provide everything, for instance proper installer tool is missing in c:, but you can just download the commodore version from aminet and put it there.

In that case, why not just use the official version of *everything*, no need for AROS at all then.

Quote
Even where its still buggy, slow or incomplete, it comes with the sources and can be fixed and improved.

Development tends to be random, presumably it is more interesting for the devs to expand the system in non-standard ways and ignore the missing functionality. Even 15 years later...

Quote
with the genuine amiga you had to get and install even mui separately, in contrary to where you have zune with basic set of libs.

Well, of course. MUI has never been part of AmigaOS. AmigaOS already has a GUI system and it isn't MUI. So I'm not sure why you would put MUI into AROS instead of the official GUI system.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on September 03, 2014, 11:17:03 PM
Quote from: Minuous;772294
If you're aiming to do a proper job of replacing an OS, it is indeed necessary to support all the standard functionality of what you are replacing. This should surely be the first priority, before wasting time doing non-standard AROS-only extensions and crapplets such as a new editor when there is already a perfectly functional editor in OS3.9, not to mention dozens available on Aminet. I don't think it's appropriate to make these kinds of value judgements on the necessity of various components which are already official parts of the OS and hence are depended on by third-party applications. The fact is, ReAction is part of the OS, is used by various components of the OS d third-party applications. (Not just AWeb either.) Certainly more necessary than an unofficial one that was never part of the OS and which isn't used by OS components.
first of all there might be replacements on aminet without proper sources, which is my assumption, secondly aros aims officially at full source compatibility with os 3.1 for starters, whats happens beyond is just what the devs have fun to do, which is perfectly legitimate with me. whoever is not satisfied with the approach may contribute themselves, this is not a guarantee on non open approach.

Quote
BTW ClassAct files are generally earlier versions than the corresponding ReAction files, and are missing functionality that is offered by the ReAction files. So just downloading them from Aminet is not necessarily enough.
has not made any difference so far when trying to run any reaction app on aros. care to name me one that doesnt work that way?


Quote
In that case, why not just use the official version of *everything*, no need for AROS at all then.
have i not answered that before? aros is for convenience to have the complete system out of the box, but not the whole aminet. if you find the sources for important component it can be included in contribs, otherwise just use it for free under aros 68k.


Quote
Development tends to be random, presumably it is more interesting for the devs to expand the system in non-standard ways and ignore the missing functionality. Even 15 years later...
true. for whatever amiga or non amiga development, proprietary or open, but with an open approach you are able to compensate for what you miss.

Quote
Well, of course. MUI has never been part of AmigaOS. AmigaOS already has a GUI system and it isn't MUI. So I'm not sure why you would put MUI into AROS instead of the official GUI system.
reaction nor class act was not official with 3.1, aros aims at. and it can be easily substituted on 68k qith freely available binaries. there is no apps i can tjink of using it. mui ismuch more an important framework for instance for mail, rss, web clients and a lot mpre and aros zune allows to run them just fine from what i have been testing. i dont recall an reaction app i needed that did nt run on aros 68k, again, care to name one?
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Gulliver on September 04, 2014, 12:57:35 AM
But then, have you actually run aros on real Amiga hardware?

It sucks horribly (unless you are using a 68060 with graphics card and plenty of ram), and that is why most real Amiga users still prefer AmigaOS 3.1, 3.5 and even 3.9.

Aros seems it is the way forward for 68k, but then it also seems that it never reaches that desired state to even replace AmigaOS 3.1 efficiently.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: saimon69 on September 04, 2014, 01:35:36 AM
@Gulliver
Well if nobody works on doing the feature is hard to see them implemented; it is not like in an official OS where all is provided when ready, nor is like in Linux where there are several hundred devs -paid and not: whether we are talking of AROS or not, the Amiga and NG ecosystem is pretty small and there are just few knowledgeable devs working in lot of stuff, not necessarily useful or not immediately...
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Minuous on September 04, 2014, 05:23:36 AM
Quote from: wawrzon;772295
first of all there might be replacements on aminet without proper sources, which is my assumption, secondly aros aims officially at full source compatibility with os 3.1 for starters, whats happens beyond is just what the devs have fun to do, which is perfectly legitimate with me. whoever is not satisfied with the approach may contribute themselves, this is not a guarantee on non open approach.

Why pick an arbitrary obsolete version like V3.1 and not, for example, V1.1? Seems pretty random. I don't see what's so special about OS3.1.

Quote
has not made any difference so far when trying to run any reaction app on aros. care to name me one that doesnt work that way?

Report+ and MCE, for example, require BB1 versions of some ReAction components as they use some of the newer functionality.

Quote
aros is for convenience to have the complete system out of the box, but not the whole aminet.

OS3.1 never included MUI anyway so I don't see the reasoning behind having it in AROS. If it's missing Installer then it's hardly a "complete system out of the box", even for an OS3.1 clone.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Terminills on September 04, 2014, 05:55:07 AM
Quote from: Minuous;772304
Why pick an arbitrary obsolete version like V3.1 and not, for example, V1.1? Seems pretty random. I don't see what's so special about OS3.1.


Aros predates 3.5 by 3-4 years.  Therefore it makes sense for it to be based on 3.1 and not 3.5 or 3.9.  Otherwise would that mean today we should be basing it on 4.1+?
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Gulliver on September 04, 2014, 06:43:02 AM
Yet, after all these years, aros doesnt manage to implement the functionality AmigaOS had back in 1993. Blame whoever you want, but AmigaOS 3.1 was not even top technology back then, and it is a shame it cant be accomplished in 2014.

So my point is that aros is full of really good objectives, but lacks in its poor execution as a project.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: olsen on September 04, 2014, 07:14:53 AM
Quote from: Minuous;772304
Why pick an arbitrary obsolete version like V3.1 and not, for example, V1.1? Seems pretty random. I don't see what's so special about OS3.1.


Trick question: what's the big difference between programming for Kickstart/Workbench 1.1 and 3.1, other than the number in front of the dot? The APIs evolved big time between 1.1 and 3.1, putting much more power into the hands of the programmer. What required a lot of inside knowledge and fiddling with barely documented data structures back in 1985 became easier to achieve and was a lot less error prone, too. Documentation and example code arguably became better, too, although much of the original documentation was quite good already (even though it was not exactly complete).

Also, the operating system became more robust, thanks to tons of bugs getting found and fixed when QA tools such as "The Enforcer" were widely used within Commodore engineering (which may not be relevant for AROS, though).
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Kronos on September 04, 2014, 07:57:53 AM
Quote from: Minuous;772294

Well, of course. MUI has never been part of AmigaOS. AmigaOS already has a GUI system and it isn't MUI. So I'm not sure why you would put MUI into AROS instead of the official GUI system.


Well maybe you should take a step back to see what really has happened:

Hack&Patch were doing 3.5/9 on the cheap, scamming contributors left and right.
Doing those few actually new tools in 3.5/9 based on just plain GadTools+BOOPSI was no option.
Stuntz was to smart to give MUI away for free.

So they had to find a 2nd class GUI system that could be aquirred at next to 0 cost, and hell did ClassAct fill that bill.

The reality even today is that it is 100% possible (and not even hard) to setup a useable Amiga without ever touching ClassAct/ReAction. Try the same without useing MUI (yes even on OS4)...
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on September 04, 2014, 08:07:54 AM
Quote from: Gulliver;772297
But then, have you actually run aros on real Amiga hardware?

It sucks horribly (unless you are using a 68060 with graphics card and plenty of ram), and that is why most real Amiga users still prefer AmigaOS 3.1, 3.5 and even 3.9.

for everyday tasks, yes. but this is a vicious circle. too few users or rather testers create too low demand on improvements and deliver too few competent bug reports and the developers go for things that create more interest like ppc emulation on uae.
Quote

Aros seems it is the way forward for 68k, but then it also seems that it never reaches that desired state to even replace AmigaOS 3.1 efficiently.


maybe, maybe not. the chance is there, or at least a chance of an improved but legally safe hybrid system such as the one olaf is working on. people must get at least a little engaged to push it forward in order for it to become actually usable alternative on genuine hardware. none will come and serve you full dish for free without the customers cooperation as it was the case when you first bought your amiga from a commercial company back then.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on September 04, 2014, 08:21:18 AM
Quote from: Minuous;772304
Why pick an arbitrary obsolete version like V3.1 and not, for example, V1.1? Seems pretty random. I don't see what's so special about OS3.1.
aros aims at maximal compatibility with the 1.x-3.x range. 3.1 is a reference point, but measures to allow for execution of software that depends of exclusive features of kickstarts since 1.x are being implemented. tonic surely could better comment on this. im only a noob tester. why not ask him on eab?

Quote
Report+ and MCE, for example, require BB1 versions of some ReAction components as they use some of the newer functionality.
i seem to remember to try out report+ but i will try to check those if time and patience allows.
Quote
OS3.1 never included MUI anyway so I don't see the reasoning behind having it in AROS. If it's missing Installer then it's hardly a "complete system out of the box", even for an OS3.1 clone.
it was quite a reasonable practical decissions in my eyes. there is much more important and complex apps written for mui than for reaction. those could be easily ported having a mui replacement. if im not mistake currently i observe preparations for odyssey, but there is a number of mui dependant software i can just use on aros68k in its genuine amiga version. lets name yam and simple mail, ibrowse and digibooster almost work..
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on September 04, 2014, 08:27:11 AM
Quote from: Gulliver;772308
Yet, after all these years, aros doesnt manage to implement the functionality AmigaOS had back in 1993. Blame whoever you want, but AmigaOS 3.1 was not even top technology back then, and it is a shame it cant be accomplished in 2014.

So my point is that aros is full of really good objectives, but lacks in its poor execution as a project.
which of amigoid systems is top technology by todays standards? aros is probably least polished on the surface, but it has technical advantages in comparison with mos and os4 in some fields and most certainly in comparison with a bare 3.1 setup. you might simply install a 3.1 system from your floppies and then decompress an aros nightly to another disk on the same machine to try them side by side.you will notice the difference but you will probably notice too that aros will likely run most of the programs ou can run on 3.1 out of the box. in other to run others you will need to download libraries and classes from internet exactly as you need to do on 3.1.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: psxphill on September 04, 2014, 08:41:06 AM
Quote from: itix;772231
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?

If you're asking the user for the usbtrackdisk.device name and unit then why not ask them for the type of ram?

Asking both devices is the only way to get the most optimal solution. By telling exec what things need to be able to access the ram then you can implement memory protection at the same time.

Or you could just copy the data using memcpy and pretend it's the best way.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on September 04, 2014, 09:06:22 AM
Quote from: Gulliver;772308
Yet, after all these years, aros doesnt manage to implement the functionality AmigaOS had back in 1993. Blame whoever you want, but AmigaOS 3.1 was not even top technology back then, and it is a shame it cant be accomplished in 2014.

So my point is that aros is full of really good objectives, but lacks in its poor execution as a project.


You talk in general phrases... what is missing in your view and I will make a screenshot showing you it running on my distribution. Perhaps you never used it, haven´t you? I saw this already often in the community, the less experience the stronger are the opinions. As I said Aros 68k is really the last chance for the 68k community to get a working AmigaOS successor that is in development. If people are not interested in it and prefer fiddling around with their aging AmigaOS then it is ok for me and I do not need to invest time in anything for real hardware and can concentrate on emulation (what is enough for me personally).
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kolla on September 04, 2014, 09:09:45 AM
Hm, AROS does have "installer", evindently.

http://kolla.no/aros-installer.jpg
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on September 04, 2014, 09:09:58 AM
Quote from: Gulliver;772308
Yet, after all these years, aros doesnt manage to implement the functionality AmigaOS had back in 1993. Blame whoever you want, but AmigaOS 3.1 was not even top technology back then, and it is a shame it cant be accomplished in 2014.

So my point is that aros is full of really good objectives, but lacks in its poor execution as a project.


A simple question to you... What functionality is missing in my distribution?
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on September 04, 2014, 09:16:15 AM
Quote from: kolla;772319
Hm, AROS does have "installer", evindently.

http://kolla.no/aros-installer.jpg


On 68k you can use a standard installer by copying the file in C. I use the official installer from aminet and it perfectly works. I only include it not in my distribution because of legal reasons.

BTW examples of GUI toolkits in Aros 68k

http://www.aros-platform.de/html/gui_toolkit.html
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Ball000 on September 04, 2014, 09:22:47 AM
Quote from: kolla;772319
Hm, AROS does have "installer", evindently.

http://kolla.no/aros-installer.jpg


If you're satisfied with it being able only to run the provided demo (and even then, it sometimes crashes...), then yes. Really, I would guess it's only about 50% finished and still needs a lot of work. But perhaps you were kidding?

Until some developer is interested in finishing it, I would advise people who need those functionalities to use a shell script of course: it is quite stable and evolved on ABIv1 and ABIv0-on-trunk, and so is able to make many tests on installed files and the system in general, and even allows quite comfortable interactions with the user.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on September 04, 2014, 09:33:17 AM
Quote from: Ball000;772322
If you're satisfied with it being able only to run the provided demo (and even then, it sometimes crashes...), then yes. Really, I would guess it's only about 50% finished and still needs a lot of work. But perhaps you were kidding?

Until some developer is interested in finishing it, I would advise people who need those functionalities to use a shell script of course: it is quite stable and evolved on ABIv1 and ABIv0-on-trunk, and so is able to make many tests on installed files and the system in general, and even allows quite comfortable interactions with the user.


What are you talking about? I really use it so i say you tell not the truth or your experience is based on old nightly builds. Nightly builds are NOT what people use or should use and are misleading. They are a backbone for testing new features for devs, not more not less. For users and application devs are distributions.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on September 04, 2014, 09:37:38 AM
Quote from: OlafS3;772323
What are you talking about? I really use it so i say you tell not the truth or your experience is based on old nightly builds. Nightly builds are NOT what people use or should use and are misleading. They are a backbone for testing new features for devs, not more not less. For users and application devs are distributions.


you did not understand. he is talking about the aros installer utility, and is being correct. therefore we on amiga 68k use the commodore installer. would be cool to have aros installer finished, but since there is free available 68k utility i dont consider it a priority. the x86 is naturally missing on these functionalities, but then to my knowledge there is currently no x86 software that requires it.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on September 04, 2014, 09:39:47 AM
Quote from: Ball000;772322
If you're satisfied with it being able only to run the provided demo (and even then, it sometimes crashes...), then yes. Really, I would guess it's only about 50% finished and still needs a lot of work. But perhaps you were kidding?

Until some developer is interested in finishing it, I would advise people who need those functionalities to use a shell script of course: it is quite stable and evolved on ABIv1 and ABIv0-on-trunk, and so is able to make many tests on installed files and the system in general, and even allows quite comfortable interactions with the user.


Some raytracer I have tested on it:
http://www.aros-platform.de/html/raytracing.html

But of course not even demos are running. Perhaps I am just daydreaming and making screenshots of it
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on September 04, 2014, 09:51:15 AM
Quote from: wawrzon;772324
you did not understand. he is talking about the aros installer utility, and is being correct. therefore we on amiga 68k use the commodore installer. would be cool to have aros installer finished, but since there is free available 68k utility i dont consider it a priority. the x86 is naturally missing on these functionalities, but then to my knowledge there is currently no x86 software that requires it.


Yes I know what he was talking about. But we are talking about 68k here and he is saying it is 50% because of important parts missing and example here is installer that can be easily solved. I read that people on MorphOS and AmigaOS use the original 68k libs to add AREXX, then both are only 50% finished too? People here partly are talking nonsense, based on non-knowledge or halftrue based on very old experiences to have reasons to stay where they are and not needing to contribute. That may sound a little harsh but that is my view in the meantime.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Ball000 on September 04, 2014, 10:15:14 AM
Sorry Olaf I may not have been clear. I was only answering to Kolla's post and his screen-shot of AROS' installer. I am totally convinced that your distribution is perfectly usable on emulators, and polished even. Congratz BTW.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on September 04, 2014, 10:32:47 AM
Quote from: Ball000;772327
Sorry Olaf I may not have been clear. I was only answering to Kolla's post and his screen-shot of AROS' installer. I am totally convinced that your distribution is perfectly usable on emulators, and polished even. Congratz BTW.


ok sorry then for my answer

I am only a little nerved because people seem to search for any reason not to do anything or invest time (even testing would be something). If people would show interest I could perhaps motivate developers to improve Aros 68k, if not there is no reason for anyone to invest time in it. It is a wasted chance then for the 68k community, but then they should stop moaning about the situation because obvious they are happy about it otherwise they would act differently. Thomas has said that he cannot directly contribute because of legal reasons, that is regrettable but nothing can be changed about it. Others could but obviously do not want and try to find excuses why they do not. If people have a alternative but do not help they earn the situation and should stop moaning.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Minuous on September 04, 2014, 11:00:53 AM
>Hack&Patch were doing 3.5/9 on the cheap, scamming contributors left and right.

Allegedly. It's odd that no one was ever able to provide any proof of this; if they had had a case they would have been able to sue H&P and get lots of money from them.

>Doing those few actually new tools in 3.5/9 based on just plain GadTools+BOOPSI was no option.

Why not, if they were just doing it on the cheap?

>So they had to find a 2nd class GUI system that could be aquirred at next to 0 cost, and hell did ClassAct fill that bill.

I've never seen any evidence that it was acquired "at next to 0 cost". Do you have a source for this claim?

>The reality even today is that it is 100% possible (and not even hard) to setup a useable Amiga without ever touching ClassAct/ReAction. Try the same without useing MUI (yes even on OS4)...

I don't use any MUI programs, I keep it installed just for trying out new programs but have never found a MUI-based one worth keeping...I can't see how you could possibly have a usable Amiga without ReAction, considering that important OS components require it. At least for OS3.5/3.9.

@olsen:

Yes, I agree that OS3.1 is a big improvement over OS1.1, I don't think anyone is disputing that.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: itix on September 04, 2014, 12:14:24 PM
Quote from: psxphill;772317
If you're asking the user for the usbtrackdisk.device name and unit then why not ask them for the type of ram?


Why ask user? Is user expected to know difference of memory types? If I am streaming MP3 from the disk should I ask user what memory type is optimal for disk access and what memory type is optimal for ahi.device for audio output? And also ask what memory type is preferred for mega.library that could use some sort of hardware decoding?

Quote
Asking both devices is the only way to get the most optimal solution. By telling exec what things need to be able to access the ram then you can implement memory protection at the same time.

Or you could just copy the data using memcpy and pretend it's the best way.


It is the best way. It is better than guru meditation or ask user for memory config. This is not MS-DOS.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: itix on September 04, 2014, 12:21:07 PM
Quote from: Minuous;772329
>

>The reality even today is that it is 100% possible (and not even hard) to setup a useable Amiga without ever touching ClassAct/ReAction. Try the same without useing MUI (yes even on OS4)...

I don't use any MUI programs, I keep it installed just for trying out new programs but have never found a MUI-based one worth keeping...I can't see how you could possibly have a usable Amiga without ReAction, considering that important OS components require it. At least for OS3.5/3.9.


OS 3.1 users don't have any OS components using ClassAct/Reaction and I don't know any 3rd party software requiring Reaction. AWeb works with ClassAct, so does DirAction and few other I have tried.

OS 3.5/3.9 had almost no improvements (scsi.device with large hd support was only major improvement there) but just 3rd party software you can download from Aminet for free.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: olsen on September 04, 2014, 12:23:28 PM
Quote from: Kronos;772312
Well maybe you should take a step back to see what really has happened:

Hack&Patch were doing 3.5/9 on the cheap, scamming contributors left and right.
Doing those few actually new tools in 3.5/9 based on just plain GadTools+BOOPSI was no option.
Stuntz was to smart to give MUI away for free.

So they had to find a 2nd class GUI system that could be aquirred at next to 0 cost, and hell did ClassAct fill that bill.

I was there, on the ground, when the decision was made to go with BOOPSI classes instead of either sticking with gadtools or using MUI. Cost may have been a factor, but the plan clearly was to use what the operating system could support out of the box withour resorting to middleware, if you want to call MUI that. Problem was, ClassAct was not as mature as we had hoped for, and additional time was needed to integrate and test it. In retrospect, the usefulness of ClassAct was limited, and investing into upgrading it to become a fully featured user interface toolkit did not pay off. Moving every user interface to MUI would have taken a bigger effort, and user interface work certainly was challenging and arduous at the time.

As for contributors getting the short end of the stick, it's very well possible. This was a small project with limited capital investment. Let's not forget that back in 1998 there was not much faith in an Amiga operating system upgrade popping into existence, and just about everybody who might have contributed to working on the product had cold feet. You had to be somewhat crazy to jump in. I certainly was...
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: olsen on September 04, 2014, 12:36:04 PM
Quote from: itix;772332

OS 3.5/3.9 had almost no improvements (scsi.device with large hd support was only major improvement there) but just 3rd party software you can download from Aminet for free.


Hey, no fair, that hurts :(

I'm one of the crazy people who worked their asses off for those "almost no improvements" in OS 3.5.

You casually dismiss the whole effort of rebuilding and fixing most of the disk-based operating system components, including the datatypes, the printing subsystem, preferences, Workbench and its icon system. We even managed to put in bug fixes for ROM-based components. OS 3.5 brought API changes, code cleanup and the original plan was to build upon that in future development work. We even managed to beta test the whole product.

In retrospect, the OS 3.5 update was too little too late, but it certainly was no frivolous attempt at selling basically nothing to the gullible.

Now OS 3.9, that certainly deserves it share of criticism.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Gulliver on September 04, 2014, 01:15:25 PM
Quote from: OlafS3;772320
A simple question to you... What functionality is missing in my distribution?

Your distro is really okay, it does what it says on the tin. The problem is performance, and is something you cant solve (it is an aros based issue).

I have tried it under WinUAE and I liked it and works reasonably well. But it tortures real amiga hardware (performancewise), So you see that is my main gripe with aros: it works reasonably well on x86/x64 and even in 68k emulation, but is as slow as a snail on a real Amiga. And this is not opinion based, it is just reality, that ends up with the fact that users are willing to pay for ancient unsupported AmigaOS versions, than to use the free aros alternative.

I know it is a chicken and egg situation (little money/users/devs = little development). But it is what it is.  

I really wish aros could match in performance 3.1, so everyone could get a better OS, but unluckily this seems so distant...
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: itix on September 04, 2014, 01:38:42 PM
Quote from: olsen;772335
Hey, no fair, that hurts :(

I'm one of the crazy people who worked their asses off for those "almost no improvements" in OS 3.5.

I know...

Quote
You casually dismiss the whole effort of rebuilding and fixing most of the disk-based operating system components, including the datatypes, the printing subsystem, preferences, Workbench and its icon system. We even managed to put in bug fixes for ROM-based components. OS 3.5 brought API changes, code cleanup and the original plan was to build upon that in future development work. We even managed to beta test the whole product.

Unfortunately it is not so useful to end users. Being paid update users dont have much interest on API changes or code cleanup or components he can download from Aminet for free. OS 3.5 introduced GlowIcons (which I already had in NewIcons format) and WB improvements. Latter made me quite curious about to get update but in the end I never could justify price. OS 3.1 with all patches and that stuff was just too good.

But that is just me. Real problem in bigger picture obviously was lack of users.

Quote
In retrospect, the OS 3.5 update was too little too late, but it certainly was no frivolous attempt at selling basically nothing to the gullible.

It was developed in difficult situation, no doubt.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on September 04, 2014, 01:48:22 PM
Quote from: itix;772332
OS 3.1 users don't have any OS components using ClassAct/Reaction and I don't know any 3rd party software requiring Reaction. AWeb works with ClassAct, so does DirAction and few other I have tried.

OS 3.5/3.9 had almost no improvements (scsi.device with large hd support was only major improvement there) but just 3rd party software you can download from Aminet for free.


aweb.. performancewise ok, but simplistic and completely outdated browser..
dir action, this is really a sort of software completely uncalled for. i wonder if a single person ever used this clumsy, ugly and unreadable another directory manager, while there were already so many good alternatives available.
bah.. i cant really think about much reaction/classact software of any use.. i know its just another opinion..
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kolla on September 04, 2014, 02:21:14 PM
What I really like with OS3.5/3.9 (dont remember when it came) is AREXX support in Workbench - finally, and the "resize window to fit" menu entry :) I also like shell improvements and fixes, the H protection flag working again and various other minor things. Regarding preferencs, I could do without the Reaction toolkit, and I really do not see the point in 020+ requirement. From my experience with trying to get as much of OS3.9 as possible to work on (a mighty fast) 68000, it is largely just the preferences programs that require 020+ - that is, resource.library is 020+.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on September 04, 2014, 03:54:26 PM
In that respect, relax. The workbench is perfectly safe (Olsen has it) and the Shell is perfectly safe (I have it, and Olsen has a copy), so those parts are definitely not lost. Reaction is "lost in time and space", somehwere at H&P, I afraid, and it seems unlikely that we'll see sources anytime.

I'm personally missing SetPatch, FFS and Ram-Handler, components that were prepared and updated by Heinz. I'm not sure whether Olsen has the 3.9 versions of them. FFS had a couple of fixes, (ACTION_FLUSH finally working is one of them, ACTION_CLOSE returning proper result codes another, avoiding a memory leak present in 3.1), SetPatch includes a list of bug fixes that have been found (ExAll most notably, probably some stuff in Gfx), and Ram-Handler using memory pools, which is a nice addendum. Unfortunately, FFS misses TD64 support (which would be extremely easy to add, and is really just an annoyance, not a technical challenge).
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on September 04, 2014, 05:14:42 PM
Quote from: Minuous;772329
>Hack&Patch were doing 3.5/9 on the cheap, scamming contributors left and right.

Allegedly. It's odd that no one was ever able to provide any proof of this; if they had had a case they would have been able to sue H&P and get lots of money from them.

>Doing those few actually new tools in 3.5/9 based on just plain GadTools+BOOPSI was no option.

Why not, if they were just doing it on the cheap?

>So they had to find a 2nd class GUI system that could be aquirred at next to 0 cost, and hell did ClassAct fill that bill.

I've never seen any evidence that it was acquired "at next to 0 cost". Do you have a source for this claim?

>The reality even today is that it is 100% possible (and not even hard) to setup a useable Amiga without ever touching ClassAct/ReAction. Try the same without useing MUI (yes even on OS4)...

I don't use any MUI programs, I keep it installed just for trying out new programs but have never found a MUI-based one worth keeping...I can't see how you could possibly have a usable Amiga without ReAction, considering that important OS components require it. At least for OS3.5/3.9.

@olsen:

Yes, I agree that OS3.1 is a big improvement over OS1.1, I don't think anyone is disputing that.


You need Reaction? For what?

I use f.e. Simplemail, what Mailprogram do you use with Reaction?
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on September 04, 2014, 05:34:30 PM
Quote from: Gulliver;772340
Your distro is really okay, it does what it says on the tin. The problem is performance, and is something you cant solve (it is an aros based issue).

I have tried it under WinUAE and I liked it and works reasonably well. But it tortures real amiga hardware (performancewise), So you see that is my main gripe with aros: it works reasonably well on x86/x64 and even in 68k emulation, but is as slow as a snail on a real Amiga. And this is not opinion based, it is just reality, that ends up with the fact that users are willing to pay for ancient unsupported AmigaOS versions, than to use the free aros alternative.

I know it is a chicken and egg situation (little money/users/devs = little development). But it is what it is.  

I really wish aros could match in performance 3.1, so everyone could get a better OS, but unluckily this seems so distant...


Aros devs and (in case of Aros Roms) Toni Wilen are basically idealists, they do things for fun and to get some positive feedback (and perhaps some donations :) ). When people always say I "would" use Aros 68k but first it must be as fast as AmigaOS on classic hardware, have all the drivers, and of course all patches of aminet then I "would perhaps" use it how motivated do you think they are to invest additional time in it (they all have a bunch of projects already) and others who could jump in and help with it or do at least testing and make logs and send it to Toni say it is still not good enough to use (functionality using it on UAE I would say not true, speedwise running on classic hardware yes it is still not fast enough). I could make a bet with you... it will never be optimized then and there will be never a amigaos successor if nobody helps. I am running it on emulation outperforming a Sam 440 speedwise (and I do not need any optimized libs to do that and there are tons of in my distribution f.e. graphical libs, game libs, Chunky and 3D libs and so on). For me it is perfectly ok now but I think it would potentially of big benefit for all the 68k community, being adaptable and in development unifying everything 68k related. But people seem not to share my ideas.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: biggun on September 05, 2014, 06:45:18 AM
I think Olaf has a very good point here.

We should not forget this.

This is certainly true for people working on AROS or people like Cosmos.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on September 05, 2014, 08:49:31 AM
yes, do not forget os4 is extensively funded and even morphos does cost some money.
in comparison people still expect aros to present them just every imaginable feature on a tablet for free and be up to concurrent solutions (which it even mostly is) without them even to lift a finger.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on September 05, 2014, 09:12:49 AM
Quote from: kolla;772343
What I really like with OS3.5/3.9 (dont remember when it came) is AREXX support in Workbench - finally, and the "resize window to fit" menu entry :) I also like shell improvements and fixes, the H protection flag working again and various other minor things. Regarding preferencs, I could do without the Reaction toolkit, and I really do not see the point in 020+ requirement. From my experience with trying to get as much of OS3.9 as possible to work on (a mighty fast) 68000, it is largely just the preferences programs that require 020+ - that is, resource.library is 020+.


I use Magellan as desktop and Magellan has extensive AREXX support. Most of what is included in 3.5 or 3.9 can be added from aminet because available freely or there are similar replacements available (I tried that as much as possible in my distribution). That not means that I want to downtalk what people did with 3.5 or 3.9, it was certainly a big effort but from todays view I would say it is replaceable and not unique like some here claim.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: NorthWay on September 05, 2014, 10:00:01 AM
Quote from: Minuous;772304
I don't see what's so special about OS3.1.

It is the most obvious choice to me, and I applauded AROS when they finally dropped all their pie-in-the-sky ideas and went for a down to earth choice which you could actually measure and compare with the yardstick.

3.1 is the last official C= release, and the last combined ROM+disk release. The more recent releases have no big API updates anyway, and a whole lot less status among the congregation (no offence Olsen and the rest).

(Oh, and I liked ClassAct, but that is another discussion.)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: warpdesign on September 05, 2014, 10:50:48 AM
I'm wondering: if we exclude the fact that it's opened (that's already huge, yes), can be fixed and improved by anyone, and is portable, what are the benefits of running AROS instead of original AOS on 68k hardware? It seems most AROS developers don't seem to be that interested in seeing it run correctly (ie: at least on par with original AOS on 68k hardware) but why would they? What's the motivation? What would it bring?
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on September 05, 2014, 12:22:46 PM
Quote from: warpdesign;772376
I'm wondering: if we exclude the fact that it's opened (that's already huge, yes), can be fixed and improved by anyone, and is portable, what are the benefits of running AROS instead of original AOS on 68k hardware? It seems most AROS developers don't seem to be that interested in seeing it run correctly (ie: at least on par with original AOS on 68k hardware) but why would they? What's the motivation? What would it bring?

for amiga userrs aros brings additional functionalities, like built in usb stack, network stack, rtg support, gallium/mesa, css capable browser, ability to move windows off screen, a number of contributions, apps and games, capable of running on 68k. aros basically runs on every system without patching and reconfiguration, which allows to have centralized effort in improvement, everybody may contribute to according to his abilities, instead wasting time on multiple concurrent and uncoordinated projects. the goal is that you can download aros and just run in on whatever amiga hardware you own or under uae without spending weeks to set up the system to your satisfaction. i know for many this is a pleasure itself to fiddle with it, but it may be redirected to common effort that results in amiga characteristic easiness of use and plug and play abilities that have been long lost unfortunately. also aros kickstart aims at mutual compatibility with the 1.x - 3.x range as far as it can be done, so genuinely incompatible amiga applications can be run side by side. as far as i know it provides also improved posix compliance, that allows easier porting without ixemul library, which still remains an option though.

aros devs are taking aos compatibility serious as i said, but it is not their priority to have perfectly working hardware drivers for each and every amiga system out there. except perhaps for toni. but without testing, cooperation on the part of the (potential) users and educated bug reports they certainly are left with nothing. im sorry, if you want to see aros as upgrade alternative to aos, its your move now.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: itix on September 05, 2014, 02:56:52 PM
Quote from: wawrzon;772379
Quote

I'm wondering: if we exclude the fact that it's opened (that's already huge, yes), can be fixed and improved by anyone, and is portable, what are the benefits of running AROS instead of original AOS on 68k hardware? It seems most AROS developers don't seem to be that interested in seeing it run correctly (ie: at least on par with original AOS on 68k hardware) but why would they? What's the motivation? What would it bring?


for amiga userrs aros brings additional functionalities, like built in usb stack, network stack, rtg support, gallium/mesa, css capable browser, ability to move windows off screen, a number of contributions, apps and games, capable of running on 68k.


I think AROS on Amiga HW is having sort of same problem than OS 3.5/3.9 had. If you had USB/network/gfx board or other expansion HW you already had required drivers and programs installed. Probably bunch of WB enhancers too which allow most of those candy features and given that Amiga hardware is quite limited it is difficult to build new enhancements.

If there was new/old 68k hardware supported only by AROS 68k then it could be different game. I guess it is too late to support old 68k Macs now ;-)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on September 05, 2014, 03:16:02 PM
Quote from: itix;772381
I think AROS on Amiga HW is having sort of same problem than OS 3.5/3.9 had. If you had USB/network/gfx board or other expansion HW you already had required drivers and programs installed. Probably bunch of WB enhancers too which allow most of those candy features and given that Amiga hardware is quite limited it is difficult to build new enhancements.

If there was new/old 68k hardware supported only by AROS 68k then it could be different game. I guess it is too late to support old 68k Macs now ;-)


in fact someoneseems to attempt just that;)

otherwise i think you are right, though i have a well tuned 3.x setup myself all aling with custom kick and set of libs in flash, still ive seen the opportunity in aros. as for new hardware, who knows.. perhaps gallium supported rtg cards could be used on pci extended systems one day.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: biggun on September 05, 2014, 03:47:28 PM
Quote from: itix;772381

If there was new/old 68k hardware supported only by AROS 68k then it could be different game.



I think this is a good idea ...
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: warpdesign on September 05, 2014, 04:11:26 PM
Quote
If there was new/old 68k hardware supported only by AROS 68k then it could be different game. I guess it is too late to support old 68k Macs now ;-)
Or maybe if AROS brought something really new and better (memory protection? etc...) ?
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: itix on September 05, 2014, 04:45:25 PM
Quote from: warpdesign;772387
Or maybe if AROS brought something really new and better (memory protection? etc...) ?


If you break binary compatibility why bother with 68k?
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Terminills on September 06, 2014, 01:56:42 AM
Quote from: itix;772381
I think AROS on Amiga HW is having sort of same problem than OS 3.5/3.9 had. If you had USB/network/gfx board or other expansion HW you already had required drivers and programs installed. Probably bunch of WB enhancers too which allow most of those candy features and given that Amiga hardware is quite limited it is difficult to build new enhancements.

If there was new/old 68k hardware supported only by AROS 68k then it could be different game. I guess it is too late to support old 68k Macs now ;-)



http://www.mirari.fr/ZkeU

The PX60 is the stand alone of this board. :D  Perfect home for Aros 68K if you ask me. ;)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Minuous on September 06, 2014, 03:25:22 AM
>OS 3.5 introduced GlowIcons (which I already had in NewIcons format)

NewIcons is just an unofficial "hack and patch" based on tooltypes, whereas GlowIcons is a proper upgrade to the icon system, the two are not at all equivalent.

>3.1 is the last official C= release, and the last combined ROM+disk release.

Actually 3.1 was released by Village Tronic, not Commodore. Not that there is anything sacred about Commodore. I don't see the relevance of whether the ROM upgrade is performed in firmware or software.

>The more recent releases have no big API updates anyway

Yes they do, obviously you haven't read the autodocs.

>Most of what is included in 3.5 or 3.9 can be added from aminet

That's incorrect.

>OS 3.5/3.9 had almost no improvements (scsi.device with large hd support was only major improvement there) but just 3rd party software you can download from Aminet for free.

Maybe if you had actually bought and used the product, or even bothered to read the changelog and/or autodocs, you would know this to be wrong.

>I am only a little nerved because people seem to search for any reason not to do anything or invest time (even testing would be something).

Open source status isn't really a reason for an ordinary user to want to use something. They will make that assessment based on other factors such as as features, speed, etc. which AROS lacks.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kamelito on September 06, 2014, 06:51:17 AM
Quote from: Terminills;772402
http://www.mirari.fr/ZkeU

The PX60 is the stand alone of this board. :D  Perfect home for Aros 68K if you ask me. ;)

Well why not but can you buy it? for now it seems more vaporware than anything else no?

Kamelito
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: psxphill on September 06, 2014, 07:58:26 AM
>Actually 3.1 was released by Village Tronic, not Commodore.
 
 It was distributed by Village Tronic. The content came from commodore.
 
 > Not that there is anything sacred about Commodore.
 
 In terms of Provenance there is.
 
 If I converted the Ship of Theseus to fibre glass then would it be the same ship? http://en.wikipedia.org/wiki/Ship_of_Theseus
 
 Some people want to maintain classic cars in their original form, others want to strip them down and rebuild them with different engine, suspension and lower the roof etc. The later only appeals to a minority, like OS3.5/3.9/4.x
 
 It's a shame that AROS hasn't been more focused on 68k in the past, I think that had the most potential for bridging the gap between old and new hardware.
 
 > I don't see the relevance of whether the ROM upgrade is performed in
 > firmware or software.

 If it's not in ROM then it's taking up RAM.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on September 06, 2014, 08:25:53 AM
Quote from: Minuous;772404

Open source status isn't really a reason for an ordinary user to want to use something. They will make that assessment based on other factors such as as features, speed, etc. which AROS lacks.


you are talking about regular customers, such as those buying regular products on regular therms such as warranty or comparable prices and so on. there is no users/customers in the amiga community by this definition. judging by features such as speed amiga nor its offshots are an option anyway. putting people that only fire up their 500 now and then to play a game aside, people like you, me, olaf, terminills, itix and others are obviously interested in what is going on with amiga, beyond that regular usage (whatever it would be), otherwise they would not be taking part in the discussion.

im not so much advocating to attract regular customers to aros 68k at this point, but people who care, and are able to contribute in some way. but in the end we cannot enforce it.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on September 06, 2014, 08:27:26 AM
Quote from: psxphill;772414
It's a shame that AROS hasn't been more focused on 68k in the past, I think that had the most potential for bridging the gap between old and new hardware.


yes, perhaps its too late.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on September 06, 2014, 09:02:55 AM
Quote from: psxphill;772414
 Some people want to maintain classic cars in their original form, others want to strip them down and rebuild them with different engine, suspension and lower the roof etc. The later only appeals to a minority, like OS3.5/3.9/4.x
I suggest to stick with 1.2 then. Everything else was not delivered with the original Amiga.  
Quote from: psxphill;772414
 If it's not in ROM then it's taking up RAM.

Oh, com'on! How many MBs does the average Amiga has today? Do you think a couple of KBs do actually matter?
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: psxphill on September 06, 2014, 09:41:03 AM
Quote from: Thomas Richter;772425
I suggest to stick with 1.2 then. Everything else was not delivered with the original Amiga.

None of my original Amigas were ever delivered with 1.2

Quote from: Thomas Richter;772425
Oh, com'on! How many MBs does the average Amiga has today?

I have no idea & it's not relevant to my argument. It's relevant to your argument, so why don't you know?

Quote from: Thomas Richter;772425
Do you think a couple of KBs do actually matter?

The difference between software running or not could be 1 byte, but where are you getting "a couple of KBs" from. That was neither in the original statement or my reply.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on September 06, 2014, 09:53:50 AM
Quote from: psxphill;772426
None of my original Amigas were ever delivered with 1.2
 
 Lying doesn't help your argument.

Who is lying? Did your Amgias come with 3.1 equipped? Mine did not. Mine came with 1.2, so who's lying?

The memory argument might have been an argument when Amigas came with 256K or 1MB. But those days are long gone, since a long time. If done properly, actually none of the system components should be ROM to ease upgrading, but I said this before. The A1000 had this, in a primitive and inconvenient form, and not exactly for the same reasons.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: psxphill on September 06, 2014, 09:58:36 AM
Quote from: Thomas Richter;772427
Did your Amgias come with 3.1 equipped?

I bought original Amigas with 1.3 (A500), 3.0 (A1200) and 3.1 (A1200).

Quote from: Thomas Richter;772427
Mine did not. Mine came with 1.2, so who's lying?

You didn't say your Amiga, you said "the original Amiga". So I'd say it was you who is lying by trying to twist facts to justify your argument.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: BSzili on September 06, 2014, 10:03:41 AM
I don't understand why people are so fixated on the fact that AROS strives for 3.1 compatibility. This doesn't mean that they won't implement anything beyond V40. Look at icon.library for example, it has DrawIconStateA(), which is a V44 function.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on September 06, 2014, 10:18:00 AM
@bszili
+1. finally informed statement about the matter from someone who knows not only aros but os4, mos and genuine amiga from application programming standpoint.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kolla on September 06, 2014, 10:28:38 AM
In this time and day, I would say AROS goes way beyond original AmigaOS in terms of features, most important being that it is not locked to certain hardware. In time I'm sure someone will be intrigued enough to implement better support for Amiga chipsets too. In the meantime I'm perfectly happy with AROS on x86, with Directory Opus Magellan, tbh I forget that it is AROS when I use it these days.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kolla on September 06, 2014, 10:33:34 AM
I will be looking for an ARM based laptop of some sort, to build myself an environment with customized Linux setup and AROS hosted, and DOpus as DE :)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Minuous on September 06, 2014, 11:30:29 AM
@psxphill:

>>Not that there is anything sacred about Commodore.

>In terms of Provenance there is.

I suppose you think that an Amiga Technologies (Escom) A1200 is not a real Amiga then? Or that eg. a ZX Spectrum +3 isn't a real Spectrum, etc. because Amstrad had bought Sinclair. With that Ship of Theseus analogy, that was about whether it was still the real thing after every single component in it had been changed. OS3.9 is a big upgrade with lots of new features, but of course not every single byte in it is different from OS3.1.

>If it's not in ROM then it's taking up RAM.

I should point out that OS3.1 and even earlier versions used SetPatch to patch the ROM.

@wawrzon:

>im not so much advocating to attract regular customers to aros 68k at this point, but people who care, and are able to contribute in some way.

You seem to be suggesting that there are no regular users left in the community, only programmers. But I think the majority of Amiga users are still non-programmers. Maybe we should have a poll about this.

>finally informed statement about the matter from someone who knows not only aros but os4, mos and genuine amiga from application programming standpoint.

I've programmed for all these systems, so I believe I qualify...granted that for OS4/AROS there are other users that help with testing etc. Several of my programs are available for AROS x86. The rest would also be available, except for the fact that AROS is missing ReAction. How is software supposed to get ported to AROS when AROS lacks basic functionality that is part of the OS (not even undocumented functionality!) that the application absolutely depends upon? (In the interests of fairness, I should point out that both MOS and OS4 are missing some OS3.9 functionality too, but AROS is missing the most though.)

@BSzili:

>I don't understand why people are so fixated on the fact that AROS strives for 3.1 compatibility. This doesn't mean that they won't implement anything beyond V40.

Well, we've been waiting 15 years already...maybe if we wait another 15 it will have complete V45 support...? *Then* there might be a reason to switch to AROS...
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: psxphill on September 06, 2014, 11:52:43 AM
>>In terms of Provenance there is.

>I suppose you think that an Amiga Technologies (Escom) A1200 is not a >real Amiga then?

Why would you suppose that? Once you have reverted the floppy disk motherboard hack then it's mostly equivalent to a commodore A1200.

The AmigaOne isn't an Amiga though.

>I should point out that OS3.1 and even earlier versions used SetPatch to patch the ROM.

SetPatch goes back a very long way, but they were generally very small patches. OS3.5/3.9 replaced some libraries in ROM with disk based versions. Ideally you'd have the latest scsi.device in ROM.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Terminills on September 06, 2014, 12:48:23 PM
Quote from: kamelito;772408
Well why not but can you buy it? for now it seems more vaporware than anything else no?

Kamelito



The PX60 was never promised by Rodolphe.  It all depends on how well the CTX60 sells.  However the CT60, CT63, CTPCI that he has previously released have been very high quality.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: kolla on September 06, 2014, 01:00:31 PM
With all due respect, but from a user's point of view, Reaction has very little to offer over Zune (and/or MUI), and the only parts that rely on Reaction in OS3.9 are the preference programs - is the API of OS3.9 open enough to allow third party prefs programs to be written? I would love 68000 compatible equivalents for my minimig :)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: BSzili on September 06, 2014, 01:13:36 PM
Quote from: Minuous;772437
@BSzili:

>I don't understand why people are so fixated on the fact that AROS strives for 3.1 compatibility. This doesn't mean that they won't implement anything beyond V40.

Well, we've been waiting 15 years already...maybe if we wait another 15 it will have complete V45 support...? *Then* there might be a reason to switch to AROS...
I don't know how is this even related to what I've said. People have been complaining about AROS only implementing 3.1 functions and nothing from 3.5+ which isn't factually true. I for one don't want to convince you or anybody to use AROS, so you don't have to tell me your conditions of when you might switch to AROS :)
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: NorthWay on September 06, 2014, 01:42:36 PM
Quote from: Minuous;772404
Actually 3.1 was released by Village Tronic, not Commodore.

For me, as a developer, it was released by Commodore. For the general public it might have been distributed by someone else, but it was still a Commodore product.

Quote from: Minuous;772404
Not that there is anything sacred about Commodore.

Of course there is. After they died there haven't been anyone who has been universally agreed upon to hold all the rights to the fallen empire. If someone had stepped in and taken command then I would have agreed.

Quote from: Minuous;772404
I don't see the relevance of whether the ROM upgrade is performed in firmware or software.

True(partially), but then again the 3.5/3.9 releases didn't really update the ROM parts much so not so much of a upgrade to the ROM contents? The Amiga being what it is is also more vulnerable the more of the code that lives in ram instead of rom, but I'm not suggesting to limit updates because of that.

Quote from: Minuous;772404
Yes they do, obviously you haven't read the autodocs.

Touche. I'm sure I quickly browsed them when it was released. Can't have been much of interest to me if it didn't register. I obviously haven't done much Amiga side in the recent years (all of my machines have died on me now - bah).
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: itix on September 06, 2014, 01:48:36 PM
Quote from: Minuous;772404
>OS 3.5 introduced GlowIcons (which I already had in NewIcons format)

NewIcons is just an unofficial "hack and patch" based on tooltypes, whereas GlowIcons is a proper upgrade to the icon system, the two are not at all equivalent.


Not really hack and patch. NewIcons just replaces original icon image with image encoded in tooltypes. It is slower but works and is quite clean. Glowicons append IFF ICON chunk to end of icon file. Users dont really care how icon data is stored.

Quote

>The more recent releases have no big API updates anyway

Yes they do, obviously you haven't read the autodocs.


I did. New calls in Exec are not important. Improved printer.device is useful only to few application developers who want to support printing and it is probably enough if you support Turboprint. Icon.library changes -- not very useful to average developers. Me being MUI developer I dont have to deal with icon.library except when using GetDiskObject() to get proper app icon and icon.library new API was probably meant to support future 3rd party WB enhancers (?). Workbench.library changes are nice, OpenWorkbenchObject() is one of few new API calls I have ever used.

ClassAct is avaibale from Aminet and had they chosen to use MUI instead it would have not made any difference.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on September 06, 2014, 01:49:50 PM
Quote from: Minuous;772437
@psxphill:

>>Not that there is anything sacred about Commodore.

>In terms of Provenance there is.

I suppose you think that an Amiga Technologies (Escom) A1200 is not a real Amiga then? Or that eg. a ZX Spectrum +3 isn't a real Spectrum, etc. because Amstrad had bought Sinclair. With that Ship of Theseus analogy, that was about whether it was still the real thing after every single component in it had been changed. OS3.9 is a big upgrade with lots of new features, but of course not every single byte in it is different from OS3.1.

>If it's not in ROM then it's taking up RAM.

I should point out that OS3.1 and even earlier versions used SetPatch to patch the ROM.

@wawrzon:

>im not so much advocating to attract regular customers to aros 68k at this point, but people who care, and are able to contribute in some way.

You seem to be suggesting that there are no regular users left in the community, only programmers. But I think the majority of Amiga users are still non-programmers. Maybe we should have a poll about this.

>finally informed statement about the matter from someone who knows not only aros but os4, mos and genuine amiga from application programming standpoint.

I've programmed for all these systems, so I believe I qualify...granted that for OS4/AROS there are other users that help with testing etc. Several of my programs are available for AROS x86. The rest would also be available, except for the fact that AROS is missing ReAction. How is software supposed to get ported to AROS when AROS lacks basic functionality that is part of the OS (not even undocumented functionality!) that the application absolutely depends upon? (In the interests of fairness, I should point out that both MOS and OS4 are missing some OS3.9 functionality too, but AROS is missing the most though.)

@BSzili:

>I don't understand why people are so fixated on the fact that AROS strives for 3.1 compatibility. This doesn't mean that they won't implement anything beyond V40.

Well, we've been waiting 15 years already...maybe if we wait another 15 it will have complete V45 support...? *Then* there might be a reason to switch to AROS...


If you talk about X86 or ARM branches maybe, I do not think that they ever tried to implement everything (or could because much is closed source including Reaction), on the other side they added lots of features never part of 3.1., including some of the patches, 3D and many others.

But again this thread is about 68k so we talk about Aros 68k where you can add almost everything (similar to the PPC platforms) so again what features are missing. I want 1. and 2. and 3. and 4. then I can say it is possible or not (in my experience). You only talk in generalizations that are not true.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: itix on September 06, 2014, 02:04:13 PM
Quote from: psxphill;772414
> I don't see the relevance of whether the ROM upgrade is performed in
 > firmware or software.

 If it's not in ROM then it's taking up RAM.

Memory is cheap. I had 64MB on my A1200 and there was always more than needed. But having ROM is advantage because to replace ROM libraries you had to reboot. It is annoying because even with 3.1 booting was taking quite long.

If there was 3.5/3.9 ROM chip with BVision support in boot menu it could have been much much better... dont you hate it when it stops booting and you dont have TV near? :) Sometimes I was thinking my Amiga 1200 was better without those stupid complex expansions. Just vanilla Kickstart 3.1 and Miami + ethernet card, simple 68030 accelerator and small HD, Workbench on 640x256 screen.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on September 06, 2014, 02:08:37 PM
Quote from: Minuous;772437
@wawrzon:

>im not so much advocating to attract regular customers to aros 68k at this point, but people who care, and are able to contribute in some way.

You seem to be suggesting that there are no regular users left in the community, only programmers. But I think the majority of Amiga users are still non-programmers. Maybe we should have a poll about this.

i am talking to you, among other contributors to this thread, i assume most of whom have some programming experience. in fact its me, who is basically a plain user, occasional but rather incompetent tester and have been trying to make few simple ports to amiga.  i agree that most of the plain users who just sometime play a game do not count much in this case even if they could actually motivate aros68k development if there were any.

Quote
>finally informed statement about the matter from someone who knows not only aros but os4, mos and genuine amiga from application programming standpoint.

I've programmed for all these systems, so I believe I qualify...granted that for OS4/AROS there are other users that help with testing etc. Several of my programs are available for AROS x86. The rest would also be available, except for the fact that AROS is missing ReAction. How is software supposed to get ported to AROS when AROS lacks basic functionality that is part of the OS (not even undocumented functionality!) that the application absolutely depends upon? (In the interests of fairness, I should point out that both MOS and OS4 are missing some OS3.9 functionality too, but AROS is missing the most though.)

okay, but in case of aros you even could substitute missing components of the system on which your software relies if you really wanted. you dont have such a possibility on closed source alternatives.

so to exemplify and invert your reasoning, you who blame aros developers for the state of aros, namely not working enough or fast enough for you are actually even more to blame if you dont even contribute. aros developers are the same situation as you, making it in their free time, working on what they have fun working on. neither you nor them are on any duty.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Minuous on September 06, 2014, 02:12:08 PM
>Why would you suppose that? Once you have reverted the floppy disk motherboard hack then it's mostly equivalent to a commodore A1200.

Well, if you revert enough of OS3.5/3.9 you can turn it back to OS3.1. After all, 3.1 is even included on the CD, so it's just a matter of replacing files. I'm really trying to understand your reasoning but it doesn't seem consistent. It seems to be that if OS3.5/3.9 was almost the same as OS3.1 it would be OK (like an Escom A1200 compared to Commodore A1200) but since it is a significant upgrade, it's not OK? What about Amiga Walker, would that have been a real Amiga if released?

>The AmigaOne isn't an Amiga though.

Well, I'm certainly no OS4 fanboy, and it's tangential to the issues at hand, but IMHO an AmigaOne is a real Amiga, it's just not a "Classic Amiga". Which is why we have the term. It's a bit like saying that a PPC Mac or Intel Mac isn't actually a Mac, only a 68K Mac is a real Mac. I suspect that if anyone went to a Mac forum and claimed such a thing there would be howls of derision.

>the only parts that rely on Reaction in OS3.9 are the preference programs - is the API of OS3.9 open enough to allow third party prefs programs to be written?

There are other parts: some that spring immediately to mind are AWeb and various items on the Workbench menus (eg. "Execute command...", "Information...", etc.). As to preferences files, they are mostly just IFF files and are mostly documented, eg. Report+ can interpret most of these files.

>After they died there haven't been anyone who has been universally agreed upon to hold all the rights to the fallen empire. If someone had stepped in and taken command then I would have agreed.

Escom bought everything important. IIRC they bought everything except some trademarks and patents.

>True(partially), but then again the 3.5/3.9 releases didn't really update the ROM parts much so not so much of a upgrade to the ROM contents?

Quite significant upgrades to the ROM-based components actually.

>The Amiga being what it is is also more vulnerable the more of the code that lives in ram instead of rom, but I'm not suggesting to limit updates because of that.

That's an interesting point, ROM is indeed not susceptible to being overwritten with garbage. However if a program is writing garbage to arbitrary addresses you will likely have problems regardless of whether Kickstart is in RAM or ROM...because most of the time statistically such accesses will be hitting RAM.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: olsen on September 06, 2014, 02:17:40 PM
Quote from: itix;772449
Not really hack and patch. NewIcons just replaces original icon image with image encoded in tooltypes. It is slower but works and is quite clean. Glowicons append IFF ICON chunk to end of icon file. Users dont really care how icon data is stored.

I doubt that. The size of icon files directly affects how quickly Workbench reads directories, and even under optimal conditions things aren't so nice to begin with. Due to how Workbench is designed, and how the icon file layout looks like, there is no clean way to provide for caching, and even changing one small aspect of an icon (say, a tool type) requires that the entire file is written back to disk; prior to icon.library V44 this would amount to a series of individual Write() calls with no write buffering whatsoever.

I added an icon.library API for streamlining snapshot operations (which ends up modifying the icon file on disk) but for all other operations things are not really sunny.

The NewIcons text encoding/decoding of the image data contributes significantly to the time it takes to read/store an icon on disk. Also, the NewIcons patches have to hide the encoded image tool types from display, which again burns CPU cycles. This stuff adds up. It works, but sacrifices are being made on your behalf.

With icon files you have a choice between a bad solution and a worse solution. The icon image chunk appended to the icon files by icon.library V44 and beyond is an optimization. It reads more quickly than the NewIcons encoding of the image data (remember, prior to icon.library V44 this data was read by a series of individual Read() calls), and it takes up less space in the file. In this context I consider the new icon file format a bad solution, and NewIcons a worse solution.

Bottom line is, icon I/O operations are expensive and how Workbench reads icons adds insult to injury. The modified icon file format attempts to remedy this.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: biggun on September 06, 2014, 02:23:15 PM
Stupid question.

What is wrong/bad about the original Icon format?

Of course with just 2 planes Icons look not so impressive.
But with 3 planes like in MagivWB the Icons look already quite cool.
I would imagine that a 4 planes MagicWB+ might even look nice.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: stefcep2 on September 06, 2014, 02:39:52 PM
I use PeterK's icon.library on a 68060 and CV 64 A4000 with Kens PNG icons.  Any slow down if its there is neglible.

TBH its all eye candy anyway.  The icon is supposed to be a pictorial representation of the file- you are supposed to know what it is without looking at its name.  I find I rarely do that, and the icon is nothing more than the place I click- which I could do just as well in 4 colors, maybe even better.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on September 06, 2014, 02:52:45 PM
Quote from: Minuous;772453
>Why would you suppose that? Once you have reverted the floppy disk motherboard hack then it's mostly equivalent to a commodore A1200.

Well, if you revert enough of OS3.5/3.9 you can turn it back to OS3.1. After all, 3.1 is even included on the CD, so it's just a matter of replacing files. I'm really trying to understand your reasoning but it doesn't seem consistent. It seems to be that if OS3.5/3.9 was almost the same as OS3.1 it would be OK (like an Escom A1200 compared to Commodore A1200) but since it is a significant upgrade, it's not OK? What about Amiga Walker, would that have been a real Amiga if released?

>The AmigaOne isn't an Amiga though.

Well, I'm certainly no OS4 fanboy, and it's tangential to the issues at hand, but IMHO an AmigaOne is a real Amiga, it's just not a "Classic Amiga". Which is why we have the term. It's a bit like saying that a PPC Mac or Intel Mac isn't actually a Mac, only a 68K Mac is a real Mac. I suspect that if anyone went to a Mac forum and claimed such a thing there would be howls of derision.

>the only parts that rely on Reaction in OS3.9 are the preference programs - is the API of OS3.9 open enough to allow third party prefs programs to be written?

There are other parts: some that spring immediately to mind are AWeb and various items on the Workbench menus (eg. "Execute command...", "Information...", etc.). As to preferences files, they are mostly just IFF files and are mostly documented, eg. Report+ can interpret most of these files.

>After they died there haven't been anyone who has been universally agreed upon to hold all the rights to the fallen empire. If someone had stepped in and taken command then I would have agreed.

Escom bought everything important. IIRC they bought everything except some trademarks and patents.

>True(partially), but then again the 3.5/3.9 releases didn't really update the ROM parts much so not so much of a upgrade to the ROM contents?

Quite significant upgrades to the ROM-based components actually.

>The Amiga being what it is is also more vulnerable the more of the code that lives in ram instead of rom, but I'm not suggesting to limit updates because of that.

That's an interesting point, ROM is indeed not susceptible to being overwritten with garbage. However if a program is writing garbage to arbitrary addresses you will likely have problems regardless of whether Kickstart is in RAM or ROM...because most of the time statistically such accesses will be hitting RAM.


It was already written a number of times here but I repeat it

AWeb does NOT need Reaction, it needs Classact and both Classact and AWeb work perfectly on Aros 68k. But you seem not to react on the comments of others
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on September 06, 2014, 02:58:01 PM
Quote from: Minuous;772453
That's an interesting point, ROM is indeed not susceptible to being overwritten with garbage. However if a program is writing garbage to arbitrary addresses you will likely have problems regardless of whether Kickstart is in RAM or ROM...because most of the time statistically such accesses will be hitting RAM.

LoadModule and MuProtectModules exist.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on September 06, 2014, 03:10:28 PM
Quote from: biggun;772455
Stupid question.

What is wrong/bad about the original Icon format?
It is really an ad-hoc solution and was not designed for extensibility. I.e. it is four colors only (two bitplanes), and no chance to add it with functionalities beyond those originally intended. Ideally, the original icon file should have used some kind of extensible file format, e.g. IFF (ignoring the fact that IFF came actually later.)

For me, the original four color icons always worked "good enough", but arguably, it's really not an up-to-date look.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: Minuous on September 06, 2014, 03:20:14 PM
Quote from: OlafS3;772459
AWeb does NOT need Reaction, it needs Classact and both Classact and AWeb work perfectly on Aros 68k. But you seem not to react on the comments of others

I don't? Read through this thread again and you will see that I have responded to the comments of various people. Without resorting to ad hominem attacks as you are doing now. I've made this point before, but again: yes you can add extra bits to AROS to get a semi-usable system. That doesn't make it a usable system. Someone could get a bare CPU and add various bits to it to make it a usable system, that doesn't make it a usable system in its own right. You have to download extra bits to make it equivalent to something that already works fine out of the box. What good is that?

Also with AROS x86 you can't even do that; if a piece of software is not available in an AROS x86 version you can't use it at all. Unless they finally have working 68K emulation, which they didn't last time I checked. And like I and others have said before, there's no reason for any 68K user to bother with AROS: it's slow, missing features and ugly. Really, it has next to nothing to recommend it except for copyright issues, which seemed to be the main reason Toni Wilen was bothering with it, because it could be distributed freely with WinUAE, not because it was actually better. The same applies to various BIOS replacements that are included with various emulators. For best compatibility you use an authentic BIOS which, by definition, is 100% byte-for-byte identical. Substitute BIOSes are included for legal reasons only, generally the first thing one does is get an authentic ROM dump.

Quote from: biggun
What is wrong/bad about the original Icon format?

The main one is that they aren't palette independent. So users have to keep the default colours; if the user changes their palette all their old-style icons will look awful. And if the developer used a non-standard palette to begin with, you have to match your palette to theirs. Not everyone runs MagicWB. MagicWB doesn't even define more than 8 colours IIRC. The original icon format was designed for OS1.x which didn't support deep screens. Even if you assume that neither the developer nor the user has modified the colours from the default, you still can't guarantee what palette is in use. Eg. 1.x has a different default palette as compared to 2.x.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: biggun on September 06, 2014, 03:26:07 PM
Quote from: Minuous;772462
You have to download extra bits to make it equivalent to something that already works fine out of the box. What good is that?


But this is normal - right?

AMIGA OS as it also needed extra stuff to be added to become useable.
This is why they made those packs with text editors and DPaint and such.

Isn't this the same with Linux for example?
Also Linux as it - is just a Kernel.
All the programs in Linux are gnu tools and do actually not belong to Linux.
So people/companies took time and effort to bundle them all together into a working useable distribution.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: OlafS3 on September 06, 2014, 04:02:37 PM
Quote from: Minuous;772462
I don't? Read through this thread again and you will see that I have responded to the comments of various people. Without resorting to ad hominem attacks as you are doing now. I've made this point before, but again: yes you can add extra bits to AROS to get a semi-usable system. That doesn't make it a usable system. Someone could get a bare CPU and add various bits to it to make it a usable system, that doesn't make it a usable system in its own right. You have to download extra bits to make it equivalent to something that already works fine out of the box. What good is that?

Also with AROS x86 you can't even do that; if a piece of software is not available in an AROS x86 version you can't use it at all. Unless they finally have working 68K emulation, which they didn't last time I checked. And like I and others have said before, there's no reason for any 68K user to bother with AROS: it's slow, missing features and ugly. Really, it has next to nothing to recommend it except for copyright issues, which seemed to be the main reason Toni Wilen was bothering with it, because it could be distributed freely with WinUAE, not because it was actually better. The same applies to various BIOS replacements that are included with various emulators. For best compatibility you use an authentic BIOS which, by definition, is 100% byte-for-byte identical. Substitute BIOSes are included for legal reasons only, generally the first thing one does is get an authentic ROM dump.



The main one is that they aren't palette independent. So users have to keep the default colours; if the user changes their palette all their old-style icons will look awful. And if the developer used a non-standard palette to begin with, you have to match your palette to theirs. Not everyone runs MagicWB. MagicWB doesn't even define more than 8 colours IIRC. The original icon format was designed for OS1.x which didn't support deep screens. Even if you assume that neither the developer nor the user has modified the colours from the default, you still can't guarantee what palette is in use. Eg. 1.x has a different default palette as compared to 2.x.


You install a distribution (OS3.5/3.9) and then compare it to a backbone that is aiming to reimplement 3.1. API and not suited for users and then make your judgements? I have shown you screenshots of 68k software running on it no reaction from you.

AmigaOS is not in development anymore, 3.9 was the last update and then there will be no updates in future. 4.X is another branch for me because it needs completely different hardware. So if anyone wants development then there is only one potential chance.

And to make some comments about what you wrote about X86... there IS a working emulation in AROS but only in certain distributions (Icaros Desktop and Aeros), not in nightly builds. They are for testing for developers not users. 68k emulation runs in a kind of box with UAE, integrated but not the same as on MorphOS or AmigaOS. I do not know when you last checked it but it seems to be very long ago or you have just looked at a nightly build (that has no 68k emulation integrated).

"no reason for any 68K user to bother with AROS: it's slow, missing features and ugly."

Really? Who has said that before? It is slow? Where and when? On real hardware yes, that was this discussion about, on emulation (what certainly most use today) no. Missing features? Which? I work for a couple of years on my distribution that is based on Aros 68k, which features are missing? As I explained before distributions are for users (not nightly builds). Ugly? Really? How that? Show me a example of that? I have a nice RTG 24bit background from Wawa, use Magellan as Desktop Manager and support almost any GUI technology inside that was ever available.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on September 06, 2014, 04:35:33 PM
Quote from: Thomas Richter;772461
It is really an ad-hoc solution and was not designed for extensibility. I.e. it is four colors only (two bitplanes), and no chance to add it with functionalities beyond those originally intended. Ideally, the original icon file should have used some kind of extensible file format, e.g. IFF (ignoring the fact that IFF came actually later.)

For me, the original four color icons always worked "good enough", but arguably, it's really not an up-to-date look.


i must admit, that also for my taste the most inspiring amiga icons were probably all in the genuine icon format. this might not be the reference for good one, but as you see even ms returns to simplistic graphics and its suits them better. i dont ever remember a new- glow- or png- icon to be particularly recognizable nor stunning. im not sure if giving icon designers more options adds up to the overall aesthetics, unique characteristics and ergonomy of the system. sometimes less is more.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: wawrzon on September 06, 2014, 04:47:09 PM
Quote from: Minuous;772462
I don't? Read through this thread again and you will see that I have responded to the comments of various people. Without resorting to ad hominem attacks as you are doing now. I've made this point before, but again: yes you can add extra bits to AROS to get a semi-usable system. That doesn't make it a usable system. Someone could get a bare CPU and add various bits to it to make it a usable system, that doesn't make it a usable system in its own right. You have to download extra bits to make it equivalent to something that already works fine out of the box. What good is that?

Also with AROS x86 you can't even do that; if a piece of software is not available in an AROS x86 version you can't use it at all. Unless they finally have working 68K emulation, which they didn't last time I checked. And like I and others have said before, there's no reason for any 68K user to bother with AROS: it's slow, missing features and ugly. Really, it has next to nothing to recommend it except for copyright issues, which seemed to be the main reason Toni Wilen was bothering with it, because it could be distributed freely with WinUAE, not because it was actually better. The same applies to various BIOS replacements that are included with various emulators. For best compatibility you use an authentic BIOS which, by definition, is 100% byte-for-byte identical. Substitute BIOSes are included for legal reasons only, generally the first thing one does is get an authentic ROM dump.



The main one is that they aren't palette independent. So users have to keep the default colours; if the user changes their palette all their old-style icons will look awful. And if the developer used a non-standard palette to begin with, you have to match your palette to theirs. Not everyone runs MagicWB. MagicWB doesn't even define more than 8 colours IIRC. The original icon format was designed for OS1.x which didn't support deep screens. Even if you assume that neither the developer nor the user has modified the colours from the default, you still can't guarantee what palette is in use. Eg. 1.x has a different default palette as compared to 2.x.


as you yourself rightly observe aros allows to detach amiga scene from parent enterprises who proved to be untrustworthy one after the other. secondly it allows to preserve the code base, which even if thor and olsen claim to have at hand, well i don intend to be rude, but everybody can be hit by bus and then his work will be lost unregarded good intentions. and last but not least it allows to fix and extend functionality, support more different probably cheaper and more economic platforms, therefore allows for variety of choices, which looks like an important issue in an individualistic society. i think its worth it. but its everybodys own choice.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: guest11527 on September 06, 2014, 05:48:07 PM
Quote from: biggun;772463
Isn't this the same with Linux for example?
Also Linux as it - is just a Kernel.
All the programs in Linux are gnu tools and do actually not belong to Linux.

Which is certainly true, and distributions - or people preparing distributions - invest quite some time to compile a selection of programs that work well together with the kernel.

However, for AmigaOs the situation is in so far more complicated as even some "outside the kernel" components might be required, and unlike typical Linux distributions and GNU tools, the binaries are typically non-distributable (unless you can still negotiate with the author or owner).

Also, Linux distributions compile and patch the user-space tools to match the needs of the distribution, probably fix some minor bugs here and there. That's also not possible for most AmigaOs programs as sources are not available.

One way or another: The task for AROS is much bigger than for Linux. There is no sufficiently large ecosystem of free and open source software to make the system self-sustainable. Or at least "not yet".

Thus, anyone complaining that AmigaOs sources "are not available" should then contribute to AROS - that seems to be the only logical consequence for me.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: smf on September 06, 2014, 06:05:53 PM
Quote from: TheMagicM;771705
What if it was released as open source...  I wonder how much better WB 3.x can actually get.


Check out AmigaOS4.1 or Morphos and you will find out ;) it will just be a lot slower on the old hardware.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: cgutjahr on September 06, 2014, 11:03:00 PM
Quote from: itix;772451
If there was 3.5/3.9 ROM chip with BVision support in boot menu it could have been much much better... dont you hate it when it stops booting and you dont have TV near? :)

The BlizzardPPC had a feature that would constantly copy the current screen from chip ram to BVision ram. It would be enabled if something was displayed during the boot process and disabled as soon as the first non PAL:Hires screen was opened. Display wasn't all that fast, but fast enough for BVision setup, ESM, or booting without startup-sequence.

Quote

Sometimes I was thinking my Amiga 1200 was better without those stupid complex expansions.

Yeah, a highly expanded A1200 is a major PITA if you're trying to get some real use out of it.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: psxphill on September 07, 2014, 07:55:04 AM
Quote from: Minuous;772453
Well, if you revert enough of OS3.5/3.9 you can turn it back to OS3.1.

"enough" is subjective. I consider the Amiga Technologies badge and the floppy hack on the A1200 to be trivial to revert, while I don't consider having to install a CD drive to be trivial.

I don't have a problem with icon or datatype changes, even a standard tcpip stack is a good idea. Some of the bundled software wasn't the best examples out there though, but it tried to gain traction by virtue of it being distributed on the official media.

Quote from: Minuous;772453
It's a bit like saying that a PPC Mac or Intel Mac isn't actually a Mac, only a 68K Mac is a real Mac. I suspect that if anyone went to a Mac forum and claimed such a thing there would be howls of derision.

Apple didn't go bankrupt with a seven year gap between new products. Also Apple certainly had opposition amongst it's user base when it switched to PPC and to Intel, it was just so long ago now and they've been so successful that people have moved on. Which makes the two situations quite different.
Title: Re: New improved intuition.library version from the Kickstart 3.1
Post by: itix on September 07, 2014, 12:56:40 PM
Quote from: cgutjahr;772477
The BlizzardPPC had a feature that would constantly copy the current screen from chip ram to BVision ram. It would be enabled if something was displayed during the boot process and disabled as soon as the first non PAL:Hires screen was opened. Display wasn't all that fast, but fast enough for BVision setup, ESM, or booting without startup-sequence.


Oh, indeed... you are correct.

Unfortunate how much Amiga knowledge one can forget.