Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: Heiroglyph on May 20, 2016, 06:06:26 PM
-
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
-
Amen brother!
Where do I sign? :)
-
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
-
just lately in process of moving to gcc6 kalamatee added some code to the build system to allow alternate compilers like clang. perhaps vbcc can be introduced to aros build tree. it can be built itself for different targets rather easily. the question is, is it worth it? im not sure since deadwood experimented with vasm without the resulting binaries being much better. all that must be evaluated.
anyway the crictical 68k binaries, especially those in amiga-m68k theoretically could be built that way. however i wouldnt expect that things like register parametrizing macros present for neccessary functions for 68k could/should be avoided or otherwise hidden from the code. as other compilers have also certain ways around it.
i think whoever has a good idea how to handle this better should enter dev ml list and discuss it with aros team. gcc couldnt be improved to handle this in the past any beter alas. currently gcc6 also seems to be buggy producing crashing code at times, maybe its time to take care of this?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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... :)
-
This is a replacement RTG system for AmigaOS 3.x.
This is based on Aros.
This uses the same license as Aros.
thats an approach i agree with, if its feasible, that is. see my afa-os mention, and my other previous postings on such subject.
There's no keeping the sources synchronized beyond watching for bugs we both share or code that the other team did better.
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.
-
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)
-
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.
-
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.
-
Very cool to see this and I hope it takes off. I would be more than willing to test any mediator based stuff you do. My system is as up dated as you can get too. I have both a voodoo 5, 5500 and a Radeon 9200 on my mediator. 060 and a PPC if you decide to support PPC at all.
-
Do you want a name for this project? May I suggest Pirate96 :D
-
Do you want a name for this project? May I suggest Pirate96 :D
Atleast be a bit creative:
Dali16
-
Very creative ;)
-
Do you want a name for this project? May I suggest Pirate96 :D
or Pablo2016
-
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.
-
or Pablo2016
Yes !
Vote for Pablo in 2016 !
Because its no crazier than any other option.
Back on topic, open RTG and mediator drivers?
Good idea.
-
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.
-
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.
The current P96 driver for Vampire (written by Jason M.) does exactly this, works on both Aros and P96
-
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.
-
Does anyone know if Mediator DMA works on Aros 68k? They don't use Elbox libraries if I'm not mistaken.
amiga pci bridges support is not complete on aros. it deosnt work as it is now. maybe you can view the cards present, but you cant use them. for details please ask jaosn and toni.
pci hidd code for mediator an prometheus is here:
https://trac.aros.org/trac/browser/AROS/trunk/AROS/arch/m68k-amiga/hidd
-
To anyone interested, how is the Aros running at the moment on real Amigas rather than emulators?
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.
So far, I've got a nightly build running on WinUAE, but that's pretty limited and far faster than real hardware.
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.
-
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.
-
you wont get an appropriate speed approximation with uae. set it as 040 without jit but not cycle exact to 020 and its slower than you will get on real hw in my case.
btw give me your specs. do you have a drive or some bootable flash cars you can sacrifice to try aros out on your machine just once;)
what concerns wondows redrawing delay it might be fixewd in between, im not sure olaf has updated since then. btw is this on amiga or rtg screen? nightlies are not barebone. you can download contribs as well and merge them in. amiga software and libs you need you will find on the net or on the aminet more specifically. while i admire olafs work its a bit overloaded and not suitable for testing.
-
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
-
Oh, I've only tested rtg modes, that's all I cared about using at the moment.
-
as i said everything, that is behind pci bridge will be useless at this point im afraid, but you are free to experiment with it or add lacking support yourself if you feel like that;)
so basically a4k with a 060 and scsi sounds good. you only dont have any compatible rtg, say a zorro one. an a4k has a problem to boot aros from internal ide, some timing issue, unlikely a1200, but scsi should be fine.
do you use ide drives on scsi, via scsi-ide adapter? because the easiest is to copy aros files to a partition via uae and i dont know any method to attach there scsi hds. instead to access an uide drive sb-ide adapter should no issue.
-
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?
-
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?
then i can send you a small aros installation that should start on your machine. you simply need to remember to boot from scsi, not internal ide as its slow and buggy. there is anyway only minor changes you need to apply to a nightly.
what concerns p96, yes it works, as long as its only behind zorro, not pci. the pci implementation is not complete (for amiga bridges). im not the person to ask whats is missing exactly. id have to look through dev ml archives to find out, but ive been kicked out recently and didnt bother to reregister.