Critical components to open source

[wawa]

Originally Posted by grelbfarlk

Just two questions, does Aros load a kickstart image?

ok. just tested. loading kickstart from 1mb image, not soft kicking and mapping it to ram, obviously, aros is booting without the s-s with an 68020 and 1 mb chip ram. according to avail there is some 94 kb memory left free.

If it was 1MB I could see 1MB of that 1.5MB. And the question was booting with no S-S, AmigaOS4.1 uses 70MB to boot to no S-S?

no. os4 needs those 70mb+ to boot to workbench. you can search up the countless threads all over the forums, about how to reduce this footprint. there is apparently no way. it is already the optimized limit, otherwise its over 80mb.

aros boots to wanderer with under 7mb ram altogether. im not checking that now, if i could reduce it without backgrounds or something.. seriously, everybody who wants has today some 4 ot 8 mb minimum.

I find that hard to believe but I don't know how to check it since Avail doesn't really work the same on OS 4.1 does it? Sorry that's three questions.

yeah. for some curious reason. avail works under aros just fine.

[grelbfarlk]

Originally Posted by wawa

ok. just tested. loading kickstart from 1mb image, not soft kicking and mapping it to ram, obviously, aros is booting without the s-s with an 68020 and 1 mb chip ram. according to avail there is some 94 kb memory left free.


no. os4 needs those 70mb+ to boot to workbench. you can search up the countless threads all over the forums, about how to reduce this footprint. there is apparently no way. it is already the optimized limit, otherwise its over 80mb.

aros boots to wanderer with under 7mb ram altogether. im not checking that now, if i could reduce it without backgrounds or something.. seriously, everybody who wants has today some 4 ot 8 mb minimum.



yeah. for some curious reason. avail works under aros just fine.

I booted OS4.1 no S-S on the CSPPC and avail said something like 135MB total and 105MB free. So 30 megs to boot to no S-S, that's a lot more than I was expecting. So how about we say percentage of RAM to boot versus what's likely configured in the system. OS4.1 I assume the standard configuration is something like 512MB, so 70MB is 13%. I don't count OS4.1 on CSPPC as the standard target system of OS 4.1.

Compare away how much RAM is used booting WB1.3 in a base A500.
In my OS3.9 machines it's about 10MB with ClassicWB and lets guess that standard configuration is 128MB, so 7%. But others would say no that's crap, standard configuration is 16MB+2MB Chip, which would say 62% of all RAM used just to boot.

So AROS' memory consumption is either completely excessive or pretty reasonable, depending on how you look at it. I assume the standard fork of AROS is x86 which would be what, something like 2GB of RAM for 32-bit?

[Daedalus]

Originally Posted by wawa

yeah. for some curious reason. avail works under aros just fine.

Avail works just fine under OS4 too, but the results may be different to what you might expect because the memory allocation strategy is different to that of OS3. "Slab" allocation means that large chunks of RAM aren't returned to the free memory list until actually needed - kind of like how libraries aren't immediately flushed by OS3, but on a larger scale. IIRC the Avail Flush argument doesn't do anything on OS4 for this reason.

Originally Posted by grelbfarlk

Compare away how much RAM is used booting WB1.3 in a base A500.

Base machines generally have the advantage that almost the entire OS is in ROM, which means it doesn't need to be stored in RAM. If that was needed, the RAM usage would be close to 60%.

As wawa said, anyone who wants more than a base machine probably has more RAM at this stage, so it's kind of a silly discussion, especially given that so many people are more than happy to hand over 0.5 or 1MB of fast RAM for a copy of Kickstart in order to speed up access, and even more for loading replacement modules via OS 3.9 or Blizkick. 1.5MB seems pretty reasonable in comparison.

