Welcome, Guest. Please login or register.

Author Topic: RTG API replacement - Lets finally do this  (Read 3204 times)

Description:

0 Members and 3 Guests are viewing this topic.

Offline wawrzon

Re: RTG API replacement - Lets finally do this
« on: May 20, 2016, 07:52:56 PM »
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?
 

Offline wawrzon

Re: RTG API replacement - Lets finally do this
« Reply #1 on: May 20, 2016, 07:59:24 PM »
Quote from: Heiroglyph;808854


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)

Quote

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.

Quote

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.

Quote

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.
 

Offline wawrzon

Re: RTG API replacement - Lets finally do this
« Reply #2 on: May 20, 2016, 08:12:10 PM »
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.
 

Offline wawrzon

Re: RTG API replacement - Lets finally do this
« Reply #3 on: May 20, 2016, 08:19:11 PM »
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.
 

Offline wawrzon

Re: RTG API replacement - Lets finally do this
« Reply #4 on: May 20, 2016, 08:43:47 PM »
Quote

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.

Quote

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.
« Last Edit: May 20, 2016, 08:47:13 PM by wawrzon »
 

Offline wawrzon

Re: RTG API replacement - Lets finally do this
« Reply #5 on: May 20, 2016, 08:58:45 PM »
Quote from: Heiroglyph;808870
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.
 

Offline wawrzon

Re: RTG API replacement - Lets finally do this
« Reply #6 on: May 21, 2016, 08:41:42 PM »
Quote from: Heiroglyph;808922

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
« Last Edit: May 21, 2016, 08:46:09 PM by wawrzon »
 

Offline wawrzon

Re: RTG API replacement - Lets finally do this
« Reply #7 on: May 21, 2016, 08:52:06 PM »
Quote from: Heiroglyph;808940
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.


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

Offline wawrzon

Re: RTG API replacement - Lets finally do this
« Reply #8 on: May 21, 2016, 09:47:17 PM »
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.
 

Offline wawrzon

Re: RTG API replacement - Lets finally do this
« Reply #9 on: May 21, 2016, 11:39:12 PM »
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.
 

Offline wawrzon

Re: RTG API replacement - Lets finally do this
« Reply #10 on: May 22, 2016, 12:49:20 AM »
Quote from: Heiroglyph;808958
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.