I looked more closely at the BIOS interrupt handler and noticed that to
load 0x03007FFC that it actually used 0x04000000 - 4

I guess doing it that way eliminates an add instruction.

Is it safe to take advantage of address wrapping in code in order to
reduce the number of instructions needed to load an address?

--
            The Phoenix - NekoCo - The Artistic Intuition Company
DevKitAdvance*MirrorReflex*Teapot*PhoenixQuake*Caelius*Zen-X*InfiniteRealms

On Fri, 2 May 2003, Rob Brooks wrote:

> I used to like the 68k method of 7 levels. I had no problems at all with
> that but this penny-pinching one-size-fits-all just seems like grief.
>
> :)

When you can pick up a system for less than 50 bucks, how can you
complain?  ^_^

I really need some more details about what happens when an interrupt is
triggered.

First, if more than one flag is set in IF, then how do you know which one
is causing this particular interrupt?

Are interrupts retriggered if you return from the ISR without clearing the
IF.

If they are retriggered, or multiple interrupts happened while the IME was
cleared, which one is triggered first.  In other words, what is the
hardwired priority of the interrupts, or, is it like are they all
triggered at the same time.

Is the IME cleared by the ARM processor when an IRQ occurs, or is this
done by the BIOS.

Is this correct:
1. The SPSR register controls if the CPU will accept interrupts

2. The IME register controls if the IO system will tell the CPU about
interrupts

3. The writing to IE controls which interrupts the IO system will set in
IF

4. If bits are set in IF and IME is set then an interrupt will be
triggered.

5. Setting an IF bit will clear it.

6. Even if the IME is set, if an an interrupt is enabled in IE, it will be
set in IF, but no interrupt will be generated until IME is cleared.

7. Because of 6, you should set IF before clearing IME if you do not want
to process any interrupts which have occured since IME was cleared.
And/Or you should clear IE before clearing IME so that no new interrupts
will be recorded.

8. Of course, there is no way to tell if an interrupt has occured more
than once and you missed it.

9. Each IRQ source has its own controls on when it will generate an
interrupt, so you have to have a lot of ducks in a row (spsr, ime, ie, and
specific IO register controls).


Questions:

If I enable IRQs while processing another IRQ (multiple IRQs), when
another interrupt occurs and preempts my first one, how do I know what
the new interrupt is and which ones may already be in progress?  If I
cannot tell, then I may end up processing the first interrupt twice.

The second one would not get processed until it gets retriggered.

Speaking of retriggering, am I just imagining this?  It seems to me that
it could work in one of two ways.  Either a set bit in IF will always
trigger an interrupt until you clear it, OR, an interrupt will not be
triggered again until you clear the IF bit and the interrupt occurs again.

But, if the second was true then your ISR would always have to process all
interrupts, because if you didn't, they would never happen again until you
cleared the IF.

Maybe it works in some third way I have not imagined.


Maybe my mistake is that I assuumed that the Single Interrupt code in
crtls.zip would not miss interrupts.  So I imagined some mechanism by
which it would get them all.

But, if there is no retriggering, then single interrupt code needs to
process all interrupts it sees and clear them all before returning from
IRQ.

Also, if there is no retriggering then multiple interrupt code cannot
ignore interrupts to implement priorities like I suggested.  So, to set
priorities you may just have to have some of your ISRs clear IME so they
can't be interrupted, and/or have the main ISR record lower priority
interrupts somewhere in memory, return, and then have the earlier, higher
priority instance of the main ISR take care of them explicitly after it
returns.

Does ARM only have a single interrupt line?  It would appear that the
gameboys IO system has a single interrupt, and relies on the memory mapped
IO registers to relay more information.  If there is more than one IRQ,
what are they connected to.

I've read a lot about IRQ handling on the GBA, so I am surprised that I
still have so many questions.  Maybe all the newbies to IRQs just use the
supplied code and it works well enough for them, while all the gurus who
write the FAQs have dealt with this on so many different systems that it
just makes sense to them and they do not feel the need to explain it in
detail.

