Overview Features Instructions Performance Forum Downloads Products OrderV4 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 TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Questions and Answers for AROS AMIGA OS

Building for AROSpage  1 2 3 

Ronnie Beck
(Apollo Team Member)
Posts 173
16 Jan 2020 19:05


Martin White wrote:

Whatever I use has to have a cross-compiler to m68k, preferably optimised for Amiga and better still has optimisatoins for Vampire since I'm happy to make 080 a requirement.

You need to be perhaps clearer with your intent.  Both VBCC and Bebbo's gcc6 port support m68k and the 68080.  The question is, what do you want to achieve exactly?  If you are porting an existing software from Linux, GCC will offer a clear advantage in getting that port running.  GCC is the native Linux compiler, so it could reduce the effort.  If your goal is to create something new, then you are open. VBCC however is a C compiler only.  But it is a good compiler. 

I don't think it makes sense to really compare performance between VBCC and GCC (C code) because if you really need to care about performance of your code that much, then you should consider writing performance critical code in assembler anyhow.  Mixing C/C++ (for high level non-performance critical stuff) with assembler is a good balance.  Both VBCC and GCC will allow you to embed assembler.  I know VBCC will allow you to embed AMMX instructions but I am not sure about GCC.  I assume its possible.

I don't see a problem with using SDL for things like screen/window setup.  You can still write to the frame buffer directly with the same code that you would otherwise use.  The SDL port from Henryk Richter has AMMX optimisations already for many things such as blitting surfaces to the screen.  Like Gunnar says, SDL performance for graphical draw operations is ok but you will likely be able to make something better yourself (and in assembler).

@Gunnar: Do we have something in SAGA for blitting like in the original Amiga chipset?  Something that could take care of byte copying (moving blocks of graphics) while the CPU is doing something else?


Ronnie Beck
(Apollo Team Member)
Posts 173
16 Jan 2020 19:17


Martin White wrote:

  There are opinions that the gcc6 port can be buggy (I don't know if that is correct or not).......

Bebbo, the author of the port, responds to bugs very quickly in my experience.  I don't really know if I could say that gcc6 for Amiga is any more/less buggy than the alternative.  In terms of a modern C compiler, there aren't really that many alternatives.  And for C++11 (not sure if you care about that), there is only gcc

Martin White wrote:

  What toolchain to use then? I've gone for gcc6........SDL1.2 layer......

I have gone a similar route as you.  I am coding with bebbo's GCC6 compiler and SDL1.2.  I find this quite comfortable.  Right now I am working on code for getting amiga fonts displayable in SDL_Surfaces easily.  I gave up trying to compile SDL_ttf for Amiga.  I would be happy to share code if you want to collaborate on solving similar problems for the Vampire/Amiga.

The way I see things is, that we need APIs to take over where the original Commodore/H&P APIs left off.  Trying to use Amiga native graphical functions in the world of RTG requires some sort of translation layer (P96 for exampe).  Maybe if we were to create some open source libraries that will work directly with RTG graphics modes, we can help other developers accelerate their efforts.  Just a thought.

SDL could be enhanced further, as an example.  Henryk Richter has done a lot of work already.  But this work could be continued.


Gunnar von Boehn
(Apollo Team Member)
Posts 4718
16 Jan 2020 19:46


Ronnie Beck wrote:

  @Gunnar: Do we have something in SAGA for blitting like in the original Amiga chipset?  Something that could take care of byte copying (moving blocks of graphics) while the CPU is doing something else?
 

 
Does this question imply that the concept
of the AMIGA BLITTER was all good without drawbacks?
 
Honestly the truth is far from this.
The Blitter idea has serious drawbacks.
 
Let us explain the drawbacks to make this clearer to understand:
 
1) Using the Blitter means you need to send the job to it.
Sending the job information needs extra cycles and extra instructions.
 
2) While the Blitter writes to GFX memory, the CPU has to avoid writing to GFX memory. To prevent chaos.
 
3) A blitter job can not be "stopped" interrupted and can not be continued. This means if a program starts a blitter job, this job runs even if the program was task swapped and a new task should run.
 
