Picasso 96 driver for ECS/AGA

[Gorf]

Originally Posted by funK

...that thread instantly becomes a constant flow of closed source whining...

It did not.
Just putting some fake news about OSS straight.

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

[Thomas Richter]

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.

[kolla]

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.

[Gorf]

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

[grelbfarlk]

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.

[kolla]

Originally Posted by Gorf

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?

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.

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?

[grond]

Originally Posted by kolla

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.

[kolla]

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

[grond]

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.

[Gorf]

Originally Posted by kolla

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

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

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.

[Thomas Richter]

Originally Posted by grond

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]

Originally Posted by grond

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.

[Bruce Abbott]

Originally Posted by Thomas Richter

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.

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.

[Thomas Richter]

Originally Posted by Bruce Abbott

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.

Originally Posted by Bruce Abbott

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.

[grond]

The way I heard it P96 contains large chunks of disassembled code of layers.library that then get built into a P96 binary.

[Thomas Richter]

Originally Posted by grond

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.

[kolla]

[aros-sg]

Originally Posted by Thomas Richter

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:

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);
  }

[Thomas Richter]

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.

[kolla]

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.