Vampire/SAGA support

[Thomas Richter]

Originally Posted by grelbfarlk

I thought there was a P96 driver for classic chipsets now? So if you targeted P96, basically as long as you had a compatible screenmode you could target everything ECS or AGA and forward that that had a P96 driver?

You seem confused. So, the native chipset has of course a linear frame buffer, providing direct access to the memory of the frame buffer. Quite unlike some ancient VGA chipsets such as the one of the Retina Z2.



Second, the "Native" P96 driver is not a monitor driver in the strict sense because creating the screen modes and the screen, and loading the frame buffer to the display is still run by the operating system. Getting this done through P96 would povide no advantage anyhow. What "Native" does is that it enables the blitter emulation, so all blitter operations are performed through the CPU (and hence typically faster), which also allows to place non-displayable bitmaps in FastMem. Bitmaps you want to display of course still have to go in chip mem (and no matter whether there would be a P96 driver or not) simply because that's where the custom chips need them to be able to create an RGB output.

[aros-sg]

Originally Posted by Thomas Richter

Err... Maybe I don't understand the question, but the short answer is "no". P96 requires a linear frame buffer mapped into the CPU address space. The driver may accelerate some low-level functions, but P96 also provides access functions to allow user code to render directly into video RAM.

If the answer was yes, it would allow for example better accelerated P96 driver for Amiga emulators as the driver could "map" Amiga side screen bitmaps and friend bitmaps of screen bitmaps to host side bitmaps/pixmaps and then map gfx functions in this bitmaps/pixmap (and between this bitmaps/pixmaps) to host side accelerated gfx functions (line drawing, blitting, rectfill, ...)


As for direct access by user code: both P96 and CGX docs say bitmap locking may fail so in theory user code needs to have a fallback for when direct access fails. Of course there will be mostly games/demos which ignore that ...

[Solo Kazuki]

Originally Posted by clebin

Gunnar announced it but maybe it hasn't happened yet. Hopefully they want to address the issues raised here by releasing it only when it's considered final. That would make sense rather than reinforce people's perception of the project as a moving target.

http://www.apollo-core.com/knowledge.php?b=1¬e=5768

EDIT: Wow, that post was from 2017. I didn't think it had been that long.

Is it not weird for You why it's still not open-source to almost end of 2021? Mind that in 2017 most (if not all) Vampire competitors which You mentioned in other post were not existing yet (i'm not counting plans).

Btw: You forgot mentioned Warp between mentioned solutions. Yes, Warp have FPGA in function of card controller and also graphic card. This is THAT FPGA which lack of stopped Warp production. So if SAGA would be open-source it could be used also with Warp. But as I mentioned before I don't think it happens in near future.

[grond]

Originally Posted by Thomas Richter

Nonlinear frame buffers (as for the Retina Z2) are not supported (anymore).

Which ironically makes P96 also somewhat of a moving target. If one wants to be safe, one should only code for OCS...

[grond]

Originally Posted by Solo Kazuki

Is it not weird for You why it's still not open-source to almost end of 2021?

I suppose that's because it's not finished yet.

[Thomas Richter]

Originally Posted by grond

Which ironically makes P96 also somewhat of a moving target. If one wants to be safe, one should only code for OCS...

No, because that was only part of the internal driver API, but not of the API between user and P96. Non-linear frame buffers went away already in ancient times (before the P96 2.0 release, before 2000).

[Thomas Richter]

Originally Posted by aros-sg

If the answer was yes, it would allow for example better accelerated P96 driver for Amiga emulators as the driver could "map" Amiga side screen bitmaps and friend bitmaps of screen bitmaps to host side bitmaps/pixmaps and then map gfx functions in this bitmaps/pixmap (and between this bitmaps/pixmaps) to host side accelerated gfx functions (line drawing, blitting, rectfill, ...)

I don't know how UAE handles this, but the Amiga memory is part of the PC memory, obviously. I guess the PC is just fast enough for line drawing and blitting - such operations can be forwarded from a P96 driver to the host side.

Originally Posted by aros-sg

As for direct access by user code: both P96 and CGX docs say bitmap locking may fail so in theory user code needs to have a fallback for when direct access fails. Of course there will be mostly games/demos which ignore that ...

The point is not so much that it can fail, the point is that the memory can move, in particular off-display. SDL-ports fail miserably updating their frame pointer, even though the SDL API itself is able to handle such cases.


P96 does not have a lock-mechanism, but a "hook" mechanism which calls your code and the address of the current frame buffer.

[kamelito]

@Thor, offtopic did you got my privates messages?

[clebin]

Originally Posted by Solo Kazuki

Is it not weird for You why it's still not open-source to almost end of 2021? Mind that in 2017 most (if not all) Vampire competitors which You mentioned in other post were not existing yet (i'm not counting plans).

No, not really if it's still in active development. 2017 isn't so long for a project done in people's spare time. If they released it unfinished and full of bugs and inconsistencies, you and others would stamp all over it, would you not?

You can make assumptions, or... maybe you could just ask them?

[Solo Kazuki]

Originally Posted by clebin

You can make assumptions, or... maybe you could just ask them?

Yeah, they tell me the truth for sure...
Let's see what the future brings. Maybe i'm wrong... but maybe a bit naive thinking is.

[grond]

Well, perhaps a little logical thinking can help here. Wouldn't it be much better for general acceptance of SAGA if all those minimigs, misters, pistorms etc. supported the same new set of features? Wouldn't that help sell Vampires if there were more software making use of the new features? Wouldn't this address precisely what most van Helsings critisise about SAGA: hardly any software available for it anyway? To summarise: wouldn't it make an awful lot of sense to open-source or license SAGA to other products once it is finished and offers a defined set of features?

[Thomas Richter]

The trouble is that you seem to assume that this is some kind of "one-way road". Gunnar defines what it has to be, other people just implement and pay. However, this is not how the world works. Gunnar has been reluctant to accept advice from outside, on compatibility or interoperatbility, and this is not a solid ground on which cooperation(!) can work.

Instead of definiing a particular "chipset" (that is, a hardware interface), it is generally much more advisable to define a software interface how to drive a chipset. That includes mechanisms how to find a chipset (we have one for that already, it's called Autoconf), and a series of interface functions to talk to the chipset, abstracting the features away and provide those functions to users.

This was, just to remind you, the way how the PC operated. While there was initially a "VGA standard chipset", it became soon enough too limiting, and instead of restricting chips to this legacy, vendors agreed on a software interface (back then, the "VESA bios", today, the "linux kernel interface" or the "MS driver architecture). This turned out to be a much more viable approach, and one that scales a lot better.

It also allows competition between vendors, to the advantage of the user...

[clebin]

Originally Posted by Thomas Richter

Instead of definiing a particular "chipset" (that is, a hardware interface), it is generally much more advisable to define a software interface how to drive a chipset. That includes mechanisms how to find a chipset (we have one for that already, it's called Autoconf), and a series of interface functions to talk to the chipset, abstracting the features away and provide those functions to users.

This was, just to remind you, the way how the PC operated. While there was initially a "VGA standard chipset", it became soon enough too limiting, and instead of restricting chips to this legacy, vendors agreed on a software interface (back then, the "VESA bios", today, the "linux kernel interface" or the "MS driver architecture). This turned out to be a much more viable approach, and one that scales a lot better.

It also allows competition between vendors, to the advantage of the user...

Why would they model the PC and create another RTG system like we already have?

This is supposed to be an enhanced Amiga chipset, programmed like the classic chipset, banging the hardware, coexisting and mixing with OCS/AGA modes, playfields, etc. Abstract that away behind a software interface like you describe and there is no USP, no reason for SAGA to exist.

EDIT: And I mean no offence to P96 and your work on it. P96 is a vital, well established piece of software. That's why there's no need for them to reinvent that wheel. This is something different.

[Thomas Richter]

Originally Posted by clebin

Why would they model the PC and create another RTG system like we already have?

SAGA is not an RTG system. It is a chip interface that provides chunky and hicolor graphics. An RTG system is a software layer. So please, don't confuse the two.

Originally Posted by clebin

This is supposed to be an enhanced Amiga chipset, programmed like the classic chipset, banging the hardware, coexisting and mixing with OCS/AGA modes, playfields, etc. Abstract that away behind a software interface like you describe and there is no USP, no reason for SAGA to exist.

And that's where the argument is wrong. Chunky or hi-color graphics is not a matter of "banging the hardware". If you "bang the hardware", you create another dead end as the ECS or AGA already was because you depend too much on a particular chipset or its interface. In essence, CBM had to carry all the legacy errors of ECS to AGA, now the legacy errors of AGA to SAGA; and in the future the legacy errors of SAGA to the next generation. You make the job of extending the chipset harder and harder, by requiring developers carrying more and more legacy around.



As I said, there was a reason why the PC world moved away from "defining an interface through chipset registers". It is considerably less flexible than a software defined interface. Software allows competition between hardware vendors, and that is a *good* thing. The problem of the Amiga graphics is that is too much bound to the chipset capabilities - just continuing with this error does not sound very smart to me.

[clebin]

Originally Posted by Thomas Richter

SAGA is not an RTG system. It is a chip interface that provides chunky and hicolor graphics. An RTG system is a software layer. So please, don't confuse the two.

I'm not, you misunderstand my point (and it was you who started the conversation about software layers)

If you "bang the hardware", you create another dead end as the ECS or AGA already was because you depend too much on a particular chipset or its interface.

The problem of the Amiga graphics is that is too much bound to the chipset capabilities - just continuing with this error does not sound very smart to me.

This might be why you're not getting it. Plenty of people are attracted to coding for old platforms like the Amiga for precisely the thing you call a "problem".

[Thomas Richter]

Originally Posted by clebin

This might be why you're not getting it. Plenty of people are attracted to coding for old platforms like the Amiga for precisely the thing you call a "problem".

If people like old platforms, why they need a new chipset? Or, to put it differently, why not bang the hardware of a raspi, alternatively? Or call a software function, alternatively?

[daxb]

Originally Posted by clebin

Plenty of people are attracted to coding for old platforms like the Amiga for precisely the thing you call a "problem".

The "bang the hardware" coders are usually game makers and demo scene people. They usually use OCS/ECS/AGA. As far as I can see nearly nobody is interested in direct SAGA coding except some rare exceptions. I would say SAGA comes at least 20 years to late. However, you can use SAGA over RTG. Hence SAGA isn't completely useless.

[Int42]

I use the Amiga to relearn 68k assembler with direct hardware addressing. I don't wanna any abstraction of the chipset. But when a coder like c programming on an Amiga, abstraction and libs are fine.

[clebin]

Originally Posted by Thomas Richter

If people like old platforms, why they need a new chipset? Or, to put it differently, why not bang the hardware of a raspi, alternatively? Or call a software function, alternatively?

As I say, the best use case I can see is people writing existing Amiga code who offer SAGA-enhanced features. And maybe those who want to step up the graphical fidelilty without losing the skills and knowledge they’ve built up over the years.

It’s a bit like the ZX Spectrum Next. There’s a definite split in opinion and even some backlash (mild in Amiga terms) on that machine too. My favourite Next game so far, Delta’s Shadow, shown against the 128k Speccy version shows how some creative, interesting projects can emerge from the mix of old and new constraints. Take the sound - as the Next offers 3 AY chips instead of one, they keep the same music but beef it up with extra bass etc. It’s cool stuff IMO.

[clebin]

Originally Posted by daxb

As far as I can see nearly nobody is interested in direct SAGA coding except some rare exceptions.

That’s the uphill struggle they face, no getting around it.

SAGA needs to be good enough and stable enough, first to get any kind of support in emulators and hardware, and second to win developers over to actually want to use it. I don’t believe that the appetite for SAGA conceptually-speaking has been proved one way or the other yet. Even the failure of SAGA may not answer the question if it were done badly. Although on that, I’m encouraged to see Thomas Hirsch on board.