Now, that's annoying...

Bon, DarkneSs, ma DS noire, est toujours en réparation ... Je viens de recevoir de ZeBlackOS un sympathique iplayer -- le linker de bisounours qui ne lance pas les ROMs commerciales -- mais j'ai encore du mal à le faire tourner convenablement... il "boote" sur la DSi, ça c'est déjà un progrès, mais reste bloqué au niveau des logos "loading": le message "DS Video Expert" n'apparaît jamais.

Apologises to those of you who expected an activity boost after the first "owl school zone" level: you'll have to wait for me to fix some issues... I have only one working linker left until I buy some new parts or got other back from repair.

Mes derniers développements se sont donc faits essentiellement sur la DS "phat" de ma fée, avec le 'faux' R4 SDHC que j'avais obtenu pour DarkneSs... Ce n'est pas génial pour les couleurs, mais pour éditer des animations et vérifier que tout passe bien sur hardware, c'est toujours ça... enfin "c'était". Les opérations de mise à jour de l'iplayer ont eu raison du système FAT de ma carte mémoire (oui, j'ai commis l'erreur d'essayer d'utiliser la même carte mémoire sur R4 et iplayer), bousillant au passage rungama.nds et sedsgama.nds, faisant disparaître ledsgama.nds, animeds.nds, spritea.spr (la school zone) et spritey.spr (la green zone). Rien de définitivement perdu normalement tant que les disques dur de mes machines PC tiennent bon, mais c'est tout de même très dérangeant.

One left, that should be enough ? well, except it's the linker that has no built-in support for DLDI, on the DS that has poor color contrast. No art can be seriously built on that, and software upgrades will be a pain at best... Hopefully, I don't think I've lost any data although both green zone and school zone .spr files were killed by the mess that resulted from running the iPlayer firmware.

Il me reste la possibilité de me rabattre sur mon bon vieux SuperCard slot 2 et son passcard associé ... le soucis, c'est qu'il ne supporte pas le DLDI. Je devrais donc veiller à ce que tous les fichiers transmis soient bien patchés pour super-card avant de les uploader ... plutôt pénible quand on se souvient qu'au départ le support supercard était d'office dans la libfat. Et non, m'sieur devkitpro, *je ne vais pas tenter la mise à jour système du dernier linker fonctionnel qui me reste*.

So long, exec.cpp

Since August 2007 the exec.cpp file from GrizzlyAdams has been a corner stone of my activities on the Nintendo DS. It allowed me to launch NDS files from other NDS files -- a functionality that was missing of the "standard" features of libnds by then. Combined with dswifi and a small HTTP retriever, it allowed me to introduce a "self-update" feature that replaced the media card mounting/unmounting that was previously taking most of my development time. Since I mostly work on my DS project on lunch time or in the evening, it had a major impact on my ability to keep going on.
En août 2007, mes projets sur DS ont pris un grand tournant avec l'ajout d'un morceau de code de DsChannel de GrizzlyAdams, qui permettait d'enchaîner un NDS vers un autre. Combiné à un petit code HTTP, je devenais capable d'écrire des programmes se mettant à jour eux-même. Et il n'y a pas à dire, celà a nettement boosté le travail sur le Sprite Editor, le Level Editor, la lecture de modules et plus tard, le moteur de jeu à la base d'Apple Assault ...

But here we are, 3 years later, at devkitArm revision 32, with all the libraries changed. The handling of FIFO code, among other things, received a major revision, that breaks the compatibility with the custom loader. Meanwhile, too, Wintermute included a similar feature in HBMenu and made several part of the libnds dependent of its own approach. Reseting the ARM7 on request from the ARM9, for instance, is directly located in fifosystem.c, and a C++ exception will try to return to the launcher of a program. Rather than fighting against this, I decided to try and see to what extent the bare bones of "HBmenu" can be converted to support runME.

Mais voilà. Ce code utilisait le FIFO -- pratiquement inutilisé du temps du devkitArm 21 -- qui entretemps a subit une refonte importante, et Wintermute et ses accolytes ont cherché à intégrer une fonction similaire dans la libnds. L'astuce, en fait, c'est que la fonction n'est pas directement offerte aux programmes, mais intégrée dans HBmenu, qui laisse une partie de son code à un emplacement "persistant" qui (si je comprends bien) est uniquement capable de revenir au programme qui a installé ce programme persistant. Plutôt que de me battre à essayer de faire cohabiter le code de GrizzlyAdams dans le nouvel environnement, j'ai donc repris la base de HBMenu pour reconstruire runMe par-dessus. Ca marche plutôt bien, dirait-on, même si je n'ai pas encore fini le portage ... mais curieusement, ça me fait un peu chose de laisser tomber cet "exec.cpp" qui m'a soutenu tout ce temps ...

The result is encouraging, although I've got a small tear in my eye for that piece of software that I analysed and debugged to make it fully support DLDI ... Although the code from the devkitpro project shares many similarities with "my" previous approach, a larger part of the stub executes from the ARM7 (as far as I understood), meaning that it's not possible to perform debugging for it. The new code consists of

• nds_loader_arm9.c, acting as a library and directly linked to your program (runme or HBMenu), that mainly ensure software reset of the two processors and DLDI patching of the loader
• bootstub.bin, installed from the end of the ARM9 memory (the upper 48K of the 4MB area) by installBootStub() function in the "library" file
• loader.bin, copied in VRAM by runNdsFile(). It contains its own (stripped-down) FAT access, the DLDI patcher.

PS: loader.bin and bootstub.bin are thus by-products of HBMenu compilation. To get them, you need to gather the latest sources from SVN, compile them (make all is enough provided that you have devkitpro installed with the appropriate libraries), and find them in the hbmenu/data directory.

To the moon and back

My homebrew development kit has recently been upgraded to include a shiny DS lite, in order to enjoy the true colors of my pixels. That's for the neat side. I asked my brother to get me a R4 chip to fuel it, since i had quite a good experience with his (see former entries), and so he ordered me a R4-IIISDHC. Quite confusing device, i must say. On the web, everything looks like it is indeed an upgrade of the former R4, but documentation provided doesn't match the device's operation. It doesn't seem to be really using MoonShell at all (which my bross installed on the device, following former instruction), and it is said to be "a fake, scam, don't buy" on forums (as of june 2008)...

En plus de ma DS "phat" et sa Supercard, me voici équipé d'une DS Lite et sa R4-IIIsdhc, légèrement différente de la R4 "originale" de mon frère, et un rien intriguante (nombreux forums la dénonce comme "clone pirate" de la R4), mais en gros, je n'ai pas à m'en plaindre. Seul hic, ils ont fait l'impasse sur le "CD d'installation", pourtant annoncé sur le site du constructeur (www.r4iii.com, www.r4iiisdhc.com ou www.r4dsl.net selon celle que vous avez obtenue). Il faudra donc aller télécharger le "kernel" adapté et installer les fichiers à la racine de votre carte mémoire micro-SD, faute de quoi, vous aurez juste droit à un écran bigarré avec un petit logo "loading" animé en bas à droite de l'écran ...

I first thought that the authors of MoonShell didn't like that their product was embedded and defaced into a device's firmware, but i'm really starting to wonder whether that R4iii has anything to do with the earlier device :-/

Anyway, my software runs flawlessly on that beast. So far, i only regret it has no notion of directories and obviously recursively scan the media for some .nds, showing 4 of them per screen ... i feel like i'm gonna miss my supercard's menu, somehow.

At least, tweaking directories names and things alike could allow me to have files in a more "usable" order. On the other side, it made me realise that Moonshell is capable of something that i still have to implement in runme : soft reset to the firmware. And they do this quite simply via "reset.mse" (MoonShell Executable) pluging provided by the card vendor.

To quote "reset.txt" that comes along with the "R4iii upgrade" :

MoonShell execute plug-in

This plug-in is exclusive return to firmware function.

Reference URL that becomes base of reset function.
Most of reset.mse is a copy of LoveLite.

Lick + ds homebrew
http://licklick.wordpress.com/tag/lovelite/

For other homebrew developers.
'reset.mse' can be used from your self-made application.

Please make the C/D bank of VRAM accessible from ARM9.
example.
VRAM_C_CR = VRAM_ENABLE | _VRAM_CD_MAIN_BG_0x6000000;
VRAM_D_CR = VRAM_ENABLE | _VRAM_CD_MAIN_BG_0x6020000;

Please write the following values in 1024 bytes from 0x0603FC00. (16bit access is necessary.)
0x0603FC00 0x01
0x0603FC01 0x01
0x0603FC02 0x01
0x0603FC03 0x01
0x0603FC04 '?'
0x0603FC05 '?'
0x0603FC06 '?'
0x0603FC07 '?'
0x0603FC08 0x00
0x0603FC09 0x00
0x0603FC0A 0x00
0x0603FC0B 0x00
0x0603FC0C 0x00,0x00,0x00...
Please input the adaptor name (four characters) from 0x0603FC04 to 0x0603FC07.
Please fill zero from 0x0603FC0C to 0x0603FFFF.

Please start 'reset.mse'. (Please begin with usual NDS multi boot in a similar way.)

As a matter of fact, i did not even tried to implement this directly. I happen to have a slightly different memory setup in exec.cpp:LoadNDS_VRAM, which is the root of my devstation (and comes from GrizzlyAdams' work in DSChannels, remember?). All i want is a way from runme to the firmware without going through the power button. Moonshell does this ? fine. So just

if (keys & KEY_SELECT) {
  if ((keysHeld()&KEY_L)) {
printf("** trying to switch to moonshell **\n");
LoadNDS_VRAM("_DS_MSHL.NDS","/",0);
  }
  printf("checking for updates...");

does the trick ... at the expense of going through moonshell, i admit (which is a shortcut if you had just uploaded some MP3 to your system, i must add). This is somehow an ugly hack, true. I'm not proud of it in any way, but it's there and maybe at some point it will save the day. Who knows.

It could be equally sufficient if moonshell was able to run my tools, but for some reason, all i get is some "not support adapter type" error message when i try to. Only a few programs (without DLDI ?) seem to work with the version of moonshell that ended up on my system. Wait and see...

I see Debug Sessions coming, darker than night itself ...

Well, patching the ARM9 stub when executing another .nds, that works. Fine. But now, i also need to ensure that the stub patches the binary. This is supposed to take place in LoadNDSArm9(), and the DLDIEnabled flag and DLDIStub themselves are found in some "magic" addresses in VRAM that need to match those used by exec.cpp in the calling program.

As far as i can tell, everything should work fine in that regards. I tweaked the stub a bit (yeah, now i manage to compile it properly ;) to make it halt before and after patching ... it all seems right, but for some reason, the freshly downloaded "runme" do not detect the presence of DLDI, nor does it manage to access FAT (of course :P)

// Copy the DLDI patch into the application
-       memcpy (pAH, pDH, dldiFileSize);
+       memcpy (pAH, pDH, ddmemSize);
+       printf("%i bytes of driver copied\n",ddmemSize);

Hmm. Fortunately enough, i'm now fluent with diff and other revision control tools, so just checking what changed in my own copy of chishm's DLDI patcher (integrated to runme when it patches the stub) revealed a wrong memcpy that was using 0 bytes (dldiFileSize) instead of the just-computed driver size (ddmemSize). This affects v1.23 as far as i can tell, though i cannot guarantee this isn't just something odd in DSchannels' copy of the DLDI tool, as this is where my stuff comes from.

(this is usually where Beyond Infinity waved his towels in a "GG. Stay Safe.")

*fix*
*compile*
*snip -- getting the SD card out of the R4*
*copying files*
*snap -- pushing the SD card back in the R4*
*can't help to press "start" again and again while the device is booting*
*launching runme*
*updating runme*
*seems to work*
*yeah. indeed, it works ^_^*
*updating again, then launching LEDS, just for fun*

Okay, everything seems fine. So it was "just" my exec_stub.arm9 that was buggy. it's now in the CVS too ...

credits : chishm for the libfat and DLDI patchers -- EyeballKid for DSlurper/happyhttp -- sgstair for the libwifi (of course) -- whoever wrote DSChannels and did not stick his name there -- chishm again for the exec_stub i'm using (as far as i can tell) -- padrinator for non-jumpy stylus input -- wintermute, darkfader and many others working on libnds and devkitpro ;)

*ahem* test ? un deux ? un deux? *broum* Chers amis francophones, bienvenue sur le Blog de Bilou. J'ai l'insigne honneur et l'immense plaisir de vous annoncer qu'au terme d'une longue et fastidieuse semaine de débugging, runme et mes éditeurs de sprite/niveau tournent enfin au maximum de leur possibilités sur le linker R4. J'ai de bonnes raisons de croire que du coup, la compatibilité sur l'ensemble des linkers devrait être améliorée. Merci pour votre attention. A vous les studios. *wiiiit*


edit: oh well, now it seems that SEDS is touch-screen-blind and only recognize "gba" buttons (e.g. it ignores X and Y aswell) when started directly. Launching it through runme still works fine.

edit again: fixed. When you have some interrupt handler checking a "commands" buffer shared between ARM7 and ARM9, better make sure that you initialized the command buffer properly, even if you don't intend to send any commands in your program ^^"

car4mba! encore r4té

Bon, suivant les bons conseils de gbadev.org, j'ai essayé d'adapter un "exception handler" pour l'ARM7, histoire de savoir si oui ou non il y a un plantage sur ce processeur. J'en ai aussi profité pour remettre une ou deux choses en place et voilà que je me retrouve avec un ARM7 qui fonctionne sur R4 sans tout planter. Son, wifi, tout y est.

Bref. J'espère juste être mieux armé pour le prochain plantage (je n'aime pas laisser un bug derrière moi comme ça). En attendant, la guerilla avec le R4DS est encore loin d'être finie : j'en prends à témoin un message du genre "DLDI driver available ; using built-in driver for R4TF; operating without DLDI" ... mes routines de détections sont dans les choux, quoi.

Résultat, si je lance SEDS depuis Runme, par exemple, SEDS n'aura plus accès à la carte mémoire (et donc sera incapable de se remettre à jour) ... hum, hum ...

r4volu7ion

Bon. Si je veux convaincre mes potes de tester mes p'tits Bilous sur leur DS, il serait temps que je m'assure de la compatibilité avec les linkers autres que mon "supercard". Mon frère est sur le point de se marier, donc il n'a pas vraiment besoin de sa DS pour les semaines qui viennent. Je la lui chipe donc, histoire de voir ce qui coince...

• 26 juin : selon Smealum, ma p'tite démo ne passe pas sur le R4
• 29 juin : premier test sur la R4 de mon frère, visiblement c'est l'initialisation ARM7/ARM9 qui coince
• 30 juin: ouf. la R4 est quand-même capable de charger un .nds avec du code 'custom' sur le processeur ARM7. C'est donc juste que mon code est foireux.
• 13:37 petit debugging à coup de "changement de couleur de fond". l'ARM7 compilé sans NTXM entre bien dans la routine "setupWifi()", mais reste bloqué en attente d'un fifo_temp==IPC_WIFI_INIT. Normal : j'ai retiré toute référence au wifi du côté ARM9 :P ... A noter malgré tout que celà n'empêche plus le traitement des autres évènements ...
• 17:00 "si tu veux, je teste ça ce soir sur mon M3" dixit Oli ... wait'n'see
• 20:00 je re-teste entre deux copies ... apparemment, c'est l'activation de la bibliothèque NTXM qui pose des problèmes ... je reprends mes habitudes de développeur de bootsector: on change la couleur de l'écran en fonction des étapes franchies dans le code, avec une légère variation pour prouver que le CPU est toujours bien actif ;)
• 22:30 ok. c'est l'interruption timer qui douille. je la désactive, ça me fait toujours un runme fonctionnel sur R4 (auto-update et téléchargement compris. fini le card-swapping) mais pas de son :'(
• 22:55 YES! on rajoute Song=0 dans le constructeur de Player et hop! ça marche "revolution ... r4volu7ion ... mem0ry ... m0re mem0ry" comme disais JMJ ;)

I'm doing tests with my brother's R4 this week and trying to find out what's going wrong with that latest demo. After a couple of hacks, it turned out that the ARM7 is apparently halting at some point when the NTXM player is enabled ... weirdo.

I already found a couple of uninitialized pointers, but unfortunately, the problem can only be reproduced when launching the software from R4 menu (launching from runme works like a charm, but then you need a no-sound version of runme to get bootstrapped :P) I've been somehow cheated in my attempts, though, by the fact that i kept the SuperCard in slot 2 while doing tests from the R4 on slot 1 ... Somehow, the FAT library "prefers" the supercard and i ended up running program out of the R4 that was doing I/O (and WiFi upgrades) through the SCSD :P 

(PS: je ferai une nouvelle release demain, après m'être assuré que j'ai bien un binaire qui marche, l'EFS lib et le DLDI fonctionnel, etc)

edit: éviter le mélange SCSD dans le slot 2 et R4DS dans le slot 1 pour le dev. on est jamais trop sûr duquel est utilisé par la libfat :P du coup, je m'interroge ... est-ce que j'ai vraiment réussi à avoir le son et le wifi sur la R4 ?

Une nouvelle démo

Bon, une petite anim' enregistrée et un nouveau petit .nds autonome pour que vous puissiez tester les amélioration de mon moteur de jeu sur votre DS à vous. Au programme, le nouveau scrolling , la gestion des collisions , les test-points conditionnels (avec moins de bugs dans la gestion des déplacements de Bilou).

Bref, faites-vous plaisir: téléchargez la "ROM" ;)
le programme va démarrer et afficher "Ready." sur la console, sur l'écran du haut. A ce moment, appuyez plusieurs fois sur Y pour exécuter le niveau pas à pas jusqu'à ce que Bilou tombe. Vous pouvez alors le diriger avec le pad. Vous pouvez aussi changer de méthode de scrolling en appuyant sur START.

Here comes a new demonstrator of my game engine, so that you can test the latest improvements on *your* DS : collision management, conditional test-points, new scrolling ... So stop hesitating and start downloading. Once launched, the program will display "ready" and then wait for you to press 'Y' button half a dozen of times to perform step-by-step initialization of the level. As soon as Bilou starts falling, you can control him with the D-pad. You can also toggle the scrolling algorithm by pressing "START".
Les bugs connus:

• lorsqu'il retombe sur le sol, il arrive que Bilou se mette à glisser sans s'arrêter
• si Bilou heurte un mur en saut, il y reste "scotché" tant que vous gardez le bouton "gauche" ou "droite" enfoncé
• quand Bilou n'est qu'à moitié sur une plate-forme, il "tremble" et l'écran du haut défile à toute vitesse. (ce n'est pas vraiment un bug: je n'ai pas encore d'animation pour le montrer en déséquilibre)

PS: il va falloir que je chipe le R4 de mon frère par contre. J'ai régulièrement des testeurs sur dev-fr qui m'indiquent que mes roms ne marchent pas chez eux, et là, en principe, c'est tellement simple que je ne vois pas ce qui peut ne pas marcher. Le DLDI, peut-être ?

edit: j'ai retiré le lien vers la version "efs2.0", qui ne résout apparemment rien pour les utilisateurs de R4. J'ai visiblement un problème avec le code ARM7 qui ne fonctionne pas comme prévu. Investigation en cours ...

dslinker [t.a.g.]

Running homebrew software on a Nintendo DS needs a little help ... a device called "a linker" that typically looks like a DS/GBA game, but that include a (micro)SD card reader. Finding, maintaining and using those device is sometimes a story of its own, as Captain N typically hunt corporates that manufacture them and puts pressure on governments to make those things illegal and pretend that people who sell them are evil criminals.