Appleman 2.0

Bon, je me suis enfin refait les animations de l'Appleman dans l'éditeur d'animation modulaire. C'est que déjà avant que je ne m'attaque à Apple Assault, j'avais dans l'idée que Bilou puisse ramasser le corps de l'Appleman pour s'en servir ensuite de projectile. Puis c'est plus cohérent avec le comportement de dumblador qui joue le même rôle dans la School Zone.

Sauf que, vous vous en doutez, ça ne s'est pas passé sans mal. D'abord quelques plantages de MEDS (oui, encore) qui m'ont obligé à tout refaire, puis le niveau qui ne voulait plus rien charger le temps que je lui réexplique où se trouvent les animations demandées et que je corrige celles qui étaient lues en boucle alors que la machine d'état prévoit une transition "à la fin de l'animation".

You could easily claim that this was a cursed sprite and I would almost believe you. See, I've had applemen pixels from over 15 years now, and yet I wanted to upgrade its motion into a compound sprite. The idea would be to make it more like the dumblador, losing its feet when stomped, staying stunned until feet are recovered etc. I expect that it would feel fun...

Then the curse started, with blue screens in the editor as I tried to "clean up" some animations, despite I fixed something similar in September. Then the level would no longer load because some of the newly defined animations were looping and AppleAssault assumed it could wait for them to be done for some transition. And when all that was fixed, with WiFi transfers over RunMe through the NUC, the appleman did not have feet but huge, purple fists instead.

