Amiga.org
Amiga News and Community Announcements => Amiga News and Community Announcements => Amiga Software News => Topic started by: unusedunused on December 25, 2005, 05:10:53 PM
-
You can download Final AFA OS 3.91.It uses AROS files to enhance OS3.x and should be 99.9999% binary compatible.
Features:
New diskfontlibrary allow the use of antialiased Truetype Fonts in all Apps.There are 2 settings that let you choose optimal AA Quality for your taste.Kontrast and strength
picture Datatype suppport the use of alphachannel datatypes
cybergraphics library offer funcs for alphablended blitting
exec library use 67 funcs from AROS.Some of them are protect against wrong values to reduce risc of amiga totalcrash or help developers to find faster errors in their progs give a enforcer hit.This cost no speed and is done by checking the structure nodes.
If you notice compatibility problems you can remove the exec library.But please report the program that cause the problem
Get it here: http://amidevcpp.kilu.de/afaupload.php3
-
AROS backporting could be something promising for the, no longer developed, classic OS. I already use reqtools.library and i'm going to test this set.
The only possible drawback about this thing, could be that the "new" backported system files would be a lot slower than the originals, since the AROS runs on a hardware multiple times faster than the fastest 68060. Thus, the AROS developers does not have to care much about compiling optimized code.
This is Just a thought, though. I don't have a specific example in mind.
picture Datatype suppport the use of alphachannel datatypes
cybergraphics library offer funcs for alphablended blitting
Can you elaborate about these 2 features? :-)
As for alphablending, isn't that supported already? When you drag'n'drop an icon for expample or you are talking about something different?
-
I'm very curious how stable there are to the originals, as well as how performace speeds and ram requirements compare...
I'd assume that the developers behind AROS are serious about maintaining the Amiga spirit by writting small but powerful code, but who knows, maybe not?
-
I cannot vouch for classic 68k Amiga hardware, however under emulation in WinUAE, this is extremely usable.
Currently, the only functionality that I find useful is the anti-aliased truetype font support; I'm curious if the datatype rendering is as fast as the tightly compiled 68k originals, however given Bernd's close association with WinUAE, I'm hopeful that he will find a way of adding optimisations that make greater use of the native host hardware.
I uploaded a screenshot here:
http://www.amiga.org/gallery/index.php?n=1235
Cheers,
James
-
>As for alphablending, isn't that supported already?
>When you drag'n'drop an icon for expample or you are talking about something different?
The amigaOS 3.x picture datatype does not support alphachannel.When request a 32bit picture from datatype
that support alphachannel the alpha channel byte is always same value
all programs that want use alphachannels must write extra code.powericons too on OS3.x
AFA use same includes as AROS do.Same as in CGX for MOS there are too funcs in
static VOID WritePixelArrayAlpha(ULONG *pixarray,
UWORD srcx,
UWORD srcy,
UWORD srcmod,
struct RastPort * rp,
UWORD destx ,
UWORD desty ,
UWORD width ,
UWORD height ,
ULONG globalalpha )
This func allow a blit when 32bit data is used depend on alpha value of the pixel and let choose a globalalpha
par to make a image in general transparent.
void BltTemplateAlpha_intern(APTR src,
LONG srcx,
LONG srcmod,
struct RastPort *rp,
LONG destx,
LONG desty,
LONG width,
LONG height)
{
this func is used to blit a single color picture(most used in text).But diffrent is that the sourcedata
is not only a bit 0 and 1 mean transparent or not.The mask data must be in byte format,so the transparency can
have 256 steps
Of course progs can do it himself,remember the C64,this machine have no OS and after 1,5 Years this system was
out there were much programs out.
But today developer can compare
windows Linux.And when they see here it is more easy to code andn there is a standard.But on amiga noone
can code for 1 system and use new features and reach all of the splittet and few Amiga Users.
If AFA port to MOS OS4 then all can use it and developer can see that as standard,same as directx 9 is too available for win98
wich was sold with directx5
>I'm very curious how stable there are to the originals,
>as well as how performace speeds and ram requirements compare...
I want AFA be compatible OS because i know that very few are intrestet to use or code amiga.And i dont want
miss a old program if noone code a better.
Make a incompatible OS is waste the rare developer resource and the advantage of Linux win MAC get more greater.
They have compatible OS and more developers.More user than necessary give up Amiga.I know from point
of OS developing it is much more easy say the program is wrong all OS calls work as RKM say than try out wy.
But in RKM stand not much.OS3.x have much undocumentet Features that programs use.
I have done some fixes to the original AROS funcs,hope they come in the sourcetree.I post all in aros list
for example last founds was that on AROS allocmem MEMF_LARGEST dont work (kingcon crash)
AROS obtainsemaphorelook do deadlock when same task always keep a look.On OS3.x this is handle correct
some enhancements to PictureDatatype (MUI toolbar show icons)
When a problem is report that take most time a few minutes to find the problem because AFA is modular.
I need only deactivate new AROS functions and look when the program work to see the AROS function fail
So release new updates with fixes is too in a few days possible
But i cant test all 10 000 or more amiga programs that are out.
So it is important that if somebody find a problem report this.Can be too on this thread.
This is done in the beta stage of AFA 20 Nov-19 dez.Thanks to the User that report.
Now on 19 dez i release the final beta
Until 24 dez i get no Bugproblem or Report.So this is called final.
If AROS add all the changes from AFA then if a program run on AFA it is more realistic
that this program run just with a recompile on AROS.I hope more are motivate to port(or should i better
say compile) their program to AROS.
The speed of AFA is when you bench the functions slower.C cant be so fast as asm.
But in real world progs you dont notice or cant measure that
If so report it.My goal is make AFA in real world app with same features same fast as OS3.x.
if there really a measurable speedloss,the function can optimize or written in ASM
1 example.All know gadtools is fast on OS3.x real amiga and MUI is slower with same look.
MUI use own code that is not in the OS.If most time is used in non OS funcs it help near nothing to speed up OS
same happen when you load a iff image or a jpg image or load a wave or a mp3.
mp3 jpg image is known as very slow a faster OS does not help.same is with picture datatype.The main CPU load is in the jpeg png gif etc. datatype.So AFA use in near future this datatype not from AROS,because the highly optimized asm datatypes out are much faster i am 99% sure
AFA use currently 350 kb RAM when use exec.
If you use kick to fast then this cost you additional 512 kb.But i think with AFA you need that not.
all frequently called OS functions as process structure signal lock semaphores are in fastram from AFA
So all in all you maybe save with AFA mem.
If you use new features of AFA like AA this depend on your system if it is fast enough.
-
I think the idea is really great.
Now, I can update the system on my new ppc amigas along side the old-good 68k based ones.
I love to have new features on my old 4k and 2k.
In any way, seems that the old amigas will never die at all ( really! )
Did anyone test it? Much preformance impact?
-
>In any way, seems that the old amigas will >never die at all ( really! )
Yes thats the reason.I want use my old programs that do what i want and i want use my coded programs in Amiblitz and i can enhance them and use.
I want not fear that on some day no Hardware is available.UAE AFA AROS can run on all.Aros is nice but i cant use them.porting all my programs is too much work.(most have 68k because in the old days the amigas sucsess compare to other system was the speed that come from programs that use asm routines.A X86 PPC is hard to code in asm.)
before UAE i have buy 2 Cyberstorm PPC Cards if 1 get damage i can continue use Amiga.But before 2 years on 1 Card the PPC dont work.
I dont want give up Amiga.If noone want sell AmigaHardware with Good Power price relation OS that fit my needs and availibility then a EMU is need and OS3.x must enhance
-
@bernd_afa
I've been trying to get AFA_OS working on my Amithlon system with OS 3.9. If I put afa_os_loader in my startup-sequence it hangs when Amithlon says it is loading Picasso 96. If I remove the graphics_lib.exe then it does boot but my background pictures etc. don't load and while truetype fonts display they are not antialiased. I guess both the new picture datatype and the antialiasing rely on new features in the graphics library.
I've disabled all the patches etc. I can find in my startup-sequence with no improvement. Any idea why this doesn't work for me?
Thanks
Robert
-
Doesn't work here either so you're not alone.
Doesn't matter where I put the loader, I guess it doesn't like my patches which I don't want to remove.
-
>I've been trying to get AFA_OS working on my Amithlon system with OS 3.9.
>Doesn't matter where I put the loader, I guess it doesn't like my patches which I don't want to remove.
when you tell what patches you run i can test.AFA should run with all.
I get yesterday a report from a User that dont get it running and see in his startup-sequence stand cyreq.
But i search aminet for cyreq but nothing found. maybe you use too cyreq ?.O ask the User what it is
but in teh short time no response
amigathemexperienece i have find on aminet CD.these are backgroundpictures i have test them they work
or maybe i have wrong and you have a link for download
>If I put afa_os_loader in my startup-sequence it hangs when Amithlon says it is loading Picasso 96.
then you maybe do it wrong.it must start after P96 because P96 patch AFA funcs away
The AFA docu say that you must add it at startup-sequence short before iprefs
amithlon startup look like this.I cant test on Amithlon,but the screenshot from Thilo on AFA page
is done with Visual prefs birdie on Amithlon.
What happen when you boot without AFA and doubleclick the afa_os_loader icon later ?
C:RunEnvCheck >NIL: AmigaXL
If WARN
C:Mount >NIL: DEVS:DOSDrivers/AmigaXL/~(#?.info)
Else
C:Mount >NIL: DEVS:DOSDrivers/AMIthlon/~(#?.info)
EndIf
C:LoadMonDrvs
SetEnv Language "english"
SetEnv Workbench $Workbench
SetEnv Kickstart $Kickstart
UnSet Workbench
UnSet Kickstart
C:AddDataTypes REFRESH QUIET
Run > NIL: "DH0:System/VisualPrefs/VisualPrefs"
<-start other patches latest here so you are sure they dont overwrite AFA
<-------------------------- here afa_os_loader should add
<-start patches that you are sure they dont overwrite AFA or AFA overwrite a func of them
and the patches get no result
C:IPrefs
C:ConClip
Path >NIL: RAM: C: SYS:Utilities SYS:Rexxc SYS:System S: SYS:Prefs SYS:WBStartup SYS:Tools SYS:Tools/Commodities