AGA questions
Joakim Grundwall
to answer these questions:
1. The sprites, how many/depth/size/colour regs?
2. DMA slot allocation, is there some sort of table for the AGA like the one
for ECS found in the HW-ref (this must be _the_ most important page in the
entire manual!)?
3. Will the duble playfield mode now be 4/4- bitplanes?
Any further info on AGA would be nice, please email! :)
Thanks
Jocke, email: f92...@nada.kth.se
Morten Eriksen
> Ok, I might have missed some of the AGA debate but could someone please try
> to answer these questions:
>
> 1. The sprites, how many/depth/size/colour regs?
8 sprites, 64 pix wide, infinitly high (?), don't know about the depth.
256 colour on 32 regs, use some bits in $dff106 to switch between which 'set' to
use.
>
> 2. DMA slot allocation, is there some sort of table for the AGA like the one
> for ECS found in the HW-ref (this must be _the_ most important page in the
> entire manual!)?
No HW-ref for the AGA-chipset. Sad but true.
>
> 3. Will the duble playfield mode now be 4/4- bitplanes?
Yep.
>
> Any further info on AGA would be nice, please email! :)
Check out 'HowToCode' on amiga.physik
>
> Thanks
Anytime.
Morten
Spencer Shanson
>In article <1993Feb10.0...@kth.se>, f92...@alv.nada.kth.se (Joakim Grundwall) writes:
> > Ok, I might have missed some of the AGA debate but could someone please try
> > to answer these questions:
> >
> > 1. The sprites, how many/depth/size/colour regs?
>
>8 sprites, 64 pix wide, infinitly high (?), don't know about the depth.
8 sprites, 16, 32 or 64 pixels wide, no height limitation, and 2 bitplanes deep
(4 if attached).
The resolution of the sprites can be 140ns, 70ns or 35ns pixels, independant of
the display they are over.
>256 colour on 32 regs, use some bits in $dff106 to switch between which 'set' to
>use.
>
No No No NO NO!
Even numbered sprites can use any bank of 16 colours. So can odd numbered
sprites, but they can use a different bank ('A' and ECS sprites always used
colours 16-31). You can set these, together with the sprite resolutions on a
ViewPort by ViewPort basis with the graphics function VideoControl(). DO NOT HIT
THE HARDWARE. The information above is incorrect, non-system friendly, and even
if it were correct, it will not work in the future. Guaranteed!
> >
> > 2. DMA slot allocation, is there some sort of table for the AGA like the one
> > for ECS found in the HW-ref (this must be _the_ most important page in the
> > entire manual!)?
>
>No HW-ref for the AGA-chipset. Sad but true.
Yes there is a table, but it's unpublished.
> >
> > Thanks
>
>Anytime.
>
>
>Morten
--
---------------------------------------------------------------------------
Spencer Shanson - Amiga Software Engineer | email: spe...@commodore.COM
| or uunet!cbmvax!spence
All opinions expressed are my own, and do not | Bix: sshanson
(necessarily) represent those of Commodore. | "Work is the scurge of
| the drinking class"
| - Oscar Wilde
Morten Eriksen
> In article <1993Feb11....@ugle.unit.no> mor...@Lise.Unit.NO (Morten Eriksen) writes:
> >256 colour on 32 regs, use some bits in $dff106 to switch between which 'set' to
> >use.
> >
> No No No NO NO!
>
> Even numbered sprites can use any bank of 16 colours. So can odd numbered
> sprites, but they can use a different bank ('A' and ECS sprites always used
> colours 16-31). You can set these, together with the sprite resolutions on a
> ViewPort by ViewPort basis with the graphics function VideoControl(). DO NOT HIT
> THE HARDWARE. The information above is incorrect, non-system friendly, and even
> if it were correct, it will not work in the future. Guaranteed!
Hey! Nobody was talking about how to set the sprite color-regs. The question was
how to set the colors for 8 bitplanes (256 colors) with only 32 colorregs.
And... I WILL HIT THE HARDWARE! I WILL HIT THE HARDWARE! I WILL HIT THE HARDWARE!
(And I don't care if "it" works in the future or not).
Morten
Lars Holmgren
>Hey! Nobody was talking about how to set the sprite color-regs. The question was
>how to set the colors for 8 bitplanes (256 colors) with only 32 colorregs.
>And... I WILL HIT THE HARDWARE! I WILL HIT THE HARDWARE! I WILL HIT THE HARDWARE!
>(And I don't care if "it" works in the future or not).
I think that they might have done something like:
every colour register is 16 bits
in older versions 12 bits were used to hold 4 bit R,G & B
->4 bits left!
* use the msb (bit 15) to tell if the write is intended to affect
(1) the LOW nibble or (0) the HIGH nibble of the 3*8 bits
this makes old programs work OK (only high bits are set)
* use bits 14-12 to tell the hardware which BANK of 32 colours that
is ment (32*8=256 colour-"registers") Again, old programs will
work because they use bank 0!
This might be a solution!
---------------------------------------------
Lars Holmgren - dat9...@ludat.lth.se
Topasvägen 32 (+46)(0)46- 70 99 02
S-240 21 Lo"ddeko"pinge (I hate oe!)
Christoph Feck
Get the file HowToCode.txt from aminet. It is in the text/doc/ directory
and tells you, how to hit AGA chips. However, this information is based on
resourcing the operating system and programs are likely to fail on future
chip sets. Get it and be happy with it!
--
Christoph
===========================================================================
| // | Christoph Feck, 6750 Kaiserslautern |
| \X/ A3000/030/25/6MB/540HD/OS2.04 | E-Mail: c_f...@informatik.uni-kl.de |
===========================================================================
"It is better to dream about an Amiga, than to have a PC."
Pahl Melin
[stuff deleted]
>The resolution of the sprites can be 140ns, 70ns or 35ns pixels, independant of
>the display they are over.
>Even numbered sprites can use any bank of 16 colours. So can odd numbered
>sprites, but they can use a different bank ('A' and ECS sprites always used
>colours 16-31). You can set these, together with the sprite resolutions on a
>ViewPort by ViewPort basis with the graphics function VideoControl(). DO NOT HIT
>THE HARDWARE. The information above is incorrect, non-system friendly, and even
>if it were correct, it will not work in the future. Guaranteed!
What parameters do you supply the funktion VideoControl() to change the pixel
resolution and colour bank of the sprites? I have _not_ found this information
i the RKM's. I (and many more) need this information to be able to write AGA-
games _without_ hitting the hardware...
Thanks,
Pahl (wad) Melin d90p...@und.ida.liu.se
Ryds Alle 11:108 // Tel: 046 (0)13-14 15 18
S-582 51 Linkoping //
Sweden \x/
Chris Green
>Ok, I might have missed some of the AGA debate but could someone please try
>to answer these questions:
>
>1. The sprites, how many/depth/size/colour regs?
>
where in the palette the sprite colors come can be sent to any 16 color
boundary, independently for even and odd sprites.
>2. DMA slot allocation, is there some sort of table for the AGA like the one
> for ECS found in the HW-ref (this must be _the_ most important page in the
> entire manual!)?
>
It's the same as ECS. The only difference is that there are some new
fetch patterns for higher bandwidth modes.
>3. Will the duble playfield mode now be 4/4- bitplanes?
Yes. It's also possible to set the areas of the palette that each
playfield comes from.
--
*-------------------------------------------*---------------------------*
|Chris Green - Graphics Software Engineer - chr...@commodore.COM f
| Commodore-Amiga - uunet!cbmvax!chrisg n
|My opinions are my own, and do not - icantforgettheimpression o
|necessarily represent those of my employer.- youmadeyouleftaholeinthe r
|"A screaming comes across the sky..." - backofmyhead d
*-------------------------------------------*---------------------------*
Chris Green
>What parameters do you supply the funktion VideoControl() to change the pixel
>resolution and colour bank of the sprites? I have _not_ found this information
>i the RKM's. I (and many more) need this information to be able to write AGA-
>games _without_ hitting the hardware...
#define VTAG_PF1_BASE_SET 0x8000002a
palette offset for playfield 1
#define VTAG_PF2_BASE_SET 0x8000002b
palette offset for pf2
#define VTAG_SPEVEN_BASE_SET 0x8000002c
pal offset for even sprites
#define VTAG_SPODD_BASE_SET 0x8000002d
pal offset for odd sprites
#define VTAG_BORDERSPRITE_SET 0x8000002f
makes sprites appear even when no display window
#define VTAG_BORDERSPRITE_CLR 0x80000030
#define VTAG_SPRITERESN_SET 0x80000031
pixel res of sprites
#define VTAG_IMMEDIATE 0x80000037
makes videocontrol changes modify the copper list
immediately instead of at next makevport. you pass a pointer
to a longword variable in the ti_data. This variable will be
set to true if it is necessary to remake the viewport. copper
pokes are fast enough for animation.
#define VTAG_FULLPALETTE_SET 0x80000038
tells MakeVPort to load all 256 colors in the copper-list,
regardless of what depth the viewport is, etc. This is necessary
for most of the color banking features.
Matthias Scheler
[usefull stuff deleted]
It's nice that you post this stuff and the docs for (G|S)etRGB32(), but I think
it would be easier and better to release the 3.0 includes and autodocs to the
public. So everybody could use the new features without having half of the
V39 includes in his source code.
--
Matthias Scheler tr...@uni-paderborn.de
University of Paderborn (Germany)
Gregory R Block
: > What parameters do you supply the funktion VideoControl() to change the pixel
: > resolution and colour bank of the sprites? I have _not_ found this information
: > i the RKM's.
: It's in mine: Includes & Autodocs (3rd ed) graphics.library/p127.
It shouldn't be: The tags he's talking about are in 3.0, to control the
AGA's varied-resolution sprites, and controllable color banks.
I&A 3rd ed. is 2.0(2?) based.
Greg
--
(: (: (: (: Have you overdosed on smileys today? Why NOT!?! :) :) :) :)
(: "Frankly, we doubt he could sell his body to science." :)
(: -Dan Barrett, and/or Fluffykins :)
(: (: (: (: (: (: (: (: (: (: (: (: :) :) :) :) :) :) :) :) :) Wubba :)
Philippe Berard
>
> It's nice that you post this stuff and the docs for (G|S)etRGB32(), but I think
> it would be easier and better to release the 3.0 includes and autodocs to the
> public. So everybody could use the new features without having half of the
> V39 includes in his source code.
I've heard that CBM France should release them to the public soon.
Sincerely,
-- Philippe
.----------------------------------------------------------------------------.
| Philippe Berard (French Amiga User) | UseNet : am...@amipb.gna.org |
| "They hold a cup of wisdom, | -> Please don't send mails |
| But there is nothing within" (Kate Bush). | >50 Ko ! |
`----------------------------------------------------------------------------'
Andy Duplain
>In article 47...@ugle.unit.no, mor...@Lise.Unit.NO (Morten Eriksen) writes:
>
>* use the msb (bit 15) to tell if the write is intended to affect
> (1) the LOW nibble or (0) the HIGH nibble of the 3*8 bits
> this makes old programs work OK (only high bits are set)
>* use bits 14-12 to tell the hardware which BANK of 32 colours that
> is ment (32*8=256 colour-"registers") Again, old programs will
> work because they use bank 0!
Mmm, this sounds feasible; if you run "PowerMonger" on an A1200
the colours are all screwed, but it otherwise appears to work OK;
maybe they are neglecting to clear the 4 MSBs, and thus the colour
definitions are being spread around different colour banks!?!?
--
Andy Duplain, BT Customer Systems, Brighton, UK. dup...@rtf.bt.co.uk
#define DISCLAIMER My views and opinions are my own, and not my company's
Amiga Utilities
>
>[usefull stuff deleted]
>
>It's nice that you post this stuff and the docs for (G|S)etRGB32(), but I think
>it would be easier and better to release the 3.0 includes and autodocs to the
>public. So everybody could use the new features without having half of the
>V39 includes in his source code.
I don't know about the rest of the world, but this material is available
from C= Australia. They charge $40 for the Includes, Autodocs & programming
info and $25 for KS+WB 3.
I have already sent my money to them :-)
Peter.
/// am...@cs.unsw.oz.au
/// The amiga utilities account.
\\\/// University of New South Wales
\XX/ Sydney, Australia
Christoph Feck
> I don't know about the rest of the world, but this material is available
> from C= Australia. They charge $40 for the Includes, Autodocs & programming
> info and $25 for KS+WB 3.
^^^^^^^^^^^^^^^
Dream on.
fhei...@desire.wright.edu
>> Hi Chris,
>>
>>[usefull stuff deleted]
>>
>>It's nice that you post this stuff and the docs for (G|S)etRGB32(), but I think
>>it would be easier and better to release the 3.0 includes and autodocs to the
>>public. So everybody could use the new features without having half of the
>>V39 includes in his source code.
>
> I don't know about the rest of the world, but this material is available
> from C= Australia. They charge $40 for the Includes, Autodocs & programming
> info and $25 for KS+WB 3.
So I can send C= (US) $25.00 and ask for NATDEV30 and they'll know
what I want?
Fred Heitkamp, ** Not an organization **
Amiga Utilities
>In article <1993Mar1.2...@usage.csd.unsw.OZ.AU>, am...@cse.unsw.edu.au (Amiga Utilities) writes:
>
>> I don't know about the rest of the world, but this material is available
>> from C= Australia. They charge $40 for the Includes, Autodocs & programming
>> info and $25 for KS+WB 3.
> ^^^^^^^^^^^^^^^
>Dream on.
No need to dream. This is a disk update only. What you get is
the kickfiles and distribution disks, that's it. Remember,
this is meant for programmers who need to get their software
going now, not wait for an official upgrade kit with ROMs and
user manuals.