Picasso 96 driver for ECS/AGA

[Thomas Richter]

Originally Posted by kolla

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.

Stability? You must be kidding. According to whom?

Originally Posted by kolla

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.

Probably not, because a simple program to enable CPU blitting was missing, as it seems. And probably not, because it does not take a lot of options to do things right. No options are totally fine. Your assumption that one needs "more options" seems to be nothing but hot air and motivated by your political agenda.

FBlit is a typical example of an open source system: Not yet completely done, not fully working, hard to maintain, and hard to use. You are certainly welcome to invest your time into the tool, no problem. But don't tell me what I have to do, and how to waste my precious time.

[kolla]

I have no political agenda in this, you do. You're essentially saying that anyone who experience FBlit as a faster option, must be delusional.

[Minuous]

@kolla:

Did you actually read post #41 before replying to it? Where does it say anything about "faster"?

I think you do have a political agenda, it seems pretty obvious to me that you are a CloneToo shill.

[kolla]

Is FBlit not faster, then?

I have no idea what "CloneToo" is.

[Minuous]

@kolla:

You know, the ones who are selling a free emulator and doing their utmost to stop any further AmigaOS development. Your mates at www.cloanto.com

[kolla]

They are not my "mates", I don't use any of their products, and if you search back far enough, you will find that I slam them for introducing "registry" to Amiga. However, unlike you, I do recognize their contribution to development of Amiga emulation.

[Minuous]

That's funny, I always thought it was written mainly by Bernd Schmidt, Brian King and Toni Wilen. But instead it was Mike Battilana the whole time. Silly me. Did he write Fellow too or just UAE? ;-)

[britelite]

Originally Posted by Minuous

That's funny, I always thought it was written mainly by Bernd Schmidt, Brian King and Toni Wilen.

So now programming is the only way to contribute to a project?

EDIT: You might want to actually run WinUAE and see who's listed as contributors

[aros-sg]

Originally Posted by Thomas Richter

Not a problem. P96 keeps a hash list of bitmaps, and it knows which bitmaps are "its own" bitmaps,

The point was not whether this is a problem or not (btw, I think hash list is overkill. there are easier/faster ways) but whether to have a fixed/unchangable approach in the software (fblit or P96) for cases such as chipram blit to chipram blit (ie. always do it with cpu routines, or always let it fall back to the blitter routines in the OS) despite the fact that depending on your system or on the software there may be cases where the cpu routine is faster and other cases where the blitter routine is faster. If the user has options to change behaviour on his system or for certain apps he may get better/faster result.

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

Because chip ram gets eaten up very quickly if all bitmaps and up in there. So he may want to have as many of them as possible in fast ram. But maybe for some app he may want to override that as maybe the app is not compatible (ownblitter; direct blitter access; disownblitter) or for some app speed is better with std blitter instead of cpu routines and for that app he prefers speed over chip ram usage.

DPaint is actually working fine as it uses Os functions, so no issues.

When Deluxe Paint source code was released I think Olaf on some Forum somewhere mentioned how clean the code was despite it using things like direct blitter access. Maybe that's just the earlier versions of DPaint, not the latest ones.

If you bang the hardware yourself... well, that's then pretty much your problem, of course.

... if your only option is to disable something (Fblit/P96) completely or enable/use something completely ...

[kolla]

Originally Posted by Thomas Richter

DPaint is actually working fine as it uses Os functions, so no issues.

Really, no issues with DPaint, doing HAM8 animations on P96 just works.
Well, that is perhaps the most news worthy thing mentioned in this thread.

[Thomas Richter]

Originally Posted by aros-sg

Because chip ram gets eaten up very quickly if all bitmaps and up in there. So he may want to have as many of them as possible in fast ram. But maybe for some app he may want to override that as maybe the app is not compatible (ownblitter; direct blitter access; disownblitter) or for some app speed is better with std blitter instead of cpu routines and for that app he prefers speed over chip ram usage.

