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

SAGA / AGA Launchpage  1 2 3 4 5 6 7 8 9 10 11 

Mallagan Bellator

Posts 393
26 May 2018 15:06


The way the Amiga works, in order to use 16/24/32 bit color depth, you’ll need to go via P96 or another graphics card system, since this is ”graphics card” features.
The SAGA core is based on this, and is therefor considered a ”graphics card”, seen from AmigaOS side. As me if anything is unclear
This also allows for resolutions such as 1280x720 and 960x540, for example, that didn’t fit into the graphics modes of the AGA (in normal modes, at least), since AGA/ECS/OCS needed to be working on regular TVs of the 80s/90s.
Amiga is old hardware! (But lovely, nonetheless)

So! A500 and A600 didn’t have AGA. You all know this.
This means that if you wish to display AGA modes on the Vampire V2, it MUST go through the DIGITAL-VIDEO output, since the chips on the motherboard are incompatible and outdated, and therefor unable to didplay it on the RGB out port. That port is controlled by Denise, which is too slow and too old. Agnus is too slow and too old too! And that’s not all. ECS/OCS is 16 bit, AGA is 32 bit!
Apollo core is 64 bit
You won’t ”need” P96 in order to see AGA modes through the DIGITAL-VIDEO out on the Vampire, you will SEE what you’re doing, but you wont get 16 bit color depth, 24/32 bit color depth, or higher resolutions than 724x768 (going by real AGA capabilities) without P96!
If you wanna use SAGA screenmodes, you will need P96.

One more thing, what Gunnar said about the FPU not being fitted in together with AC68080, AGA and SAGA, is that they ”currently” can’t fit.

The team keep tweaking and coding on the core, and they try to make things fit better into the limited space of the FPGA on the V2 boards.
They might get it to fit, eventually, or they might NEVER get it to fit. They’re no wizzards, they can’t do magic, even if at times it does seem like they can, but no.

On the Cyclone 5 that’s used on the V4, it’s different. This one is bigger, and all that good stuff will fit in there


Mallagan Bellator

Posts 393
26 May 2018 15:10


David Wright wrote:

Mallagan Bellator wrote:

 
Tim D wrote:

  So, that means for FPU dependent software?
   
    - Not gonna work
    - Can use Femu as Mallagan sais
    - other?
 

  I’m waiting for V4, so the problem doesn’t exist there.
 
  Sure, the future where all problems don’t exist.
 
 

 

Poverty is a problem that will always exist in this world... so is hatred...
We will have problems in the future, but FPU not fitting on the V4, at the same time withAGA, SAGA and AC080 CPU, is not one problem that will be with the V4


David Wright

Posts 373
26 May 2018 15:16


I know Mallagan and it’s not a problem on my laptop or surface pro. We are talking about V2.


Mallagan Bellator

Posts 393
26 May 2018 15:25


David Wright wrote:

I know Mallagan and it’s not a problem on my laptop or surface pro. We are talking about V2.

And like I said above, the team are working on the core. Sometimes they can make things smaller to fit all the stuff into the core, sometimes they can’t.
The FPU was never intended to be in the V2 to begin with, it’s more a bonus that you have an FPU prepped core for the V2, because people asked for it. They got it. At the cost of AGA, but still.
It’s possible that you could at some point get a core that skips SAGA and has

FPU
AGA
AC68080

Maybe something more, but that’s up to the A-team and the FPGA of the V2


Eric Gus

Posts 477
27 May 2018 08:10


Roy Gillotti wrote:

  Are you sure it's with the DIGITAL-VIDEO input?, or are they talking about PAL/NTSC issues on Composite or Component video inputs on said TV?

Oh its DIGITAL-VIDEO, the hdmi input on some North American displays wont take a PAL DIGITAL-VIDEO signal..


Eric Gus

Posts 477
27 May 2018 08:12


Mallagan Bellator wrote:

   
    One more thing, what Gunnar said about the FPU not being fitted in together with AC68080, AGA and SAGA, is that they ”currently” can’t fit.
   

 
  the full blown FPU no, but because they have created a "hybrid" FPU that uses some hard functions and some by software this answer isnt as clear .. its unclear if they mean the hybrid fpu or the full hard fpu.. hence the need for clarity. Why I was asking if the fpu situation would be like core 2.5 (full software fpu via femu) or like 2.9 with a "hybrid" low precision FPU with main functions in the hard and the rest done in software.. its not very clear WHICH (if either) are coming in core3 for the V2 .. (obviously the V4 gets the FULL hard FPU) .. but since we are talking about several possible permutations of "fpu" its ambiguous.
 


Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
27 May 2018 08:35


My personal understanding is:
     
      v2 had no FPU and FPU was software emulated at one point
      v2 had mixed FPU in test case, in the end cut down full FPU (precision and some instructions are microcoded) was put to v2 and with it v2 space was maxed out.
     
      Its obviously and mentioned in Amiten Gunnars interview few months ago  you will NOT have AGA and FPU of 2.9 in core 3 for v2. I believe he said SAGA (RTG) and AGA will be avail in one core.
   
    Maybe some other combinations will be introduced, but core limit space remains so it might be variations. Further bugfixes and small improvements remain for such cores but gold 3 will be kind of advanced big features end for v2.
     
      So in my understanding, You will have to reflash, but that is quick and easy. Maybe some faster method like Mist core selector could be introduced as long as cores are stored in a certain folder.
     
      v4 will be only to have it "all-in-one" (and should have far improved Apollo FPU). One reason beside not having a working Classic why I am waiting for standalone. Too bad I am missing the experience.


Ian Parsons

Posts 230
27 May 2018 08:48


There's nothing to stop you banging the hardware directly on SAGA so P96 is optional unless you use apps/games that are written to use P96. P96 was created because Amiga graphics cards bring the PC problem to the Amiga, lots of different designs all needing their own driver and an API to re-target graphics data to the card.

When Commodore extended OCS to ECS and then ECS to AGA they had an integrated system so no need for drivers. Games programmers could continue to hit the bare metal and system friendly software used the updated ROMs. They stuck with planar graphics so the hardware register changes were minimal (space was left in the OCS design for extra plane registers but the CLUT needed bank switching). SAGA is an extension to AGA, it updates some existing hardware registers and places new ones along side the old ones so the can also be controlled by the Copper.

Banging the hardware is rare these and with the Amiga community being so small it seems more common for games to be ported using C and SDL but there are times when coding or optimising in 68080 and hitting the metal makes sense for example the Neo Geo emulator.

I hope that SAGA will be adopted as the new standard for the Amiga so that coders can use the new graphics and audio features directly for the best possible performance.


Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
27 May 2018 08:56


Ian Parsons wrote:

    I hope that SAGA will be adopted as the new standard for the Amiga so that coders can use the new graphics and audio features directly for the best possible performance.
 

 
  Beside bringing AGA backward compatibility out of box, that would be the meaning of SAGA core3 launch.
 
  I hope Team will provide enough documentation on improved things for you coding "metal benging" guys to stop unoptimized backporting only (which has not bring much happiness under e.g. OS4 even it added some functionality)
 


Roman S.

Posts 149
28 May 2018 18:03


Vojin Vidanovic wrote:
I hope Team will provide enough documentation on improved things for you coding "metal benging" guys to stop unoptimized backporting only (which has not bring much happiness under e.g. OS4 even it added some functionality)

Documentation = yes. Register-banging in 'user-space' software = NO!!! Otherwise we could end up with one great piece of AmigaOS 68k software working on Vampire only, another one - on FPGA Arcade only, and yet another - on UAE only...


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
28 May 2018 19:00


Roman S. wrote:

Documentation = yes. Register-banging in 'user-space' software = NO!!

Of course register banging is perfectly legal on AMIGA.
The AMIGA is designed for register banging.
The Copper is made for this and does nothing else but register access.

As SAGA is a true AMIGA chipset its register are accessable by the Copper which will bang them.


Eric Gus

Posts 477
28 May 2018 20:13


Gunnar,

Do we have a finalized "list" of exactly what features we are getting in Core 3.0 for V2 vampire? or is that list still in testing/development? Or is it still a bit too early to list them at this time?

Thanks!


Roman S.

Posts 149
28 May 2018 20:51


Gunnar von Boehn wrote:

Of course register banging is perfectly legal on AMIGA.

Such approach was used, because CPUs didn't have that much power to waste it on abstraction layers, and the chipset remained compatible between OCS for A1000, A500 and A2000, ECS for A600 and A3000, etc. But it's not the case anymore, CPUs tend to be much faster than 14MHz 68020 in just about any current project, and SAGA is only a Team Apollo way of extending the chipset - definitely not an universal standard. Things like AHI or CGX were created for a reason.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
28 May 2018 21:00


Roman S. wrote:

SAGA is only a Team Apollo way of extending the chipset

 
Yes and this is the right way of doing it.
 
The AMIGA key feature was the COPPER.
The Copper allowed Dragging Screens, changing colors, changing resolutions, changing Sprites, controlling Audio, turning Video ON/OFF - at any point of Screen.

The Copper controlled every part of the chipset.
Because of the Copper AMIGA "feeled" like an AMIGA.

In a real AMIGA chipset the Copper can control every part of it.
Also SAGA allows using the COPPER to access all registers.
 
Of course when you had a PC-GFX-CHIP then you could NOT do this.
This means you did loose the AMIGA way to control the GFX chipset.
Those PC chipset did not support the AMIGA Sprites on them, they did not support pixel exact Copper controlled color changes - they were not AMIGA like.

While AHI and such abstractions layers are working - these solutions are slow and inefficient and are no real AMIGA solutions - and are incompatible with the Copper.
 
 
The only way to do it 100% correct - is the original AMIGA way.
This way is having a Copper which can control all GFX features.

 


Ian Parsons

Posts 230
29 May 2018 00:07


SAGA is the only extension to the AGA chipset that's ever actually been implemented and released (I'm vaguely aware of at least one other new chipset being worked on by another party but don't know much about it's status).

