[DCMOTO/MESS] Freeze HNY2013
Modérateurs : Papy.G, fneck, Carl
-
- Messages : 7964
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [DCMOTO/MESS] Freeze HNY2013
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.
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.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: [DCMOTO/MESS] Freeze HNY2013
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...
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...
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
-
- Messages : 7964
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [DCMOTO/MESS] Freeze HNY2013
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:
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)
Code : Tout sélectionner
DKFIN equ $60F3 ;dernier bloc
DKBLK equ $60F6 ;1er bloc fichier
DKTDS equ $60F7 ;nb octets dern sect (2octets)
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: [DCMOTO/MESS] Freeze HNY2013
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...
- 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...
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
Re: [DCMOTO/MESS] Freeze HNY2013
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
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
Re: [DCMOTO/MESS] Freeze HNY2013
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...
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...
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
-
- Messages : 7964
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [DCMOTO/MESS] Freeze HNY2013
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)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'obtiensMais la même zone avec le contrôleur SD indique
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
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 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{|}.
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 ................
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
Dernière modification par __sam__ le 09 févr. 2021 19:26, modifié 1 fois.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: [DCMOTO/MESS] Freeze HNY2013
Chargement de la FAT avec SDDRIVE :
Chargement de la FAT avec le TO8D :
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é ?
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
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é ?
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
-
- Messages : 7964
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [DCMOTO/MESS] Freeze HNY2013
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.
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.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: [DCMOTO/MESS] Freeze HNY2013
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.
Ç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.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
-
- Messages : 7964
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [DCMOTO/MESS] Freeze HNY2013
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é.
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é.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: [DCMOTO/MESS] Freeze HNY2013
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.
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.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
-
- Messages : 7964
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [DCMOTO/MESS] Freeze HNY2013
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 ?Daniel a écrit : ↑09 févr. 2021 18:08 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.
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
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).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.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: [DCMOTO/MESS] Freeze HNY2013
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 :
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.
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
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.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
-
- Messages : 7964
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [DCMOTO/MESS] Freeze HNY2013
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
On doit pouvoir le faire en 7ajouter 128 octets au pointeur DK_FAT, c'est 8 octets de plus.
Code : Tout sélectionner
CC 0080 LDD #$80
D3 ED ADDD <$ED
DD ED STD <$ED
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos