Would you support a new Unified Opensource RTG standart?

[arnljot]

I´m with Karlos on this one.

Gulliver has exchanged emails with the P96 IP holder, and his request to open up P96 has been declined.

No attempt as far as I know has been made to have CGX4 opened up. I don´t know who one would contact for that.

So, if CGX4 could be opened up to support Mediator graphic cards and UAE, then we´d be there.

Also, the community could patch and improve CGX for classic systems and bring it inline with MOS and AROS, and P96 on OS4 eventually. It would make life a little better for Amigans all over I  think.

But if the CGX4 IP holders won´t or can´t make CGX4 LGPL or another open lisence, then this poll is about making a new open compatible unified RTG system.

Would you support it. Either by helping out in a non coding capacity (finding documentation, writing documentation, etc), provide coding skills or contribute to a bounty.

This issue was in a way sparked by the excellent Cosmos´ efforts to modernize and update graphics library.

[arnljot]

I thought this was covered in the other thread, besides it is still in development in case you missed it.

No, I didn´t miss it. But I didn´t take pirus post as a definitive answer as he said it was unlikely. That is hardly an official request, or an official answer.

And yes, I know that CGX is part of MOS, but it´s no longer developed for classics, and I thing they´ve reached version 5.

So what we´re asking, got to ask, is can version 4 codebase for classics be released. Posted on Aminet as open source.

Until someone step forward and take ownership of CGX4 and denies it going opensource I´ll hope that it will. Or until someone points to the IP owners so that we can direct a request to them. Gulliver has done a good job so far of tracking down various IP holders and asking them, and I think we better should get hold of the CGX4 IP holders and ask them propperly.

I respect Piru a great deal, and I appreciate that he´s part of the MOS team, but I think he was voicing an opinion and not speaking officially for them when he replied.

And I don´t know if the MOS team has ownership to CGX4 or if they have lisence rights to it. All this has to be uncovered so that we know where we stand so that we know we´re proceeding in the right direction.

The AROS team might shed some light on this. Are they for instance reimplementing the CGX system from scratch like they do with the OS3.1 APIs, or have they had a code donation from the CGX code base? Things like this might help us sort this out.

[arnljot]

What about making the m68k CGX v4.2 driver SDK available? That's all that's really being asked. Nobody is expecting CGX5 to be opened up.

Precicely. The first goal would to bring P96 m68k "into" CGX4.2 m68k. Next step would be to see if "Open CGX" could implement features from CGX5 and "OS4 P96". Or if the community wanted something else After all, it would be open.