4) The Blitter can NOT be used by several task in parallel.
This means when one program uses the Blitter, another program can not use it in parallel.
To prevent chaos from happening usage of the Blitter needs be done through an allocation mechanism. This is mandatory. And this creates a "bottle-neck" device.

5) One program using the Blitter needs to wait for the 1st job to finish before starting the next, if not havoc will happen.
And the Blitter can overwrite random memory causing crashes.
This needed WAIT can waste CPU time.

6) several tasks which depend on each other but which also use the Blitter can easily create deadlock situations.
 
 
 
On the AMIGA the 68000 CPU at 7 MHz was relative slow doing bitcopy operations.
The AMIGA Blitter did improve the speed.
Therefore the extra complexity for setting up the Blitter, for managing access and arbitration, the bottleneck situation  and problem in Multitasking where a trade-off which made sense.
 
 
Now the time has changed.
APOLLO 68080 is 300 times faster than 68000@7Mhz.
APOLLO is designed for SMP/Hyperthreading, for multitasking and for Multi-Core Support.
 
APOLLO 68080 is 200 times faster than AMIGA Blitter.
The deadlock risk of the Blitter, and Multitasking unfriendlyness is now a serious drawback - which needs be considered.
 


Kamelito Loveless

Posts 91
16 Jan 2020 19:47


I didnít know that VBCC supported 080/AMMX I thought it was just Bebboís GCC.
VASM do, but it is an assembler.


Ronnie Beck
(Apollo Team Member)
Posts 173
16 Jan 2020 20:12


Gunnar von Boehn wrote:

Ronnie Beck wrote:

  @Gunnar: Do we have something in SAGA for blitting......
 

  Does this question imply that the concept
  of the AMIGA BLITTER was all good without drawbacks?

  Honestly the truth is far from this.
  The Blitter idea has serious drawbacks........

Good to know. So I take it that AMMX optimised code would be the better route, when doing draw/blit operations.


Martin White

Posts 85
16 Jan 2020 20:19


Ronnie Beck wrote:

I have gone a similar route as you.  I am coding with bebbo's GCC6 compiler and SDL1.2.  I find this quite comfortable.  Right now I am working on code for getting amiga fonts displayable in SDL_Surfaces easily.  I gave up trying to compile SDL_ttf for Amiga.  I would be happy to share code if you want to collaborate on solving similar problems for the Vampire/Amiga.

just very quickly, since I have spent so much of the day looking and thinking about this that I now need to do some paid work this evening, but...

I got SDL_ttf compiled and working very easily a few nights ago. I don't know if you will want it since it is compiled against the SDL from the Devilution X guys (and indeed built using the GCC container that Marlon provided!) but you are welcome to the lib and includes if you'd like?

I had quite a lengthy chat on Slack with Gunnar and I understand all of what is being said, but my first step has to just be getting something built and running, then look at what can and should be converted and / or optimised.

Tonight (well, tomorrow night now), the stumbling block is SDL_image. I can't get that to build the same way I built SDL_ttf.

The project itself is an existing multi-platform closed source codebase which makes it difficult to be too open about. That's the score right now. I don't know what might happen to it in the future.


Martin White

Posts 85
16 Jan 2020 20:43


Ronnie Beck wrote:

  SDL could be enhanced further, as an example.  Henryk Richter has done a lot of work already.  But this work could be continued.

 
Something that would be so, so, useful, especially now that SDL 1.2 versions do not really increase any longer is if there were pre-built binaries for sdl, sdl_image, sdl_ttf and any other commonly used ones. Is it perhaps a licensing reason that they are source that we have to build?
 
I've also been told that the license of SDL1.2 dictates that I need them to be non-statically linked if I want to release something without having to release my source. At this point in time it's the least of my concerns but if true, will have to be tackled.
 
What would be ideal from my point of view, as someone who I will admit doesn't really have a huge interest in getting down to the kind of level that would be required for the ASM (or otherwise) optimisation would be if I could just grab an archive with all the components of SDL as ".library" files. Like i say, maybe that isn't allowed? Even if it is allowed someone still needs to create those files :D


Matthias Rustler

Posts 1
17 Jan 2020 04:47


AROS has SDL as Library in Contrib. It would be great if Vampire related improvements could be added there.


