[UserReview] Vampire V2-128 received and it's just pure p0rn.

[kolla]

In other words, FUD. Just what I thought. Thank you for confirming.

Oh wow, you know about "FUD"?

I did have a PicassoIV card at some point, and I also tried really hard to use P96 with CV64. It was pointless. I got rid of the PIV as it brought more hassle than I needed, was easier to use CSPPC along with CV64 than along with PIV. Then came the Mediator, and I was eyerolling. It took 5 years from I bought the Voodoo5+Mediator for them to work together, and in the meantime I borrowed a Voodoo3. The same stupid artifacts and bugs I had back with CV64 were still there with the Voodoo cards, and the user interface made me dream of editing xorg.conf by hand. Luckily with UAE for most part there is no need to deal with it, I belive last time I messed with it was with FS-UAE on DragonFlyBSD, just to test that PIV emulation was working before I installed OS4.1FE.

Your assumption that I am "just spreading FUD" is rather ignorant.

Actually, this might not be quite so...

I have no reason to believe that you have any rights to currently do any work with P96 unless I hear it from the original authors. I am aware that you are on the "thank you list", but that is not the same as having a license to do official development. The DDK was for hardware developers, and AFAIK you have no hardware that you are selling.

[guest11527]

Ok then so the "private" interface is the API for dealing with chipsets (hardware drivers) and various graphics cards.

Yes, indeed, tis is the case.

If I was reimplementing, speculating only here I admit, then I wouldn't bother with that end of it at all. I would just create a very simple system for the one chipset that I was supporting.

Unfortunately, there is nothing "simple" about that. The graphics library is really build around the blitter, and planar graphics, minterms, and a couple of blitter functionalities. It uses copperlists, and denise's sprite system.

The Vampire rtg graphics is chunky, not planar, has no hardware sprite and no copper list.

Any replacement of graphics hence has to deal with incompatible pixel formats (chunky, planar), the emulation of blitter min-terms, the emulation of sprites, and other elementary graphics and hardware primitives.

It's really all but simple.

I suspect that is what has been done because the Vampire implementation isn't a general purpose system meant to be reused with different chips.
It targets a single design, one done by the same "team" as the author, that supports little more than a framebuffer and some basic operations.

Yes, the vampire framebuffer is pretty simple indeed, and the driver is rather minimal. Mostly because it already uses many of the services that are natively available within P96.

We cannot know more with seeing the source code for it, or at least the team discussing it in more detail, however there's no reason to assume infringment of any license here.

Once again, if you depend on P96 services for your framebuffer, you're depending on a lot of work somebody has done. You also depend on the calling interface from P96 into the driver, which was only available on a license basis.

Yes, the framebuffer driver itself is pretty simple, but only because somebody else has put an enourmous amount of work into the P96 system to keep it that simple. Call me old fashioned, but I believe this is something worth paying for.

Hooking into "graphics.library" is pretty simple, and writing an "rtg.library" is almost trivial especially if you have access to the hardware designer who's written the underlying chip.

