CGX 4 and P96 SDK

[Gulliver]

Olaf Barthel just posted on http://utilitybase.com yesterday. He is one of the most die hard Amiga developers out there. I don't know him personally but I wish I did .

I have just sent a message to Olaf Barthel regarding Roadshow thru sourceforge.net.
Lets hope he agrees to make it public domain!

[ncafferkey]

Miami or AmiTCP, don´t care which

Older versions of AmiTCP are already open source. The AROSTCP and MOSNet stacks are based on it.

@salax54:

Isn't there already a (third-party) Firewire stack for MorphOS?

[Gulliver]

Just to let you know I emailed Heinz Wrobel and asked him about releasing Envoy 3 in the public domain and its sources if possible.

On another matter, I received an email from the author of a Picasso96 driver for a particular graphics card, and he told me he developed the driver by doing reverse engineering!

[Gulliver]

Bad news again, Heinz Wrobel said no:


From:
"Wrobel Heinz-xxx"
Add sender to Contacts
To:
"Ignacio"
Ignacio,

the answer has to be "No" for the time being.

Regards,

Heinz

> -----Original Message-----
> From: Ignacio [mailto:xxx@yahoo.com]
> Sent: Wednesday, April 07, 2010 05:34
> To: Wrobel Heinz
> Subject: Request to make Envoy Amiga network solution, Public domain
> software
>
> Hi, I am sorry to bother you with this ten year old stuff. The thing
is
> that I have bought Envoy 3 networking solution a couple of years ago.
It
> is great sofware for networking Amigas, and since you have been in the
> past a great supporter and developer for this now small Amiga
community,
> I dare to ask you if will you please allow me to put these files on
the
> Public Domain, so that they are freely available to everyone? I would
> also add if you think it is necessary, that you wont provide any
suport
> whatsoever, and not be liable for any damage at all.
> By the way, if at some point, you are willing to give out the sources
for
> no commercial purposes, that would be even better.
> So please, just say yes.
>
>
> Thank you for your time,
> Regards,
> Ignacio
>
>
>

[arnljot]

It´s a bit poor that the IP holders doesn´t provide any reasons. Not that they have to, but some reasons are more understandable than others, say if for instance envoy contains lisenced code that he cannot give away.

Perhaps we should just all pay Karlos and Cosmos a bundle of cash to make a new RTG system ;-) And Piru and Plato42 one to backport ArosTCP with a GUI :-D

The developer who reverse engineered the P96 system to develop a gfx card driver could have peaked at the WinUAE/UAE code I guess (perhaps that´s what he did). But it´s not the way it should be.

Also, it would be far better if CGX4 and P96 could be unified. Since P96 is exclusive on some hardware(Mediator/UAE) and CGX4 on other(CVPPC and GRex).

How much code from AROS is usable on classic for a CGX back port?

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

[kolla]

It´s a bit poor that the IP holders doesn´t provide any reasons. Not that they have to, but some reasons are more understandable than others, say if for instance envoy contains lisenced code that he cannot give away.

It might be that it legally still is IAM that hold rights.

Perhaps we should just all pay Karlos and Cosmos a bundle of cash to make a new RTG system ;-) And Piru and Plato42 one to backport ArosTCP with a GUI :-D

I would rather see a new TCP stack for amiga systems written from scratch, instead of messing around with this 20 year old ancient stuff. Miami was such a rewrite.

The developer who reverse engineered the P96 system to develop a gfx card driver could have peaked at the WinUAE/UAE code I guess (perhaps that´s what he did). But it´s not the way it should be.

In amiga land, very little is as it should be.

Also, it would be far better if CGX4 and P96 could be unified. Since P96 is exclusive on some hardware(Mediator/UAE) and CGX4 on other(CVPPC and GRex).

Ofcourse, but remember what the prime objectives for those projects were - both started as driver systems for dedicated hardware that were in direct competition with one another, and then expanded into being competing standards for "all amiga graphics cards". A bunch of egotripping jackasses, the lot of them, could ofcourse not agree on anything, and when P96 was chosen for OS3.5+ it was ofcourse ridiculed by the "blue" side (like anything beyond OS 3.1). How P96 SDK could continue to be closed even after being pulled into OS3.5+ is beyond what I can grasp, but in amiga land, anything silly is possible, and even very likely.

A merge of south and north Korea is probably more likely than any merge of CGfx and P96 (aka MorphOS and AmigaOS)

[arnljot]

Yes, I realise that.

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

More importantly is to select what to support.

I think it should have an abstraction layer for amiga bussboards ("native" Zorro) and PCI bussboards (Mediator, GRex, Prometheus). That would be probably an framework on top of expansion.library, pci.library and openpci.library.

Then which cards. Cybervision family cards(64, 643d, PPC), Picasso family cards(II, 4), Voodoo cards and Radeons should come first. Then other related cards (chipset wise).

And screens should be able to be in a grid (side by side, above/below) and stacked(amiga like).

Back to the documentation side of things. Like I said, if it were to be an LGPL product in the end, much could possably be gleamed from open source.

As for bounty funding, I think both Vesalia and AmigaKit could find it in their hearts to get the ball rolling, perhaps even Elbox and Individual Computers too.

I do think that the users would welcome it too.

This time it could be done propperly with more accellerated rasters too like you mentioned in another thread here

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

[arnljot]

A merge of south and north Korea is probably more likely than any merge of CGfx and P96 (aka MorphOS and AmigaOS)

I think you might be right. But hopefully we´ll be able to agree on what should be, and then perhaps motivate someone next to build it.

I think that if we could specify a new API which could have emmulation for CGX and P96 on top of it, it would be a relief to the Amiga community.

Remember, AROS has discussed making Cairo the base and have a CGX emmulation layer on top of that. ATM it´s kinda "side by side" which isn´t optimal. I don´t know if Cairo could be suitable as a basis for an Amiga RTG, probably we´d want to start designing all from scratch.

I´m not too familiar with what´s wrong with current amiga TCP IP implementations, besides them not being open. Which stops them from being ubiquitous in Amiga land like Poseidon could be now. That code is 20 years old shouldn´t mean that it´s bad. After all many parts of the Amiga operating system is, and we´re not opening that can of worms now

The reason why I´m brining up RTG as a pressing issue is Comos´ efforts to improve the graphics.library. To make it RTG compliant. It´s a great effort and best of luck to him! This shows however that some Amiga coders have matured to a level where perhaps elefants can be eaten...

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

[arnljot]

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

If anyone attempts this, it´s going to be a huge project.

However, I think that the openpci guys(guy?) would be the right one to have an alliance with. There is good support for GRex in openpci, and provisional support for mediator in the latest version of openpci.

I dunno if Elbox will come down from the fence and join the lgpl open source party, or if any qualified coders would welcome them if they would given all the bad blood. But lets face that if any of this comes to fruition.

I think that if this were to go ahead, then it first should have a six month designing stage where in parallel a team source needed documentation and structure it in a wiki for the devs.

Any bounty raised should go to a lead developer or a small number of developers.

I know, I´m a dreamer...

[arnljot]

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.

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

[Gulliver]

So where or to whom do I have to give some $ to the Unified RTG opensource bounty?

[arnljot]

hehe, I feel the same Gulliver. But at the moment we´re just throwing around some ideas here.

It´s really helpfull to pick Karlos´ brain, because he´s knowledgeable on the subject. Would be fun if also Piru and Plato42 had some dreams and ideas... (fishing expedition here guys )

[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