Hi, i have some questions

  Were I can find
1. Docs, soft, SDK for GBA?
2. Updated WWW GBA sites?
3. Big N's engeeners, that make GBA like (_|_)
:)))

And also, anybody interesting for develop new, small
computer(GB/C/A, Palm etc.) oriented programming language?

Heh, sorry, english so hard for me...

Thanks
---------------
DWORD is not enough

I assume some one, some where, will, at some time, release some thing, that
some what resembles a crib sheet too no doubt...

;-)


----- Original Message -----
From: "Web Dreamer" <rownik@...>
To: <gbadev@egroups.com>
Sent: Wednesday, August 09, 2000 7:55 PM
Subject: Re: [gbadev] Re: GBA Specs


> >Sounds very cool.  I can't wait to get my hands on a kit.  Thanks for
> >all the info.
> >
> >--
> >PoV
>
>
> More info is coming very soon. As the official dev docs ARE copyrighted
and
> protected and all that stuff of Nintendo, It would be awfully foolhardy to
> enganger the scene by releasing the official docs ot the dev community.
> SO... we here at CindeKat Studios have been carefully reverse engineering,
> and screwing around with things to bring you a Pandoc-like text for the
> GBA...Soon, my children... very soon. MWA HA HA HA HA... *cough cough*
> erhrm...
>
>
> -WD
> ________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
>
>
>
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>
>

In case anyone missed them, there are two sets of GBA game screenshots up
at pocket.ign.com- so for those who have yet to see its graphical prowess
in action, check 'em out!

>Sounds very cool.  I can't wait to get my hands on a kit.  Thanks for
>all the info.
>
>--
>PoV


More info is coming very soon. As the official dev docs ARE copyrighted and
protected and all that stuff of Nintendo, It would be awfully foolhardy to
enganger the scene by releasing the official docs ot the dev community.
SO... we here at CindeKat Studios have been carefully reverse engineering,
and screwing around with things to bring you a Pandoc-like text for the
GBA...Soon, my children... very soon. MWA HA HA HA HA... *cough cough*
erhrm...


-WD
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

--- In gbadev@egroups.com, "Web Dreamer" <rownik@h...> wrote:
> >1. How much Ram the GBA has (compared to the 32k the GBC has)?
>
> I believe it's down to 32K of work ram, and now 256K on cart...
strange as
> it sounds. There is also the video memory, registers, etc.

Alrighty.  Are you guys sure the 256k is on the Cart?  Or is it a
possibility that 32k is like a CPU cache or just High RAM and the
256k
is something more like SIMM's or DIMM's on your PC (but of course not
replaceable). It does sound silly to have the ram on the cart (mainly
because it would be expensive for production costs of the cart, if
every cart had to have 256k of ram on it for the GBA.).

> >2. How many Sprites the GBA can display (compared to the GBC 40)?
>
> 128 on screen at 64x64 size, and 128 PER SCANLINE at 8x8 size.

Nice.  So would that also mean if I had 16 64x64 sprites (128 8x8's
wide total), I'd be at my 128 sprite limit (hehehe...  oh boy.  I
don't see how I've lived so long with the GB's 10 sprite limit. :)
:).)?

> >3. What sprite modes are available (i.e. 8x8, 8x16, 16x16, ...)?
>
> 16 different sizes from 8x8 to 64x64.

Very nice.  Is the mode selectable via 4 bits in the sprites
attributes, or is it like the SNES with 1 bit in attributes and 2
registers that select the 2 sizes to use?

> >4. The Attributes Setup (i.e. what is in it, how many bytes each
> >sprite takes up)?
>
> 4 bytes, including flags for h and v size, mosaic, color mode,
> semi-transparent... etc etc etc

Is that 4 bytes for everything, or just the attributes?  Where does
the Scaling and Rotating fit in (please say attributes :), that would
kick so much!)?

> >5. How tiles are stored in memory (i.e. like GBC, but with 4 planes
> >instead of 2)?
>
> um... brain just went blank.

Alright.  GBC stores each line of tile data this

bits
0 1 0 1 0 1 0 1 <- row 1 of 2
0 0 1 1 0 0 1 1 <- row 2 of 2

these rows or "planes" are mergerd to produce the following color
values.

0 1 2 3 0 1 2 3

8 of these produce your standard 8x8 tile.  Now the SNES did the same
thing, but with 4 rows or "planes".  Does the GBA do this too (for
the
16 color mode)?

> >6. The number of "Backgrounds" or "layers" the GBA has (compared to
> >the background and window the GBC has, and anything fancy about
them)?
>
> um 4, IIRC. Each scrollable, 2 rotateable/scalable. OBJ's moveable
between
> layers.

Very Cool.

> >8. How the Palettes are set up (i.e. how you load them, is it like
> >the
> >GBC with 2 registers you work with)?
>
> Regular old palette ram. In flavors of 256 colors in 1 palette or
16
colors
> in 16 palettes... with, of course, color 0 being transparent on the
display,
> like GBC OBJ's.

Are there seperate palettes of 256 for Background and Sprites (like
the GBC)?

> >9. Anything else really cool (such as the priority bit of the
> >attributes on the GBC, If individual sprites can have an Alpha
> >Channel
> >applyed to them, If Sprites can be rotated or scalled, etc...)?
>
> Well, plenty of things... BG maps ranging in size from 128x128 to
1024x1024
> with wraparound, mosaic effects, alpha blending (not too sure how
well it
> works yet), hardware LCD fade control, windows... itsa gonna be a
really
> nice leetle plataform to geta you hands on...;-)

Sounds very cool.  I can't wait to get my hands on a kit.  Thanks for
all the info.

--
PoV

>Ok. This confuses me, the data bus to cart memory is only 16-bit,

Well, I actually hear that the cart ram data bus is only 8-bits, but I could
be wrong...

>What strategies are people using so far for they code & data? Not

I'm not too sure, I haven't actually disassembled anything yet to take a
look, as I'm still learning ARM, though Yoshi was done in C....

>UART makes it a lot simpler. Plus using a minimum of 256KHz is a good thing
>too.

Very much so... Serial on the GBC was just more trouble than it was worth.
LOL


> > 11) Change in maximum simultaneous colouring numbering - Changing to
>5:5:5
> > (32768 colours) from 5:6:5 (65536 colours)
>
>Now I wonder why they chose to do that... Simpler hardware decoding logic
>perhaps.

Well, the way the color was laid out was a bit interesting...
G:R:R:R:R:R:G:G:G:G:G:B:B:B:B:B
Just eliminating that leading G bit and fixing it low will probably make the
LCD controller's job easier (more time for other drawing?) And not like we
are really going to miss 32768 extra shades... 32768 is a hell of alot for a
handheld. Playing the gamegear, I am quite satisfied with the color
capabilites... and it had what, 256 colors from a 2048 palette? We've got
more colors to work with without hardware tricks than the GBC could do with
lots of hardware tricks. hehehe

-WD
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Well, I thing they are ok, but they are still playing around with the
hardware, so the one I have will not be the final version

-----Ursprüngliche Nachricht-----
Von: Joshua Meeds [mailto:dreamer@...]
Gesendet: Montag, 7. August 2000 01:37
An: gbadev@egroups.com
Betreff: [gbadev] Happy with devkits?


Anyone out there who has had some time to play with the AGB dev kits, are
you happy with them, or do they leave something to be desired?




unsubscribe: gbadev-unsubscribe@egroups.com

> 1) WRAM decrease from 48K to 32K

Damn. I had also heard that too but was hoping it wasn't true. Sheeit!

> 2) Installation of 256K of CPU external WRAM

Ok. This confuses me, the data bus to cart memory is only 16-bit, right? And
I'm presuming this 256KB is on the cart also, so what happens when a company
decides to perform a cost cutting measure and remove the RAM from a cart and
consequently your entire game is running in 16-bit Thumb mode. Or worse, you
have to do the copy code function down to RAM and execute from there, ala
N64.

What strategies are people using so far for they code & data? Not working on
a GBA title at the moment I haven't thought about the best way to tackle
these issues. Are you copying down to WRAM and executing there?

> 3) Elimination of the IR communications function (but there will be an
> adapter accessory)
>
> (I personally think #3 was a bad idea)

Yeah, pretty bad, but IR was never used that much anyway. I'd rather see a
good serial comms support in hardware and a bundled cable than an IR port.
(The bundled cable is just pure conjecture).

>
> 4) Change of serial comm to 32bit from 16bit.  SCCNT_L register interal
> shift clock will change: "0" 8KHz -> 256 KHz, "1" 256KHz -> 2MHz.  Adding
> UART-based comms.  Compatability with N64/Dolphin controller port

This is at least good. No more faffin' around handling your own clocking.
UART makes it a lot simpler. Plus using a minimum of 256KHz is a good thing
too.

> 11) Change in maximum simultaneous colouring numbering - Changing to 5:5:5
> (32768 colours) from 5:6:5 (65536 colours)

Now I wonder why they chose to do that... Simpler hardware decoding logic
perhaps.

>From: "Otaku" <otaku@...>
>Reply-To: gbadev@egroups.com
>To: <gbadev@egroups.com>
>Subject: Re: [gbadev] GBA Specs
>Date: Sun, 6 Aug 2000 15:17:50 -0700
>
>Is it confirmed that the WRAM is 256KB now? Or was that just a wild rumour?

Well, the following is a changelog for the hardware... not sure yet what the
final hardware specs will be. =(

1) WRAM decrease from 48K to 32K
2) Installation of 256K of CPU external WRAM
3) Elimination of the IR communications function (but there will be an
adapter accessory)

(I personally think #3 was a bad idea)

4) Change of serial comm to 32bit from 16bit.  SCCNT_L register interal
shift clock will change: "0" 8KHz -> 256 KHz, "1" 256KHz -> 2MHz.  Adding
UART-based comms.  Compatability with N64/Dolphin controller port
5) Changes in the coordinates of OBJ centre of rotation, changing to dot
boundary from dot centre.

(good idea I hear, provides for better results)

6) Changes to DMA functionality.  Adding a decrement transfer function,
changing the bit configuration of the control register.
7) The IME flag will be assigned to the new designed IME register instead of
the IE register
8) Changes to system calls in the monitor ROM (sound and affine).  Some may
be eliminated

(still haven't gotten hold of the original monitor rom... =/ )

9) Memory map may be changed.  Use the address definitions in AgbMemoryMap.h
10) Power-down function may be disabled
11) Change in maximum simultaneous colouring numbering - Changing to 5:5:5
(32768 colours) from 5:6:5 (65536 colours)



-WebDreamer
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Anyone out there who has had some time to play with the AGB dev kits, are
you happy with them, or do they leave something to be desired?

Is it confirmed that the WRAM is 256KB now? Or was that just a wild rumour?

----- Original Message -----
From: "Web Dreamer" <rownik@...>
To: <gbadev@egroups.com>
Sent: Saturday, August 05, 2000 5:39 AM
Subject: Re: [gbadev] GBA Specs


> >1. How much Ram the GBA has (compared to the 32k the GBC has)?
>
> I believe it's down to 32K of work ram, and now 256K on cart... strange as
> it sounds. There is also the video memory, registers, etc.
>
> >2. How many Sprites the GBA can display (compared to the GBC 40)?
>
> 128 on screen at 64x64 size, and 128 PER SCANLINE at 8x8 size.
>
> >3. What sprite modes are available (i.e. 8x8, 8x16, 16x16, ...)?
>
> 16 different sizes from 8x8 to 64x64.
>
> >4. The Attributes Setup (i.e. what is in it, how many bytes each
> >sprite takes up)?
>
> 4 bytes, including flags for h and v size, mosaic, color mode,
> semi-transparent... etc etc etc
>
> >5. How tiles are stored in memory (i.e. like GBC, but with 4 planes
> >instead of 2)?
>
> um... brain just went blank.
>
> >6. The number of "Backgrounds" or "layers" the GBA has (compared to
> >the background and window the GBC has, and anything fancy about them)?
>
> um 4, IIRC. Each scrollable, 2 rotateable/scalable. OBJ's moveable between
> layers.
>
> >7. If any special tile modes exist (i.e. 16x16 tiles in the
> >background
> >instead of the normal 8x8 or such)?
>
> See above.
>
> >8. How the Palettes are set up (i.e. how you load them, is it like
> >the
> >GBC with 2 registers you work with)?
>
> Regular old palette ram. In flavors of 256 colors in 1 palette or 16
colors
> in 16 palettes... with, of course, color 0 being transparent on the
display,
> like GBC OBJ's.
>
> >9. Anything else really cool (such as the priority bit of the
> >attributes on the GBC, If individual sprites can have an Alpha
> >Channel
> >applyed to them, If Sprites can be rotated or scalled, etc...)?
>
> Well, plenty of things... BG maps ranging in size from 128x128 to
1024x1024
> with wraparound, mosaic effects, alpha blending (not too sure how well it
> works yet), hardware LCD fade control, windows... itsa gonna be a really
> nice leetle plataform to geta you hands on...;-)
>
> WD
> ________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
>
>
>
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>
>

>1. How much Ram the GBA has (compared to the 32k the GBC has)?

I believe it's down to 32K of work ram, and now 256K on cart... strange as
it sounds. There is also the video memory, registers, etc.

>2. How many Sprites the GBA can display (compared to the GBC 40)?

128 on screen at 64x64 size, and 128 PER SCANLINE at 8x8 size.

>3. What sprite modes are available (i.e. 8x8, 8x16, 16x16, ...)?

16 different sizes from 8x8 to 64x64.

>4. The Attributes Setup (i.e. what is in it, how many bytes each
>sprite takes up)?

4 bytes, including flags for h and v size, mosaic, color mode,
semi-transparent... etc etc etc

>5. How tiles are stored in memory (i.e. like GBC, but with 4 planes
>instead of 2)?

um... brain just went blank.

>6. The number of "Backgrounds" or "layers" the GBA has (compared to
>the background and window the GBC has, and anything fancy about them)?

um 4, IIRC. Each scrollable, 2 rotateable/scalable. OBJ's moveable between
layers.

>7. If any special tile modes exist (i.e. 16x16 tiles in the
>background
>instead of the normal 8x8 or such)?

See above.

>8. How the Palettes are set up (i.e. how you load them, is it like
>the
>GBC with 2 registers you work with)?

Regular old palette ram. In flavors of 256 colors in 1 palette or 16 colors
in 16 palettes... with, of course, color 0 being transparent on the display,
like GBC OBJ's.

>9. Anything else really cool (such as the priority bit of the
>attributes on the GBC, If individual sprites can have an Alpha
>Channel
>applyed to them, If Sprites can be rotated or scalled, etc...)?

Well, plenty of things... BG maps ranging in size from 128x128 to 1024x1024
with wraparound, mosaic effects, alpha blending (not too sure how well it
works yet), hardware LCD fade control, windows... itsa gonna be a really
nice leetle plataform to geta you hands on...;-)

WD
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

>
>16.78mhz is correct
>
>


And I'm pretty sure the ARM core is fixed in little-endian format for data,
which drops the size (and cost) of the die a good bit versus an
endian-switchable core.

WD
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

>just a addition to your statement:
>the GBA use same cartridge connector as the GB/GBC. but with some
>anti-piracy
>chip that mirrors the memory banks or something like that. got no more info
>on that as of now

The connector IS definately the same 32-pin one found in the GBC. Though to
access the 32MB (read BYTES) or cart space, it multiplexes the address and
dates lines together, giving a 24-bit(?) address bus and a 16-bit data bus.
The GBA carts can be accessed in different speed modes, which equates to
different wait state timing. The cart space is accessed linearly in the
ARM's memory space. Cart RAM is accessed through a multiplexed bus also, I
think, but with only an 8-bit data bus. There is also supposed to be flash
possible on carts as well, up to 3mbit, IIRC. One interesting feature of the
video ram that I must say I REALLY like now is the bitmapped mode for BG
layers... 15-bit color images with no special hardware palette switching,
because it doesn't draw from a palette, just the 5:5:5 RGB data. Dear God,
this little machine is cool!

WD
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

>16.78 MHz .. are you sure ? (I'm working on a GBA debugger/emulator)
>Any other specs that can't be found on the net are also welcome :)
>

16.78mhz is correct

>The GBA and GBC are quite seperate pieces of hardware - different
>processors, different everything.  The GBA just has a GBC built into
>it.  So when the GBA detects that the ROM header is that of a GBC's, it
>enables that processor and the GBA effectively becomes a GBC.
>
>Hope that answers your question.

just a addition to your statement:
the GBA use same cartridge connector as the GB/GBC. but with some anti-piracy
chip that mirrors the memory banks or something like that. got no more info
on that as of now

----- Original Message -----

From: anarko

To: mike@...

Sent: Saturday, August 05, 2000 4:00 AM

Subject: Re: [gbadev] GBA Specs

hello ppl, ive been moving and stuff.. now im back.


msn> Could someone please share with us the following information about
msn> GBA.  At the very least I would really like to know the top 3. 
msn> Thanks.

msn> 1. How much Ram the GBA has (compared to the 32k the GBC has)?

we have 48k workram, 96k VRAM, 128x64bit OAM, 512x16bit paletteram
(256 bg,256 oam)

msn> 2. How many Sprites the GBA can display (compared to the GBC 40)?

you have multiple modes. char format modes & bitmap format modes.
for example we have char format mode 0, with 4 screens, 256x256 to
512x512 size, 1024 chars (sprites), 16/16 or 256/1 colors.
mode 0 and 1 can both do 1024 sprites. a scale-enabled mode 1 can only
do 256 sprites, and so can mode 2.

got that? =)



more later i guess


/anarko



unsubscribe: gbadev-unsubscribe@egroups.com

> Sorry to be OT (On-Topic) but I just want to confirm my calculations with
> people.  I have calculated that H-Blank takes 272 cycles and V-Blank takes
> 83799 cycles.  Its based on these stats:
>
> CPU is 16.78 MHz
> H-Blank takes 16.212 us
> V-Blank takes 4.994 us

hfreq=13.618khz
vfreq=59.727hz

of help?

hello ppl, ive been moving and stuff.. now im back.


msn> Could someone please share with us the following information about
msn> GBA.  At the very least I would really like to know the top 3.
msn> Thanks.

msn> 1. How much Ram the GBA has (compared to the 32k the GBC has)?

we have 48k workram, 96k VRAM, 128x64bit OAM, 512x16bit paletteram
(256 bg,256 oam)

msn> 2. How many Sprites the GBA can display (compared to the GBC 40)?

you have multiple modes. char format modes & bitmap format modes.
for example we have char format mode 0, with 4 screens, 256x256 to
512x512 size, 1024 chars (sprites), 16/16 or 256/1 colors.
mode 0 and 1 can both do 1024 sprites. a scale-enabled mode 1 can only
do 256 sprites, and so can mode 2.

got that? =)



more later i guess


/anarko

Could someone please share with us the following information about
GBA.  At the very least I would really like to know the top 3.
Thanks.


1. How much Ram the GBA has (compared to the 32k the GBC has)?

2. How many Sprites the GBA can display (compared to the GBC 40)?

3. What sprite modes are available (i.e. 8x8, 8x16, 16x16, ...)?

4. The Attributes Setup (i.e. what is in it, how many bytes each
sprite takes up)?

5. How tiles are stored in memory (i.e. like GBC, but with 4 planes
instead of 2)?

6. The number of "Backgrounds" or "layers" the GBA has (compared to
the background and window the GBC has, and anything fancy about them)?

7. If any special tile modes exist (i.e. 16x16 tiles in the
background
instead of the normal 8x8 or such)?

8. How the Palettes are set up (i.e. how you load them, is it like
the
GBC with 2 registers you work with)?

9. Anything else really cool (such as the priority bit of the
attributes on the GBC, If individual sprites can have an Alpha
Channel
applyed to them, If Sprites can be rotated or scalled, etc...)?

--
Mike Kasprzak

Matt J. Davies
Programmer
Acclaim Studios Ltd.

Matt J. Davies
Programmer
Acclaim Studios Ltd.

I wasn't aware of this. thanks for the info.

---
Giovanni Bajo
Lead Programmer

Protonic Interactive
www.protonic.net

a brand of Prograph Research S.r.l.
www.prograph.it


