Aros68k viability on real Amiga hardware

[wawa]

Originally Posted by E-Penguin

I was wondering about trying this on my a1200(b1230 iv @50 128MB), but can't find where to start. The AROS website points me to AfA, which seems both ancient and not full AROS. Can anyone please point me in the right direction?

http://aros.sourceforge.net/de/nightly1.php

to softkick on real hardware add this at the beginning of your s-s:

boot/amiga/AROSBootstrap ROM boot/amiga/aros.hunk.gz
SetPatch QUIET

use amiga or linux editor. eventually notepad++ but not generic windows one, because of carriage return format.

delete theme.var from prefs/env/sys to disable themeing if you are on a planar screens. if you have a rtg card append p96 driver files after arosbootstrap.

set windows and screen backgrounds to colors instead of images in wanderer prefs. (second tab)

[wawa]

Originally Posted by grelbfarlk

What about a comparison between a heavy 3.1, 3.9 (ClassicWB would be fine) and AROS build on a low end 060(like A3640)+RTG with a low end RTG card like a Picasso 2/Spectrum/Piccolo?

i am currently running aros on an 4000/3640/16mb with no rtg. eventually p4 or cv64. but im bit tired doing all these comparisons, people could do themselves. they dont trust me anyway.

[Kalamatee]

Originally Posted by nobody

AROS looks too modern for a 020 processor.

Not really. The code just hasn't been that optimized (if at all) for m68k. It also has features suited for more powerful hardware enabled by default since x86, etc, are where it is mostly used/tested - but nothing stops users (or maintainers of distro's) disabling anything that is too demanding.

It would be nice to see some things better optimized for classic hardware, etc though (since it should also have a knock on effect on more powerful hardware..)

There is certainly plenty of scope for improvement in a lot of areas but that takes feedback and interested parties to resolve

But, I will be honest - it wont magically mean you can run anything that runs on AROS. Some things are just too memory intensive for plain m68k systems, so would need something like WinUAE or Vampire to really use.

The current debug build of odyssey for x86_64 needs 1GB to even run! (yeah I almost cried), and Doom3 uses pretty massive amounts of memory also (not to mention the processor/gfx hardware requirements).

[Kalamatee]

Originally Posted by grond

This supports the impression that AROS's biggest problem is the graphics subsystem whenever there is no accelerated driver. Memory footprint looks okay to me (your mileage may vary).

It is and isn't - the main problem is people can be lazy writing code so the gfx subsystem/drivers (and tbh, most other drivers/subsystems based on oop) don't utilise oop.library to its fullest, so it loses a lot of time on overhead of method calls. We are currently discussing it on the AROS mailing list, so hopefully something will be done to improve the behaviour.

There is also a bit of work needing done to improve general planar display handling, but nothing that cant be achieved with a little work.

It is also worth noting, Zune doesn't exactly use the most efficient rendering code and could certainly be made to do some basic gfx operations much faster.

Perhaps you could try running both in a WinUAE P96 setup and see how they compare then?

[Kalamatee]

Originally Posted by gulliver

OBJECTIVE:
Determine wether Aros68k is a viable alternative in its current form on Amiga hardware.

METHODOLOGY:
A comparison between AmigaOS 3.1, AmigaOS 3.9 and Aros68k will be held. Tests will be conducted Under WinUAE for the sake of simplicity. The chosen tests will be boot speed and memory footprint.

After the first set of tests is conducted, another will be held with all OSes trimmed down to the lowest common denominator to provide a leveled plainfield (labeled as “Comparable” in the results section). In this way we can fairly compare OSes that do much more things at boot time and consume much more memory due to the fact they are running extra programs and providing other features. So AmigaOS 3.1 is chosen as the lowest common denominator, and this means I will adjust both Aros and AmigaOS 3.9 to the following settings:
Only PIPE as DOSdriver
No WBStartup programs
ENV-Archive/sys will be empty
Only 8SVX, ANIM, AmigaGuide, FTXT, CDXL and ILBM datatypes.
Arexx will not be started by default
No Wallpapers
Only 2 visible icons in the desktop in 4 colours.
No decoration


TERMS:

The operating systems will be used in the following form:

AmigaOS 3.1 v40.42 + kickstart v40.68

AmigaOS 3.9 with BoingBags 1 and 2 applied with no other extras + kickstart v40.68 (softkicking AmigaOS Rom Update)

Aros 68k ABI 1 Nightly (17th may 2017) no contribs + aros kickstart with its extended rom (will not boot from its emergency floppy, but directly from its own roms)

WinUAE will be set in the following configuration:

Amiga 1200 with 4MB of fastmem, in the most cycle exact emulation settings possible.

Tests will be conducted following these procedures:

“Boot time” is the time it takes the operating system from cold boot to show the full desktop in a complete manner.
“Memory usage” is obtained from the avail command being issued from the Execute menu item of Workbench. The “in use” category will be taken into account.

RESULTS:




Results have been rounded, and are averages after different runs.

ADDITIONAL OBSERVATIONS:

Aros is unbearably slow after it has booted in this 14mhz 68020 Amiga config. It is nearly impossible to be able to access the Workbench menu, as it takes ages to draw it, timing out the mouse selection operation. You can literally see the cascading window being drawn.

Removing Aros “decoration” improves the situation considerably, but it is still noticeably slow.

During tests, Aros crashed out of the blue, and produced screen refreshing issues several times when performing ordinary workbench tasks. Seems to be quite unstable and prone to crashes. Whilst all other Oses had no issues performing the same mundane tasks.

On Aros Workbench windows are as slow as a snail.It doesnt matter if you ramp up the available cpu power a bit. Opening a window and closing it, seems an eternal wait.

Quite interesting results and comments. It would be also interesting, however, to know what is actually "loaded" and available once the system has booted, since obviously if there is more going on then the memory footprint, etc is going to be bigger =)

I assume by the boingbag having no extras - it isn't using p96/cgfx at all, or loading drivers etc for them? I'm quite interested to know "exactly" what differs between the final loaded systems, and if there are specific benchmarks/tests that can give good feedback about areas that need work.

[grelbfarlk]

Originally Posted by wawa

i am currently running aros on an 4000/3640/16mb with no rtg. eventually p4 or cv64. but im bit tired doing all these comparisons, people could do themselves. they dont trust me anyway.

Well what about just Sysspeed and AIBB modules on your A4000/040 on AROS, that would be a good starting point. Writepixel test on AIBB and P96 benches, stuff like the memory tests and MIPS shouldn't really be different, or should they?

I'm guessing all the various hacks like FBlit, FText, CGX-AGA, BlazeWCP, etc that really pep up an AGA system aren't really recreated on AROS yet.

[Kalamatee]

Originally Posted by grelbfarlk

Well what about just Sysspeed and AIBB modules on your A4000/040 on AROS, that would be a good starting point. Writepixel test on AIBB and P96 benches, stuff like the memory tests and MIPS shouldn't really be different, or should they?

That's assuming gfx are the only issue ;D

I'm guessing all the various hacks like FBlit, FText, CGX-AGA, BlazeWCP, etc that really pep up an AGA system aren't really recreated on AROS yet.

Well, some probably don't make much sense in relation to AROS's code, but yes, there aren't really any AROS specific things like that (if those particular items would work on AROS, is another question I wouldn't know the answer to )

[grelbfarlk]

Originally Posted by Kalamatee

That's assuming gfx are the only issue ;D



Well, some probably don't make much sense in relation to AROS's code, but yes, there aren't really any AROS specific things like that (if those particular items would work on AROS, is another question I wouldn't know the answer to )

Right, obvious answer since that is oft complained that GFX subsystem is unoptimized. How about this, anyone that has AROS in WinUAE, can you try dropping powerpc.library on it and seeing if the PPC emulation works at all?

Reading some reports that Mediator might sort of work has me downloading AROS-Vision and a nightly build, I'll try some of this stuff myself, and I'm sure my feedback will be less relevant than Wawa's.

[wawa]

Originally Posted by grelbfarlk

Well what about just Sysspeed and AIBB.

okay, i dont have patience to do that on my a4k tonight but here goes aibb in the very same config of winuae:

test aos aros
emu 1058.58 805.13
elipse 9.45 7.65
line 3.24 3.35
inst 937.58 728.0
writepxl 238.35 118.52
matrix 2137.73 1668.47
savage 1030.75 793.22
flops 1138.94 967.06
sieve 1327.45 925.08
imath 1854.42 1446.62
fmath 938.00 720.47
trantest 1046.49 788.08
dhryst 1692.55 981.51
mem 3281.40 2851.95
fmatrix 1762.48 1339.76
ftrance 1094.89 808.09
sort 1366.71 1061.72
tgtess 2.91 3.34
beachball 1336.26 686.11
cplxtest 790.94 592.00

both with jit unfortunatelly, couldnt bother to turn it off.

now could you people do tests you want yourself, instead to make someone else do them?

[Kalamatee]

Originally Posted by wawa

okay, i dont have patience to do that on my a4k tonight but here goes aibb in the very same config of winuae:

test aos aros
emu 1058.58 805.13
elipse 9.45 7.65
line 3.24 3.35
inst 937.58 728.0
writepxl 238.35 118.52
matrix 2137.73 1668.47
savage 1030.75 793.22
flops 1138.94 967.06
sieve 1327.45 925.08
imath 1854.42 1446.62
fmath 938.00 720.47
trantest 1046.49 788.08
dhryst 1692.55 981.51
mem 3281.40 2851.95
fmatrix 1762.48 1339.76
ftrance 1094.89 808.09
sort 1366.71 1061.72
tgtess 2.91 3.34
beachball 1336.26 686.11
cplxtest 790.94 592.00

both with jit unfortunatelly, couldnt bother to turn it off.

now could you people do tests you want yourself, instead to make someone else do them?

No offense wawa but that attitude doesn't really encourage people ;p

If you don't want to do some test, don't do it - and just say you don't want to/don't have time, no need to have attitude about it.

[wawa]

No offense wawa but that attitude doesn't really encourage people ;p