You are here envisioning a system that is, frankly, just too complex for the average user, as experience shows. Is there any way how to "know" how to configure it correctly without understanding the technical details? This is precisely the difference between "a product" and "code". P96 does have the ability to off-load bitmaps to and from "graphics cards", so yes, one could "offload chipmem bitmaps" to fast ram - as a mechanism, this is there. But - is this actually useful for native graphics? For graphics cards, this is only done if the board is running low on memory.

Originally Posted by aros-sg

When Deluxe Paint source code was released I think Olaf on some Forum somewhere mentioned how clean the code was despite it using things like direct blitter access. Maybe that's just the earlier versions of DPaint, not the latest ones.

I was certainly not talking about Prism or earlier releases. Prism and these early releases do certainly not use AllocBitMap() either (as it did not exist) so bitmaps go into chip ram in first place, so not a problem. But if you're running 68K only, Kickstart 1.2, then P96 is "probably" not quite what you want.

Originally Posted by aros-sg

... if your only option is to disable something (Fblit/P96) completely or enable/use something completely ...

Right. It is an option users understand and that is easy to explain and easy to handle. Don't make things unnecessarily complicated. Look, if you want to continue to use it - go ahead. But my first reaction to "graphical glitches" remains "remove patches, try again".

[Gorf]

Originally Posted by Thomas Richter

FBlit is a typical example of an open source system: Not yet completely done, not fully working, hard to maintain, and hard to use. You are certainly welcome to invest your time into the tool, no problem. But don't tell me what I have to do, and how to waste my precious time.

The opposite is true:
It is now hard to maintain, because it was NOT Open Source from the beginning!

I am not telling you anything. I just mentioned that I can not understand your motivation to work for free on commercial closed source products and let others charge money for your free work.

[DamienD]

Originally Posted by Gorf

because it was NOT Open Source from the beginning!

OMG, can we drop the open source rubbish?

The product is not open source; deal with it!!!

Here's an idea, why don't you and kolla work on something similar and then open source it?

You both imply that you're top-notch Amiga experts and seem to have the answer to everything; so get cracking instead of constantly derailing threads...

[Don_Adan]

Right, open sourcing for Amiga is totally useless. Can be useful only if someone with big/enough knowledge about Amiga can be supervisor for open sourcing project. For me only a few people can be supervisor: Olaf Barthel, Thomas Richter and Toni Wilen. Maybe Ross and meynaf. Anyway every project need good betatesters too. For most programs programmer/coder cant find all bugs/problems.

[Gorf]

Originally Posted by DamienD

OMG, can we drop the open source rubbish?

