En effet, j'ai reçu la NGCD de Kuk il y a quelques jours et j'ai pu constater la même chose (j'aurais pu déjà le voir sur la photo de la CM sur son site, mais y'avait pas l'autre face).
Le LC89515 passe par NEO-MGA pour mettre les données en RAM avant de les distribuer en DRAM. Il n'a rien à voir avec la lecture audio, j'ai dit des conneries.
Il me semble aussi que c'est par NEO-MGA que toute la console passe ses commandes pour récupérer tel ou tel truc sur le CD, vu où vont les pistes de CN4. Je ne sais pas trop de quel type est ce composant, je me suis toujours demandé si "GA" ça voulait pas dire simplement "Gate Array".
Avant d'inventer trop de bêtises, j'ai commencé à fouiller dans la source de NeoCD, qui donne tout ce dont on a besoin: l'espèce de "hack" de Fabrice Martinez est bien pensé je trouve.
Dans l'émulateur, il patche le BIOS (neocd.bin) pour que les appels vers les fonctions de lecture du CD pointent sur des instructions 68K illégales. Il a ensuite rajouté ces fausses instructions dans l'émulateur 68K et remplace le tout par des fonctions en C, qui imitent ce que ferait le BIOS sans avoir à émuler complètement le lecteur CD. Je ferais une page là dessus, si j'ai son accord.
Progfr, t'avais donné la source des macros PlayAudio et StopAudio, qui montrait qu'elles ne faisaient que mettre un argument dans D0 et appelaient 0xC0056A. C'est justement une adresse que patche NeoCD:
*((short*)(neogeo_rom_memory+0x56A)) = 0xFAC3;
Il remplace donc le JMP #$C0B6DE qu'on trouve à $00056A dans le BIOS, par l'opcode $FAC3, qui n'est pas valide.
Dans la source de l'ému 68K, on a le "trap" justement sur cet opcode, qui nous mène vers la fonction intéressante:
OP_fac3:
call neogeo_cdda_control
La fonction neogeo_cdda_control (dans neocd.cp) récupère le contenu du registre D0 et sépare ses deux octets bas en commande et argument, pour les passer à neogeo_do_cdda. C'est cette fonction qui imite le comportement du BIOS, pour faire croire au jeu que c'est un lecteur CD tout à fait normal qui fait le travail.
Si on compare ce que fait cette fonction avec la même dans le BIOS, désassemblée depuis $C0B6DE (qui correspond à l'appel vers $C0056A comme je l'ai écrit ci-dessus), on s'aperçoit qu'elles font à peu près la même chose. Je vous épargne la comparaison asm/C, sauf si ça intéresse quelqu'un. La seule différence c'est que le BIOS va parler à NEO-MGA par le biais de $FF0127 (numéro de la piste), $FF0105 (toujours #4) et $FF0147 (numéro de la piste également), alors que l'ému s'en occupe même pas et va juste lire le fichier wav correspondant. Par contre il y a des mises à 0 dans la mémoire du Z80 si je comprend bien (à partir de $E00000), mais j'en vois pas (encore) l'utilité.
Exemple avec Viewpoint (j'adore la musique, j'arrive pas à me lasser de la piste 12):
Arrêt de la lecture CDDA avec la commande 06, piste 00:
move.l #$00000600,d0
jsr #$C0056A
Lecture CDDA avec une table, le numéro de l'entrée est dans D0:
andi.l #$000000FF,d0
movea.l #$00012A60,a2
add d0,d0
move 0(a2,d0),d0
jsr #$C0056A
Avec à $012A60, des données du genre "dc.w #$0402", ce qui enverrait la commande 04, piste 02. Je ne sais pas pourquoi VP utilise une table avec des paires commande/piste au lieu de les passer directement dans D0.
Pour résumer, c'est bien $C0056A qu'il faut appeler pour lire une piste, avec dans D0, la commande et la piste. Les commandes 2 et 6 arrêtent la lecture, et les 0,1,3,4,5,7 démarrent la lecture. Toutes les autres sont ignorées. Les macros de Neodev mettent le bit 7 de $10FD80 à 1 avant de balancer la commande, mais je ne sais pas à quoi ça sert.
J'ai à peine commencé à écrire un petit programme de bricolage à graver, avec possibilité de faire des peek/poke dans la mémoire et de (si j'y arrive), uploader des programmes depuis le port joystick. Sans débugger sur les émus et avec un nombre limité de CD-R, ça va être un peu chaud ;p
Je fais des trucs. Des fois ça marche, des fois ça marche pas.
. Mais pour le hard cela reste presque la meme chose
mais pour les SFX ..??) pas possible que cela soit une pliste audio a chaque fois
