[DCMOTO] Sudoku

[Daniel]

@kirion: Pour chaque périphérique (SDMO, SDMOTO, CS91-280, SDDISK, SDSTREAM, SDANIM7, SDDRIVE etc.) il y a une documentation dans le site dcmoto. Elle explique précisément le fonctionnement de chacun, son utilisation, ses avantages et ses inconvénients.
Je conseille de lire cette documentation (RTFM) pour ne pas tout confondre.

[__sam__]

Et s'il faut d'abord mettre un fichier .fd pour charger le fichier Basic avant de pouvoir lancer la lecture séquentielle, on a autant trouver le même programme sur un fichier .fd

Pas vraiment car le volume gérable en FD et en SD ne sont pas les mêmes. On mets en SD, en particulier sous SDStream, des choses nettement plus grosses qu'un fichier FD n'est capable de gérer: exemple (charger le BOOT.FD, le fichier SD aux bons endroits, cocher SDStream, et booter via B sur TO8D)

[Daniel]

Mais il faudrait trouver quelque chose pour que l'utilisateur ait la possibilité de lancer un fichier .sd aussi facilement qu'un fichier .fd
je sélectionne le fichier .fd, j'appuye sur B, le programme se lance.

Je sélectionne un fichier .sd, j'appuie sur B, l'écran SDDRIVE s'affiche, j'appuie sur ENTREE, le programme se lance.
Bon, c'est vrai, il y a un appui sur ENTREE en plus. Mais sinon on ne saurait pas si on a lancé le fichier .fd ou le fichier .sd.

[Daniel]

@kirion : Tu dis qu'il vaut mieux une disquette (fichier .fd) que SDSTREAM. Je ne peux pas laisser passer ça. Tu n'as pas compris que SDTREAM, c'est du streaming à 250 kilo octets par seconde. Avec SDSTREAM __sam__ a fait des vidéos plein écran de films en couleur de plus d'une heure.
Si tu crois pouvoir faire ça avec une disquette, abandonne l'idée, c'est impossible.

[__sam__]

Quelle différence entre SDSTREAM et SDMOTO ?

Le débit!

Avec SDtream on lit des octets à la vitesse native du 6809. Avec SDMoto on lit péniblement des bits.

Mais les deux ne sont que des interfaces pour connecter une carte SD à un Thomson. Tout nu, on y accède avec du langage machine (d'où le petit lanceur basic). Mais si on y ajoute un contrôleur disk (une rom pour le "bios" on va dire pour simplifier), on peut utiliser une interface de façon transparente comme un disque, sans "loader" en langage machine à saisir en basic.

Pour l'interface SDMoto, le contrôleur est le CS91-280. Pour le SDStream: il n'y en a pas car il ne sert moralement qu'à streamer (lire) à très haute vitesse (même si on pourrait imaginer un contrôleur, mais comme personne n'est motivé par cette interface, bref passons).

SDMoto est une vielle interface qui a besoin d'être configurée différemment pour les TO et les MO. Elle bloque aussi un port joystick et nécessite en plus un contrôleur externe pour être simplement utilisable comme diskette virtuelle. Tout ceci n'est ni très simple ni très compact.

Cette interface est avantageusement remplacée par SDDrive qui n'a pas toutes ses complications (marche indifféremment sur TO ou MO, le contrôleur est intégré; elle ne bloque pas de port joystick et ; tout ceci est hyper compact). En outre elle est plus rapide (voir l'explication de Daniel plus bas au sujet de l'horloge).

Avec SDSTREAM __sam__ a fait des vidéos plein écran de films en couleur de plus d'une heure.
Si tu crois pouvoir faire ça avec une disquette, abandonne l'idée, c'est impossible.

Tout à fait. Voir l'exemple donné un peu plus haut.

[Daniel]

La principale différence entre la première génération de contrôleurs de cartes SD (CS91-280 et SDDISK) et la dernière (SDDRIVE) est la génération du signal d'horloge de la liaison SPI.

Avec CS91-280 et SDDISK le signal est généré par soft. Il faut une écriture mémoire pour un front positif et une écriture mémoire pour le front négatif suivant.

Avec SDDRIVE le signal d'horloge est généré par le matériel. Pour chaque bit lu ou écrit on économise deux écritures mémoires, soit 8 cycles du processeur 6809. Cette méthode permet d'aller environ 3 fois plus vite qu'avec la méthode "soft".

Avec SDSTREAM on ne lit plus des bits, mais des octets. Le passage d'une liaison série (SPI) à une liaison parallèle sur 8 bits permet d'aller environ huit fois plus vite que SDDRIVE et 24 fois plus vite que SDDISK.

[kirion]

Oui merci Daniel et Sam, c'est plus clair à présent.

et SDSTREAM ne pouvait pas être créé avec un contrôleur comme SDDRIVE pour ne pas avoir besoin d'utiliser un bootloader ?

[kirion]

Je sélectionne un fichier .sd, j'appuie sur B, l'écran SDDRIVE s'affiche, j'appuie sur ENTREE, le programme se lance.
Bon, c'est vrai, il y a un appui sur ENTREE en plus. Mais sinon on ne saurait pas si on a lancé le fichier .fd ou le fichier .sd.

oui en regardant de plus près j'ai trouvé qu'on peut avoir le lecteur de disquette et le sd en même temps et qu'il suffit de taper

POKE &HE7E7, &HD4
POKE &H6081, &HD4
EXEC &HE025

[kirion]

Pas vraiment car le volume gérable en FD et en SD ne sont pas les mêmes. On mets en SD, en particulier sous SDStream, des choses nettement plus grosses qu'un fichier FD n'est capable de gérer: exemple (charger le BOOT.FD, le fichier SD aux bons endroits, cocher SDStream, et booter via B sur TO8D)

J'ai regardé la vidéo RTYPE, effectivement c'est impressionnant. Et une interface deux en un n'était pas possible? que ca fasse SDDRIVE ou SDSTREAM au choix de l'utilisateur par programme?

Grâce à Rtype je vois bien l'avantage de SDSTREAM mais une autre question me vient à l'esprit :
je ne voyais pas l'avantage de basculer le jeu SUDOKU (ou d'autres) au format .sd vu qu'il fonctionne très bien en .fd alors ma question est la suivante :
pourquoi n'était il pas possible de copier les fichiers .fd sur la carte SD sur un système de fichier FAT32 et de simplement sélectionner le fichier .fd avec un petit écran LCD sur l'interface ou par programme sur un menu de lancement de la carte SD.

Comme un fichier .fd peut contenir les faces de 4 disquettes, on aurait pu garder le format .fd et simplement le copier sur la carte SD et l'interface se chargeait de sélectionner le fichier choisi.

A ce que j'ai lu sur le site (comme conseillé par Daniel), l'eeprom ne contient que 2ko de programme mais peut en contenir 64. Avec 64ko le controleur doit pouvoir gérer de la FAT32 sans problème, non ?

[__sam__]

Comme un fichier .fd peut contenir les faces de 4 disquettes, on aurait pu garder le format .fd et simplement le copier sur la carte SD et l'interface se chargeait de sélectionner le fichier choisi.

Je l'ai indiqué plus haut. La taille des secteurs n'est pas la même: 256 octets pour les Thomson et 512 octets pour les cartes SD. Or comme il est impossible de modifier moins d'un secteur sur SD, le plus simple est donc de mapper un secteur thomson sur un secteur SD en utilisant que les 256 premiers octets et combler le reste avec des 0 (edit $FF). C'est pour cela que le format SD est différent du format FD. C'est franchement pas un problème.