Ensuite, voilà que les pieds de l'appleman sont remplacés par des gros poings mauve alors qu'il devrait réutiliser les pieds de Bilou relookés en brun. La faute à un code encore un peu trop jeune dans le chargement d'un 2eme fichier de graphismes. Les couleurs erronées, ça, ça m'aura pris plus de temps. Je me replonge dans le code d'il y a 2 ans, je vérifie qu'on a bien assez de mémoire vidéo pour charger tout ce petit monde (scoop: oui. On a 16KiB, assez pour 8192 couleurs alors que les 16 palettes accessibles par les sprites n'en consommeraient que 4096)

To get proper images, the first thing is to ensure SpritePages are properly remapped when loading the additional set. For the school zone, that was done with spr.more "school.spr" page8,82 meds+4. Yeah, I know. That's not the most self-documenting line of script in the world ^^". What's important here is page8,82. That is controlling the remapping.

• The first number (8) indicates that we expect Bilou.spr to feature 8 sprite pages, and that pages for "school.spr" are to be numbered 8, 9, 10, ...
• The second is not a number: it is a series of digits each identifying a page, and each telling where each page is starting with the 8th slot. Page 8 remains unchanged (since the series starts with an 8), but page 9 will use page 2 instead (where Bilou hands and feet are)

That was for the school zone, but the green zone spriteset did not have hand and feet. Instead, they had to be added as the 11th page within the set ... almost page 20 for the level. Code parsing that was a bit crude too and was never meant for things identifying page number higher than 10. Oh, you could do it, but you might have to identify page 11 in the whole set with ;. I tried to simplify that a bit so that we can actually use spr.more "green.spr" page8,-..---.----2 meds+4 instead. Here,

• every - in the sequence means "that page holds no sprites. It shouldn't be used by animations".
• . means "don't touch: that page is perfect as it is". Any sprite page in green.spr has such a dot.
• And you know about the final 2 already: it identifies one page within bilou.spr that must appear instead of a "draft" page of green.spr and be used by Appleman animations

Definitely, some colors from green.spr were loaded here. We wouldn't have the sprite-branch with colours that close to those of the trunk otherwise. But the yellow worm now has weird blueish outlines and the appleman feet are both light-Bilou-green rather than having one dark brown and the other darker brown. 

Et là, la raison était plus ... exotique, on va dire. Le code C++, rien à redire. C'est presque limpide: ça *doit* ajuster les commandes qui définissent les images et palettes utilisées par les personnages, à condition que le décalage soit correct. Et le décalage, je fournis à la main dans le script du niveau. Mais manque de bol: le compilateur (gcc 8.1.0 ajouté à devkitARM 49 en 2018) produit du code machine qui ne correspond pas à ce qu'il me faut (une fois encore). Vérification faite, le gcc 10.1.0 du devkitARM 54 ne fait pas mieux. Pour avoir enfin mes bonnes couleurs, il faudra que je réexprime mon code différemment pour contourner ce qui semble être un bug dans le générateur de code ou dans l'optimiseur ...

There's a line in the remapPages() function that should deal with that: find "change sprite" instructions in the animation code, isolate the current palette value and add the "adjust palette" computed by the caller. It should work, really, but single stepping through the code with all the optimized-away locals left me puzzled. So I dug deeper, taking notes of the machine code, tracking what register meant what and ... 0_0

and there was no add instruction to be found. Nowhere in the loop. The machine code generated by gcc 8.1.0 would just assign the same green_palette[0] to every sprite no matter what palette they were using. That seemed to happen with gcc 10.1.0 as well... it wasn't too hard to work around, but yet. Troublesome.

Only 6 releases and 2.5 years behind

Believe it or not, that's actually a pretty up-to-date devkit I was running (by my standards) when I encountered a weird GCC bug that would turn a for loop into an endless one. I'm not super-hot about upgrading the toolchain while I just managed to have all my tools working again, but it should be safe to give them a try, at least.

There is at least one trick I'd have to fix or revert: I tried to override the _jp2uc function to save some room in the binary, but with devkitARM release 54, the trick doesn't work anymore. (well, the trick saves 14K. It wouldn't be such a big deal to drop it).

/opt/devkitpro/devkitARM/lib/gcc/arm-none-eabi/10.1.0/../../../../arm-none-eabi/bin/ld: /opt/devkitpro/devkitARM/lib/gcc/arm-none-eabi/10.1.0/../../../../arm-none-eabi/lib/thumb/libg.a(lib_a-jp2uc.o): in function `_jp2uc': (.text._jp2uc+0x0): multiple definition of `_jp2uc'; .//outnds/Demo/shrink.o:.//Demo/source/shrink.cpp:22: first defined here collect2: error: ld returned 1 exit status .//common.mk:360: recipe for target './/Demo/Demo.elf' failed 

That trick is based on the idea that symbols from libraries are weak, and thus can be overridden from the linking application if the application decides so. Maybe that assumption doesn't hold anymore ?

• apart from that trick, no breaking errors occured while rebuilding
• there is now V=1 support in ds_rules. I'll have to check to what extent that allows common.mk to be simplified.
• Both LEDS and SEDS seems to work with the new release.
• I couldn't reproduce the odd bug with latest gcc.

Note: I had tried to solve an issue with the editor getting stuck when using that Zap! command since early 2019, which is in the middle of the "devkitpro update" started in September 2018.

It's not that it crashes when we hit 'Zap!' on the palette windows: the code stalls. That's not helping to track where the bug is, of course. On alternate palettes, it doesn't it keeps working (on emulator) but extremely slowly... sometimes.

The amount of steps performed during this operation is too high to make step-by-step debugging in desmume any practical. And when it hangs, it is in the middle of nowhere, with no code to execute...

It also explains why attempts to use natively-compiled code to unit-test the issue kept useless.

Petits essais desmume

J'ai pris conscience il y a quelques jours que je n'avais toujours pas écrit de document présentant le fonctionnement de AnimEDS, pourtant lauréat du concours NeoFlash.

Du coup, comme j'ai un PC windows qui traine à la maison en ces temps confinés, j'ai

- re-téléchargé un desmume-0.9.11

- configuré le chargement des ROM en mode "load into RAM" (pour la compatibilité DLDI)

- ajusté le SLOT 1 pour émuler une R4 vers le répertoire "efsroot" de mon dernier tuto en date (auquel j'ai quand-même rajouté un sous-répertoire "moving", pour la forme).

ça suffit pour LEDS. Maintenant, voyons AnimEDS ...

 

Some days ago, I realised I still had no document describing how one would use my Animation Editor for Nintendo DS: AnimEDS, despite it is the only homebrew I had ever submitted to a coding compo. 

Since I have a windows PC at home during "lock down", I re-downloaded desmume-0.9.11 and went through the required "load into RAM" and setup SLOT 1 folder through the 'Config' menu . (yep, I'll be emulating an R4 on slot 1, this time). Contents of the folder will be that latest tutorial I uploaded on gbatemp. That worked for LEDS (packed with the tutorial), but not with AnimEDS.

 

PS: oui, j'ai bien lu: les gens derrière le projet Desmume recommandent plutôt de prendre un "nightly build" plutôt que les "stable build", mais ces derniers sont les seuls à ne pas faire grincer les dents de Winwin avec un auteur du logiciel non défini. On ne va pas tenter le diable, non plus.

Par contre, le dernier build que j'ai d'AnimEDS ne parvient pas à charger les fichiers .spr de la même manière. J'aurais dû m'en douter >_<.

Puis les vacances sont arrivées. J'ai pris un moment pour comprendre ce qui se passait, et pourquoi il fallait une combinaison "desmume/devkit" pour que ça coince. 

 

I should have guessed. I knew there's a compatibility issue between desmume 0.9+ and devkitpro's resources since I downloaded them back in 2018. So far, I just rebuilt stuff with my 'older' devkit (still running GCC 4.x >_<), but the laptop where I did that seems to be definitely damaged. Well. It's locked-down holiday time and the painting is drying on the walls, so I kicked up my debugger and started investigating what happened.

• things work fine on a real Nintendo DS
• things work fine with an old emulator
• things work fine with an old devkit compiling nearly the same sources.
• when things go wrong, we see that fatInitDefault fails. Yet it found the 'fat' device but it cannot mount it.
  

Et j'ai fini par me rendre compte que toutes les fonctions liées au DLDI pointaient vers la même fonction qui return false.

Je creuse encore et je me rends compte que les fichiers .nds qui marchent sont renseigné comme ayant un autre type de header que les .nds qui échouent. Et que le code de desmume a un test du type "taille du header < 16K" pour décider si il a affaire ou non à un homebrew.

When I realised that all the IO functions in the DLDI interface were pointing to the same code (actually just returning false), I started to be very suspicious about desmume's DLDI patching feature, and I re-downloaded its sources. While it was building, I noticed that the old-built-working .NDS and the new-built-failing .NDS were not reported similarly by the 'file' linux tool. And here's the catch:

• desmume has some code checking whether it is running a homebrew before patching DLDI
• that code only work for so-called 'old' (512-bytes) headers.
• 'new' devkitpro tools use 'new' (16K) headers by default.
  

Visiblement, les "nouveaux" homebrews ne sont plus reconnus comme tels, et donc même plus candidats au patch DLDI. Heureusement, l'outil ndstool est toujours capable de faire des "vieux headers" (-h 0x200) en plus des "nouveaux headers" (par défaut, -h 0x4000).

Il faudra que je vérifie que ça marche aussi avec l'émulateur "tout frais" sous Windows, bien sûr, et que je me souvienne que je suis aller bricoler dans /opt/devkitpro/devkitARM/ds_rules ... un patch qui n'était pas indispensable puisque j'ai repris une règle équivalente dans mon common.mk.

Enfin, avec un peu de chance, je pourrai enfin faire mon tuto "comment utiliser AnimEDS" ;)

In devkitpro packages, there is a tool that convert .elf compiled files and into a single .nds ROM image: ndstool. Hopefully, it is still able to produce both types of headers, you just have to request it with -h argument. And luckily, I already had replaced the default makefile rule that uses ndstool in my own common.mk helper, so I don't need to mess with the contents of /opt/devkitpro to get working NDS files again... and be able to load contents in AnimEDS. Tuto-writing can at lasts start (as soon as the temperature drops under 30°C, that is)

 

Sounds like it was all over ? Well, there's a bit more of it. While I was debugging desmume, I trigger another issue that makes desmume-0.9.11 crash on my Ubuntu laptop when it encounter a symbolic link. A bit of bug hunt located a pretty trivial error in vfat.cpp. I'm proud to say that this is my first accepted pull request on a homebrew-related project ^_^ 

 

So

• I need to use the desmume-cli version I recompiled (0.9.12)
  
• desmume-cli --slot1 R4 --preload-rom --slot1-fat-dir FAKEROOT_DIR TOOL.NDS

• with 0.9.11 (still what's shipped on Ubuntu 22.04 :P) I frequently use desmume-cli --load-type=1 --gbaslot-rom=DS/Dreams/Dreams.nds DS/Dreams/Dreams.nds --nojoy=1 to run standalone games.

FlatWorld : public iWorld

Bon, je laisse un instant les commentaires sur Ori et Link's Awakening de côté, les pixels studies et compagnie. Les enfants commencent à me demander s'ils peuvent essayer les niveaux dans la forêt de Bilou, et j'ai une idée un peu plus claire du moteur de jeu que je voudrais avoir pour pouvoir le réaliser.

La première étape va être de faire en sorte que les propriétés du niveau soient conservées dans un tableau séparé, plus dans l'emplacement réservé aux couleurs d'une des deux couches de graphismes (une des plus vieilles fausses-bonnes-idées du projet).

Il faudra adapter l'éditeur de niveaux, mais ce sera pour la deuxième étape. Avant ça, j'utiliserai un "extracteur automatique" pour les "vieilles" maps (comme celle de School Rush et Apple Assault).

Je vais essayer d'avoir un bon design de classe dès le départ ce coup-ci, avec un type pour les données du moteur physique, l'implémentation qui reste un détail et iWorld qui est le seul élément connu du reste du code.

It was about to be a post on how I'm refactoring the Map/World/Camera classes to support my new tile types plans. And then I wanted to quick-check what I had so far with School Rush and problems kicked-in. I couldn't get the debugger handling it properly on my old laptop, and when I tried a rebuild on my fairy's laptop with "latest" devkitPro, I just got a blue screen reminding me that I should have dropped EFS years ago as it is no longer supported by the devkit team. All the previous tricks I could remind of didn't help.

J'ai voulu réessayer de faire tourner ça dans SchoolRush pour voir, mais je n'arrive qu'à avoir un écran bleu quand je compile avec le "dernier" devkitpro. Un conflit avec EFS, semble-t-il ... ou bien j'ai fini par oublier comment je devais invoquer le programme, mais

• ni --load-type=1 ne semble marcher
• ni un build plus ancien
• ni --cflash-path=SchoolTest (et recherche dans les fichiers)

Un premier problème que je parviens à identifier, c'est lseek(..., SEEK_END) qui renvoie -1. Pas bon, vu que le code d'efs va chercher à comparer la taille trouvée avec celle pré-enregistrée. Et si ça foire avec lseek, c'est apparemment parce que open("fat:/SchoolTest.nds") échoue avec un beau ENOENT ... pourtant ce nom provenait d'argv[0]. Bref, c'est de nouveau la saison des guru meditations...

Par contre, le commit précédent marchait sans problèmes sur 'grizzly', mon vieux laptop de 2007 qui utilise toujours un ancien devkitpro. Et mon nouveau code passe sans problème la découverte du système de fichiers embarqué quand il est compilé sur grizzly. Au point que j'en viens à me demander si j'ai jamais fait un build de SchoolRush sur le nouveau système... Fort peu probable, en fait vu que le système de highscores dépend du stylet (décembre 2018) alors que je n'ai corrigé le bug d'intégration du stylet avec le nouveau devkitpro que 6 mois plus tard.

Using the old desmume-cli on newest devkitpro and investigating with their libfatdir sample program, I'm tempted to say that --cflash-path=SchoolTest should have worked (it will work some hours laters for whatever reason -- typically meaning 'make clean' left some stuff dirty), and that the --gbaslot-rom thing is the one that is truly broken with the new devkitpro setup.

And I guess I was too tired to realise I was trying to remote-debug SchoolTest.nds using the LevelEditor.elf image ... So I'd better go to bed sooner tonight.

Je sens que je vais archiver le setup devkitpro de grizzly sur mon nuc-à-tout-faire, moi.
mais, en utilisant grizzly-desmume-cli --cflash-path=directory/to directory/to/SchoolTest.nds, je peux faire tourner le code (c'est l'implémentation pour "cartouche GBA" qui ne marche plus, apparemment).
et en débuggant ce code-là, il apparaît que le destructeur d'InfiniMap se voit appelé lors du premier getflags()... c'est supposé être un iWorld, mais il a une vtable de Vblcallback ...

Et si desmume sur grizzly ne se laissait pas débugger avec ddd c'est parce que ... J'avais chargé l'éditeur de niveau dans ddd pendant que l'émulateur tournait le moteur de jeu et SchoolRush. Eh oui. Je vous en prie, balancez votre vanne préférée sur la quarantaine dans les commentaires.

touchInit()

J'espère que ce sera la dernière surprise dans la branche "mise à jour de mon kit de développement DS"... Après avoir enfin réussi à avoir des programmes qui tournent à nouveau sur la DS (et dans l'émulateur, au passage), je finis par me rendre compte que plus aucun de mes widgets ne fonctionne. Au point que j'en viens à soupçonnner quelque-chose dans le code qui relaie les mesures depuis le composant SPI en charge de l'écran tactile à travers le processeur ARM7 pour être exploité sur le processeur ARM9. D'autant que tous mes programmes utilisent un code ARM7 "custom", chose qui ne sera forcément pas testée lors des mises à jour de libnds, devkitARM et leurs sbires.

Mais mon code ARM7 voit toujours bien son gestionnaire d'interruption appelé, recompiler un des programmes d'exemple avec mon code ARM7 au lieu de la version officielle marche toujours ... Ou en tout cas, c'est l'impression que ça donne au premier regard. En débugguant de plus près, je constate que mon code sur l'ARM9 reçoit bien des 'touchPosition' en bout de chaine, mais chose curieuse, deux paramètres (px et py) sont toujours nuls. Il s'agit des valeurs traduites en pixels, à l'aide des paramètres de calibrage. Et le programme d'exemple fait pareil: il ne nous donne que les valeurs "brutes".

En réalité, il faut maintenant appeler une fonction "touchInit" pour appliquer les données de calibrage, et la version du devkitpro que j'avais installée avait fait la mise à jour correspondante dans le "code ARM7 par défaut", mais pas encore dans les programmes d'exemple utilisant du code ARM7 custom ... On va finir par y arriver.

.arm7.elf

écran tout blanc sur une DS, cascade de message d'erreur "MMU7 write32 to undefined register 044xxxxh = 00000000h (PC:00000000)" produits par desmume, avec des valeurs xxxx commençant je ne sais pas trop où et qui continuent de 2BD4 à 3A34 au moins, et ça même si j'essaie d'attacher un débugueur sur le processeur ARM7.

Il y a clairement quelque-chose qui va de travers avec les programmes recompilés sur mon NUC et sur le nouveau portable avec la dernière version téléchargée de devkitPro. Pourtant je parviens sans difficultés à recompiler les exemples. En essayant de retrouver la commande qui fait appel à ndstool -- cet outil permettant d'emballer deux programmes jusque-là tout à fait classiques (format ELF) en une image de ROM nds. Et en relisant la ligne de makefile produisant "lib/ppp7.arm7" à coup de copie de section de fichier (outil GNU 'objcopy) je suis pris d'un doute: et si la technique passant par objcopy était devenue obsolète pour l'ARM7 aussi. Après tout, j'ai réussi à compiler les sources avec le nouveau devkit, mais est-ce que j'ai essayé de les faire tourner après ? pas sûr.

Et effectivement, en utilisant ppp7.arm7.elf directement, ça marche beaucoup mieux. 'faudra que j'aille corriger tout ça.

4MB ?

Bon, je dois avoir quelque-chose de foireux dans la configuration de mon système de build avec le dernier devkitarm que j'ai installé: la plupart des outils prennent soudain une taille de 4MiB... avec plein de vide au milieu du fichier ...

Première question, est-ce que ce problème est déjà présent dans le fichier .elf, ou est-ce quelque-chose que j'ai introduit au moment des conversion vers le format .nds ?

J'utilise pour ça l'outil objdump, et il y a déjà quelque-chose de louche: vous voyez ces vaddr et paddr ? l'une est une adresse virtuelle, que les données doivent avoir pour que le programme tourne bien. l'autre... bin c'est la première fois que je vois des valeurs différentes pour ces "adresses physiques"
Et en particulier, une de ces commandes de chargement va utiliser une adresse "physique" 4MiB plus loin que le début de la RAM de la NDS.

Si je croise ces information avec la liste des sections, disponible un peu plus bas, j'ai une correspondance (grâce aux offsets à l'intérieur du fichier ELF) avec une section baptisée ".twl" -- là aussi, c'est une première pour moi. C'est en tout cas bien les bytes qui correspondent à ce qu'on trouve au bout du gouffre du fichier .nds, aux alentours de 4MiB.

Renseignements pris, cette section contient des instructions spécifiques au démarrage pour DSi (et son TW Loader). Une petite mise à jour de mes makefiles pour éviter le passage par un fichier .arm9 (version pré-applatie du contenu du fichier .elf) et c'est réglé: l'outil ndstool qui construit les .nds est maintenant suffisamment évolué pour manipuler lui-même les .elf, comme dit WinterMute.

Et au passage, une simple utilisation de stringstream pour des manipulations de chaînes me coutait 250K dans runMe (qui autrement ne prend "que" 500K).

Voilà qui cloture (enfin) la branche "latest-devkitpro"

Wformat-truncation

Pretty impressive new feature of gcc/g++ available in the latest devkitarm.
Look at that.

MapWindow.cxx:377:23: warning: %i directive output may be truncated writing 

    between 1 and 2 bytes into a region of size between 0 and 9 [-Wformat-truncation]
snprintf(msg, 32, "@%i,%i : %s [%ix%i]",xpos, ypos, why,
                   ^~~~~~~~~~~~~~~~~~~~~
MapWindow.cxx:689:12:      report("editing meta-layer");
                                  ~~~~~~~~~~~~~~~~~~~~
MapWindow.cxx:377:23: note: directive argument in the range [8, 16] 

MapWindow.cxx:377:23: note: directive argument in the range [8, 16]
 note: 'snprintf' output between 32 and 42 bytes into a destination of size 32

- gcc detected that I'm calling that snprintf function with a value of 'why' that is actually the "editing meta-layer" string, which is 18 bytes long
- it understood that this and some numbers had to fit within 32-bytes output
- the format characters only take 9 bytes
- xpos and ypos are 16-bit values, needing at most 5 characters to be rendered on-screen
- 18 + 9 + 4 = 31. that's the case where all the numbers take only 1 byte. We have barely enough room to display the message (and its terminating zero character)
- 18 + 9 + 5 + 5 + 2 + 2 = 41. That's the case where we have all numbers using their maximum size. Note that GCC/G++ could guess that we'll only use numbers between 8 and 16 by looking at  blockop?16:8 argument!

Having such thing can be super precious when you know what's going on and want to harden your software. Hopefully, there is no overflow expected here. Only truncation. And since the purpose is to put a message on a 32-bytes wide line, I'm fine with truncation here. I'll have to tell that to the compiler the best possible way with some #pragma.

edit: oh, actually the compiler is even smarter than I thought: it can tell whether you checked for the return value and won't bother you if you handled truncation with an if (needed > sizeof(msg) - 1)

If the output was truncated due to this limit, then the return value is the number of characters (excluding the terminating NUL byte)  which would have been written to the final string if enough space had been available.

Oh, and by the way,

*snprintf() write at most size bytes (including the terminating null byte) to str.

So in my code where I want 32 characters on the 32-char-wide screen, I should have a 33-bytes buffer and pass 33 to snprintf.

Another devkitpro update

Another laptop update ... The previous one started to act pretty weird regarding AC power. I survived a couple of week with the old (2007) laptop, enjoyed the music collection it has and the larger screen. This one is more similar to the faulty one with a 1350x768 screen, but it has SSD.

Well, it was also the opportunity to try dsgametools with the latest devkitpro. And it was pretty disturbing. At first, you now have to install a package manager first before you install what you need. It could have been done with a custom apt-get setup but they opted for pacman with a binary package you have to pre-install from their github. Not really the way I believe open source should work ...

Pour bien démarrer le développement homebrew, que ce soit sur NDS ou GBA, une seule addresse: devkitpro.org. La procédure d'installation a pas mal bougé depuis la dernière fois, par contre. L'équipe de Wintermute est passé à un dépôt pacman (pour "PACket MANager", hein. Toute ressemblance avec une pizza au citron n'est que clin d'oeil de geek), avec la nécessité de télécharger leur version binaire de pacman (pourtant un outil fréquent dans les distributions linux) avant de continuer.

Les utilisateurs windows auront peut-être une expérience plus proche de leurs habitudes avec l'installateur .exe ... Un peu déboussolant pour un vieux briscard de sourceforge, mais j'ai fini par en venir à bout et mon laptop tournant un ubuntu bionic LTS 2018 est maintenant prêt à me râler dessus vu que les réglages par défaut de g++ 8 n'ont pas grand-chose à voir avec ce à quoi mon code était habitué.

I'll keep the new error messages and improved warnings of g++ 8.1.0 for another post. Here, I missed some headers or other stuff to rebuild everything

• errno definition for dswifi ... that is likely an old one. manually installing sgIP_errno.h apparently fixed things. I'd prefer to get the sources of current dswifi to ensure everything is fine. Hope I'll find them.
• load_bin,load_bin_size as well as bootstub_bin, bootstub_bin_size (for nds_loader_arm9, used in runME and self-upgrade features) are missing. Iirc, they should be built from .bin files ... They are still in libppp9/data ... I'll have to find out why they were not processed.
• there's a weird warning about __sync_synchronize() which is invoked when I have a static object. I have a workaround, but I really wonder why they introduced that in newlib...

The latest devkitpro

• [solved] latest runme crash with stack=0 when loading the title screen
• runme triggers a crash of desmume-cli, version 0.9.11 when --cflash-path is used to grant access to data items
• same runme can be launched when no --cflash-path is provided
• same runme works fine when emulated on old desmume (0.9.6, 32-bit, running on old laptop), even with --cflash-path
• same runme crashes when emulated on old desmume (0.9.6) rebuilt on 64-bit system, with --cflash-path
• SchoolTest can read the title screen, but suffers the same "stuck-on-the-title-screen" bug as observed on the Androïd emulator
• desmume 0.9.11 apparently doesn't emulate bad address / invalid instruction. That's not going to help.

Sounds like there will be some guru meditation in the upcoming weeks...

Si les tests automatiques avaient plutôt bien supporté le passage d'un vieux devkitpro à un plus récent, les outils du type "runMe" et le test du jeu s'en sortent moins bien. Il n'y aura probablement pas de "release Noël" de School Rush ...

First step to sort that out would be to make sure I can see last command the parser tried to parse. That should already be mentioned in the "die()" function, but with such a stackless-crash, it is unclear it would be possible to call a function at all.

Second priority will be to figure out whether the "latest devkitpro/libnds-1.5.12"  team still properly support the "register exception handler" feature.

Finally, I'll have to try freshly compiled SchoolTest against my old desmume, just to check where the regression is.

3 days

File copies in progress. I could get the unit tests and the editors of dsgametools succesfully built by the latest devkitpro installed on my BMx, after all. But without the copyrighted content of SchoolRush, the unit tests won't run ^^".

I'm a bit disappointed by 'terminology', the new terminal+file explorer from the Enlightenment project, esp. because its 'set terminal background' command (tybg) doesn't seem to work, neither do the fancy 'tyls' command. 

I'm kinda scared, too, because it looks like emacs is doing weird rendering. And I'm afraid this is something related to my graphical environment rather than related to emacs itself ...

PS: file copied. Unit test succesful

7 days!

Here I am, back on my BMX because my 2007 "grizzly" thinkpad is no longer operational. I cannot call it "dead", but the battery no longer works, meaning that using it for arm-chair development in the evening has turned highly improbable (with improbability equal to 42, to be precise).

I'll give myself 7 days to try and compile SEDS and LEDS with the latest devkitpro on this box. If that's not enough, I'll just import my damn' old "devkitpro 32" and keep going.

Me revoici sur mon BMX: la batterie de mon autre ordi m'a complètement lâché. Certains des éléments que j'avais pointé en mai comme posant problème devraient fonctionner mieux maintenant que j'ai restructuré mon code, d'autres ont toujours besoin d'une mise à jour. Je me donne 7 jours pour y remédier. Passé ce délai, je récupérerai mon gros .zip avec l'ancienne version de devkitpro que je traine depuis Apple Assault, et basta.

En direct de Xenial

Voici la relève. Un laptop BMX quad-core avec un Ubuntu Xenial Xerus fraîchement installé (LTS 16.04).

Première bonne nouvelle: il aura suffi d'un apt-get install desmume pour avoir un émulateur capable de faire tourner la dernière version de Bilou. Le support du DLDI a apparemment été bien amélioré puisque je n'ai plus besoin de donner du --gbaslot-rom pour que le jeu fonctionne.

I'm testing a new laptop, thus a new Ubuntu release and ... well ... why not trying out the latest DevkitPro toolchain ? So far, I can easily run homebrews on desmume emulator (easier than with former ubuntu flavours), and it was trivial to install devkitPro on the beast. I'll take some time to discover all the small things I have to fix to bring my code with something compliant with "devkitpro r45". Please allow me to be a bit brief tonight.

Deuxième bonne nouvelle, il suffit de télécharger le devkitArmUpdate.pl depuis devkitpro et d'exécuter perl devkitARMupdate.pl dans le répertoire où il a été téléchargé pour se retrouver avec un kit de développement DS (ou 3DS, ou GBA, etc, d'ailleurs) fonctionnel, capable de recompiler tous les bons vieux exemples -- ce qu'il fait d'ailleurs très bien d'un "make" dans ~/devkitPro/examples/nds.

Premiers bémols: ce laptop a un pavé numérique à la place des touches "home/end/page-up/page-down", je loupe sa touche "CTRL" une fois sur deux (CTRL et Fn sont inversées par rapport au thinkpad que j'avais jusque là), et il lui manque un bouton du milieu pour son touchpad.

Maintenant, le gros morceau: il va falloir s'assurer que le nouveau devkitPro sait toujours compiler Bilou ... ou plus exactement adapter le code de Bilou au nouveau devkit. 
pour libgeds

• les fonctions de raccourci pour la programmation des modes vidéo sont marquées obsolètes. Il faudra que je trouve ce que le sieur Wintermute et ses accolytes nous proposent à la place.
• le nouveau compilateur est plus pointilleux sur les types entiers. En particulier, dans le code de lecture des animations AnimEDS.
• je ne vois plus de diropen ou dirnext que j'utilise dans FileWidgets ... ça, c'est plus problématique. Il faudra que je convertisse le code correspondant vers opendir/readdir. Ça aura aussi des répercussions sur le code de Noda (efs).
• le nouveau "die.cpp" a besoin d'un en-tête (nds_loader_arm9.h ?) hébergé à l'intérieur de runME, mais runME ne compilera pas sans libgeds. Il faudra y remédier.

pour les tests automatiques:

• mercurial, linux-libc-dev, vim, libc6-debv-i386, libstdc++-4.9-dev, libx32stdc++-4.9-dev et surtout g++-multilib.
• les fonctions DMA de la libnds sont désactivées et remplacées par des memcpy, vu que le PC aura un peu du mal à émuler les copies à travers les registres de la DS. Par contre, du coup il me manque des déclarations de registres dans videoGL.h... il faudra que j'aille voir sur mon bon vieux grizZly si j'ai fait des patches sur les headers de la libnds pour que ça passe...

guruMediationDump()

I love it when my wish have been granted even before I'm aware of the wish. In this case, devkitpro team has revamped the way exceptions are handled in libnds "r32". The large "wizardry" part of the guru mediation screen, that dumps registers and all has been extracted in a guruMeditationDump() library function, and the default handler is a 2-lines function that definitely locks the DS once the dump has occured.

Ah, bin au moins, je ne me fatiguerai pas trop à retrouver comment-j'avais-modifié-guru-meditation-pour-mon-usage-personnel: l'équipe de devkitpro m'a mâché la besogne en plaçant tout ce qui était utile dans une fonction et tout ce que je ne voulais plus (ou presque) dans une autre ^_^. Je vais pouvoir reprendre mes tests sur la school zone très prochainement (dès que je n'ai plus les yeux qui piquent et "OIUY" imprimé sur mon front à la fin de la journée, quoi :P)

Instead, I used in "r21" to define a die() function that allows me to perform recovery such as leaving to moonshell or inspecting memory. So all I should need is to redefine my own 2-lines function and use setExceptionHandler() rather than defaultExceptionHandler(). Let's see whether that helps me figuring out why the school zone is so freaky.


edit: it looks like using scanKeys() in die() is not such a good idea. With the r32, it relies on some working communication between arm7 and arm9, which afaik requires the Fifo (and thus the interrupts) to work. If for some reason the crash comes from an interrupt handler, you'll find yourself unable to see keys changes. Polling the following register could help:

//!     Key input register.
/*!     On the ARM9, the hinge "button," the touch status, and the
     X and Y buttons cannot be accessed directly.
*/
#define REG_KEYINPUT    (*(vuint16*)0x04000130)

and checking the value of REG_IE and REG_IF could explain the situation as well.

meta_buttons_shown=false

Comme je devais tester une imprimante, ce week-end, je me suis imprimé quelques fichiers sources de l'éditeur de niveau, histoire de comprendre d'où vient le comportement erratique des "meta-buttons", cette petite palette en haut à droite de l'image qui permet d'indiquer quelle portion d'un niveau est solide, où sont les pentes, etc. Pour pouvoir éditer les "arènes" d'Apple Assault, je les avais rendus "escamotables", mais c'est loin d'être un succès. Ils donnent l'impression d'être actifs ou non indépendamment du fait qu'ils soient visibles ou non. Malheureusement, le Level Editor est aussi le dernier outil qui n'a pas encore été "porté" pour la nouvelle release du devkitpro. Du boulot en perspective, comme la réactivation de la lecture des répertoires, les nouveaux mécanismes pour initialiser la console, etc.

• loadNDS_Vram turns into runNdsFile : http://dsgametools.svn.sourceforge.net/viewvc/dsgametools/trunk/SpriteEditor/source/main.cpp?r1=617&r2=824
• convert to the new console system : http://dsgametools.svn.sourceforge.net/viewvc/dsgametools/trunk/runMe/arm9/source/main.cpp?r1=735&r2=750

at least those two must be done and checked before I can start fixing the huge mess that appeared on the Level Editor user interface when I tried to make the "meta-buttons" a pop-up widget... Yes, LEDS is the latest of my tools that has not received a revision since I switched to "devkitpro 32" ...

edit: done... maybe ?

Welcome, libfat 1.0.9

While I was busy on a tons of things (including building up the first prototypes of AnimEDS) in february, Wintermute and his friends at devkitpro did a major revamp of the libfat, separating "what's good for the DS" from "what's good for the Wii". When it comes to mass storage performance, the two beasts are strongly different ... L1 cache, data transfer speeds, amount of L2 memory ... The release (1.0.7) I used in my "dkp-r32" setup tried (and failed) to provide a uniformised solution. I tried a few hacks that at some point looked to improve the performance, but didn't find the time to quantify the boost in a systemic way. I offered a patch, but ignoring the project's habbits made it doomed to /dev/null.

Hopefully, the new build seems to provide good performance again (PC->AP->DS transfer rates of 64-80KB/s at home).

Oh well, one annoying difference remain: i *have* to apply a DLDI patch manually for SCSD device (which used to have a built-in driver in former libfat). I also have an issue with directory scanning ... I hope it won't take too long to figure out what it is. it looks like I underestimated the MAX_FILENAME_LENGTH ... again ...

J'étais tellement à la bourre en février que j'ai complètement loupé la sortie de la version 1.0.9 de la libfat. Heureusement que je suis repassé jeter un oeil sur le forum de devkitpro après avoir tenté de refaire le point sur l'état du cache la semaine dernière, sinon j'aurais bêtement perdu plein de temps. Enfin, donc, une version qui traite la DS indépendamment de la Wii et de la gamecube, même si j'ai du ruser pour contourner les problèmes de __io_dsisd manquant et patchouiller mes programme pour m'ajuster à une augmentation de MAX_FILENAME_LENGTH visant à améliorer le support d'UTF8. Enfin, c'est réglé.

Une vitesse de transfer entre 64 et 80kB/s (@home en utilisant le wifi entre le PC et le routeur et entre le routeur et la DS), c'est tout ce que je demandais.

Bon, maintenant, 'faudra que je regarde comment faire en sorte que ma fonction die() marche à nouveau ...

(PS: oui, j'ai testé tout ça sur la PHAT de ma fée, histoire de limiter la casse et les pertes de données au cas où... honte à moi ^^" ... quoi que, avec le binaire de SEDS qui crèe systématiquement des fichiers de taille 0 datant de janvier 1979 ...)

Et ... qu'est-ce qu'on fait maintenant ?

Bion première release de AnimEDS: check, mise à jour de SEDS : check. Quoi d'autre ?

En premier, une petite uniformisation de mon environnement de compilation ne serait peut-être pas une mauvaise idée. J'avais identifié un problème de performances dans la libfat pendant les congés de Noël ... ça pourrait valoir la peine de revenir dessus histoire de soumettre un "vrai" patch pour le projet devkitpro. Pour l'instant:
- démarrer SEDSgama.nds depuis le menu R4 et faire un "QUIT" vers rungama.nds: ok
- mise à jour interne de SEDSgama et rungama: ok, mais lent (compilé sur beetle)
- démarrer SEDSgama depuis runbeta: ok, mais empèche d'utiliser le loader pour sortir de SEDSgama.

Ensuite, on pourra voir pour les histoires d'effets miroir dans AnimEDS, la définition d'autres structures de sprites (changer le nombre de membres et l'utilisation des pages de sprites) et le support de tout ça dans le moteur de jeu (eh oui, l'idée, ça reste de faire des jeux).

swiSleep()

Je suis resté sans support de la mise en veille pour mes programmes jusqu'en juillet 2009, puis j'ai copié un petit bout de code qui permettait de s'approcher pas trop mal de cette fonction. Thoduv dans un post précédent, expliquait alors qu'il y avait techniquement moyen de faire mieux, que l'approche était en cours d'intégration dans la libnds, et que ça lui donnait du fil à retordre pour son "Lapinou Jumps" ...

Du coup, je me retrouve maintenant avec deux bouts de code qui tentent de mettre le programme en veille : mon "code utilisateur" sur l'ARM9 et le "code système" sur l'ARM7... et de temps en temps, le programme qui éteint la console au lieu de se mettre en veille >_<

Here's how 'sleeping' is implemented in the "devkitpro-r32" : there are SLEEP_DISABLE and SLEEP_ENABLE messages that can be sent to the powerValueHandler on the ARM7. When sleep is enabled on the ARM7, systemSleep() is invoked by inputGetAndSend() directly when the lid is closed for more than 20 frames (1/3 second). The ARM9 "acknowledges" this by echoing the PM_REQ_SLEEP message and the ARM7 side then proceed to the suspension of execution through the hardware power management register. swiSleep() on the ARM7 is the core of this shutdown. The rest is turning off the speaker, changing LED stats, etc.

So far, it makes my programs randomly shutdown with low probability when one closes the lid. I still have to define whether it's due to an intermix of the old code with the new lib or to something more intrinsic to swiSleep()... That's not really a problem for runme or apple assault, but it will definitely be a nuisance for the editors. Also, I haven't seen anything sending _SLEEP_DISABLE or _SLEEP_ENABLE, though, while it would be a good thing that I could prevent the DS to enter sleep mode in the middle of a wifi transfer. I'm also unsure of the reason for that 1/3 second delay, and I fear it could lead to gameplay issues (the game state change too much while I'm closing the lid).

dsgametools todo list

La nouvelle année semble un bon moment pour refaire le tour de ma "todo list" ... surtout combiné au fait que je viens de changer de devkit et que tous mes programmes (runme, seds, leds) auront besoin d'un brin de polish pour fonctionner sans hics dans ce nouvel environnement. Et pourquoi pas commencer par cet éditeur d'animation qui reste dans les cartons depuis si longtemps ? ...

Looks like shortening my todo-list could be a good #1 new year resolution (as far as homebrew deving is concerned. Fixing the dishwasher of course has higher priority ;)
Right now, the "animation editor" is receiving some more attention, but sprite and level editors will need some polish to work flawlessly with the new-and-improved devkitpro. I'd like to have a sketchy prototype of it by end of march, but Q1 is likely to be fairly intense at work :P

SEDS	LEDS	runme	engine
non-square sprites (32x40, 32x48), flood fill for 16x16 grid, more tileset storage areas, complete palette edition mode, release	meta-tiles buttons bug, gobno bug, cursor bug, easier meta-tile edition, some more release (w/ biokid levels), copy/paste/save of areas, map resizing	3D model viewer, text editor, debugging r32	improved vertical scrolling, limit scope of external actions, state initialisation expressions, slope landing, and many more.

libFAT : hide and fseek ...

Well, initially I thought that the performance issue of TCP transfers would be worth another investigation-novel-styled post, but being somewhere between Christmas and New Year's Eve didn't allowed me to do so. Or maybe just digesting the source code of libfat, figuring out what kind of access pattern made it so slow and what more subtle access pattern was making my new cache policy go wrong was already demanding enough.

The patch is not ready for inclusion in libfat according to devkitpro's standards. Yet, having a look at it is the only way for you to have an idea of what can be changed to fix the performance issue.

The core idea of this patch is to allow pages in the cache to reflect only partially what is (should be) on disk. The new readable field gives the position in the page where we leave 'valid' data and enter uncharted, here-be-dragons, area which content shouldn't be relied upon. I proceeded with additional extensive checks (64M movies transfers, md5 checksum verification and fsck on the media card) and fixed one last bug affecting end of files. The patch released on Tuesday is thus invalidated.

Remember, kids: FAT is the worst filesystem ever.

Oh, and btw, server.pl, the PC-side data source for a PC-to-DS wifi transfer can now be invoked so that it will cycle within a list of files, allowing one to efficitently transfer the files one after the other, e.g. :

server.pl neoflash/*.nds [DS_IP_ADDR [PC_IP_ADDR]]