Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
The team will post updates and news about our project here

The AMIGA Future Is NOW! NG-AMIGA-OS!page  1 2 3 4 

Olaf Schoenweiss

Posts 690
09 May 2017 13:53


I tested Aros nightly some time ago

with more colours (24bit) it was visible faster than with few colours. But that should be no problem on vampire that has true color


Wawa T

Posts 695
09 May 2017 13:58


Olaf Schoenweiss wrote:

  I tested Aros nightly some time ago
 
  with more colours (24bit) it was visible faster than with few colours. But that should be no problem on vampire that has true color
 

 
  aros is (or should be) speedwise in a range of usability on rtg.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
09 May 2017 14:57


wawa t wrote:

aros is (or should be) speedwise in a range of usability on rtg.

I think so too.
SAGA has very fast access truecolor modes.
AROS should be well useable.

And one could later add some tuning for PLANAR modes too.
Thats the beauty of AROS people could contribute!

Speaking about contribution.
If people like see important bounties for AROS 68k please speak up.
Maybe we find ways to help support those bounties.


Wawa T

Posts 695
09 May 2017 14:59


Mr Niding wrote:
How is the install process of AROS?

no installation necessary. simply copy the boot iso to your boot partition of an amiga drive.

to softkick aros from amiga kickstart on real hardware you will have to add something like this at the beginning of your s-s:

boot/amiga/AROSBootstrap ROM  boot/amiga/aros.elf

eventually you will want to add

SetPatch QUIET

(use an aros, amiga or linux editor, last case notepad++ for windows not to trash carriage returns.)

from there on you can delete env/sys/theme.var to get rid of themeing in advance. (otherwise you might think aros is completely irresponsive on planar. the first boot may take forever loading backgrounds. set backgrounds to colors instead of images in wanderer prefs.




Nixus Minimax

Posts 416
09 May 2017 15:03


Obetto Sannala wrote:

@Nixus Minimax
 
  Is a bounty required for this?

I think two bounties for an accelerated driver for the Vampire framebuffer and for custom chip Displays, respectively, could make a lot of sense. I'd recommend talking with more AROS people about how to define such bounties.



Wawa T

Posts 695
09 May 2017 15:06


Gunnar von Boehn wrote:

  Speaking about contribution.
  If people like see important bounties for AROS 68k please speak up.

deadwood brought some drafts of bounties some time ago. like overscan prefs, something like that. minor things, nothing essential, so could be postponed. the interest was limited at the time and he went inactive in the mean time..

what i consider priority for now, contributions welcome, but there is no bounty for:
- the ata driver problem, debug and enable aros booting on a4000 and a600 internal ide port, currently it gets stuck underway.
- improvements in gfx subsystem. particularly speedwise.
but i cannot offer an opinion, what exactly and how should be done.

i think maybe it was possible to keep planar imagery in a buffer and reuse it if possible, rather than converting everything to full depth on the fly, regardless screen resolution. but i cannot tell if and how could that be done properly leaving hardware abstraction intact.


Kalamatee (AROS)

Posts 15
09 May 2017 15:24


Gunnar von Boehn wrote:

wawa t wrote:

  aros is (or should be) speedwise in a range of usability on rtg.
 

 
  I think so too.
  SAGA has very fast access truecolor modes.
  AROS should be well useable.

So long as you provide suitable accelerated functions, and can cache things needed to improve performance in your code - there should be no issue.

 
  And one could later add some tuning for PLANAR modes too.
  Thats the beauty of AROS people could contribute!

That's is for sure the beauty of AROS ;)

I'm curious though, how much of the Appolo side can AROS currently use? Does it have direct access to the SD-Card or is that through emulation? Is there other hardware features it can be using that it doesn't take advantage of directly?


  Speaking about contribution.
  If people like see important bounties for AROS 68k please speak up.
  Maybe we find ways to help support those bounties.

Well the obvious thing is to identify and come up with "fixes" for perceived bottlenecks/performance issues in AROS.

And that doesn't mean just disabling things/reverting code - but looking at why it is actually an issue and what can be done to fix it properly so it is usable - like decorations performance on planar modes (and likely a lot of other AROS code).

Keep in mind though - AROS always aims at "enabling" rather than trying to force a specific way of doing things, so changes that don't reflect that are unlikely to get accepted.

Trying to get the base components AROS uses, changed based on personal preference isn't going to work - that is something left for users or distribution maintainers to do, but providing suitable configurations for lower end systems and having it used when building those platforms will.

And also, don't try to aim too high with the bounties or come up with too fanciful sounding things or they will end up not getting any interested developers/just stagnate.  If possible break them down into sub-bounties that can be easily worked on, possibly in parallel.


Kalamatee (AROS)

Posts 15
09 May 2017 15:29


Nixus Minimax wrote:

Olaf Schoenweiss wrote:
Regarding speed I think yes and no... It was tested on RTG and there it was very slow. [...] Another bottleneck might be graphics driver because the driver in Aros 68k was a relative unoptimized driver using the RTG system used in UAE (P96) so with a better driver directly using the framebuffer in Vampire it could be faster too.
 

 
  When AROS was booted on the Vampire for the first time, graphics were so slow that you could see each pixel appear one after the other even though the comparatively fast Vampire RTG was used. The current speed of AROS graphics operations on Amiga RGB is similar. Both effects seem to be caused by one and the same issue, the over-abstraction deep inside AROS where each pixel is an object and a line inherits from pixels and so on.

The driver abstraction is not so much the problem, but the oop subsystem itself is. The way methods/objects are handled is not particularly efficient - for starters theres no reason certain method pointers couldn't be cached in the driver code if it knows what it was doing, giving a more direct line of calling the necessary code (I don't believe there is any means to do this in practice with oop currently..)


If there is no cybergraphics driver with overrides for each graphics primitives, this ultra slow fallback solution gets used. The Vampire RTG driver currently only has stubs and does not offer any override functions and for this reason uses the Picasso96 CPU drawing functions on AmigaOS 3.1. The P96 drawing functions are quite okay and thus user experience in AmigaOS is generally good even without acceleration. A driver with accelerated functions is in the works. This driver would most probably also solve the central issue with graphics speed when running AROS on Vampire RTG. However, AROS would still use its abysmally slow built-in rendering functions for custom screens. Thus, I think apart from an accelerated Vampire RTG driver there is need for an accelerated driver for Amiga custom chip display modes. If this could be written, AROS may all of a sudden become quite usable even on classic accelerated 68k Amigas.
 




Wawa T

Posts 695
09 May 2017 15:53


welcome, kal;)


Olaf Schoenweiss

Posts 690
09 May 2017 16:33


good to see the best here :)


Tango One

Posts 102
09 May 2017 18:01


hope it will be upto the end user what OS we can install.


Olaf Schoenweiss

Posts 690
09 May 2017 18:02


certainly... only another option


Wawa T

Posts 695
09 May 2017 18:24


tango one wrote:

hope it will be upto the end user what OS we can install.

how else?


Michael R

Posts 281
09 May 2017 20:04


Gunnar von Boehn wrote:

wawa t wrote:

  aros is (or should be) speedwise in a range of usability on rtg.
 

 
  I think so too.
  SAGA has very fast access truecolor modes.
  AROS should be well useable.
 
 
  And one could later add some tuning for PLANAR modes too.
  Thats the beauty of AROS people could contribute!
 
  Speaking about contribution.
  If people like see important bounties for AROS 68k please speak up.
  Maybe we find ways to help support those bounties.

I would like to have support for Bounties for AROS component upgrades such as improving their IDE support for classic Amigas and Vampire accelerators, in addition while installing Icaros Desktop (AROS) recently I discovered that the Bounty might also cover revising AROS support for SATA (AHCI) then we could Dual-Boot AROS. The Bounty or Bounties would pertain to upgrading (ata.device, ahci.device, and usbscsi.device).

Additionally a Bounty for Vampire accelerators to upgrade the scsi.device and on-board micro SD card driver would be greatly beneficial.

Now that my Vampire accelerator card has arrived I would like to test the speed and stability of AROS Vision on the 68080 as well.


Tango One

Posts 102
09 May 2017 21:07


wawa t wrote:

tango one wrote:

  hope it will be upto the end user what OS we can install.
 

 
  how else?

Who else. ?

Well AOS3.1/3.9


Vojin Vidanovic

Posts 770
09 May 2017 21:17


Hi! I might be known to you as vox :-)

I was a long term NG fan, but to be honest, Vampire seems to be glow of light, not only of 68k development, but also what I always wanted - turn on an AmigaOS that is fast and that everything works. Old and new. And MOS and my choice OS4, only failed at emulating full AGA - which they pushed on PPC CPUs and UAE, but emulation is a bit of shame in "native OS". To be honest, beside "OS unity" real shame similar FPGA solutions werent part of AmigaOnes and Pegs since day one.
And until 68080 it was true to say 68k is dead.

OK, wont be coming back to that.

So my plan is to get a standalone Vampire, so I ll just watch all the nice development going on here.

My current "issues" are:
a) 080 and SAGA even FPU feat development is great and your past track entitles you to a realistic trust that WILL be done.
b) Like with OS4 and MOS, then the apps to really utilize new features come order of a day. fact is OS 4.1FEu1+enhancer and MOS 3.8 are great archievements both, and nice OSs, but there are barely few old apps that were updated and just a lot of FLOSS ports and very few new endevours. That pace not only mythical OS 4.2 and x64 MOS wont come soon - their situation in realistic use wouldnt improve instantly even if they would come this month. This challenge remains also for Vampire features
c) Very differently, independent and limbo (great!) position of being in none of the "camps" of being without official OS.

