Logicielsmoto.com

Nous sommes le 28 Mar 2024, 19:34

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 598 messages ]  Aller à la page Précédente  1 ... 17, 18, 19, 20, 21, 22, 23 ... 40  Suivante
Auteur Message
MessagePosté: 01 Nov 2021, 11:50 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 464
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.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 01 Nov 2021, 14:58 
Hors ligne
M. DCMOTO

Inscription: 06 Juin 2004, 08:23
Messages: 681
Localisation: Provence (France)
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.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 01 Nov 2021, 15:26 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 464
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 ... :oops: car le bouquin fait tout de même 8 cm d'épaisseur et plus de 5 kg.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 09 Déc 2021, 15:36 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
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


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 09 Déc 2021, 16:08 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
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.

_________________
Good morning, that's a nice Tnetennba


Dernière édition par Samuel Devulder le 09 Déc 2021, 16:22, édité 2 fois.

Haut
 Profil  
Répondre en citant le message  
MessagePosté: 09 Déc 2021, 16:12 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
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.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 09 Déc 2021, 17:14 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
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


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 16 Déc 2021, 10:01 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
ç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
sonic.png [ 40.64 Kio | Vu 4798 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.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 16 Déc 2021, 10:49 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
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
sonic2.png [ 26 Kio | Vu 4798 fois ]


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 16 Déc 2021, 12:09 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
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.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 16 Déc 2021, 12:46 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
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.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 16 Déc 2021, 22:49 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Humm je ne sais pas trop où poster ca, mais le challenge concernant Sonic se fait du coté C64
phpBB [video]

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 16 Déc 2021, 23:25 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
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 ;-)


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 16 Déc 2021, 23:44 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 478
ouaa super sonic sur c64....
il vient de poster une nouvelle vidéo même
https://www.youtube.com/watch?v=tDnLJJ7B4Pw

_________________
Image


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 17 Déc 2021, 00:05 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Et hop je rediffuse en sens inverse :)

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  [ 598 messages ]  Aller à la page Précédente  1 ... 17, 18, 19, 20, 21, 22, 23 ... 40  Suivante

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 24 invités


Vous ne pouvez pas poster de nouveaux sujets
Vous ne pouvez pas répondre aux sujets
Vous ne pouvez pas éditer vos messages
Vous ne pouvez pas supprimer vos messages
Vous ne pouvez pas joindre des fichiers

Rechercher:
Aller à:  
Développé par phpBB® Forum Software © phpBB Group
Traduction par phpBB-fr.com