Welcome, Guest. Please login or register.

Author Topic: Aros 68k vs aos on legacy hardware  (Read 2810 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline wawrzon

Re: Aros 68k vs aos on legacy hardware
« on: December 15, 2012, 09:45:27 PM »
i wouldnt call 030 a satysfying option for aros68k currently. even with 060 the user experience is sluggish, but about usable.

the situation is such: 68k applications run in most cases with usual speed. what is slow may be user interaction due to zune (mui clone) not being optimized enough. such is also alas the performance of wanderer (workbench replacement) which is built upon zune and contains several bugs (especially listing files in detailed mode) and oddities, that make it not as usable.
also loading binaries is noticeably slower than on original aos. generally the system is still more crashy and not tested enough due to apparent general lack of interest alas.

there are several contributions to aros that already run under aros68k, mostly games and demos, and most noticeably the aros owb web browser. unfortunatelly the executable alone is about 40mb big and loads very slowly especially parsing ttf fonts (about 2 minutes if you dont feed it with too much fonts). it is usable on simple pages but complex css loaded sitest load pretty slowly.

you can use whatever zorro rtg card you can find p96 driver for i think. i used picasso4 and cybervision64. but you will have to add the appropriate *.card and *.chip drivers to bootstrap command in the startup-sequence to have them available. then simply choos the desired rtg resolution in screenmode prefs.

you can also use an network card to connect to the net. having a router the setting should be pretty straightforward. get the appropriate 68k device copied into your devs/networks and choose it under network prefs. your card should run under arostcp stack with default automatic settings. note that imho arostcp is slow in comparison to miamidx i have used under aros68k on my a4k previously.

to tell the truth, aros 68k may be a lot of fun testing and trying to contribute to development but is not yet a real alternative to an end user, except maybe on winuae. if you seriously want to give it a shot, i can guide you through and likely answer many questions. setting up a system is not complicated at all. its just downloading a nightly (or a distro) to a hd you should be able to boot from it as it is, whatever hardware you got. no messing with appropriate cpu libs, aros setpatch will take care of it for you.

you may also head to aros-exec.org for further assistance.
« Last Edit: December 15, 2012, 09:52:43 PM by wawrzon »
 

Offline wawrzon

Re: Aros 68k vs aos on legacy hardware
« Reply #1 on: December 15, 2012, 10:30:43 PM »
Quote
What prevents it from running on an 68000?
nothing afaik. except it would be awfully slow (to boot) and you will need some more ram. aros needs about 6meg to run i think..
 

Offline wawrzon

Re: Aros 68k vs aos on legacy hardware
« Reply #2 on: December 16, 2012, 12:33:16 AM »
Quote

can it run shapeshifter/fusion?

possibly. i have not tried that. what stops you?
 

Offline wawrzon

Re: Aros 68k vs aos on legacy hardware
« Reply #3 on: December 16, 2012, 11:50:33 AM »
@deadwood
there are several platform independent issues to fix i think.
- as mentioned by jason already in the past, the long boot
- slow loading of executables
- improving speed of wanderer, zune, fixing lister functionality (kalamatee not seen around for long, likely will never see his fixes)
- some sort of control of vram usage, monitoring and handling of out of memory situations.
- enforcer with segtracker functionality for better debug, toni claims to be to lazy for that boring task
...
what comes to my mind.
 

Offline wawrzon

Re: Aros 68k vs aos on legacy hardware
« Reply #4 on: December 16, 2012, 03:18:01 PM »
certainly 68000 and even 68020 doesnt make practically much sense, but theoretically aros should run on as wide choice of hardware as possible, including as low as there is. currently aros68k nightly is compiled for 68000 so fai i know. of course it means it is not the 68k higher end optimal, but i guess this is not the main issue with it anyway. i would try to aviod introducing incompatibilities and overly optimizing it for just one system choice. as long as expected speedup is under 200% it isnt currently worth bothering anyway.