Have you tried melonDS ?

Have you tried using melonDS for DLDI-based homebrew? It's my personal preference, it emulates the DSi too, and it's getting GDB support for debugging soon (though not yet). (@asie.pl) [...]
It's free software (doesn't even require any dumps for DS mode, though hardware dumps are required for DSi emulation) and I use Linux exclusively.

This post was a draft last updated on 20th November ... Asie's comment was from March 2023, after I tried to get my demo running on 3DS and believed it wouldn't be hard to fix DLDI support in desmume... (but I was wrong)

And today I just notice that I do have "hobby/melonDS" folder in my fresh-Debian laptop. 111MiB of cmake & dependencies later, I can rebuild the emulator (got hell lots of warnings, but it did build) and managed to make it load and play the current "Three Rooms of Dreamland" demo.

It has polished UI for setting keyboard/joystick, it has much more stable sound output than desmume had and did load my files properly, despite I couldn't do it from the command line yet (EFS files wouldn't be found unless I use the menu to load the .nds)

It has a nice "DLDI" entry indeed, where you can define some appealing "sync SD to folder" ... but I'll have to read more documentation if I want to make any use of that. If it can let me use Level Editor for DS straight on files hosted on my laptop, that could excuse the lack of a GDB stub ...

No fancy VRAM preview or any similar power-emulator as those I've seen on 8-bit and 16-bit console emulator either ... sigh.

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 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
  

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.

couldn't list the directory.

For some reason, recent desmume (0.9.11) shipped with my Ubuntu distro cannot list files in directories passed as --cflash-path.
and this time, my 'old version' of desmume binaries are 32-bit while the system is running a 64-bit OS. I had multiarch-support package installed, but not libc6:i386, nor libstdc++6:i386, and as a result, and I just had a weird message about the 'file not being found', while it was obviously there. Once those core packages had been installed, I got more coder-friendly error messages mentioning which library was missing, so I could just find the corresponding package with apt-file and install e.g. libsdl1.2debian:i386, libglib2.0-0:i386 and the like.

And eventually, I could run a copy of desmume-cli so old that --version isn't even supported :P 0.9.6 svnr3873 dev+, it says. And that one granted me with proper file loading, so I'll be able to investigate whether my edits on the extended monsters editions are OK or not ... next time.

(and no, this time adding --load-type=1 did not help)
(bug confirmed with filesystem/libfat/libfatdir example from devkitpro)

.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.

Panic! GameInfo reading out of buffer!

Pretty weird error message. I don't know what triggers that. It doesn't interrupt the emulated program but kills the emulator itself, even when we're running in gdb-debugging mode. It happens while parsing some line of text in my "wave.cmd" script unless I invoke GobAnim::setWindowed() on an animation earlier on. The object parsed when the crash occurs has no relationship with the GobAnim that gets windowing-enabled.

• Panic! GameInfo reading 302251 out of ROM (302254)! 
• halting emu: ARM9 PC=020406A0/02000F0B, LR=0204069C 
• ARM9 halted 
• halting emu: ARM7 PC=037F9B84/037F9B7C 
• ARM7 halte

The crashing address happens to be within memcpy.

  break *0x20406a0 if $r3 + $r0 > 0x300000 && $r0 < 0xb000000

could be working, except that GameInfo doesn't start at offset 0, but apparently rather at offset 0x08000000.

A bit more digging (setting the right breakpoint, using one more desmume patch to reveal registers R0 through R3) finally allowed me to get a stack trace....
And the offending memcpy was part of a buffer refill for waves.cmd file. For some reason, by incrementing the size, I hit a threshold where one more copy is needed, but then the very last bytes can't be read because the emulator believe they should always pick a 4 bytes from the current position (instead of an aligned 32-bit word holding the byte). Simply adding a zz.zz file that will come past the waves.cmd file make the code work again.

runme + assault = todo

I'd love to have the time to provide a real tutorial for people to start working with libgeds. So far, the best I have is a package with 8-bitifed graphics for AppleAssault and the corresponding game/character scripts... which -- thanks to some work I did a few weeks ago -- now also comes with a copy of RunMe that can run all of that. Maybe that will at some point make it more interesting to start working with the Game Engine for DS.

Of course, because runME is a tool primarily designed to transfer files, it will not exactly be easy to start a game there.

Bon, j'avoue, j'adorerais avoir le temps de travailler sur un vrai tutoriel pour le système lib geds, mais jusqu'ici, la seule chose qui s'en rapproche un petit peu, c'est une sorte de kit avec les graphismes de Apple Assault en version 8-bit et les script correspondant pour les personnages et pour le jeu. Et grâce au travail de ces dernières semaines,  tout ça i tourne maintenant avec une version récente de runme. youpi. Peut-être que ça rendra les choses plus faciles pour ceux qui veulent commencer à travailler avec le game engine for ds on peut toujours rêver...

click 'offline', then 'cmd'	click 'A' to pick one of ASSAULT*.CMD, and then click the name you want to run	press now L+A to load the script into the memory	and now press L+Y to process that script to the end.

Évidemment, le programme 'runMe' est avant tout un outil de téléchargement. Donc il faut un peu chipoter pour pouvoir démarrer son programme:  passer la détection réseau , par exemple, puis choisir le fichier qu'on veut démarrer, et des commandes un peu barbare du genre La+À ou L+y pour démarrer la lecture du script ou pour l'interpréter sur la DS.

When I want to run this, I do it with desmume-cli, using --cflash-path=AA-efsroot (which is in the 'runMe.zip' archive) and --load-type=1. But that only works in Linux. For windows user, you'll have to go into config->slot2 and setup the directory manually (I just hope for Windows users that they can somehow save that configuration)

Il faudra aussi s'assurer que l'émulateur a accès au fichier du jeu qu'on veut essayer. Moi, je fais ça à la ligne de commande dans Linux, mais évidemment, les gens qui travaillent sous Windows devront passer par les menus de configuration de desmume pour avoir la même fonctionnalité ( voir l'image).

Voilà, avec tout ça vous avez la possibilité de tester le jeu que vous avez vous êtes en train de développer, mais malheureusement, s'il y a des erreurs dans le script, c'est encore très laborieux de les trouver et de les corriger. On peut faire mieux avec l'outil de test automatique que j'ai développé pour mettre School rush au point, mais c'est un truc qui doit être compilé à part. Et pour l'instant, il faut même le compiler à chaque fois qu'on veut essayer de traiter de nouveaux script pour un nouveau jeu, donc il faudrait que je fasse appel à l'équipe pour avoir une variante qui tourne sous Windows histoire que les jeunes puissent essayer de faire le même. Mais voilà, l'équipe, pour l'instant c'est juste bibi. alors soit vous vous enrolez, soit de vous patientez. Ciao.

All this makes you able to try the game you're developing, but when there are errors in the script, you just have a stop with the content of the offending line dumped.
Hopefully, It can now also be checked with 'testme', the unit-testing tool for current School Rush game. (which unfortunately still requires a rebuild for Windows everytime you change the scripts you want to check).

I could really use a helping hand to get that going somewhere. Someone who's used to do builds of Linux native projects in a Windows environment. Even then, it's unclear whether I can compete with a tool such as DSGameMaker, but I still think people should have the choice ^_^

Oh, et si vous allez jusque là, la présence du "log" deviendra vite gênante dès le niveau chargé avec succès. Rassurez-vous: il est tout à fait possible de le faire disparaître: il suffit pour ça de toucher le bouton 'log' sur l'écran du bas. Et si vous voulez retourner charger un autre niveau, le bouton "beam out" vous ramènera sur l'écran avec la liste de fichier et le "clavier virtuel" (qui fait les "lettres paires" quand on garde L enfoncé, soit dit en passant).

Et pendant que vous lisiez tout ça, j'ai ajusté la position des vagues d'encre pour le "niveau retour" de School Rush...

LEDS ghost layer

Evidemment, il ne suffit pas d'appliquer le système de gestion des layers à mon programme de chargement. Maintenant que c'est au point, il faut que je convertisse l'éditeur de niveaux, puis ce sera au tour de l'éditeur de sprites et l'éditeur d'animations. N'ayant pas réussi à faire la conversion "d'instinct", je prends le temps de regarder quels sont les éléments présents sur quel layer dans l'ancienne branche de développement.

Introducing a new layers management system isn't useful before tools are converted to that system, of course. I tried the Level Editor first, but it didn't worked as expected -- i.e. the spriteset on the top screen doesn't show up. The best I could get was a weird layer that mimmic the structure of the tileset, but using plain ASCII characters.

Being for a week-end on my former laptop, I tried showing selectively the layers of an older build, and I could have the "ghost" layer appearing when showing BG1_SUB too. Curiously, it also shows when no layer at all is enabled. Let's just work on the hypothesys that the "Emulation > Layers" checkboxes in desume UI invert what is programmed in the picture engine registers, not hiding the layers. As a result, if defaults (or previous) contents of this layer is "use the same map slot as the BG3 (tileset), use the same colors and characters as BG1 (because the ghost layer is obviously *not* BG1, which is the widgets' text). then you get the ghost out of uninitialized registers.

J'avais été surpris par cette couche qui avait la forme des "planches de graphisme", mais utilisant des caractères ASCII 16 couleurs, sur le background #1. Bien sûr, ce layer n'apparaît pas quand le programme tourne normalement, seulement si je coche sélectivement les layers (une technique que j'utilisais tout en jouant à Donkey Kong Country pour essayer de découvrir les passages secrets).

Autre chose intriguante la "couche fantôme" reste présente même quand tous les layers sont dé-cochés. J'en viens à penser que desmume est programmé avec quelque-chose comme "shown_layers = program_layers XOR gui_layers" alors que l'interface laissait supposer qu'on aurait "show_layers = program_layers AND gui_layers". En clair, cocher un layer qui n'a pas été activé par le logiciel qui tourne sur la DS émulée le montre plutôt que de le cacher.

--load-type=1

It seems like I finally figured out why I had so much trouble with desmume on my new Linux. It's nice from desmume developers to warn me that DLDI would not work. Maybe it would have been nicer if using --cflash-path had automatically modified the load-type so that the tryPatch wouldn't segv while trying to operate on a NULL pointer...

Now, I'm ready to resume checking whether my mode-switching code is worth a push.

Bien ... il suffisait donc d'ajouter --load-type=1 sur la ligne de commande pour pouvoir utiliser l'émulation de carte mémoire avec desmume. Je suppose que j'aurais dû pouvoir le trouver sans faire de back-tracking à partir d'un émulateur en train de planter, mais c'est mon côté guru: plus à l'aise dans les sources que dans la doc.

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.

The lifemark

Allez, je vais tenter d'enchainer sur l'implémentation de la marque-ta-page-de-vie, parce que tout de suite, c'est moins utile quand l'illustration pour le 'punch' se fait manger à moitié dès qu'on prend un seul coup ^^"

Puis un peu de débugging, parce qu'au retour sur le menu, mon bel écran se fait cacher (pas de tile transparent sur les écrans de menu) ... donc je dois utiliser la version "normale" de desmume pour afficher/masquer les calques en cours de jeu (j'utilise d'habitude desmume-cli, la version sans interface utilisateur)...

Two great news. First, I'm almost done with that new life meter for Bilou: School Rush. The old "black rectangle" display mimick'ing some raising ink really doesn't work anymore with the gameplay hints on the bottom screen.

Second -- that happened as I tried to move a (regular) desmume window: looks like the full-fledged version of desmume (0.9.9) is now featuring a scaling filter that reconstruct curves from pixel images. And it behaves reasonably well with my pixel art.

Et là, surprise: desmume intègre maintenant un système pour agrandir l'image, avec du lissage qui donne plutôt bien dans le monde de Bilou.

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...

reverse emulator bug ?

Je connaissais le bug d'émulation. Vous savez, ce genre de bug qui ne se produit jamais quand vous testez sur émulateur et qui crashe lamentablement le programme dès qu'il tourne sur une vraie plate-forme (généralement parce qu'elle a de la vraie mémoire).

Why? I can explain easily a bug that happens only on bare metal, but not in an emulator, but this time, it's the opposite. I spent 3 evenings trying to figure out why the emulator crashed before I could explore any issue with DDD. However, on the Real Thing, I can play the game without any issue... 

If I find a way to re-build that emulator from its source, it could be interesting to implement a ring of last N jumps/calls so that we can actually track the reason of such crash. But do I still have the source+compiler combination do to so ?

Là, il semblerait que je viens de passer 3 soirées à tenter de comprendre l'inverse: un bug qui ne se produit que sur l'émulateur. Mais qui crashe l'émulateur, pas le programme émulé, sans espoir de placer des breakpoints ni rien de ce genre. J'avais fini par m'imaginer qu'un vrai "guru meditation screen" serait plus instructif que ce rapport de crash généré par desmume. Et euh ... rien. Pas de bug. Je fait les 4 niveaux deux fois, avec des morts ici et là. Sans que ça ne s'arrête. Au moins, le nouveau système de gestion de mémoire (merci, PAdM) m'a sorti d'un mauvais pas.

branch/newcollide : buggy

Voilà environ 3 mois que j'ai entammé la révision du moteur de collision de Bilou, avec pour objectif de permettre la gestion de blocs, plate-formes et autres. Je n'ai pas avancé très vite, mais le code compile et fait tourner AppleAssault ... enfin, presque. Voyez plutôt ....

3 monthes to get a first prototype of the new collision engine. I haven't been very quick on that, but at last, Apple Assault mostly work again ... well ... sort of. I'll let you judge that.
-- btw, I wonder whether desmume-cli --record-movie would be easier to use than byzanz-record for those posts. Please, allow me to debug that on-line:

# stopped by monster-player collision.
statW0->statF2 on found1 (v0 ~ :0 200 ~ :1)
statW1->statF3 on found1 (v0 ~ :0 200 ~ :1)

Makes the appleman bounce when it hurts Bilou

#hit
state4..7->statH15 on hit0
\\   [wc 1 ? we 0 < &] (256 ~ :1 512 ~ :0 0 :6 x1)
state4..7->statH16 on hit0
\\   [wc 1 ? we 0 >= &] (256 ~ :1 512 :0 0 :6 x1)

The collision halfly works, on the video above: the applemen indeed bounces and the collision is triggered. But Bilou isn't affected. Afaik, that's because something got wrong in the guardian expression (conditions between the square braces) that can no longer be true in the new collision engine. Before we actually take a transition to the "hit-to-left" (H16) or "hit-to-right" (H15) state, one must detect where the collision came from (test on 'we', other dude's variable #14, which holds centrum-to-centrum horizontal distance), and whether it was actually something that hurts (test on 'wc', the other dude's variable that indicates the matching collision bits on both active and passive collisions area). For some reason,

case OP_GETCTX:
   if (sp>=STACKSIZE-1) return oops("vCTX");
   if (c[1].data==0) return oops("!CTX");
   if ((op&0xf)>=0xc) stack[sp++]=xcontext[op&0x3];
   else stack[sp++]=c[1].data[op&0xf];
break;

Did return at the oops("!CTX") line. In that case, the expression is never true. Bilou won't ever got hurt. I must be missing something that swaps contexts in the code that manages collisions, at the root. Some gc[2]=gc[0]; on line 1742 could do the trick...

that and some silly boolean inversion in the c[1].data =? NULL condition ^^"

DSertyuiop

Parce que je vais re-travailler AnimEDS pour éviter les pertes de données, et que pour ça, je dois utiliser plus largement ABXY et un peu moins L et R, voilà un petit pense-bête de leur emplacement sur desmume-cli... quand on a un clavier AZERTY.

I'd really be happy if people using QWERTY keyboard around the world and developing e.g. games or emulators could take note that other keyboards also exists. Playing Doukutsu, Frogatto or Iconoclasts with W and Z swapped or Q and A swapped is a pain. It's obvious desmume-cli was also targetted at QWERTY given that if I swap things, I fall back to a "logical" layout with A nexto B, X nexto Y and L nexto R. But I have an AZERTY keyboard, hence the cheat sheet.

libFAT cache-cache

Après avoir instrumenté un brin le gestionnaire de cache de la libFAT, j'ai droit à une belle série de statistiques qui montrent que pour réécrire ~400K sur ma carte mémoire, il me faut au préalable lire à peu près autant (968 secteurs) ... En fait, puisque j'écris chaque paquet (~550 bytes) au fur et à mesure dans le fichier, et puisque le cache travaille par "page" de 4K, toutes les écritures sont partielles et le cache lit d'abord le contenu du disque avant de commencer à écrire la bonne valeur). Le hic, c'est bien sûr que dans mon cas, les anciennes données ne seront jamais utiles, puisque je les écraserai toutes :-P

J'essaie donc de modifier "cache.c" pour forcer une politique de "lecture paresseuse" où l'on ne remplirait une entrée du cache avec le contenu du disque que si une tentative de lecture a lieu. Il est donc possible de "préparer" progressivement un contenu à écrire et ne l'écrire qu'une fois complété. Bon, maintenant, il va falloir débugguer ça. A moi desmume, ddd et strace ...

Tout semble fonctionner sur émulateur, mais sur la DS "Phat" de ma fée, j'ai juste droit à un "FATinit failed" ... qui s'avère être dû à un petit problème de DLDI sur SuperCard SD. Après quelques hexdump et diff supplémentaires, je peux enfin vous proposer ma libfat revue et corrigée, jusqu'à 3 fois plus rapide sur les écritures de fichier.

PS: il restait un bug, donc voyez le post du 31 pour la version définitive.

Debugging sessions darker than night

Beyond Infinity, a fellow OS hobby developer back in 2002 used to twist Gandalf's quote into "I see debugging sessions coming, darker than night itself" ... I guess that could apply to the last week. After identifying the reason why DDD wasn't operating properly (not showing machine code) anymore and quickly applying a patch, I started investigating the internals of desmume's gdb stub ... the part of the emulator that allows one to perform source-level debugging as if it was a locally running program. With zeromus, we identified a couple of curious things in the emulator-debugger communication, and although we don't agree yet on how it should best be fixed, I managed to patch the emulator as well so that it behave the way I need.

J'aimais bien être développeur d'OS sur mega-tokyo. Une chose sympa avec les développeurs d'OS, c'est que comme on en prend tous pour 20 ans, on apprend à se connaître, à construire ensemble, etc. "Beyond Infinity" était l'un de ceux-là, geek de première dans sa manière de détourner les 'quotes' des grands films et livres. C'est à lui que je dois le parallèle entre les "jours plus sombres que la nuit elle-même" du Seigneur des Anneaux et ces scéances obscures de debugging ou plus rien ne semble marcher comme il se doit au point qu'on finit par débugguer la machine virtuelle et/ou le débuggueur lui-même.

D'une certaine manière, voilà qui colle parfaitement à mes activités homebrew de la semaine dernière ... Et après avoir surmonté des lignes de code sans nombre, triomphant de bugs inouïs, de haute lutte j'ai frayé mon chemin jusqu'au stub par-delà localhost:9999 pour reprendre la condition de course qui s'était infiltrée. Vouaip. Et du coup, je suis enfin en mesure de chercher pourquoi certains décors ne s'affichent pas dans Apple Assault sous "dkp-r32". Vous vous tenez bien les côtes ?

Bon, bin voilà: le comportement de fread() a changé. Il n'est désormais plus possible de transférer des données directement entre un fichier et la VRAM si la position dans le fichier n'est pas un multiple de 4. Quand on sait que la VRAM ne peut pas être adressée par bytes (mais uniquement par mot de 16 ou 32 bits) et qu'on a désassemblé quelques memcpy dans sa vie, on se dit "bon sang, mais c'est bien sûr" ... mais on a quand-même passé des heures dessus >_<

I am thus (at last) in position to think about why some of the background in AppleAssault don't show up anymore. It looks like something has changed either in newlib or in libfat that altered the way non-aligned memory transfers are handled by fread(). The problem is I regularly transfer tiles data straight from the file into the VRAM, but that the VRAM only support 16-bit or 32-bit wide writes. It is typical for a memcpy implementation to fall back to byte-per-byte copies as soon as a mis-alignment condition is detected, but in this case, it kills the whole transfer. I need to patch some pictures so that they have an even number of colours.


Là-dessus, maintenant que mon code est revenu à un état plus rassurant, il va falloir que je réattaque vaisselle et ménage ... Ma fée a beau avoir une patience d'ange, 'y'a des choses qui ne se font pas toutes seules.

cd /home/kitchen
make mrproper
/etc/init.d/dishwasher reload
cat /tmp/laundry > /dev/drier

It works ! I can't believe it !! ...

Wo, dudes. It sure has been an odd week at work, but it was even weirder after office hours when I tried to figure out what prevented Apple Assault to work... I wish I had actually typed "svn copy trunk branch/dkp-r32" before I started "fixing" the code for the new release of devkitarm.

After spending hours contemplating fifosystem.c and other hours digging into the source of DesMuME, I found no heroïc bug to fix, gained more confidence in the new tools and finally figured out that some of the assumptions I was working with (e.g. "thou shall call irqInit() before you invoke swiWaitForVBlank") were no longer true in the latest release ... and actually weren't true anymore for a while.

Migrating to the new libnds requires you to switch to the new everything ... including the latest desmume where the way to support "emulated filesystem" had changed. After I inserted a fake register whose content is dumped immediately on both ARM processors (I'm pretty sure there is similar features already, but it's faster to redo it than to locate it :P), I got capable of tracking the execution of the program ... Another modification enabled register dump after haltemu was called, which "explained" that the emulator shutdown was due to a new policy for handling not only exit(), but also abort() -- and C++ exceptions, which I had used in a tweaked way with the "devkitarm-21-based" setup I used so far.

The good news is that I now have Apple Assault running -- in a degraded mode, but running. And I have plenty of developer-friendly stuff added to my emulator to help me fix (hopefully) quickly the remaining things... It was about time : I nearly got discouraged yesterday.

Vous avez vu ? j'ai réussi à réavoir de l'Apple Assault qui s'affiche. C'est pas encore complètement rétabli, mais ça remarche de nouveau. Tout le reste, vous l'avez déjà lu dans les posts précédents :P

edit: I even managed to get sound running, although TrackSequences aren't working yet (missing the get-current-position ? no : curpos() do not rely on FIFO : it's just shared memory ... Or maybe I should ensure the oops[] array is accessed through un-cached addresses it looks to work fine the way it is, but it constantly compares against "pos == 0" ... ) That means the "trunk" is now definitely for "devkitpro-r32" (whatever it means) and that the devkitpro-r21 old things are archived once for all in tags/apple-assault-release.

SYSTEM POWERED OFF VIA ARM7 SPI POWER DEVICE

sauf erreur de ma part, je parviens maintenant à avoir le code de runme qui tourne sur desmume (version 0.9.6-SVN) quand il est compilé avec en mode "dkp-r32". Par contre, si j'essaie d'utiliser les même outils pour AppleAssault, j'ai droit à un magnifique "SYSTEM POWERED OFF VIA ARM7 SPI POWER DEVICE". Je soupçonne desmume de couper froidement toute communication avec GDB quand ça se produit, ce qui, du coup, m'empêche d'en chercher la cause >_<

IPC9@201564a send FIFO < 0x480A725C -- size 000 (l 0x8505, tail 00) (r 0x8501, tail 05)
-- IRQ delivering.
IPC7@37ff16a recv FIFO > 0x480A725C -- size 000 (l 0x8401, tail 05) (r 0x8504, tail 01)
IPC9@201564a send FIFO < 0x04010040 -- size 000 (l 0x8505, tail 01) (r 0x8501, tail 08)
-- IRQ delivering.
IPC7@37ff16a recv FIFO > 0x04010040 -- size 000 (l 0x8401, tail 08) (r 0x8504, tail 02)

Evidemment, la version "standard" de desmume (0.9.5, livrée par Ubuntu), elle, coince à l'initialisation du Wifi, et ça ne vaut donc même pas la peine de continuer à chercher. Je vais donc devoir aller ajouter l'équivalent-émulateur d'un gurumediation dans le code de emu_halt(), voire y ajouter un DEBUG_dumpMemory() ...

I think I can now get runMe running under desmume when it is compiled with my 'dkp-r32' install. If do try to use the same tools for AppleAssault, I end up with an error message suggesting ARM7 powered off sometihng. I bet the emulator doesn't try to talk to GDB any further when that occurs. Let's see if I manage to get more information by adding something helping guru meditation in emu_halt() ... and later a 'magic' fake register that allows me to track evolution.

After exploration, it turns out that something is calling `abort()` before my exception catch-and-report code could kick in. And abort() may shut power down. All this occurs because I forgot command line argument --gbaslot-rom to let DLDI code access files.

Après modification, et si j'en crois mon nouvel outil, c'est au niveau de libnds_exit.c que le processeur ARM9 s'est arrèté, juste après un appel à powerOn, qui aurait été appelé quelque part à partir de fifosystem.c (dans la fonction waitBlock, ce qui me paraît on ne peut plus louche ...) Le processeur ARM7, lui, s'est bloqué au niveau de writePowerManagement appelé depuis powerValueHandler. Ca, au moins, c'est cohérent. Le dernier message transmis de l'ARM9 vers l'ARM7 est (poétiquement) un 0x04010040, ce que je peux décoder en:

• 0xxx.xxxx : Channel 0 : power management
• x4xx.xxxx : Immediate value (type=4)
• xxx1.xxxx : PM_REQ_ON
• xxxx.0040 : PM_SYSTEM_PWR (?...)

Ma foi, ça me semble être tout à fait la situation découlant d'un appel à systemShutdown, dernière opération de __libnds_exit() lorsque le "retour à hbmenu" a échoué :P Bref, heureusement, je m'étais donné un "faux registre" 0x04042000 pour envoyer des mots de 32 bits hors de l'émulateur ... ce qui m'amène à la conclusion que mon interception des exceptions C++ s'est fait court-circuiter par un appel "abort()" qui a ordonné la fin du programme ... grr. ... et derrière tout ça, l'oubli de --gbaslot-rom, désormais indispensable pour EFS sous desmume >_<.

7 of 9 -- personal Log

27/11 : quelque soit le code ARM7 que j'utilise (le mien modifié, celui de Tobias ou le code DefaultARm7), runme ne passe pas le cap "sync with 7" sur l'ARM9 ...
28/11 : avec le code ARM7 de Tobias et le code ARM9 de l'exemple httpget.c, je parviens à avoir une transmission WiFi fonctionnelle. C'est donc (contre toute attente) le code ARM9 qui foire.
29/11 : la présence d'IrqInit() dans le code de GuiEngine::prepare() était clairement une des causes d'erreur, mais je ne sais pas encore dire si c'était la seule. Je vais devoir continuer à importer petit à petit les fonctionnalités de runme sur cette nouvelle base pour mettre le doigt sur les éléments perturbateurs.

Seven's log, stardate 201011.27 -- I am trapped in my ARM7 cortical implants. Although I could potentially still communicate with the WiFi collective -- if any was at short range -- I have lost connection with the ARM9 behaviour controller that would allow me to communicate with the crew of the Voyager. I have analysed the defect starfleet fifosystem.c that the Doctor installed to replace my damaged borg implants that is the root cause of my malfunction. The only tool I have to operate is a standard DESMuMe tricorder from the federation filled with irrelevant features, and that reaches only 67.3% of the efficience of a corresponding Borg nanoprobe.

Seven's log, supplemental -- A double initialisation of my interrupt mask might be the cause of this FIFO dysfunction. Deeper inspection of the starfleet FIFO protocol revealed a rigid structure with 16 virtual channels and imperfect typing of messages into one-word addresses, one-word value and external larger dataquads. I will resume my investigation when my refresh cycle is complete.


PS: curieux qu'avec le couple de processeurs ARM7 et ARM9, personne (que je connaisse) n'ai fait le rapprochement entre la DS de nintendo et le borg converti "Seven of Nine" de Star Trek : Voyager, vous ne trouvez pas ?

Note: j'aimerais bien également en savoir plus sur le support des fonctions FIFO dans desmume ... je note par exemple dans la fonction _MMU_ARM9_write32

case REG_IPCFIFOSEND :

  IPC_FIFOsend(ARMCPU_ARM9, val);

  return;

Mais aussi (dans le même fichier FIFO.cpp) des fonctions GFX_FIFOsend, apparemment utilisées par l'implémentation des fonctions 3d -- et qui n'a donc probablement rien à voir dans le cas qui m'intéresse.

PS: to the devkitpro and desmume teams : no offense intended. That's Seven's "personality". Watch season 4 of Star Trek Voyager if you haven't yet: you'll know what I mean.

PPS: here's a patch against svn revision 3601 of desmume that enhance debugging of FIFO by
1) enabling per-direction logging of writes to FIFO registers through the DESMUME_FIFOLOG environment variable
2) uses location 0x04042000 as REG_DEBUG : everytime you write some 32-bit word there, it will be dumped -- together with processor no and PC value -- on STDERR.
I don't think I have "fixed" anything, so it looks like r3601 of desmume-cli already supported the full FIFO features (even though generation of interrupts are a bit obscured and could use some more documentation), but it could certainly help people understanding or validating the fifosystem.c of libnds, or other ARM7 initialisation code.