sorry. im probably just tired tonight, just tried to get sysspeed to run on aros, but couldnt. snoopdos doesnt reveal whats wrong. maybe tomorrow.

[OlafSch]

@gulliver

how do you set something cycle exact emulating 68020? As far as I know this is simply not possible, exact is only 68000er emu on WinUAE as far as I know. Crashes and not running stable? When and in which environment? On WinUAE RTG on Aros is just a wrapper to P96 that is not optimized, when running on fast hardware optimizations are not that urgent. From my personal tests it looks like Aros is slower with less colours, I use 24bit or 32bit depth RTG but of course running it on AGA with say 32 colours certainly makes a big difference.

[OlafSch]

@Kalamatee

I can remember one patch that works for me in Aros Vision but general most patches are low-level stuff and thus certainly do not work in Aros. Virus work though :-), it is the question if that is a bug or feature

[OlafSch]

Originally Posted by Kalamatee

It is and isn't - the main problem is people can be lazy writing code so the gfx subsystem/drivers (and tbh, most other drivers/subsystems based on oop) don't utilise oop.library to its fullest, so it loses a lot of time on overhead of method calls. We are currently discussing it on the AROS mailing list, so hopefully something will be done to improve the behaviour.

There is also a bit of work needing done to improve general planar display handling, but nothing that cant be achieved with a little work.

It is also worth noting, Zune doesn't exactly use the most efficient rendering code and could certainly be made to do some basic gfx operations much faster.

thank you very much for supporting Aros 68k even though not being your main interest (the same to the other devs and Toni)

[Retro1234]

I should test myself I know
But when you use the aros rom and then load a OS friendly app, office app etc or Workbench its still slow isnt it ?

[OlafSch]

Originally Posted by Retro1234

I should test myself I know
But when you use the aros rom and then load a OS friendly app, office app etc or Workbench its still slow isnt it ?

on plain AGA with few colours it is visible slower even when testing it in UAE. It needs RTG and 24bit colour depth (at least from my experience).

[grelbfarlk]

How about a little AROS-68k install thread for noobs like me? I could just post my poorly researched questions in this thread if nobody minds. I grabbed the large AROS-Vision image, 1.1GB, dropped it in UAE, changed the softkick line so it wouldn't error out and it booted then Arexx crashed.

And it seems to be freezing up if I change the Screenmode and then WinUAE crashed.

Is there an up-to-date quick install guide somewhere? Ultimately I would like to try it on an A4000 with Mediator.

[wawa]

Originally Posted by grelbfarlk

How about a little AROS-68k install thread for noobs like me

isnt it this thread? and my instruction up the page in post #21?

I could just post my poorly researched questions in this thread if nobody minds. I grabbed the large AROS-Vision image, 1.1GB, dropped it in UAE, changed the softkick line so it wouldn't error out and it booted then Arexx crashed.

very likely. rexx is buggy on aros. i wouldnt say this is a priority, but out of general interest, what have you done?

And it seems to be freezing up if I change the Screenmode and then WinUAE crashed.

that might have been the case once. maybe olafs distro isnt ip to date. but i have not had such a problem since long.im only testing with the nightlies and own compiles though.

Is there an up-to-date quick install guide somewhere?

again, its up this very page.

Ultimately I would like to try it on an A4000 with Mediator.

its too early for this. it wont work with pci devices as pci bridge drivers are not ready. i think they would have to be emulable under uae for toni to care.

an a4000 with zoro expansions will work though.

[AMIGASYSTEM]

Originally Posted by grelbfarlk

H
Is there an up-to-date quick install guide somewhere? Ultimately I would like to try it on an A4000 with Mediator.

If it may be interesting here is a boot on WinUAE of AROS 68k Nightly Build

[ Show youtube player ]

[grelbfarlk]

Originally Posted by wawa

isnt it this thread? and my instruction up the page in post #21?


very likely. rexx is buggy on aros. i wouldnt say this is a priority, but out of general interest, what have you done?


that might have been the case once. maybe olafs distro isnt ip to date. but i have not had such a problem since long.im only testing with the nightlies and own compiles though.


again, its up this very page.




its too early for this. it wont work with pci devices as pci bridge drivers are not ready. i think they would have to be emulable under uae for toni to care.

an a4000 with zoro expansions will work though.

I switched to the nightly build and sort of got a little further. I did see something like Mediator-Hid.library in the archive so I just guessed maybe it somewhat worked.

So the boot floppy loads and I see the AROS DOS screen then it tries to switch screenmodes which fails unless I close the AROS DOS screen, but it doesn't change modes.

Wanderer opens up in a 640x200 screen, I opened Screenmode and selected a 640x400 or 640x512 mode and then it complains to close all windows that weren't opened by Wanderer(This terrible thing from AmigaDOS is still here), which is the Prefs window, I close that then Wanderer crashes when the screen changes. I tried saving the screenmode prefs but that doesn't seem to stick on next reboot.

Got the install completed, now it seems to be working with AGA graphics, how do I add a PIV drivers?

Does AROS support P96 drivers? Where do I drop them? Is there an equivalent to P96Mode where I have to bind screenmodes to the boards?