English Amiga Board


Go Back   English Amiga Board > News

 
 
Thread Tools
Old 31 January 2019, 17:12   #81
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 709
Quote:
Originally Posted by funK View Post
...that thread instantly becomes a constant flow of closed source whining...
It did not.
Just putting some fake news about OSS straight.

Quote:
@Thomas Richer
...
Should you have a Paypal account, please let me know and I'll be more than happy to send you a little tip: you truly deserve a gold medal, not this constant and tireless bashing.
He does and I did thank him here earlier and nobody is questioning his expertise or skillset.

Please do not mistake the challenging of certain decisions as "bashing".
Thank you.
Gorf is offline  
Old 31 January 2019, 17:55   #82
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 55
To all: Please don't forget who earned the money: Tobias and Alex did. They did most of the work, which was a tremedous task because P96 is more or less a reimplementation of the graphics system. Jens paid them off, because he had the money in the pocket, not one of us. While I do not know exactly, to my knowledge this was a high four-digit amount, if not one digit more - to give you figures.

So please, with all necessary respect: Remember that you pay the authors, even though indirectly. They really earned it. I did relatively little compared to them.
Thomas Richter is offline  
Old 31 January 2019, 20:02   #83
kolla
Registered User
kolla's Avatar
 
Join Date: Nov 2007
Location: Trondheim, Norway
Posts: 1,721
It was mentioned somewhere (I think here on EAB, recently), that Tobias and Alex had access to the OS sources when making P96. It strikes me as a little odd that someone could look at OS sources, and write code that is then theirs and sold as a product. I am not suggesting anything, but some clarification could be nice.
kolla is offline  
Old 31 January 2019, 20:19   #84
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 709
Well - since the sources were leaked long ago anyone can have a look at the sources.
That does not change anything as long as you are not trying to recreate the OS (like AROS) - any other tool/program is still ok - there is no conflict.

Think of Linux: everyone is invited to look at the sources, but nobody will dispute that you can write your very own program (even closed source) for Linux - it will be yours alone and you can sell it as a product.

Even Microsoft allows third parties to look at their source code (and NT was leaked in the 90s).
Gorf is offline  
Old 01 February 2019, 04:58   #85
grelbfarlk
Registered User

 
Join Date: Dec 2015
Location: USA
Posts: 1,597
Does anyone know whether multi-monitor support as in extending workbench between new monitors is possible with P96? I know it doesn't support it currently but someday I think it would be great if you could have the AGA and a RTG to have a Workbench spanning multiple monitors.

Shapeshifter could do that 20-some years ago but the native OS could not.

It would be somewhat limited in usefulness as the resolution between monitors ideally was about the same as in 640x480 AGA and 800x480 RTG.
grelbfarlk is offline  
Old 01 February 2019, 07:34   #86
kolla
Registered User
kolla's Avatar
 
Join Date: Nov 2007
Location: Trondheim, Norway
Posts: 1,721
Quote:
Originally Posted by Gorf View Post
That does not change anything as long as you are not trying to recreate the OS (like AROS) - any other tool/program is still ok - there is no conflict.
So is everyone in their right to do this? I can look at the sources for scsi.device, and based on them write a "new and improved" scsi.device, which I can claim is all mine and sell?

Quote:
Think of Linux: everyone is invited to look at the sources, but nobody will dispute that you can write your very own program (even closed source) for Linux - it will be yours alone and you can sell it as a product.
That is a very different situation, and you can bet your butt that many will dispute your ownership of code if you replace for example entire graphical layer of the kernel with your own commercial code.

Quote:
Even Microsoft allows third parties to look at their source code

