Login
Username:

Password:

Remember me



Lost Password?

Register now!
Main Menu
Who's Online
1 user(s) are online (1 user(s) are browsing Forum)

Members: 0
Guests: 1

more...

Browsing this Thread:   1 Anonymous Users



(1) 2 3 »


Apollo core and AROS 68k

Joined:
2016/7/17 0:02
From Switzerland
Group:
Member
Posts: 3
Offline
Dear AROS team,

As you might know, since beginning of the Apollo/Vampire story, we made several attempts to run AROS 68k as we are looking for a free opensource alternative to the dead closed-source AmigaOS3.

At that time, there was still some work need to get it working at acceptable speed.

Today, we would like to accelerate this move and hopefully get AROS 68k running in the future as main OS for next Apollo/Vampire projects.

To enable this, we want to offer today needed Apollo/Vampire hardware to motivated developers.

If any is interested, just get in touch with me or any of the other Apollo team members.

Looking forward

Attach file:


pdf Apollo_datasheet.pdf Size: 711.26 KB; Hits: 135

Posted on: 2016/7/17 0:31

Edited by TuKo on 2016/7/24 3:43:07
Transfer the post to other applications Transfer


Re: Apollo core and AROS 68k

Joined:
2008/1/7 12:41
From Poland
Group:
Dev
Posts: 2923
Offline
Hello,

Thank you for this interesting offer. What would help, at least me personally, is to know what are short term and long term needs to AROS to support Vampire, in other words, what would be the target for the developments. The more details you can put the better, especially for people like me who have limited knowledge of 68k.

Posted on: 2016/7/17 2:55
_________________
Krzysztof

"There is no such thing as software for free. If it is not the user who covers the cost of software creation with money, it is the developer who covers this cost with his own free time."

www.aros3d.org
www.twitter.com/ddeadwood
Transfer the post to other applications Transfer


Re: Apollo core and AROS 68k

Joined:
2010/8/30 7:20
Group:
Member
Posts: 830
Offline
there were major grapical glitches on rtg last time we have tried it with the apollo team. this has been resolved by georg. what most urgently remains to be done in graphical department is the problem when using picasso/uae wrapper new opened screen doesnt fit into the video card memory we have a distroted picture (no crash). obviously the screen is being displayed so far it is possible but the rest is rubbish. perhaps offloading the content of background screens from vram to main memory needs to be fixed. have notified toni about it, but since i cant test with real hardware while in poland, nothing has been done so far. besides toni doesnt seem too motivated with aros as present. there is another compatibility issue (internal structs i guess) we have been looking into due to glitch in usage of hd-rec.

now. what concerns vampire, i dont think it needs much of particular adjustments. to have aros usable on 68k there are general speed/compatibility/stability/issues.


most pressing is speed. stability is not that bad, errors are usually well reproducible. for working with trusted heavy tools like hollywood or hd-rec aros68k is stable enough for hours, at lest under uae.

another thing is chipset compatibility in rom. whole parts of functionality are still missing to correctly display floppy based games afair, toni would be the one to ask about details. but i suppose, this is the lesser priority.

ill return to this thread, when i have more details to share.

edit: äh, since as i mentioned the main issue gunnar and co have mit speed i have tried to compile aros for something higher than plain 68000. but there are some hardcoded asm that prevents it. apollo could take advantage of compiling for 040, perhaps even their own extensions.

the problem is currently the optimisations for above 68000 are carried out by setpatch. i dont know how much it is and which functions there are, but one would probably have to find a method to compile for higher targets and use setpatch on such binaries without messing things up.

Posted on: 2016/7/17 3:36
Transfer the post to other applications Transfer


Re: Apollo core and AROS 68k

Joined:
2016/7/17 0:02
From Switzerland
Group:
Member
Posts: 3
Offline
Dear deadwood, dear wawa,

First, thanks to both for the fast answers.

We had some experiences with AROS on Apollo core :
GOOD : It boots, we can even go up to Workbench
BAD : It's slow, very slow, even with our very fast core in Early-Startup menu and with RTG

