Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: Gulliver on April 08, 2010, 09:35:27 PM
-
This thread and its corresponding poll are meant to gauge interest in a new Unified open source RTG standart that attempts to support both earlier Piccasso96 and Cybergaphx RTG systems.
-
What's wrong with P96?
-
What's wrong with P96?
Is anyone but OS4 developers able to create new drivers for it?
Oh btw... do you have any qualified developer lined up? and what exactly do you mean with support?
-
It is closed source, there is no freely available SDK, and no one supports it any longer.
On an opensource solution you are able to update and bugfix the rtg standart, whenever you feel to. New drivers can be easily created, and every graphics card can stand the chance of being included, unlike Picasso96 and Cybergraphx.
-
What's wrong with P96?
Lack of readily available SDK for developing new drivers?
-
I voted maybe. If the driver SDK for an existing standard can be made available to developers, I would probably prefer that route, since creating an entirely new one is a much larger project.
-
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.
-
since we have several ongoing projects involved with 68k gfx solutuions, i would just mention wazp3d by alain, warp3d voodoo/mediator hw optimization-fix by matthey, sdl by bernd r, graphics.library with planned gfx support by cosmos, not to mention some approach on aros that might come handy like gallium 3d by deadwood (am i right)... i think it is nothing wrong to call together an initiative to unify the graphic standard as open source.
whoever will pick up this subject - for what i see from last year experience - there will not be many people to attend. there will be an one leading dev. no questions asked. but there is a spirit of cooperative support already. the only chance is to improve something. if it goes broken we will just have to stick to what we already have anyway. so : no risk, only gain possible.
i vote : yes-!
-
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.
I thought this was covered in the other thread (http://www.amiga.org/forums/showthread.php?t=40173), besides it is still in development in case you missed (http://www.morphos-team.net/) it.
-
I thought this was covered in the other thread (http://www.amiga.org/forums/showthread.php?t=40173), besides it is still in development in case you missed (http://www.morphos-team.net/) it.
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.
-
Yes if the user API (i.e. to write programs that use it) is to be CGX/P6 compatible.
-
I thought this was covered in the other thread (http://www.amiga.org/forums/showthread.php?t=40173), besides it is still in development in case you missed (http://www.morphos-team.net/) 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.
-
I voted maybe. I am wondering how it will help the community exactly.
-
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.
-
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
-
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?
-
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...
-
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.
-
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.
-
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?
-
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.
-
I'd support it just to piss off the P96 guy!
-
I'd support it just to piss off the P96 guy!
Let's call P97 :laughing:
-
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)
-
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.
-
@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.
-
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?
-
no
-
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.
-
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.
-
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.
I was paying attention, I was talking about programming for p96 not just drivers but other sofware. I toned my response back to one word because it doesn't really matter to me. I'm just sick of people starting threads like this. Come up with even a hobbled together beta and I'll eat my words. It's all well and good to come up with ideas but lets see them go somewhere.
We have had dozens of thread on great ideas that had tons of "support" that went nowhere.
-
@kthunder: ok, and where is the place to gather and discuss such an idea if not on a forum? maybe it will get nowhere, but why do you get upset just when people discuss it?
-
Well... my vote was no since I really don't understand where this is coming from and why you think this deserves any support whatsoever. But do feel free to point me to any other similar project that actually amounted to anything. And by similar I mean anything involving the same amount of actual work by qualified developers.
-
@kthunder: ok, and where is the place to gather and discuss such an idea if not on a forum? maybe it will get nowhere, but why do you get upset just when people discuss it?
Discussions do nothing! Rolling up your sleeves, digging into the os and rtg docs, programming graphics software, actually doing the work of setting up an opensource rtg standard will do something.
I'm much more impressed with someone who actually gets working, gets his homework done, then comes to us (his "support") for suggestions and help.
If he came to us with a website with all the docs, his programming ideas, maybe some outlines and at least some code with what he is talking about, that is a totally different situation.
-
This thread and its corresponding poll are meant to gauge interest in a new Unified open source RTG standart that attempts to support both earlier Piccasso96 and Cybergaphx RTG systems.
So perhaps you got the thread topic wrong.
-
@kthunder:so people who just want to brainstorm about if some idea is worth considering at all and what the way to take shall hide from you in the corner? concurrent projects have to be started by single visionary programmers. no right to coorinate effort is granted? its redicolous. there is a lot going on without that you probably are aware of anyway.
@gulliver: yeah, the title reads a little misleading, maybe you could adjust that.
-
we have had dozens of threads posted "gauging interest" the question is how much is the author of said post is interested and able. I don't think Ive seen many that people weren't interested in.
Can you program? Do you have any of the materials necissary to do this? Or are you just thinking "boy wouldn't that be great"
Sorry, these threads really annoy me. We have people interested, we have people desparate to give real cash monies for this stuff, but that doesn't get stuff done. Real work does.
-
@kthunder:so people who just want to brainstorm about if some idea is worth considering at all and what the way to take shall hide from you in the corner? concurrent projects have to be started by single visionary programmers. no right to coorinate effort is granted? its redicolous. there is a lot going on without that you probably are aware of anyway.
@gulliver: yeah, the title reads a little misleading, maybe you could adjust that.
Noone has to hide from me. But pie in the sky dreams with no support from the dreamer are vapor pure and simple. Noone was aware of what Dennis Van Weeren was doing and he made what amounts to an amiga clone.
-
@wawrzon
So please tell me which one is better, and I will correct it. :)
-
once again, i think this thread is for what i see just to discuss if such a thing was needed at all. there are individual projects in this direction. however i think anything this scale isnt realistic to achieve all alone.
as for me even i actually cannot program im contributing in a way im able to a few projects, i dont need to justify myself though.
@gulliver: maybe just replace "will" by "would" otherwise it suggests something is already in the works.
-
I know of people who have worked on drivers by themselves. Ahi was created almost entirely by Martin Blom. Thats a complete audio standard and several drivers by one guy.
-
I am sorry, for some reason I am unable to edit it. If Karlos or another mod is reading, please can you do it?
-
Are there enough video projects out there to justify an open source standard incorperating both of the old? or would effort put into other areas make more sense? For example a opensource setup that can coexist with the old.
-
@KThunder
I am sorry, I wasnt ignoring you. It seems to me you are a little bitter towards the Amiga, I really dont know, and dont want to dig into it. But then in the end it is your call, you are free to think and express yourself.
You want to know what my abilities are, that is fine with me:
1. I can drink 3 liters of beer in less than 2 minutes :)
2. I can use a Mac :)
3. I can play Diablo II for an entire night :)
No, seriously speaking, what does it matter what can I or cant I do? If you feel better with an answer, choose the one that suits you most, to make the point you want to make. I am sorry I dont get it. I am just trying to gauge interest, nothing else.
PS: By the way, the three things I can do are truth. ;)
-
@KThunder
I understand your frustration with all things Amiga as we all experience it. That doesn't mean that we have all been lazy and there has been no progress. You need to look around. Gulliver has put together a pretty nice unoficial Boing Bag compilation already. That's not nothing. He is testing 3 libraries I have enhanced. I'm also working on the Warp3D.library in a group effort (Allan Thellier, Bernd AFA, wawa, kas1e, etc) to give better 3D support for the Amiga including a new version of Mesa. I updated a disassembler (ADis) and debugged it to the point that it works quite well when my biggest C program before ADis was a hello world. I helped debug 68k Vasm (Frank Wille) for VBCC at the same time as a disassembler and assembler together can pinpoint errors. I would like to do a version of exec.library next and include some nice patches like my CopyMem, TLSFmem and bug fixes and speed ups. It takes time though. I will probably wait and see where Cosmos goes with his graphics.library but I could probably edit the P96 and/or CGFX libraries to not patch the graphics.library if it didn't need to anymore because it had high color support built in. Cosmos has a lot more time than me though. My day job is busier now than before the slow down while Cosmos doesn't have a day job. I am trying to help the Natami team as well. The question is what are you doing to help the Amiga? I wouldn't ask but you are complaining about people that are involved and doing what they can. That doesn't help.
-
@KThunder The question is what are you doing to help the Amiga? I wouldn't ask but you are complaining about people that are involved and doing what they can. That doesn't help.
My favorite part is when he goes and completely edits a post that someone has responded directly to, making the response seem out of place. I liked the "wah, wah, why are you ignoring me, Gulliver?" one but that got edited already.
-
I like the open ideas posts. It's not like it is hogging up space reserved for news.
If you do the poll first you can think, "70 people want to use this software." Instead of, "I wonder if more than 5 people will even like it."
-
sorry i'm not really adding anything to this. being more of a pain in the arse than anything.
-
i was actually editing post to make myself look like less of an idiot.... it didnt work
and i wasnt whining i asked several questions and made several comments and gulliver didnt respond at all.
-
The nice thing about standards is that there are so many to choose from.
- Andrew S. Tannenbaum
To create a new standard, it takes something that's not just a little bit different; it takes something that's really new and really captures people's imagination — and the Macintosh, of all the machines I've ever seen, is the only one that meets that standard.
- Bill Gates
-
What's wrong with P96?
Lots of bugs that the author refuses to fix.
-
Apart from the possibility of newer/faster drivers and drivers for cards you couldn't use before?
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
-
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.
-
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
One thing that would be interesting would be a native chipset driver that allows software written for CGX/P96 to run on AGA/ECS. Now, in CGX v3, the was an AGA driver that did indeed allow RTG software to work, but only software that would run on an 8-bit screen. It would seem that all it really did was to ensure PPC friendly alignment of BitMaps and implement the 8-bit pixel array read/write functions of cybergraphics.
Ever since experimenting with different EVD's for shapeshifter, an idea that has constantly intrigued me is a 'full' RTG driver AGA. One that is capable of performing RGB->HAM c2p for example, opening the possibility of running RTG software that requires an RGB display. In this model, RGB bitmaps would have be allocated in fast ram and blitting / WritePixelArray()ing them to screen would invoke the required c2p. Not sure how feasible this would be, but a logical extension to that would be that when opening a fake RGB screen, a fake Screen structure would be returned, hiding the true Screen (which would obviously be a HAM customscreen), where even the screen bitmap would be an RGB pixel buffer. Some process (perhaps triggered on vblank) would be responsible for updating changed areas on the real screen, using a delta buffer and/or using flags that can be set when any potentially destructive (ie can change the buffer) operation is invoked, for example calling any drawing functions or locking the bitmap.
It wouldn't be particularly fast, but shapeshifter demonstrated that the concept of RGB -> HAM c2p is possible outside of demos :)
-
I think he was voicing an opinion and not speaking officially for them when he replied.
I talked with Frank about it. It wasn't an opinion.
-
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?
-
It's a commendable idea, but it doesn't work in practice.
I think it's unrealistic to expect someone to write drivers for all the existing amiga graphics cards. Writing graphics card drivers is quite tricky and requires special kind of skillset. There aren't many around who would be capable, not to mention willing.
This would basically lead to a situation that instead of two systems that support different set of hardware we'd have three. Instead of two different systems with slightly different quirks, we'd have three systems with different quirks.
New driver system would also mean that 3d drivers would need to be written from scratch.
I don't have an easy alternate solution to offer, unfortunately.
-
Is there any chance you can put us in contact with him so that we may enter a dialogue.
I'm afraid the answer is no.
-
This would basically lead to a situation that instead of two systems that support different set of hardware we'd have three. Instead of two different systems with slightly different quirks, we'd have three systems with different quirks.
New driver system would also mean that 3d drivers would need to be written from scratch.
Well, we would only end up with 3 different systems because neither of the two existing are willing to open up their SDK... As always, the lack of open-mindedness is what makes people reinvent the wheel... over and over.
-
Dumb question:
Is it technically feasable for this new rtg system to provide backwards compatibility for both Picasso96 and CybergraphX at the driver level? So that there is a chance we can still use old drivers until new ones arrive.
-
I rather like disscusions like these, but I do have to point out that I can really see any future for this.
68k is not going to get any new hardware*... So the C64 and P96 systems support everything that is available. Both are basically compatible... Solid and in use... This idea is just reinventing the wheel without any tangible benefits.
*I really can't see any PCI-E boards for the Amiga being either comercially or technically viable...
There could be some merit in porting AROS's gallium gfx thing to MOS and AOS4... maybe?
-
I rather like disscusions like these, but I do have to point out that I can really see any future for this.
68k is not going to get any new hardware*... So the C64 and P96 systems support everything that is available. Both are basically compatible... Solid and in use... This idea is just reinventing the wheel without any tangible benefits.
*I really can't see any PCI-E boards for the Amiga being either comercially or technically viable...
There could be some merit in porting AROS's gallium gfx thing to MOS and AOS4... maybe?
There may be some benefit for those with PCI busboards if it allows them to use a broader range of GFX boards. I agree though that there is limited upside for those with classic Amiga's but there are some benefits - faster raster and greater stability (bug fixes). Also the poll seems to be pointing in favour of developing a unified open RTG standard.
Weed
-
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.
-
But someone is going to have to write drivers for the new system that support the cards that are already supported by either P96 or CV64... No one is going to do that...
-
I think it's unrealistic to expect someone to write drivers for all the existing amiga graphics cards.
Why would it be someone? Typically there might be someone who will write a driver for his/her card. However, without SDK there's almost a guatantee that there will be no new drivers at all - ever..
Writing graphics card drivers is quite tricky and requires special kind of skillset. There aren't many around who would be capable, not to mention willing.
And again, by not providing the SDK needed, it is almost guaranteed that noone will bother. God forbid any new people who might stumble into this freakshow of a plattform and who might be interested in writing drivers.
This would basically lead to a situation that instead of two systems that support different set of hardware we'd have three. Instead of two different systems with slightly different quirks, we'd have three systems with different quirks.
Ofcourse, but one of them at least having the advantage that it can be upgraded and fixed on - that's what this is all about.
New driver system would also mean that 3d drivers would need to be written from scratch.
No it doesnt. 3D on m68k is not that much of an issue in the first place.
I don't have an easy alternate solution to offer, unfortunately.
I just wonder what people like you will do when MorphOS eventually is in the same situation :)
-
Just top put things in perspective - imagine if AHI was closed up like P96 and CGX, and what that would mean.
-
But someone is going to have to write drivers for the new system that support the cards that are already supported by either P96 or CV64... No one is going to do that...
What do you know about that? As I wrote before, the typical scenario is not someone writing all the drivers to replace CGX and P96 all over, it's someone writing a driver for his/her card, and to be able to tweak and test out things with his/her own hardware. Ofcourse the best would be if one could do this using existing SDKs for CGX and P96, since they no doubt are superior to anything a new RTG would be able offer in years. However, today this is not really possible without reverse engineering and and a lot of guesswork.
-
Just top put things in perspective - imagine if AHI was closed up like P96 and CGX, and what that would mean.
Not much if you consider who wrote the existing drivers.
-
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.
-
perhaps the existing ahi drivers just work perfectly, dont recall who actually wrote the pci ones, but all in all i think soundcards are not that a problem atm and if they were a driver could be written.
but what concerns other things like rtg and especially warp3d there is an unnecessary amount of work people (i mean actually matthey) are forcred to invest in fixing it after disassembling. while if it was open maybe amiga might have working, as much as possible up to date, 3d accel solution and not a pile of rubbish what it is atm.
-
But it's AHIs open nature who enabled other developers besides Martin to do so.
That isn't the impression I got.
-
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.
-
That's the way we would like it to be for the rtg systems too.
I'm well aware of what is available, but the thing is... look again at who actually wrote the existing drives, somehow I think they would have gotten access even if it was closed source.
-
@golem: once again, what ahi drivers you immediately require that are missing? i think the ahi job has been done quite decently, what isnt true for rtg anymore. there is a lot of things that might be improved or fixed if the standards were open source. i dont say they would be fixed but they might. such an example is inexistant support for w3d on mediator radeon that pretty much rules this card out against voodoo, which drivers still have to be fixed. the best supported to date are i think b- and c- visions. how many years ago the drivers were written exactly. i dont recall.
and i think we seriously have to stop thinking of amiga software on profit basis. it is a hobby, so it is either open source or nothing. the consumer base is too small to generate income. not so hardware wise since it cant be done in the kitchen. i dont know exactly if this is sad , but it is the truth.
-
@golem: once again, what ahi drivers you immediately require that are missing?
The ones I mentioned obviously.
and i think we seriously have to stop thinking of amiga software on profit basis. it is a hobby, so it is either open source or nothing. the consumer base is too small to generate income. not so hardware wise since it cant be done in the kitchen. i dont know exactly if this is sad , but it is the truth.
Good thing we have AROS.
-
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 (http://grex.amigaworld.de/index.php?lang=en&page=40) 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?
-
I believe the next step should be to outline goals (in persue of a bounty).
I am thinking on a bounty. I already emailed power2people (AROS bounty system), and they said they are willing to help with their website and bounty management system on AmigaOS bounties.
What do you think?
-
If by "support" you mean "use if it is better" then Yes.
edit: 1000th post - woohoo!!
-
How does AROS and RTG relate?
Enquiring minds want to now.
-
Those are the drivers from the main m68k ahi archive.
Yes, I see most of those predate AHI being released under the (L)GPL, which was kinda the point I was trying to make :)
-
How does AROS and RTG relate?
Enquiring minds want to now.
Search for Bernd AFA :)
-
@bloodline: ok, ill notify him of the thread.;P
but he will not do the job.
who would probably be the right person is alain, but his projects, wazp and mesa, are keeping him busy enough already. i also have had a talk on subject like that with both already some time ago, and they regarded i too big a task to handle. (i believe i was thinking of w3d driver for radeons)
-
Yes, I see most of those predate AHI being released under the (L)GPL, which was kinda the point I was trying to make :)
What does (L)GPL have to do with any of this?
Besides, no - it was not the point you were trying to make, I know you too well - your point was that some of those drivers would have been written anyways, because those who wrote them would happily have used a pirated SDK ;)
-
I have not look lots in AROS driver working, because i know, the Problem of writing drivers is the Hardware dependent Part.And there are lots drivers for classic here.writing this all as opensource again, is a years Job.
only thing thats not so hard and possible is use the P96 HW drivers due a wrapper.or best to get the P96 driver source.
the P96 driver api have some calls for blit,rectfill, openscreen, close screen, and hardware mousepointer show.there need a wrapper do that AROS code call this functions with correct Parameter.Because winuae driver is here, there can see what Parameters must send.
Or use gallium 3d on classic, but i dont know if that support ATI or Voodoo Gfx Cards
-
but gallium is not a replacement for an rtg system? i expect perhaps it could be used to replace or improve warp3d but not the rtg itself. besides from what i remember gallium doesnt support r200 only >r300 so radeon9xxx series is out of the question and that are exactly the pci graphic cards is that have decent driver support on all amiga(oid) brands. i recall there were lately some 5 v tolerant radeon pci cards. perhaps effort should concentrate on writing openpci driver for such a card to get gallium based mesa or warp3d based support later. although im not sure if this isnt pile of bs what i write.
-
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.
-
Which existing graphics cards for the Amiga have chipsets that support the VESA standards (and which version thereof)?
-
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?
>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?
Yes its a driver system, the other part do then the AROS Code.
Even if it is a 3d system it can do 2d actions.For example to scroll a bitmap there need a rectangle polygon use and attach to the screen data as texture on the gfx card.now the rectangle is blit to another position, and the data is move.same can do with rectfill, that contain a solid color textur.
i think sooner or later the code from older Radeon driver is move to work in gallium too.But Gallium currently is very young and so the replacement of the older Linux driver API is not finished yet.
http://www.x.org/wiki/RadeonFeature
Gallium is also design to give best speed on virtual systems.
-
Which existing graphics cards for the Amiga have chipsets that support the VESA standards (and which version thereof)?
obviously at least those pci:
voodoo3 - vesa 2/3 (would impy also voodoo 4/5)
radeon9xxx
http://www.geos-infobase.de/HWARE03.HTM#
@bernd: ok, then i misunderstood something about gallium, it then does rely only on a (gallium) hardware driver. in this case i suppose 2d graphics could be wrapped to be implemented by 3d means as you suggest.. maybe not all that heavy.
-
@karlos:
but if we are going for vesa pci cards anyway, do we really need one already supported by amigaos drivers if gallium interfaces directly to the hw via vesa if i understood you right?
edit: would amithlon vesa2 drivers be of any help? i dont know how it is done on amithlon, nor on linux for that matter, does the kernel contains them or what?
-
@karlos:
but if we are going for vesa pci cards anyway, do we really need one already supported by amigaos drivers if gallium interfaces directly to the hw via vesa if i understood you right?
I was just asking, not steering. I just was thinking about where I'd begin if I had to start out from scratch. VESA has been around a long time and I suspect even the older cards (read Cirrus Logic based) may support it.
-
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.
-
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.
-
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
-
talking about a dead horse
7 pages about: galium, cgfx5, p96, aros, vesa ...
but not a single posting from a well known coder saying .. it could be (easily) done
.. a dead horse
-
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.
-
talking about a dead horse
7 pages about: galium, cgfx5, p96, aros, vesa ...
but not a single posting from a well known coder saying .. it could be (easily) done
.. a dead horse
Piru and others have said it'll be a lot of work. I think we all understand that. The point of the discussion is, what should it be like. And do we want it?
-
I agree with Bernd " gallium is a 3D driver with most parts similar to warp3d , some parts are upper level (use more recents cards so accept more parameters) some part
are more low-level and works very close to the gpu so allowing to do 2D opérations on surfaces/textures looking much to cleararray/writepixelarray
so making a wrapper p96->gallium is certainly possible
badly gallium exists only for more recent cards
so it is not a solution for older cards.....
Alain Thellier - Wazp3D author
-
How does AROS and RTG relate?
Enquiring minds want to now.
CyberGraphics.library under AROS is supposed to be somewhat if not fully compatible with GyberGraphX3. If it is already set to support Gallium drivers for modern hardware then I'm all for it. Gallium looks like a plausible solution.
If we need backward compatibility in hardware, FPGA-based solutions will make the grade whether we're talking about Natami or some future solution based on MiniMig's cores. In order to make drivers for them, we won't be able to depend on the MorphOS team or OS 4 team to backport their APIs to OS 3.x or AROS. We need something new.
As a developer, I support the open-source solution so if one developer gets fed up with it someone else can take over without having to beg, borrow or steal the other person's code. That's what open-source is all about whether we're talking about the AROS Public License or LGPL.
I voted YES!
-
talking about a dead horse
7 pages about: galium, cgfx5, p96, aros, vesa ...
but not a single posting from a well known coder saying .. it could be (easily) done
.. a dead horse
it is just discussing the outline, where also contributing users might have something to say. but then your opinion is more than welcome. so you do not deem it realistic-
-
badly gallium exists only for more recent cards
so it is not a solution for older cards.....
Alain Thellier - Wazp3D author
I think it take so long that the Radeon drivers > 9200 for OS4/MOS need so long time or other drivers(for mac) need so long times because its closed source.so they cant just copy and paste a driver and it must develop from 0 and the Users of course must pay this additional effort.
but as can see there are drivers for Linux here, so i dont see a big problem wy a copy and paste not work.
also for 68k there are good low level debuggers here(winuae debugger, hrtmon), so a function during interrupt or layerlock can single step and look how it work.
I think a 2d GFX driver source have always this functions as can see on the P96 driver API
open a display with a resolution and depth and return a bitmap address
close the display
alloc mem on gfx card
freemem on gfx card
set a Hardware pointer image on GFX Card
move the Hardware cursor
blit a rectangle
rectfill a rectangle.
Thats the most important things that need on hardware for 2D.
But because i miss lots of programs and features on all AOS, i better add this to 68k AOS, because its the easiest way to get features because of the good debuggers here that help to find every Problem, i dont have the time and fun to spend on low Level stuff.because with a new display driver i cant use more programs.
but i think a opensource Driver API is a big step to make driver that exist on Linux easy working on 68k too, so change a old Linux driver that it can work in Gallium is maybe not the biggest work, but there need somebody who want do that.
-
@bernd: you dont want to debug hardware drivers under uae i suppose?
so what do you propose, i dont get it besides that you like 68k, to port linux drivers over?
to establish vesa as standard on amiga to prepare it to accomodate gallium? im losing the grip on that. can someone outline an overall concept?
-
>to establish vesa as standard on amiga to prepare it to accomodate gallium? im losing the >grip on that. can someone outline an overall concept?
Vesa is only a function set to open/close a screen on a specific resolution.I guess to use it you need a X86 CPU.
but to give usefull speed you need a bitblit command for the GFX Card, that can copy blocks on the GFX Card fast and also a rectfill command.
maybe to make live easy in a driver you can open the display in Vesa and then use the function from Linux that do blitblit and rectfill.
so this avoid handling with hardware registers to open screen
But i dont know if when a screen is open in Vesa mode the GFX Card work in linear mode and not work in 64 kb mode andif VESA work on non X86 CPU
when work in 64 k mode all is slow.
-
>A little dig around shows driver code for the following in x.org
If you want search, you need look for drivers for Big Endian Systems.maybe PPC or so.
i look on a link and it include X86 files.
-
>A little dig around shows driver code for the following in x.org
If you want search, you need look for drivers for Big Endian Systems.maybe PPC or so.
i look on a link and it include X86 files.
The GD5446 code(PicassoIV) seems like it will compile for ppc linux too. Look in the configure file.
xfree86 (xf86 or x86) is the name of the system regardless of cpu platform.
-
Vesa is only a function set to open/close a screen on a specific resolution.I guess to use it you need a X86 CPU.
but to give usefull speed you need a bitblit command for the GFX Card, that can copy blocks on the GFX Card fast and also a rectfill command.
VESA is more than just opening a screenmode. VESA 1.0 may have been limited to setting the resolution and timing, but remember it's currently at version 3 or something.
Check the VESA/AF standard. It specifies hardware accelerated rasterization of primitives, bit blitting and the usual gamut of 2D operations.
-
Its allways nice to have a "new standard" ... but how much is it worth without support?
As far as I know, its ONLY NVidia with the latest generation of gfx-cards supporting Vesa3.0.
Most other cards are only Vesa2.0 (all ATI-cards / Matrox / SiS ..).
-
vesa 2.0 had operations for querying cards for features as well as setup for video modes etc. vesa 3.0 has some 3d operations in hardware, but it is difficult to find info on3.0 for programming or card support.
I dont think 3.0 is in rom it is a program you setup and it has to support your card. there isnt any real reason it has to be x86 only or even isa/pci/agp/pcix
-
Is it 3D acceleration in VESA 3 or just that it exposes accelerated operations in general?
I had the documentation here someplace. Never print anything out if you actually intend to read it :lol:
-
From Wikipedia (VESA BIOS Extensions):
VESA BIOS Extensions (VBE Core) 3.0 [Sep. 1998]
A superset of the VBE 2.0 standard. This standard adds refresh rate control, support for stereo glasses, improved multi-buffering support and other functions to the VBE 2.0 standard.
* Triple Buffering. Allows high speed applications to perform multi-buffering with less screen flickering and without having to wait for the graphics controller.
* Refresh Rate Control using GTF timings. This allows applications and operating system utilities to change the refresh rate in a standard way on all VBE 3.0 graphics controllers. Important for stereo applications, since when stereo is enabled, the user’s effective refresh rate is cut in half.
* Stereo Page Flipping. When viewing an application using stereo glasses, software needs to page flip twice as often as normal, because it needs to generate separate images for each eye. This new feature allows stereo compatible software to display properly.
* Hardware Stereo Sync. Allows stereo software to determine if there is a connector for stereo glasses on the user’s graphics card.
-
Two good URLs on GPU coding which I found at the aros-exec.org board:
Understanding GPUs from the ground up (http://www.botchco.com/agd5f/?p=50)
and from the same blog:
Notes about radeon display hardware (http://www.botchco.com/agd5f/?p=51)
This is the source posting on aros-exec:
Two tutorials for coding ATI Radeon drivers (http://aros-exec.org/modules/newbb/viewtopic.php?topic_id=4523&forum=4&post_id=39716#forumpost39716)
Worth mentioning I think, as he takes a developer step by step in how to initialize a Radeon PCI card on a x86 PCI bus.
The code won't be much help, but the knowhow which he shares is good.