Also a very different situation, that is what "open" used to mean (OpenVMS, OpenSolaris, OpenSTEP, OpenVieew etc) and this was/is common. But Picasso96 was released in 1996/97, so who allowed it?
kolla is offline  
Old 01 February 2019, 08:33   #87
grond
Registered User

 
Join Date: Jun 2015
Location: Germany
Posts: 537
Quote:
Originally Posted by kolla View Post
It was mentioned somewhere (I think here on EAB, recently), that Tobias and Alex had access to the OS sources when making P96. It strikes me as a little odd that someone could look at OS sources, and write code that is then theirs and sold as a product. I am not suggesting anything, but some clarification could be nice.

Since they did a lot of work, they can still sell there rights to that work. The question is whether the purchaser can use what he bought without permission from a third party and thus what price he would be willing to pay. Here Hyperion was a party in the deal which supposedly exempts P96 from copyright infringement.
grond is offline  
Old 01 February 2019, 10:49   #88
kolla
Registered User
kolla's Avatar
 
Join Date: Nov 2007
Location: Trondheim, Norway
Posts: 1,721
@grond
Picasso96 was released a long time before Hyperion even existed, years before H&P and OS 3.5 even. The only ones who could have granted access to sources legally would have been Commodore or Amiga Technologies/ESCOM - rumours had it that Petro were handing out OS sources east and west at the time, so I guess that's how it could have happened. Village Tronic that made the Picasso cards, were also publishing OS 3.1, so perhaps it sticks even deeper. The Village Tronic OS 3.1 release was also controversial, I know.

Last edited by kolla; 01 February 2019 at 11:27.
kolla is offline  
Old 01 February 2019, 13:59   #89
grond
Registered User

 
Join Date: Jun 2015
Location: Germany
Posts: 537
I'm not sure how any of this is relevant today. Assuming that Hyperion's involvement and consent put the legal issues straight, it doesn't really matter how legal the release was back then. And the rumours I heard said that it was disassembled OS code, not high-level language OS code that went into some parts of P96.
grond is offline  
Old 01 February 2019, 16:45   #90
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 709
Quote:
Originally Posted by kolla View Post
So is everyone in their right to do this? I can look at the sources for scsi.device, and based on them write a "new and improved" scsi.device, which I can claim is all mine and sell?
It is a little bit like with drugs: you are not allowed to possess or sell them, but it is no felony to take them.
So yes: you can in theory look at the sources.

And you can even write a improved scsi.device if it is NOT based on the original code - if it it is based only on your knowledge of the inner workings it would be still ok. (As you see it becomes slightly grey here, as you picked a part, that already exists in the old OS - this was not the case with P96.)

Quote:
(Linux)
That is a very different situation, and you can bet your butt that many will dispute your ownership of code if you replace for example entire graphical layer of the kernel with your own commercial code.
Not really: it is called kernel-blob and while I do not like it, most distributions do come with closed source graphics drivers.
Nobody disputes the ownership of Nvidia's drivers...

Quote:
Also a very different situation, that is what "open" used to mean (OpenVMS, OpenSolaris, OpenSTEP, OpenVieew etc) and this was/is common. But Picasso96 was released in 1996/97, so who allowed it?
I don't know. I am not even sure they did - you came up with it

But I do not see the relevance here, since "looking at something" does not change anything at all.
Gorf is offline  
Old 01 February 2019, 22:45   #91
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 55
Quote:
Originally Posted by grond View Post
Since they did a lot of work, they can still sell there rights to that work. The question is whether the purchaser can use what he bought without permission from a third party and thus what price he would be willing to pay. Here Hyperion was a party in the deal which supposedly exempts P96 from copyright infringement.
Hyperion does have a (non-exclusive, not transferable) license for P96 which was later on extended to a source code license for PPC only. They did not and still do not have sufficient rights to sub-license the sources to someone else (i.e. no transferable rights). This would have required another extension, or buying the whole thing. That, however, did not materialize. So there was no deal with Hyperion. Instead, after discussing multiple options, the two sold it to Jens. This deal, of course, does not touch other agreements, so the license to Hyperion still holds. I do not know how these two agreed, but apparently, there is no conflict I am aware of.
Thomas Richter is offline  
Old 01 February 2019, 22:53   #92
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 55
Quote:
Originally Posted by grond View Post
I'm not sure how any of this is relevant today. Assuming that Hyperion's involvement and consent put the legal issues straight, it doesn't really matter how legal the release was back then. And the rumours I heard said that it was disassembled OS code, not high-level language OS code that went into some parts of P96.
The problem P96 has to solve here is how to handle an OpenScreen() on an rtg.screen. The problem is that intuition calls AllocBitMap() for the new screen. But at this time, no information on which monitor this bitmap is for, so P96 cannot know whether this bitmap should go to the graphics board, or to the native chipmem.