OS4's high initial usage might be a combination of several things - Picasso96, the USB stack and various other modules that would be loaded later during a full boot on OS3 are a part of Kickstart under OS4, so are loaded and running before the startup-sequence is executed. Two 68k emulators are also loaded at this stage stage. And by default there are heaps of drivers loaded into RAM as part of Kickstart that aren't necessarily required - various PCI storage drivers, graphics card drivers and so on. And the slab allocation system mentioned above tends to cache objects, not releasing the RAM until you're running out. So you might find that if you get your free RAM down to a few MB, you can still allocate larger chunks than you think as some of the cached objects are expunged.

[wawa]

Originally Posted by grelbfarlk

I booted OS4.1 no S-S on the CSPPC and avail said something like 135MB total and 105MB free. So 30 megs to boot to no S-S, that's a lot more than I was expecting. So how about we say percentage of RAM to boot versus what's likely configured in the system. OS4.1 I assume the standard configuration is something like 512MB, so 70MB is 13%. I don't count OS4.1 on CSPPC as the standard target system of OS 4.1.

as i told you

Compare away how much RAM is used booting WB1.3 in a base A500.
In my OS3.9 machines it's about 10MB with ClassicWB and lets guess that standard configuration is 128MB, so 7%. But others would say no that's crap, standard configuration is 16MB+2MB Chip, which would say 62% of all RAM used just to boot.

do you want all the additional features aros delivers for free? i mean, an os with function extent exceeding that of os4 but requiring as much space as kickstart 1.3? is that your reasoning? according to what you write yourself aros is already more memory efficient than os3.9 delivering more functionality. and it might be even improvesd, it is open, you know..

So AROS' memory consumption is either completely excessive or pretty reasonable, depending on how you look at it. I assume the standard fork of AROS is x86 which would be what, something like 2GB of RAM for 32-bit?

completely excessive.. maybe by some convoluted logic one could wrap to just to justify some prejudice one is not ready to admit.

x86 is not an "aros fork" it is the same platform and the result of the same development as amiga-m68k or arm, or x64 targets. x64 built from the same sources has smp and i cant even tell the limit of memory it can address, being 64 bit system. people run it on more than 16gb machines for what i know, even if i think it waste of power. dont you think it is extremly flexible for a system to support that wide a range of hardware from 30 years old, to fastest and biggest you can get today on consumer market?

another issue, people sometimes complain about is that aros68k boot iso is 20mb. that seems much to them. funny enogh half of it are ttf outline fonts, you can safely delete. then you are left with a system that is about a size of your 3.x distribution, whether it came on floppies or on cd.

[wawa]

Originally Posted by Daedalus

Avail works just fine under OS4 too, but the results may be different to what you might expect because the memory allocation strategy is different to that of OS3. "Slab" allocation means that large chunks of RAM aren't returned to the free memory list until actually needed - kind of like how libraries aren't immediately flushed by OS3, but on a larger scale. IIRC the Avail Flush argument doesn't do anything on OS4 for this reason.

im pretty certain avail works the same way on aros as on aos. for what i know aros uses on amiga the same traditional memory mechanism for compatibility reasons. tlsf is available but off by default. you can check if aros version of avail is working the same as the os3 one running them side by side on an aros system if you want.

OS4's high initial usage might be a combination of several things - Picasso96, the USB stack and various other modules that would be loaded later during a full boot on OS3 are a part of Kickstart under OS4, so are loaded and running before the startup-sequence is executed. Two 68k emulators are also loaded at this stage stage. And by default there are heaps of drivers loaded into RAM as part of Kickstart that aren't necessarily required - various PCI storage drivers, graphics card drivers and so on. And the slab allocation system mentioned above tends to cache objects, not releasing the RAM until you're running out. So you might find that if you get your free RAM down to a few MB, you can still allocate larger chunks than you think as some of the cached objects are expunged.

aros provides the same if not wider infrastructure as os4 already in its kickstart. extended massstorage (ata), usb, rtg system (cybergraphics), im not sure if pci is enabled, as it isnt working yet with 68k dedicated hardware bridges and so on.. so i dont think this is a valid excuse for ten times higher memory footprint. especially loading everything on early startup, if this is really the case seems to be a wrong strategy..

edit: btw, you can look into this makefile to consult what aros roms content actually is:
https://trac.aros.org/trac/browser/A.../mmakefile.src

and i can post you a boot log, either from x86 hosted, uae or one of my amigas, where you can see whats being initialized.

[grelbfarlk]

Originally Posted by wawa

as i told you


do you want all the additional features aros delivers for free? i mean, an od with function extent exceeding that of os4 but requiring as much space as kickstart 1.3? is that your reasoning? according to wht you write yourself aros is already more memory efficient than os3.9 delivering more functionality. and it might be even improvesd, it is open, you know..



completely excessive.. maybe by some convoluted logic one could wrap to just to justify some prejudice one is not ready to admit.

x86 is not an "aros fork" it is the same platform and the result of the same development as amiga-m68k or arm, or x64 targets. x64 built from the same sources has smp and i cant even tell the limit of memory it can address, being 64 bit system. people run it on more than 16gb machines for what i know, even if i think it waste of power. dont you think it is extremly flexible for a system to support that wide a range of hardware from 30 years old, to fastest and biggest you can get today on consumer market?

another issue, people sometimes complain about is that aros68k boot iso is 20mb. that seems much to them. funny enogh half of it are ttf outline fonts, you can safely delete. then you are left with a system that is about a size of your 3.x distribution, whether it came on floppies or on cd.

Sorry that I called the x86 a fork. I see on Aminet i386-aros is sorted separately from AmigaOS-m68k applications, I took that to mean that AROS-x86 compiled binaries would not run on AROS-m68k. If that's not the case and any AROS compatible binary will run without recompilation under any other architecture then that's great.

If AROS-m68k applications run just fine on AmigaOS 3.x then that's great too, I only know of AFA-OS, which I assume isn't binary compatible.

But my point is if people really like AROS then why mess about with running it on an M68k Amiga anyway, why not run it on the platform where people don't need to argue about a few or dozens of MBs here or there.

Saying if you want to run whatever AROS-i386 application on your 040 Amiga, compile with make target-m68k, that's not practical for most users, they aren't going to mess about with that. That's vastly overestimating the amount of effort casual users are going to but towards their hobby OS. Many people don't have a problem with it.

[Locutus]

AROS-i386 and AROS-m68k aren't binary compatible.

AmigaOS 68k-> AROS 68k aims to be (and probably is to a large extent).

The point is though that all of these architectures live in the same code tree, they aren't suddenly seperate projects or whatever.

As such non-architecture specific code affects all ports (hey the joys of portable software!)

[wawa]

Originally Posted by grelbfarlk

Sorry that I called the x86 a fork.

nothing to be sorry about its just a misconception that needs to be corrected. calling it a fork suggests, that work is done on different branches separately, and whats done on one target doesnt affect the other. thats only partly right. most code is common, however there are necessary architecture and platform specific individual parts as well.

I see on Aminet i386-aros is sorted separately from AmigaOS-m68k applications, I took that to mean that AROS-x86 compiled binaries would not run on AROS-m68k. If that's not the case and any AROS compatible binary will run without recompilation under any other architecture then that's great.

correct. aros doesnt provide fat binaries. aros binaries run only on a corresponding platform, in this case x86 or 68k, and need recompilation to run on another. howeveri would underscore it being recompilation, rather than port, since very few changes to the source might be necessary, if any, to achieve this.

If AROS-m68k applications run just fine on AmigaOS 3.x then that's great too, I only know of AFA-OS, which I assume isn't binary compatible.

aros68k applications run on amiga (os) as long as they are available in hunk rather than elf format (which they usually are) and are not linged against some aros exclusive library (such as arosc or posixc.library). the other way around it is expected that an amiga application for the range of 1.x to 3.x kickstarts should run on aros. there are exceptions and not everything is already properly implemented, but thats the general rule. you will be even able to replace single libraries classes or other os elements between these both.

