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 18 sur 40 |
Auteur: | Bentoc [ 13 Oct 2021, 13:49 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
J'avais pas vu la date ... les photos sont de Aout 2001 effectivement ! Oui c'est ici : http://www.logicielsmoto.com/viewdocument.php?docid=58 Moi je t'en prend une carte midi c'est sur et certain, je pense que ça va intéresser adnz également mais je le laisse confirmer. Tu penses les proposer en kit ou assemblées ? (pour moi c'est égal) Je pourrai piloter mon Kurzweil K1000 (Motorola 68000) avec mon TO8 ! la classe En ce qui concerne les cartes de Dino elle sont opérationnelles, c'est juste qu'avec des composants un peu plus modernes on pourrait : - réduire le nombre de CI de logique (et par conséquent le nb de composants (ci, condensateurs) et le prix) ? - arriver à tout caser sur une seule carte (on peut tout passer en smd a part les chips) ? - améliorer la partie préamp du YM2413 (un TL072 alimenté en +5v c'est pas optimum) - faire des mesures pour "calibrer" les niveaux de sortie audio entre les cartes et le DAC et vérifier que les signaux sont mixés correctement => c'est peut être la dessus qu'il faudrait aider Dino (j'ai cru comprendre au travers de nos mp qu'il se sentait un peu seul sur le sujet, d'un autre coté il n'a pas demandé d'aide de manière directe ...) Le fait d'avoir deux cartes c'est un peu une double peine, car du coup il faut se fabriquer le minibus de Daniel en version 3 ports si on veut utiliser le sddrive (a moins d'avoir l'ancienne version + le minibus). On se retrouve donc à acheter et peupler 3 pcb, pas top. Si on n'avait qu'une seule carte, on pourrait utiliser le sddrive et le minibus de daniel, ce qui j'imagine sera la majorité des cas. |
Auteur: | Bentoc [ 13 Oct 2021, 14:01 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
A propos du moteur de jeu, je viens d'intégrer un nouveau driver pour les cartes son qui fonctionne un peu comme le vgm. J'utilise le format suivant pour les données : Code: * format: * ------- * x00-x38 xnn : (2 bytes) YM2413 * x40-xff : (1 byte) SN76489 * x39 xnn : (2 bytes) command code xnn (x00-xff) * |____ x00 : (2 bytes) stop track * |____ xnn : (2 bytes) wait xnn frames (x01-x7f) * |____ x80 xnnnn : (4 bytes) jump to xnnnn * |____ x81 xnnnn xnn : (5 bytes) replay at xnnnn (signed offset) xnn bytes and return J'ai une tool chain qui permet d'utiliser DefleMask en mode Genesis Standard: - exporter un VGM (YM2612, SN76489) - vgm-conv (YM2612=>YM2413, SN76489) - convertisseur java maison (samples => drumkit, conversion du format VGM dans le format custom ci dessus) - Driver TO8 "svgm" du moteur de jeu pour la lecture Pour l'instant je n'ai pas implémenté la loop et la compression, mais sinon ça marche bien. Les données prennent plus de place, mais on a un gros gain de perf par rapport au smps Ce qui est cool c'est que les commandes des deux chips ne se recouvrent pas (du moins sur le premier octet), du coup on peut "mélanger" les données et retrouver nos petits. Il a juste fallu passer un bit inutilisé à 1 sur une des commandes du SN76489, chose qui est faite dans le convertisseur java. |
Auteur: | adnz [ 13 Oct 2021, 19:06 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
ah oui une prise MIDI sur Thomson ! je suis ouf moi j'avais même pas pensé que ça pouvais exister ... moi aussi moi aussi Je t'en prend une aussi si possible une prise MIDI TO8 |
Auteur: | Fool-DupleX [ 13 Oct 2021, 22:23 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Depuis novembre 1985, sur TO7, TO7/70 et MO5 : http://dcmoto.free.fr/documentation/theophile13/index.html - page 6. Bon, ok, je démarre sur ce premier projet. Le reverse et la refabrication à l'identique, ça me connait. Par contre, j'ai pas les boitiers plastique. Ca fait partie des trucs que j'aimerais refaire, mais pour le moment, je n'ai fait que le boitier MEMO7 et la moitié du boitier MEMO5. |
Auteur: | adnz [ 13 Oct 2021, 22:37 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Pour les boitiers je me les modélise moi même pour moi, donc je pourrais éventuellement le mettre à dispo si besoin sans soucis ... Je dois me faire le boitier un pour la carte son aussi ! (boitier pour minibus 3 ports+les 2 cartes de Dino) ! faut juste que je trouve un moment pour le faire |
Auteur: | Yoann Riou [ 14 Oct 2021, 08:31 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Fool-DupleX a écrit: Depuis novembre 1985, sur TO7, TO7/70 et MO5 : http://dcmoto.free.fr/documentation/theophile13/index.html - page 6. Bon, ok, je démarre sur ce premier projet. Le reverse et la refabrication à l'identique, ça me connait. Par contre, j'ai pas les boitiers plastique. Ca fait partie des trucs que j'aimerais refaire, mais pour le moment, je n'ai fait que le boitier MEMO7 et la moitié du boitier MEMO5. Va te falloir une imprimante 3D pour creer des boitiers |
Auteur: | Fool-DupleX [ 14 Oct 2021, 09:46 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
J'en ai une. Mais pour la T.2, je les fais faire en Chine, histoire d'atteindre une qualité similaire aux boitiers d'époque. Le problème c'est le modèle 3D, il est beaucoup plus complexe qu'il n'y parait et je refuse de faire dans l'approximatif façon scan 3D. Je souhaite qu'il soit aussi proche que possible des originaux, idéalement identique. Naturellement, dans l'intervalle, on peut se contenter d'un parallélépipède rectangle. |
Auteur: | Fool-DupleX [ 19 Oct 2021, 14:21 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
J'ai ouvert un nouveau fil de discussion pour l'interface MIDI ici. |
Auteur: | Bentoc [ 21 Oct 2021, 06:47 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Dans la dernière démo, une petite optim sympa a été mise en place ... je vous explique ... Vous vous souvenez de la méthode pour afficher une séquence d'images qui utilise uniquement les pixels en différence, c'est ce qui est utilisé dans la démo Sonic pour la piste du special stage. Une option a été mise en place dans l'outil de préparation des images pour pouvoir utiliser la possibilité de réindexer certaines couleurs de la palette. Ainsi quand on est dans ce cas de figure : Fichier(s) joint(s): Tri.png [ 4.54 Kio | Vu 5487 fois ] on ne redessinera pas le centre du triangle, on fera une réindexation de palette. Pour ça l'outil de préparation des images encode les nouveaux index de couleurs (on ne permute que 4 couleurs dans la palette) sur un octet et associe cette valeur à l'image. Dans le code il suffit de faire ça au niveau du code objet : Code: @a jsr GetImgIdA ; preprocessed palette color switch cmpa oldPal beq @b sta oldPal stu @dyn+1 ldb #0 ldy #Pal_Triangle+2 ; offset because cycling colors indexes are 1-4 ldu #Pal_TriangleTmp _lsrd _lsrd lsrb lsrb lsrb lsrb lsrb ldx b,y stx 8,u _lsrd _lsrd lsrb lsrb lsrb lsrb lsrb ldx b,y stx 6,u _lsrd _lsrd lsrb lsrb lsrb lsrb lsrb ldx b,y stx 4,u _lsrd _lsrd lsrb lsrb lsrb lsrb lsrb ldx b,y stx 2,u stu Cur_palette clr Refresh_palette @dyn ldu #0 ; (dynamic) @b jmp DisplaySprite A chaque fois que l'index change, on réactualise la palette de couleur. Pour le moment ça fonctionne en effectuant des permutations (1,2,3,4 devient 3,4,2,1), mais on peut envisager d'autoriser des réindexation du style : 1,1,1,1 quand il ne reste plus qu'une couleur dans l'image. Je pense que l'algo tel quel gère ce cas, il faut juste modifier les combinatoires à tester lorsqu'on cherche la meilleure solution. De même on ne gère que 4 couleurs mais ça peut être étendu à plus si le besoin se présente. |
Auteur: | Bentoc [ 30 Oct 2021, 22:27 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Le support de la lecture de fichiers midi est maintenant intégrée au moteur de jeu. Il est constitué des éléments suivants : - Un convertisseur de fichier midi - Un outil de "split" des données intégré au builder - Un driver asm pour la lecture "in game" L'objectif étant d'avoir un lecteur performant, voici les choix : - lecture par IRQ 50Hz - adaptation du format de fichier midi pour des données plus compactes sans pénaliser la vitesse d'exécution Convertisseur ------------- Pour ne pas pénaliser les perfs à la lecture et pour que les jeux qui utilisent les drivers FM ou Midi aient des perfs similaires, il fallait rester sur une IRQ à 50Hz. Il a donc fallu écrire un convertisseur qui redéfini les indicateurs temporels de chaque commande pour les arrondirs au 1/50s. Le convertisseur gère les changements de tempo en cours de morceau. Un fichier midi contient un indicateur de temps devant chaque bloc de commande, y compris si des blocs doivent être lus de manière consécutives (sans temps d'attente). Pour gagner en place, j'ai retiré l'indicateur quand celui ci vaut 0 (lecture consécutive), la valeur 0 devient l'indicateur de fin de page/données. La distinction se fait alors sur la plage de valeur : 00-7F : nombre de frame a attendre 80-FF : commande midi Pour mon fichier de test on passe de 54 052 octets à 46 687 octets (morceau de 4m 20s) juste avec cette modification sur le "timestamp" des messages. Je n'ai pas touché aux données midi pour ne pas avoir a décompresser les données au runtime (on cherche la performance) Outil de split -------------- Divise les données par page de 16Ko, mais ne coupe pas les données en plein milieu, on s'arrête avant le début d'une nouvelle commande. On ajoute alors une balise de fin (0). ça permet de simplifier le controle de fin de page/fin des données lors de la lecture, car on ne controle la fin qu'a chaque début de commande et non à chaque lecture d'un octet. Driver asm ---------- On gère tous les messages midi, y compris les sysex (pour changer à la volée les params des instruments) Voici le code : Code: * --------------------------------------------------------------------------- * SMIDI 6809 - Small Midi playback system for 6809 * --------------------------------------------------------------------------- * by Bentoc October 2021 * with inputs from Fool-DupleX * --------------------------------------------------------------------------- opt c,ct MIDI.CTRL EQU $E7F2 MIDI.STAT EQU MIDI.CTRL MIDI.RX EQU $E7F3 MIDI.TX EQU MIDI.RX MIDI.RXFULL EQU $01 MIDI.TXEMPTY EQU $02 MIDI.RXIRQ EQU $80 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 a lda #$ff sta MusicLoop ; set the loop flag on bra @a PlayMusic pshs a @a stx MusicIndex ; store index for loop restart stx MusicIndexPos ; init data chunck index position lda ,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 lda #1 sta WaitFrame ; wait frame is only zero where reading commands, should be init to 1 ldx 1,x ; get ptr to track data stx MusicDataPos ; init data location puls a,pc ****************************************************************************** * MusicFrame - processes a music frame (VInt - 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 ****************************************************************************** MusicFrame lda MusicStatus ; check if a music track is to play bne @a rts @a lda WaitFrame deca sta WaitFrame beq ReadCommand ; no more frame to wait, play the next commands rts IsMusicLoop tst MusicLoop beq StopMusic ldx MusicIndex bra LoopRestart StopMusic lda #0 sta MusicStatus sta MusicLoop rts BankSwitch ldx MusicIndexPos ; read byte was $00, this is end of data chunk or music track leax 5,x ; move to next index lda ,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 1,x ; get ptr to track data bra @a ; ReadCommand ldx MusicDataPos ; load current position in music track lda MusicPage @a _SetCartPageA CommandLoop lda ,x+ ; read data byte in new page bmi DoCommand beq BankSwitch DoWait sta WaitFrame stx MusicDataPos rts DoCommand cmpa #$C0 blo TXRdyLoop0 ; skip 2 bytes (command 8n to Bn, 2 data byte) cmpa #$E0 blo TXRdyLoop1 ; skip 1 byte (command Cn and Dn, 1 data byte) cmpa #$f0 beq DoSysEx ; bne: skip 2 bytes (command En, 2 data byte) TXRdyLoop0 ldb <MIDI.STAT ; wait interface to be ready andb #MIDI.TXEMPTY beq TXRdyLoop0 sta <MIDI.TX ; send byte to the midi interface lda ,x+ TXRdyLoop1 ldb <MIDI.STAT ; wait interface to be ready andb #MIDI.TXEMPTY beq TXRdyLoop1 sta <MIDI.TX ; send byte to the midi interface lda ,x+ TXRdyLoop2 ldb <MIDI.STAT ; wait interface to be ready andb #MIDI.TXEMPTY beq TXRdyLoop2 sta <MIDI.TX ; send byte to the midi interface bra CommandLoop DoSysEx ldb <MIDI.STAT ; wait interface to be ready andb #MIDI.TXEMPTY beq DoSysEx sta <MIDI.TX ; send byte to the midi interface lda ,x+ cmpa #$f7 bne DoSysEx sta <MIDI.TX ; send byte to the midi interface bra CommandLoop Question pour Fool-DupleX : on est obligé de faire du pooling avant chaque envoi d'un octet sur l'interface, ou on peut se baser sur un nb de cycles a attendre ? Une démo est prête ... Reste plus qu'a tester une fois l'interface disponible ;-) |
Auteur: | Samuel Devulder [ 31 Oct 2021, 08:33 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Quelques remarques d'optim: Code: @a lda WaitFrame LDA/DEC/STA coute 12 cycles, un "DEC WaitFrame 7" fait juste pareil (y compris au niveau du flag Z) cycles, et on économise 4 octets au massage.deca sta WaitFrame Code: beq ReadCommand ; no more frame to wait, play the next commands "LDA MusicLoop" positionne les mêmes flags que TST mais en 5 cycles au lieu de 7 (et hop 2 cycles de gagnés)rts IsMusicLoop tst MusicLoop Code: beq StopMusic CLRA pour économiser 1 octet, et si StopMusic est supposé n'être appelé que depuis IsMusicLoop dont on a optimisé le test avec un LDA, le registre A serait déjà égal à 0 ici et on aurat pas besoin de le clearer ldx MusicIndex bra LoopRestart StopMusic lda #0 Code: sta MusicStatus sta MusicLoop rts |
Auteur: | Bentoc [ 31 Oct 2021, 09:19 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Merci sam pour cette relecture ! Au passage j'ai corrigé un oubli dans la gestion de la lecture en boucle : Code: IsMusicLoop lda MusicLoop beq StopMusic ldx MusicIndex lda ,x bra LoopRestart StopMusic sta MusicStatus sta MusicLoop rts il manquait le rechargement de l'id de page (lda ,x) Je n'ai pas encore testé la fonction de boucle. Le reste a été testé avec le debugger de dcmoto. - les messages sont bien transmis sur le port - j'ai testé avec différents changement de tempo en cours de morceau et la durée de lecture équivaut à celle du morceau sous un player midi donc ça a l'air de bien se passer niveau timing. - les changements de bank se passent bien également J'ai hâte d'essayer ça avec l'extension ;-) |
Auteur: | Samuel Devulder [ 31 Oct 2021, 10:09 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Quelques autre remarques. Tu pourrais gagner de la place et de la vitesse en plaçant les variables "dans le code", c'est à dire au lieu d'avoir Code: MusicIndex RMB 2 Tu peux faire à l'endroit où l'on fait le plus fréquemment ce "LDX MusicIndex":(...) LDX MusicIndex Code: LDX #0 et tu laisse les autre "LDX MusicIndex" tels quels. Alors évidemment ca ne marchera pas avec du code en ROM, mais je ne pense pas que ce soit le cas général.MusicIndex SET *-2 ; (variable in code) Autre chose: le changement de page n'est pas local à l'interruption. Il semble global entre le jeu/demo et le serveur d'interruption, or il est possible que le programme principal utilise lui aussi le switching de bank. Du coup il y a risque que le programme principal voit sa bank courante changée par le player. Aussi il serait peut-être bon de sauvegarder la valeur de du registre de contrôle des banks en entrée de l'interruption et le restaurer à la sortie. |
Auteur: | Bentoc [ 31 Oct 2021, 12:23 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
ok pour l'automodif bonne idée. Sinon pour la gestion de page tu as raison, c'est exactement ce qui est fait : Code: * --------------------------------------------------------------------------- * Irq Smidi * ------- * IRQ Subroutine to play midi data * * input REG : [dp] with value E7 (from Monitor ROM) * reset REG : none * * IrqOn * reset REG : [a] * * IrqOff * reset REG : [a] * --------------------------------------------------------------------------- irq_routine equ $6027 irq_timer_ctrl equ $E7C5 irq_timer equ $E7C6 irq_one_frame equ 312*64-1 ; one frame timer (lines*cycles_per_lines-1), timer launch at -1 IrqSet50Hz ldb #$42 stb irq_timer_ctrl ; timer precision x8 ldd #IrqSmidi std irq_routine ldx #irq_one_frame ; on every frame stx irq_timer jsr IrqOn rts IrqOn lda $6019 ora #$20 sta $6019 ; STATUS register andcc #$EF ; tell 6809 to activate irq rts IrqOff lda $6019 anda #$DF sta $6019 ; STATUS register orcc #$10 ; tell 6809 to activate irq rts IrqSmidi _GetCartPageA sta IrqSmidi_end+1 ; backup data page ldd Vint_runcount addd #1 std Vint_runcount sts @a+2 ; backup system stack lds #IRQSysStack ; set tmp system stack for IRQ jsr MusicFrame @a lds #0 ; (dynamic) restore system stack IrqSmidi_end lda #$00 ; (dynamic) _SetCartPageA ; restore data page jmp $E830 ; return to caller ; This space allow the use of system stack inside IRQ calls ; otherwise the writes in sys stack will erase data when S is in use ; (outside of IRQ) for another task than sys stack, ex: stack blast copy fill 0,32 IRQSysStack J'ai aussi ajouté un espace dédiée à la pile système, ainsi je sais qu'en dehors des IRQ je peux faire du stack blast tranquille, j'ai juste à gérer les 12 octets potentiellement écrasés par la sauvegarde des registres lors de l'appel IRQ. Mais toute l'utilisation de la pile systeme dans le code appelé par l'IRQ utilise un espace dédié. J'ai juste à ajuster la taille de IRQSysStack en fonction des besoins, je sais que je n'aurai pas d'ajustement à faire ailleurs. |
Auteur: | Bentoc [ 31 Oct 2021, 12:24 ] |
Sujet du message: | Re: Outillage pour développement de jeux sur TO8 |
Pour terminer voici le code a placer pour déclencher la lecture : Code: jsr ResetMidi jsr IrqSet50Hz ldx #Smid_intro jsr PlayMusic Le label utilisé dans le code asm correspond a celui du fichier properties dans lequel on déclare le fichier midi à inclure dans le projet. Code: # Sound
sound.Smid_intro=./object/background1/music/dott-intro.smid |
Page 18 sur 40 | Heures au format UTC + 1 heure |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |