Picasso 96 driver for ECS/AGA

[kolla]

Originally Posted by SpeedGeek

it's too technical for some users.

And the same can be said about P96 - that is why this "driver" was made in the first place, all it does is load rtg.library and set some "too technical" env variables, this was already possible since a long time. I understand that there is a certain desire to replace FBlit etc with something "system friendly", but that will never happen without "Native" support in P96 doing similar compromises as FBlit does, when it comes to compatibility, "system friendliness" vs speed and memory foot print.

[Thomas Richter]

Which "compromises" do you actually talk about? P96 implements the full API to work with bitmaps and bobs.

[Thomas Richter]

Originally Posted by SpeedGeek

Why do people here expect P96 to be faster (or just as fast) as Fblit? Did you compare the size of the P96 library + drivers to the Fblit library + executable? Do you understand that P96 has a "Lot" of code to handle PC graphics board (SVGA) chips?

Actually, that is not quite correct. The logic to drive SVGA chips is in the chips and boards drivers. What the rtg.library provides is a full fledged framework to make this logic accessible to graphics. That is, there is a lot of code to implement blitting on chunky bitmaps (8 bit, 15 bit, 16 bit, 24 bit, 32 bit, in various bit arrangements) in P96 you would not need natively, but there is also a lot of code to "associate" bitmaps with its properties and layouts, something that is only available to a limited degree in FBlit. The reason why the rtg.library is as large as it is is because there are so many combinations of minterms and masks that need to be considered, and it is pretty hard to miss some, or implement not all of them correctly.

Originally Posted by SpeedGeek

If you are too lazy to RTFM the docs, you can use the default settings for either Fblit or P96. But you might be able to tweak the performance a little if you modify the default settings (at you own risk).

The problem with FBlit is that it makes settings accessible to the user that do not make sense to begin with, some of them dangerous or useless, and some of its functions are implemented incorrectly or incompletely, such as performing write-accesses to read-only chip registers (for QSBlit()) or such as not implementing all min-terms.

One of the reasons why the rtg.library is as large as it is is that there are plenty of functions that handle all minterms, that is, many possible options it has to support to give a complete blitter emulation. We noticed during 3.1.4 testing that popular "graphics emulations" typically do not implement all these combinations correctly or completely, giving rise to graphic glitches or even memory trashing.

[kolla]

Originally Posted by Thomas Richter

Which "compromises" do you actually talk about?

The compromises that makes systems using FBlit instead of P96 faster, obviously.

What are your expectations with this native driver? That people replace FBlit and use P96 instead?

[Thomas Richter]

Originally Posted by kolla

The compromises that makes systems using FBlit instead of P96 faster, obviously.

What use is a fast system if it doesn't work correctly? First make it work. Then make it fast.

Originally Posted by kolla

What are your expectations with this native driver? That people replace FBlit and use P96 instead?

It fills a gap in the expectations of the users. There was some arguing back and forth that CGfx supports a "native driver" for the chipset and that this would be of an advantage. I do not know what exactly CGfx does, but probably quite something similar than this "driver": Using the CGFx native functions that are "present anyhow" to move native graphics out of chipmem if possible. Of course the same was possible all along with P96 to begin with, but many users did not know how to activate this feature.

Which graphics system people use I do not care, but I do care receiving bogus bug reports that stem from using incomplete or inappropriate software. FBlit is such a source of bogus bug reports - certainly not the only one. If there is a simple way to provide users an alternative that has been proven more robust and better tested, and it is simple to provide such an alternative, then why not.

Unlike what you seem to imply, I do not earn any money from P96.

[Romanujan]

do not know what exactly CGfx does, but probably quite something similar than this "driver"

Not really. CGX AGA is a real driver, it provides CGX API, so that one can run CGX-only software on AGA-only systems. At least in theory, as the driver has issues. What's nice, is that CGX AGA driver actually replaces native chipset modes with CGX-enhanced ones. Besides, I think I read that you should use FBlit with it, just disable some options (never tried this, though).

Unlike what you seem to imply, I do not earn any money from P96

If you did work on the release, and does not earn anything from it - than I'm somewhat less happy... holly crap, people working on a commercial product SHOULD earn money if the product turns out to be profitable.

[kolla]

Originally Posted by Thomas Richter

Unlike what you seem to imply, I do not earn any money from P96.

I never implied any such nonsense.

What I do imply is that you rather see people use the locked garden of P96, than contribute to improve FBlit, which is open source.

[aros-sg]

Originally Posted by Thomas Richter

No, it does not. There are no tooltypes to configure, and there are no issues to work around, and there is no config file you need to play with. You click on the icon and it works. .

Well, but without options what about things like blits between chipram bitmaps and chipram bitmaps (you may still have those as fast ram may become full and bitmaps end up in chip ram once again, or if bitmaps are allocated by hand and not AllocBitMap()). On slow machines this blits may be faster with original blitter routines. On faster machines they may be faster with cpu blit routines.

And what about apps which maybe don't like fastram bitmaps at all (but are still coded legally: -> OwnBlitter(); ...; DisownBlitter()). Deluxe Paint?). With an option you may be able to disable fast ram bitmaps only for apps like these but still have them enabled for pretty much everything else.

[Thomas Richter]

Originally Posted by kolla

I never implied any such nonsense.

What I do imply is that you rather see people use the locked garden of P96, than contribute to improve FBlit, which is open source.

Then, why is this such a nasty program if it is all "open source", and why don't you just get along and help improving it, if it is open source?

[Thomas Richter]

Originally Posted by aros-sg

Well, but without options what about things like blits between chipram bitmaps and chipram bitmaps (you may still have those as fast ram may become full and bitmaps end up in chip ram once again, or if bitmaps are allocated by hand and not AllocBitMap()).

Not a problem. P96 keeps a hash list of bitmaps, and it knows which bitmaps are "its own" bitmaps, and which bitmaps are not. Otherwise, rtg would hardly ever work because quite a couple of programs "roll their own" bitmaps. Including some from the 3.1 workbench, to name prominent examples.

Originally Posted by aros-sg

On slow machines this blits may be faster with original blitter routines.

Then, why would you install this driver in first place?

Originally Posted by aros-sg

And what about apps which maybe don't like fastram bitmaps at all (but are still coded legally: -> OwnBlitter(); ...; DisownBlitter()). Deluxe Paint?).

DPaint is actually working fine as it uses Os functions, so no issues. If you bang the hardware yourself... well, that's then pretty much your problem, of course.

[Thomas Richter]

Originally Posted by Romanujan

Not really. CGX AGA is a real driver, it provides CGX API, so that one can run CGX-only software on AGA-only systems.

Oh, that shouldn't be a problem with P96 either. As far as the rtg.library is concerned, the bitmaps are just "regular planar bitmaps", so its functions work on it "as is", and so do the "cgfx" emulated functions. Of course, they are still planar, so if you request "direct access" to the bitmap, don't expect that you get anything "chunky". VGA hardware can also do planar, it is - as far as P96 is concerned - just another planar bitmap that runs, however, not on a VGA core.

There are no new screen modes - this is all handled by graphics. So for that, one would need to write a new monitor driver. Admittedly, this is another black art (I attempted to document this a bit, see aminet), but nothing stops you. All this would do is just replicate code in P96 that is present in Graphics, so there is nothing to loose or to gain.

Originally Posted by Romanujan

If you did work on the release, and does not earn anything from it - than I'm somewhat less happy... holly crap, people working on a commercial product SHOULD earn money if the product turns out to be profitable.

P96 received bug fixes that "piled up" on my side over the years, so I could have either thrown them away or just integrate them.

[kolla]

Originally Posted by Thomas Richter

Then, why is this such a nasty program if it is all "open source"

Because, like is so much software on this platform, the open sourcing was done as an after thought, a decade and more after all "nastiness" had already been done.

and why don't you just get along and help improving it, if it is open source?

Indeed, why don't you, since you have full overview of everything that is wrong with it.

[DamienD]

Give it a rest kolla; it's getting really boring now...

All I see you do is tell people what software / projects you believe should be open source (and then constantly keeping banging on about); not to mention what they should / shouldn't work on while doing sweet FA yourself

Thomas is contributing to software / projects free of charge, for the community, plus trying to support as best as he can. Hats off to this man

[kolla]

Originally Posted by DamienD

All I see you do is tell people what software / projects you believe should be open source (and then constantly keeping banging on about); not to mention what they should / shouldn't work on while doing sweet FA yourself

Really, if that is what you see, then your eyesight needs adjusting.

What I am banging on about here is that P96 will not substitute FBlit, and that ThoR, as the great open source contributer that he is, can either stop his repeating rants about how crap FBlit is, or fix it.

[utri007]

Originally Posted by kolla

Really, if that is what you see, then your eyesight needs adjusting.

-

Not in this single thread, but it is same in every thread. You are not constructive, you are destructive. Somebody could say that you just mean and maybe you just like it. Considering what you write, I really would like to know what you have done? You are such a expert on every thread here, so surely you have done a lot?

[Gorf]

Hmm - If you read all the posts here carefully it becomes rather obvious:

Some people like me are using FBlit happily without feeling the need to fix something as it works as expected. Others like Thomas don't.

Thomas claims to know exactly what is wrong with FBlit - it seems he has analyzed it very sorely and even found out where the problems lay that cause "bogus bug reports" and what specific minterms are missing ...
I honestly would not know where to start here, so it seems a litte bit unfair to hear Thomas saying "why don't you fix it yourself" ... while he claims to not only know the problems but the solutions as well.

But instead of a contribution to some open source software, we got now a new commercial release of P96, because ... well "bug fixes that piled up" on Thomas side, which means it had bugs as well ...

Again like in OS3.1.4 we have a good samaritan developer, that gives away his time, expertise and work without compensation, so that a company can charge for an update and keep all money .... sorry that is all just beyond me.

[SvladJelly]

I really wish the boards would also block quoted text from an ignored troll...erm...user. :-/

[Minuous]

@kolla, Gorf:

Surely someone is allowed to have an opinion on the quality of a program without being required to fix every bug in it? I am reminded how the AROS zealots ignore any criticism and expect the users to fix all the bugs for them, just because it is open source.

[Thomas Richter]

Originally Posted by Gorf

Again like in OS3.1.4 we have a good samaritan developer, that gives away his time, expertise and work without compensation, so that a company can charge for an update and keep all money .... sorry that is all just beyond me.

P96 has an architecture. With relatively little effort, I can get relatively moderate bugs fixed and get not only a "blitter to fast" utility, but also a fully working graphics system with it. Little investment, big return. FBlit is "a pile of code" (to put it mildly). With relatively high effort (as in "rewrite the thing") one can get working code, and only has a "blitter to fast" utility in return. High investment, little return.

Clear now?

[kolla]

Originally Posted by Thomas Richter

Clear now?

It was clear all along. Just as it is clear that "most users" will continue to use FBlit, since that is what offers the best compromise when it comes to saving precious chip ram, speed and stability. If P96 was so good at this, it would have replaced FBlit 20 years ago, but it didn't. If P96 is to replace FBlit, it would most likely also need various "nasty" options.