My solutions would be:
a) Make an AmiKit style installer that would require original OS 3.5,OS 3.9CDs or OS 3.1 FDDs/ADF/DMSs.It would make necessary updates and changes to it, including core flash on first install, upgrading OS 3.9 to BB2 etc. If legally possible, do it with AmiKit. If not, in users stylee. Include Dopus 5.x and most of updated 68k components, and similar to BB4 project, bring it as possible to abilities of "NG older sisters" while keeping compatibility due to chipset presence.
My extended wishlist would be an WarpOS JIT 603e emulation layer that would enable us to play Heretic II, Shogo ... and PPC versions of AmigaOS 3 software.
b) Go AROS way, support it via bounties, build Vampire edition, work on it. Become part of Amiga open source while keeping users some kind of dual boot ability to install OS 3.x on their own. Have an modern Amiga compatibile OS. Backporting more x86 AROS apps to 68k AROS would give some modern apps too.
c) Similarly to AEROS, try integrating whatever is best and most stable 68k Debian with 68k AROS (you can drop UAE unlike real AEROS) and make one unique OS that could run Libre Office 3.5 and some Linux apps of selection + AROS apps + if possible, since being 68k ... AmigaOS 3 boxes. Call the OS "VampireOS"

AROS Bounties - Power 2 the People (sounds so Rasta or socialist)
EXTERNAL LINK  AEROS EXTERNAL LINK https://www.youtube.com/watch?v=ZoSTGWjoEwM
AROS 68k Clean 2011
EXTERNAL LINK  GNU toolchain for building amiga-m68k aros under windows cygwin
EXTERNAL LINK


Vojin Vidanovic

Posts 770
09 May 2017 21:25


How viable option is AKReal?
  EXTERNAL LINK 
  Maintainer is retrofan
  EXTERNAL LINK 
  Not that I am against AROS 68k, it just doesnt seems to be in line with AROS x86 development + issues, it might need a lot of work = time, so AKReal could be a quick solution to instantly jump above OS 3.9 with a lot of updates to whatever is avail at 68k side in 2017

Edit:
Found a video of working AkReal on an Vamaporized A2000
EXTERNAL LINK


Wawa T

Posts 695
09 May 2017 22:45


tango one wrote:

wawa t wrote:

 
tango one wrote:

  hope it will be upto the end user what OS we can install.
 

 
  how else?
 

 
  Who else. ?
 
  Well AOS3.1/3.9

certainly.. who is taking it away from you? im using it myself.


Wawa T

Posts 695
09 May 2017 22:50


Vojin Vidanovic wrote:

How viable option is AKReal?
  EXTERNAL LINK 
  Maintainer is retrofan
  EXTERNAL LINK 
  Not that I am against AROS 68k, it just doesnt seems to be in line with AROS x86 development + issues, it might need a lot of work = time, so AKReal could be a quick solution to instantly jump above OS 3.9 with a lot of updates to whatever is avail at 68k side in 2017

two different things. amikit and akreal are bells and whitles upon the 3.x core os. perhaps there some improved libraries or patches are a pert of distribution as far as they may be legally supplied. this isnt a coordinated approach to improve the os, ecpecially its core elements and low level infrastructure.

aros in turn provides such an opportunity. sure it needs some commitment.



Vojin Vidanovic

Posts 770
10 May 2017 00:09


wawa t wrote:

 
Vojin Vidanovic wrote:

  How viable option is AKReal?
    EXTERNAL LINK   
    Maintainer is retrofan
    EXTERNAL LINK   
    Not that I am against AROS 68k, it just doesnt seems to be in line with AROS x86 development + issues, it might need a lot of work = time, so AKReal could be a quick solution to instantly jump above OS 3.9 with a lot of updates to whatever is avail at 68k side in 2017
 

 
  two different things. amikit and akreal are bells and whitles upon the 3.x core os. perhaps there some improved libraries or patches are a pert of distribution as far as they may be legally supplied. this isnt a coordinated approach to improve the os, ecpecially its core elements and low level infrastructure.
 
  aros in turn provides such an opportunity. sure it needs some commitment.
 
 

 
  Yes Wawa, I do understand that, so I am for even Vampirezed AROS (or blended with Linux 68k for some apps if needed, maybe as sandbox) but it will be a long road judging by current AROS 68k state.
 
  Somewhat fixed OS 3.9 and maxed out looks like a stopgap solution that even as we know captures the hearts of many.
 
  It cannot be legally systematically developed (or could be only by Amiga Inc and Hyperion) but a number of feature improvements including even MUI "5" 68k could quite upscale it close or with Vampire feats and few optimized apps above lets say OS4/MOS level of usability and OS features minus 3D.
 
  And 3D needs to be resolved even by Warp3D SAGA driver or similar :-)

Edit

Debian 68k exists
EXTERNAL LINK  But it seems it needs MMU, which rules out Vampire for now.
"Please note that a memory management unit (MMU) is required; this rules out the "EC" variants of these processors. Floating-point emulation is available; however, it is not functional on some mac models due to a bug in some revisions of the 68LC040 processor. (68LC040 processors in other subarchitectures are fine; only Macintoshes appear to have been shipped with the broken 68LC040 processors)."
EXTERNAL LINK

posts 72page  1 2 3 4