CGX 4 and P96 SDK

[Karlos]

Perhaps it's time to create a free RTG system that supports P96/CGX library calls.

[Karlos]

Yes, Karlos !

I didn't say I was going to do it... I paid good money for CGX4 :-)

It was pretty obvious that neither development camp would allow free redistribution of the drivers themselves, but if someone has a copy of the relevant SDK, I take it they can still apply for approval to release a driver they've developed for a new card? Or does the license of the RTG system cover all drivers written for it?

[Karlos]

I don't know for sure, but I imagine that AROS's implementation of CGX is a thin layer around the HAL and that perhaps you'd end up having to recreate the latter, which may be quite difficult.

[Karlos]

I wouldn't say that. Adding an RTG card to my A1200 was one of the single most significant upgrades I ever made. It made a very big difference to my everyday use and prolonged the life of my A1200 as my "primary machine" by several years.

[Karlos]

@kolla

I think it's more "political" than that. CGX and P96 have become the respective RTG standards for MOS and OS4, thus all development of each API has become tied to each platform.

Nobody ever installed RTG software for it's own sake, rather they installed it to allow them to run all their existing software in higher resolutions and/or greater colour depths. Just because the developers of the existing standards aren't interested/able to continue support doesn't mean the original motivation behind RTG has gone away. People still want to be able to use higher resolution screen modes with faster refresh rates etc.

[Karlos]

Personally, I was never entirely happy with either RTG system on 3.x (I've used both for years). Whilst they worked, every system I ever used felt as if they only accelerated the most basic functions using the available hardware. On my CGX 4.2/Permedia 2 install, for example, it was obvious that scaled/transparent blits weren't remotely accelerated, despite the fact the hardware is perfectly capable of it.

Other than basic integration, what I'd always wanted to see was a retained mode graphics library (basically one where you'd queue up some rasterization commands, then have them issued inside a hardware lock using whatever acceleration exists) designed especially for RTG hardware. Instead all we ever really got was a few chunky pixel copy functions.

[Karlos]

@karlos: isnt it how aros handle it? if you mention its gfx systeb above hal?

Well, my understanding was that the CGX implementation was a thin layer on top of the HAL. Which would imply that to back port AROS's CGX implementation would at least require a fair amount of work.

the reason of this thread if im not mistaken is that over at eab cosmos puts together his graphics.library replacement. he intends to incorporate gfx support directly into it. i dont know if this is a good idea in first place. i also do not know how he wants to accomplish it. one library for all seems a little bloathed idea. hardware and hw acceleration should be specifically handled by system specific drivers i believe. but i have actually no knowledge of this.

Well, in fairness, most of RTG is something you don't "see". What I mean is that it replaces graphics.library functionality, thereby ensuring that graphics.library calls are sent to the graphics card. The existing RTG implementations do this by patching (AFAIK).

A replacement graphics library might offer the opportunity of doing it a lot more cleanly.

[Karlos]

Why firewire? Granted it's a better serial standard than USB was, but USB has surely taken over.

[Karlos]

Well, with respect, I think things like RTG, USB etc should probably take priority - better to focus on what people already have that could do with improved support before moving on to what they could have.

[Karlos]

People have been doing all kinds of clever, open source stuff with FPGAs recently. I'm surprised nobody has attempted an open PCI bridge.

[Karlos]

Creating a new RTG system is not without serious problems either. Ideally, you'd want to support existing cards, but finding the requisite documentation wouldn't be easy.

[Karlos]

@kolla

P96 provides an implementation of the cybergraphics.library for applications that make cgx specific calls. I'm not sure about the converse, but either way the two standards being in competition isn't quite the end user problem you might otherwise think.

Some documentation could be retreived from the linux world. Some even from the Amiga 68k linux I guess.

I was thinking about the documentation for things like mediator/grexx, let alone specific cards.

[Karlos]

I have to admit, I rather like the idea of a replacement graphics.library as a solution, in theory it can be implemented more cleanly than existing RTG for classic systems.

In practise, it might be more difficult to implement than a "work alike" RTG system, ie one that simply patches the OS in a manner similar to P96/CGX.

[Karlos]

I don´t know the Amiga APIs or libraries well enough to understand this concept

How, in this "vision" is support for various buses and cards achieved in your mind? I would think that this would be delegated to a driver that know the chipset. The next problem is that this chipset can reside on a zorro bus, pci bus - or heaven forbid usb bus - LOL

The key to this, I think, is one of abstraction. This "new" graphics.library would itself be agnostic to the underlying hardware and thus need to sit on top of something lower level, in my mind. The additional functionality presented by existing rtg libraries would sit on top of the same layer and just expose the relevant features of it that the new graphics.library doesn't.

This lower layer would be responsible for detecting/managing the hardware bus and memory space, thus providing a consistent API for actual chip drivers, such that it doesn't matter if your graphics chip is attached by zorro or PCI. For the most part I see bus and memory management as different aspects of the same task - essentially how  you map the device's memory/register space into the system memory map such that the chip driver knows where the hardware registers/memory are located as well as the graphics.library's BitMap allocator knowing where to get video memory from.

I think a lot more thought is required though

[Karlos]

TBH, I would suggest the first thing should be to gauge the level of interest.