-----Original Message-----
From: ninge1 [mailto:ninge1@...]
Sent: Thursday, May 31, 2001 3:25 PM
To: gbadev@yahoogroups.com
Subject: [gbadev] checksums / maker codes etc

Are there any other official devs on the list that have gone through submission and know how to go about setting the maker code etc?

 

I had (stupidly it woudl appear) assumed i would just have to change the stuff in the rom header (rom_header.s from all the examples) and then re-compile.. but that just stops the game from running! Im guessing there must be some tools available i should be using for this?!? ive had a look on wario world and cant see anything?

 

i know on the gbc i just used to write the values in with hex-edit and then run rgbfix to set the checksum and then use some NOA program or other that displayed the header and what was right / wrong - can i do this (or something similar) with gba??

 

any help would be appreciated!

 

you can reply off-list to ninge1@... if you would prefer :)

 

cheers!

 

ninge

 

 

 

unsubscribe: gbadev-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Does anyone know how to calculate the CRC and CMP info of a GBA rom.

Thanks
-TeleKawaru

Jack Ukleja wrote:
> I havent got to that stage yet myself but I remember reading
> something on the newsgroups about this. I believe there is a little
> tool hidden away somewhere in the devkit that calculates a rom
> checksum for you which you need to put into the rom header. have a
> look through the newsgroup see if you can spot it.

I think the hardware debugger uploader can fix this CRC in the devkit
and nrdc is calculating the 16 bit CRC isn't needed in the header
anymore, only have to be attached with the submitted items.

You can get my tool to fix the CRC and manipulate other things in the
header from the bottom of my site: <http://credo.resource.cx/>. Forget
the 16 bit CRC part, I'll remove it soon. And the VGBA emulator is
checking on a wrong way the not needed 16 bit CRC, if you want to
execute some demos with it, be sure to use the pad option in my tool
too.

Credo <credo@...>

On 31 May 2001, at 18:19, dbrioso@... said something like:

> Way to go, Alex!!!
>
> We'd be better off with some topnotch 2d games. Besides, you want to
> play 3d lifelike fps, go get a ps2! This is just like trying to push a
> fast-paced 3d game into an old Speccy, get over it, we have a nice 2d
> box here, but a mediocre 3d platform...

As Jonas said, the point is that 3d is worth it if you can do a good
game and do some decent code behind it.

Doing 3d for the sake of it is just daft, but we all know some
industry peeps doing just that.

If you want to code demo stuff - cool.

If you have a decent game in mind, cool.

If you just want to do 3d for the sake of it (and you're in the
industry), then that's a bad idea.

Pick a game and do what's appropriate. On the GBA both 2d and
3d stuff will sell. Its a massively different market (and machine!)
from PSX etc.

I don't think GBA games will sell just because they are 3d - people
have too many expectations these days. If its 3d, it had better be
good.


Alex Amsel (#irc sillytuna)
Tuna Technologies Ltd (Sheffield)
PC/Console Game and Tools Development
Tel: +44 (0)114 266 2211  Mob: +44(0)7771 524 632

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

From: ninge1

To: gbadev@yahoogroups.com

Sent: Thursday, May 31, 2001 8:24 PM

Subject: [gbadev] checksums / maker codes etc

Are there any other official devs on the list that have gone through submission and know how to go about setting the maker code etc?

 

I had (stupidly it woudl appear) assumed i would just have to change the stuff in the rom header (rom_header.s from all the examples) and then re-compile.. but that just stops the game from running! Im guessing there must be some tools available i should be using for this?!? ive had a look on wario world and cant see anything?

 

i know on the gbc i just used to write the values in with hex-edit and then run rgbfix to set the checksum and then use some NOA program or other that displayed the header and what was right / wrong - can i do this (or something similar) with gba??

 

any help would be appreciated!

 

you can reply off-list to ninge1@... if you would prefer :)

 

cheers!

 

ninge

 

 

 

unsubscribe: gbadev-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

In message <009b01c0ea07$5d2a5560$8a7ba8c0@ninge>
           "ninge1" <ninge1@...> wrote:

> Are there any other official devs on the list that have gone through
submission and know how to go about setting the maker code etc?
>
> I had (stupidly it woudl appear) assumed i would just have to change the stuff
in the rom header (rom_header.s from all the examples) and then re-compile.. but
that just stops the game from running! Im guessing there must be some tools
available i should be using for this?!? ive had a look on wario world and cant
see anything?

There is one byte that keeps your rom from running, it's the complement
check at offset 0xBD. At the end of the manual there is the formular
to compute it.
In the tools section on www.agbdev.net/agbdev there is a GBA ROM Fixer,
which might do just what you are after, i haven't tried it myself,
though.
Anyway, if it doesn't do its job properly, it should be fairly
trivial to write such a tool (just for the complement check) yourself.

--
exoticorn/icebird

It may be even easier that all that....I have a Sega Master adapter that
dumps carts via a Gameboy Xchanger...also a firm has a Flash Card (4M) to PC
Engine adapter that you ul games via the Xchanger to the Flash Card ....but
I thought that the AGB carts had ROMs in them that could operate at
different speeds if required...I'm probably wrong though....



Best regards,

James :-)


This e-mail is private and confidential between the sender and the
addressee.  In the event of misdirection the recipient is prohibited from
using, copying or disseminating it or any information contained in it.
Please notify me of any such misdirection, and delete the message from your
system immediately.
----- Original Message -----
From: "Frostgiant" <frostgiant@...>
To: <gbadev@yahoogroups.com>
Sent: Thursday, May 31, 2001 6:31 PM
Subject: Re: [gbadev] Making carts for AGB


> You seem to know lots about EPROMs and carts and stuff so I was wondering
if
> it would be possible to modify a programmable GBA cart to work on a
Virtual
> Boy. Here is a schematic for a VB cart, if you wouldn't mind taking a
look.
> http://dana.ucc.nau.edu/~dbt/VBCart.html Thanks!
>
>
> ----- Original Message -----
> From: "daniel viksporre" <digitales@...>
> To: <gbadev@yahoogroups.com>
> Sent: Wednesday, May 30, 2001 6:21 PM
> Subject: Re: [gbadev] Making carts for AGB
>
>
> > Hi Daniel!
> >
> > I don't know if you have been on my page
> >
> > http://www.netcolony.com/technology/digitales/agb_rom.html
> >
> > It have been some time since I updated my page last time. I was about to
> make a cart for the GB advance.
> >
> > I have made a buss interface for a GBA cart. And I have the skills to
make
> circuit boards :)
> >
> > Here is one of my other projects...
> > http://www.netcolony.com/technology/digitales/
> >
> > I think this plastic injection machine sounded iteresting. Are the tools
> expancive for it? How much would it cost to make tool to make a cart
casing?
> >
> > If you have read some of my posts you would know that I would like easy
> way to realese your own stuff without nintendo interfering.
> >
> > I am also making a music tool for the GB advance, and I have thougth of
> making a custom cart with control knobs and midi connectors.
> >
> > How come that you have access to this machine?
> >
> > // Daniel Viksporre
> >
> >
> > Find the best deals on the web at AltaVista Shopping!
> > http://www.shopping.altavista.com
> >
> > unsubscribe: gbadev-unsubscribe@egroups.com
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
> >
> >
> >
>
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

Let's face it.  The reason everyone gets all excited about 3D on the GBA (myself
included) is that it is a throwback to the old days.  You have a framebuffer and
can write directly to it using all the cool little tricks we used to use in the
PC VGA days.

First thing I did when I got the hardware was port all my old 3D engine code
over to see how it ran.  I did the terrain heightmap thing, the 3D textured
polygon renderer, and the span buffer duke 3D thing.  Spent some time re-writing
the pc assembly inner loops to ARM.  Just to see how it worked.

It does.  I can now make a fairly mediocre 3D game on the GBA and it runs like
you would expect.  Like low resolution graphics on a low end pc.  It looked like
crap on the PC in 320x200 and it looks pretty crappy on the GBA though the small
screen helps.  Look at the announced games that use either wolfenstien or
duke/doom tech.  Sure they work and that is pretty cool but they still look like
junk.  The backgrounds are grainy and the scaled sprites look pretty bad.
Compare it to the graphics on a game made for the exact rendering size like
Rayman which looks gorgeous.

