AROS Vision 2.4 uploaded

[SamuraiCrow]

I don't intend to do much with graphics card support since my real A1200 doesn't have any free card slots.  I will see how much can be done with AGA though and will see if I can try to add Copper support to the AROS classic Amiga chipset drivers.  (Commodore's Copper support was never adequate to start with.)

First things first however.  I need to get AllegroGL running to see if AGA is fast enough to do proper 3D graphics (like GLQuake, for example) in 256 colors.  Otherwise trying to add a Gallium driver to AGA will fall flat on its backside.  I plan on doing a hybrid blitter-accelerated and CPU texture-mapped mode first.   (4 bitplanes for the CPU chunky2planar, and 4 bitplanes for the blitter-filled shading.)  If it's not fast enough to do anything useful, I might just shift my priorities.

Also of note, try using a non-Windows version of FS-UAE with AROS Vision.  You'll see that when it is capped at the performance of an A4000/40 it's already dead-slow.  I'll have my work cut out for me in the graphics drivers alone.

[wawrzon]

@samuraicrow
lets do first things firtst befrore those bold tasks you are talking about.

does the aros68k nightly curently boots at all under uae? didnt check for a while and last time it did not as it seems. i had also brief contact with toni few weeks ago because of someone with blizzard 060/ppc that did not boot aros but since then toni didnt wrote me back. so if your blizzard dosnt boot, catch the serial debug and bother him.

what concerns optimizations, there is a few issues with core system functions. f.i. memory allocation within exec if i recall and blitting take multiple times in comparison with their genuine equivalents on 68k. there is a tool to compare execution time of individual functionsfor 68k, i need to recall the name. you need the fn files from sdk to have the functions properly identified.the problem is that even having traced down the culprit, improvement may not be an easy task.

[OlafS3]

@samuraicrow
lets do first things firtst befrore those bold tasks you are talking about.

does the aros68k nightly curently boots at all under uae? didnt check for a while and last time it did not as it seems. i had also brief contact with toni few weeks ago because of someone with blizzard 060/ppc that did not boot aros but since then toni didnt wrote me back. so if your blizzard dosnt boot, catch the serial debug and bother him.

what concerns optimizations, there is a few issues with core system functions. f.i. memory allocation within exec if i recall and blitting take multiple times in comparison with their genuine equivalents on 68k. there is a tool to compare execution time of individual functionsfor 68k, i need to recall the name. you need the fn files from sdk to have the functions properly identified.the problem is that even having traced down the culprit, improvement may not be an easy task.

to boot it under UAE you must simply delete one file. Thread about this:
http://aros-exec.org/modules/newbb/viewtopic.php?topic_id=8646&forum=4&post_id=86969#forumpost86969

[NovaCoder]

I assume you still need RTG to run this?

[wawrzon]

to boot it under UAE you must simply delete one file. Thread about this:
http://aros-exec.org/modules/newbb/viewtopic.php?topic_id=8646&forum=4&post_id=86969#forumpost86969

ah,thanks, i might have forgotten this one.

[wawrzon]

I assume you still need RTG to run this?

for what? aros68k? not.

[SamuraiCrow]

I assume you still need RTG to run this?

AROS Vision currently opens to a truecolor screenmode but I aim to make the AGA drivers better.  I'm open to suggestions though.

[OlafS3]

I assume you still need RTG to run this?

Aros 68k runs also on AGA or even ECS and 68000 (even if unusable then). AROS Vision is not (yet) optimized for AGA like Icon set and many others. I have also added small own components that are developed with Hollywood and Hollywood not supports AGA. Other included software does not correctly run on AGA (included are RTG versions). The icon set is Kens icons which are not shown correctly on AGA either. MagicWB icon support is already there but I did not change the icons because I have only found too few icons that I could use. But I would like to work together with the 68k community to develop a version that is suited for both classic hardware, new hardware like FPGAs and emulation and could become a bridge between 68k and NG.

The reason why I kept truecolor was because some software like the "cow" demo or netsurf need at least 16bit.

Regarding optimizations... in Aros Vision are a number of tests who gave partly very different results when run on Aros Vision or on AmigaOS 3.1.. Of course it could depend on different components so it certainly needs some time to track it down.

[wawrzon]

AROS Vision currently opens to a truecolor screenmode but I aim to make the AGA drivers better.  I'm open to suggestions though.

aros vision default resolution may be rtg, but aros nightly should open fine on an aga machine out of the box. as for improvements on planar modes best would be to check back with toni first.

[SamuraiCrow]

aros vision default resolution may be rtg, but aros nightly should open fine on an aga machine out of the box. as for improvements on planar modes best would be to check back with toni first.

I checked with Toni quite some time back.  He's not interested in resurrecting Amigas nor improving AROS to the point that it makes OS 3.x obsolete.  He considers Amiga to be a platform that is better emulated than implemented and only helps out with the development of AROS 68k with the goal of having a free source of Kickstart ROM images for WinUAE.  I might ask Toni about certain undocumented bugs in the chipset that I may encounter but I would otherwise consider him to be of little help.

Jason McMullan would be a better source of help except that he is primarily interested in getting an improved Kickstart for his A1000 and other Amigas.  I think he was given a Mediator-equipped A1200 by another AROS developer but he has plenty on his plate at this point with Arix, other AROS-related projects, and his day job of course.

My motive is to get familiar with the differences between AROS and AmigaOS 3.1 and augment them to the point that AROS supersedes AmigaOS 3.1 in every way possible.  I likely will try to join the Arix team as well so this knowledge will be useful to me in the future as well.

[wawrzon]

I checked with Toni quite some time back. He's not interested in resurrecting Amigas nor improving AROS to the point that it makes OS 3.x obsolete. He considers Amiga to be a platform that is better emulated than implemented and only helps out with the development of AROS 68k with the goal of having a free source of Kickstart ROM images for WinUAE. I might ask Toni about certain undocumented bugs in the chipset that I may encounter but I would otherwise consider him to be of little help.

of course everybody has his own vision on the subject, but cant we accept each others bias and simply work together where applicable? imho toni is a lot of help and has done tremendous work on aros68k already while we look forward towards your contribution.

toni has mentioned today that he was intending to add copperlists support (whatever it is, i dont know) so i just wanted to signalize to coordinate where possible rather than double the effort.

My motive is to get familiar with the differences between AROS and AmigaOS 3.1 and augment them to the point that AROS supersedes AmigaOS 3.1 in every way possible.

i allow myself to quote toni on what he has written me considering aros68k optimizations:

IMHO biggest problems are:

- C compiler that optimizes 68k code badly and can't handle register
parameters. Lost of unnecessary moves between registers and memory. -
Nice new aros-only features that are not needed in m68k version and only
slow down the system.
- Debugging options or sanity checks will slow down it too.
- Internally lots of data is in chunky format (or in format that is not
planar friendly), lots of conversions that are really slow. For example
no media boot screen is planar image that gets converted to chunky and
then chunky is converted back to planar. Horribly slow..
- There is no fast C2P routine, none of existing fast assembly routines
are generic enough or lack some required feature.

I likely will try to join the Arix team as well so this knowledge will be useful to me in the future as well.

speaking of jason, try not to get your own plate too full, please

[SamuraiCrow]

i allow myself to quote toni on what he has written me considering aros68k optimizations:

IMHO biggest problems are:

- C compiler that optimizes 68k code badly and can't handle register
parameters. Lost of unnecessary moves between registers and memory. -
Nice new aros-only features that are not needed in m68k version and only
slow down the system.
- Debugging options or sanity checks will slow down it too.
- Internally lots of data is in chunky format (or in format that is not
planar friendly), lots of conversions that are really slow. For example
no media boot screen is planar image that gets converted to chunky and
then chunky is converted back to planar. Horribly slow..
- There is no fast C2P routine, none of existing fast assembly routines
are generic enough or lack some required feature.

The first, second, and fourth problem here are all related to the compiler.  They are really not problems with AROS but rather with the 68k backend for GCC.

speaking of jason, try not to get your own plate too full, please

Hmmm...  Another goal I have is to get a job outside my retail store janitor staff position.  As I see it, I wish my plate were full enough that people would pay me to do what I'm trained in instead of having me mop floors.

[wawrzon]

The first, second, and fourth problem here are all related to the compiler.  They are really not problems with AROS but rather with the 68k backend for GCC.

is there any way to benchmark the compiler generated code in comparison between the current aros 4.6.2 (i guess it is the current version) and the 68k backends like bernds 4.5.0, zeroheros 3.x.x  (i dont remember the exact version) and the genuine 2.9.x.

[SamuraiCrow]

I'm afraid profiling will do limited good.  Unless somebody makes a better GCC backend, my approach will be to make a new backend for LLVM and its Clang compiler.  But not yet.  That's heavy-duty work and I'd want pay for that.  Tinkering with AGA I'll do on my own time but not compiler work.  (BTW, the PBQP register allocator on LLVM will go so far as to stuff two shorts into a 32-bit int register if it improves execution time.  I wouldn't recommend this allocator for native code generation on a system without OpenCL but this will probably come too with new chipset designs for FPGA machines.)