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
Information about the Apollo CPU and FPU.

SAGA Video Coodingpage  1 2 

Samuel Crow

Posts 424
05 Sep 2018 13:03


Re:Hardware banging vs. OS functions

The biggest problem with using the AmigaOS functions for setting things up is that AmigaOS barely even supported their own chipset.  MrgCop() is the only Copper support function worth mentioning and it is buggy and slow.

Now that we have AROS 68k as open-source we can make the OS functions not suck as bad.  I'm trying to figure out ways to make the drivers better for any chipset right now.

One thing is to make a new MrgCop() that supports relative offsets in the CWait() function so that the Copper can field the register writes to the Pamela core during the visible display portion of it's cycles to make audio less of a burden on the CPU.  A reason this would also be better is that a Copper interrupt can drive the CPU interrupt for the music player according to the resolution of the horizontal blank instead of the vertical one.  That's 15 KHz on PAL or NTSC and has little regard for scan rate differences other than that.  (Of course, the PLL thing will vary the HBlank still but at least that will be the same on all SAGA systems.)

Anther thing that could be done with AROS is to add "Corkscrew refresh tube scroller" mechanisms like the ones Georg outlined in his Scrolling Trick archive on the Aminet.  Once included in the drivers it would never need to be recoded from scratch.  Of course similar ideas would need to be coded for other chipsets for the other supported platforms but there are texture and shader tricks on the PC and RasPi that are equivalent.

If anyone wants to comment on what the drivers of AROS should include that aren't there already, we should start a separate thread to discuss it.


Mallagan Bellator

Posts 393
05 Sep 2018 21:17


On my A1200 with 040 @40MHz, I use a voodoo 3 card with mediator.
 
  The first time I booted into Workbench on a voodoo 3 mode, I was happily surprised at how much faster my entire Amiga was.
  My conclution was (ofcourse) that this setup was way faster in hardware than using the AGA display chips, because to me, it seemed like the chips on the motherboard are a lot slower (and this is true)
 
  Still, playing classics like, let’s say Super Frog? Pinball dreams/fantasies/illusions? Yes, those games run pretty fast even on an A500, and I was using an A1200.
 
  Bearing this in mind, now consider P96 to be a layer of software over the hardware. It’s STILL FASTER!
 
  And not only that, even if I ran a res of 1280x1024 or higher, in 24 bit color mode (yes, I know the chip on voodoo 3 doesn’t support real 24 bit, but it’s still more than 16 bit, which still looks great) it was still WAY faster.
 
  Call me bold if you like, but I dare say that SAGA running through P96 is fast enough to make some pretty good looking games run pretty smoothly.
 
  And yes, the copper is heavilly utilized in classic games like those mentioned, and I don’t know how well (or if at all) the copper and/or blitter works with P96.
  If they do work great together, the new games made for Vampire with SAGA have all chances of being more than a lot better than the classics, even going through P96.


Peeri the Sunlight

Posts 71
06 Sep 2018 08:25


Mallagan Bellator wrote:

    Call me bold if you like, but I dare say that SAGA running through P96 is fast enough to make some pretty good looking games run pretty smoothly.
 
  And yes, the copper is heavilly utilized in classic games like those mentioned, and I don’t know how well (or if at all) the copper and/or blitter works with P96.
  If they do work great together, the new games made for Vampire with SAGA have all chances of being more than a lot better than the classics, even going through P96.

Copper does not work at all in P96, (at least for screen handling) As Gunnar and other earlier mention, Copper is Very nice coprocessor even with only 3 functions.
And in my opinion RTG or P96 display is only screenbuffer, what you use as any computer screenbuffers, without Amigas fantastic possibilities.
Classic Amiga System is using copper for example draggable screens, to perform such thing trough P96 will be extremly time consuming.
Also copper make possible to change screenbuffer middle of the screen, all kind of plasma effects and display effects without huge consumption of processor time... There is numerous of possibilities.  SCALA MM uses most of the wipeouts just copper functions.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
06 Sep 2018 08:29


Peeri the sunlight wrote:

  Copper does not work at all in P96, (at least for screen handling)
  ..
  And in my opinion RTG or P96 display is only screenbuffer, what you use as any computer screenbuffers, without Amigas fantastic possibilities.
 

 
This is correct.
The cause is not a limitation of SAGA but a limit of P96.
 
P96 simply never expected that the Copper can control RTG screen modes.
The SAGA registers are in DFFxxx range and can be fully controlled by Copper - like all real Amiga chips. 
This means you can scroll screen, or pulldown screen.


Thellier Alain

Posts 141
06 Sep 2018 09:34


You can pull down screens with RTG : I got right here a Sam460 and the screen is draggable
Just for information : nothing copper related in fact

Also I agree with Gunnar: Copper is super for all things related to screen position and display pointers (distorsion,mirror,pip,etc...)




Mallagan Bellator

Posts 393
06 Sep 2018 22:37


My point was that P96 is fast enough for games, and I bet even for games in pretty nice resolutions and color depths.

Maybe I should use less words, I might tend to over explain my point and get misunderstood


Philippe Flype
(Apollo Team Member)
Posts 299
07 Sep 2018 07:12


P96 is always fast enough for games and demos since most only calls the p96/intuition openscreen() and then the coder directely bang the video framebuffer. No one use in games or demos primitivees like drawline() or setpixel() but directely pokes the video memory. This methodology is sytem-friendly enough, especially when the screen opened is a palette-based (8bits) pixformat.

posts 27page  1 2