HuDK (SDK pour PCEAS/CA65 et HuC/CC65)

[MooZ]

Oyé braves gens!

La Gameboy a son GBDK. L'Oric son OSDK. La Megadrive son SGDK.
Maintenant la PC Engine a son HuDK!

Pour l'instant c'est loin d'être utilisable. Je me concentre principalement sur la partie assembleur, avec à l'esprit une compatibilité pceas et ca65 (l'assembleur de cc65). Il faut voir ce projet comme un dépoussiérage de MagicKit.

https://github.com/BlockoS/HuDK

[Warhol]

Congratulations!!

[Kaminari]

[Hero_Tonma]

Magnifique. Je vais suivre ça avec beaucoup d'intérêt.

[touko]

Bonne initiative

[MooZ]

La doc est dispo ici : http://blockos.github.io/HuDK/doc/
Pour l'instant il n'y a pas grand chose. Je fais de mon mieux pour la mettre à jour. Mais bordel ça prend un temps fou :'(

[touko]

Bah c'est propre en tout cas,et bien présenté ..

[touko]

Mooz, j'ai vu que tu sauvegardais pas l'état du registre de sélection du VDC quand tu le modifies, y'a pas un risque qu'une intérruption te pose un problème ??

[MooZ]

C'est le problême.
Mais même si il est sauvé, tu peux te retrouver dans des cas à la con comme une interruption qui pète avant que tu aies pu écrire dans $0003.

Sinon autre chose, on a rajouté 2/3 bricoles dans pceas pour le rendre un peu plus compatible avec ca65 (et bordel le code de pceas est pas joli à voir).

[touko]

C'est le problême.
Mais même si il est sauvé, tu peux te retrouver dans des cas à la con comme une interruption qui pète avant que tu aies pu écrire dans $0003.

En fait le risque est surtout avec les interruptions hsync, le reste ne pose pas trop de problème sauf si ton code déborde sur la frame suivante,et tu utilises rarement le timer pour des modifs du VDC.
Mais bon en sauvegardant tu limites aussi les risques VS du CPU en plus .

Et pour les sprites, tu vas garder le même système que Huc, à savoir une sat locale en RAM ??,ou tu vas écrire directement en VRAM ??

[MooZ]

Bonne question!
Soit je fournis juste des macros et des routines pour formater les entrées.
Soit je fais comme HuC (et au délà! Genre tenter de faire du multiplexage).

Si tu as des idées, je suis preneur.

[touko]

Soit je fais comme HuC (et au délà! Genre tenter de faire du multiplexage).

Ca je pense que ce serra pas possible(a moins de connaitre une technique pour forcer le DMA VRAM->SAT mid frame), dans la même frame bien sur, mais bon c'est justement l'utilité du multiplexage (sauf à utiliser des techniques de sioux bancales (style plusieurs frames dans une même frame),mais coton à gérer je pense ..

Si tu as des idées, je suis preneur.

Moi je le fais déjà (écrire directement en VRAM), donc tu peux utiliser/adapter mes routines si tu veux, je t'envoie les dernières versions si ça t'intéresse(avec petit exemple d'utilisation) et tu vois .

Perso, je trouve ça bcp plus rapide ,tu ne mets à jour que ce qu'il faut, ça t'évite de perdre +de 3000 cycles lors de la maj de la sat à chaque frame + 512 octets de ram(le tout x2 si tu codes pour la SGX of course),et tu n'as pas la frame de retard(facilement contournable si tu désactives le DMA auto de la SAT,et que tu le lances à la mano) .

[MooZ]

Thx. Je vais zieuter ça.

[touko]

Les fonctions sont dans include/pce/huc_gfx.asm .
Si tu as des questions n hesites pas

[MooZ]

Ca avance mais du coup je suis de nouveau tout seul sur le bousin. Je me demande si je ne vais pas repousser le support de ca65 à une prochaine release.
Pour ceux que ça intéresse, j'ai ajouté un petit programme pour faire maigrir les VGMs. Je pourrai faire mieux (comme ce qui est fait sur SMS), mais ce sera pour la suite.
Le code source en C de l'outil est dispo ici : https://github.com/BlockoS/HuDK/blob/ma ... vgmstrip.c
La routine ASM (avec des explications) là : https://github.com/BlockoS/HuDK/blob/ma ... lude/vgm.s

Voilà.