CPUs may be faster but only VERY expensive 680x0 accelerators are in the same ball park as the Apollo Core and emulation on fast x86 hardware can go to another level entirely but only Apollo Core has AMMX. The success of the Vampire makes SAGA the logical step for a new universal standard for classic Amiga.


Joe M

Posts 2
29 May 2018 00:18


Great summary, Gunnar! This is what AMIGA is about - and this is what makes it unique. I've never used AHI much for audio - and I never saw the point upgrading to an AMIGA graphics card. SAGA is the future!


Gilles Dridi

Posts 52
29 May 2018 15:10


Hello,
 
AAA was on the edge in 1993 Dev Conf :
 
EXTERNAL LINK 
And some ugly nyx prototype board?
 
 
But a totally different chip set with SIMD? for 3D was design in parallel? :
 
EXTERNAL LINK 
 
What about NatAmi 3D core ?
 
I understood that 68080 with AMMX (SIMD) is used instead ; isn't it ?
 
Of course there's the Vampire team working hard to AAA salvation as excerpted Stephen Jones in a Retro Gaming episode.
 
Someday I will start with HDL but seems there's other way to participate like making software for USB or Ethernet on/for the standalone V4 ...
 
DGILLES


Roman S.

Posts 149
29 May 2018 16:26


@Gunnar - what is 'Amiga way' and 'not Amiga way' depends solely on someone's point of view. I only know what is obsolete, and what is not... Copper controlled color changes become obsolete when we stopped using indexed color screen modes. Or when double-buffering became a common technique. Sprites (besides the mouse pointer sprite) became obsolete with fast blitting capabilities, etc. I know extending the chipset this way is probably fun to the team, but as a  (hopefully) future Vampire user... well, I mainly care about compatibility with current software, as I seriously doubt we will see many serious new games utilizing such exotic chipset features (if they will came at all... remember the Xena/Xorro from the PPC world?).

@Ian, Joe - for the SAGA to be 'universal', it has to be:

1. Universally (or at least - broadly) accepted - didn't happen as of yet and I doubt it will ever happen... read what, for example, Toni Willen writes about Vampire emulation in WinUAE
2. It's specification has to be frozen (and I mean - frozen, removing 'just this tiny piece of bizarre functionality probably no one ever used' is definitely not a frozen state) and available to everyone - AFAIK it didn't happen as of yet

Until both happen, it will be Vampire-only and not universal in any way.


Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
29 May 2018 17:15


Roman S. wrote:

  well, I mainly care about compatibility with current software, as I seriously doubt we will see many serious new games utilizing such exotic chipset features (if they will came at all... remember the Xena/Xorro from the PPC world?).
 

 
  I have x1000 and even Xorro developer board. Problem is that this kind of feature is largerly not documented, standard Xorro tools are not ported to AmigaOS ... One card was made - Sentry Logger and was not much on sale.
 
  In Vamp case, its just an extension of existing feature (e.g. more bit planes in same resolutions, 16-bit sound) so it should not be "hard to use", as well as second chipset is NOT obsolete if done right. For 68000 and 68010 chipset was a blessing, 030+ could do blitts faster then blitter. AGA was good for 020 14Mhz.
 
  In other words if chipset is made to be faster then CPU, it can aid the operation. PC style sound and graphic chips have also proven that too :-)
 
  I agree compatibility is nice, but extending modern things to be done in retro fashio is "HD remake of Amiga" we want :-)
 


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
29 May 2018 17:33


Roman S. wrote:

@Gunnar - what is 'Amiga way' and 'not Amiga way' depends solely on someone's point of view.

 
The Amiga hardware is defined by the AMIGA GFX chipset.
 
As gamer you love the games using the dual playfields.
You will recall that many great Amiga game titles like Lionheart, Shadow of the Beast, and many more used Dual playfield.
 
Smart coders could on AMIGA create in addition an extra playfield with sprites reusing - such sprite playfields are done in "Bubble and Squeak", Rtype,  Risky Woods and several others.
 
As gamer you certainly likes the 50FPS smooth scrolling of the AMIGA.
 
And you liked to many colors that the games had, e.g. like in Lionheart.
 
As coder you would have know that this all the effects were only possible by using the COPPER.
 
The Copper defined the AMIGA GFX chipset.
 
 
The smooth scrolling on AMIGA was possible without wasting huge computing resources.
 
Also the AMIGA audio can play multi channel samples, in different sample rates - without needing CPU power.
 
Of course you can say - that today in the world of 4 GHz PC - you can waste CPU power on anything.
Instead using elegant hardware you can waste CPU to scroll the screen, or spend CPU to create the Audio.
 
 
If you are a coder than you will know that for example AHI on AMIGA can use ridicolous amount of CPU time and plays with lack. And that the original AMIGA audio design is in many ways much more elegant.
 
 
 
The AMIGA hardware offered elegant and efficient solutions.
This is also our goal.

posts 220page  1 2 3 4 5 6 7 8 9 10 11