Picasso 96 driver for ECS/AGA

[Predseda]

In very short: it is not possible to fix this problem?

[Thomas Richter]

Not from my end.

[Predseda]

Thank you anyway for your effort.

[Thomas Richter]

Finally, I believe I found a method. DPaint seems to recognize several undocumented flags from GetBitmapAttr() - who knows where those came from. One flag seems to trigger CPU blitting, and it seems to work for this purpose on my end.

Thus, please contact iComp in the forum, I informed Jens that I have a beta ready for you. He will probably need an order ID from you to verify your purchase.

[DaMi]

Hi Thomas, thank you for searching for a solution. I am going contact iComp.

In between I found out that DPaint V (specifically the version 5.2) works fine with combination p96 and the native driver. No glitches there when I work with the brush tool.

[Predseda]

Problem is that Dpaint V does not replace functions of Dpaint IV (non AGA) properly, so for OCS drawing still the old version is needed. Thanks to all involved.

[Thomas Richter]

Originally Posted by DaMi

Hi Thomas, thank you for searching for a solution. I am going contact iComp.

In between I found out that DPaint V (specifically the version 5.2) works fine with combination p96 and the native driver. No glitches there when I work with the brush tool.

Just to remind you, there is still a beta waiting for you, please provide an order ID. If you do not have an order ID, now would be the time to buy the product.

[DaMi]

Thomas, you are a magician. Jens sent me today the beta and the glitches in DP IV disappeared. If I run into something, I'll let you know. I also made a note on iComp forum. Thank you.

[DaMi]

Sorry to inform you, but I forgot to copy the Native driver to DEVS:Monitors. After I do so, the problem with glitches in DP IV when I use brush persists. The glitches are the same, there is neither more or less of them. So the situation is the same, as it was at the beginning. I'll understand if it can't be fixed.

[shelter]

FBlit and FText sure is buggy, some whdload stuff don't run properly. EDIT: While it might affect whdload etc. it wasn't the root cause of issue for me, it was something else.

However it seems to be slightly faster, so what is it doing that P96 and Native doesn't do?
I tried opening startup-sequence in TextEdit, TextEdit does a second refresh after opening the file, that second refresh seems faster with FBlit/Ftext enabled than running Native.
It's tested in DblPAL mode on a 030.

Can P96 be improved?

[Thomas Richter]

P96 does not patch Text() as it is not needed to be patched. The graphics.library Text() function just prepares a 1-plane bitmap and then runs into BltTemplate(). If you want to play with faster implementations of Text(), I suggest:

http://aminet.net/package/text/font/FastFonts

But, as said, this is unrelated to P96.

[shelter]

Thanks for the info, I'll have a look at FastFonts.

Still refreshing my Amiga knowledge here...

[tron^fr]

Frage, gibt es eine P96 basierte card die 24Bit (18Bit via HAM8 Chunky) und 2568Bit Chunky direkt auf AGA unterstützt. Also quasi RTG emuliert und dabei C2Ps verwendet ?

[Thomas Richter]

Is that "card" as in "hardware"? No, but why would that make sense? It is much more efficient to pipe out the chunky pixels directly to the monitor rather than going through the slow chipset graphics.

[tron^fr]

With card I meant the P96 SW driver (I can see they called xxx.card). So does a monitor driver like your native but with support of 8Bit Chunky and RGB888 Chunky (using HAM8 18Bit C2P) exists ? So that for instance a A1200 without RTG-HW-Card can run actual RTG applications (even if it will be terrible slow, obviously).

[Thomas Richter]

No, and it would be surprisingly hard to do so. The problem is not the C2P conversion - P96 comes with a pretty nice algorithm for that already. The problem is what a P96 driver has to do, namely drive the graphics chips. In this particular case, the graphics chip is the native chip set, but that is already in use by the Os.

Thus, the driver would not only need to re-implement everything the Os does to drive the chips, including building copper lists for loading the palette, adjusting them etc..., it would also need to ensure that the Os does not attempt to use the chip in parallel, and switch between the P96 driving the chips and the Os driving the chips.

[aros-sg]

Originally Posted by Thomas Richter

The problem is what a P96 driver has to do, namely drive the graphics chips. In this particular case, the graphics chip is the native chip set, but that is already in use by the Os.

Why?? It would not need to "drive the native chip set". It would just invent an internal fake gfx card. In simplest form basically just a chunky buffer in memory. And then use some mechansim to ~present that on a native screenmode using standard AOS gfx functions. This could be handled in separate task (some kind of ~display server) so the gfx driver after gfx operation to fake visible screen bitmap, would send a "damage" message/region to that display server task, telling it which Region of the chunky buffer has changed so it can updated to the ~"mirror AOS chipset screenmode screen" that the gfx driver had asked it to create earlier (when screen was opened).


X11 has such "nested" gfx drivers, btw.

[Thomas Richter]

Originally Posted by aros-sg

Why?? It would not need to "drive the native chip set". It would just invent an internal fake gfx card.

There are two answers on this one. The first answer is that it depends on what you expect. An "Xnest" driver is probably quite boring, and probably not quite helpful, see below for what would need to happen.



The second answer is that the Amiga graphics system is considerably more complex than the X system. In the X system, you only have one rendering surface ever, and once X is initialized, bitdepth, screen size etc are frozen. This is not how Amiga works.


So consider that I as a user want to "open a screen on chunky" with such a driver. That involves providing a bitmap for such a screen - where do I take this from in such a driver? From opening another screen? Of from opening window on an existing screen? Within the driver, I cannot open a screen because that would break the intuition architecture.



Even if so, then intuition calls (indirectly) through P96 to arrange this "fake" screen if the user drags a screen whose view port belongs it the "emulated" chunky screen, but from within a P96 driver, I can no longer work on the native screen (actually view port) - again as you cannot call intuition from within intuition. (i.e. the dependency order is user->intuition->graphics->P96->intuition, and that does not go well due to the intuition state machine).


Thus, essentially, to break the dependency, the window or screen to render in needs to be open upfront, and the driver would just need to borrow the bitmap of the screen. This pretty much renders out that such screen appear just in the screen mode requester as everything that is there can "open a screen" but not specify a window where that fake screen should go. So just not that something that is very useful for the average user.


Essentially, you are bound to a "mode" that uses some new interface that both opens a window (or a screen) and within that host screen initializes a driver.



Anyhow, if you believe it's so trivial, the P96 specs you can get, so maybe just give it a go.

[tron^fr]

thanks a lot for the detailed information. I was just noticing that the P96 Packages containers drivers for Graffiti. I did had one of the early prototypes back in the day. http://aminet.net/package/game/misc/voxel087 working fine on the Indivision MK3. Anyways, there is a P96 card for it and a monitor driver. But for what purpose ? No modes are listed in ScreenMode.