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.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Running Games and Apps.

Lets Write Games for Amiga - Use SAGA!

Gunnar von Boehn
(Apollo Team Member)
Posts 4796
29 Apr 2020 08:24


This time of the year, some people are locked in, some people have some time ...

Maybe this is a great chance to write some small games for Amiga.

You will recall the many good old classic games like: Centipede, Falcon Patrol, River Raid

Those games were fun, easy to understand and actually fast and easy to develop.

How about rewriting them for SAGA using the nice new features like more colorful Sprites?

If we all work together here, we can quickly re-create a bunch of nice small games for Amiga.


Maurizio Tirone

Posts 15
29 Apr 2020 16:09


I have nothing against retrogaming, on the contrary, but talking about "Centipede" on Vampire makes me smile a little ...

If you allow me, I think you should urge to dare more about your beautiful creature called Vampire


Kamelito Loveless

Posts 97
29 Apr 2020 17:30


Nice idea and code snippets could be used to develop a game library.


Eric Gus

Posts 404
30 Apr 2020 07:01


Would love to but im waiting for a high level language like BlitzBasic, AMOS (ProX say) to have support.. I am really not up to asm these days .. just no time to dedicate to it.. otherwise yep, fully onboard with the idea though!


Gunnar von Boehn
(Apollo Team Member)
Posts 4796
30 Apr 2020 07:10


eric gus wrote:

Would love to but im waiting for a high level language like BlitzBasic, AMOS (ProX say) to have support..

There is no need to wait any longer.
You can today write a game with the languages already.



Michael Borrmann

Posts 133
30 Apr 2020 07:59


eric gus wrote:

Would love to but im waiting for a high level language like BlitzBasic, AMOS (ProX say) to have support.. I am really not up to asm these days .. just no time to dedicate to it.. otherwise yep, fully onboard with the idea though!

You can just use those things, and will have a massive speed boost with the vampire, anyway.




Antony Coello

Posts 24
30 Apr 2020 14:46


Gunnar; as soon as I manage to get a working Vampire system, I will start looking into crossporting my PC game framework.

I already know what Toni Wilen has said regarding Vampire emulation, but I dont suppose theres a software version of the 68080 core that I can hack into WinUAE so that I can test/take advantage of any of the '080/SAGA/AMMX extras in the meantime?


Gunnar von Boehn
(Apollo Team Member)
Posts 4796
30 Apr 2020 16:01


Antony Coello wrote:

  I already know what Toni Wilen has said
 

Tony has clearly his own interests, no doubt about this.
I can understand this.
But isn't just normal that he see other Amiga-developers as competition? I think this is understandable.


Eric Gus

Posts 404
30 Apr 2020 19:46


Michael Borrmann wrote:

 
    You can just use those things, and will have a massive speed boost with the vampire, anyway.
 

 
  Well thats my plan short of specific features added to a highlevel language.. Now I just need a V4 (or core3 on my v2 .. :-D .. lack of chipram is killing me on the v2 -- and I have zero interest in hacking my (actual own original first Amiga I ever bought) rev5 NTSC locked A500 to try to expand it, nope shes not going under the knife).


Antony Coello

Posts 24
30 Apr 2020 21:57


Gunnar von Boehn wrote:

  But isn't just normal that he see other Amiga-developers as competition? I think this is understandable.
 

 
  Perhaps I have it all wrong, but from what I took from his posts on the matter, it seemed the reason he has not put the work in to emulate the Vampire is that he did not want to chase a so called 'moving target'. I dont think he is direct competition. Some people like convenient emulation, others, it HAS to be the real hardware. Wouldnt it be in his interest to emulate Vampire at some point?
 
  Anyhow, back to the subject matter, what would be the ideal stepping stone for many, is if some of the Assembly/C compiler writers can be persuaded to include automatic 080/MMX compile optimisations/instruction swap-ins from standard 68xxx code. Then its just a matter of dealing with SAGA techniques/conversions.
 


Gunnar von Boehn
(Apollo Team Member)
Posts 4796
01 May 2020 02:24


Antony Coello wrote:

Perhaps I have it all wrong, but from what I took from his posts on the matter,

 
But is this is his true opinion or just an excuse?
 
Fact is that the 68080 CPU instruction set is clearly defined
and that the AMMX instruction did not changed since years.
So moving target is clearly not correct.

Also 68080 has compiler support and obviously can't be a moving target which changes behaviors - as otherwise the compilers would all break.
   
Fact is that Tony never even care to talk to us or ask for roadmap or if features are planned to be changed.
So I wonder how he would come to his wrong opinion?
 
   
Antony Coello wrote:

Anyhow, back to the subject matter, what would be the ideal stepping stone for many, is if some of the Assembly/C compiler writers can be persuaded to include automatic 080/MMX compile optimisations/instruction swap-ins from standard 68xxx code. Then its just a matter of dealing with SAGA techniques/conversions.
     

 
What do you mean by
automatic 080/MMX compile optimisations/instruction swap-ins
 
Its not fully clear to me what you understand under this.
Can you please give a concrete example?
 
AMMX is designed to solve problems which you can not easily solve with 68K instructions. Therefore there is not such thing as an 68k-Asm instruction matching 1:1 to this AMMX code.

I'm not sure how familiar you are with 68K ASM code.
AMMX does not "replace" existing 68k instructions.
There is no point in doing this.
AMMX does extend the 68K instruction set to solve problems people could not effectively tackle before.



Antony Coello

Posts 24
01 May 2020 10:38


Gunnar; I can guarantee I dont know as much about compilers or MC68k architecture as you, so forgive me any mistakes! ;)
 
  However, I still think it may still be relevant.
 
  I see VASM has compiler support. This is just for the new insructions which have to be coded in manually, obviously.
 
  As for 'swapping': perhaps I am stepping a bit too far with AMMX conversion, like you say, as its too far removed from 68k. But for 68xxx code, what I was describing/proposing, from the simplest viewpoint, like when eg someone would code:
 
  MOVE.L  #$xxxx,A0
 
  the compiler would swap it for:
 
  MOVEA.L  #$xxxx,A0
 
  Same with MOVEQ/ADDQ, etc. The compilers will be doing this addressing mode swap already, but not going as far as swapping of actual NEW instructions.
 
  This could be extended from the simplest adressing mode, attribute or instruction swap (as above) with a compiler pattern recognition if for example there are any new 080 instructions that can be used to replace a SPECIFIC SET of 68000-60 (longer/slower) instructions. This would be similar to higher level compiler directives.
 
  If this is not relevant or invalid, then forgive my ignorance and perhaps we can just settle for making do with collecting all your 080 code snippet examples into one document, so we can do what cannot be done above ourselves!
 
  I hope this makes sense to some degree. I have to admit though, I havent had a thorough look at the new 080 instructions, so perhaps there are absolutely no use cases which are applicable.
 
  As for Mr.Wilen; perhaps you are right. Its hard to tell some peoples motives sometimes. Externally, he doesnt appear to be against it..?
 
  Have you discussed Vampire emulation with any other emulation authors? (even modified Atari emulators may be suitable). I think the more exposure to the 080/AMMX/SAGA, the better. BUT I can totally understand if you would prefer not to have the core emulated and if this were to be the case I can see why from your perspective.
 
  As a 'real' example of the solutions the above would solve; I am sat here with a broken (possibly bad caps) A500/Vampire board and cannot make games for Vampire by any other method :(


Gunnar von Boehn
(Apollo Team Member)
Posts 4796
01 May 2020 11:11


Antony Coello wrote:

As for 'swapping': perhaps I am stepping a bit too far with AMMX conversion, like you say, as its too far removed from 68k.

Let me clarify some basis.
68080 makes already the old 68K instructions as fast as possible.

Its not that the old 68K MUL instruction takes 100 cycle but the new AMM-MUL takes 1 cycle.
And that you need replace the old instruction by the new one to get more speed.
We did already make the old MUL instruction as fast as possible (2 cycle) - therefore there is no need for an instruction replacement.

The new AMMX-MUL is a vector operations which does do 4 MUL in parallel - This makes the code faster, but for using this you also need to layout all the data in memory different.
This is normal for all VECTOR operations, same is needed for IBM PPC or INTEL x86. To benefit from vectorization you need to change the structure of the data in memory.

In short a programmer needs to decide to use vectorization where the data layout permits it.



Antony Coello

Posts 24
01 May 2020 14:25


Ok. I see.

So, I get the need for code change for the AMMX parallel operations. (Im guessing the setup is in some ways similar to aligning code for prefetch optimisation).

From what you are saying I now understand that the non-AMMX 080 instructions are the SAME as on 000-060 but (variably) much faster.

  Which would mean having to change code, not because it wouldnt work, but for the more optimal faster instructions which may be different to what was the fastest setup before.

Have I got it yet? ;)
 


Bartek Kuchta

Posts 4
29 Jun 2020 14:09


Hi Gunnar,

I would be interested. I'm happy to polish and improve 194x graphics so that we could finish the game:)

Kind Regards

posts 15