Squalyl: c'set une 6502, et LLVM n'est pas prevu pour ce type de CPU, un backend CPU 8 ou 16bit reviendrais a reecrire pas mal de choses..

Sinon ce qu'il faut faire c'est de changer le "pointeur" de abc_score_ptrX* des que Y arrive a 255 sur le buffer suivant de 256 caracteres

X = 0 a 3

Si je ne me trompe pas les valeurs sont lu par cette boucle:


abc_read_char:: txa ina dea bne .abc_read_char1 lda (abc_score_ptr0),y bra .abc_read_char4 .abc_read_char1 dea bne .abc_read_char2 lda (abc_score_ptr1),y bra .abc_read_char4 .abc_read_char2 dea bne .abc_read_char3 lda (abc_score_ptr2),y bra .abc_read_char4 .abc_read_char3 lda (abc_score_ptr3),y .abc_read_char4 beq .abc_read_char5 iny .abc_read_char5 rts
au travers des lda (abc_score_ptrX),y
Sachant que on est sensé trouver 16bit de data pour le pointeur, quand Y arrive a 255, un simple

INC abc_score_ptrX+1

permet a ce pointeur de pointer sur le buffer suivant de 256 octets.

Il faut pour ca bien sur que les buffers soient consecutifs

Il faudrait, je pense faire un truc du genre:

abc_read_char:: txa ina dea bne .abc_read_char1 lda (abc_score_ptr0),y bra .abc_read_char4 .abc_read_char1 dea bne .abc_read_char2 lda (abc_score_ptr1),y bra .abc_read_char4 .abc_read_char2 dea bne .abc_read_char3 lda (abc_score_ptr2),y bra .abc_read_char4 .abc_read_char3 lda (abc_score_ptr3),y .abc_read_char4 beq .abc_read_char5 iny bne .abc_read_char5 inc abc_score_ptr0+1 inc abc_score_ptr1+1 inc abc_score_ptr2+1 inc abc_score_ptr3+1 ; a ajouter un moyen de compter ou on est, si si on est a la fin des buffers, on reset les 4 pointeur sur les valeurs d'origines .abc_read_char5 rts
Pour que ce code marche il faut ABSOLUMENT que les X octets de abc_score_ptrX soient consecutifs sinon ca ne marchera pas

Ce qui peux aussi etre fait, c'est de simplement signaler a la boucle principale qu'on est en fin de buffer:


bsszp abc_score_ptr0 ds 2 abc_score_ptr1 ds 2 abc_score_ptr2 ds 2 abc_score_ptr3 ds 2 end_of_buffer ds 1 text [...] _abcmusic:: lda #$0 sta end_of_buffer [...] abc_read_char:: txa ina dea bne .abc_read_char1 lda (abc_score_ptr0),y bra .abc_read_char4 .abc_read_char1 dea bne .abc_read_char2 lda (abc_score_ptr1),y bra .abc_read_char4 .abc_read_char2 dea bne .abc_read_char3 lda (abc_score_ptr2),y bra .abc_read_char4 .abc_read_char3 lda (abc_score_ptr3),y .abc_read_char4 beq .abc_read_char5 iny bne .abc_read_char5 inc end_of_buffer ; a ajouter un moyen de compter ou on est, si si on est a la fin des buffers, on reset les 4 pointeur sur les valeurs d'origines .abc_read_char5 rtsEt dans la boucle du jeu, a chaque debut lire l'etat de "end_of_buffer" et si il n'est pas 0, c'est qu'il faut mettre a jour abc_score_ptrX avec la valeur qu'on veux.
Cette version permet en theorie de changer les buffers a la vollée.


le code dans ce post est tapé de tete et n'a pas été testé il peux peut etre transformer votre Lynx en Four a Microonde ou en rasoir electrique, donc a utiliser avec prudence!

Edit:

on pourrait donc avec 65535 octets de zic ce qui serait effectivement plus sympa.

Hint: le 6502 ne permet d'addresser QUE 65535 octets de memoire, CODE compris, donc il ne faut pas rever, tu n'aura jamais 65535 octets de musique, et encore moins pour chaque canaux.