Would you support a new Unified Opensource RTG standart?

[Tumbleweed]

I voted maybe. I use P96 with my CV64-3D (A4000D), CV64 (A3000D) and Picasso-II (A2000) cards.

What advantages would an open source RTG standard have over what I've already got?

Weed

[Karlos]

I voted maybe. I use P96 with my CV64-3D (A4000D), CV64 (A3000D) and Picasso-II (A2000) cards.

What advantages would an open source RTG standard have over what I've already got?

Weed

Apart from the possibility of newer/faster drivers and drivers for cards you couldn't use before?

[arnljot]

I voted maybe. I am wondering how it will help the community exactly.

Our argument has some points we´d like to put forward to you
1. Current solutions are no longer maintained, and is to some degree buggy and lack features supported by current and older hardware

2. Current new initiatives must either support two software solutions or shut one side out. Either cause pain to users, or developers.

3. Current RTG systems are diveded on hardware. P96 UAE and Mediator exclusive. CGX GRex and CyberVisionPPC exclusive.

4. A new ubiquitous RTG system can be ROM-able and alow "native" support for RTG cards.

5. A new RTG system could nativly support FPGA Arcade and Natami GFX hardware. At this moment talk is on mimicing older P96 hardware...

[kolla]

What advantages would an open source RTG standard have over what I've already got?

Open and free developer kit for developing drivers so that new graphics card solutions can be supported.

I find this poll a little confusing though, as I find that this is a topic that is only really relevant for developers, not users. Users can support it all they like, but nothing will happen without developers supporting a new standard.

[Gulliver]

Open and free developer kit for developing drivers so that new graphics card solutions can be supported.

I find this poll a little confusing though, as I find that this is a topic that is only really relevant for developers, not users. Users can support it all they like, but nothing will happen without developers supporting a new standard.

But on the other hand, will it make sense if no user is going to actually use it?

We need both, users and developers.

[wawrzon]

the developers need to support the new standard by programming it, on the other hand it will make their life easier in turn. they will be able stick to program for cgx or p96 whatever they like and know best, and it will still work under the new standartd till it wipes out the others anyway. isnt it a gain?

[kolla]

But on the other hand, will it make sense if no user is going to actually use it?

We need both, users and developers.

Sure, but developers first

Whether users will really support it depends entirely on how well the result is, and how easy it is to test it without screwing up existing p96/cgx installations.

[tone007]

I'd support it just to piss off the P96 guy!

[kolla]

I'd support it just to piss off the P96 guy!

Let's call P97 :laughing:

[wawrzon]

Whether users will really support it depends entirely on how well the result is, and how easy it is to test it without screwing up existing p96/cgx installations.

i could dedicate a few different setups for this sole task (but not the main machine of course)

what concerns this new graphics.library
on a1k and eab ratte warns that cosmos is circumnavigating jumptables to gain speed:

Zitat:
Zitat von Cosmos  
- Four 'jsr -$1B0(a6)' replaced by faster 'bsr.w R_LockLayerRom' (Cosmos)
- Four 'jsr -$1B6(a6)' replaced by faster 'bsr.w R_UnLockLayerRom' (Cosmos)
- Fourteen 'jsr -$2F4(a6)' replaced by faster 'bsr.w R_GetDisplayInfoData' (Cosmos)
- One 'jsr -$2E8(a6)' replaced by faster 'bsr.w R_AddDisplayInfoData' (Cosmos)
- Four 'jsr -$2EE(a6)' replaced by faster 'bsr.w R_SetDisplayInfoData' (Cosmos)
- Three 'jsr -$2DC(a6)' replaced by faster 'bsr.w R_NextDisplayInfo' (Cosmos)
- Ten 'jsr -$84(a6)' replaced by faster 'addq.b #1,$127(a6)' (Cosmos)
 

[arnljot]

Whether users will really support it depends entirely on how well the result is, and how easy it is to test it without screwing up existing p96/cgx installations.

I believe the aim would have to be to replace P96 or CGX4 on m68k, but retaining backwards compatability with software written for P96 and CGX4.

So the procedure would be an install process that would replace P96 or CGX4 with itself when it was mature for general release.

But so far, all we have are aspirations and wants This thread is to motivate would be developers that this is something that the users want, and indeed needs.

[Karlos]

@wawrzon

Bit early for implementation detail, but I don't really see these methods as being beneficial (not to mention potentially dangerous if something needs to patch a particular call) when you consider the only calls that really need accelerating are the ones that do graphic operations and in those cases, the time spent actually doing work is likely to take orders of magnitude longer than the library call itself.

[cv643d]

Yes!

When would you think you can have a beta finished? I would love to be able to run native modes on my CVPPC card with a flashed rom.

Also, I think it would be awesome to ditch the crazy installation of Mediator with the Next-generation RTG system, possibly support all kinds of different PCI graphics boards, maybe multi graphics board, anyone want to run tripple head or dream of running 30" TFT at 2560x1600?

[KThunder]

no

[kolla]

do you have all the os docs on rtg? have you studied and programmed for  p96?

That's where all this started, if you had been paying attention.... the P96 SDK is not available, and the rightholders refuse to open it. The only way to write P96 drivers today, legally, is to through reverse engineering an existing driver.

[Trev]

I suspect that anyone that asks nicely and plays by the rules can get a copy of the P96 DDK. (EDIT: I suspect it because that's how I got a copy. It was several years ago, though.) I agree that a closed solution is not ideal, but nothing prevents an enterprising developer from designing a P96 shim driver that allows an open standard to be developed. If the open standard is adopted by enough developers, it provides the impetus to move all systems to the new standard.