What P96 (up to 2.3) does here is that it "collects" some information intuition "leaves by pure chance" in registers, as for example the ViewMode of the new screen. You cannot do that without disassembling parts of intuition.

CGfx has to do something similar, but I do not know the details there as I haven't seen its source.

All this will have to change, of course. P96 already had (even in the Aminet version) an extended interface for AllocBitmap() I cooked up back then, though it was never activated. And of course, the counterpart for this interface in intuition is also missing (including 3.1.4), and ditto in graphics.

Betatesters do have access to a version where this is all cleaned up, and one does not have to "peek registers", but rather, intuition tells to which monitor the bitmap should go, but that did not make it into 3.1.4.
Thomas Richter is offline  
Old 02 February 2019, 01:04   #93
Bruce Abbott
Registered User

Bruce Abbott's Avatar
 
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 132
Quote:
Originally Posted by Thomas Richter View Post
What P96 (up to 2.3) does here is that it "collects" some information intuition "leaves by pure chance" in registers, as for example the ViewMode of the new screen. You cannot do that without disassembling parts of intuition.
It might be easier and more reliable to disassemble the ROM code, but not necessary. In many cases just analyzing the register contents alone could be enough, eg. the bit patterns for commonly used screen modes are easily recognizable.

And of course, having the source code wouldn't help much because the 'pure chance' register contents would be dependent on the particular compiler and its settings.

Quote:
Originally Posted by Gorf
A problem often seen in old closed source code is the lack of comprehensive comments and documentation, that makes it hard to understand
That affects a lot of open source code too.
Bruce Abbott is offline  
Old 02 February 2019, 10:00   #94
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 55
Quote:
Originally Posted by Bruce Abbott View Post
It might be easier and more reliable to disassemble the ROM code, but not necessary. In many cases just analyzing the register contents alone could be enough, eg. the bit patterns for commonly used screen modes are easily recognizable.
It is not that simple. The viewmode -which is exactly the missing information - does not "lie around" in the registers. You need to fetch the intuition stackframe from the registers, from there the tag list for OpenScreen, and there you find the view mode. So it is double indirection.
Quote:
Originally Posted by Bruce Abbott View Post
And of course, having the source code wouldn't help much because the 'pure chance' register contents would be dependent on the particular compiler and its settings.
Which is precisely true. The register allocation P96 is compiled for is dependent on the GreenHills compiler intuition was compiled with, and which is missing these days. Intuition V45 was recompiled with SAS/C, and for this particular reason, contains a "kludge" that fills the registers with what P96 needs. Which is also the reason why CGfx does not work anymore with intuition V45 because nobody knows which registers have to be filled how to deliver this missing information to it.
Thomas Richter is offline  
Old 02 February 2019, 10:41   #95
grond
Registered User

 
Join Date: Jun 2015
Location: Germany
Posts: 537
The way I heard it P96 contains large chunks of disassembled code of layers.library that then get built into a P96 binary.
grond is offline  
Old 02 February 2019, 12:19   #96
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 55
Quote:
Originally Posted by grond View Post
The way I heard it P96 contains large chunks of disassembled code of layers.library that then get built into a P96 binary.
Certainly not. P96 shipped with "fastlayers" but this included only a single patch to MoveSizeLayers of the layers library which was not based on original code, and only made a single optimization by switching the layer to simple refresh, then move the layer, then turn it back to smart if necessary, and then fix up the damage list.

