[DCMOTO/MESS] Freeze HNY2013

[__sam__]

Oui il y a beaucoup d'accès car la diskette est remplie à ras-bord d'images compressées par EXOmizer.

En fait il n'y a que la face 0 qui est utilisée et on est dessus quand l'erreur arrive. On est pas en fin de diskette: il reste des images à décompresser.

Pour le débordement de pile on est autour de $9600, c'est à dire très loin de la pile système et des zones utilisées par sddrive.

Le plus surprenant est, oui, que finalement le même code marche impec pour les images précédentes. L'image 26 a exactement une taille de 12 386, c'est à dire 48*255 + 146 (pour le dos les secteurs font 255 octets pas 256) , ce qui ne semble pas poser de subtilité d'arrondi.

[Daniel]

En cherchant à localiser l'erreur, je vois qu'elle se produit dans le traitement du secteur 14 de la piste 0.
Si je ne me trompe pas le fichier commence en piste 63 (secteurs 1-16) et se poursuit piste 0 secteur 2.
Les 28 premiers secteurs du fichier sont traités correctement et l'erreur se produit dans le traitement du 29eme.
C'est juste pour faire avancer le schmilblic...

[__sam__]

Il "semblerait" (je mets au conditionnel car je ne l'ai pas observé, mais juste déduit) que l'erreur vienne du fait qu'on fasse une lecture après la fin de fichier. La détection de fin de fichier utilise et modifie des infos dans la page 0 du moniteur:

Code : Tout sélectionner

DKFIN  equ    $60F3   ;dernier bloc
DKBLK  equ    $60F6   ;1er bloc fichier
DKTDS  equ    $60F7   ;nb octets dern sect (2octets)

Est-ce que par (mal)chance, l'un de ces octets pourrait être mal calculé ? (A noter: 2 octets pour TDS alors que la valeurs est forcément <= 255)

[Daniel]

En observant la lecture du fichier, on voit la différence entre la version .fd et la version .sd :
- FD: Lecture piste 63 secteurs 1 à 16, puis piste 64 secteurs 1 à 16, puis piste 65 secteurs 1 à 16, etc.
- SD: Lecture piste 63 secteurs 1 à 16, puis piste 0 secteurs 2 à 14 et plantage lors du traitement du secteur 14.

En version SD il y a une remise à zéro malencontreuse du numéro de piste après la lecture du secteur 16 de la piste 63.
Reste à trouver pourquoi...

[jasz]

Etrange que ce soit juste après la piste 63

Dans la logique on pourrait déduire
LDA #63
INCA
ANDA #63

A se retrouve donc à zero et non à 64. Après cela n'explique pas pourquoi il continue par le secteur deux de la nouvelle piste et bloque sur le 14

[Daniel]

Je privilégie maintenant la piste d'une erreur dans le contrôleur SDDRIVE.

C'est une adaptation du contrôleur CD90-640, dans laquelle j'ai forcé la double densité et le nombre de pistes à 80. Il y a peut-être un détail qui m'a échappé. L'erreur étant bien cernée elle devrait être découverte bientôt. La FAT est peut-être tronquée, ou le nombre de pistes limité à 6 bits, ou un autre problème du même genre. On approche du dénouement...

[__sam__]

L'organisation des secteurs vient de la FAT. A ce sujet l'accès au bloc suivant par le code se fait ainsi (reprenant le code de préhisto)

Code : Tout sélectionner

       ldx    <DKFAT  ; ptr FAT
       ldb    <DKBLK  ; bloc courant
       incb           ;   bloc
       ldb    b,x     ;   suivant <=== HUM
       stb    <DKBLK  ; sauve bloc
       cmpb   #$C0    ; si dernier bloc,
 

Ce "b,x" ne m'inspire pas confiance dans la mesure ou b doit être signé et que x pointe sur le début de la fat, donc pour les blocs entre $80 et $BF (ils ne vont pas au delà), on tape "avant" la FAT, là où il n'y a rien.

Ce qui est surprenant est que ce code marche bien avec le contrôleur standard. Il y a un truc qui n'est pas logique là. Si effectivement on tape "avant" la fat et que ca marche, c'est que la FAT se retrouve "dupliquée" un peu avant. Je ne vois pas pourquoi on aurait ca, mais ca mérite une inspection...

sam (allez, on y repart...)

[EDIT] ok j'ai pigé pour cette histoire de "b,x". Ce qu'il se passe est intéressant. On mets un pointeur sur notre zone mémoire dans le registre DKFAT du moniteur. Lors des appels à LECFA (lecture FAT), ce pointeur est avancé de 128 places et la FAT en mémoire est organisée pour que les accès en signé type "b,x" marchent de façon transparente. Premier mystère résolu..

Et peut-être une piste pour Daniel avec cette réorganisation. En effet si je regarde la zone iofat avec le contrôleur FD, j'obtiens

Code : Tout sélectionner

9C90 80 81 82 c4 84 85 86 87 c6 89 8a 8b 8c c4 8e 8f  ................
9CA0 90 c8 92 93 94 95 c4 97 98 99 9a c6 9c 9d 9e c8  ................
9CB0 ff fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe  ................
9CC0 fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe  ................
9CD0 fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe  ................
9CE0 fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe  ................
9CF0 fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe  ................
9D00 fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe  ................
9D10 00 fe ff c5 c5 03 04 05 c3 07 08 09 0a c1 0c 0d  ................ <== DKFAT pointe ici
9D20 0e c8 10 11 12 c5 14 15 c2 17 18 19 1a c2 1c 1d  ................
9D30 1e 1f 20 c5 22 23 24 25 c8 fe fe 27 2a c7 2c 2d  .. ."#$%...'*.,-
9D40 c3 2f 30 c6 32 c3 34 35 36 37 c4 39 3a 3b 3c c8  ./0.2.4567.9:;<.
9D50 3e 3f 40 41 c4 43 44 c3 46 47 48 49 c1 c4 4c c1  >?@A.CD.FGHI..L.
9D60 c5 c3 52 c5 54 55 c6 57 58 59 5a c4 c1 5d 5e 5f  ..R.TU.WXYZ..]^_
9D70 60 c8 62 63 64 65 c6 67 68 69 6a c2 6c 6d 6e c2  `.bcde.ghij.lmn.
9D80 70 71 c4 73 74 75 c2 77 c8 79 7a 7b 7c 7d c2 7f  pq.stu.w.yz{|}.

Mais la même zone avec le contrôleur SD indique

Code : Tout sélectionner

9C90 00 fe ff c5 c5 03 04 05 c3 07 08 09 0a c1 0c 0d  ................ <== DKFAT pointe ici
9CA0 0e c8 10 11 12 c5 14 15 c2 17 18 19 1a c2 1c 1d  ................
9CB0 1e 1f 20 c5 22 23 24 25 c8 fe fe 27 2a c7 2c 2d  .. ."#$%...'*.,-
9CC0 c3 2f 30 c6 32 c3 34 35 36 37 c4 39 3a 3b 3c c8  ./0.2.4567.9:;<.
9CD0 3e 3f 40 41 c4 43 44 c3 46 47 48 49 c1 c4 4c c1  >?@A.CD.FGHI..L.
9CE0 c5 c3 52 c5 54 55 c6 57 58 59 5a c4 c1 5d 5e 5f  ..R.TU.WXYZ..]^_
9CF0 60 c8 62 63 64 65 c6 67 68 69 6a c2 6c 6d 6e c2  `.bcde.ghij.lmn.
9D00 70 71 c4 73 74 75 c2 77 c8 79 7a 7b 7c 7d c2 7f  pq.stu.w.yz{|}.
9D10 80 81 82 c4 84 85 86 87 c6 89 8a 8b 8c c4 8e 8f  ................
9D20 90 c8 92 93 94 95 c4 97 98 99 9a c6 9c 9d 9e c8  ................
9D30 ff fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe  ................
9D40 fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe  ................
9D50 fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe  ................
9D60 fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe  ................
9D70 fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe  ................
9D80 fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe  ................