[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...

[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.

[arnljot]

Faster drivers that visibly enhance the user experience that would be good. But what else wil it provide? From what I gather there is a big advantage for those with a G-rex or toher similar bus board as they can potentially use other graphics cards. But for those without a bus board, other than potentially fatser drivers, there is not much else. Or am I mistaken?

Weed

Yes the primary benefits for end users would be bug fixes and new and updated drivers (raster accelleration).

The second goal would be to manage to make it "romable", to have it in kickstart ROM.

Also, there is talk about adding RTG support to the FPGA arcade. With an open RTG system it would be much easier for new efforts to add new hardware to the classics family and other amiga related systems.

[arnljot]

I talked with Frank about it. It wasn't an opinion.

I'm sorry to hear that. Is there any chance you can put us in contact with him so that we may enter a dialogue. It would at least be nice to know why, so that we can lay it to rest. Perhaps there are some provisions the community could make that would make him feel secure about releasing it?

[arnljot]

I agree that new hardware for classic amigas is unlikely. But not impossible. One new hardware rumor is the Indivision A1200 mkII. But I expect Jens has all the SDKs he needs.

However, a more tangible discussion recently was the Virge emmulation discussion in FPGA Arcade (Minimig AGA thread). It would open up much better possabilities if such challenges could be sorted out in the RTG system.

Thank you Piru for your response. I think I now understand some of the concern that you have.

The idea we're tossing around here is however not to create a third way, but a common way. For software, clients of the RTG system if you will, it would be vital that API compatability is retained. Or else the users wouldn't want it as it would render too much software allready compiled and no longer maintained useless.

As it stands in the moment, it seems that a new RTG initiative would have to specify a new API which would be P96 and CGX compatible, not so hard in it self as P96 currently to some extent does this.

The hard thing, like you and others have pointed out is the driver situation. And everything in interfacing with the hardware as that is what the RTG layer does.

As someone asked here, is it possible to "mimic" the other RTG systems, and retain compatability with existing drivers? I think that would be hard, and cost way more than you'd like to put into such a project, even though the project we're talking about here would be huge.

Please remember that one huge user benefit would be that this new RTG system should also exist in a minimal footprint version, which you could have in Kickstart so that RTG is available from power on. Much like linux and other OS' today have their VESA modes.

[arnljot]

Not much if you consider who wrote the existing drivers.

But it's AHIs open nature who enabled other developers besides Martin to do so. That is part of the argument here.

[arnljot]

If you look here
http://arp2.berlios.de/ahi/#downloads

Then you can see that the driver developer SDK is freely downloadable.

That means that openpci guys have made ahi drivers, elbox has made mediator pci drivers, and grex dudes have made their drivers.

That's the way we would like it to be for the rtg systems too.

[arnljot]

Included drivers
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
concierto.audio   4.28 (1.11.98)    © 1997-1998 Village Tronic Computer
delfina.audio     4.07 (11.10.98)   © 1997 Petsoff Limited Partnership
maestropro.audio  2.3 (28.10.97)    © 1997 Richard Koerber
melody.audio      4.10 (31.07.98)   © 1998 Thorsten Hansen
melody1200.audio  4.10 (06.09.98)   © 1998 Kato Development (Thorsten Hansen)
paula.audio       4.30 (29.04.03    Public Domain
paula.audio (MOS) 4.30 (30.03.03)   © 2002-2003 Sigbjørn "CISC" Skjæret and
                                    Harry "Piru" Sintonen
prelude.audio     2.30 (06.02.99)   © 1996 A.C.T.
toccata.audio     4.7 (19.06.2005)  Public Domain
wavetools.audio   2.11 (15.02.97)   Public Domain

Those are the drivers from the main m68k ahi archive.

http://bvernoux.free.fr/DevPCI.php The open PCI site doesn't quote who wrote the AHI drivers for OpenPCI library audio cards.

The GREX drivers are " ©2000-2001 by DCE Computer Service GmbH ".

And then there are the Elbox AHI drivers, and number of AHI drivers around for MOS, AROS, AOS4 and number of drivers on aminet. All made possible because Martin Bloom recognized that for his Audio system to be a success, it had to be open.

Your comment on AROS, I completely agree on. And I like it so much, because it's open!

But, to get back on track.

It seems that we need to make a new system from scratch.

The question is then, what is the best starting point. Is it to look what code that can be taken from the AROS repository?

[arnljot]

Isn't gallium a driver system? P96 and CGX is a two parter, one part is the driversystem, the other is replacing and patching OS screen and window routines?

As I've understood it gallium will be injected between AROS CGX and the hardware. Then there is talk about putting Cairo on top of that, and make a cgx library on top of that for backwards compatability.

This is how I've understood it.

[arnljot]

VESA Modes is something in the VESA Bios extention I think (VBE), so I think it's mostly on PCI, PCI-e and AGP cards. Amiga native cards can support VESA modes, but doesn't have a VBE to query for them (API).

--

A little dig around shows driver code for the following in x.org

GLINT (Permedia2 driver, + others). Such as in the CyberVisionPPC
http://ftp.x.org/pub/individual/driver/xf86-video-glint-1.2.4.tar.gz

Cirrus (Cirrus Logic GD5446). Such as the PicassoIV
http://ftp.x.org/pub/individual/driver/xf86-video-cirrus-1.3.2.tar.gz

cl64xx is a driver for Cirrus Logic GD5426 and GD5428. Such as the PicassoII and II+
I haven't found it's sources

s3virge is the linux driver for the S3 Virge chip. Such as the CyberVision64/3d
http://ftp.x.org/pub/individual/driver/xf86-video-s3virge-1.10.4.tar.gz

The s3virge driver should also work with the S3 86C764 Trio64 which is in the CyberVision64 card.

And the RetinaZ3 is supported under m68k linux (chipset NCR 77C32BLT) so code should exist somewhere for that too.

Amiga cards are identified by autoconfig id's, pci cards with vendor id's.

Seems like it should be possible to make a driver structure where the driver lists which autoconfigs ids it supports and which vendor id's it supports.

[arnljot]

Here is the databook on the CL-GD5446 which is in the PicassoIV.

It even has programming examples:
http://www.tjd.phlegethon.org/gd5446trm.pdf.gz

[arnljot]

yeah, but since i guess karlos asks about vesa support because of gallium relays on it, these cards are out of question because they lack 3d support. if the new gfx system i to be 3d based (on gallium) that is. might be good solution for classics at least with their slow bus.

I don't think it's a good solution for classic systems, as I think most users would like to retain support for PicassoIV, II, II+, Retinas and other non 3d graphic cards.