I used to like the 68k method of 7 levels. I had no problems at all with
that but this penny-pinching one-size-fits-all just seems like grief.

:)

-----Original Message-----
From: Jason Wilkins [mailto:fenix@...]
Sent: 02 May 2003 15:42
To: gbadev@yahoogroups.com
Subject: Re: [gbadev] Multiple interrupts revisited - was crtls
Interrupt Handler


Hey Rob, it looks like you might be experiencing what I hypothesized
would happen if you use the multiple interrupt code.  My theory is that
the Multiple IRQ code in crtls.zip and Nintendo's reintr example is
'last
come, first serve'

This means that the latest interrupt is always the one which will get
serviced now, and it will preempt any one that is already in progress.
If
you want to assign priority then you will have to write code which
temporarily ignores lower priority interrupts.

If you are using single interrupts then the problem is that interrupts
are
being put off too long, and you should switch to multiple interrupts so
that those more important IRQs can get priority.

Of course I could be completely wrong.  I thought I understood
interrupts
pretty well before I started to get my hands dirty with them.  The
text-book made it sound so easy ^_^

Hey Rob, it looks like you might be experiencing what I hypothesized would
happen if you use the multiple interrupt code.  My theory is that the
Multiple IRQ code in crtls.zip and Nintendo's reintr example is 'last
come, first serve'

This means that the latest interrupt is always the one which will get
serviced now, and it will preempt any one that is already in progress.  If
you want to assign priority then you will have to write code which
temporarily ignores lower priority interrupts.

If you are using single interrupts then the problem is that interrupts are
being put off too long, and you should switch to multiple interrupts so
that those more important IRQs can get priority.

Of course I could be completely wrong.  I thought I understood interrupts
pretty well before I started to get my hands dirty with them.  The
text-book made it sound so easy ^_^

On Fri, 2 May 2003, Rob Brooks wrote:

> While we're on the subject of interrupts can anyone suggest a reason why I
> might be getting squeaks and splutters in the sound when I'm running
> multiplayer code?
>
> This only happens when I'm running multiplayer code and I'm assuming that
> the MP interrupts are somehow blocking my vblank interrupts which service
> the sound buffers.
>
> This same situation seems to occur occasionally with VCount interrupts
> flipping out when there is a lot of sound which is also worse when MP code
> is happening.
>
> What are the solutions for running multiple time-critical interrupts
> successfully on GBA?
>
> I must have my VCount interrtupts for palette switching, and if I let my SIO
> and Timer interrupts for MP go astray I'll lose synch.
>
> :(
>
> -----Original Message-----
> From: Jonathan Perret [mailto:jonathan.perret@...]
> Sent: 02 May 2003 13:45
> To: gbadev@yahoogroups.com
> Subject: Re: [lists] Re: [gbadev] Re: crtls Interrupt Handler
>
>
> From: "matthew conte" <itsbroke@...>
> > there's no need to handle game pak interrupt at highest priority.  only
> one
> > interrupt is handled per entry to the main ISR (for most usual setups), so
> > giving the lowest priority is fine.
>
> I don't follow you. Do you mean that only one bit is ever set in IF when
> the BIOS calls the ISR ? That seems quite unlikely.
> If this is not the case then the cart interrupt MUST be handled first
> since every other interrupt handler is likely to access code or data that
> resides in ROM. No ?
>
> Cheers,
> --Jonathan
>
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

--
            The Phoenix - NekoCo - The Artistic Intuition Company
DevKitAdvance*MirrorReflex*Teapot*PhoenixQuake*Caelius*Zen-X*InfiniteRealms

On Fri, 2 May 2003, matthew conte wrote:

> there's no need to handle game pak interrupt at highest priority.  only one
> interrupt is handled per entry to the main ISR (for most usual setups), so
> giving the lowest priority is fine.

I think I see what you mean.  If you have multiple interrupts enabled like
how Nintendo has demonstrated, then a "lower priority" interrupt will
still preempt a higher priority one.  The order that you check the IF
flags doesn't mean anything if any interrupt which happens preempts the
one you are currently processing.

It is like a store where any customer who comes to the counter will get
immediately served.  It would be pretty annoying to a customer with a lot
of stuff to buy, but really convenient for those people with just a couple
of things.  The problem is that if the person with just a couple of things
was being served, he would have to wait if the big customer came up behind
him him (but this is less likely because the small customer is so fast).

I guess interrupts that do not need to be preempted can set IME to 0.  It
will be restored by the main ISR.

Hmm, how does the multiple interrupt process keep from processing the same
interrupt twice?  If an interrupt high on the list was being processed,
and then an IRQ lower on the list occured, isn't there a situation where
the IF bit for the higher IRQ has not been cleared yet?  In that case
wouldn't the ISR confuse which interrupt had occured?

I guess a true priority system would return from the ISR without clearing
the IF flag and handling the interrupt if the interrupt was lower
priority.  I assume that if you return from your ISR without writing the
bits of the IRQs you handled to IF, that the IRQ will be immediately
reasserted.

In a single interrupt system, the order has meaning because the IRQs which
occur while you were processing the current IRQ will be waiting.  When it
cames back into the ISR, the one highest on the list will get processed
first.  I assume the IME simply keeps IRQs from being asserted, but that
if they are enabled in every other whay they still set IF and will be
asserted when IME is set to 1.

I dunno, the more I think about it, the more confused I get.  Nintendo's
sample code seems to work just fine for the most part, so I must assume
that any questions I ask have satifactory answers.

I am concerned about how the multiple IRQ ISR knows if it is already
processing an interrupt in another context.  Is the IE bit reset until
you reset the equivalent IF bit?  If so, then that would explain the IF&IE
instruction and explain how it knows to only process new interrupts.

Is this explained in detail anywhere?

> but if you disable all interrupts, you'll never get the game pak interrupt
> if someone inserts the cart again. ;)

I guess if you are looking to allow reinsertion you should push the IE
onto the stack, clear it except bit 13, and then wait.

I was thinking in context of what a simple cart interrupt handler for
devkitadv might do.  I would probably just reset IME and be done with in
that case.  Anything more complicated would be up to the programmer to
override.



> regards,
> matthew.

When I store data to a cart address does this infact cause the agb to write
to the flash cart or is something else required?  (Intel  Strata Flash)

i.e. assuming flash block cleared..

mov    r0,#0xff                    ;data to store
mov    r1,#0x40                ;Byte write command
mov    r2,#0x08000000    ;cart start address
strh    r1,[r2]            ;write 1/2 word  command
strh    r0,[r2]            ;write data to flash

I read:
> im new to the group and was wondering what you use for converting
> sound to C/C++ files

you could use sox http://sox.sourceforge.net/ or just about any sound
editor to convert your sounds to gba format and choose a suitable sampling
rate, then choose one of the methods described here:
http://devrs.com/gba/files/gbadevfaqs.php#IncRaw
to get it into your rom

HTH

x

--
chris@... Postmodernism is german romanticism with better
http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)

On Fri, 2 May 2003, Jonathan Perret wrote:

> ... or whatever you think is appropriate ! I wonder if it would be feasible
> to just say "Please re-insert the cartridge" and resume the game once
> this is done ?

I have not read the documentation, but I never thought about if another
IRQ is generated when the cart, or a different cart, is inserted.  I guess
that it is, because one feature of multiboot and joybus boot is to be able
to access the save data and first 4K of a cartridge.  I would assume that
you would be able to swap carts when you do this, and not have to insert
it before power on.  But, how coauld you tell if a cart was present or not
when you start?

Maybe say "Please press start when My Game(tm) GamePak is inserted"