No, not at all. (-: The problem is that graphics doesn't have a well-defined interface for rtg graphics in first place. It really goes down to the blitter. So it's not that you have "just" to implement a handful of graphics primtives and you're done. It's more that you have to re-implement a major part of the graphics.library.

Actually, this is pretty much what P96 is: A better implementation of graphics.

So for example, due to the lack of a customized interface, a lot of work in graphics is replicated in P96, as for example line clipping and line drawing, text drawing, text clipping and so on.

It's really a design problem graphics has of not defining any useful interfaces for other graphics systems than the native one.

Now as to the second part about how you feel about it, well they took a look at what was offered and the licensing terms. They didn't like them or they decided that they were unnecessary given what they hoped to achieve.

Oh, sure, you can simply say that you didn't like the terms. Then you need to come up with better terms and negotiate. It's not that such discussions are quick, and decisions are easily made. It usually takes some time to come up with the result. In this particular case, it only took a week.

The point is not so much whether a decision has been made for or against a given solution. The point is rather that now, at this point, the decision must been accepted with full consequences. And the full consequences are that if you don't want P96, you cannot create a driver that depends upon it. I believe this is a pretty simple consequence.

Sorry that it didn't work out for the P96 API authors but I just can't see what the problem is here. Unless nefarious dealings mean that propriatary code was used in this SAGA P96 implementation it seems that it should be quite legal.

How you can build a code against a proprietary interface is one question. Whether this is legal a second.

But what I don't really like is first to say "we don't want to pay for this interface", but then also use it in first place.

Call me old fashioned, but if the interface was good enough for me to work with, it should also be good enough for me to pay for.

[kolla]

Authors want payment.

Not all authors. As for the P96 authors, they want to be left the heck alone, and never be bothered about P96 ever again. I suggest we as a community grant them this wish.

[nicholas]

All these recent happenings have pretty much made me convinced that the sooner AROS is a drop in replacement for OS3.x the better for the Amiga community.

The death of the proprietary vultures can't come soon enough.

[AJCopland]

Call me old fashioned, but if the interface was good enough for me to work with, it should also be good enough for me to pay for.

As a gesture yeah sure, but legally? No.

Otherwise every header, function interface, dll, library etc would need to be licensed on a case-by-case or batch basis.
The only ones trying that sort of rubbish are Oracle-vs-Google with the Java library headers.

I'm still not sure what's going on with this stuff. I mean what part of P96 is it actually *using* and therefore what is the fuss about? Looking at the source code I see a lot of calls into AROS and... that's it, no P96 specific stuff all.

So what part of P96 does it use? Is it a library loaded by something to do with P96? Is that what the problem is?

I'm still struggling to understand what the back n' forth between you all is actually over.

Yes if someone is using a library or software that needs a license, and that license has a fee, then I think that someone should pay that fee.
However, I can't figure out what software/library is being used that would require someone to be paid.

[guest11527]

I did have a PicassoIV card at some point, and I also tried really hard to use P96 with CV64. It was pointless. I got rid of the PIV as it brought more hassle than I needed, was easier to use CSPPC along with CV64 than along with PIV. Then came the Mediator, and I was eyerolling. It took 5 years from I bought the Voodoo5+Mediator for them to work together, and in the meantime I borrowed a Voodoo3. The same stupid artifacts and bugs I had back with CV64 were still there with the Voodoo cards, and the user interface made me dream of editing xorg.conf by hand.

So, once again, what are these bugs and stupid artifacts? FUD?

For CGFx, I can point you at particular bugs. For example, its line clipping is incorrect, and it does not adjust the line patterns correctly. That's one of the bugs I remember. I don't know whether this has been fixed at this time, but my GVPSpectrum worked a lot better with P96 than with CGfx.

Picasso96TNG worked pretty well for me for setting up the screen modes, not much of a problem there. There might have been an older configuration tool at some point, but that was much before I entered.

The P96 CV64 driver is probably unmaintained, and indeed, if this was your hardware, CGfx would have been the better choice as its driver came from its manufacturer, no surprise really.

For the PIV and the PII (and the similar GVPSpectrum) the situation was quite reverse, so it's hard to come up with a general recommendation. The P96 PiP-functionality was particularly tuned for the PIV, for example.

I have no reason to believe that you have any rights to currently do any work with P96 unless I hear it from the original authors.

I doubt that they would talk to you. Actually, I do not even know why I'm doing as I would not really expect any particular useful answer from you in first place.

I am aware that you are on the "thank you list", but that is not the same as having a license to do official development. The DDK was for hardware developers, and AFAIK you have no hardware that you are selling.

I've neither hardware nor software to sell, nor was I ever selling hardware for the Amiga.


And no, I don't have a license at this point, but it was part of the discussion to get an official one to work on P96. Actually, I worked on P96 back then, with agreement with the authors. We didn't need a particular written icense back then. A word (or a mail) among honest people was enough in those days. That's not the typical "legal vs. illegal" bullsh*t I see here.

My argument is quite simple: If it's good enough to use it in your products, it should be good enough to pay for. Something Elbox already got particularly wrong.

Anyhow, all of this is history anyhow. My mood to work on anything Amiga related has gone missing lately, even more with folks like you on board.

[kolla]

All these recent happenings have pretty much made me convinced that the sooner AROS is a drop in replacement for OS3.x the better for the Amiga community.

True, and this also makes it a lot easier for people to do the mental migration to modern hardware that AROS also runs on :laughing:

[grond]

Hooking into "graphics.library" is pretty simple, and writing an  "rtg.library" is almost trivial especially if you have access to the  hardware designer who's written the underlying chip.

It's not trivial and it is not what was done here. What was done wasn't difficult (for Jason, that is) because indeed there is very little in the apollo RTG subsystem to set up. The documentation is somewhere in the apollo forum. Basically you set some bits in some registers thereby selecting the colourdepth and resolution you want.

The difficult part is indeed the patching of the graphics.library. And that has not been reimplemented by the apollo team which  means that you need a standard picasso installation and then install the apollo picasso drivers on top of that picasso installation. This is still legal because the picasso files are distributed freely with permission by their authors (e.g. on aminet).

As already mentioned before the work of the original authors is respected and acknowledged. They are invited to talk to the apollo team directly.

*Sigh*. Again, you want to find a twist around it. What's so hard to understand? Authors want payment. You don't want to pay, but still use it? Is this a fair trade in your language?

It may not be fair but it is legal. That's an important difference.

I don't know what he did or not did, but one may wonder where the API docs came from. Such information is not on file or on github. It's at least a pretty questionable practise.

AFAIK the "documentation" came from looking at the open-source implementation in uaegfx.

No. Tobias and Alex didn't want to sell directly to Gunnar. Too much hassle for them. The business was planned indirectly through Hyperion, which would have bought full rights on P96 (or probably even have them bought, right now).

This is almost funny. First you use the author's hurt feelings as an argument and then you say they weren't even interested enough to take part in the negotiations and of all possible companies left it to Hyperion to make a deal? And Hyperion itself negotiated with a potential licensee while trying to take over the rights to the product to be licensed? Do you understand what you are saying there? I had to look up the English term because I don't deal with penal law: this could be a case of breach of trust on the side of the proxy ("Untreue" in German).

Maintenance would have been done through an external team, again to be  paid by Hyperion (by people like me, for example). No, I do not  represent either Hyperion, nor the P96 developers. I'm only very  remotely related to this at all.

Hyperion pays people? I hope the contractors demand up-front payment. People "like you" but not you? Or do you have an interest in this deal yourself? As you know, the devil fools with the best laid plans. Sorry if it didn't work out.

[kolla]

So, once again, what are these bugs and stupid artifacts? FUD?

You expect me to to dig out 10-20 year old screenshots? Sorry, I have not kept them around AFAIK.

For CGFx, I can point you at particular bugs. For example, its line clipping is incorrect, and it does not adjust the line patterns correctly. That's one of the bugs I remember. I don't know whether this has been fixed at this time, but my GVPSpectrum worked a lot better with P96 than with CGfx.

Again - CGfx merged into MorphOS, and to a degree AROS. Where did P96 go? OS4, where you can still mess around with the same darn Prefs thingy as back in the 90ies :laughing:

Picasso96TNG worked pretty well for me for setting up the screen modes, not much of a problem there. There might have been an older configuration tool at some point, but that was much before I entered.

The program that comes with it is called Picasso96Mode, it is even there in OS4.1FE (!!). Picasso96TNG I vaguely remember, it gives me 8 hits on Google.

The P96 CV64 driver is probably unmaintained, and indeed, if this was your hardware, CGfx would have been the better choice as its driver came from its manufacturer, no surprise really.

For the PIV and the PII (and the similar GVPSpectrum) the situation was quite reverse, so it's hard to come up with a general recommendation. The P96 PiP-functionality was particularly tuned for the PIV, for example.

I wanted multimonitor setup, it was a hassle. Eventually when I had CVPPC, the choice was clear - get rid of the PIV and P96 too. Sadly P96 came back when I tried to put together an A4000 with Mediator 4000Di and the voodoo cards.

I doubt that they would talk to you. Actually, I do not even know why I'm doing as I would not really expect any particular useful answer from you in first place.

They do not have to talk with me, they just need to issue an official statement, on behalf of themselves and not via you.

And no, I don't have a license at this point, but it was part of the discussion to get an official one to work on P96. Actually, I worked on P96 back then, with agreement with the authors. We didn't need a particular written icense back then. A word (or a mail) among honest people was enough in those days. That's not the typical "legal vs. illegal" bullsh*t I see here.

This exercise in BS is mostly performed by you though.

My argument is quite simple: If it's good enough to use it in your products, it should be good enough to pay for. Something Elbox already got particularly wrong.

Do you know the difference between "should" and "must"?

Anyhow, all of this is history anyhow. My mood to work on anything Amiga related has gone missing lately, even more with folks like you on board.

Good for you! Take a vacation from Amiga, the world is bigger and life is short!

[AJCopland]

As long as it is based on the P96 API, it is. There is likely a native CGfx API, though.

I do not know what the conditions are for a third party to offer a CGfx driver. I can only tell you want the conditions for the P96 API are.

Currently, the drivers use the P96 API, and *that* is not valid.

This is only true if it uses the code, compiled libraries which require a license. If it's reimplementing the API based on the interface definitions, i.e. those exported to shared libraries and headers, then it's perfectly legal.

You can copyright a specific implementation, but there is nothing to stop someone else from implementing it themself without using any of the existing code or libraries and then selling or open sourcing that implementation.

[AJCopland]

It's not trivial and it is not what was done here. What was done wasn't difficult (for Jason, that is) because indeed there is very little in the apollo RTG subsystem to set up. The documentation is somewhere in the apollo forum. Basically you set some bits in some registers thereby selecting the colourdepth and resolution you want.

The difficult part is indeed the patching of the graphics.library. And that has not been reimplemented by the apollo team which  means that you need a standard picasso installation and then install the apollo picasso drivers on top of that picasso installation. This is still legal because the picasso files are distributed freely with permission by their authors (e.g. on aminet).

As already mentioned before the work of the original authors is respected and acknowledged. They are invited to talk to the apollo team directly.

Ah, thanks Grond I think that answers it for me

[nicholas]

This is only true if it uses the code, compiled libraries which require a license. If it's reimplementing the API based on the interface definitions, i.e. those exported to shared libraries and headers, then it's perfectly legal.

You can copyright a specific implementation, but there is nothing to stop someone else from implementing it themself without using any of the existing code or libraries and then selling or open sourcing that implementation.

Which is exactly what the P96 authors did with the CGX API, but apparently what's good for the goose is not good for the gander.

[Terminills]

I don't know what he did or not did, but one may wonder where the API docs came from. Such information is not on file or on github. It's at least a pretty questionable practise.

A quote from Jason...

Well, _I_ didn't get the SDK from Toni nor Cloanto.

and

I would be willing to itemize where I got every line from, if need be.

As a personal friend of mine I take offense to your questioning his ethics.

[kolla]

As a personal friend of mine I take offense to your questioning his ethics.

Someone earlier on this thread mention FUD :hammer:

[grond]

As a personal friend of mine I take offense to your questioning his ethics.

Give him a little rest. Thomas wrote the first vampire/apollo RTG driver hoping that the whole project would go the route he favours. His work seems now to have been done in vain because it was replaced by a second driver. I can understand this doesn't feel good. And the new driver was written in such a short time (I'm still awed) that I can also understand that somebody who didn't witness its progress would wonder about whether this could be done without peeking at some illegitimate resource.

Just a few hours ago Jason asked when he will finally get the SDcard hardware documentation. He brought it up only yesterday and I wonder whether BigGun & Co can deliver fast enough to keep him happy. If they do, we can probably expect the Sdcard driver by the end of the week... :lol:

It's such a pity for us that his interests have moved away from AROS/Amiga. Just imagine what he could do if this was his main project.

[Terminills]

Give him a little rest. Thomas wrote the first vampire/apollo RTG driver hoping that the whole project would go the route he favours. His work seems now to have been done in vain because it was replaced by a second driver. I can understand this doesn't feel good. And the new driver was written in such a short time (I'm still awed) that I can also understand that somebody who didn't witness its progress would wonder about whether this could be done without peeking at some illegitimate resource.

Just a few hours ago Jason asked when he will finally get the SDcard hardware documentation. He brought it up only yesterday and I wonder whether BigGun & Co can deliver fast enough to keep him happy. If they do, we can probably expect the Sdcard driver by the end of the week... :lol:

It's such a pity for us that his interests have moved away from AROS/Amiga. Just imagine what he could do if this was his main project.

His sugar printer is pretty impressive too.   But yes Jason's work and speed is very impressive(3 days for the RTG driver).