Ronnie Beck
(Apollo Team Member)
Posts 173
17 Jan 2020 07:12


Martin White wrote:

I've also been told that the license of SDL1.2 dictates that I need them to be non-statically linked.......

That isn't how I interpret the license text.  SDL 1.2 is covered by the Lesser GPL which has less strict rules.  Read the text in detail.

Martin White wrote:

What would be ideal from my point of view, as someone who I will admit doesn't really have a huge interest in getting down to the kind of level that would be required for the ASM (or otherwise) optimisation would be if I could just grab an archive with all the components of SDL as ".library" files.

But you have this already.  You built your own copy of these libraries.  The ASM enhancements are already in the source code.  I advocate libraries that come in source code form because you have the possibility to fix problems yourself.  Look how far ahead AROS is compared to OS 3.X.  This is because it is open source.  And AROS will continue to advance.

But I feel perhaps as you do.  I don't want to have to spend huge amounts of time with ASM to write boiler plate code.  Common tasks can be encapsulated in libraries which are used and optimised by programmers.  The SDL port by Henryk Richter already does that for us. Look at the Apollo specific assembler code in SDL:

EXTERNAL LINK 
It already has AMMX enhanced blitting and colour conversion which is in line with your wishes.


Nixus Minimax

Posts 415
17 Jan 2020 09:27


Gunnar von Boehn wrote:
1) Using the Blitter means you need to send the job to it.
  Sending the job information needs extra cycles and extra instructions.

This amounts to a few cycles per blit.
 
 
  2) While the Blitter writes to GFX memory, the CPU has to avoid writing to GFX memory. To prevent chaos.

The 080 is SMP-ready, accordingly it should not be too difficult to prevent chaos here. Of course, a second CPU would always be better than a very rudimentary unit such as a blitter but we have space constraints in the FPGA and we are running AmigaOS (AROS may be an opportunity to introduce SMP to AmigaOS, though).

3) A blitter job can not be "stopped" interrupted and can not be continued. This means if a program starts a blitter job, this job runs even if the program was task swapped and a new task should run.

I don't think this is a problem in itself and could be changed in a "SAGA-blitter".

4) The Blitter can NOT be used by several task in parallel.
  This means when one program uses the Blitter, another program can not use it in parallel.
  To prevent chaos from happening usage of the Blitter needs be done through an allocation mechanism. This is mandatory. And this creates a "bottle-neck" device.

That is why AmigaOS has a blit queue. Blitting with the CPU is just as much a bottle-neck in a multitasking OS because all tasks require the same resource, the CPU. With a blitter interrupt the CPU would not have to check whether the blitter is still busy or not. No CPU time wasted other than that for serving the interrupt.

5) One program using the Blitter needs to wait for the 1st job to finish before starting the next, if not havoc will happen.

This is avoided by using a blit queue.

And the Blitter can overwrite random memory causing crashes.

A soft-blitter can do just the same.

6) several tasks which depend on each other but which also use the Blitter can easily create deadlock situations.

This is true but it is a standard problem in multi-threaded applications and the programmer is responsible.
 
 
Now the time has changed.
  APOLLO 68080 is 300 times faster than 68000@7Mhz.
  APOLLO is designed for SMP/Hyperthreading, for multitasking and for Multi-Core Support.
 
  APOLLO 68080 is 200 times faster than AMIGA Blitter.

Well, IMO a blitter could still make sense because it can work on RAM saturating the memory bus (all cache prefetches and burst mechanism will work very well with the blitter) while the CPU is working in the instruction cache. The 080 is much faster than the first generation Amigas but at the same time it is supposed to run programs and GUIs that have much higher resolution and much higher colour depths. In 1985 a normal blitjob was 16x16 pixels in 16 colours which is a mere 128 bytes in lenth. Now we could do e.g. 64x64 in hicolour which would be 8k per tile. The time required for blitter setup becomes very small in relation to the blitjob itself.

Of course, if we were to have an 080-ASIC, I would rather have it be a multicore CPU than one 080 plus a SAGA-blitter. But within the size and speed constraints of an FPGA, I think that an improved SAGA-blitter can make a lot of sense.



Gunnar von Boehn
(Apollo Team Member)
Posts 4718
17 Jan 2020 09:57


Nixus Minimax wrote:

But within the size and speed constraints of an FPGA, I think that an improved SAGA-blitter can make a lot of sense.

APOLLO CPU can fully saturate the memory interface.
If you look at the BUSTEST scores you can see that APOLLO 68080 has no problem to do 700 MB/sec memory write!

So if you do pure "memcopy/blitting" stuff Apollo does this today already perfectly.

I can see the virtue of a 2nd unit more in the field of texture 3D accdeleration.


Nixus Minimax

Posts 415
17 Jan 2020 11:20


Gunnar von Boehn wrote:
APOLLO CPU can fully saturate the memory interface.
 
  So if you do pure "memcopy/blitting" stuff Apollo does this today already perfectly.

Yes, sure. But the CPU can't do numbercrunching at the same time as doing soft blits. If the blitter does its blit jobs on the memory interface and the CPU does register-intensive numbercrunching executing code that is in the instruction cache, more work is being done in the same time than if the CPU does both the blit jobs AND the numbercrunching.



Ronnie Beck
(Apollo Team Member)
Posts 173
17 Jan 2020 12:23


Nixus Minimax wrote:

But within the size and speed constraints of an FPGA, I think that an improved SAGA-blitter can make a lot of sense.

This topic is interesting enough to have it's own thread.  Could those who are interested please move this discussion to a new thread so that the discussion here can remain faithful to the original topic?

I asked Gunnar about existing hw blitting capabilities with the view of enhancing SDL (which is the core of this thread).  What we discuss now is in essence a feature request to Gunnar.


Martin White

Posts 85
17 Jan 2020 12:39


So, I'm not spending time on this today as I spent far too long on it yesterday and ended up working until nearly midnight as a result but I'd like to comment on a couple of points quickly.

Ronnie Beck wrote:

  That isn't how I interpret the license text.  SDL 1.2 is covered by the Lesser GPL which has less strict rules.  Read the text in detail.

So this one's easy. Unfortunately it doesn't matter how I interpret the LGPL or how you, but only how the man in charge of the project interprets it. And he says dynamically linked only for SDL1.2. So that's what I must do. For what it's worth, I did indeed read the entirety of the license and sadly, I agree with him but anyway, as above. But i don't have to care about it until it's done, finished and going to be published. All I need to know now is that it can be linked that way and we know it can.
 
Ronnie Beck wrote:

But you have this already.  You built your own copy of these libraries.  The ASM enhancements are already in the source code.  I advocate libraries that come in source code

snip...
 
But I feel perhaps as you do.  I don't want to have to spend huge amounts of time with ASM to write boiler plate code.

I think we're in agreement here anyway. It's not at all about whether I want to spend time on boiler plate ASM. I simply cannot write or even read ASM. I did a little 6502 hacking about 10 years ago by writing some code for an Asteroids arcade machine but tha'ts about it, oh and a little vectrex programming but i did 90% of that in C and only the ASM linkage.

My aging brain has little capacity or desire to learn 68080 ASM at this point in life while I still need to maintain the capacity to program professionally for a living (I tend to need to surround myself in stuff to fully absorb it). Maybe when I've semi-retired in a few years I might take on that challenge, but not now.

So, like I say, would be really useful if there were an SDK you could just download that contains the libraries, both static and dynamic, and the headers for those people that don't want to get into the source at this point. Those that want to can still do so of course. It would be doubly useful if the libs were included in the OS (sounds like they are for AROS but again, I don't have aceess to a working image of Aros for Vampire)

To wrap up, I will continue to try and see if I can compile the bits that I'm missing and progress but for now I fired up my PowerBook G4 that is running MorphOS and discovered that it has all the things that I mention above. Along with the SDL libs already installed into the OS it also has git, gcc, cmake etc. in the Dev kit so it looks like MorphOS may end up being my initial SDL1 target and assuming that works, I can look at other platforms and optimisations.


Ronnie Beck
(Apollo Team Member)
Posts 173
17 Jan 2020 14:55


Martin White wrote:

Martin White wrote:

I've also been told that the license of SDL1.2 dictates that I need them to be non-statically linked.......

 
Ronnie Beck wrote:

That isn't how I interpret the license text.  SDL 1.2 is covered by the Lesser GPL which has less strict rules.  Read the text in detail.

 
  So this one's easy. Unfortunately it doesn't matter how I interpret the LGPL or how you, but only how the man in charge of the project interprets it.

Guess again:

https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic

Text:  (1) If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.

It also doesn't matter what "the guy who runs the project" thinks. It is what is stated in the license.  You only need comply with the license.

Martin White wrote:

So, like I say, would be really useful if there were an SDK you could just download that contains the libraries, both static and dynamic, and the headers............

Look at Bebbo's GCC port.  It is essentially that.

EXTERNAL LINK 



Martin White

Posts 85
17 Jan 2020 15:30


I mean, this is pretty pointless to be honest. But it really does matter what they think regardless of what the internet says, they are in charge of this project.


Ronnie Beck
(Apollo Team Member)
Posts 173
17 Jan 2020 16:50


Martin White wrote:

I mean, this is pretty pointless to be honest. But it really does matter what they think regardless of what the internet says, they are in charge of this project.

I don't think you know who is in charge of the project(you mean SDL right? Because that is what is relevant here).  I am quoting the authors of the License.  Who are you quoting exactly?  Certainly not the Free Software Foundation (the license author) nor Sam Lantinga (the author of SDL).  And you didn't get your advice from a lawyer, that we can be sure of.  Well, I guess it can only affect you.

But just so others reading don't follow your example, here are some things to note:

* The license, as stated in the begining text, is written by the Free Software Foundation who, as part of their mission of free software, created licenses which software authors can use for there own projects.  These licenses are used frequently throughout Open Source world (including Linux itself) and are well known in the industry.  You can find countless examples of where these licenses were enforced by the courts in numerous countries, if you are interested to know how well tested these are.  This organisation is but one of many who provide such licenses.

* The authors of the license helpfully provide a FAQ for navigating the sometimes tricky text of a license.  It covers commonly asked questions, including this one.  It of course can't beat proper legal advice but is helpful nonetheless.
  This can be found here:

EXTERNAL LINK 

* SDL 1.X is written by Sam Lantinga.

* A version of SDL 1.2 optimised for vampire is provided in source via github by Henryk Richter.  You can find this here:

EXTERNAL LINK 

* You should seek advise from legal professionals if you are not capable of understanding licensing.


Kamelito Loveless

Posts 91
17 Jan 2020 17:03


the OS already have all the libraries to program a game if the OS uses hand optimized code using 68080/AMMX then it will benefit all programs. Maybe more functions could be added like physics/collision etc that way programmers will only need to focus on the gameplay/game design.


Martin White

Posts 85
17 Jan 2020 19:21


Ronnie Beck wrote:

I don't think you know who is in charge of the project(you mean SDL right?

Obviously I donít mean SDL, no!!!! I donít care whoís in charge of that.

I mean the closed source, commercial project Iím working on.


Gerardo GonzŠlez-Trejo

Posts 39
17 Jan 2020 22:01


Gunnar von Boehn wrote:

 
  APOLLO CPU can fully saturate the memory interface.
  If you look at the BUSTEST scores you can see that APOLLO 68080 has no problem to do 700 MB/sec memory write!
 
  So if you do pure "memcopy/blitting" stuff Apollo does this today already perfectly.
 
  I can see the virtue of a 2nd unit more in the field of texture 3D accdeleration.
 

 
I think this thread is so interesting. Maybe blitter and 3D related info needs another thread, but, on some way, it is related to building for AROS too...
 
  I understand that thanks to the Apollo 68080, and having AMMX, it makes no sense to add a blitter, right?
 
  So then why not to keep the same way of adding more instructions instead of adding a 3D unit? Like AMD did with 3DNow! (Accelerating, on flotating point, physics, transform, clipping and lighting) but adding, too, triangle set up and pixel rendering acceleration (like your planned 3D unit will do, I suppose)
 
  This could extend FPU and AMMX units without growing so much space
 
  Probably it would not be as fast as an independent TMU / 3D unit, but it would be extremely flexible. Please correct me if I am wrong.

posts 47page  1 2 3