So, yes, it wasn't about stability but more about speed.

We would be happy to provide to any volunteer a Vampire card for their A500/600/2000.

Posted on: 2016/7/17 3:51
Transfer the post to other applications Transfer


Re: Apollo core and AROS 68k

Joined:
2008/1/7 12:41
From Poland
Group:
Dev
Posts: 2923
Offline
@All,

I had a chat with TuKo on IRC and as far as I can understand, these are two immediate needs

- Make AROS work with A600 disk controller (compatibility)
- Improve speed of RTG (speed)


Posted on: 2016/7/17 3:58
_________________
Krzysztof

"There is no such thing as software for free. If it is not the user who covers the cost of software creation with money, it is the developer who covers this cost with his own free time."

www.aros3d.org
www.twitter.com/ddeadwood
Transfer the post to other applications Transfer


Re: Apollo core and AROS 68k

Joined:
2010/8/30 7:20
Group:
Member
Posts: 830
Offline
yes, i think few devices like sd card need a rom driver module to be available at boot.

yes i think graphics should be reviewed for optimizations, but also other parts. for instance listing dirs in wanderer seems to be inefficient, wanderer loads whole icons i guess instead just poking them for information it needs, for instance in list mode it doesnt need imagery. thats as far as i remember.

@tuko: what worekbench you have booted to? wanderer? workbook doesnt give a proper impression. have you tried scalos?
try to include:
PetPatch
at the beginning of your startup-sequence
note if and what patches it loads. im not sure if it will recognize apollo core as 040.
when you confirmed that patches are being load you can add QUIET flag to that:
SetPatch QUIET to supress the output.

Posted on: 2016/7/17 5:01
Transfer the post to other applications Transfer


Re: Apollo core and AROS 68k

Joined:
2005/1/20 10:24
From Germany - Sulz am Neckar
Group:
Member
Posts: 81
Offline
Apollo will run 68000 code faster than any other 68K CPU.
I think there is no need to compile AROS for 68040 or so, AROS should fly on Apollo.

It looks to me more like there is some problem with AROS RTG on Picasso96..
AROS RTG looks slow.. a bit like running Windows in PC-Task ..

If this RTG/Picasso96 issue is "fixed" I assume AROS will feel many times faster.

not sure what the best approach here is...
Maybe doing a native AROS driver for SAGA would be the solution, maybe changing something in how AROS works over Picasso96 drivers.

An AROS developer would need to answer this.

Posted on: 2016/7/17 5:47
Transfer the post to other applications Transfer


Re: Apollo core and AROS 68k

Joined:
2010/8/30 7:20
Group:
Member
Posts: 830
Offline
Quote:
An AROS developer would need to answer this.

none knows aro68k and its issues better than jason. has he vanished again?

then ask toni. he is the other half of aros68k team.

Posted on: 2016/7/17 6:05
Transfer the post to other applications Transfer


Re: Apollo core and AROS 68k

Joined:
2004/4/3 13:20
Group:
Member
Posts: 345
Offline
Quote:

wawa wrote:

what most urgently remains to be done in graphical department is the problem when using picasso/uae wrapper new opened screen doesnt fit into the video card memory we have a distroted picture (no crash). obviously the screen is being displayed so far it is possible but the rest is rubbish. perhaps offloading the content of background screens from vram to main memory needs to be fixed.


I was about to look into this (before losing motivation again) and IIRC there's just a simple issue that screen bitmaps are locked (bm->locked variable) when visible (to prevent them from being swapped) but later never ever get unlocked even if some other screen bitmap has become the visible ones. So all screen bitmaps stay in VRAM forever. IIRC:

speed:

if there's some gfx functions which the driver does not handle itself, often the fallback functions will be slow or very slow. Even more so with RAM/VRAM swappable bitmaps because of the required bitmap locking. The fallback are not optimized and they never really can be super fast because the AROS gfx system is designed in such a way that it does not rely on having direct access to the gfx driver bitmap (or other bitmaps') pixel data. It could try to obtain direct access in fallback functions, but at the moment it mostly doesn't and so just uses indirect access to pixel data like through putpixel/getpixel or putimage/getimage.

