I decided to have a look in more detail what bits of OS 3.1 are missing from AROS and how much I should really care. For those who've never seen the status, look here:

http://aros.sourceforge.net/introduction/status/everything.php

I don't know exactly how up-to-date the status is but suffice to say, it's past, not future! My post is just skimming the surface, but it's interesting to get into real details.

So, I wondered... what's the biggest missing area, what's important and what's not?According to that page, AmigaOS 3.1 is 81% complete.

Devices

The most incomplete area is Devices (only 51% complete). However, this is due to Audio, CD, Narrator & Printer devices. As AROS has audio and CD support (even booting from a USB CD-ROM) is this a red herring? Narrator device would be a nice retro Amiga-thing but no more.

LinkLibs

Then there's linklibs (60% complete) which is missing something called ddebug.lib. Is this still useful?

Programs

Programs is only 73% complete. We're missing Pointer prefs and an IconEditor (which would be improved tools rather than clones of 3.1 stuff). I can't remember what BRU and CMD are. I assume Lacer is to do with interlace, which I'd consider deprecated even if AROS was running on Natami.

The majority of missing programs relate to printing (Printer, PrinterGFX, PrinterPS in Prefs and InitPrinter and PrintFiles in Tools) This was the most important omission in Devices too. So when we get printing in AROS, probably deprecating the apps rather than cloning them, we'll see a huge leap in the 'Completeness' status. Some work is a-foot there and I think we'll see this bit of the puzzle get solved soon.

Classes

Classes is 81% complete, with the biggest missing area being datatypes (69%). Animation.datatype accounts for most of that, and is missing completely. How much of a legacy thing is this? If Emumiga is a success, would using 68k files be an alternative?

Libraries

Libraries is 90% complete. AmigaGuide.library is missing, though AmigaGuide.datatype is listed as 71% complete in Datatypes. So it's a mixed picture there, and I wouldn't get too concerned about this. Maybe using 68k libraries with Emumiga will be a solution anyway. If it's good enough for OS 4 to mix 68k & PPC code...

Translator.library, like Narrator.device is missing (nice but not essential). LowLevel.library is missing. How important is this for non-Classic hardware?

Workbench.library is only 50% complete, with all elements AddAppIconA, etc marked as "in progress" - so what is or isn't done is a mystery.


Like I say, I'm scratching the surface (the devil is in the details no doubt) but I feel it's an interesting topic. Can anyone answer my questions? Anyone else want to go a-hunting for interesting bits & pieces?

Chris

@clebin

About the pointer preferences, Sonic implemented pointer changes last month plus is working on the screen dragging (and therefore in a optimization and completion of the rastPort), and Mazze wrote the control panel so that part is already complete; since was deadwood to check the completeness, and since he is busy with the Gallium 3d port, i have a reasonable impression that is not up to date.

Saimon69

_________________
Scarabocchi Binari - Italian AROS Blog
Binary Doodles - English language AROS Blog

@clebin

That list requires some updating on it! I guess that a more representative figure would be on the 84-85%. Still it depicts the general picture.

DEVICES:
Narrator device is not part of AmigaOS 3.1 - only upto 2.1, so the inclusion of these is a bit more far-fetched. Still it would be appreciated to have these on AROS.

PROGRAMS:
Pointer prefs is already in place, and work is being pursued regarding printing... Actually there is a printer prefs program, it just does not do nothing beside handling the GUI itself, so it's considered non existent for all purposes. CMD is tool useful for redirecting printing output. So all fall in the same category...

IconEditor is a really missing part and it would be useful to have that.

CLASSES:
Animation datatype is being non existent for quite sometime and has been regarded very important in the past, but seems almost forgotten. It's understandable from the user POV but still...

LIBRARIES:
AmigaGuide.library is missing?! Hmmm, strange as you can read amigaguide documents in AROs multiview!... So something is substituting amigaguide library possibly...

Lowlevel.library also exists, although it's a recent addition (usb joypads are supported through this AFAIK)...

Translator library is not part of AmigaOS 3.1 - only upto 2.1, so the inclusion of these is a bit more far-fetched. Still it would be appreciated to have these on AROS.

_________________
Because Amiga It's not just about technology but it's also about people...

@clebin

Printing is the last major roadblock considering things that are non-existant in AROS, and ignoring things that exist but aren't really ready, or may not be important to most users.

Most users want to be able to save work and print high quality output from programs.

AmigaOS 3.1 wasn't really much good in this regard, its imaging support for high quality print output was minimal, so every application writer would have to roll their own internal translation of on-screen graphics to quality print output (or live with jagged clunky 72dpi bitmaps being output on 300dpi+ printers). Commodore Amiga missed the boat on this one. They should have paid someone, maybe Soft Logik or Gold Disk, who had DTP acumen to create a useful standard structured vector graphics imaging model for all Amiga software developers to use with ease.

Last edited by radical on 30-Mar-2010 at 08:14 PM.
Last edited by radical on 30-Mar-2010 at 08:13 PM.

You guys should forget Narrator device and Translator library IMHO. (But then again if you guys will make those two then they could be ported to other platforms. Port Flite f.ex. or something else to your platform. Do you need an IconEditor because everybodys using PNG icons nowadays anyway.

You guys should concenrate on AmigaOS4 and 100% MUI3/MUI4 compatibility before anything else.

@radical
Quote:

Most users want to be able to save work and print high quality output from programs.

I'm wondering why people still want to print something. I have everything in electric form nowadays. Even some bills are in electric form.

Last edited by Tomppeli on 30-Mar-2010 at 08:15 PM.

_________________
Rock lobster bit me. My Workbench has always preferences. X1000 + AmigaOS4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." -Seymour Cray

@Tomppeli

There's a common misconception that AROS developers are postponing work on modern features until 100% OS3.1 compatibility is reached. This is untrue. So bear in mind that analysing 3.1 API completeness won't bring features such as SMP support any closer (or further away).

Quote:

You guys should concenrate on AmigaOS4 and 100% MUI3/MUI4 compatibility before anything else.

Personally, I see OS4 as a different (but related) OS to the Commodore AmigaOS. The aim of the AROS project is to create an OS that's compatible with Commodore AmigaOS, not AmigaOS 4. That doesn't mean we don't want to progress past OS3.1, just that we may do it in a different way to OS4 and MorphOS.

@Tomppeli

maybe because you don't need to turn on and off a book or a piece of paper and you can read it witout power? :P

Saimon69

Last edited by saimon69 on 30-Mar-2010 at 08:45 PM.

_________________
Scarabocchi Binari - Italian AROS Blog
Binary Doodles - English language AROS Blog

narrator.device and translator.library could be replaced by Giga Voice TTS i am working on.
This would give almost state of the art speech synthesis to AmigaOS.

A few things are missing:
1. Needs to be ported from Amiblitz3 to C, volunteers are welcome (it's only 3500 lines, C-Style, c'mon!)
2. Data. It has only a German voice (mine) so far. We would need more speakers for more languages.
3. A bit more pampering here and there and more time from my side, but a C port would boost up my interesst in the Engine...

I am familiar with Flite too, it is easy to port, but it is not nice when it comes to handling different voices, means adding new voices means always updating the binaries, and the whole thing is quite bloated compared to Giga Voice (even though Flite means "Festival Lite"). The newer HMM voices are also too slow for a Classic to synthsize in realtime.

So, if there is an AROS enthusiast who would be willing to port Giga to C, I would think about providing the sources.

Last edited by Wanderer on 30-Mar-2010 at 09:16 PM.

_________________
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more...
Homepage: http://www.hd-rec.de

@ saimon69, hardwired

Thanks for this really useful info. I like hearing how the big projects are helping towards the smaller core goals. All sounds good - printing would be a huge leap forward by the sounds of this!

Regarding AmigaGuide, there is a datatype for it, but no library - not sure if that even matters..?

@Wanderer

You have a great back catalogue of software!

Perhaps you could post on AROS-Exec and see if anyone's interested in doing a port. How difficult a project would it be for someone looking to get into AROS programming? Are there any dependencies to port, or is it simply translating between languages?

Chris

@ncafferkey

I'm not sure that was what Tomppeli was saying, but I sometimes get this impression despite obviously modern features like networking, USB, 3D or others (some of which we have you to thank for!)

I'd be interested to see people's opinion on the MUI 3.8 compatibility and identify the biggest missing chunks there (or the fantastic progress people are making!)

How interesting/boring is this exercise for everyone?

Chris

@clebin

The engine itself has only dependencies on Amiblitz Includes, which are mostly ported to C already (like file access, prefix tree, dynamic array etc.).
The frontend for playback depends on AHI of course, but is not really part of the engine. The engine just renders into a given memory buffer, so it is 100% platform indepdendent.

The Giga TTS consists of the engine and the developer tools for developing new voices. I think only the engine itself has to be ported. The developer tools can always work emulated. Part of the "tool chain" is HD-Rec, which would be a lot more work.

_________________
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more...
Homepage: http://www.hd-rec.de

IMO:
- AROS seems able to run AOS3.x apps via JanusUAE very nicely, so...
- AROS developers should stop the API mimic process and already start the development of SMP capable memory protected AmigalikeOS, and the next gen AROS API.
- Also I would like to see AROS NG application player for other Amiga flavors

Is there anywhere analyzed (+documented) what are the key areas that need to be solved/changed to evolve the familiar Amiga API to the MP&SMP&64bit one?


(DAMN! I should get my acts together to really try Amithlon, to prove to MY doubting SELF that even a bloated unix like kernel can deliver Amigalike behaviour. So far I do not believe in it.)

Did AnubisOS project deliver anything?

Last edited by KimmoK on 14-Apr-2010 at 08:03 AM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@ncafferkey Quote:

That doesn't mean we don't want to progress past OS3.1, just that we may do it in a different way to OS4 and MorphOS.

And thus ensure that AROS will stay splitted from other AmigaOS variants as much as possible, so that sharing program development effort is harder, and that AROS has the smallest user/developer base possible.

IMHO it would be better for AROS to say "OK, we've cloned the important parts of OS3.1 API, now lets move on to OS3.9 or OS4.0 API". I don't expect such a forward-looking decision though, since post-Commodore AmigaOS developers often have difficulty looking past their ego (e.g. "my way is technically superior", never mind that a more pragmatic way would give a better chance for survival).

Quote:

There's a common misconception that AROS developers are postponing work on modern features until 100% OS3.1 compatibility is reached.

Hmmm, I think there is a difference between copying some existing modern defacto standards (e.g. AHI, Picasso96, MUI, OpenGL) and actually improving on the existing AmigaOS API (such as adding resource tracking, etc) & interface (e.g. a decent Workbench replacement).

Although in the case of a decent Workbench replacement, I think missing OS3.1 APIs would be a hurdle.

Last edited by ChrisH on 14-Apr-2010 at 10:41 AM.
Last edited by ChrisH on 14-Apr-2010 at 10:36 AM.
Last edited by ChrisH on 14-Apr-2010 at 10:36 AM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH


why the os4 api? it's as outdated as the rest. why not go beyond?

_________________
Support AROS sponsor a developer.

"AROS is prolly illegal ~ Evert Carton" intentionally quoted out of context for dramatic effect

@terminills

"go beyond"

ABSOLUTELY !!!!

IMHO: if commercial AmigalikeOS developers are incapable in developing NG api (already), the community should do it !
(AROS NG API / AOS5 API / A-QBOX API / Lorraine2 API / BoiNGball API / OS with Balls API / ...)


Does anyone have the info of how MOS was going to handle NG QBOX and ABOX applications (IIRC, nowdays also MOS has given up QBOX development).
UPDATE:
http://www.morphos-news.de/?lg=en&nid=154&si=1
http://pegasos.si/files/morphos_in_detail.pdf

Offtopic, perhaps, but found my long lost bit of PPC advantage mention:
"Given the above, one might wonder why Q can be based on a microkernel (strictly
speaking it’s only “microkernel like”) and still expected to perform well. The answer to
this lies in the fact that MorphOS runs on PowerPC and not x86 CPUs. It is a problem
with the x86 architecture that causes context switches to be computationally
expensive. Context switching on the PowerPC is in the region of 10 times faster,
similar in speed to a subroutine call. This means PowerPC Operating Systems can use
a microkernel architecture with all it’s advantages yet without the cost of slow context
switches."

