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
Questions and Answers for AROS AMIGA OS

Building for AROSpage  1 2 3 

Martin White

Posts 85
15 Jan 2020 21:13


If I build some code / a program that runs on coffin, V4SA - will it also run on AROS (m68k V4SA) without any changes or do I need to take extra steps or make extra considerations when building?


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
15 Jan 2020 21:29


Martin White wrote:

If I build some code / a program that runs on coffin, V4SA - will it also run on AROS (m68k V4SA) without any changes or do I need to take extra steps or make extra considerations when building?

Yes normally your program should just work on AROS too.



Wawa T

Posts 695
15 Jan 2020 21:30


the whole reason to have aros on m68k is that amiga binaries should run on it.


Martin White

Posts 85
15 Jan 2020 21:31


Cool, thanks.

[edit] I'm asking because I keep crashing the video driver on Coffin and having to power cycle so I'm keen to see if AROS is doing the same and it's my code or something else.


Wawa T

Posts 695
15 Jan 2020 21:33


if you however want to use aros features, whatever it may be, youll probably be best served building ma68k binary within aros build system. this will probably though cause that your binary wont work on genuine system.


Wawa T

Posts 695
15 Jan 2020 21:35


simply run aros under uae and run your binary with it.

you have joined the slack, right? why not head to aros channel for advice?


Martin White

Posts 85
15 Jan 2020 21:40


Well, there are two reasons that I haven't so far succeeded in doing that. Well. Sort of...

By emulation here I'm talking about AOS3, not Aros.

On V4SA my code maintains a solid 50fps. Or so it would seem I've not implemented enough to really push it yet. Under emulation, depending on what it's doing it can be 3 to 10fps even with as far as I've got. It's pretty painful. Under emulation, aside from being painfully slow, it works well.

I did try getting an Aros up and running under FS-UAE but failed. Admittedly I didn't try that hard yet, I've been pretty busy.


Martin White

Posts 85
15 Jan 2020 21:40


[edit] Re: Slack - yes, done I think. Aros on AmigaPorts. Seems to be where everyone is
 


Martin White

Posts 85
16 Jan 2020 01:54


OK, managed to get a reasonably fast Aros up and running under FS-UAE and my code runs just fine. So given that's Amiga OS and Aros not reporting any problems then I have to conclude that the memory crashes are either being ignored by those two OS's or it's the Vampire and maybe coffin at fault.

In addition, I don't get any issues with video locking up and becoming unresponsive under emulation either so I guess that's the SAGA driver?

I guess for completeness I need to build my own HDD that's as clean as I can get it but I'm not sure what that should be? 3.1.4 + P96 + SAGA drivers maybe? (I need RTG and SDL for my application)


John William

Posts 563
16 Jan 2020 01:59


wawa t wrote:

if you however want to use aros features, whatever it may be, youll probably be best served building ma68k binary within aros build system. this will probably though cause that your binary wont work on genuine system.

THAT IS HOT!!!! POOOOOOOORRRNNN!!! - fans face -



Wawa T

Posts 695
16 Jan 2020 07:43


you can use muforce tools on amiga and you can enable mungwall on aros to catch illegal mem access. right now i dont recall the aros procedure, might need to be enabled at compile time. best ask on slack.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
16 Jan 2020 10:50


Martin White wrote:

I guess that's the SAGA driver?

Help me understand better what you do and what you tested?

You have a video player or game screen?
You ran it on AOS or AROS?
The behavior is the same on both?

What screenmode do we talk about?
What GFX functions do you use? CGX, P96, ?


Martin White

Posts 85
16 Jan 2020 12:00


Sure, I will see if I can put some videos together this evening. It doesn't do it every time I run the program, but enough for it to be a real pain.

At the moment, on Vampire I can only try coffin r55. This is all I have. I wish I could test it on Aros but I have tried for two evenings to get the HDF from the nightly builds to work on Vampire with no luck. If there is an image you can share, even privately because it's not really ready yet, please do.

I am using screenmode 480x270x16. I have tried a few others but they behave the same, just slower. Note, this is a starting position. If I can get a better resolution later then great but for now that size is fine.

In terms of graphics functions, I use SDL 1.2 that has some vampire optimisations from the guys doing the Diablo port. Does it use CGX or P96? No idea. It is mostly SDL_CreateRGBSurface, SDL_FillRect, SDL_BlitSurface, SDL_Flip.

Right now, the program simply draws 100 random size and colour boxes per frame, displaying the FPS. When the program exists I get an error box about a corrupt memory list during free from exec.library. I just ran it twice. The first time it was ok at the end, the second time I left it running longer and now the screen is mostly off flashing on just often enough to know that the system is still alive. If I do a soft reboot the screen will not come back. If I power off / on then of course everything is OK.


Martin White

Posts 85
16 Jan 2020 13:40


I need to investigate further when I have some more time but as per conversation on Slack, I think you're onto something with the clipping.

Demo code that I've seen online doesn't explicitly set clipping but if I do and I just clip it to the entire size of the surface then it continues to crash. If I clip it with a 1 pixel border all round (so 1, 1, w - 2, h - 2) then my crashes appear to be gone. BUT, I need to do more testing.


Ronnie Beck
(Apollo Team Member)
Posts 199
16 Jan 2020 14:40


Martin White wrote:

  In terms of graphics functions, I use SDL 1.2 that has some vampire optimisations from the guys doing the Diablo port.

Don't use this.  The Diablo port uses a bastardized SDL which has the goal they will remove SDL slowly.  In the original port from HenrykRichter, the SDL_Flip is implemented differently.  The last time I checked the code from the Diablo guys, they by-passed all the code from the original port and just simply change the frame buffer.  This never checked if the frame was finished displaying and in my testing, lead to screen tearing.  The performance was great but the image was garbage.  The original port did screen flipping in synchronisation with the OS (but I forget the details now).

Use the original port.

EXTERNAL LINK 
If you can't get that working, can you post some code somewhere?  I can probably get it working for you.


Martin White

Posts 85
16 Jan 2020 14:53


OK, that certainly explains some of the things I'm seeing, like text for the FPS not consistently being drawn and looking like it's being overwritten. My problem is that I need it to be as fast as possible but as a starting point I'll take whatever works.

I need to get to a point relatively soon where I know whether porting to Vampire is viable or if it's flogging a dead horse (in terms of performance). I have other problems right now. Like I need SDL_Image and the compiler dies trying to compile it.

I haven't looked at the source for the Diablo port but I am 99% sure that there is an issue with SDL_SetClipRect(). According to the docs passing NULL as the rect should be the same as passing the full surface dimensions but that doesn't appear to be the case, it appears that if NULL is passed no clipping is performed.

And that's ignoring the fact that I don't think I should need to explicitcly set the clipping at all. But I defer judgment on that. I hadn't done any graphics coding at all until about 2 or 3 weeks ago.


Martin White

Posts 85
16 Jan 2020 15:19


So this leads me to another question that I've not had an answer to yet.
 
  There are opinions that the gcc6 port can be buggy (I don't know if that is correct or not) but if not using that, what should I use? Bear in mind that this is a modern project built with cmake that also has Windows, Linux, MacOS, ChromeOS and other native versions (of course they don't use SDL1) so the code isn't unique to Amiga.
 
  What toolchain to use then? I've gone for gcc6 because as much as possible that was a case of some modifications to CMakeLists.txt to define the cross-compiler, some flags, some libs and off we go working on the SDL1.2 layer. If we are talking SAS/C on an Amiga for example then I appreciate it can probably be done but it's another level in terms of the amount of work.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
16 Jan 2020 16:15


Martin White wrote:

I've gone for gcc6

 
You can choose from GCC 2.9 to GCC 10 which one you like most.
 
Regarding "performance"
SDL is always so "lala" in performance.

Depending how you use SDL you can also accidently create some extra indirections which will reduce performance.

For result verification you can also do some direct rendering to create comparison numbers: 

Or you can do some math to verify the scope of the scores_

For example:
A 480*270 16bit Screen is 250 KB in size.

If you "fill" the screen with 1 color then you should roughly be able to do this 2000 times per second!
 
So 2000 FPS for a Fillscreen test which fills one time and 100% of the screen.




Martin White

Posts 85
16 Jan 2020 16:25


Gunnar von Boehn wrote:
 
You can choose from GCC 2.9 to GCC 10 which one you like most.

Obviously not what I meant! 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.

And I don't mind some (let's call it) vampire specific code, but I'm not maintaining and entirely different fork forever. Fork that!

And of course just filling a screen with a single colour isn't really a very useful test of performance. Not surprisingly there's the entire rest of the code base to take into account.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
16 Jan 2020 16:33


Martin White wrote:

  Whatever I use has to have a cross-compiler to m68k,

This is exactly what I said.
You can use from GCC 2.9 to GCC 10 - any GCC for cross compiling.
 
Martin White wrote:

  And of course just filling a screen with a single colour isn't really a very useful test of performance.

What would be a useful test?

 
I think doing the math for some ballpark numbers is good
and having a rough feeling what is peak possible never hurts.

So for example:
SOLID FILL SCREEN 480x270
peak ~ 2000 FPS

COPY IMAGE TO SCREEN 480x270
(Copy 1 fullscreen background image on SCREEN)
peak ~ 1000 FPS

COPY Sprites to Screen with 100% draw 480x270
peak ~ 1000 FPS

If you combine this with Background Image copy + Sprites covering 100% overdraw of Screen
peak ~ 500 FPS

posts 47page  1 2 3