gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Hardware > BIOS functions

#59569 - SittingDuck - Wed Nov 02, 2005 7:01 pm

Do BIOS functions have any real advantage over my own code? Are they fast? I've heard somewhere (from TONC) that BIOS calls are for space and not speed. (Stupid, since GBA programming is all about speed!)

#59599 - poslundc - Wed Nov 02, 2005 9:01 pm

SittingDuck wrote:
Do BIOS functions have any real advantage over my own code? Are they fast? I've heard somewhere (from TONC) that BIOS calls are for space and not speed.


They are optimized to fit on the small BIOS chip and make some speed tradeoffs in this regard. There is also an entry penalty for calling BIOS routines that makes them quite easy to beat with your own assembly code placed in IWRAM.

They are coded in the ARM instruction set and in zero-waitstate memory (same as IWRAM), so they easily outperform compiled C code running from the ROM.

Quote:
(Stupid, since GBA programming is all about speed!)


*shakes head and sighs* You have a long road ahead.

Dan.

#59612 - Joat - Wed Nov 02, 2005 9:58 pm

The BIOS functions are really there because the bios bootup sequence uses them, and they figured hey, why not expose these to developers.

Some, like the compression functions make a lot of sense to use, especially when time isn't critical, and the CPU clear beats the pants off of using DMA to clear (but a short cpu loop will kill both of them if you only need to clear a few bytes).

Others, like the math functions are not particularly good implementations, and even being in zero wait memory doesn't save them, and the sound engine is neither documented nor worth documenting (it's a steaming turd). Had they cut that dumb sound engine from ROM, they would have had room for ARM implementations of all the math funcs that are currently in thumb, although judicious unrolling would still be pushing it.

Like poslundc said, if you need speed, stick a well-written function in IWRAM, but honestly, write your code first, make it work correctly, and *then* worry about making it fast.

(broke the run-on into a few sentances)
_________________
Joat
http://www.bottledlight.com

#59619 - tepples - Wed Nov 02, 2005 10:18 pm

Joat wrote:
Had they cut that dumb sound engine from ROM, they would have had room for ARM implementations of all the math funcs that are currently in thumb

But then you wouldn't get that arpeggio before the "da-ding".
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#59637 - Joat - Wed Nov 02, 2005 11:15 pm

Although it's been a long time since I last looked, IIRC yes you would. The music driver itself isn't used by the BIOS (I'll check later tonight, I could be remembering wrong), although midikey2freq was. Even if it were, it'd be as easy or a lot easier to just do a nice intro sound outright rather than have a moderately sophisticated multi-channel mixer / driver.
_________________
Joat
http://www.bottledlight.com

#59680 - SittingDuck - Thu Nov 03, 2005 9:21 am

Is it possible, then, to keep some ARM code in ROM and load it into IWRAM when it is needed? For example if there are several games on one cartridge.

#59703 - tepples - Thu Nov 03, 2005 5:13 pm

Yes. There are "IWRAM overlays" but I've never investigated how to get them to work.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.