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 

Peeri the Sunlight

Posts 71
12 Aug 2018 23:26


Finally I was taking some time and made my first test to SAGA graphic tests... what I made:
 
  - Opening custom frame buffer by messing registers Apollo wiki EXTERNAL LINK was failing miserable. (I did only got no display in my lousy AOC TV)
  - Controlling SAGA registers $dff1EC, $dff300...  from Copper... Fail, as I was presuming.
 
  so bit more system friendly: (SUCCESS!)
  - Open new screen of SAGA display (800x600x8) (intuition: OpenScreen)
  - Changed screen to new "bitplane" pointer (own nice frame buffer, space where i can mess what i wish) move.l a0,$dff1ec
  - Changed palette ($dff300-->) there is error in wiki the color format is $rrggbbaa (not $aarrggbb)
  - Some old rutines to draw something silly to my frame buffer
  - double buffering with changing $dff1ec, works fine :)
  - graphics.library WaitTOF() is taking top of field from original Amiga output (what is in this case just one color gray)
  - tried to change color palette middle of screen (was bit failing because my screen is 60hZ and WaitTOF is 50hZ so place is not static) but generally it has all potential to work)
  - I cam use Amiga screen as raster time meter, before inner loop move.l #$0,$dff180 and after inner loop move.l #$ccc,$dff180 and I will see in my monitor attached Amiga video port leftover raster time. (this keeps sync ok with WaitTOF)
 
  Early comments. Coding was so fun and easy :D .. you need still do some additional register available. at least:
  - $dff1ec r/w now it is just w (probably other screen registers as well, to return back after heavy stabbing ;) )
  - Read vertical beam position (like $dff006)
  - BPLMOD ($dff108 and 10A) to set Modulo for Saga play fields (so that negatives modulos work as well :D )
  - Saga Copper :)
  - Saga Blitter :)
      - line draw (xiaolin wu's line algorithm)
      - copy with edge (http://mlab.uiah.fi/~kkallio/antialiasing/)
        (Kiia has made fabulous work)
 
  Currently used Asmone, nice old and familiar, no AMMX nor Apollo added commands.
 
  Next thing try to get VASM up and running in my Amiga. And then try to make some routines with AMMX.. ;D or try to find opt code for ammx commands and make some macro for them...
 
  If something worth of release will come, I upload them to somewhere...
 
  But seriously it is so fun to code Amiga... try every one your self. (if you cant, here is small text read: EXTERNAL LINK )


Niclas A
(Apollo Team Member)
Posts 219
13 Aug 2018 06:29


Have you looked here?
EXTERNAL LINK 


Peeri the Sunlight

Posts 71
13 Aug 2018 09:03


Thanx, anyway I have coded Amiga (even commercial products) from 1998-> 2006.. Now again after short break (12years).
 
  Now I want to get rid off RTG, AHI etc., and try to get things in Amiga way. (stabbing hardware ugly and big NO NO for all layers between my program and hardware :D )
 


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
19 Aug 2018 18:56


Peeri the sunlight wrote:

  - Read vertical beam position (like $dff006)

You can read BEAMPOS on register
$DFF204 / $DFF206

Peeri the sunlight wrote:

  - BPLMOD ($dff108 and 10A) to set Modulo for Saga play fields (so that negatives modulos work as well :D )

Modulo register is $dff1e6

Cheers Gunnar



Peeri the Sunlight

Posts 71
19 Aug 2018 21:16


Danke! Thanks!

You are :D the best!


Philippe Flype
(Apollo Team Member)
Posts 299
22 Aug 2018 20:58


@Peeri
 
    - Opening custom frame buffer by messing registers Apollo wiki EXTERNAL LINK was failing miserable. (I did only got no display in my lousy AOC TV)
 
 
 
 
  ---
 
  The registers are corrects but there is one important needed thing. When opening a new screen (by hardware banging!) you MUST tells SAGA chip which PLL to use. This is a sequence of values for a given bandwidth (20MHz, 25MHz, etc...).
 
  The SAGA rtg driver use such initialization, for example.
 
  This part is undocumented but is public, can be checked from the very first rtg driver code, since beginning, available on github.
 
  EXTERNAL LINK   

  The SAGA chipset, in current state is designed to work on any possible monitor, through the Picasso96mode resolution tool. Keep in mind, that using one own res does not guarantee you that your code will work everywhere for everybody, because it depends on the end-user monitor specs. That's why it is not much documented. Banging is fun, i agree, but here, opening SAGA screen by hand is quite un-modern practicing. Will work for you but not for another.
 
  That's why such lowlevel inits are generally 'reserved' to the graphic driver, and yes, sorry, it force coders to be more system-friendly.
 
  That said, now you are warned, nothing prevents to play with, as i like do myself. If you need more infos, i can share.


Philippe Flype
(Apollo Team Member)
Posts 299
22 Aug 2018 22:12


Let's show you an example :
 
EXTERNAL LINK 

In this example, it use a quite standard 640x480 modeline / bandwidth. That is the one used in the BootPic, so it is good on most monitors, so far.


Gregthe Canuck

Posts 274
22 Aug 2018 23:15



Is there any value in providing any support for VESA modes? Maybe just in an include file/macro/thingy that sets up the chipset for these modes?


Philippe Flype
(Apollo Team Member)
Posts 299
23 Aug 2018 00:09


You have the VESA modelines here :

EXTERNAL LINK


A1200 Coder

Posts 74
23 Aug 2018 19:43


Philippe Flype wrote:

Let's show you an example :
 
  EXTERNAL LINK 
 
  In this example, it use a quite standard 640x480 modeline / bandwidth. That is the one used in the BootPic, so it is good on most monitors, so far.

Thanks for the example. This looks (to me) more complex than initiating AGA screens with programmable screenmodes. Would have thought that selecting screenmode (#bitplanes/chunky + resolution), setting screen modulos, programmable screenmode values (SAGA_SetModeline), and initiating color regs (SAGA_SetColorMap) would be enough. In particular, what does this SAGA_SetPLL do?



Philippe Flype
(Apollo Team Member)
Posts 299
23 Aug 2018 22:51


You dont have to compare with OCS/AGA. It is not comparable. If you would like compare, do it against how you would do it for any other 'RTG' graphics cards (Picasso4 for example), but not the Amiga chipset. SAGA (as it is in GOLD2.x series) is NOT a planar chipset. Takes SAGA as a graphic card (!)

If you understand well what does Picasso96Mode, then this is how you could figures it :

EXTERNAL LINK 
1 => PIXEL FORMAT
2 => CLOCK / PLL (SAGA_SetPLL)
3 => DOUBLE SCAN flags
4 => MODELINE

So, SAGA_SetPLL() is for initialising the clock / bandwidth, in MHz. This one depends a lot on your monitor spec. It speaks to the core (using some SPI-like protocole) and tells which values to use for a desired MHz.

The example offers the needed code for a ready-to-use 640x480x8 screenmode, in which you can a) takeover the system b) direct draw without any gfx driver. Generally nobody wants to do this (even the demomakers).

For a pure gfx Amiga approach (planar, copper, ...), that's what the GOLD3.x serie is intended for.


A1200 Coder

Posts 74
24 Aug 2018 07:52


Philippe Flype wrote:

You dont have to compare with OCS/AGA. It is not comparable. If you would like compare, do it against how you would do it for any other 'RTG' graphics cards (Picasso4 for example), but not the Amiga chipset. SAGA (as it is in GOLD2.x series) is NOT a planar chipset. Takes SAGA as a graphic card (!)

Ok, I understand now. But this doesn't look so good from a hardware programmer's point of view. I don't need to use some SPI-like protocol to set up a VGA 640x480 60 Hz screen with e.g. 8 bitplanes under AGA chipset. I understand that an FPGA needs some protocol to communicate with other chips, but this complexity should be hidden somewhere, so that users see just some bplcon & other HW registers, where resolution and other values (chunky/planar) are selected and screen goes up. Maybe this is planned in some later releases (GOLD3), I don't know.




Peeri the Sunlight

Posts 71
24 Aug 2018 07:58


Thanx Flype! I will try when got back home!
Rolling my sleeves for Gold3 ... But sure still learning vampire and not indendt to release anything soon, so now I don't care how stabile and how well it is compatible.
Just having fun.


Philippe Flype
(Apollo Team Member)
Posts 299
24 Aug 2018 17:29


@A1200 Coder

Yes, GOLD3, as said. I only explain how it is. I do not judge, and didn't designed anything core side. Just, that is how it is, for a RTG chip approach. As i explained, such code is handled driver side, so it is already 'hidden' implementation since people SHOULD only use OS openscreen way.


Denis Markovic

Posts 4
29 Aug 2018 21:04


A1200 coder wrote:

Philippe Flype wrote:

  You dont have to compare with OCS/AGA. It is not comparable. If you would like compare, do it against how you would do it for any other 'RTG' graphics cards (Picasso4 for example), but not the Amiga chipset. SAGA (as it is in GOLD2.x series) is NOT a planar chipset. Takes SAGA as a graphic card (!)
 

 
  Ok, I understand now. But this doesn't look so good from a hardware programmer's point of view. I don't need to use some SPI-like protocol to set up a VGA 640x480 60 Hz screen with e.g. 8 bitplanes under AGA chipset. I understand that an FPGA needs some protocol to communicate with other chips, but this complexity should be hidden somewhere, so that users see just some bplcon & other HW registers, where resolution and other values (chunky/planar) are selected and screen goes up. Maybe this is planned in some later releases (GOLD3), I don't know.
 

I would be surprised if this wouldn't change in GOLD3 for the new Amiga-like modes (i.e. to have more Amiga-like way of accessing GFX HW like you described, at least as an option), but let's see.



Thellier Alain

Posts 141
30 Aug 2018 09:03


Hello

I dont see the point to not use the OS for opening a screen
As doing this way do not prevent yourself to poke in the pixels the demoscene way




Peeri the Sunlight

Posts 71
30 Aug 2018 21:48


thellier alain wrote:

Hello
 
  I dont see the point to not use the OS for opening a screen
  As doing this way do not prevent yourself to poke in the pixels the demoscene way
 
 

Maybe because you don't like challenges :D. The point is not what is easy, what is common way to do it, the point is to do it because it exist :)
I'm a kid of Vic20... and soon after c64, the only way is make something is to use machine how it is not designed to operate. If i win couple of cycles CPU time, by disabling DMA, interupts, multitasking, and trapping processor to supervisor mode, I gladly check if there is something "fun"...

Of course programs to be released should be with jsr SetAPen(a6) and then jsr WritePixel(a6)... (woow)

Another point is that do we want to use that only stone (nice and most advanced processor) to do all the work? Amiga is designed to operate with co-processors (Copper, Blitter and Paula) and in (soon) future I'm more than happy let the copper keep my SAGA screen in order, (mixed Chunky and Planar playfields) (Don't want system to interrupt with it)


A1200 Coder

Posts 74
31 Aug 2018 08:55


thellier alain wrote:

Hello
 
  I dont see the point to not use the OS for opening a screen
  As doing this way do not prevent yourself to poke in the pixels the demoscene way
 
 

Having access to screen pixels is not enough. The reason is that you may also want to use copper for doing raster based effects (colors, bitplanes, resolution, sprites), and here the timing is critical. AmigaOS also does not support copper usage very well (especially the AGA registers, which e.g. allows changing several colors with a single instruction), and I suppose the SAGA copper has even less support from OS.



Thellier Alain

Posts 141
04 Sep 2018 13:36


I agree: but lots of those copper tricks used to enhance résolution or the colors count will become pointless on a SAGA full screen in true color ;-)




Gunnar von Boehn
(Apollo Team Member)
Posts 6207
04 Sep 2018 13:49


thellier alain wrote:

I agree: but lots of those copper tricks used to enhance résolution or the colors count will become pointless on a SAGA full screen in true color ;-)
 

Copper is super.

Copper can be used for many things also on truecolor screens.

Copper can be used to scroll and create "water" effects.
Copper can be used to mirror a region.
Copper can be used for picture in picture effect / or for splitscreen.



posts 27page  1 2