so, yes, you can say aros 68k and amiga are binary compatible.

But my point is if people really like AROS then why mess about with running it on an M68k Amiga anyway, why not run it on the platform where people don't need to argue about a few or dozens of MBs here or there.

the reason is the same as to use amiga hardware today at all. no matter what os. with aros you have opportunity to use it in potentially more ergonomic way, while keeping the same pool of applications and without the necessity of emulation. certainly you are free to choose anothe aros platform. it is a matter of your own sentiment and preference.

Saying if you want to run whatever AROS-i386 application on your 040 Amiga, compile with make target-m68k, that's not practical for most users, they aren't going to mess about with that. That's vastly overestimating the amount of effort casual users are going to but towards their hobby OS. Many people don't have a problem with it.

you dont necessarily need to compile things yourself. aros has contributions and ports that either are being constantly recompiled or kept ready to be recompiled for a particular platform once there is interest.

also aros software is usually available as source. given that, it might be made available for aros68k amiga target pretty fast, faster than it would be possible to properly port them to amiga. this is the potential benefit, besides the whole bunch of infrastructures aros provides and amiga could possibly take advantage of,

[OlafSch]

@grelbfarlk

AfA-OS is a backport of Aros sources to 3.1, f.e. Themeing in Amikit is based on this. Aros distributions run fine on 3.X as long you do not use specific components like Zune (the open source MUI implementation in Aros). But I personal normally test it the other way round, compile it for amiga 68k and then test it on Aros. As long it uses existing libraries and a compatible GUI it should work.

[wawa]

Originally Posted by OlafSch

@grelbfarlk

AfA-OS is a backport of Aros sources to 3.1

an ancient one, btw. before even aros68k was maintained again. kudos to bernd, who did it. missing guys like him.

[michaelz]

Time to get back to topic. Critical components to open source, not another topic posted full with "aros is open source and that should be good for everyone". It's not the same sentiment and should be in it's personal thread.

[wXR]

Good point @michaelz But so as not to kill an interesting discussion, I will make a new thread for AROS development.

[wXR]

AROS thread kicked out here:

http://eab.abime.net/showthread.php?p=1157590

[IridiumFX]

So, back on topic, given Exec is tightly bound to the underlying architecture, Full-asm and not extremely useful for long term evolution, if we could get the legal rights to touch the OS code, I'd suggest Starting with a c backport of it. I always though that, with an arbitrary simplification of the concept, an Amiga can be fully define by the tuple { Exec, Dos, Intuition, Graphics }

[gulliver]

@IridiumFX

I agree upto some point:

CBM code was a mess, in that every AmigaOS developer used whatever C and ASM compiler they liked, and then they didnt follow any coding standard, so figuring what two different developers did, requires two totally different aproaches.

Backporting to a standard open source C compiler is a very good idea on AmigaOS components which are not speed or size constrained, which happens in many cases. But where speed and size efficiency are required, ASM is a must and now that PhxAss has become open source, it seems to be a very good candidate.

Then it is pretty reasonable to start working with the core of AmigaOS, which happens to be in the kickstart. Wether those components should still remain in a rom is another matter alltogether.

Also establishing some coding standards, and common tools will help build and enhance the entire OS much more easily.

[matthey]

Originally Posted by gulliver

CBM code was a mess, in that every AmigaOS developer used whatever C and ASM compiler they liked, and then they didnt follow any coding standard, so figuring what two different developers did, requires two totally different aproaches.

Backporting to a standard open source C compiler is a very good idea on AmigaOS components which are not speed or size constrained, which happens in many cases. But where speed and size efficiency are required, ASM is a must and now that PhxAss has become open source, it seems to be a very good candidate.

The code should be for a C standard (C89 but consider moving to C99) and not use compiler specific support without good reason. Vasm is also free but supported and is a better choice than PhxAss (default vasm mode is an enhanced Devpac syntax). It would be good to have most code in C but have exact replacement conditionally used assembler routines where there are improvements. Sometimes improvements in the C code can be found from optimizing the assembler output and can be used to improve the C code as well. Having good performance is important on low end 68k systems. AmigaOS 3.9 never really advanced to the optimization stage and it became a bit too heavy for low end users. Some parts of the AmigaOS need improvements before optimizing though. ThoR's layers.library is a good example of a CPU intensive library which has been improved and would benefit from optimization. My benchmarks were showing about 10% improvements on average using P96 Speed with a partial optimization job.

Originally Posted by gulliver

Then it is pretty reasonable to start working with the core of AmigaOS, which happens to be in the kickstart. Wether those components should still remain in a rom is another matter alltogether.

Moving components out of kickstart would cause compatibility issues. Using compilers which generate better 68k code and optimizations could probably get components to fit in a 512kB kickstart again (10%-20% average size reduction is probably possible for kickstart components). New hardware should probably move to a 1MB kickstart. An enhanced 68k CPU could improve code density (reduce code size) another 5%-15% and make compiler support easier for code quality improvements, not that anybody cares about that but me. The whole kickstart can be write protected in memory giving some cheap partial memory protection. New hardware just needs flash MAPROM support. Of course, with the current situation it would probably be better to do something similar with AROS.

[IridiumFX]

@gulliver and matthey

Agree with both of you. Slightly more on the idea of not restricting ourselves to 512Kb ROMS. We learned that Workbench library can be (almost) safely swapped out. I guess other pieces could eventually follow that path, be proxied or, yes, we could copy a page from AROS book and have a modular component list, but this in a distant future. I'd like to stick with what makes Amiga an Amiga, without premature NGfication as I think is also the case for both of you

[gulliver]

I gave a thought to the kickstart backwards compatibility dilema, and I found a very good solution:

It is as simple as reusing the same old and buggy v40 rom we all know and love&hate. It is despite its shortcomings, a highly compatible rom. My idea is to insert in its build a modified form of the kickmenu module (which was present in those A3000 36.16 roms).

The module provided a way to either boot from itself or to load and soft kick from a file in devs:
I would only modify three things from it:
1. Build the softkick procedure so that it doesnt require a MMU.
2. Change the volume labels of the softkick targets from 1.3 and 2.x to 3.1 and 3.x (Assuming 3.x is this new release)
3. Change the behaviour, so that if the module doesnt find the corresponding kickfile in those volumes, it just continues booting its own rom contents (which is an unmodified v40 rom).

This small change will allow backwards compatibility and an option to softkick a new or wip rom without issues, and out of the box.

The kickmenu module occupies less than 8KB and its sourcecode is provided in the leak, along with sourcecode of well know
CBM softkickers. So it is just a matter of glueing it all together.

[idrougge]

Originally Posted by wawa

i guess os3.9 might need about the same. os4 needs more than 70mb to boot. dunno about morphos. at least aros has already pretty low requirements in this comparison, doesnt it?

You're guessing wrong. OS 3.9 in ROM eats up 67 kB of chip RAM and 172 kB of fast RAM when booting without startup-sequence. That's still a lot, but astronomically smaller than 1,5 MB.

And no-one has proposed to port OS4 to 68k, so I'll just ignore that.

[Kalamatee]

Originally Posted by michaelz

Time to get back to topic. Critical components to open source, not another topic posted full with "aros is open source and that should be good for everyone". It's not the same sentiment and should be in it's personal thread.

Not to try and derail this thread - but no one was saying "AROS is open source and should be good for everyone". the thread is about open sourcing components and which should be necessary - AROS already has open sourced versions of said components so it is obvious (unless you are trying to live in a cave, or trying to prevent it being mentioned) that it is going to crop up.

Clearly there isn't real interest in open sourcing anything since the people on here wouldn't use it (for the same reasons they claim to oppose AROS or try to shut down any mention of it in threads).