I should know, I did layers V45 then later on. But this was about two years later. Actually, the two asked me whether I would work on a more complete "fast layers" at the same time I fixed bugs in P96, but I did not have the time to look into layers. This only started later with the Os4 activities, remembering the implications to P96 of course.

So, no, there is nothing in P96 and nothing in fastlayers, and fastlayers is not related to layers or layers V45.
Thomas Richter is offline  
Old 02 February 2019, 12:20   #97
kolla
Registered User
kolla's Avatar
 
Join Date: Nov 2007
Location: Trondheim, Norway
Posts: 1,721

kolla is offline  
Old 02 February 2019, 15:41   #98
aros-sg
Registered User

 
Join Date: Nov 2015
Location: Italy
Posts: 16
Quote:
Originally Posted by Thomas Richter View Post
It is not that simple. The viewmode -which is exactly the missing information - does not "lie around" in the registers. You need to fetch the intuition stackframe from the registers, from there the tag list for OpenScreen, and there you find the view mode. So it is double indirection.

"Not that simple". Wouldn't something like this be more simple:


Code:
struct TagList *openscreen_taglist;
struct SignalSempahore openscreensem; /*single thread open screen calls */


OpenScreen_Patch(newscreen, taglist):
  ObtainSemaphore(&openscreensem);
  openscreen_taglist = taglist;
  retval = (*Original_OpenScreen)(newscreen, taglist);
  ReleaseSemaphore(&openscreensem);
  return retval;


AllocBitmap_Patch(w, h ...):
  if (detect_this_call_coming_from_intution_openscreen_to_alloc_screen_bitmap)
  {
     taglist = openscreen_taglist;
     viewmode = extract_viewmode(taglist);
  }
aros-sg is offline  
Old 02 February 2019, 17:56   #99
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 55
Simple yes, unfortunately not completely functional. Of course, we have both OpenScreen() and OpenScreenTagList(), but leaving this aside, this is unfortunately not the only way how intuition can open a screen. The tricky case is the workbench.

If a program (e.g. DPaint) opens its own screen, and then closes the workbench, and the program then closes its own screen again, intuition triggers the workbench open again, to avoid that the user "pulls the rug" under its feed - so that the workbench becomes accessible again. Unfortunately, this does not go through the OpenScreen LVO, so you cannot capture it like this. Hence, you would not be able to safely run the workbench on an RTG screen with this approach alone.
Thomas Richter is offline  
Old 03 February 2019, 11:12   #100
kolla
Registered User
kolla's Avatar
 
Join Date: Nov 2007
Location: Trondheim, Norway
Posts: 1,721
Picasso 96 driver for ECS/AGA

It seems that there is software that "crashes" with "Native" and P96... Ranchero goes 8000 000B and DPaint (4.1 and 5.0) brushes are garbled. No hacks and patches. rtg.library from aminet (http://aminet.net/package/driver/video/Picasso96). Just me?

Edit: DPaint 4.6 actually doesn't garble brushes. DpaintV also just bummed 8000 000B on me when attempting to "pick up" a brush.

Last edited by kolla; 03 February 2019 at 20:05.
kolla is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Indivision AGA MK2 driver PeteJ support.Hardware 2 10 August 2014 12:51
TRADE: Picasso II for Indivision ECS Fingerlickin_B MarketPlace 2 20 April 2014 06:12
Picasso II and Indivision ECS Dijerydack support.Hardware 8 24 September 2012 09:51
Driver for Picasso II (A2000 kick 3.1) 8bitbubsy support.Hardware 1 16 April 2011 08:44
FS : Picasso IV, CompuServe AGA Scandoubler, C1581 coze MarketPlace 0 22 January 2009 12:35

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 14:26.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.09354 seconds with 13 queries