Les données ne sont pas réorganisées par le contrôleur SDDrive contrairement au contrôleur FD! Du coup ca marche bien tant qu'on utilise des blocs <= 127, mais au delà ben ca part en vrille.

En base densité on a effectivement pas besoin de réorganiser la FAT car les blocs sont <= 127 (et la FAT ne fait que 128 entrées). Je pense que le bug est là: la routine LECFA du controleur SDDrive ne réorganise pas DKFAT ni la FAT de sorte à marcher avec le "b,x" qui m'intriguait.

Ce bug, s'il est avéré, peut impacter pas mal de jeux/démos utilisant LECFA pour le chargement de données avec des diskette ayant des blocs >= 128 (bien pleines). Je pense que les routines DOS de l'extramon, n'utilisent pas LECFA du mini-dos, donc le problème n'apparait pas en basic (à vérifier.) Les jeux/démos utilisant un trackloader n'utilisent pas non plus LECFA et n'auront pas le problème.

[EDIT2] l'inversion de la FAT avait été décrite par Préhisto par le passé: http://collection.thomson.free.fr/code/ ... ?XI=0&XJ=3

[Daniel]

Chargement de la FAT avec SDDRIVE :

Code : Tout sélectionner

;------------------------------------------------------
; LECFA = Chargement de la FAT
;------------------------------------------------------
LECFA
  LDX   <DKWED         ; adresse de la FAT
  STX   <DK_BUF        ; adresse du buffer secteur
  LDA   #$02           ; numero secteur a lire
  BRA   LSEC20         ; lecture secteur piste 20