One things which at the moment the uaegfx driver does not handle itself is blits where source bitmap pixfmt is different from dest pixfmt and at least one of the bitmap is in RAM instead of VRAM. For COPY drawmode/minterm at least it should be possible to handle/implement it using HIDD_BM_ConvertPixels (if both bitmaps are uaegfx bitmaps) or HIDD_BM_PutImage/GetImage (if one of the bitmaps is a foreign one). Speaking about drawmodes at least INVERT and CLEAR (bitmap allocated with BMF_CLEAR may trigger this) should be handled, too.

pixel fmt conversion routines: IIRC AROS 68k only has some of the improved ones (the stuff which used to be SYS:tests/patchrgbconv) built in (space constraints in ROM).

graphics.library/Text(): the code which puts the single font chars into the temp bitplane is very unoptimized. This template bitplane is what then gets rendered on screen using BltTemplate(). If someone wants to improve this, he can try to compile/optimize this (rom/graphics/text.c) on AmigaOS (maybe even AOS4 or MorphOS) with a little program which patches this into the system with SetFunction(). Doesn't rely on AROS internals, so no problem (disable antialiasing related stuff on AOS3). Then compare how much slower this is then original AOS function. Then optimize until it doesn't suck anymore ... then contribute back to AROS.

planar bitmaps: internally most AROS bitmaps are bitmap objects (boopsi like), but not all are. Handmade ones (like with InitBitMap()) are not and IIRC even planar bitmaps allocated with AllocBitMap() are not bitmap objects. So during gfx functions this are wrapped into bitmap objects on the fly, because the gfx system only works with this bitmap objects, but not "struct BitMap *" as known from graphics.library. One thing which I have noticed that is stupid/slow in this wrapping is that the planarbm class in SetbitMap() method always calls RegisterPixFmt to register pixfmt of wrapped planar bitmap. So during each and every gfx function with involved planar bitmap a pixfmt is re-registered. Should be changed to do so only if a matching pixfmt wasn't registered already earlier.

icons: loading of stuff like this (also fonts) is slow(er) in AROS, because AROS can be 32 bit, 64 bit, big endian, little endian and there is same code used for all possible variations. In AOS (or AOS4 or MOS) they have endianess fixed to "big endian" and the system is fixed to 32 bit. So they can basically read in this stuff as one chunk like it was one struct in memory. AROS m68k-amiga could have optimized loading, too (#if AROS_BIG_ENDIAN etc. do it like they do in AOS68k land), but doesn't at the moment.




Posted on: 2016/7/17 10:10
Transfer the post to other applications Transfer


Re: Apollo core and AROS 68k

Joined:
2008/1/7 12:41
From Poland
Group:
Dev
Posts: 2923
Offline
Quote:

Georg wrote:


I was about to look into this (before losing motivation again)





How to get it back?

Posted on: 2016/7/17 10:42
_________________
Krzysztof

"There is no such thing as software for free. If it is not the user who covers the cost of software creation with money, it is the developer who covers this cost with his own free time."

www.aros3d.org
www.twitter.com/ddeadwood
Transfer the post to other applications Transfer



(1) 2 3 »



You can view topic.
You cannot start a new topic.
You cannot reply to posts.
You cannot edit your posts.
You cannot delete your posts.
You cannot add new polls.
You cannot vote in polls.
You cannot attach files to posts.
You cannot post without approval.

[Advanced Search]


Search
Top Posters
1 paolone
paolone
4280
2 magorium
magorium
4095
3 phoenixkonsole
phoenixkonsole
3887
4 nikolaos
nikolaos
3670
5 deadwood
deadwood
2923
6 ncafferkey
ncafferkey
2572
7 mazze
mazze
2200
8 clusteruk
clusteruk
2055
9 Kalamatee
Kalamatee
2010
10 damocles
damocles
1789
© 2004-2017 AROS Exec