Given all the recent drama regarding the current situation in Amiga RTG land, I propose that we finally sit down and create our own open standard and have community control over our own future.

At this point, we can't count on the potentially opened CGX sources. I'm afraid that may be tied up in license hell for some time to come. If we do get that, great, but we can't count on it.

I suggest that we start pulling from and feeding into the Aros CGX-like implementation since nobody seems to have issues with the legal status and it is pretty far along already.

I do have issues with the Aros codebase that are directly related to their development process.

They jumped to an new architecture and completely foreign compiler without making 68k stable first.

That in turn made testing any one component a nightmare and introduced code that has seemingly more macros than actual code. It's like reading a foreign language in places.

I strongly believe that if they had replaced just one library at a time on a 68k system using all other stock libraries, we'd have a stable, fast 68k Aros by now.

This also allowed them to weave in Aros specifics throughout all components to the point that it's almost all or nothing. For example, graphics devices currently need their HID, etc.

So IMHO, that makes Aros more like a reference than usable code, but it's still very valuable.

My suggestion is to do what they could have done to start with.

1. Use a real Amiga compiler such as vbcc since it is still developed and the developer is quick to fix bugs or add features if the Amiga community needs them.

2. Using Aros code as a reference, write a new, APL licensed Graphics.library compatible replacement that doesn't use any Aros specific code. It should drop into any Amiga system and just work. At this point, even Picasso96 and CGX should still work with this new library because it's a OS3.x work-alike.

3. Do this for each library that requires heavy patching for RTG.

4. Port the Aros RTG code to our new libraries. This may or may not break the ability to run Picasso96 or CGX on our libraries.


This approach also gives us a start on being in control of the OS itself.

The existing version of OpenPCI gives us a way to support Mediator PCI backplanes without signing an NDA.

I have the authority to relicense the OpenPCI source as I see fit as long as it's open, so this could go APL in order to support future PCI backplanes.


What are your thoughts?

Edit: Also posted at http://eab.abime.net/showthread.php?t=82760

Email me at jeperk70@gmail.com and let me know your skill set, skill level, etc. or post it here.

We can hash our details and assign tasks as we go along but I feel strongly that:

All source code must be APL licensed.

It should primarily target 68k. Cleaner code is in preference to cross-platform compatibility.

Each replacement component should be usable on a stock AOS system without requiring our other libraries.

Components will be built as native Amiga HUNK files, not mangled ELF.

Completed replacements will be comparable in performance to original AOS libraries on 68020 or higher. Support for 68000 and 68010 is IMHO optional, but I'm open to debate.

Assembly is permitted if performance or ROM size requires it, but must be accompanied by functionally identical C representations and must be kept in sync.

Both should be easily verifiable by setting a unique #define for each function replaced and by a define used to globally disable all assembly. This will be used for testing and verification of the C versions.

Example:
#if defined(NOASM) || defined(FUNCTIONNAME_CIMPL)
// C version of FunctionName goes here here
....
#else
// asm version of FunctionName goes here here
....
#endif

Components will be built as native Amiga HUNK files, not mangled ELF.

aros build system/gcc produces elf by default, but the binary format is being converted to hunk afterwards for 68k. (elf2hunk)

Completed replacements will be comparable in performance to original AOS libraries on 68020 or higher. Support for 68000 and 68010 is IMHO optional, but I'm open to debate.

aros builds currently 68000 binaries for what i know, except what setpatch provides.

Assembly is permitted if performance or ROM size requires it, but must be accompanied by functionally identical C representations and must be kept in sync.

thats the policy anyway for what i know.

Both should be easily verifiable by setting a unique #define for each function replaced and by a define used to globally disable all assembly. This will be used for testing and verification of the C versions.

Example:
#if defined(NOASM) || defined(FUNCTIONNAME_CIMPL)
// C version of FunctionName goes here here
....
#else
// asm version of FunctionName goes here here
....
#endif

such could be discussed with the maintainers, toni and jason. i wouldnt leave aros build system and fork if possible as it makes maintenance much more difficult. ask toni.

such could be discussed with the maintainers, toni and jason. i wouldnt leave aros build system and fork if possible as it makes maintenance much more difficult. ask toni.

This isn't Aros, they aren't currently involved in this project, although they are more than welcome.

I strongly disagree with the Aros development process. Although I have the utmost respect for them, will share code with them and will discuss options for compatibility, I won't work on that project directly.

btw, the sources of afa-os, which comes closest to what you want to achieven, namely patch/replace some critical aos binaries with aros counterpparts are still within aros repository. maybe they will be of some use for you, even if severly outdated, the project itself unmaintained:
https://trac.aros.org/trac/browser/AROS/branches/trunk-AFAOS
especially they wont be compatible with the current v1 main trunk, which 68k target is based upon.

Would this replacement library also support the custom chipset if active, i.e. do what cpu-blitting does cleanly?

And do you happen to own an a600? I think a vampire would keep the compile time low...

Would this replacement library also support the custom chipset if active, i.e. do what cpu-blitting cleanly?

And do you happen to own an a600? I think a vampire would keep the compile time low...

That's all future features that we shouldn't deal with until it works as intended.

We'll have the source and documentation, so anything is possible.

Nope, no a600. They can send me the A4000 version any time they like though

I'll probably use WinUAE for the majority of work. (I know heresy, but it's blazing fast and has a cool debugger built in)

Last I messed with AfaOS it had some odd exe/elf thing going on.

afa-os dates back to times when amiga-m68k native aros was unmaintained. there was no elf2hunk tool, which was first written by jason, when porting aros back to 68k in oder to ensure aros binaries to run on aos, so far as they dont contain aros library dependencies.