Overview Features Instructions Performance Forum Downloads Products Reseller Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
VISIT APOLLO IRC CHANNEL



All TopicsNewsPerformanceGamesApolloVampireReleases
The team will post updates and news here

AROS 68k for 68080page  1 2 3 4 5 6 

Wawa T

Posts 434
10 May 2017 22:29


id rather prefer to cooperate on it and to agree on some basics first, style, number of colors, resolution and the like.

my idea was among others to provide an icon set almost without the horizontal lines to reduce flicker on interlace. 4-8 colors, default palette, two state iff .info format, around 48x48px in size.


Michael R

Posts 247
11 May 2017 20:20


wawa t wrote:

  id rather prefer to cooperate on it and to agree on some basics first, style, number of colors, resolution and the like.
 
  my idea was among others to provide an icon set almost without the horizontal lines to reduce flicker on interlace. 4-8 colors, default palette, two state iff .info format, around 48x48px in size.
 

 
  Certainly. AROS 68k could benefit from good looking icons.
 
  From your description it seems that IFF ILBM 5bitplane icons should work well. GlowIcons are in this category, although the NewIcons specification I believe supports up to 8bitplanes (256 colors).
 
  Many GlowIcons in Amiga OS 68k are 5bitplanes (32 colors) but as you can see in the sample from my IFF Icon Editor only the first 9 colors are actually used, which includes the first color slot for the grey background and 8 additional colors. The rest of the colors are merely "filler" colors because we are using a 32-color palette.
 
So it seems that GlowIcon format IFF ILBM icons would work fine. I'll post some sample icons to test with AROS 68k.
 
 
  EXTERNAL LINK 
 
 


Wawa T

Posts 434
11 May 2017 21:49


i dont think aros will have a problem to depict any of these icons, be it 1-8 bitplane icons nor high or true color ones.


Simo Koivukoski
(Apollo Team Member)
Posts 263
23 Jun 2017 21:36


A quick Origyn Web Browser (OWB) test:
 
EXTERNAL LINK 
 



Vojin Vidanovic

Posts 655
23 Jun 2017 23:59


It looks nice and I hope it will be faster with AROS optimizations, core updates etc. We have both modern OS and usable browser (in HTML5 standards)

Thanks Power2People!
EXTERNAL LINK 
p.S.
There are two open AROS x86 bounties, CUPS and Wanderer Enahancement.
If succedeed, and back ported to m67k AROS, it would bring much joy in OS GUI and printing. Maybe we could open some that we needed?

Bring CUPS to AROS
EXTERNAL LINK 
Enhance Wanderer to WB level
EXTERNAL LINK


John William

Posts 218
24 Jun 2017 01:27


Simo Koivukoski wrote:

A quick Origyn Web Browser (OWB) test:
   
  EXTERNAL LINK   
 
 

There are two things that will need to be met that makes me migrate to AROS 68k permanently they are as follows:

A) All WHDLOAD games or 98% of them run 100% in AROS no problem in additional to any RTG games that is 68k Amiga will run 100% to AROS and all other 68k apps like paint, amiblitz, amos, and word processor apps.

B) AROS 68k will need to be reworked under the hood and have AMMX technology implemented for optimal performance and use the new hyper threading for optimal performance and to be coded again into assembly with optimization so that it have performance matching bar with Workbench 68k.

Otherwise, forget it.


David Wright

Posts 198
24 Jun 2017 01:30


I'll get right on it.


John William

Posts 218
24 Jun 2017 01:32


David Wright wrote:

I'll get right on it.

Thanks ;)



Kalamatee (AROS)

Posts 15
24 Jun 2017 01:54


John William wrote:

Simo Koivukoski wrote:

  A quick Origyn Web Browser (OWB) test:
   
  EXTERNAL LINK   
   
 
 

 
 
  There are two things that will need to be met that makes me migrate to AROS 68k permanently they are as follows:
 
  A) All WHDLOAD games or 98% of them run 100% in AROS no problem in additional to any RTG games that is 68k Amiga will run 100% to AROS and all other 68k apps like paint, amiblitz, amos, and word processor apps.

I have never looked into how whdload is implemented or tried it under AROS, but most of the games should be patched using it I assume, to use OS functions where appropriate (e.g. for disk access) - and therefore should work so long as the hardware features they still use are available...


  B) AROS 68k will need to be reworked under the hood and have AMMX technology implemented for optimal performance

That doesn't need reworked under the hood. It means suitable "optimized" versions of functions need implemented.


  and use the new hyper threading for optimal performance

The normal m68k build is unlikely to have this.
While its easy to bring up another "processor" (which from the p.o.v of the operating system, hyper threading is exposed as) and run code on it, there are provisions needed to allow sharing data between tasks on the different "cores" - particularly locking access to such data. On platforms where such smp is allowed, both the non smp and smp code is compiled so that some structures have space for this locking - that allows the binaries to be used on both smp/non smp builds in most cases, however this just isn't possible for m68k without breaking compatibility completely with amigaos binaries using these structures.


  and to be coded again into assembly with optimization so that it have performance matching bar with Workbench 68k.

If you mean "all of AROS" (which isn't just the roms, or some modules in the roms) then that is not going to happen. AROS is written so that the bare minimum ASM is used as is possible, and it is only necessary in very specific cases


  Otherwise, forget it.

you should probably forget it then, since most of what you have asked is unrealistic (at best).



Kalamatee (AROS)

Posts 15
24 Jun 2017 02:06


Kalamatee (AROS) wrote:

 

  and use the new hyper threading for optimal performance
 

 
  The normal m68k build is unlikely to have this.
  While its easy to bring up another "processor" (which from the p.o.v of the operating system, hyper threading is exposed as) and run code on it, there are provisions needed to allow sharing data between tasks on the different "cores" - particularly locking access to such data. On platforms where such smp is allowed, both the non smp and smp code is compiled so that some structures have space for this locking - that allows the binaries to be used on both smp/non smp builds in most cases, however this just isn't possible for m68k without breaking compatibility completely with amigaos binaries using these structures.

To clarify this better - the "normal" m68k build wouldn't be able to support it out of the box except via specific code that uses it as some kind of support processor - much like how PPC is used on existing m68k hardware.

Also, an "smp" AROS build for Apollo-m68k, would have the same problem running normal amigaos binaries since some offsets in structures will be wrong.


Gunnar von Boehn
(Apollo Team Member)
Posts 2957
24 Jun 2017 04:58


What AROS really needs is an optimized SAGA-RTG driver.
With this AROS GUI will much faster and really be useable.

We should not today demand SMP!
SMP is complex today for AMIGA OS.
But AMP can relative easily be done.
The HW threads can be used with AMP to provide "acceleration" for dedicated drivers. This means with using AMP we can relative easily get something like a free Network driver, or free filesystem de/compression.

Looking at SMP.
Doing SMP did traditionally had some challenges on AMIGA.

Interestingly we fixed a number of them already.

a) Problem TAS/CAS/CAS2
The 68k provides hardware instruction for SMP syncronisation.
Those SMP instruction did use read-and-modify busy cycles which
could collide with the old AMIGA chipmem bus cycles.
This problem is fixed!
Apollo in combination with SAGA has solved this collisions.
These instructions can now be used as expected!

b) Problem MUTEX
On AMIGA applications have several ways to guarantee that a certain operation is ATOMIC. One example is simply poking chipset to disable IRQ for a code block execution to guarantee that the OS-schedular will called for this period.
APOLLO and SAGA being in one SOC can now provide compatibility to this behavior also over more than one core.
This means SAGA offer snooping of this and can "hold" all cores when MUTEX code is protected like this.

c) Cache coherence and Selfmodify code
APOLLO Caches are by design coherent.
This is done fully in Hardware and not Operating systems calles are needed for this. Also compatibility and support for selfmodifying code is guaranteed by the hardware.

While SMP in AMIGA is never easy to do.
APOLLO 68080 is currently the hardware having the best designed abilities for this.