> Could this be used for data-swapping between GBAs without a link cable ?

Hmm, you could write a multiboot program that would copy saved data from
one cart to another I guess.  Make it one of the tools you keep in your
game wallet.  Proceed to steal some kid's Pokemon.

> Cheers,
> --Jonathan

On Fri, 2 May 2003, Damian Yerrick wrote:

> Ever played "Golden Sun"?  If you pak-swap from GS1 to GS2, it's
> rumored that you can keep your characters.  "Banjo-Tooie" for N64
> initially was going to support pak-swapping with "Banjo-Kazooie",
> but the feature was pulled at the last minute.

I actually thought of a feature like this, but I didn't mention it because
that is not what these games are trying to do.

After doing some more disassembly, I see why I thought that the interrupt
handler was in ROM.  It is because they register the load address of the
handler in crt0.s, but then later copy it to RAM and register that one.

I'm really curious to check out my other games now and see how many of
them follow the same pattern.  I will be able to tell which programmers
just build something on top of Nintendo's samples and which ones start
from scratch.

While we're on the subject of interrupts can anyone suggest a reason why I
might be getting squeaks and splutters in the sound when I'm running
multiplayer code?

This only happens when I'm running multiplayer code and I'm assuming that
the MP interrupts are somehow blocking my vblank interrupts which service
the sound buffers.

This same situation seems to occur occasionally with VCount interrupts
flipping out when there is a lot of sound which is also worse when MP code
is happening.

What are the solutions for running multiple time-critical interrupts
successfully on GBA?

I must have my VCount interrtupts for palette switching, and if I let my SIO
and Timer interrupts for MP go astray I'll lose synch.

:(

-----Original Message-----
From: Jonathan Perret [mailto:jonathan.perret@...]
Sent: 02 May 2003 13:45
To: gbadev@yahoogroups.com
Subject: Re: [lists] Re: [gbadev] Re: crtls Interrupt Handler


From: "matthew conte" <itsbroke@...>
> there's no need to handle game pak interrupt at highest priority.  only
one
> interrupt is handled per entry to the main ISR (for most usual setups), so
> giving the lowest priority is fine.

I don't follow you. Do you mean that only one bit is ever set in IF when
the BIOS calls the ISR ? That seems quite unlikely.
If this is not the case then the cart interrupt MUST be handled first
since every other interrupt handler is likely to access code or data that
resides in ROM. No ?

Cheers,
--Jonathan






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

From: "matthew conte" <itsbroke@...>
> there's no need to handle game pak interrupt at highest priority.  only
one
> interrupt is handled per entry to the main ISR (for most usual setups), so
> giving the lowest priority is fine.

I don't follow you. Do you mean that only one bit is ever set in IF when
the BIOS calls the ISR ? That seems quite unlikely.
If this is not the case then the cart interrupt MUST be handled first
since every other interrupt handler is likely to access code or data that
resides in ROM. No ?

Cheers,
--Jonathan

> Copy your isr(interrupt service routine) to iwram/ewram
> Handle the card interrupt at highest priority
> Disable sound, set IME to 0 (disable all interrupts), and go to an
> infinite loop

there's no need to handle game pak interrupt at highest priority.  only one
interrupt is handled per entry to the main ISR (for most usual setups), so
giving the lowest priority is fine.

but if you disable all interrupts, you'll never get the game pak interrupt
if someone inserts the cart again. ;)

regards,
matthew.

Hmm, would be interesting..

Does anybody know wheter you can distinguish between a insert card and
remove cart interrupt??
What happens when you try to read from 0x08000000 when there is no
cartdridge??

I suppose it is time to get my hands dirty again :-)

Willem

> -----Original Message-----
> From: Jonathan Perret [mailto:jonathan.perret@...]
> Sent: 02 May 2003 11:10
> To: gbadev@yahoogroups.com
> Subject: RE: [gbadev] Re: crtls Interrupt Handler
>
>
> From: "Willem Kokke" <wkokke@...>
> > So just to make sure I'm upto to date:
> >
> > Proper card interrupt handling:
> >
> > Copy your isr(interrupt service routine) to iwram/ewram Handle the
> > card interrupt at highest priority
>
> Looks ok.
>
> > Disable sound, set IME to 0 (disable all interrupts), and go to an
> > infinite loop
>
> ... or whatever you think is appropriate ! I wonder if it
> would be feasible to just say "Please re-insert the
> cartridge" and resume the game once this is done ?
>
> Could this be used for data-swapping between GBAs without a
> link cable ?
>
> Cheers,
> --Jonathan
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~--> Get A Free Psychic Reading! Your
> Online Answer To Life's Important Questions.
> http://us.click.yahoo.com/cjB9SD/od7FAA/uetFAA> /cPRolB/TM
>
>
> --------------------------------------------------------------
> -------~->
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>

From: "Willem Kokke" <wkokke@...>
> So just to make sure I'm upto to date:
>
> Proper card interrupt handling:
>
> Copy your isr(interrupt service routine) to iwram/ewram
> Handle the card interrupt at highest priority

Looks ok.

> Disable sound, set IME to 0 (disable all interrupts), and go to an
> infinite loop

... or whatever you think is appropriate ! I wonder if it would be feasible
to just say "Please re-insert the cartridge" and resume the game once
this is done ?

Could this be used for data-swapping between GBAs without a link cable ?

Cheers,
--Jonathan

So just to make sure I'm upto to date:

Proper card interrupt handling:

Copy your isr(interrupt service routine) to iwram/ewram
Handle the card interrupt at highest priority
Disable sound, set IME to 0 (disable all interrupts), and go to an
infinite loop

Would that be correct?

Willem


> -----Original Message-----
> From: Jason Wilkins [mailto:fenix@...]
> Sent: 01 May 2003 22:26
> To: gbadev@yahoogroups.com
> Subject: Re: [gbadev] Re: crtls Interrupt Handler
>
>
> On Thu, 1 May 2003, Damian Yerrick wrote:
>
> > And I keep reassuring them that after Sega v. Accolade, people who
> > include logo data have nothing to worry about.
>
> I believe this too, but if Nintendo took you to court, it
> would be a huge
> hassle to get in front of a judge and tell Nintendo how
> mistaken it is.
>
> > > but disassembling code and distributing it is apparently
> just fine.
> >
> > If there's only one efficient way to express a given idea,
> then by the
> > "merger doctrine", the expression is not worthy of copyright.
>
> I believe this as well, but there are several different
> permutations of
> how this can be done, and in this case it is an instruction for
> instruction match.  It is not a big deal, I'm just curious.
>
> > Is there a way for a GBA cart to generate an interrupt
> other than by
> > being pulled off the bus entirely?  For example, NES carts
> generated
> > interrupts for all sorts of reasons.
>
> I would guess yes, but both handlers go into infinite loops,
> which is not
> a good way to handle any event except removal of the cart.
>
> Hmm, I just realized another bad thing about this code.  It
> turns off sound, and goes into an infinite loop, but it does
> not set IME to zero, so
> another interrupt could occur and take the program out of its loop.
>
> Removing the cart is bad, m'kay?
>
> I'm glad this feature only protects extremely careless people, nobody
> handles it correctly.
>
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~--> Get A Free Psychic Reading! Your
> Online Answer To Life's Important Questions.
> http://us.click.yahoo.com/O10svD/Me7FAA/uetFAA> /cPRolB/TM
>
>
> --------------------------------------------------------------
> -------~->
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>

--- In gbadev@yahoogroups.com, "Jan-Lieuwe Koopmans" <jan-lieuwe@e...>
wrote:
> Who ever pulls out cartridges out of a working machine anyway?

Ever played "Golden Sun"?  If you pak-swap from GS1 to GS2, it's
rumored that you can keep your characters.  "Banjo-Tooie" for N64
initially was going to support pak-swapping with "Banjo-Kazooie",
but the feature was pulled at the last minute.

--
Damian

I was able to confirm that the interrupt code in crtls is indeed copied
from Nintendo's very own 'reintr' sample program which demonstrates
handling multiple interrupts.

I believe that the person who did this could have at least changed the
function names!

I was trying to figure out why this bothered me.  I think it is because I
have tried to keep DKA from offending Nintendo or its 3rd parties in
anyway, I do want to work at one of those places at some point.

Code and docs which have been copied and pasted, bugs and all (typos and
all, like the LSR_usr thing), from files provided under NDA, are not the
sort of thing I want in DKA.

I guess I'll leave it at that.  I was rewriting the code for various
reasons anyway.

On Thu, 1 May 2003, Damian Yerrick wrote:

> And I keep reassuring them that after Sega v. Accolade,
> people who include logo data have nothing to worry about.

I believe this too, but if Nintendo took you to court, it would be a huge
hassle to get in front of a judge and tell Nintendo how mistaken it is.

> > but disassembling code and distributing it is apparently just fine.
>
> If there's only one efficient way to express a given idea, then by
> the "merger doctrine", the expression is not worthy of copyright.

I believe this as well, but there are several different permutations of
how this can be done, and in this case it is an instruction for
instruction match.  It is not a big deal, I'm just curious.

> Is there a way for a GBA cart to generate an interrupt other than
> by being pulled off the bus entirely?  For example, NES carts
> generated interrupts for all sorts of reasons.

I would guess yes, but both handlers go into infinite loops, which is not
a good way to handle any event except removal of the cart.

Hmm, I just realized another bad thing about this code.  It turns off
sound, and goes into an infinite loop, but it does not set IME to zero, so
another interrupt could occur and take the program out of its loop.

Removing the cart is bad, m'kay?

I'm glad this feature only protects extremely careless people, nobody
handles it correctly.

What the heck is LSR_usr?

I have found this register mentioned in two places.  nocash's gbatek docs
and [guess].  It exists nowhere else in the world (according to google).

Should this perhaps be LR_usr?

Ah, I am in a nit-picky mood today.

On Thu, 1 May 2003, Jan-Lieuwe Koopmans wrote:

> mentioned ;)  Nintendo's LOT check doesn't seem to bother... (I've seen
> quite a few bugs slipping through, actually!)

I found a bug in Wind Waker.  Lost 2 hours of game time ^_^

Be careful you do not fall off a ledge at the same time that you get mail
from a post box.

> It's also not strange to see Jeff's crtls being used all over the place.

I would not be surprised either.  But in this case, I think it was copied
from N.  If that is the case, then I wanted people's opinions about
changing it, considering other people's concerns about the logo data.

> Who ever pulls out cartridges out of a working machine anyway? And I don't
> mean that single time you did it while testing your own cart interrupt
> handling code :)

And if you did, why would you put another cartridge in without turning it
off?  And if you do that, don't you deserve to potentially lose your save
data?  I have more faith in players than that, even the millions of 6 year
olds who own gameboys.

I only said it was wrong, not that it was useful ^_^

> Greetings,
> Jan-Lieuwe

On Thu, 1 May 2003, Kurt Mahan wrote:

> I'd be more willing to bet they used Jeff's code and modified it.  Since
> it is a nice generic place to start.
>
> Kurt

I wouldn't, Super Mario Advance was a launch title.  The interrupt
handling in crtls was not added until months later, if I recall correctly.
(at least, i do not remember -removing- it from devkit advance R4).

When I first started to write my post, i was doing it because I thought
'hey cool, pro games are using Jeff's crt stuff', but then I thought I
should confirm it, so I looked at the oldest GBA game I had (Jap verson
of SMA).

It doesn't really matter to me however.  It is just a distraction while I
am researching 'industry best practices'

You can tell that I think about these details way too much because I am
finding tiny mistakes in commercial games ^_^

Other people just make games,  I really need to get my head out of this
compiler.

> I was stepping through the code of Pokemon Sapphire and I was especially
> interested in what Game Freak's interrupt routine looked like.  It turns
> out that it looks almost exactly like the multiple interrupts routine with
> user stack switching and cart interrupt handling that is in Jeff's crtls.
> It looked like only the order (i.e. priority) of the interrupts was
> changed.
>
> So, I checked Super Mario Advance.  Same code (except the priorities).
> Now I'm starting to worry.  People are so nervous about including
> Nintendo's logo data, but disassembling code and distributing it is
> apparently just fine.
>
> Interesting things to note.  I cannot find evidence that either game
> copies its ISR to ram, yet they both attempt to handle the cart interrupt
> by going into an infinite loop.  This won't happen because the cart will
> be gone.  Pokemon makes an additional mistake of making the cart interrupt
> the lowest priority, which would intermittently fail (Mario makes it top
> priority).  Maybe they do copy their ISR's to RAM, but the interrupt
> vector is set to its load address in ROM instead of its VMA.
>
> Anyway, I am wondering if this is all just an amazing coincidence, or did
> someone copy nintendo's code?

Many developers make/made the same mistake. I only handle the cart interrupt
correctly in my most recent projects (i.e.: ISR in (IW)RAM and cart
interrupt should be the 1st vector if the other vectors (indirectly) point
to ROM space). There are many other (bad) examples apart from the games you
mentioned ;)  Nintendo's LOT check doesn't seem to bother... (I've seen
quite a few bugs slipping through, actually!)

It's also not strange to see Jeff's crtls being used all over the place.
It's much better than the one Nintendo provides, so I guess even Nintendo's
developers might end up using it, hehe. Just like a lot of other GBA
developers do (usually in adapted form).

Who ever pulls out cartridges out of a working machine anyway? And I don't
mean that single time you did it while testing your own cart interrupt
handling code :)


Greetings,
Jan-Lieuwe

I'd be more willing to bet they used Jeff's code and modified it.  Since
it is a nice generic place to start.

Kurt

> I was stepping through the code of Pokemon Sapphire and I was especially
> interested in what Game Freak's interrupt routine looked like.  It turns
> out that it looks almost exactly like the multiple interrupts routine with
> user stack switching and cart interrupt handling that is in Jeff's crtls.
> It looked like only the order (i.e. priority) of the interrupts was
> changed.
>
> So, I checked Super Mario Advance.  Same code (except the priorities).
> Now I'm starting to worry.  People are so nervous about including
> Nintendo's logo data, but disassembling code and distributing it is
> apparently just fine.
>
> Interesting things to note.  I cannot find evidence that either game
> copies its ISR to ram, yet they both attempt to handle the cart interrupt
> by going into an infinite loop.  This won't happen because the cart will
> be gone.  Pokemon makes an additional mistake of making the cart interrupt
> the lowest priority, which would intermittently fail (Mario makes it top
> priority).  Maybe they do copy their ISR's to RAM, but the interrupt
> vector is set to its load address in ROM instead of its VMA.
>
> Anyway, I am wondering if this is all just an amazing coincidence, or did
> someone copy nintendo's code?

--- In gbadev@yahoogroups.com, Jason Wilkins <fenix@i...> wrote:
> It turns out that [Pokemon Sapphire's ISR] looks almost exactly
> like the multiple interrupts routine with user stack switching and
> cart interrupt handling that is in Jeff's crtls.
>
> So, I checked Super Mario Advance.  Same code (except the
> priorities).  Now I'm starting to worry.  People are so nervous
> about including Nintendo's logo data

And I keep reassuring them that after Sega v. Accolade,
people who include logo data have nothing to worry about.

> but disassembling code and distributing it is apparently just fine.

If there's only one efficient way to express a given idea, then by
the "merger doctrine", the expression is not worthy of copyright.
I'm guessing that the way Jeff's crt0 and Nintendo's libraries
handle interrupts is relatively commonplace on embedded systems.

> Interesting things to note.  I cannot find evidence that either
> game copies its ISR to ram, yet they both attempt to handle the
> cart interrupt by going into an infinite loop.  This won't happen
> because the cart will be gone.

Is there a way for a GBA cart to generate an interrupt other than
by being pulled off the bus entirely?  For example, NES carts
generated interrupts for all sorts of reasons.

--
Damian

I was stepping through the code of Pokemon Sapphire and I was especially
interested in what Game Freak's interrupt routine looked like.  It turns
out that it looks almost exactly like the multiple interrupts routine with
user stack switching and cart interrupt handling that is in Jeff's crtls.
It looked like only the order (i.e. priority) of the interrupts was
changed.

So, I checked Super Mario Advance.  Same code (except the priorities).
Now I'm starting to worry.  People are so nervous about including
Nintendo's logo data, but disassembling code and distributing it is
apparently just fine.

Interesting things to note.  I cannot find evidence that either game
copies its ISR to ram, yet they both attempt to handle the cart interrupt
by going into an infinite loop.  This won't happen because the cart will
be gone.  Pokemon makes an additional mistake of making the cart interrupt
the lowest priority, which would intermittently fail (Mario makes it top
priority).  Maybe they do copy their ISR's to RAM, but the interrupt
vector is set to its load address in ROM instead of its VMA.

Anyway, I am wondering if this is all just an amazing coincidence, or did
someone copy nintendo's code?

Hi people

im new to the group and was wondering what you use for converting
sound to C/C++ files i've heard that the program called 'Simon'
works quite well but cant find it anywhere anyone know a link ?

many thanks

Me "8)

> Yes, if you have a MBV2 cable. I'm not sure about the normal F2A
> cables.

thats the problem, i read some time ago that flashlinkeradvance carts
are working with the mbv2.
but currently they are sold out at lik-sang. despite of this i had
bad exprience with lik-sang, last year. i took nearly a half
year to refund me ,because of the ms/nintendo modchip thing timeout at
lik-sang.

david

On Thu, 1 May 2003 11:21:13 +0000 (UTC) David Voswinkel
<d.voswinkel@...> wrote:
>
> are there  linux based tools for uploading to
> flash2advance cards available ?

Yes, if you have a MBV2 cable. I'm not sure about the normal F2A
cables.

Boris

> OUCH! Most people probably wouldn't even use the Xport stuff that much. If
> you don't wanna go the small flash card with steroid way then:
> http://www.success-hk.com ----- Original Message -----

are there  linux based tools for uploading to
flash2advance cards available ?


david

> How about calling BIOS SoftReset() on exit?  Would that be logical?

Anything is fine.  I try to catch myself anytime I get too worried about
calling constructors, atexit, and what to do on exit because it really isn't
an important feature.

I really just want to make it easy to override, so that things like
PogoShell or a more flexible, could handle it in whatever way they needed.
To facilitate that, I just seperated all the low level functions out into
their own object files so they can be redefined without interfering with
each other.

> In that case, I guess it'd be best to optimize libc for beta 4.

I do not want to do beta 4.  That is probably why Beta 3 is taking so long.
If I readjusted my thinking and accepted that I probably want to do a few
more beta's then I probably would have released Beta 3 already.  But, the
idea that 'beta 3 is the last beta' is forcing me to put everything I want
in the final into this next release, because it is not a good idea to add
new features to something so close to release.

I didn't want to fall into perpetual beta mode, but now I am starting to get
tired of talking about features which no one has yet.

I was hoping to have release candidate 1 after beta 3, but I think now I
probably want to go with a schedule of 1 beta release every week until it is
ready.  In that spirit, I will release what I have this weekend.

Release early, release often.

> --
> Damian