RTG API replacement - Lets finally do this

[Heiroglyph]

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

[Heiroglyph]

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

[Heiroglyph]

I'm open to debate on anything.

My main concern was using an available, supported, open compiler that can produce Amiga binaries.

gcc is available and open, but isn't really supported on 68k, it's pretty much untested legacy code and it can't make HUNKs properly.

clang is compatible enough with gcc that many gcc-isms still build. I have no knowledge of whether clang even handles 68k.

My secondary concern was readability. Targeting the one compiler we really have left for the one platform that this project would target would make the code a lot cleaner and more predictable.

As far as I can tell, Aros uses gcc primarily to target platforms this project isn't concerned with and now they are mostly stuck with it trying to backport to 68k.

If at some point in the future this project is complete and Aros isn't, vbcc is available for other platforms if we choose to expand to them.

IMHO, it's a lot easier to port from a working and tested 68k to new platforms rather than get everything working on a new platform, then port back and hope for compatibility.

[Heiroglyph]

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.

[Heiroglyph]

then you will fail im afraid, because you will have to keep the sources synchronized by hand, among others. i wish you luck nevertheless and am curious how you are going to go around this and how far you get.

I very well may fail, but you're at least missing some points.

This isn't a fork of Aros.
This isn't an OS.

This is a replacement RTG system for AmigaOS 3.x.
This is based on Aros.
This uses the same license as Aros.

There's no keeping the sources synchronized beyond watching for bugs we both share or code that the other team did better.

In the future, maybe the project will expand to include more AOS libraries, but for right now, it's just a 3.x 68k RTG system.

[Heiroglyph]

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)

[Heiroglyph]

thats an approach i agree with, if its feasible, that is. see my afa-os mention, and my other previous postings on such subject.

I thought maybe we were misunderstanding each other. We're generally somewhat on the same page about what we need for the future.

This would be a lot like AfA, but HUNK. I'm adamant about native HUNK format libraries.

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

currently aros rtg system contain a rather serious limitation on amiga hardware, i asked toni to fix provided a testcase. it doesnt notice when its running out of vmem and needs to swap to main memory, so opening a second screen that doesnt fit into vmem, as example, causes (partly) corrupted, unusable display even if not a crash.

that is an example of what needs to be kept an eye onto. at least this is what kept me from providing current aros binaries to vampire team for testing.

Once we have something we'll definitely need your feedback since you know some Aros quirks.

[Heiroglyph]

lol, as creative as those are, it's going to be more like CGX.

I was thinking of something more boring less stuck to a year like OpenRTG.

[Heiroglyph]

Yes !
Vote for Pablo in 2016 !

Because its no crazier than any other option.

Back on topic, open RTG and mediator drivers?
Good idea.

Assuming this works (I'm still just scouring the Aros source to become familiar) Aros can load existing P96 style .card files so the assumption is that it's possible to use existing P96 drivers in addition to Aros style drivers.

Whether the secret sauce in the Mediator drivers that allows card to card DMA will still function is anyone's guess.

Does anyone know if Mediator DMA works on Aros 68k? They don't use Elbox libraries if I'm not mistaken.

First things first, learning the aros codebase and getting some of it patched in.

[Heiroglyph]

To anyone interested, how is the Aros running at the moment on real Amigas rather than emulators?

I'd really like to see what I'm working with. Who knows, maybe it's not as bad as it was a few years ago when I was first interested.

So far, I've got a nightly build running on WinUAE, but that's pretty limited and far faster than real hardware.

[Heiroglyph]

on my a4k 060 id say reasonable. especially rtg. the problem is with the available desktops, each one has its drawbacks, workook is too proimitive, wanderer doesnt save some prefs in right endianness and has slow dir sisting routine, scalos eats up too much chipram, magellan is too unintuitive and more a file manager imho. also the new versions are slower than original.

Yeah, the desktops make a big difference and it's hard to separate whether it is Workbook (for example) or drawing operations being slow.

you can turn off jit in uae, then it will be actually even slower than the real thing. however if you want to get aros running on your real machine to see for yourself, i can help you.

I've tried a few variations of that.

Running it as approximate A1200 speed, no jit, etc. give me a result, but it's hard to judge if it's correct.

For example, I'd assume that memory speed would be orders of magnitude faster than any real system, even with RTG.

When I run WinUAE as fast as it can go, screen and window redraws are just slow. With approximate 020 it's massively slower so to me that implies that it's CPU bound and not so much memory speed bound.

Given the emulated system/RTG memory bandwidth available, even if the emulator is wasting a lot of cycles and moving byte by byte, I'd expect better. It's not like it's using a chipset screenmode.

There have to be basic design problems that multi-GHz x86 is covering up.

AmigaVision is one way I've been testing because it comes with a few more things, the nightlies are very bare bones.

If you open the System drive In ArosVision, then drag it's position to a new location a few times, it stalls for a second or more every few drags. What can take that long, even with JIT?

I'm not just complaining, I want to know what's happening so that it can be corrected.

[Heiroglyph]

Sure,here:

A4000 D, with and without Mediators
Cyberstorm 060 Mk2 w/scsi or warp engine 040
Radeon and voodoo 3 pci, Picasso II zorro
Pci network and USB
Scsi card readers, lots of various drives

[Heiroglyph]

Oh, I've only tested rtg modes, that's all I cared about using at the moment.

[Heiroglyph]

I can get anything to any type of drive I need.

I've got Mechy's SCSI card readers on the Amigas and the PC's with Linux and Windows have SCSI and IDE plus USB multi-card readers.

It was my understanding that the Amiga P96 drivers and Mediator were supported in Aros as was the Amiga P96 driver for the Picasso II. It's in the source code, do they not work?