Chargement de la FAT avec le TO8D :

Code : Tout sélectionner

------------------------------
LECFA = Chargement de la fat
------------------------------
E52D  DCED      LDD    <$ED
E52F  0D25      TST    <$25
E531  2602      BNE    $E535
E533  DD25      STD    <$25
E535  9325      SUBD   <$25
E537  C180      CMPB   #$80
E539  2703      BEQ    $E53E
E53B  9EED      LDX    <$ED
E53D  7D9E25    TST    $9E25
E540  9FED      STX    <$ED
E542  9F4F      STX    <$4F
E544  8602      LDA    #$02
E546  8D31      BSR    $E579
E548  25CA      BLO    $E514
E54A  0D58      TST    <$58
E54C  2608      BNE    $E556
E54E  8DC5      BSR    $E515
E550  30890080  LEAX   $0080,X
E554  9FED      STX    <$ED
E556  39        RTS    

cqfd.

Remarque : L'astuce du TO8D est un peu tordue, il me semble. Quelle en est la vraie raison, à part l'utilisation du registre B signé ?

[__sam__]

Oui c'est tordu, mais ca rend le code de lecture de fichier "simple densité" et haute densité quasi-similaires. En outre c'est plus rapide que ABX, donc peut-être que le mini-dos tire le max des performances.

En tout cas, maintenant on sait ce qu'il se passe. En principe l'échange de la partie haute/basse ne devrait pas couter beaucoup d'octets. J'espère qu'il reste assez de place en ROM si tu décidais de la corriger.

[Daniel]

J'ai beau chercher, je ne vois pas d'autre solution que faire le même traitement dans le contrôleur SDDRIVE. Ça devrait concerner la lecture et l'écriture de la FAT, mais probablement aussi d'autres traitements, par exemple l'ouverture d'un fichier.

Ça ne me plaît pas beaucoup. Pourquoi faire compliqué quand on peut faire simple ? Je ne crois pas que le gain de quelques cycles dans le LDB B,X justifie cette complexité. Surtout que quelques cycles, par rapport au temps de lecture d'un bloc de la disquette, c'est complètement négligeable. Mais maintenant que le mal est fait, il ne me reste plus qu'à faire pareil.

[__sam__]

Quand on utilise "LDB B,X", il est facile d'utiliser "ABX + LDB ,X".. mais dans le code de Préhisto sur la partie écriture, l'indexation se fait via "STB A,Y" qui lui n'a pas d'équivalent non-signé simple. C'est peut-être pour cela que les concepteurs de la rom FD ont gardés l'indexation signée: c'est le plus naturel quand on utilise le mode indexé. A noter que cette "inversion" de la FAT en RAM ne complexifie pas forcément les fonctions de support comme la recherche d'un bloc libre ($E01C) si cette dernière utilise elle aussi l'indexation par un accu. C'est une question d'homogénéité dans les API du mini-dos.

Je comprends que ca t'ennuie de modifier la rom pour la rendre plus fidèle au contrôleur FD. On peut modifier la démo pour la version SD (c'est le plus simple), mais je me demande: combien d'autres programmes souffrent de cette incompatibilité de la représentation de la FAT en mémoire ? A ma connaissance il n'y a que la cartouche colorpaint qui utilise le mini-dos. Les autres outils utilisant les diskette me semblent utiliser l'extramon qui ne passe pas par le minidos. Ce minidos est quand même un point d'entré hyper secret quand on y songe: il ne figure pas réellement dans les bouquins (du moinhs ceux que j'ai lu). Seule la partie lecture de secteur est supposée être utilisée dans le grand public au final. C'est le seul point d'entrée qui soit officiellement documenté.

[Daniel]

Plus j'analyse l'impact de cette modification du contrôleur SDDRIVE et plus ça m'embête de la faire. Il ne suffit pas d'inverser la FAT après l'avoir chargée, il faut aussi la remettre dans le bon ordre avant de l'écrire, et de nombreuses routines sont impactées. Et pire, je n'ai pas assez de place dans l'EPROM : 38 octets disponibles, c'est insuffisant même en optimisant le code.

Dans tous les jeux commerciaux convertis au format .sd je n'ai jamais eu le problème. Ils n'utilisent pas le scratch.dos. Même les démos de Prehisto et le jeu Mission: Liftoff ne l'utilisent pas. Pour le programmeur il est plus simple et plus rapide de lire des secteurs physiques sans se préoccuper de la structure de fichiers. Et avec la première génération de machines l'astuce n'était pas utilisée, puisque le contrôleur CD90-640 n'inverse pas la FAT, même en double densité. Il est vrai que les disquettes n'avaient que 40 pistes et ce n'était pas nécessaire. Avec une disquette de 80 pistes il semble que l'on puisse aller jusqu'à la piste 63 sans provoquer d'erreur.

Il y a seulement quelques démos concernées. Il doit être possible de réécrire les routines d'accès à la FAT pour éviter l'inversion, et de modifier ces quelques démos spécifiquement pour la version SD. Sinon il faudra les sacrifier, la taille de l'EPROM de SDDRIVE est un obstacle insurmontable.

Pour Elvis Live j'ai une idée : mettre la moitié des images sur la deuxième face de la disquette pour ne pas utiliser les pistes au-delà de 63. On pourrait ainsi ne pas toucher aux routines du scratch.dos.

[__sam__]

Plus j'analyse l'impact de cette modification du contrôleur SDDRIVE et plus ça m'embête de la faire. Il ne suffit pas d'inverser la FAT après l'avoir chargée, il faut aussi la remettre dans le bon ordre avant de l'écrire, et de nombreuses routines sont impactées. Et pire, je n'ai pas assez de place dans l'EPROM : 38 octets disponibles, c'est insuffisant même en optimisant le code.

J'ai pas vu de routine d'écriture de FAT dans le minidos, mais ma source est le code de Préhisto. Il y a une documentation quelque part ?

A priori l'inversion haute/basse peut se faire ainsi (l'inversion est la même pour le chargement et la sauvegarde):

Code : Tout sélectionner

SWAPFAT
  LDX <DKFAT
  LDY #128
loop set *
  LDA ,X+
  LDB $7F,X
  STB -1,X
  STA $7F,X
  LEAY -1,Y
  BNE loop
  RTS

à la louche 20 octets, ce qui doit laisser 16-19 octets pour le reste (dont 2 appels au chargement et la sauvegarde). Ensuite, je dirais que dans les codes de recherches, ca ne doit pas changer grand chose, non ? (les "b,x" et "a,x" restent identique dans la mesure où DKFAT pointe 128 octets plus loin).

Pour Elvis Live j'ai une idée : mettre la moitié des images sur la deuxième face de la disquette pour ne pas utiliser les pistes au-delà de 63. On pourrait ainsi ne pas toucher aux routines du scratch.dos.

Ca devrait marcher, et comme c'est un filesystem "dos", un COPY en basic devrait permettre de déplacer les fichiers dans l'ordre de la face 0 à la face 1. Reste à voir si on ne va pas tomber sur un autre soucis lors du changement de face (ces vieux programmes conçus pour floppy sont hyper casse-gueule en fait).

[Daniel]

Je n'ai pas le souvenir d'une quelconque documentation, mais il faudrait vérifier dans la revue TEO s'il n'y a pas quelque chose sur le sujet.

Pour inverser la FAT dans le contrôleur SDDRIVE j'ai pris la routine du TO8D. Elle fait 24 octets :

Code : Tout sélectionner

;------------------------------------------------------
; INVFA = Inversion des deux moities de la FAT
;------------------------------------------------------
INVFA
  PSHS  B,A,CC
  LDX   <$ED           ; adresse de la FAT
  LEAX  $0080,X        ; ajout de $80
INVFA1
  LDA   $01,X          ; octet premiere moitie 
  LDB   $7F,X          ; octet deuxieme moitie
  STA   $7F,X          ; 1ere moitie dans 2eme
  STB   ,-X            ; 2eme moitie dans 1ere
  CMPX  <$ED           ; test de fin
  BNE   INVFA1         ; octet suivant
  PULS  CC,A,B,PC      ; retour

Il faut l'appeler après le chargement en RAM et ajouter 128 octets au pointeur DK_FAT, c'est 8 octets de plus.
Ensuite il faut remettre la FAT dans le bon ordre et remettre le pointeur DK_FAT à sa valeur initiale avant chaque écriture après modification. Ça se passe dans la routine FINTR (Clôture d'écriture). Il faut au moins 8 octets de plus. Au total 24 +8 + 8 = 40, et il n'y en a que 38. C'est peut-être jouable, je vais essayer d'optimiser.

[__sam__]

C'est quand même vachement tendu. On serait plus à l'aise avec plus de place restante en rom. Peut-être que si tu trouve une routine trop grosse, on pourrait compter sur les amateurs de mc6809 du forum pour éventuellement trouver des codages équivalents mais plus courts. Par exemple là je peux faire l'inversion en 21 octets seulement

Code : Tout sélectionner

0000 34   76         PSHS  D,X,Y,U
0002 109E ED         LDY   <$ED
0005 CC   7E40       LDD   #$7E40
0008               LOOP
0008 AE   A1         LDX   ,Y++
000A EE   A6         LDU   A,Y
000C AF   A6         STX   A,Y
000E EF   3E         STU   -2,Y
0010 5A              DECB
0011 26   F5         BNE  LOOP
0013 35   F6         PULS D,X,Y,U,PC
0015

ajouter 128 octets au pointeur DK_FAT, c'est 8 octets de plus.

On doit pouvoir le faire en 7

Code : Tout sélectionner

CC   0080       LDD  #$80
D3   ED         ADDD <$ED
DD   ED         STD  <$ED