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.

DS development > determine libnds version

#144903 - kusma - Fri Nov 09, 2007 12:57 am

I'd really like to be able to (preferably compile-time) determine the version of the installed libnds in order to support both devkitARM r20 and r21 in the same source distribution. DSWifi has a header-file called dswifi_version.h, but there doesn't seem to be any set of macros to identify different versions of libnds (specifically, it's stuff like glViewPort -> glViewport in videoGL.h I'd like to handle). Any clues?

#144920 - wintermute - Fri Nov 09, 2007 7:09 am

Why would you want to "support" an obsolete toolchain and library? That just runs the risk of ending up with the maintainance nightmare DSO and PAlib seem to have turned into.

I currently have release 22 fairly well under way, there are some more newlib tweaks for libfat and a couple of functions which don't quite work the way they're supposed to - nothing fatal, just unexpected return values. Do you plan on supporting 3 toolchain versions and 4 or more libnds versions in the same source distribution? What advantage would that give you?
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#144928 - kusma - Fri Nov 09, 2007 9:43 am

wintermute wrote:
Why would you want to "support" an obsolete toolchain and library?

Because that allows one developer to work on getting the code compiling for a new toolchain-release while other coders on the project continues development normally. Yes, I could branch out the code to upgrade, and that's most likely what I'll end up doing.

#144930 - wintermute - Fri Nov 09, 2007 10:29 am

That's probably a fair point really. r20 to r21 isn't quite the same leap that r18 to r19 was though - most of the toolchain work this time round has been related to Vista compatibility and sorting out a couple of issues with the newlib patches relating to file IO.

As far as libnds goes the major changes that have a potential to effect code were the glViewport case fix and using stdint.h for the short typedefs ( u32, u16 et al )

For the former a simple #ifndef should suffice

Code:

#ifndef glViewport
#define glViewport glViewPort
#endif


For some reason the newlib stdint.h appears to define uint32_t as unsigned long rather than unsigned int. Obviously they're equivalent on ARM but gcc likes to moan and this one seems to have caused a few issues for people who write inconsistent code where unsigned int and u32 are used interchangeably.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#144932 - kusma - Fri Nov 09, 2007 10:44 am

Quote:

For the former a simple #ifndef should suffice

Code:

#ifndef glViewport
#define glViewport glViewPort
#endif


...But glViewport isn't a preprocessor-symbol, it's a static inline function and thus not visible to the preprocessor.

#144933 - wintermute - Fri Nov 09, 2007 12:25 pm

Heh, I'm an idiot.

Weirdly I've seen code that looks like it uses function prototypes in macros for cross platform code but never thought to question it.

I guess the gcc version would suffice for your needs atm. r20 was 4.1.1, r21 is 4.1.2. See http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#144934 - kusma - Fri Nov 09, 2007 12:29 pm

wintermute wrote:
I guess the gcc version would suffice for your needs atm. r20 was 4.1.1, r21 is 4.1.2. See http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html

Ah, yes, this will solve my problem! Thanks a lot!

#144965 - tepples - Fri Nov 09, 2007 9:55 pm

wintermute wrote:
That's probably a fair point really. r20 to r21 isn't quite the same leap that r18 to r19 was though

Verifying that this is the case...
Code:
[####################...................]
0        25        50        75       100
error in mb.gba support: will isolate and then report on sf.net/projects/devkitpro
error in sf.net: waiting for password reset for account 'yerricde'

Quote:
As far as libnds goes the major changes that have a potential to effect code were the glViewport case fix and using stdint.h for the short typedefs ( u32, u16 et al )

Are there big changes that would affect custom ARM7 code? Should I rewrite my ARM7 code by copying my PSG code into a new copy of examples\nds\templates\combined\arm7\source\template.c ?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#144979 - wintermute - Sat Nov 10, 2007 12:08 am

I'm not entirely clear on what you're reporting here, have you encountered some problem with custom ARM7 code?

Checking the updates in the combined template would generally be a good idea. This last update has some extra code to put the DS in a known state & starts the irq which tracks the RTC for the time functions.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

#144983 - tepples - Sat Nov 10, 2007 12:34 am

wintermute wrote:
I'm not entirely clear on what you're reporting here, have you encountered some problem with custom ARM7 code?

Nope. DS is pretty much fine so far, but there's a problem with GBA, and I'm waiting until I get a response from SourceForge.net password reset before I put it in DKP tracker. Or I could report it directly to you through PM or e-mail.

Quote:
Checking the updates in the combined template would generally be a good idea. This last update has some extra code to put the DS in a known state & starts the irq which tracks the RTC for the time functions.

Done, and I fixed a problem with the new sound init code and the latest version of NO$GBA I could get my hands on. I had to & ~BIT(6) in the write to power management control so that the emulated DS doesn't power itself off in the init code.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.