Last edited by KimmoK on 14-Apr-2010 at 11:34 AM.
Last edited by KimmoK on 14-Apr-2010 at 11:30 AM.
Last edited by KimmoK on 14-Apr-2010 at 11:28 AM.
Last edited by KimmoK on 14-Apr-2010 at 11:26 AM.
Last edited by KimmoK on 14-Apr-2010 at 11:25 AM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

I would say narrator.device, translator library, and more importantly, updated code based on newer algorithms and knowledge of neural nets, language structes etc is one of The Most Important piece of code possible.

If you dont have room for a GUI, if you cant USE a GUI, then Audio interface is the next most data dense form. Using a sample based method, like the speaking clock, and modern PC methods, is saying you have no idea what the problem is, and really follow the Windows crowd in solving it by throwing machine resources at it, resources which really could be better redirected by adding intelligence to the computer.

What I would like to see first, is a computer that remembers. What you have done, what pixels and text and sound and websites etc are most common and whats new and different and so possibly something to worry about.

Nex I would like to see computers that take that history, and use it to predict. Not sugest as your typing, browsing, etc, but keeping track of differences, and how those differences are altered, or not, as you proceed, so it can work out what your most usual regular patterns of behaviour are, before Microsoft patents the idea of your existance, unless they already have.

But first, Work on the speech thing. Used to be good to have Nick based dialects by directing AmIRC channels to the SPEAK: device.

