Logicielsmoto.com

Nous sommes le 28 Mar 2024, 09:12

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 69 messages ]  Aller à la page Précédente  1, 2, 3, 4, 5
Auteur Message
 Sujet du message: Re: [Etude] Slap Fight
MessagePosté: 14 Juin 2021, 13:26 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 464
Je me suis replongé dans quelques magazines et j'ai posé quelques questions à droite à gauche.

Sur les machines de première génération (T9000, TO7, TO7/70 et MO5), il n'y avait pas de double densité. Le lecteur officiel était le CD90'015 et les secteurs faisaient 128 octets. Et étant donné que Microsoft Basic 1.0 était le système d'exploitation de facto, il n'y avait aucun problème.

Puis est arrivé le lecteur CD90-640 ("Enfin un vrai lecteur de disquette chez Thomson !" titrait je ne sais plus quel magazine) : 5"1/4 double densité.

Mais personne ne savait vraiment gérer ce lecteur. Est arrivé au même moment le BASIC 128 pour TO7/70, sensé résoudre ce problème et tant d'autres (16 couleurs, DOS intégré, gestion de l'extension RAM). Le nouveau standard. BASIC 128 a été au début encensé, puis les gens se sont rendu compte que tout n'était pas rose (par exemple, performances catastrophiques avec le QDD, 4 fois plus lent que sous Basic 1.0).

Et c'est bien la limitation du BASIC aux chaînes de caractère de 255 octets qui a entraîné ce choix malheureux de secteur bancal ! Que faire : modifier toute la mécanique des chaînes de caractère, quitte à rendre le BASIC 128 incompatible avec le BASIC 1.0, ou mettre discrètement sous le tapis ce très gênant 256ème caractère ?

C'est le second choix qui a été retenu. En vérité, ça semblait plutôt une bonne idée sur le moment.

BASIC 128 a ensuite été intégré au TO9. Et l'idée d'extra-moniteur date de la même époque. Et plus possible de faire marche arrière, pas vraiment besoin non plus ...

Par contre, ceux qui avaient des MO, Tintin ! Thomson a bricolé un DOS Basic v1.1 vite fait qui est compatible, mais c'est tout. De toute manière, qui possédait un lecteur de disquette sur MO, hein, c'était la branche pour les pauvres (c'est-à-dire moi !)

En lisant certaines docs en détail, on s'aperçoit que Thomson a vraiment bricolé sur ce coup-là. Par exemple, la ROM contrôleur du CD90-640 a une liste de logiciels MEMO7 simple densité pour pouvoir les reconnaitre en cas de pépin. Une bonne grosse verrue. La page 8 du manuel utilisateur du lecteur en fait état !

Un vrai scandale :fresh: Mais après 40 ans, je comprends enfin l'utilité de la notion de densité et de la complexité à copier les fichiers de l'une à l'autre.

Bon, désolé d'avoir pollué le fil de discu avec cette histoire, parce que le reste est vraiment intéressant.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: [Etude] Slap Fight
MessagePosté: 14 Juin 2021, 14:02 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Donc le basic 128 prédate le TO9. Je ne savais pas. Sur TO7/70 j'ai toujours connu le basic 1.0.

C'est vrai qu'on devrait déplacer cette partie dans la partie "historique" du forum. Yoann peut-être ?

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: [Etude] Slap Fight
MessagePosté: 14 Juin 2021, 15:18 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 464
Commercialement, le BASIC 128 et le TO9 sont sortis en même temps (automne 85), mais apparemment la logique était de faire d'abord un BASIC 2.0 pour TO7/70 et ils l'ont fort logiquement intégré au TO9, puisque le BASIC 1.0 était insuffisant pour gérer le TO9. Tout ça c'était du travail en parallèle de toute façon. Le TO9 étant un "super TO7-70", difficile de dire qui de l'oeuf ou de la poule est arrivé en premier.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: [Etude] Slap Fight
MessagePosté: 13 Sep 2021, 11:56 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Bentoc a écrit:
Je vais suivre cette analyse avec attention car j’ai bcp joué a ce jeu (difficile), et je suis curieux de savoir ce qu’il y a « derrière ».
Très bonne idée Sam :bien:


Ben pas si difficile que cela si on joue à la version crackée de HCL avec options! (Comme par exemples vies infinies)


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: [Etude] Slap Fight
MessagePosté: 13 Sep 2021, 12:06 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Bentoc a écrit:
Avec le nouvel écran titre !!! :good:

Chapeau pour cette version "Bidouille by SAM"

As-tu un cheat code pour avoir des vies infinies ? :D

Je passe le boss mais après ça se corse un peu ...


Comme je le disais, HCL avait édité tout un ensemble de jeux Thomson patchés avec des options diverses (vies infinies notamment), ils sont sur DC Moto.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: [Etude] Slap Fight
MessagePosté: 13 Sep 2021, 14:17 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Samuel Devulder a écrit:
Il y a quelques temps je suis tombé sur la vidéo de Neotenien au sujet de Slap Fight
phpBB [video]


Comme il le fait remarquer l'affichage est très coloré et pas mal rapide. Aussi j'ai voulu l'étudier pour évaluer sa vitesse de rafraichissement.

Pour ce faire, j'ai mis un point d'arrêt en écriture au milieu de la première ligne écran ($4014) sous DCMOTO et utilisé la fonction de comptage de cycle entre deux arrêts. Je crois qu'il est aussi possible de faire cela sous TEO, mais j'ai fait avec ce que j'avais sous le coude en dépit de quelques surprises qui m'ont aussi pas mal amusées, mais c'est une autre histoire.

J'ai alors observé ceci
  • 1ère écriture au bout de ~103330 cycles (PC=$C0A7 Page 2000 -> forme)
  • 2eme écriture au bout de 579 cycles (PC=$C0D4 Page 000 -> fond)

L'une des deux écritures est la vidéo de forme et l'autre de fond. Le total (environ 104ms) nous donne le temps moyen de rafraichissement de l'ensemble de l'écran à ce moment là du jeu (le tout début, quand il n'y a que le sprite du vaisseau). Cela nous fait environ 9.6fps, c'est pas mal du tout. :bien:

Vous me connaissez, j'ai poussé l'étude un peu plus loin pour voir s'il était possible d'améliorer cela un petit peu. J'ai quelques résultats et plutôt que de tout donner d'un coup, ce qui serait assez indigeste, je vous propose de suivre ici, dans ce fil, pas à pas, mes avancées sur ce jeu.

A plus tard.


C'est super que tu aies réussi à optimiser de 20%

Mais je recommande à tout le monde de regarder la vidéo jusqu'à la fin, je parle notamment de l'émulation à 4MHz du jeu (pour avoir la même fréquence que sur l'Amstrad, le ZX Spectrum et les MSX) et on voit un jeu d'une vitesse phénoménale!! Je pense que si les Thomson était à 2 MHz au lieu de 1, ça aurait défié toute la concurrence des 8 bits. Les 6809 sont à 0.42 MIPS par MHz, les 6502 sont à 0.43 (parce qu'il n'ont pas les instructions indexées, pas de registres 16 bits ni de mode indexé, ni même le MUL) et je crois que les ZX80 sont à environ 0.15 MIPS par MHz (0.52 pour les 3.8 MHz). Les 8088 c'est encore pire (quand on voit que les Thomson égalaient les 8088 à 4.66 MHz...).

Franchement les 6809 (et les 6309 d'Hitachi) c'était vraiment du bon processeur!


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: [Etude] Slap Fight
MessagePosté: 10 Juil 2022, 17:48 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Samuel Devulder a écrit:
Il n'y a pas non plus de synchro VBL, ni de double buffering-hardware (le jeu tourne sur MO5 et TO7/70). L'espace de jeu est redessiné à chaque image dans un buffer caché, lequel est ensuite recopié à l'écran par le 1ere routine que j'ai dé-assemblée. C'est du "bourrin" et on aura difficilement plus rapide que 12FPS qui correspondent à remplir le buffer interne (disons 6ko) puis recopier à l'écran (disons 7ko), ce qui nous fait un débit total de 150ko/sec à 12fps, soit 6 cycles (~le temps d'un LDA/STA ,X+) entre les accès mémoire. Pour ainsi dire le CPU passe son temps à lire ou écrire un octet en mémoire dans le jeu.


Donc ça signifie qu'il y a quand même un buffer sur les MO5/TO7 pour le terran de jeu quand même ?

Juste pour en apprendre d'avantage, parce que ça pourra me servir : ça veut dire qu'il y a un espace buffer pour le terrain qui est scrollé verticalement puis recopié sur l'écran, puis les sprites par la suite ? Donc ça signifie qu'il y a un moment où les sprites disparaissent à l'écran ?

Pour des futures créations justement je me demandais s'il était possible de faire autrement qu'ainsi (à savoir un buffer pour le fond qu'on scrolle et qu'on ets obligé de recopier)... Ca signifie quo'n ne peut se contenter d'une seule copie de masse, mais il en faut 2...

Après je me demande si, avec l'nstruction TFM du 6809, o,n aurait un scrolling plus rapide (en mode natif qui plus est).

Et en fait, il est même possible de tester si le 6309 est présent (écrit dans la doc officielle du 6309) et de choisir entre le scrol via TFM et mode natif ou simplement via des puls/pshs. N'empêche que si le 6309 était à 2, ou même 1.79 MHz comme sur le Coco 3, ça serait un plus... Mais bon ça va, on arrive quand même à avoir de bons trucs avec le 6309 à 1 MHz.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: [Etude] Slap Fight
MessagePosté: 10 Juil 2022, 20:09 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Non il n’y a aucune zone mémoire scrollée car cela entraînerait les anciens sprites avec. Non ce sont juste les tuiles qui sont redessinées un peu plus bas dans le buffer caché. Puis les sprites sont appliqués sur ce buffer, et enfin le tout est recopié à haute vitesse dans la ram vidéo. Il’n’y a donc aucun clignotement de sprites visible car tout se passe dans le buffer caché. Il n’est pas non plus besoin de restaurer ce qu’il y avait sous les sprites puisque les tuiles de fond vont tout écraser au cycle d’affichage suivant.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: [Etude] Slap Fight
MessagePosté: 18 Juil 2022, 15:34 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Samuel Devulder a écrit:
Non il n’y a aucune zone mémoire scrollée car cela entraînerait les anciens sprites avec. Non ce sont juste les tuiles qui sont redessinées un peu plus bas dans le buffer caché. Puis les sprites sont appliqués sur ce buffer, et enfin le tout est recopié à haute vitesse dans la ram vidéo. Il’n’y a donc aucun clignotement de sprites visible car tout se passe dans le buffer caché. Il n’est pas non plus besoin de restaurer ce qu’il y avait sous les sprites puisque les tuiles de fond vont tout écraser au cycle d’affichage suivant.


Imagine de faire cette chose avec le double buffer, et la bascule de l'esapce cartouche sur la banque la banque 2 ou 3, redessiner tout le terrain puis les sptites dessus ensuite et basculer la RAM vidéo sur cette banque, on multiplie quasiment par 2 la vitesses d'affichage du jeu vidéo... ou encore mieux, si on a un double buffer sur le fond, dison la banque 4 (espace logique $A000), on fait un scrolling dessus (avec PUL/PHS) dessus beaucoup plus rapide que de retracer les tuiles, puis on copie l'ensemble dans l'espace cartouche qui pointe dans la banque 2 (1 activé pour l'écran) et on recopie les sprites. (Quoique je ne suis pas sûr que cette méthode soit finalement plus rapide puisqu'on refait une copie de l'écran scrollé)


Haut
 Profil  
Répondre en citant le message  
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  [ 69 messages ]  Aller à la page Précédente  1, 2, 3, 4, 5

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 16 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