AROS Vision 2.4 uploaded

[SamuraiCrow]

I'm trying to get the 68k version of AROS to boot from Ezrec's Gitorious Git repo.  Soon I'll be able to optimize things for you.  (And I also intend to do for Allegro 68k what NovaCoder did with SDL 68k.)

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

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

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

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

[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.)