What exactly does that mean, Damian?
(sorry, honest question, as I don't understand)

The product is not open source; deal with it!!!

I am, by e.g. not buying the P96 update. No problem.

Here's an idea, why don't you and kolla work on something similar and then open source it?

As mentioned the mistake is already this: to do it first and "then" open it, instead of developing it in the open from the start.

What exactly do you have in mind, Damian?
Any Ideas or suggestions are of course welcome, but it probably makes not much sense to do something "similar" as there is already an open source solution that works for both of us.
(It was not me or Kolla, but Thomas, who is blaming FBlit ...)

You both imply that you're top-notch Amiga experts and seem to you have the answer to everything;

I try to answer things here as good as I can, in the hope others will answer my questions here.
Thanks for considering me as a top-notch expert, but while I do have a long Amiga history and some knowledge about programming (as it is my profession), people like Thomas or Toni and many others here are the real experts.

so get cracking instead of constantly derailing threads...

OK.
I certainly did not derail anything on purpose (and did not notice that it did).
The direction of a conversation is not always entirely predictable ... at least to me.

[DamienD]

Originally Posted by Gorf

What exactly does that mean, Damian?
(sorry, honest question, as I don't understand)

It's means that in numerous threads both yourself and kolla keeping bringing up open source as a possible option; the authors' reply saying that it's not possible for whatever reason, but you both keep banging on about / arguing why it should be done in your opinions...

Originally Posted by Gorf

I am, by e.g. not buying the P96 update. No problem.

Great, so if you're not purchasing / supporting the P96 update then why do you care so much if it's closed source and apparently doesn't do what you want?

Originally Posted by Gorf

As mentioned the mistake is already to do it first and "than" open it, instead of developing it in the open from the start.

What exactly do you have in mind, Damian?
Any Ideas or suggestions are of course welcome, but it probably makes not much sense to do something "similar" as there is already an open source solution that works for both of us.
(It was not me or Kolla, but Thomas, who is blaming FBlit ...)

Ok then simply use that... why not even join their team and make a difference since you like / support that product.

Originally Posted by Gorf

I try to answer things here as good as I can, in the hope others will answer my questions here.

Again, why bother if you are not using / supporting the product.

Originally Posted by Gorf

Thanks for considering me as a top-notch expert, but while I do have a long Amiga history and some knowledge about programming (as it is my profession), people like Thomas or Toni and many others here are the real experts.

Clearly sarcasm is wasted on you...

Anyway, don't bother replying to this post. The thread has already gone off topic. PM me if you really feel that you must.

Back on topic all and enough trolling please.

[flype]

So far i like this 'Native' program, for what it is. It works as it is intended to, no more no less.

For people already using some pal + p96 gfx card system + fast cpu, it makes sense to use it, imho, especially when switching back to pal occasionally. FBlit or Native, both gives globally same end-user speed feeling, at least on fast systems. I test it since a week or two, i noticed nothing that would prevent me to use it in the long term.

This program had to exists, it was easy to do since it is only a starter. The idea is smart and in addition it works with the original p96 version, which is fair enough.

Thanks Thomas.

[grelbfarlk]

One of the nice things about ClassicWb is that it has pretty well tested install of CGX-AGA+FBlit+FText (and a lot of other stuff). Which then all goes to hell when you install P96 for an RTG card and it doesn't work correctly. But it's relatively easy to turn off all that and successfully install P96.

So my suggestion is packaging up the ClassicWB build with this one instead of CGX-AGA. Or is that not possible any more due to the P96 licensing? Does this work with old P96?

I'm not directing this at Thor or anyone in particular in the thread, I'm just not sure who does ClassicWB.

[gulliver]

Originally Posted by Don_Adan

Right, open sourcing for Amiga is totally useless. Can be useful only if someone with big/enough knowledge about Amiga can be supervisor for open sourcing project. For me only a few people can be supervisor: Olaf Barthel, Thomas Richter and Toni Wilen. Maybe Ross and meynaf. Anyway every project need good betatesters too. For most programs programmer/coder cant find all bugs/problems.

You are 100% right.

I have access to the OS sources, and despite all the cleanup that both Olaf and Thomas had made (which was a monumental task), I very early discovered that tinkering with the sources requires a lot of expertisse and decades of intimate knowledge about the history, kludges and undocumented structures of AmigaOS and its funky hardware, and its corner cases.

Most of the times, subtle changes that may be perceived as minor and harmless, end up breaking many old programs that are valuable and irreplaceable.

Others, fixing a technical bug, creates a functional bug. Many programs relied on bugs to perform their work, so fixing them, makes them inoperable.

And this is also why beta testing is of great importance.

[E-Penguin]

"it's hard" and "only a few people understand it" are not valid reasons to not open source. I'm sure the Linux kernel isn't without complexities but somehow they manage to struggle though...

Commercial and intellectual property reasons are much more persuasive. Why not open source? "It's mine and I shall do with it what I want". Fair enough. But faux technical considerations are not.

Open source doesn't mean it has to be a developmental wild west. The experts who work on the code now could continue to do so and control the process, and others could learn from their experience.