[dcmoto] charger un long programme basic

[Daniel]

En comparant les fichiers ARKAMOID.BAS sauvegardés sur TO d'une part, sur MO d'autre part, on observe de grosses différences :
- Dans l'entête d'abord, et pas seulement dans l'adresse de chargement, dans la structure également.
- Dans la taille du fichier (383 octets d'écart).

Code : Tout sélectionner

------------------------------------------
ARKAMOID.BAS sauvegardé sur ordinateur TO
Taille du fichier : $CEC2
------------------------------------------
00000000   FF AE E5 04 00 07 00 00  3A 8D 00 00 25 00 01 AE   ÿ®å     :   %  ®
00000010   20 32 30 30 30 2C 2C 35  30 3A 87 BC 20 31 30 35    2000,,50:‡¼ 105
00000020   30 20 3A 8D 66 69 72 73  74 20 73 65 74 75 70 00   0 : first setup 
00000030   00 26 00 02 87 BC 20 31  39 30 30 30 3A 87 BC 20    &  ‡¼ 19000:‡¼ 
00000040   31 38 30 30 30 3A 87 BC  20 31 31 35 30 3A 87 BB   18000:‡¼ 1150:‡»
00000050   20 39 30 30 30 00 00 61  00 05 3A 8D 57 61 69 74    9000  a  : Wait

------------------------------------------
ARKAMOID.BAS sauvegardé sur ordinateur MO
Taille du fichier : $D041
------------------------------------------
00000000   FF 70 6D 04 00 25 00 01  AE 20 32 30 30 30 2C 2C   ÿpm  %  ® 2000,,
00000010   35 30 3A 87 BC 20 31 30  35 30 20 3A 8D 66 69 72   50:‡¼ 1050 : fir
00000020   73 74 20 73 65 74 75 70  00 00 26 00 02 87 BC 20   st setup  &  ‡¼ 
00000030   31 39 30 30 30 3A 87 BC  20 31 38 30 30 30 3A 87   19000:‡¼ 18000:‡
00000040   BC 20 31 31 35 30 3A 87  BB 20 39 30 30 30 00 00   ¼ 1150:‡» 9000  
00000050   61 00 05 3A 8D 57 61 69  74 20 66 65 77 20 73 65   a  : Wait few se

[EDIT] Encore une bizarrerie : Dans le listing original d'arkamoid, beaucoup de lignes se terminent par un espace.
Avec les TO, si une ligne se termine par un espace, la ligne suivante est (souvent mais pas toujours) ignorée par la simulation du clavier.
Avec les MO, la ligne est traitée normalement.
C'est ce qui explique la différence de taille des fichiers .BAS : Dans le fichier TO il manque au moins trois lignes : 550, 1050 et 19000.
Les BASIC 128 et 256 recèlent bien des mystères...

[Fool-DupleX]

Au-delà le bit 15 à 1 doit provoquer une erreur.

Un problème de calcul sur entiers signés peut-être ? Sur MO5 avec le BASIC 1.0, par définition, on n'atteint jamais 32 Ko, vu qu'il n'y a que 31008 octets de disponibles. Et Thomson nous a habitué à ce genre de corner cases déjà avec les secteurs disquette de 255 octets parce que les strings en BASIC ne peuvent pas faire 256 octets (problème n'apparaissant pas en simple densité donc pas envisagé au début).

En tout cas, je suis vos aventures avec intérêt.

[Daniel]

Théoriquement, en comparant le désassemblage du BASIC 128 et du BASIC 512 on devrait pouvoir trouver le bug. J'ai commencé à chercher, mais ce n'est pas simple avec une multitude de subroutines qui appellent elle-mêmes d'autres subroutines.

En attendant je crois qu'en version MO la bonne solution est de sauvegarder le programme en ASCII.
J'ai testé sur PC128 avec SDDRIVE. Le temps de chargement est de cinq minutes.

arkamoid_pc128sd.zip

(22.82 Kio) Téléchargé 2 fois

[__sam__]

[EDIT] Encore une bizarrerie : Dans le listing original d'arkamoid, beaucoup de lignes se terminent par un espace.
Avec les TO, si une ligne se termine par un espace, la ligne suivante est (souvent mais pas toujours) ignorée par la simulation du clavier.
Avec les MO, la ligne est traitée normalement.
C'est ce qui explique la différence de taille des fichiers .BAS : Dans le fichier TO il manque au moins trois lignes : 550, 1050 et 19000.

Ces lignes sont surtout précédées par un REM (') sans numéro de ligne:
https://github.com/cttpla/Arkamoid_MO6/ ... AS#L90-L96

Code : Tout sélectionner

540 IF BRICKS(PSXB+DX,PSYB+MOVY) THEN PX=PSXB+DX:PY=PSYB+MOVY:GOSUB 550:MOVY=MOVY*-1:RETURN 'Collisione diagonale
' Score and check for end level  
550 PLRSCR(PLR)=PLRSCR(PLR)+1+(2*BNS):BNS=BNS+1:NBR=BRICKS(PX,PY):IF NBR=2 THEN NBR=-1

' MAIN PROGRAM SETUP 
1050 POKE &H2019,PEEK(&H2019) OR 8  'NO BUZZER
1060 DIM PLTT(15):FOR I=1 TO 15:PLTT(I)=PALETTE (I):NEXT

'
19000 POKE &H2076,255:CONSOLE,,,,3:LOCATE,,0:SCREEN7,0,0:CLS
19010 PALETTE 1, 1904

J'étais tombé sur ces numéro sur TO en essayant la technique du RENUM. J'imagine que le parsing du basic se mélange les pinceaux lors du traitement d'un REM en interractif sans numéro de ligne, mais ca n'est pas systématique.

Chose anecdotique : ce sont les lignes avec des POKE spécifique aux MO (suppression du delai de l'auto-repeat et du beep clavier).

Je me demande comment l'auteur a pu tester le programme sur machine réele. Il l'a aussi sauvé en ascii ?

[Daniel]

Il n'y a aucune raison évidente de supprimer une ligne numérotée après une ligne sans numéro terminée par CR-LF.
Reste à prouver que c'est un bug du BASIC 512. Ça peut être aussi un bug de la simulation du clavier TO dans dcmoto.
Mais pourquoi sur TO et pas sur MO ? Tout ce problème est bien compliqué et bien mystérieux...

[__sam__]

En fait comme le programme est pour MO le problème des lignes disparues n'est pas si important que cela dans le fond.

Par contre le fait que les fichiers sur K7 soient correct et que c'est au LOAD que la 1ere ligne est décalé de un octet plaide plus pour un bug dans le basic MO6 lui-même.

[Fool-DupleX]

Ca plaide complètement pour un bug dans le BASIC. Mais le listing original ne devrait pas contenir de lignes sans numéro, en tout cas ça n'est pas dans l'esprit d'un programme BASIC Thomson. Si j'avais vu ça dans un listing papier dans Tilt, j'aurais grogné à l'époque et je n'aurais jamais tapé ces lignes par essence inutiles.

En tout cas, si l'auteur l'a testé sur machine réelle, et j'en doute vus vos soucis, je salue sa patience pour le chargement. Perso, j'aurais à minima du minima encodé les images avec des data, rien que ne mettre que les coordonnées et une valeur qui combine couleur et type op (pset/line), ca réduit déjà beaucoup. Transformer le tout en digits hexa dans des strings encore plus, et le fin du fin je suppose, technique chère à Sam, base 64.

Par exemple, on pourrait avoir un seul octet qui contienne la couleur sur 4 bits, le type op sur 1 bit, et les deux bits de poids fort des coordonnées X. Etant donné que ça a été de toute façon généré automatiquement, ce petit effort de réflexion me semble être du bon sens et pour tout dire, évident.

Vivent les deulignes. Sam, tu veux pas nous réécrire tout ça ?

PS. il y a plusieurs bugs plutôt, non ? Un au niveau de dcmoto dans la simulation clavier et un dans le chargement du BASIC ?

[Daniel]

Il y a plusieurs bugs, c'est certain, mais il est difficile de trouver les coupables. Il ne faut pas mélanger les MO et les TO, le comportement est différent.

Avec le MO6/PC128, c'est très clairement un bug du BASIC 128 dans SAVE et/ou dans LOAD. La simulation du clavier dans dcmoto ne produit pas d'erreur.
Le bug semble se produire dès que la taille du programme dépasse 32 Ko (mais ça n'a pas encore été prouvé).

Avec le TO8/TO9+ le SAVE et le LOAD fonctionnent bien, même pour de gros programmes. Le bug provoque la disparition de trois ou quatre lignes du programme. Je ne sais pas si c'est un bug dans le BASIC 512 ou dans la simulation du clavier de dcmoto. Nous n'avons pas trouvé la cause : ligne précédente en commentaire sans numéro de ligne, ou terminée par un espace inutile, ou POKE interdit sur TO ? Ce n'est pas systématique. Il faudrait taper tout le listing à la main (y compris les lignes inutiles et les espaces inutiles en fin de ligne) pour vérifier. Je n'en ai pas le courage. Qui veut se dévouer ?

[Daniel]

Pour mieux cerner le problème j'ai pu mettre en évidence la disparition de la ligne 19000 en mode TO.
Cette ligne est précédée de nombreuses lignes inutiles.
Certaines sont des commentaires, mais d'autres n'en sont pas, par exemple l'URL commençant par http://retrohead.appodesign.com/?
Comme cette ligne n'est pas correcte, elle provoque une erreur de syntaxe.
Les lignes parasites ont pour effet de perdre le premier chiffre du numéro de la ligne suivante, et 19000 devient 9000. La ligne n'est pas perdue, mais elle a un mauvais numéro.

arkamoid.png (10.92 Kio) Consulté 258 fois

Difficile de dire si c'est (ou pas) un bug de la simulation du clavier dans dcmoto. Ce qui est sûr : en enlevant la ligne http:// le problème disparaît.

arka19000.png (9.33 Kio) Consulté 258 fois

[__sam__]

Le texte en entrée n'est visiblement pas assez "propre" pour une saisie telle-quelle ;(

[Squeepty]

Je suis chaque episode de l'investigation par Daniel et Sam avec engouement, popcorn en main... Merci !

Il ne suffit donc pas d'ouvrir un bug avec Microsoft ?

Peut être le programme original etait plus compact mais Paulo l'aurait plus amplement commente avant de le poster..

En piece jointe, une version du programme ou j'ai enleve toutes les lignes non numerotees.
Cette version charge a partir d'un fichier dans DCMoto !

Je trouve l'intro est impresionante (le logo reveal) pour du basic !!