Logicielsmoto.com

Nous sommes le 27 Oct 2021, 13:11

Heures au format UTC + 1 heure




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

Inscription: 21 Aoû 2006, 09:06
Messages: 1523
Localisation: Brest
Bentoc a écrit:
(Bien joué pour les vies infinies)
Je crois que je peux faire mieux.

Vous voyez cette routine
Code:
      1 CD4D CECC73     LDU    #$CC73             
      1 CD50 860F       LDA    #$0F               
      1 CD52 3402       PSHS   A                   
     15 CD54 A6C4       LDA    ,U                 
     15 CD56 8163       CMPA   #$63               
     15 CD58 2712       BEQ    $CD6C               
      3 CD5A BDCD75     JSR    $CD75               
      3 CD5D A6C4       LDA    ,U                 
      3 CD5F 8163       CMPA   #$63               
      3 CD61 2709       BEQ    $CD6C               
      3 CD63 8EBADD     LDX    #$BADD             
      3 CD66 BDCAB3     JSR    $CAB3               
      3 CD69 BDCDB4     JSR    $CDB4               
     15 CD6C 3345       LEAU   $05,U               
     15 CD6E 6AE4       DEC    ,S                 
     15 CD70 26E2       BNE    $CD54               
      1 CD72 3502       PULS   A                   
      1 CD74 39         RTS                       
Elle gère les 15 tirs potentiellement actifs des ennemis. Imaginez donc ce que pourrait faire un RTS ($39) en $CD4D... :voyons:

sam (Give peace a chance :sol: )

_________________
Good morning, that's a nice Tnetennba


Dernière édition par Samuel Devulder le 13 Juin 2021, 17:36, édité 1 fois.

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

Inscription: 21 Avr 2019, 21:48
Messages: 198
Localisation: Var
Plus aucun tir ennemi ?


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

Inscription: 21 Aoû 2006, 09:06
Messages: 1523
Localisation: Brest
Bentoc a écrit:
Plus aucun tir ennemi ?
Ouais, et même le big boss, par contre nous on peut tous les dégommer et avoir une arme d'enfer à la fin !

Ouais, je sais c'est trop facile, alors regardons ce code:
Code:
      1 7DE9 8608       LDA    #$08               
      1 7DEB 3402       PSHS   A                   
      1 7DED CE7FD6     LDU    #$7FD6             
      3 7DF0 A6C4       LDA    ,U                 
      3 7DF2 8163       CMPA   #$63               
      3 7DF4 2709       BEQ    $7DFF               
      2 7DF6 334F       LEAU   $0F,U               
      2 7DF8 6AE4       DEC    ,S                 
      2 7DFA 26F4       BNE    $7DF0               
      1 7DFF EC02       LDD    $02,X               
      1 7E01 EDC4       STD    ,U                 
      1 7E03 10AE05     LDY    $05,X               
      1 7E06 ECA1       LDD    ,Y++               
      1 7E08 ED47       STD    $07,U               
      1 7E0A 10AF45     STY    $05,U               
      1 7E0D 6F42       CLR    $02,U               
      1 7E0F A604       LDA    $04,X               
      1 7E11 108E7E33   LDY    #$7E33             
      1 7E15 48         ASLA                       
      1 7E16 10AEA6     LDY    A,Y                 
      1 7E19 10AF43     STY    $03,U               
      1 7E1C 6F49       CLR    $09,U               
      1 7E1E A604       LDA    $04,X               
      1 7E20 A74B       STA    $0B,U               
      1 7E22 108E7E2D   LDY    #$7E2D             
      1 7E26 A6A6       LDA    A,Y                 
      1 7E28 A74A       STA    $0A,U               
      1 7E2A 3502       PULS   A                   
      1 7E2C 39         RTS                 
qui me semble gérer les 8 "petits" ennemis max à l'écran. Si on mets RTS ($39) au début, alors on aura une paix royale jusqu'au boss. Par contre comme on aura pas collecté de bonus on ne fait pas long feu face à lui. C'est pas cool :nanana:

L'idéal (qui m'échappe après 3 jours de recherche) serait de pouvoir être transparent aux balles des "petits" ennemis. Je ne sais pas si j'y arriverais, mais ca serait pour moi la triche la plus sympa car retirer toutes les armes aux ennemis est vraiment, mais vraiment trop facile. Ne trouves tu pas ?

PS: le comptage de nombre de fois où le PC est passé (!) dans avec le "uniq -c" est vraiment très utile quand on recherche un évènement unique (la destruction de notre vaisseau par exemple) dans un tas d'autre trucs.

_________________
Good morning, that's a nice Tnetennba


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

Inscription: 21 Aoû 2006, 09:06
Messages: 1523
Localisation: Brest
Samuel Devulder a écrit:
L'idéal (qui m'échappe après 3 jours de recherche) serait de pouvoir être transparent aux balles des "petits" ennemis.
J'ai pu déterminer que la routine:
Code:
81DB 3450       PSHS   U,X                 
81DD 8E8163     LDX    #$8163             
81E0 48         ASLA                       
81E1 48         ASLA                       
81E2 48         ASLA                       
81E3 3086       LEAX   A,X                 
81E5 EC81       LDD    ,X++               
81E7 FD81D3     STD    $81D3               
81EA EC81       LDD    ,X++               
81EC FD81D5     STD    $81D5               
81EF EC81       LDD    ,X++               
81F1 FD81D7     STD    $81D7               
81F4 EC81       LDD    ,X++               
81F6 FD81D9     STD    $81D9               
81F9 8E81D3     LDX    #$81D3             
81FC A601       LDA    $01,X               
81FE 3402       PSHS   A                   
8200 A684       LDA    ,X                 
8202 2721       BEQ    $8225               
8225 EE04       LDU    $04,X               
8227 A606       LDA    $06,X               
8229 3402       PSHS   A                   
822B BD8242     JSR    $8242               
822E A6C0       LDA    ,U+                 
8230 4A         DECA                       
8231 26FD       BNE    $8230               
8233 6AE4       DEC    ,S                 
8235 26F4       BNE    $822B               
8237 3502       PULS   A                   
8239 6AE4       DEC    ,S                 
823B 26EA       BNE    $8227               
823D 3502       PULS   A                   
823F 3550       PULS   X,U                 
8241 39         RTS                       
8242 B6E7C1     LDA    $E7C1               
8245 8808       EORA   #$08               
8247 B7E7C1     STA    $E7C1               
824A 39         RTS 
joue le son quand on est touché. Si dans une trace où je suis touché je recherche d'où l'on vient on trouve ceci:
Code:
C1AE B6CEDA     LDA    $CEDA               
C1B1 2726       BEQ    $C1D9               <== cas où on est pas touché
C1B3 7ACEDA     DEC    $CEDA               <== ici on est appelé que lorsqu'on est touché
C1B6 10270C5A   LBEQ   $CE14               
C1BA 810A       CMPA   #$0A               
C1BC 2D1A       BLT    $C1D8               
C1BE 8401       ANDA   #$01               
C1C0 2705       BEQ    $C1C7               
C1C2 8EBCA6     LDX    #$BCA6             
C1C5 2003       BRA    $C1CA               
C1C7 8EBD66     LDX    #$BD66             
C1CA BFC1A6     STX    $C1A6               
C1CD 8EC1A3     LDX    #$C1A3             
C1D0 BD7E7F     JSR    $7E7F               
C1D3 860A       LDA    #$0A               
C1D5 BD81DB     JSR    $81DB <== beep               
C1D8 39         RTS       
Dans une trace où on ne meurt pas on trouve que le BEQ est pris en compte. Ok il semble que $CEDA non nul ait avoir avec le fait d'être touché. Remplaçons ce LDA par un CLR ($7F) pour voir ce qu'il se passe..

Ouais Bingo!! :coolfuck: Les balles nous traversent sans nous tuer.

Note: La valeur $CEDA est écrite ici:
Code:
      2 CDFE C619       LDB    #$19               
      2 CE00 F7CEDA     STB    $CEDA               
      2 CE03 FCC7B6     LDD    $C7B6               
      2 CE06 8B06       ADDA   #$06               
      2 CE08 CB05       ADDB   #$05               
      2 CE0A FDC1A3     STD    $C1A3               
      2 CE0D B6C7B8     LDA    $C7B8               
      2 CE10 B7C1A5     STA    $C1A5               
      2 CE13 39         RTS                       
On peut donc aussi mettre un RTS au début pour être invulnérable. Cela dit il y a peut-être d'autres endroits qui écrivent suivant la nature du BOSS qui nous tire dessus.

Malgré cela, perso je n'arrive pas à avoir l'équipement complet. Je n'arrive pas à savoir si je le perds au fur et à mesure où si le loupe plein de bonus. De votre coté, vous arrivez à avoir l'équipement complet avec laser et tout ?

_________________
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, 08:50 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 437
Citation:
jusqu'à ce que je me souvienne que "bon sang!!!" :eek: les secteurs des diskettes DOS thomson ne font pas 256 octets mais 255 et que le $34 tombant en $xxxFE c'est à dire le dernier octet d'un secteur, il est purement et simplement ignoré par le dos Thomson.

Peux-tu nous expliquer d'où sort cette étrangeté ? Je n'en avais jamais entendu parler. D'ailleurs quand on regarde de près les routines de lecture et d'écriture de secteur, par exemple dans le contrôleur CD90-351, c'est bien 256 octets qui sont lus et écrits. Ce qui est indispensable si on veut pouvoir lire la FAT ou le catalogue correctement ...

Par contre, si tu me dis que le BASIC n'est capable de stocker que 255 caractères par variable string et que du coup les instructions DSKI$ et DSKO sont pourries en double densité, là je suis d'accord. Es-tu en train de dire que LOADM a le même genre de limitation ?


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

Inscription: 21 Avr 2019, 21:48
Messages: 198
Localisation: Var
C'est le DOS (extramon) qui n'utilise que 255 octets par secteur en double densité (p269 manuel technique du TO8).
Avec DKCO il n'y a pas cette limitation et on travaille bien avec les 256 octets.

Mais je laisse Sam répondre il aura peut être plus de détails sur ce sujet.


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

Inscription: 06 Juin 2004, 08:23
Messages: 437
Bizarrerie qui me semble extrêmement liée au BASIC. Et donc connue (ouf). Mais ce n'est pas le DOS, juste le BASIC. Effectivement, un SAVE ou SAVEM semble n'utiliser que 255 octets par secteur, le dernier octet est répété.

Car si on utilises un logiciel comme LOGO ou Gérez vos fiches, ce n'est pas le cas (je viens de vérifier), les secteurs sont utilisés à plein.

Cette idiotie vient du fait que BASIC ne gère que 255 caractères par chaîne string au max. Je connaissais le problème pour DSKI$ et DSKO, mais je ne savais pas que LOAD et LOADM faisaient de même, quelle misère.

Edit: page 278 du manuel technique des TO8/8D/9/9+, je cite:

Citation:
Attention : sur le TO9, en double densité EXTRAMON prend NBOct à 256 octets au lieu de 255, d'où de petites erreurs de calcul... Ce problème n'existe plus sur TO8 et TO9+.


Autrement dit, ils ont imposé un bug dû au BASIC Microsoft comme la nouvelle norme. Ca me rappelle cette vieille blague : "Combien faut-il d'ingénieurs de chez Microsoft pour changer une ampoule ? Zéro. Microsoft se contente de déclarer l'obscurité comme le nouveau standard."

pfff.


Dernière édition par Fool-DupleX le 14 Juin 2021, 09:30, édité 1 fois.

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

Inscription: 21 Aoû 2006, 09:06
Messages: 1523
Localisation: Brest
Oui c'est l'extramon TO9 qui impose ca (parce que les codeurs n'ont pas su compter de 256 fois sur 8 bits, genre: LDB #255 .. DECB BNE ca ne fait que 255 tours). Cette contrainte se retrouve ensuite dans les outils en ROM du TO9: paragraphe, exploitation de fichiers, basic 128, les diskettes dos-basic, et les outils un peu plus modernes comme SAPFS ou DCFDUtils.

Ne pas respecter cela c'est avoir des fichiers qui perdront 1 octet tous les 256 quand ils sont lu par le moindre de ces outils en rom utilisant l'extramon. Le pire étant la recopie par "exploitation de fichier" car la copie sera corrompue (je présume que la copie disk à disk marche complètement elle).

C'est pas pour rien que Préhisto préfère de loin les track-loaders qu'aux BIN du dos. Le dos est lent, gourmand et globalement mal-fichu (il n'y a qu'à voir le soucis récurrent de la FAT inversée par le MINIDOS/SCRATCHDOS dans SDDrive).

Après savoir si c'est le basic ou l'extramon qui est la cause de cela. Je n'en sais rien. C'est la spec du DOS-Thomson.

PS: je me demande si la réputation d'être buggé de "Fiche et dossiers" ne viendrait pas de là.

_________________
Good morning, that's a nice Tnetennba


Dernière édition par Samuel Devulder le 14 Juin 2021, 09:33, édité 1 fois.

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

Inscription: 06 Juin 2004, 08:23
Messages: 437
Citation:
C'est la spec du DOS-Thomson.

Ou est-ce écrit ? Pour moi le DOS, c'est miniDOS, celui qui est dans la ROM contrôleur et qui est commun à toutes les machines. Or celui-ci utilise 256 octets. Ce que l'applicatif décide de faire ensuite, c'est autre chose. L'extra-mon n'existe pas sur mo ni sur TO7-70 et sur le to9, c'est apparemment 256 octets qui font foi ... (voir mon ajout ci-dessus)

C'est fou :lol:

Ce n'est pas que les ingés ne savent pas compter jusqu'à 256. Je pense qu'à l'époque de la simple densité, personne n'a réalisé que 255 caractères dans une chaîne BASIC, le système d'exploitation de facto, poserait problème. Impossible ensuite de modifier le BASIC, trop d'împact, il valait mieux ajouter une couche d'abstraction moisie.

Cela dit, pas étonnant que je sois étonné, je n'ai jamais utilisé ces routines haut niveau qui vous éloignent de la machine :W


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

Inscription: 21 Aoû 2006, 09:06
Messages: 1523
Localisation: Brest
La gestion des fichiers par minidos n'est pas officielle. Ne reste de sa spec que la routines pour lire/écrire/formater les secteurs complets de 256 octets. La dessus extramon ajoute le système de fichier. Minidos a de gros soucis avec le système de fichier justement (cf les déboires de Daniel avec SDDrive).

Je ne sais pas ce qu'est la doc de référence, mais je connaissais ceci dès l'achat de mon TO9 car dans les annexes du classeur y était inscrit le format des diskette DOS avec justement les secteurs sur 255 octets.

Je ne sais pas si c'est une limitation du basic. Il y a peut-être une inspiration des blocs logiques comme sur casette avec un checksum. Checksum stocké sur le 256e octet, mais devenu à l'usage inutile dans la mesure où les diskettes sont plus fiables que les casettes.

_________________
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, 10:01 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 437
Citation:
Il y a peut-être une inspiration des blocs logiques comme sur casette avec un checksum.

Je ne crois pas. Un bloc cassette standard devrait faire 253 octets de data. Ou est le rapport ?

Par contre, ce que je sais, c'est que l'extra-moniteur n'existe pas sur bon nombre de machines de la gamme et que les logiciels commerciaux en MEMO7 ne l'utilisent pas. Par conséquent il se retrouve minoritaire et n'est pas la norme. C'est navrant que Thomson ait poussé cela sur les machines TO de deuxième génération.


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

Inscription: 06 Juin 2004, 08:23
Messages: 437
HAHAAA! Extrait de la doc du TO9 à laquelle tu faisais allusion :

Citation:
Cette annexe est destinée à ceux qui veulent en savoir un peu plus sur la manière dont BASIC 128 gère une disquette.

Citation:
Chaque secteur contient 128 octets utiles sur une disquette en simple densité ou 255 octets utiles en double densité.

Sauf que droit derrière, ils expliquent que le répertoire contient des entrées de 32 octets par fichier, soit forcément 128 ou 256 octets par secteur au total... Quelle chance que les derniers octets d'une entrée soient inutilisés ! Mais évidemment, on n'échappe pas au problème avec la FAT.

Et il est donc impossible d'écrire un programme en BASIC 128 et à fortiori utilisant l'extra-moniteur ensuite, capable de gérer autre chose que des fichiers produits par eux. C'est vraiment une c*rie :bien:

Je comprends mieux une ancienne chamaillerie que j'avais eue avec Prehisto durant laquelle il soutenait mordicus que les secteurs avaient 255 octets, chose qui me semblait totalement insensée. N'ayant jamais utilisé une machine de deuxième génération quand j'étais gamin, je n'ai jamais considéré cette bêtise comme la norme, juste comme un bug du BASIC avec le lecteur double densité.


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

Inscription: 21 Aoû 2006, 09:06
Messages: 1523
Localisation: Brest
Fool-DupleX a écrit:
Citation:
Il y a peut-être une inspiration des blocs logiques comme sur casette avec un checksum.

Je ne crois pas. Un bloc cassette standard devrait faire 253 octets de data. Ou est le rapport ?
Le checksum justement.

Tu parles de minoritaire, mais il y a eu beaucoup plus de machine de 2nde génération avec des diskette haute-densité que de TO7/70 ou MO5.

_________________
Good morning, that's a nice Tnetennba


Dernière édition par Samuel Devulder le 14 Juin 2021, 11:34, édité 3 fois.

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

Inscription: 06 Juin 2004, 08:23
Messages: 437
Y'a pas de checksum sur disquette et c'est inutile. Il y a déjà le CRC-16, qui est hors données utiles. Je ne vois toujours pas le rapport. Et c'est pas logique avec les secteur de 128 octets (ils feraient 127 dans ce cas). Sur QDD, y'a un checksum par secteur comme sur cassette. Il est hors données utiles (128 octets par secteur+checksum).

Par contre, je vois très bien le rapport avec le fait que le BASIC ne sait pas gérer des chaînes de 256 octets. Et avec le fait que la doc du TO9 parle de BASIC 128, pas de DOS.

Je vais creuser l'origine du truc, ça m'intéresse.


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

Inscription: 21 Aoû 2006, 09:06
Messages: 1523
Localisation: Brest
Oui l'histoire du checksum tombe à l'eau avec les secteurs de 128 en effet. Plouf ! :jap:

Cela dit, je suis étonné que tu parles de limitations du basic, car il me semble que Colorpaint, qui utilise le minidos, génère des fichiers totalement compatible avec le DOS-basic, c'est à dire avec des secteurs logiques de 255 octets sur les supports HD et 128 octets sur les basses densités. Donc la limite a du s'imposer très tôt dans l'histoire thomson, à l'époque même du BASIC1 (j'ai eu colorpaint en même temps que le TO7/70 et le basic1.)

_________________
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  [ 66 messages ]  Aller à la page Précédente  1, 2, 3, 4, 5  Suivante

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 6 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 à:  
cron
Développé par phpBB® Forum Software © phpBB Group
Traduction par phpBB-fr.com