Logicielsmoto.com http://www.logicielsmoto.com/phpBB/ |
|
[Etude] Slap Fight http://www.logicielsmoto.com/phpBB/viewtopic.php?f=1&t=645 |
Page 4 sur 5 |
Auteur: | Samuel Devulder [ 13 Juin 2021, 16:59 ] |
Sujet du message: | Re: [Etude] Slap Fight |
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 Elle gère les 15 tirs potentiellement actifs des ennemis. Imaginez donc ce que pourrait faire un RTS ($39) en $CD4D... 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 sam (Give peace a chance ) |
Auteur: | Bentoc [ 13 Juin 2021, 17:16 ] |
Sujet du message: | Re: [Etude] Slap Fight |
Plus aucun tir ennemi ? |
Auteur: | Samuel Devulder [ 13 Juin 2021, 17:29 ] |
Sujet du message: | Re: [Etude] Slap Fight |
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 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 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 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. |
Auteur: | Samuel Devulder [ 13 Juin 2021, 23:37 ] |
Sujet du message: | Re: [Etude] Slap Fight |
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 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: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 Code: C1AE B6CEDA LDA $CEDA 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.. 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 Ouais Bingo!! Les balles nous traversent sans nous tuer. Note: La valeur $CEDA est écrite ici: Code: 2 CDFE C619 LDB #$19 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.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 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 ? |
Auteur: | Fool-DupleX [ 14 Juin 2021, 08:50 ] |
Sujet du message: | Re: [Etude] Slap Fight |
Citation: jusqu'à ce que je me souvienne que "bon sang!!!" 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 ? |
Auteur: | Bentoc [ 14 Juin 2021, 09:04 ] |
Sujet du message: | Re: [Etude] Slap Fight |
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. |
Auteur: | Fool-DupleX [ 14 Juin 2021, 09:21 ] |
Sujet du message: | Re: [Etude] Slap Fight |
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. |
Auteur: | Samuel Devulder [ 14 Juin 2021, 09:27 ] |
Sujet du message: | Re: [Etude] Slap Fight |
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à. |
Auteur: | Fool-DupleX [ 14 Juin 2021, 09:33 ] |
Sujet du message: | Re: [Etude] Slap Fight |
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 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 |
Auteur: | Samuel Devulder [ 14 Juin 2021, 09:46 ] |
Sujet du message: | Re: [Etude] Slap Fight |
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. |
Auteur: | Fool-DupleX [ 14 Juin 2021, 10:01 ] |
Sujet du message: | Re: [Etude] Slap Fight |
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. |
Auteur: | Fool-DupleX [ 14 Juin 2021, 10:17 ] |
Sujet du message: | Re: [Etude] Slap Fight |
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 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é. |
Auteur: | Samuel Devulder [ 14 Juin 2021, 10:58 ] |
Sujet du message: | Re: [Etude] Slap Fight |
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 ? 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. |
Auteur: | Fool-DupleX [ 14 Juin 2021, 11:20 ] |
Sujet du message: | Re: [Etude] Slap Fight |
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. |
Auteur: | Samuel Devulder [ 14 Juin 2021, 11:33 ] |
Sujet du message: | Re: [Etude] Slap Fight |
Oui l'histoire du checksum tombe à l'eau avec les secteurs de 128 en effet. Plouf ! 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.) |
Page 4 sur 5 | Heures au format UTC + 1 heure |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |