Logicielsmoto.com http://www.logicielsmoto.com/phpBB/ |
|
Outillage pour développement de jeux sur TO8 http://www.logicielsmoto.com/phpBB/viewtopic.php?f=3&t=620 |
Page 20 sur 40 |
Auteur: | Fool-DupleX [ 01 Nov 2021, 11:50 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Citation: C'est le passage du spot lumineux de l'écran dans la photo-diode qui déclenche le FIRQ Oui, tu as raison, j'ai dit une bêtise. Je ne sais pas pourquoi j'ai dis ça, vu que j'ai entièrement reversé le mécanisme à l'époque pour refaire le gate-array du MO5. Ma mémoire flanche. L'inhibition du signal dépend des machines, je crois. Il faudrait étudier chaque schéma pour s'en assurer. Je vais faire une repro à l'identique, c'est une question de principe. Quelqu'un qui aurait la vraie interface MIDI aimerait ne pas avoir à la modifier. Mais je peux produire des variantes avec un jumper pour selectionner la ligne d'interruption rien que pour vous, si vous voulez. Excellent point, la FIRQ pour jouer des samples sur le DAC. Le code source commenté sur dcmoto, c'est le mien, original de chez Thomson avec les vrais commentaires des vrais développeurs (certains sont rigolos). Seul exemplaire que je connaisse, il fait dans les 1000 pages, il y a le t9000, to7, to7-70 et mo5, avec les variantes internationales. J'ai fait le boulot de scan pour le MO5, parce que c'est la machine qui m'intéresse tout particulièrement, mais je n'ai jamais eu le courage de scanner le reste. Daniel a OCRisé la chose et produit les listings correspondants. Ces listings s'assemblent et produisent la ROM à l'identique, car Daniel a fait l'effort de corriger les erreurs d'OCR sur le code. Par contre, il ne l'a pas fait pour les commentaires et il y a parfois des coquilles, mais ce n'est pas grave. la ROM TO8 est radicalement différente. A cause du gate-array, du bank switching, du déplacement des routines utiles du BASIC dans l'extra-moniteur, du DOS iconique ... et Thomson n'a plus rendu public le code source après le TO7-70. |
Auteur: | Daniel Coulom [ 01 Nov 2021, 14:58 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Quand je vois des erreurs d'OCR dans les commentaires je les corrige au fur et à mesure, mais évidemment il en reste beaucoup. Si vous en trouvez n'hésitez pas à les signaler. Pour le code je suis sûr à 100% que tout est bon, car après assemblage il y a identité parfaite avec le contenu de la ROM. |
Auteur: | Fool-DupleX [ 01 Nov 2021, 15:26 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Puisque tu es là Daniel, j'en profite pour saluer encore une fois ton travail sur ce projet. Scanner le code MO5 a été pénible, mais il fallait du courage et de la motivation pour corriger les erreurs dans le listing après OCR ! Et l'OCR est rudement bienvenu. Je compte bien un jour scanner les autres listings, mais vous savez comment ça se passe, on repousse, on repousse ... car le bouquin fait tout de même 8 cm d'épaisseur et plus de 5 kg. |
Auteur: | Bentoc [ 09 Déc 2021, 15:36 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Bon, voila le code qui utilise IRQ et FIRQ pour le lecteur midi. L'outil java qui encode les données midi découpe les informations en "frames", on a donc des lots de 62 octets max par frame (débit maximum du midi) MusicFrame est la routine exécutée avec l'IRQ 50Hz, elle valorise un buffer circulaire de 256 octets avec les 0 à 62 octets midi de la frame. Les données lues viennent de différentes pages de RAM (si le morceau est gros) et le buffer lui est en zone RAM permanente ($6100-$9FFF) Une fois les données chargées dans le buffer, l'interruption du EF6850 est est activée sur le registre d'envoi. L'interface midi déclenche la FIRQ et la petite routine (40 cycles) va lire l'octet suivant dans le buffer. Quand le buffer est vide la FIRQ est désactivée. Je ne sais pas si on peut encore gagner des cycles dans la routine FIRQ ... j'ai fait mon max. Dans le cas ou on aurait un flux continu de données midi (peu probable en réalité à moins de jouer des sysex en permanence), la conso max des FIRQ sur un frame serait de : 40*62 = 2480 cycles, soit environ 12,5% de CPU Auquel il faut ajouter le cout d'exécution de la routine IRQ que j'évalue au pifomètre à 1300 cycles maximum (62 octets par frames) Donc un total de 18,9% de CPU dans le pire des cas si on envoie du sysex en cours de jeu. Sur des phases de musique ce sera bien moins que ça, sur mon morceau de test actuel on traite environ 3 octets toutes les 2 frames Donc on devrait avoir seulement 2% de CPU occupé par la lecture midi en phase normale de jeu (un peu plus si le morceau est rapide) On verra donc au moment des tests ce que ça donne ! mais j'ai confiance ;-) Code: * ---------------------------------------------------------------------------
* SMIDI 6809 - Small Midi playback system for 6809 and EF5860 * --------------------------------------------------------------------------- * by Bentoc October 2021 * with inputs from Fool-DupleX * --------------------------------------------------------------------------- opt c,ct MIDI.CTRL equ $E7F2 MIDI.STAT equ MIDI.CTRL MIDI.RX equ $E7F3a MIDI.TX equ MIDI.RX MIDI.RXFULL equ %00000001 MIDI.TXEMPTY equ %00000010 MIDI.RXIRQ equ %10000000 MIDI.TXIRQ equ %00100000 FIRQ.ROUTINE equ $6023 MusicLoop fcb 0 ; 0 : do not loop music MusicIndex fdb 0 ; first index of all data chuncks (page, address) MusicIndexPos fdb 0 ; position in index MusicPage fcb 0 ; current memory page of music data MusicDataPos fdb 0 ; current playing position in Music Data MusicStatus fcb 0 ; 0 : stop playing, 1-255 : play music WaitFrame fcb 0 ; number of frames to wait before next play ****************************************************************************** * ResetMidi - Reset Midi Controller * ****************************************************************************** ResetMidi pshs a lda #$03 sta MIDI.CTRL ; reset midi controller lda #$15 sta MIDI.CTRL ; no r/w interrupt puls a,pc ****************************************************************************** * PlayMusic - Load a new music and init midi interface * * receives in X the address of the song * destroys X ****************************************************************************** PlayMusicLoop pshs d lda #$ff sta MusicLoop ; set the loop flag on bra @a PlayMusic pshs d @a stx MusicIndex ; store index for loop restart stx MusicIndexPos ; init data chunck index position lda sound_page,x ; get memory page that contains track data sta MusicPage sta MusicStatus ; no data on page 0, page is used to init status to a non zero value ldd #1 stb WaitFrame ; wait frame is only zero where reading commands, should be init to 1 ldx sound_start_addr,x ; get ptr to track data stx MusicDataPos ; init data location sta CircularBufferEnd+1 ; init buffer index to 0 sta CircularBufferPos+2 ; init buffer index to 0 ldd #SampleFIRQ ; set the FIRQ routine that will be called when the EF5860 tx buffer is empty std FIRQ.ROUTINE puls d,pc ****************************************************************************** * MusicFrame - processes a music frame (IRQ - DP $E7) * * format: * ------- * xnn * |____ x00 : (1 byte) next page/adr or end of data * |____ x01-x7f : (1 byte) wait xnn frames * |____ x80-xff xnn (xnn) : (2 or 3 bytes) command, data1, (data2) * |____ xf0 xnn ... xf7 : (x bytes) SysEx * * destroys A,B,X,Y ****************************************************************************** _enableFIRQ MACRO lda MIDI.CTRL anda #^MIDI.TXIRQ sta MIDI.CTRL ENDM _writeBuffer MACRO sta b,y ; send byte to the midi interface incb stb CircularBufferEnd+1 lda ,x+ ENDM MusicFrame lda MusicStatus ; check if a music track is to play bne @a rts @a dec WaitFrame beq ReadCommand ; no more frame to wait, play the next commands rts IsMusicLoop lda MusicLoop beq StopMusic ldx MusicIndex lda ,x bra LoopRestart StopMusic sta MusicStatus sta MusicLoop rts BankSwitch ldx MusicIndexPos ; read byte was $00, this is end of data chunk or music track leax sound_meta_size,x ; move to next index lda sound_page,x ; get memory page that contains track data beq IsMusicLoop ; this is an end of track LoopRestart sta MusicPage ; store the new page stx MusicIndexPos ; this is an end of data chunck, save new index ldx sound_start_addr,x ; get ptr to track data bra @a ; ReadCommand ldb CircularBufferEnd+1 ; load next free position in circular buffer ldy #CircularBuffer ldx MusicDataPos ; load current position in music track lda MusicPage @a _SetCartPageA lda ,x+ ; read data byte in new page CommandLoop bmi DoCommand beq BankSwitch DoWait sta WaitFrame stx MusicDataPos _enableFIRQ rts DoCommand cmpa #$C0 blo TXRdy3b ; branch (command 8n to Bn, 2 data bytes) cmpa #$E0 blo TXRdy2b ; branch (command Cn and Dn, 1 data byte) cmpa #$f0 beq DoSysEx ; branch (sysex) ; default (command En, 2 data byte) TXRdy3b _writeBuffer TXRdy2b _writeBuffer _writeBuffer bra CommandLoop DoSysEx _writeBuffer cmpa #$f7 bne DoSysEx _writeBuffer bra CommandLoop ****************************************************************************** * SampleFIRQ - send a sample to the midi interface (FIRQ) * ****************************************************************************** SampleFIRQ sta @a+1 ; backup register A lda CircularBufferPos+2 ; read current offset in buffer CircularBufferEnd cmpa #0 ; (dynamic) end offset in buffer (set by IRQ routine when buffer is written) beq DisableFIRQ ; branch if no more data to read (todo shutdown midi interface interupt until next buffer write ?) inc CircularBufferPos+2 ; increment the offset in buffer CircularBufferPos lda CircularBuffer ; (dynamic) read the buffer at the current index sta MIDI.TX ; send byte to the midi interface @a lda #0 ; (dynamic) restore register A rti DisableFIRQ lda MIDI.CTRL anda #^MIDI.TXIRQ sta MIDI.CTRL rti align 256 CircularBuffer fill 0,256 |
Auteur: | Samuel Devulder [ 09 Déc 2021, 16:08 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Bon la j’ai pas de quoi vérifier, mais il faudrait voir si le firq n’irait pas un chouia plus vite avec le mod 256 en utilisant l’indexage ”b,u” avec u qui pointe sur le buffer+128. Il y aurait plusieurs avantages : b,u et fait du mod 256 auto; incb est plus rapide que l’accès étendu; il n’y a plus de contraintes d’alignement sur le buffer circulaire; et enfin avec un peu de chance on peut organiser les données pour utiliser l’aspect ’pile’ de u pour charger ou sauver pleins de registres en une fois (pas forcément utile ici car seul le registre ”a” est utilisé). Probablement que x peut remplacer u ici. Mais bon comme il faudra alors sauvegarder et récupérer le registre d’index il faut comparer précisément les cycles. |
Auteur: | Samuel Devulder [ 09 Déc 2021, 16:12 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Ah aussi il y a un bug dans DisableFirq: la valeur initiale de ’a’ n’est pas restaurée. Il faudrait faire un ”bra @a” au lieu du rti seul. |
Auteur: | Bentoc [ 09 Déc 2021, 17:14 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Oui exact il faut voir le cout de sauvegarde et rechargement de u. C’est pour ça que le code utilise un seul registre pout le moment. Je vais regarder ta proposition car je n’avais pas pensé a cette astuce !! Bien vu ! Merci aussi pour le bug |
Auteur: | Bentoc [ 16 Déc 2021, 10:01 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
ça fait un moment que je cherche une solution pour réduire l'espace mémoire occupé par les sprites compilés, sans pour autant sacrifier la vitesse de rendu. On peut très bien décomposer un sprite en plusieurs autres sprites, mais cela veut dire que la structure de données est dupliquée et que le moteur de gestion des priorités d'affichage doit gérer ces sprites en plus. L'autre solution est de conserver la notion d'un seul sprite mais d'associer plusieurs routines d'effacement/affichage qui vont venir s'exécuter à la suite les unes des autres pour dessiner le sprite en entier. Chaque partie de sprite dessinnée pouvant être réuitilisée pour ce sprite ou pour d'autres. J'ai écrit une routine qui décompose des sprites en parties communes et me donne en sortie la décomposition en sous-sprites, ainsi que l'offset du sous-sprite. On fait le test de tous les alignements d'images 2 à 2 pour trouver la meilleur superposition avec un maximum de pixels en commun pour l'ensemble des combinaisons. Pour cet ensemble de pixel en commun, on rebalaye toutes les images pour trouver celles qui ont ce motif, on soustrait ce motif aux images et on sauvegarde ce motif comme nouvelle image. On reprend toutes les images et on recommence jusqu'a atteindre les limites entrées en paramètre. En paramètre on a un minimum de pixel pour un motif (ici : 64px) Voici un exemple avec l'intro de sonic : Fichier(s) joint(s): sonic.png [ 40.64 Kio | Vu 4795 fois ] Parlons tout de suite du taux de compression (ici je compte le nb de pixels non transparents), dans ce cas on est à 0,40 ce qui est plutôt pas mal ! Bon on avait deux images quasi identiques ce qui aide ici. On remarque dans la première image qu'on a des motifs communs qui sont en plus répétés dans la même image, avec des offsets différents. On peut réduire le nombre d'images communes en jouant sur le paramètre "nb minimum de pixels des sous images". Pour l'instant je n'ai fait que le générateur, il faut intégrer ça au builder et aux routines ASM ... ce sera en début d'année prochaine certainement. On aura alors une indication plus précise sur le gain en octets et la dégradation de perf. Note : je n'ai pas indiqué la cardinalité pour les liens en vert, elle est différente entre la première et les deux dernières images. |
Auteur: | Bentoc [ 16 Déc 2021, 10:49 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Voici avec le paramètre "nb de pixel minimum pour les sous images" à 256px (taux de compression 0,51) : Fichier(s) joint(s): sonic2.png [ 26 Kio | Vu 4795 fois ] |
Auteur: | Samuel Devulder [ 16 Déc 2021, 12:09 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Ca fait penser au codage différentiel: on ne stock que la différence (XOR) entre 2 images, non ? Fun fact: avec cet encodage il est facile d'aller aussi bien en avant ou en arrière (e.g. remonter le temps) dans une animation. |
Auteur: | Bentoc [ 16 Déc 2021, 12:46 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Le codage différentiel c’est plus proche de ce que j’ai mis en place pour les animations de decors (comme la piste du special stage de sonic) peut etre ? Ici c’est différent je pense car on ne dépend pas des images avant après. On a un sous ensemble de graphismes communs avec un alignement de ces graphismes propre a chaque image finale. On peut tout à fait utiliser des images qui ne sont pas dans une même animation (il faut quand même qu’il y ait des points communs) Avec un chip graphique cet aspect de graphismes communs est géré au travers de blocs de 8x8 ou 16x16 qu’on réutilise entre les sprites, c’est un peu la même chose ici mais avec une forme libre et un placement au pixel près. |
Auteur: | Samuel Devulder [ 16 Déc 2021, 22:49 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Humm je ne sais pas trop où poster ca, mais le challenge concernant Sonic se fait du coté C64 |
Auteur: | Bentoc [ 16 Déc 2021, 23:25 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Oui j'ai vu ça, c'est une très belle réalisation. Le C64 a une puce graphique pour faire du scroll et gérer des sprites en hardware, on voit de suite la différence ;-) |
Auteur: | adnz [ 16 Déc 2021, 23:44 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
ouaa super sonic sur c64.... il vient de poster une nouvelle vidéo même https://www.youtube.com/watch?v=tDnLJJ7B4Pw |
Auteur: | Samuel Devulder [ 17 Déc 2021, 00:05 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Et hop je rediffuse en sens inverse |
Page 20 sur 40 | Heures au format UTC + 1 heure |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |