Wednesday, November 24, 2010

source setup-r32

Bion, un package sources pour Apple Assault, c'est sympa, mais si le code pouvait être compilé avec les versions en date du devkitpro, ça ne serait pas plus mal, hein ? Il faut dire que j'étais resté à la version r21 qui doit dater d'octobre 2007 et sur laquelle j'ai pas mal bricolé entretemps.

I guess it'll make more sense to do a source release if you're able to compile Apple Assault from the source, right ? That's where you'll need devkitpro, the open-source cross-compiling and core-libraries project for homebrew console development ... as it was back in October 2007. Sticking to a working -- but obsolete -- development kit helped me during 3 years to stay focus and work on my tools rather than doing pointless bugfixes, but now it's time to move on. I fear it won't be an easy task, though, as I use a custom ARM7 and so on ... Hopefully, again, the ease of branching with subversion should help a lot.

  • gcc 4.5.1 râle sur char * x = "hello" et insiste pour qu'on ait const char* x = "hello", histoire que la chaîne (normalement considérée comme une constante) ne puisse pas être altérée par le programme. Dans l'absolu il a raison et c'est facile (mais chaint) à corriger... d'autant (C++ oblige) que le code de la bibliothèque doit lui aussi être recompilé pour bénéficier de l'update :P
  • IPC n'existe plus ou a été modifié. Je m'en servais pour gérer la mise en veille de la console ... 'faudra trouver autre chose. Plus gênant, mon code custom pour le côté ARM7 devra sans doute être mis à jour lui aussi, et de manière substancielle.
  • SUB_DISPLAY_CR a été renommé, de même que BGx_CR, BGx_X0 et leur variantes SUB_xxx (pour assurer la cohérence avec GBAtek, ce qui n'est pas plus mal, soit dit en passant). Pas vraiment gênant pour l'exécutable lui-même, mais ça va être pénible pour la mise à jour de mes bibliothèques
Bien sûr, mélanger les libgeds.a ou libpppnds.a de devkitpro r21 avec AppleAssault.o compilé pour devkitpro r32 (libnds 1.4.8, libfat 1.0.7, dswifi 0.3.13) serait voué à l'échec. C'est donc l'ensemble du projet qui a besoin d'être migré >_<

L'alternative, c'est de fourguer libnds, libfat et dswifi précompilé dans le "package sources", mais ça me tente tout de suite moins :P

PS: "source setup-r32" parce que j'ai pris l'habitude d'avoir un script shell nommé "setup" à la racine de chaque projet qui configure toutes les variables d'environnements (CLASSPATH, LD_LIBRARY_PATH, CFLAGS, voire même PATH pour utiliser des cross-compilers) ce qui me permet d'utiliser la commande shell source pour "activer le mode OMNet++" ou "activer le mode devkitpro". En l'occurence, pour devkitpro, j'ai un setup-rxx selon que je veux utiliser la release 19, 20, 21 ... ou maintenant 32.

7 comments:

PypeBros said...

One good news : transmission of input has been abstracted into inputGetAndSend() function from libnds/source/arm7/input.c ... it now uses the FIFO_SYSTEM rather than relying on a "shared area at a well-known location", which is (imho) a good thing as well ...

PypeBros said...

keysCurrent()&KEY_LID should be a possible alternative to IPC->buttons ...

Watch out : touchReadXY no longer has the same prototype...

PypeBros said...

consoleInitDefault is gone, and it looks like it allows me to prepare different console settings... to investigate.

PypeBros said...

exec.cpp made direct use of _io_dldi, which has been modified or somehow disappeared. to investigate as well.

PypeBros said...

libntxm and libppp weren't required to be updated to get a "booting" appleassault ... it's hanging somewhere before letting the game run, though, but I still have music playing.

PypeBros said...

IPC seems to be now __transferRegion :P
I spot references to __transferRegion()->buttons in system/initSystem.c, common/libnds_internal.h and arm9/keys.c (in the computation of KEYS_CUR that mixes touch&lid information of the ARM7 with the other keys that are available through the REG_KEYINPUT register on the ARM9)

I see #define transfer (*(__TransferRegion volatile *)(0x02FFF000)), while dkp-r21 used the transfer region @ 0x027FF000. I assume the only difference lies in some caching preference or MPU initial setting ... That would explain why my custom default ARM7 code still works :P

PypeBros said...

/beetle/hobby/DS/dsgametools/trunk/runMe/arm9/source/exec.cpp:47:24: warning: non-local variable 'const _FAT_disc_interfaces []' uses anonymous type

/beetle/hobby/DS/dsgametools/trunk/runMe/arm9/source/exec.cpp:288:52: error: could not convert 'fatUnmount(_FAT_disc_interfaces[0].::name)' to 'bool'

I restored the return type of fatUnmount from void to bool.