_________________
The older and more respected a scientist is, the longer it takes to prove him wrong.

@ChrisH

Quote:

ChrisH wrote: @ncafferkey Quote: That doesn't mean we don't want to progress past OS3.1, just that we may do it in a different way to OS4 and MorphOS. And thus ensure that AROS will stay splitted from other AmigaOS variants as much as possible, so that sharing program development effort is harder, and that AROS has the smallest user/developer base possible. IMHO it would be better for AROS to say "OK, we've cloned the important parts of OS3.1 API, now lets move on to OS3.9 or OS4.0 API". I don't expect such a forward-looking decision though, since post-Commodore AmigaOS developers often have difficulty looking past their ego (e.g. "my way is technically superior", never mind that a more pragmatic way would give a better chance for survival).

Note that I said AROS may do some things differently. I just meant that the aims of the AROS project don't necessarily include slavishly following every new API developed by competitors. In fact, we do take a pragmatic approach: for example, AROS's exec.library has new functions taken from both OS3.9 and MorphOS, Zune aims to be MUI compatible, the original AHI and Poseidon are used.

Also, being compatible with the other OSs isn't always easy: for example, there's no standard PCI API, some APIs aren't publically documented, and OS4 and MorphOS are moving in different directions anyway.

Quote:

Hmmm, I think there is a difference between copying some existing modern defacto standards (e.g. AHI, Picasso96, MUI, OpenGL) and actually improving on the existing AmigaOS API (such as adding resource tracking, etc)

I agree, and I was talking about the latter. I meant that slow progress on those features isn't because we're waiting until every obscure function in the 3.1 API is complete before starting on them, it's due to other reasons such as lack of manpower and the inherent difficulties in implementing them in a compatible way.

@terminills Quote:

why the os4 api? ... why not go beyond?

Because you then get into the argument as to whether it is "Amiga-like" or not. After ditching the existing API completely, some Amiga user might ask "Why use AROS instead of Syllable/Haiku", and since it wouldn't run any "Amiga" programs they knew, the answer would be "There is none".

Also, Anubis was trying to go down that path, and look what (didn't) happen to it. It's a damn big job, and it needs someone with a clear vision to be running it.

Last edited by ChrisH on 14-Apr-2010 at 05:44 PM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@hardwired

>IconEditor is a really missing part and it would be useful to have that.

I think the icon Editor is not really need.Even OS4 have only the old AOS 3.x Icon Editor that can not handle OS4 or PNG Icons.

and with Janus UAE, the OS3x Icon Editor look as a native Program, so cant really a Big diffrence see on AROS

Only i think thats miss on AROS now, is Scalos, for those who want a more modern Desktop, or even better Ambient.But i guess scalos can port more easy as ambient.

>Why use AROS instead of Syllable/Haiku", and since it wouldn't run any "Amiga" >programs they knew, the answer would be "There is none".

but when janus UAe can run the 68k amiga programs good integrate, then there is a reason to use AROS instead of other and the AROS API can enhance witrhout backsight look to old Amiga API.

ANd if somebody is too lazy to port his program to new API, he can just let his program as 68k.and because UAE is a box, this program run then memory protect if new AROS support this.

If AROS keep the advantages of AOS easy configurable, files system with assigns drives with more than 1 chars, thats enough.

I for example does not like Unix or windows filesystem.
I have lots assigns to my picture source tree download tree etc.

All is comfort i must miss, when i need downgrade to a Unix or windows file system

Last edited by bernd_afa on 14-Apr-2010 at 06:04 PM.
Last edited by bernd_afa on 14-Apr-2010 at 06:02 PM.
Last edited by bernd_afa on 14-Apr-2010 at 05:59 PM.
Last edited by bernd_afa on 14-Apr-2010 at 05:58 PM.
Last edited by bernd_afa on 14-Apr-2010 at 05:55 PM.
Last edited by bernd_afa on 14-Apr-2010 at 05:54 PM.
Last edited by bernd_afa on 14-Apr-2010 at 05:51 PM.

@clebin

customisable toolbar menu that's what is missing .. :)