Tech guys like me just get excited about 3D because it is interesting.  Doing
what the hardware was made for is not as fun a problem.  Who wants to set up
sprite tables and let the hardware do the work when we can get in and write the
most optimized inner rendering loop possible.

Add that to the fact that while I can render the hell out of a height map to
make a nice terrain or map some polygonal environments, but I can't paint an
awesome 256 color landscape to save my life and you get the picture.  A coder
can create a pretty cool 3D world on his own without any art help.  But create
art for a nice looking 2D scroller that can compete.  Forget it.

I agree we will see a few 3D titles that exploit what we have learned on the
high end stuff.  But mostly it is about making good art and good games that play
well on the machine.  Regardless of the perspective.

Just my take.

At 06:19 PM 5/31/2001 +0000, you wrote:

>Way to go, Alex!!!
>
>We'd be better off with some topnotch 2d games. Besides, you want to
>play 3d lifelike fps, go get a ps2! This is just like trying to push
>a fast-paced 3d game into an old Speccy, get over it, we have a nice
>2d box here, but a mediocre 3d platform...
>
>--- In gbadev@y..., "Alex Amsel" <gba@t...> wrote:
> > Guys,
> >
> > as interesting as it is to have a 3d discussion here and to have
> > some cool 3d on the gba...
> >
> > ITS A 2D MACHINE, well designed for fantastic 2d games.
> >
> > To be hacking around with 3d stuff (again) seems something of a
> > waste to me.
> >
> > Not saying it can't do 'reasonable' 3d with some good coding, but
> > it's a games machine, not a 3d demo machine.
> >
> > I'd be much more interested in seeing some top notch 2d games
> > than poor doom incarnations all over again on yet another machine.
> >
> > Hell, its just C code re-used yet again, and optimised into asm
>with
> > some clever tricks along with it. Much more interesting would be to
> > design some cool games that suit the gba.
> >
> > But perhaps its just me.
> >
> > GAMEboy advance.
> > ^^^^
> >
> > Take this email as it's meant ;)
> >
> >
> > Alex Amsel (#irc sillytuna)
> > Tuna Technologies Ltd (Sheffield)
> > PC/Console Game and Tools Development
> > Tel: +44 (0)114 266 2211  Mob: +44(0)7771 524 632
>
>
>unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>

On Thu, 31 May 2001, Alex Amsel wrote:

> as interesting as it is to have a 3d discussion here and to have
> some cool 3d on the gba...

It is still on topic at least, i.e., how to do fast 3D with the GBA.

> ITS A 2D MACHINE, well designed for fantastic 2d games.

I think we know this.  But I can't help but think that Mode 4 is a nod
from Nintendo for 3D games, even if they say its for FMV ^_^  Hmm, thats
probably just wishful thinking.

I was thinking of using 3D for a few special effects.  Like the spinning
triforces in Zelda 3

> To be hacking around with 3d stuff (again) seems something of a
> waste to me.

again?  did this come up with the GBC?

> Not saying it can't do 'reasonable' 3d with some good coding, but
> it's a games machine, not a 3d demo machine.

DemoBoy Advance!

> I'd be much more interested in seeing some top notch 2d games
> than poor doom incarnations all over again on yet another machine.

What about great Doom incarnations?  I understand your point.  Its just
that I'm putting my OpenGL + GeForce 3 + Athlon 1333Mhz coding on hold to
do some GBA coding.  I'm just curious as to what sort of 3D I can do from
scratch on a little 16.7Mhz processor.

> Hell, its just C code re-used yet again, and optimised into asm with
> some clever tricks along with it. Much more interesting would be to
> design some cool games that suit the gba.

If I do a 3D engine for GBA, is going to be ASM from the inner loop on
out.

I don't think anyone plans on doing Soul Calibre on GBA.

Way to go, Alex!!!

We'd be better off with some topnotch 2d games. Besides, you want to
play 3d lifelike fps, go get a ps2! This is just like trying to push
a fast-paced 3d game into an old Speccy, get over it, we have a nice
2d box here, but a mediocre 3d platform...

--- In gbadev@y..., "Alex Amsel" <gba@t...> wrote:
> Guys,
>
> as interesting as it is to have a 3d discussion here and to have
> some cool 3d on the gba...
>
> ITS A 2D MACHINE, well designed for fantastic 2d games.
>
> To be hacking around with 3d stuff (again) seems something of a
> waste to me.
>
> Not saying it can't do 'reasonable' 3d with some good coding, but
> it's a games machine, not a 3d demo machine.
>
> I'd be much more interested in seeing some top notch 2d games
> than poor doom incarnations all over again on yet another machine.
>
> Hell, its just C code re-used yet again, and optimised into asm
with
> some clever tricks along with it. Much more interesting would be to
> design some cool games that suit the gba.
>
> But perhaps its just me.
>
> GAMEboy advance.
> ^^^^
>
> Take this email as it's meant ;)
>
>
> Alex Amsel (#irc sillytuna)
> Tuna Technologies Ltd (Sheffield)
> PC/Console Game and Tools Development
> Tel: +44 (0)114 266 2211  Mob: +44(0)7771 524 632

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

From: Alex Amsel

To: gbadev@yahoogroups.com

Sent: Thursday, May 31, 2001 7:22 PM

Subject: [gbadev] 2d games, none of this 3d lark

Guys,

as interesting as it is to have a 3d discussion here and to have
some cool 3d on the gba...

ITS A 2D MACHINE, well designed for fantastic 2d games.

To be hacking around with 3d stuff (again) seems something of a
waste to me.

Not saying it can't do 'reasonable' 3d with some good coding, but
it's a games machine, not a 3d demo machine.

I'd be much more interested in seeing some top notch 2d games
than poor doom incarnations all over again on yet another machine.

Hell, its just C code re-used yet again, and optimised into asm with
some clever tricks along with it. Much more interesting would be to
design some cool games that suit the gba.

But perhaps its just me.

GAMEboy advance.
^^^^

Take this email as it's meant ;)


Alex Amsel (#irc sillytuna)
Tuna Technologies Ltd (Sheffield)
PC/Console Game and Tools Development
Tel: +44 (0)114 266 2211  Mob: +44(0)7771 524 632


unsubscribe: gbadev-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

On 31 May 2001, at 19:34, Thomas Nielsen [Liftoff] said something like:

> It is DEFINATELY just you. Obviously, you have not seen the games that
> are coming out for GBA - If you think they are all 2d platformers in
> mario-style, you are certainly mistaking.

Certainly don't think that, but I also think that here is a good 2d
machine so some *good* 2d games can be done on it.

> 2d games are past history

Erm, could argue the case of this one very easily. GBC game
sales.

GBA will have damn fine 2d games as well, ala SNES. That's what
it is. Yes it'll have some good 3d stuff too, but don't knock 2d. It
ain't dead.

Besides, 2d can have beautiful rendered artwork too remember.

Not everyone likes 3d - don't believe the myth put about by game
companies who are poor at marketing to their non-traditional
audience - check game sales figures for proof of what really does
well.

GBC doesn't go to that audience and GBA will also have a very
mixed on too.


Alex Amsel (#irc sillytuna)
Tuna Technologies Ltd (Sheffield)
PC/Console Game and Tools Development
Tel: +44 (0)114 266 2211  Mob: +44(0)7771 524 632

One possible solution would be to compute all the values in memory
and then use a repeating DMA to set the values in the registers.

Francisco

--- In gbadev@y..., "Jack Ukleja" <jack.ukleja@n...> wrote:
> So according to calculations there are around 270 cycles available
in Hblank
> for execution. Unfortunately in reality this dosnt seem that much!
Ive got
> my ISR (ARM) in RAM as well as the Hblank fuction (C, thumb for
now).
>
> In my Hblank it seems to cope perfectly with just copying data into
> registers for a rot/scaling BG layer. But when I try copying data
for 2
> rot/scal layers I start getting problems on screen straight away!
For
> instance lines start flickering and maybe a scanline appears to
change mid
> line etc.
>
> My only conclusion is that the code generated by the compiler is
simply too
> slow to finish execution during Hblank. The disassembly contains
approx 30
> LDR/STR which are obviously the slow functions.
>
> Does this sound reasonable? Any one have experience with this?
>
> Anyway I plan to rewrite my Hblank function into ARM assembly,
which Im
> hoping will fix the problem.
>
> Cheers,
> Jack

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

From: Dave Murphy

To: gbadev@yahoogroups.com

Sent: Thursday, May 31, 2001 6:12 PM

Subject: RE: [gbadev] Me Too Posts

hmmm, I've heard that so many times about the GBC, DMA stops the CPU. That is completely untrue, you couldn't switch ROM Banks while a DMA was going on if you were DMAing from the upper bank but that's it. DMA did NOT stop the CPU on the GBC.

As for the GBA why are there different priorities of DMA which can, according to the docs I've seen around, interrupt each other. If the DMA stopped the CPU then surely there would be no priorities?

> -----Original Message-----
> From: ninge1 [mailto:ninge1@...]
> Sent: 31 May 2001 17:55
> To: gbadev@yahoogroups.com
> Subject: Re: [gbadev] Me Too Posts
>
>
> it is not obvious - the GBA one dosnt and neither did the GBC one...
> it may seem like a very stupid way of doing things but thats
> the way it is!!
>
> this one confused the heck out of me when i first started
> working on the
> gba - "whats the f***king point of DMA if it dosnt run in
> parrallel with the
> cpu?" i asked myself! - so i tested the code myself on the
> devkit - and when
> it still didnt do what i wanted (and hoped!) it would do i
> asked on the
> wario world boards to make 100% sure - and you know what? it
> really is true!
> the DMA does stop the cpu!
>

unsubscribe: gbadev-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

You seem to know lots about EPROMs and carts and stuff so I was wondering if
it would be possible to modify a programmable GBA cart to work on a Virtual
Boy. Here is a schematic for a VB cart, if you wouldn't mind taking a look.
http://dana.ucc.nau.edu/~dbt/VBCart.html Thanks!


----- Original Message -----
From: "daniel viksporre" <digitales@...>
To: <gbadev@yahoogroups.com>
Sent: Wednesday, May 30, 2001 6:21 PM
Subject: Re: [gbadev] Making carts for AGB


> Hi Daniel!
>
> I don't know if you have been on my page
>
> http://www.netcolony.com/technology/digitales/agb_rom.html
>
> It have been some time since I updated my page last time. I was about to
make a cart for the GB advance.
>
> I have made a buss interface for a GBA cart. And I have the skills to make
circuit boards :)
>
> Here is one of my other projects...
> http://www.netcolony.com/technology/digitales/
>
> I think this plastic injection machine sounded iteresting. Are the tools
expancive for it? How much would it cost to make tool to make a cart casing?
>
> If you have read some of my posts you would know that I would like easy
way to realese your own stuff without nintendo interfering.
>
> I am also making a music tool for the GB advance, and I have thougth of
making a custom cart with control knobs and midi connectors.
>
> How come that you have access to this machine?
>
> // Daniel Viksporre
>
>
> Find the best deals on the web at AltaVista Shopping!
> http://www.shopping.altavista.com
>
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

It is DEFINATELY just you. Obviously, you have not seen the games that
are coming out for GBA - If you think they are all 2d platformers in
mario-style, you are certainly mistaking.

2d games are past history (if anyone wants to discuss this with me, mail
me privately - i do NOT want to be responsible for cluttering this fine
mailinglist up in 2d vs 3d talk. But it DOES take better coders to use
3d in inventive ways on gba :)

Dave Murphy:
There would still be properties if CPU is halted. What about vertical
retrace?!? .. That doesnt stop just because the CPU does.

/Steve--



-----Original Message-----
From: Alex Amsel [mailto:gba@...]
Sent: 31. maj 2001 19:23
To: gbadev@yahoogroups.com
Subject: [gbadev] 2d games, none of this 3d lark


Guys,

as interesting as it is to have a 3d discussion here and to have
some cool 3d on the gba...

ITS A 2D MACHINE, well designed for fantastic 2d games.

To be hacking around with 3d stuff (again) seems something of a
waste to me.

Not saying it can't do 'reasonable' 3d with some good coding, but
it's a games machine, not a 3d demo machine.

I'd be much more interested in seeing some top notch 2d games
than poor doom incarnations all over again on yet another machine.

Hell, its just C code re-used yet again, and optimised into asm with
some clever tricks along with it. Much more interesting would be to
design some cool games that suit the gba.

But perhaps its just me.

GAMEboy advance.
^^^^

Take this email as it's meant ;)


Alex Amsel (#irc sillytuna)
Tuna Technologies Ltd (Sheffield)
PC/Console Game and Tools Development
Tel: +44 (0)114 266 2211  Mob: +44(0)7771 524 632

unsubscribe: gbadev-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/

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

From: Dave Murphy

To: gbadev@yahoogroups.com

Sent: Thursday, May 31, 2001 10:18 AM

Subject: RE: [gbadev] Me Too Posts

>
> 1. Setup copy of large block o' crud with dma.
> 2. Setup large pointless loop.
> 3. Time each independantly.
> 4. Time when run together.
>
> The cycle counts for the for the independant runs and when
> run together will
> be the same.

hmm, how do you time a dma copy if it halts the cpu?

I hope you mean that the time for (1) + time for (2) = time for (4)

:o)

unsubscribe: gbadev-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

On 31 May 2001, at 18:12, Dave Murphy said something like:

> As for the GBA why are there different priorities of DMA which can,
> according to the docs I've seen around, interrupt each other. If the
> DMA stopped the CPU then surely there would be no priorities?

Because DMA can interrupt other DMA.

e.g. DMAing in HBlank needs a high priority and should interrupt
other DMAs taking place for e.g. sound.

re: DMA

Wish it didn't stop the cpu. Now, where's my Miggy blitter gone...


Alex Amsel (#irc sillytuna)
Tuna Technologies Ltd (Sheffield)
PC/Console Game and Tools Development
Tel: +44 (0)114 266 2211  Mob: +44(0)7771 524 632

First time in a LONG time that I write here :)

>hmmm, I've heard that so many times about the GBC, DMA stops the CPU. That
is completely untrue, you couldn't
>switch ROM Banks while a DMA was going on if you were DMAing from the upper
bank but that's it. DMA did NOT
>stop the CPU on the GBC.

Read your Nintendo documentation carefully...

Well, lets say you do a HDMA transfer, then the DMA transfer will only
happen in the H-Blank. So when there is NO DMA going on then the CPU runs..
Okay, so the CPU could change the ROM bank, but since the DMA controller
knows nothing about that, it will just use what ever ROM bank is active.

>As for the GBA why are there different priorities of DMA which can,
according to the docs I've seen around,
>interrupt each other. If the DMA stopped the CPU then surely there would be
no priorities?

Read your Nintendo documentation carefully...

CPU stops, but not the interrupts.

Some of the DMA's are triggered by interrupts, such as the sound DMA's and
you can also set the DMA's up on the HBlank interrupt (or even the VBlank).
Should explain it...

Cheers,
Sam
--------------------------------------------
PC, PlayStation and GBC/GBA developer.

Sam Nova
Novalicious
Bündtenstr 3B
4419 Lupsingen
Switzerland
Phone: +41 - 61 911 03 66
Cell phone: +41 - 79 455 71 14
Fax: +41 - 61 911 03 66

sam@...
http://www.novalicious.com




> -----Original Message-----
> From: ninge1 [mailto:ninge1@...]
> Sent: 31 May 2001 17:55
> To: gbadev@yahoogroups.com
> Subject: Re: [gbadev] Me Too Posts
>
>
> it is not obvious - the GBA one dosnt and neither did the GBC one...
> it may seem like a very stupid way of doing things but thats
> the way it is!!
>
> this one confused the heck out of me when i first started
> working on the
> gba - "whats the f***king point of DMA if it dosnt run in
> parrallel with the
> cpu?" i asked myself! - so i tested the code myself on the
> devkit - and when
> it still didnt do what i wanted (and hoped!) it would do i
> asked on the
> wario world boards to make 100% sure - and you know what? it
> really is true!
> the DMA does stop the cpu!
>

Yahoo! Groups Sponsor



unsubscribe: gbadev-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

>
> 1. Setup copy of large block o' crud with dma.
> 2. Setup large pointless loop.
> 3. Time each independantly.
> 4. Time when run together.
>
> The cycle counts for the for the independant runs and when
> run together will
> be the same.

hmm, how do you time a dma copy if it halts the cpu?

I hope you mean that the time for (1) + time for (2) = time for (4)

:o)

Guys,

as interesting as it is to have a 3d discussion here and to have
some cool 3d on the gba...

ITS A 2D MACHINE, well designed for fantastic 2d games.

To be hacking around with 3d stuff (again) seems something of a
waste to me.

Not saying it can't do 'reasonable' 3d with some good coding, but
it's a games machine, not a 3d demo machine.

I'd be much more interested in seeing some top notch 2d games
than poor doom incarnations all over again on yet another machine.

Hell, its just C code re-used yet again, and optimised into asm with
some clever tricks along with it. Much more interesting would be to
design some cool games that suit the gba.

But perhaps its just me.

GAMEboy advance.
^^^^

Take this email as it's meant ;)


Alex Amsel (#irc sillytuna)
Tuna Technologies Ltd (Sheffield)
PC/Console Game and Tools Development
Tel: +44 (0)114 266 2211  Mob: +44(0)7771 524 632

hmmm, I've heard that so many times about the GBC, DMA stops the CPU. That is completely untrue, you couldn't switch ROM Banks while a DMA was going on if you were DMAing from the upper bank but that's it. DMA did NOT stop the CPU on the GBC.

As for the GBA why are there different priorities of DMA which can, according to the docs I've seen around, interrupt each other. If the DMA stopped the CPU then surely there would be no priorities?

> -----Original Message-----
> From: ninge1 [mailto:ninge1@...]
> Sent: 31 May 2001 17:55
> To: gbadev@yahoogroups.com
> Subject: Re: [gbadev] Me Too Posts
>
>
> it is not obvious - the GBA one dosnt and neither did the GBC one...
> it may seem like a very stupid way of doing things but thats
> the way it is!!
>
> this one confused the heck out of me when i first started
> working on the
> gba - "whats the f***king point of DMA if it dosnt run in
> parrallel with the
> cpu?" i asked myself! - so i tested the code myself on the
> devkit - and when
> it still didnt do what i wanted (and hoped!) it would do i
> asked on the
> wario world boards to make 100% sure - and you know what? it
> really is true!
> the DMA does stop the cpu!
>

> Concerning the DMA, it is obvious, all DMA controller are supposed to
> function like this...

In a perfect world where game consoles aren't designed by companies who
pinch their pennies on every aspect of the hardware, this would be true. But
we don't live in a perfect world :).

Anyone with hardware can verify very easily that the CPU is halted during
DMA. Example:

1. Setup copy of large block o' crud with dma.
2. Setup large pointless loop.
3. Time each independantly.
4. Time when run together.

The cycle counts for the for the independant runs and when run together will
be the same.

     Just Me,
         *SF

In message <1682720015431165057296@...>
           "after" <after@...> wrote:

> Concerning the DMA, it is obvious, all DMA controller are supposed to
> function like this...

Sorry, didn't know that it was obvious or supposed to be this way, but
i'm afraid that all the dma transfers i did on the real gba hardware
so far did indeed halt the cpu...

--
exoticorn/icebird

>In theory, multiple DMA requests can be programmed at one time by the CPU
>for successive memory moving. So, the DMA controller of the gba should act
>like this, I think.

just for the record, that's how the ps2 works - and this is an incredible
useful feature. you construct your entire scene, and execute it while
building the next.

so why is it only "in theory"?


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