Longueur de track DOS inattendu

[Anonyme]

Anonyme

#225575

Blup !

J’aimerais comprendre le pourquoi.
Manip avec l’AR MKIII pour info

Remplissage de la mémoire de 80000 a 10000
o « A », $80000 $10000

Chargement des pistes 0 à 17 (18 ‘half track’)
RT 0 17 $80000

Mes données ont remplie ma mémoire jusqu’en $981EF compris.
$981EF – $80000 = $181EF
$181EF / $12 = $1570

Sauf que normalement, une track DOS fait $1600
Ou c’est ti qui sont passé mes $30 bytes ?
Ca fait 8 bytes manquant par ‘half track’
Je n’arrive pas a m’expliquer ça…

PS : Je débute 😉

[Anonyme]

Anonyme

#225610

Hummm, j’ai checké une à une les pistes

En faite mon ‘probleme’ vient uniquement de la derniere track

Sinon, toutes les autres ont bien une longueur de 1600

Mais la derniere, niet

Elle fait : $BF0 au lieu de 1600

soit !3056 bytes au lieu de !5632

Il manque 2576 sur cette derniere track

Je pense que c’est specifique au jeux en question mais

c’est sencé correspondre a quelque chose les 2576 bytes dernier ?

 

 

[dlfrsilver]

dlfrsilver

#225626

Blup !

J’aimerais comprendre le pourquoi.
Manip avec l’AR MKIII pour info

Remplissage de la mémoire de 80000 a 10000
o « A », $80000 $10000

=> il y a un problème dans la commande.

tu dois faire o « A », $10000 $80000

$10000 étant la position de départ en RAM, et $80000 la position de fin.

Chargement des pistes 0 à 17 (18 ‘half track’)
RT 0 17 $80000

=> Idem.

Mes données ont remplie ma mémoire jusqu’en $981EF compris.
$981EF – $80000 = $181EF
$181EF / $12 = $1570

=> euh…. pourquoi divisé par $12 ?

si $181EF c’est ta longueur de donnée, si tu veux connaitre le nombre de pistes sur lesquelles ton bloc de données de $181EF, tu le divise par $2C00 ($1600×2, $1600 étant la longueur d’un cylindre d’une disquette, une piste DOS exemple la piste 1 est composée de 2 faces, 0 et 1, de $1600 de long chacune) ce qui donne 8 pistes 🙂

Mon conseil, télécharge le manuel de l’action replay MKIII 😉
——————————————–
Hummm, j’ai checké une à une les pistes

En faite mon ‘probleme’ vient uniquement de la derniere track

Sinon, toutes les autres ont bien une longueur de 1600

Mais la derniere, niet

Elle fait : $BF0 au lieu de 1600

soit !3056 bytes au lieu de !5632

Il manque 2576 sur cette derniere track

Je pense que c’est specifique au jeux en question mais

c’est sencé correspondre a quelque chose les 2576 bytes dernier ?

C’est normal, l’amiga remplit autant de pistes qu’il y a de données, et si ce qui reste de données ne remplit pas la dernière piste écrites 🙂

[Anonyme]

Anonyme

#225627

Lol, pour erreur de syntaxe tu me renvoie sur le manuel, t’es gentil toi 🙂

il manque juste un zero a la fin, il fallait lire 100000 et non 10000

Pourquoi diviser par 12, parce que le jeux en question n’a que 12 tracks lisibles mais il est vrais que je n’ai pas indiquer le jeux donc on ne peux pas deviner, de plus ma formule de calcul est fausse.

J’ai penseé d’en un premier temps que mes donnees manquante venait de donnee manquante de CHAQUE track, d’ou la formule fausse de calcul.

En faite, comme tu l’as dit plus bas et que j’ai decouvert dans mon dernier poste, ce n’est pas le cas du tout.

Toute mes tracks font bien 1600 SAUF la derniere qui fait un peu moins, tout simplement.

Je me doute que l’amiga remplie la memoire de ce qu’il li -_-‘ et que…

Je fait reformuler autrement, est ce normal d’avoir une track dos d’une taille moins que 1600. Je pensais qu’obligatoirement elle devait avoir 1600 de taille MEME si au final, elle ne contient que $1200 de data par exemple, je m’attendais a avoir par exemple une remplissage de zero jusqu’a la taille attendu de 1600.

Donc tu me dit que c’est normal ca, c’est on vas dire, standard ?

ou c’est plus un ‘bidouille’ qu’on va trouver sur certain jeux ?

 

Merci pour ta reponse.

 

 

[dlfrsilver]

dlfrsilver

#225629

Lol, pour erreur de syntaxe tu me renvoie sur le manuel, t’es gentil toi 🙂

=> TRES 😀 ! Le manuel indique précisément la syntaxe. Quand j’ai commencé avec la cartouche, j’avais le manuel à portée de main, le temps de m’habituer aux commandes.

Et oui, le premier doc qui peut te confirmer si tu as fais une boulette, c’est le manuel 😉

il manque juste un zero a la fin, il fallait lire 100000 et non 10000

=> ah mince, comment on aurait pu deviner lol ?

Pourquoi diviser par 12, parce que le jeux en question n’a que 12 tracks lisibles mais il est vrais que je n’ai pas indiquer le jeux donc on ne peux pas deviner, de plus ma formule de calcul est fausse.

=> Effectivement.

J’ai pensé dans un premier temps que mes données manquantes venaient de données manquantes de CHAQUES track, d’ou la formule fausse de calcul.

=> OK

En faite, comme tu l’as dit plus bas et que j’ai découvert dans mon dernier poste, ce n’est pas le cas du tout.

=> LAWL 🙂

Toute mes tracks font bien 1600 SAUF la derniere qui fait un peu moins, tout simplement.

=> C’est ça 🙂

Je me doute que l’amiga remplie la memoire de ce qu’il li -_-‘ et que…

Je fait reformuler autrement, est ce normal d’avoir une track dos d’une taille moins que 1600. Je pensais qu’obligatoirement elle devait avoir 1600 de taille MEME si au final, elle ne contient que $1200 de data par exemple, je m’attendais a avoir par exemple une remplissage de zero jusqu’a la taille attendu de 1600.

Donc tu me dit que c’est normal ca, c’est on vas dire, standard ?

Oui c’est comme ça sur une piste standard. Mais $1600, c’est un cylindre, et non une piste entière (les disquettes étant double faces). Une piste en tant que telle fait $2C00 de long ($1600+$1600).

ou c’est plus une ‘bidouille’ qu’on va trouver sur certain jeux ?

Merci pour ta reponse.

=> Non non, c’est pas une bidouille.

[Anonyme]

Anonyme

#225635

Bein en regardant mon post en entier 🙂

si plus loin j’arrive a noter une adresse de fin de remplissage en memoire de l’amiga, c’est que la commande de remplissage a fonctionner.

Si elle a fonctionner et que celle que je met ici est fausse c’est que forcement celle que j’ai noté ici contient une erreur de copie (le copie coller winuae windows ca marche pas encore).

Mais bon, on sans fiche, pas le sujet.

 

ok, 1600 x 2, ca explique le terme Half track dans le manuel de la mkIII

Tiens, question du coup.

Si je formate une disquette amiga au format standard

Que je n’ecrie aucune donnee dessus et que je dump une track

Donc, Aucune DATA, je doit m’attendre sous l’AR qu’il ne me copie rien en mémoire finalement ou peu être un minimum comme le header.

Non ? pourtant c’est pas le cas.

Format TEST
o « AA », $70000 $80000
rt 0 1 $70000
m $715D0
La zone remplie et donc lue est de 70000 => $715FF
Alors qu’elle ne contient pas de ‘DATA’ mais fait bien $1600
Comment expliquer cela ?

[Anonyme]

Anonyme

#225676

Tiens un autre test, tjs dans l’idée de mieux comprendre la structure des données sur une disquette, format amigados.
(il existe pas un doc d’ailleurs à ce sujet ? un bouquin ?)

(Sur une disquette formaté standard amigados)
sm TEST, $70000 $70400
o « AA », $70000 $100000
f « TEST », $70000 $100000
0DC5B1

$0DC5B1-$7000 = $6C5b1
$6C5b1 / $1600 = $4E = !78
Piste 40?!, Tiens… on commence par écrire les données au milieu de la disquette !?

rt !80 1 $7000
Reading Track !40 Head 0
==>Donnée préalablement sauvegardé (fichier TEST) de $70000 jusqu’en $75ff (donc 1600 again).

Malgré une taille de sauvegarde de $400, (je n’ai donc pas remplie les 1600), il me lie les 1600 (ca, pour moi c’est normal).

Donc d’un coté, sur une disquette ‘normal’ AmigaDos
Quand que je lie un cylindre, ‘j’extraie’ $1600 de donnée
Et quand je lie ma dernière piste QUI EST AUSSI au format amigados
La, même avec AUSSI une taille de Data en dessous de $1600, il ne me lie QUE ce qu’elle contient.

J’aurais tendance a penser que la routine d’écriture des données utilisé pour sauvegardé les données du jeux en question n’est pas la même que celle ‘standard’.

D’où la question précédent, si c’est ‘normal’ ou si il y a, je ne sais pas, plusieurs méthode ‘normal’ d’enregistrement de données.

Parce que la du coup, c’est pas le même résultat.

Si tu as une explication sur ça, je suis hyper preneur !

Thks