APOLLO 68080 is also MUCH better designed for this than all PowerPC cores.




Szyk Cech

Posts 150
24 Jun 2017 09:48


Gunnar von Boehn wrote:

  APOLLO 68080 is also MUCH better designed for this than all PowerPC cores.

Do you mean 68080 is better by its instruction set or internal architecture? Or maybe both? If 68080 has better internal architecture - then - how can you tell that? Do you have access to PowerPC sources?!?


Gunnar von Boehn
(Apollo Team Member)
Posts 2957
24 Jun 2017 10:24


Szyk Cech wrote:

how can you tell that? Do you have access to PowerPC sources?!?

Yes of course I do.
How else could I develop POWER Cores for IBM without access to the source?


Wawa T

Posts 434
24 Jun 2017 11:04


Gunnar von Boehn wrote:
This means SAGA offer snooping of this and can "hold" all cores when MUTEX code is protected like this.
 

 
  yes. thats the easy way to solve it and has been discussed before even introducing smp, but this way you lose most of the advantage of smp, because in case like that all cores need to be halted, not just one.



Wawa T

Posts 434
24 Jun 2017 11:09


John William wrote:

  Otherwise, forget it.

thats usual talk by people who do not realize that aros on amiga offers other opportunities than just playing games in wdhload. which afair you already can, using olafs vision distro.

one of such opportunities are more up to date browsers like the one simo has tested, even though its by no means an html5 browser as vojin assumes, since its build around 9 year old version of webkit engine.


Cyber Gorf
(Needs Verification)
Posts 39/ 1
24 Jun 2017 11:24


Gunnar von Boehn wrote:

  We should not today demand SMP!
  SMP is complex today for AMIGA OS.
  But AMP can relative easily be done.

I prefer AMP over SMP any time.

One CPU to rule them all, One CPU to find them,
One CPU to bring them all and in the system bind them


Gunnar von Boehn
(Apollo Team Member)
Posts 2957
24 Jun 2017 12:58


wawa t wrote:

 
Gunnar von Boehn wrote:
This means SAGA offer snooping of this and can "hold" all cores when MUTEX code is protected like this.
 

  yes. thats the easy way to solve it and has been discussed before even introducing smp, but this way you lose most of the advantage of smp, because in case like that all cores need to be halted, not just one.
 

 
How much code is executed inside such MUTEX Locks?
How many clocks are covered by this in average?
 
Is this in total less than 1 PERCENT in average?
Or this this in average less than 0.1 PERCENT?
 
So when you say this will loose a lot?
What fraction of a percent is this?


Wawa T

Posts 434
24 Jun 2017 13:37


maybe i was wrong to say. "most" advantage, while is should have said "some". however i was anly a witness to these discussions, while kalamatee is one of the autors of aros smp, so better to wait what he says.


Vojin Vidanovic

Posts 655
24 Jun 2017 14:43


"one of such opportunities are more up to date browsers like the one simo has tested, even though its by no means an html5 browser as vojin assumes, since its build around 9 year old version of webkit engine"
 
  OK, I ve used that older OWB too. Its way ahead Ibrowse, but also yes, newer webkit OWB/Odyssey supports much more HTML5.
 
  So, 1.23 version we have bountied for was ported to AOS4 and AROS x64 but not m68k AROS? I suppose AROS backporting is likely?

"What AROS really needs is an optimized SAGA-RTG driver."

In plan? Bounty?


Thierry Atheist

Posts 575
24 Jun 2017 16:11


Gunnar von Boehn wrote:
The HW threads can be used with AMP to provide "acceleration" for dedicated drivers. This means with using AMP we can relative easily get something like a free Network driver, or free filesystem de/compression.

Hi Gunnar,

Do you mean, as an example, when loading a JPEG, PNG or PDF file, it can be decompressed in the AMP hyperthread portion of the 68080 CPU for much faster display onto the screen?

BASICALLY, a "68080 co-processor" is (born?) available for AOS to use, minus the custom chipset segment?

Will it have it's own AMMX and/or FPU as well??

posts 102page  1 2 3 4 5 6