> -----Original Message-----
> From: Chris Schmitz [mailto:Chris.Schmitz@...]
> Sent: Tuesday, August 01, 2000 11:22 AM
> To: 'gbadev@egroups.com'
> Subject: AW: [gbadev] DMA dilemma!
>
>
> Not really. You mean the old DMA of the B/W gameboy. On the GBC
> it stops the
> CPU for sure.
>
> Chris
> Gameboy Lead Programmer
> Software2000
>
> -----Ursprüngliche Nachricht-----
> Von: Giovanni Bajo [mailto:bagio@...]
> Gesendet: Dienstag, 1. August 2000 11:18
> An: gbadev@egroups.com
> Betreff: RE: [gbadev] DMA dilemma!
>
>
> >
> > GBC halts when doing General Purpose DMA.
> > And HBlank DMA in h-blanks.
>
> Not really. If you look at a standard DMA routine on GBC, it is copied to
> $FF00-$FFFE because that's the only area of RAM still readable (and
> executable) WHILE DMA is in progress. Tipically, there is a short
> loop there
> to allow DMA to complete its execution.
>
> > It's faster than creating a copy loop.
>
> This could be useful on GBC, but I don't think that speed in
> memory xfer is
> a major problem on AGB.
>
> ---
> Giovanni Bajo
> Lead Programmer
>
> Protonic Interactive
> www.protonic.net
>
> a brand of Prograph Research S.r.l.
> www.prograph.it
>
>
>
>
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>
>
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>
> .
>

In message <17398269E24ED31180940090279C2CE9C48324@ASC-NT-EXCH1>
           Matthew Davies <MDavies@...> wrote:

> I cannot figure it out.  Does DMA transfers run asynchronously with the CPU
> or not?  I mean, when a DMA transfer is intiated does the CPU wait until its
> finished or does it not.  The fact that there are 3 priority levels of DMA
> seem to suggest that a DMA can interrupt another, and you need a the CPU
> running to start a second DMA transfer to do the interrupting.  Also, I have
> 4 DMA transfers on priority level 3 running back to back and they do not
> interfere with each other - either the CPU waits or the DMA transfer is
> amazingly fast.  Which is it?  Anyone??

Hmm, i can think of a third possibility... Maybe the CPU stops when you try
to write to the DMA regs while a DMA is running. Honestly, i don't think
that this is very likely, but it would explain things...

--
exoticorn/icebird

I didn't mention OAM/sprite DMA.

Dark Fader

> -----Oorspronkelijk bericht-----
> Van: Giovanni Bajo [mailto:bagio@...]
> Verzonden: Tuesday, August 01, 2000 11:18 AM
> Aan: gbadev@egroups.com
> Onderwerp: RE: [gbadev] DMA dilemma!
>
>
> >
> > GBC halts when doing General Purpose DMA.
> > And HBlank DMA in h-blanks.
>
> Not really. If you look at a standard DMA routine on GBC, it
> is copied to
> $FF00-$FFFE because that's the only area of RAM still readable (and
> executable) WHILE DMA is in progress. Tipically, there is a
> short loop there
> to allow DMA to complete its execution.
>
> > It's faster than creating a copy loop.
>
> This could be useful on GBC, but I don't think that speed in
> memory xfer is
> a major problem on AGB.
>
> ---
> Giovanni Bajo
> Lead Programmer
>
> Protonic Interactive
> www.protonic.net
>
> a brand of Prograph Research S.r.l.
> www.prograph.it
>
>
>
> --------------------------------------------------------------
> ------<e|-
> Skinny Dip with Your Own NeoPlanet Browser...Free!  Download Now!
> http://click.egroups.com/1/7678/0/_/_/_/965121578/
> --------------------------------------------------------------
> ------|e>-
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>

Not really. You mean the old DMA of the B/W gameboy. On the GBC it stops the
CPU for sure.

Chris
Gameboy Lead Programmer
Software2000

-----Ursprüngliche Nachricht-----
Von: Giovanni Bajo [mailto:bagio@...]
Gesendet: Dienstag, 1. August 2000 11:18
An: gbadev@egroups.com
Betreff: RE: [gbadev] DMA dilemma!


>
> GBC halts when doing General Purpose DMA.
> And HBlank DMA in h-blanks.

Not really. If you look at a standard DMA routine on GBC, it is copied to
$FF00-$FFFE because that's the only area of RAM still readable (and
executable) WHILE DMA is in progress. Tipically, there is a short loop there
to allow DMA to complete its execution.

> It's faster than creating a copy loop.

This could be useful on GBC, but I don't think that speed in memory xfer is
a major problem on AGB.

---
Giovanni Bajo
Lead Programmer

Protonic Interactive
www.protonic.net

a brand of Prograph Research S.r.l.
www.prograph.it





unsubscribe: gbadev-unsubscribe@egroups.com

>
> GBC halts when doing General Purpose DMA.
> And HBlank DMA in h-blanks.

Not really. If you look at a standard DMA routine on GBC, it is copied to
$FF00-$FFFE because that's the only area of RAM still readable (and
executable) WHILE DMA is in progress. Tipically, there is a short loop there
to allow DMA to complete its execution.

> It's faster than creating a copy loop.

This could be useful on GBC, but I don't think that speed in memory xfer is
a major problem on AGB.

---
Giovanni Bajo
Lead Programmer

Protonic Interactive
www.protonic.net

a brand of Prograph Research S.r.l.
www.prograph.it

> If the DMA stopped the CPU:
> 1) why 3 dma channels if you can use 1 a time?
> 2) why an interrupt to acknowledge the end of the dma?
> 3) what DMA itself would be useful for???
>
> DMA is used everywhere because you can transfer memory WITHOUT the cpu
> handling it. I've never found a consolle where the DMA halted CPU
> processing, but since I don't konw anything about AGB, it
> *might* be. In
> this case, I'd be very glad if someone could explain me why
> one should use a
> blocking DMA.

GBC halts when doing General Purpose DMA.
And HBlank DMA in h-blanks.
It's faster than creating a copy loop.
But if you have block copy instructions.. (don't know if GBA has), I see no
point in blocking DMA too.

Dark Fader

> ---
> Giovanni Bajo
> Lead Programmer
>
> Protonic Interactive
> www.protonic.net
>
> a brand of Prograph Research S.r.l.
> www.prograph.it
>
>
>
>
> -----Original Message-----
> From: Matthew Davies [mailto:MDavies@...]
> Sent: Tuesday, August 01, 2000 11:11 AM
> To: AGB list (E-mail)
> Subject: [gbadev] DMA dilemma!
>
>
> Hi,
>
> I cannot figure it out.  Does DMA transfers run
> asynchronously with the CPU
> or not?  I mean, when a DMA transfer is intiated does the CPU
> wait until its
> finished or does it not.  The fact that there are 3 priority
> levels of DMA
> seem to suggest that a DMA can interrupt another, and you
> need a the CPU
> running to start a second DMA transfer to do the
> interrupting.  Also, I have
> 4 DMA transfers on priority level 3 running back to back and
> they do not
> interfere with each other - either the CPU waits or the DMA
> transfer is
> amazingly fast.  Which is it?  Anyone??
>
> Cheers!
> Matt J. Davies
> Programmer
> Acclaim Studios Ltd.
>
>
>
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>
> --------------------------------------------------------------
> ------<e|-
> BTW: Did you buy that new car yet?
> If not, check this site out.
> They're called CarsDirect.com and it's a pretty sweet way to
> buy a car.
> http://click.egroups.com/1/6847/0/_/_/_/965120921/
> --------------------------------------------------------------
> ------|e>-
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>

If the DMA stopped the CPU:
1) why 3 dma channels if you can use 1 a time?
2) why an interrupt to acknowledge the end of the dma?
3) what DMA itself would be useful for???

DMA is used everywhere because you can transfer memory WITHOUT the cpu
handling it. I've never found a consolle where the DMA halted CPU
processing, but since I don't konw anything about AGB, it *might* be. In
this case, I'd be very glad if someone could explain me why one should use a
blocking DMA.
---
Giovanni Bajo
Lead Programmer

Protonic Interactive
www.protonic.net

a brand of Prograph Research S.r.l.
www.prograph.it




-----Original Message-----
From: Matthew Davies [mailto:MDavies@...]
Sent: Tuesday, August 01, 2000 11:11 AM
To: AGB list (E-mail)
Subject: [gbadev] DMA dilemma!


Hi,

I cannot figure it out.  Does DMA transfers run asynchronously with the CPU
or not?  I mean, when a DMA transfer is intiated does the CPU wait until its
finished or does it not.  The fact that there are 3 priority levels of DMA
seem to suggest that a DMA can interrupt another, and you need a the CPU
running to start a second DMA transfer to do the interrupting.  Also, I have
4 DMA transfers on priority level 3 running back to back and they do not
interfere with each other - either the CPU waits or the DMA transfer is
amazingly fast.  Which is it?  Anyone??

Cheers!
Matt J. Davies
Programmer
Acclaim Studios Ltd.




unsubscribe: gbadev-unsubscribe@egroups.com

Matt J. Davies
Programmer
Acclaim Studios Ltd.