Par ailleurs la ROM du contrôleur doit tenir dans l'espace mémoire réservé aux contrôleurs externes de floppy. Cet espace ne contient pas 64ko, il est même tout petit (car il contient le minimum dont a besoin le thomson pour utiliser un support de stockage). En outre cela ne changerait rien. En effet la selection du fichier de floppy virtuelle n'est pas faite par le contrôleur, mais par le fichier binaire externe *.SEL lancé au démarrage du contrôleur pour lui indiquer le jeu de diskettes virtuelles à utiliser. Ce fichier de selection sait lire les FAT32 me semble-t-il (en tout cas j'ai des noms longs) et s'il y a des mises à jour, changer un fichier de la carte SD bien plus simple que de reflasher la ROM du contrôleur.

Enfin, mettre SDDrive et SDStream sur une seule carte n'a pas d'intérêt particulier par rapport à les brancher l'un derrière l'autre sur un minibus. C'est ce que j'ai personnellement.

Pour plus de détails: je te recommande de lire les fils sur les cartes SD de ce site. Ils sont nombreux. J'avais essayé de résumer leur évolution par là.

[Daniel]

Beaucoup d'utilisateurs ne comprennent pas pourquoi les fichiers .sd ont des secteurs de 512 octets. Je vais l'expliquer.

Tout d'abord il faut savoir qu'on peut uniquement lire et écrire des secteurs complets d'une carte SD, soit 512 octets.

En lecture, il n'y aurait aucun problème en mettant deux secteurs Thomson de 256 octets dans un secteur de la carte SD de 512 octets.
On pourrait, en lisant le secteur de 512 octets, retenir les 256 premiers et ignorer les 256 derniers, ou ignorer les 256 premiers et retenir les 256 derniers.

En écriture c'est différent. Si on modifie soit la première partie, soit la deuxième partie du secteur de 512 octets, il faut ensuite écrire le secteur complet. Et donc il faut avoir en RAM de l'ordinateur Thomson un buffer de 512 octets. Il n'y a pas de place libre dans la carte mémoire des ordinateurs Thomson. Rien que pour trouver les 8 octets nécessaires au fonctionnement de SDDRIVE j'ai beaucoup galéré. Trouver un buffer de 512 octets est impossible. Il faut se contenter du buffer de 256 octets prévu par le système et par les programmes existants. Et donc, pour écrire le secteur de 512 octets, on utilise ce buffer de 256 octets et on complète par 256 octets à $FF. N'importe quelle valeur pourrait convenir, ces 256 octets ne sont jamais utilisés.

Il y aurait bien une solution : ajouter un peu de RAM au contrôleur SDDRIVE. J'ai évidemment étudié cette solution, et je l'ai vite abandonnée. La complexité de l'électronique aurait rendu le contrôleur beaucoup plus gros et beaucoup plus cher, et n'aurait pas apporté grand chose.

Autre solution : Utiliser un buffer de 512 octets, non pas en RAM mais sur la carte SD elle-même, dans une zone non utilisée par le système de fichiers. Mais c'est une mauvaise idée : la lecture et l'écriture dans ce buffer vont multiplier par trois le temps d'écriture d'un secteur. On rend ainsi SDDRIVE presque aussi lent qu'un lecteur de disquette.

Il faut réaliser que toute la logithèque Thomson tient sur une carte SD de 128 Mo. Si on n'utilise que la moitié des secteurs, il faudra une carte de 256 Mo. Aujourd'hui les plus petites cartes fabriquées ont une taille de 16 Go. Il y en a encore d'occasion à 4 Go ou 8 Go, mais c'est de plus en plus difficile à trouver. On peut y mettre 16 fois ou 32 fois toute la logithèque Thomson, même en perdant la moitié de la capacité. Chercher à gagner quelques octets au prix d'un système compliqué n'a pas de sens. Autant faire simple. Small is beautiful.

[Daniel]

Ce fichier de selection sait lire les FAT32 me semble-t-il (en tout cas j'ai des noms longs)

Oui, SDDRIVE reconnaît les systèmes de fichiers FAT16 et FAT32.
Il reconnaît les noms courts et les noms longs (tronqués à 39 caractères pour l'affichage sur une seule ligne d'un écran Thomson).
Il reconnaît les cartes simple capacité (SD) et haute capacité (SDHC).
Il serait facile, je crois, de reconnaître aussi les SDXC (extended capacity).
Je ne l'ai pas encore fait car je n'ai pas de carte SDXC pour tester, mais ça viendra peut-être un jour...

[kirion]

Merci Daniel et Sam pour toutes ces informations.

Pour plus de détails: je te recommande de lire les fils sur les cartes SD de ce site. Ils sont nombreux. J'avais essayé de résumer leur évolution par là.

Je vais aller lire ce fil.

[kirion]

Daniel, comment faire pour sauvegarder ?
Quelle est la touche RAZ sur un clavier PC ?
Et sur le clavier virtuel, sur quoi faut il appuyer (combinaisons de quelles touches? Shift-RAZ ne sauvegarde pas).

Sélection_001.png (160.96 Kio) Consulté 1510 fois

[Daniel]

Touche RAZ :

Avec le clavier graphique : MAJuscule + RAZ
La touche MAJ n'est pas la touche CAPS LOCK. C'est la touche immédiatement à droite avec une flèche verte vers le haut.
Pour l'enfoncer il faut cliquer dessus et relâcher le clic hors de la touche.

Avec le clavier du PC : MAJuscule + Début
C'est la configuration par défaut de dcmoto.
Si la disposition du clavier a été modifiée par l'utilisateur, la boîte de dialogue 'Configuration du clavier" donne la correspondance.

clavier.png (6.66 Kio) Consulté 1490 fois