Amiga.org
Amiga computer related discussion => General chat about Amiga topics => Topic started by: wawrzon on November 23, 2015, 07:26:25 PM
-
since the old posts have been deleted i just wanted to repeat certain propsal here.
as we know nethier cgx nor p96, any kind of sdk or documentation allowing simply code drivers for these both only amiga rtg solutions, is publicly available. this unfortunate situation seems to be possible to overcome under the table. however an universal, possibly extendable solution may be more handy.
i dont want to force anything, let alone to drain developer resources and propose anything complicated. yet a possibilty that appears to me is usage of either whole aros kickstart or its graphics.library (freed of aros dependencies) as replacement.
aros cybergraphics is api compatible with cgx and contains a wrapper to use existing p96 drivers. of course there are still some bugs, unimplemented genuine amiga calls and speed issues in certain areas, still it might be a better starting point than anything else up to date.
as i say its just an idea, where to contribute for the sake of the platform, as i see it.
edit: typo in thread title
-
This is a great idea, in my opinion. In fact, would it be terrible to start porting in some of Aros' improvements? It's all open source reimplimentations of Amiga OS3.1, right?
I wish I could program worth a damn, 'cause I'd certainly like to help with things like this. Hell, if I had the knowhow, I'd write a warp3d driver for my Radeon card :D People charge too much for the Voodoo cards (not to mention it'd break my nice flow of DVI to radeon and VGA to the indivision).
Does p96 or cgx have any hardware accelerated API within them? Or is that all in the warp3d and/or mesa stack?
slaapliedje
-
This is a great idea, in my opinion. In fact, would it be terrible to start porting in some of Aros' improvements? It's all open source reimplimentations of Amiga OS3.1, right?
I wish I could program worth a damn, 'cause I'd certainly like to help with things like this. Hell, if I had the knowhow, I'd write a warp3d driver for my Radeon card :D People charge too much for the Voodoo cards (not to mention it'd break my nice flow of DVI to radeon and VGA to the indivision).
Does p96 or cgx have any hardware accelerated API within them? Or is that all in the warp3d and/or mesa stack?
slaapliedje
hardware accelleration is not p96 or cgx, both are "only" rtg supporting true color and similar. Hardware accelleration is like you wrote either in warp3d or mesa. Because it is based on graphic cards it is normally faster than using AGA/ECS but not in the sense you mean.
-
amiga rtg solutions as cgx and p96 support 2d hardware acceleration (apparently to a bit different extend) namely the gfx card blitter. 3d acceleration is another matter and is currently handled by warp3d (and upon that basic driver structure by either minigl or stormmesa)
but this is not a subject here. please lets stay on topic or let this thread die if there is no interest.
-
So, I have been playing with the idea of putting together a "minimalist" AROS/m68k akin to what a simple OS3.1 installation is, and my goal is that it should work well on my Minimig (2MB Chipram + 1.5MB Fast ("slow") RAM, IDE disks, serial port). AROS/m68k already bootstraps fine and runs, but it uses 1MB of RAM for the kickstart image, so my first goal is to build an AROS kickstart that fits within 512kB and can be loaded like any other kickstart on the Minimig. Hm, maybe I am posting on wrong topic again... I should make my own :)
-
in any case you can softkick aros from amiga rom as i wrote in the other thread, not messing around much, just to see how fpgaarcade p96 driver works.
otherwise, yes, lets keep threads on topic, dou you open one or should i?
-
If any effort is put into making yet another RTG system, I think it would be great to first investigate if the new OS4.1FE integrated RTG/graphics.library API could be backported to 3.x, and thus share driver and application code moving forward.
I'd inquired about the driver API per this link, but have not seen any response yet.
http://www.amiga.org/forums/showpost.php?p=797841&postcount=26
-
If any effort is put into making yet another RTG system, I think it would be great to first investigate if the new OS4.1FE integrated RTG/graphics.library API could be backported to 3.x, and thus share driver and application code moving forward.
I'd inquired about the driver API per this link, but have not seen any response yet.
http://www.amiga.org/forums/showpost.php?p=797841&postcount=26
it would be closed
-
That makes no sense, why would you want to keep an API closed? You'd want more people to use it, right? Kind of the whole point of having an API....
slaapliedje
-
That makes no sense, why would you want to keep an API closed? You'd want more people to use it, right? Kind of the whole point of having an API....
slaapliedje
not the API but the sources to create the libraries
I would prefer to have open technologies and at least for Aros 68k it would be not usable
-
not the API but the sources to create the libraries
I would prefer to have open technologies and at least for Aros 68k it would be not usable
If the API is open, sources can be written :)
-
If the API is open, sources can be written :)
:-)
-
I'd inquired about the driver API per this link, but have not seen any response yet.
you wont receive any answer. not any soon, neither a satysfying one. also its not the subject here. what im talking about is an open community standard, with open sources, that benefits community projects, not another code trap.
there is a number of rtg projects underway as it look like. many mimic or recreate the existing cards, there already is a chipset driver for. all others face software problem at some point, because or closed sources. no matter who wants to keep them close. here as example:
http://eab.abime.net/showthread.php?t=66865
we have hardware vendors defending their code and openpci standard which neither isnt properly open.
as long as standard and sources are closed, the situation will repeat.
the solution would be to create a common field where interested parties could rely on building drivers for their open or proprietary solutions. once the foundation is laid it would actually prevent unneccessarily reinventing the wheel.
-
If the API is open, sources can be written :)
both the aros cybergraphics api and sources are open,and compatible to cgx (de facto primary) standard, p96 is as well compatible to. so, we do have all material to start with actually. no need to open anything else.
-
That makes no sense, why would you want to keep an API closed? You'd want more people to use it, right? Kind of the whole point of having an API....
slaapliedje
unfortunatelly this exactly is the case. we want to talk about strategic solution here.
-
both the aros cybergraphics api and sources are open,and compatible to cgx (de facto primary) standard, p96 is as well compatible to. so, we do have all material to start with actually. no need to open anything else.
While you would also control source code and the future development.
By the way, I took a quick look into AROS and it seems that graphics drivers are implemented separately from CGX (https://en.wikibooks.org/wiki/Aros/Developer/Docs/HIDD/Graphics). CGX part in AROS is just cybergraphics.library (de facto standard for some sweeteners). The driver API is not CGX or P96 so nobody have to debate which one better.
Hardest part is integrating this stuff into the original, OCS bound, graphics.library.
-
Hardest part is integrating this stuff into the original, OCS bound, graphics.library.
Ideally you'd just replace graphics.library with the one from aros (or use aros).
But the graphics.library design they came up with for aros was not optimised because pc's have fast cpu's and the ocs/ecs/aga driver is the bare minimum implementation and really slow too. It appears to be one of the major issues with running it on 68k hardware.
Sorting that out would have major benefits all round.
-
Ideally you'd just replace graphics.library with the one from aros (or use aros).
But the graphics.library design they came up with for aros was not optimised because pc's have fast cpu's and the ocs/ecs/aga driver is the bare minimum implementation and really slow too. It appears to be one of the major issues with running it on 68k hardware.
Sorting that out would have major benefits all round.
this has been brought repeatedly. though as someone who tests aros on amiga hardware i dont think the difference is so dramatic, even currently. i could think of some testcase measuring difference between lets say 3.9 and aros on the same config with the same resolution using librarytimer. is there something that stresses all functions of graphics.lib to be simply run from the shell?