Pourquoi le 1541 était-il si lent?

Dec 13 2020

Le lecteur de disquettes Commodore 1541, vendu pour être utilisé avec le 64, était notoirement lent pour des raisons historiques et techniques :

  1. Le marketing insistait sur la compatibilité avec le 1540, le lecteur de disquette vendu avec le Vic-20, qui était lent car le registre à décalage de la puce 6522 VIA ne fonctionnait pas, il fallait donc transférer un peu à la fois au lieu d'un octet à un temps.

  2. Ensuite, cela a dû aller encore plus lentement car contrairement au Vic-20, la puce vidéo du 64 doit complètement prendre le contrôle du bus une ligne de balayage active sur huit.

D'accord, donc étant donné la pire combinaison de ces deux facteurs, sans temps de développement autorisé pour atténuer le problème, on pouvait voir comment le lecteur pourrait ne pouvoir transférer qu'un bit par blanc horizontal = 63 microsecondes. 1 / (63e-6) = 15873 bits / s = 1984 octets / s.

Mais apparemment, la vitesse réelle n'était que de 400 octets / s .

Pourquoi la vitesse réelle n'était-elle qu'un cinquième de ce qui semble possible même avec la malheureuse combinaison de problèmes historiques et techniques?

Réponses

14 Raffzahn Dec 13 2020 at 21:29

le lecteur pourrait finir par ne pouvoir transférer qu'un bit par blanc horizontal = 63 microsecondes. 1 / (63e-6) = 15873 bits / s = 1984 octets / s.

Ce serait le débit binaire pendant la transmission dans un octet, mais les octets sont encadrés et échangés, ce qui ajoute en moyenne 160 µs par octet. Résultat (63 * 8) + 160 µs, ou ~ 664 µs par octet. Ainsi, la vitesse de transfert supérieure est plutôt égale ou inférieure à 1500 octets / s

Les nombres ci-dessus sont le minimum absolu, le temps entre les octets peut être aussi long que 1000 µs et toujours dans les spécifications. Les délais d'exécution supplémentaires sont devant les commandes et entre les blocs / commandes. Ensuite, le 1541 a besoin de temps pour réagir et répondre. Et enfin, le côté C64 a également besoin de gestion après le transfert de bits pur. Tout cela s'additionne.

Mais apparemment, la vitesse réelle n'était que de 400 octets / s.

Avant tout, il est important de garder à l'esprit que ces 400 octets / s concernent la lecture à partir d'un lecteur FD réel. Avec un vrai mouvement de tête, recherchez la latence, les transferts et faites demi-tour. Le test souvent utilisé consiste à lire un programme de 185 blocs, ce qui signifie au moins 10 changements de piste et ainsi de suite.

Une bonne référence pour les taux de transfert du monde réel en utilisant un C64 non modifié (chargeur nospeed, toutes les routines d'origine utilisées) sans entraînement mécanique pourrait être l' interface SD2IEC . Il offre un débit moyen de 650 octets / s . Le SD2IEC est essentiellement un Atmel ATMega fonctionnant à 8 MHz traitant directement l'IEC série. Sa réponse et son temps de transfert sont proches du maximum possible. La lecture à partir de SD / MMC ne comporte aucun mouvement mécanique, aucune latence de recherche et un transfert de données à grande vitesse de SD / MMC vers la RAM du contrôleur.