forum.system-cfg.com

SDDRIVE est un nouveau projet de simulateur de disquettes sur carte SD pour tous les ordinateurs 8 bits Thomson (sauf le TO9).
Par rapport au contrôleur CS91-280 avec l'interface SDMOTO imaginez :
- Un boîtier externe unique comprenant le contrôleur et le lecteur de carte SD
- Une vitesse en lecture de 20000 octets par seconde

A comparer aux 5800 octets/seconde du contrôleur CS91-280 et aux 5000 octets par seconde en moyenne pour la disquette réelle. Cette vitesse accrue permet d'envisager des démonstrations beaucoup plus spectaculaires, en particulier dans le domaine de la musique, mais pas seulement.

Le premier prototype fonctionnel (23/11/2017) :
Copie d'écran :
Analyse de la liaison SPI :
Lecture d'un octet :
La programmation et la conception du produit final sont en cours, et seront probablement finalisées dans les premiers mois de 2018.

Bravo Daniel ! Super projet.

Bravo Daniel, bientôt un nouveau périphérique à grande vitesse pour Thomson ...

Carl

Ouah !!!!!!!!

Ca c'est du très lourd !!

Daniel est intarissable

bravo! L'idée ici est de ne plus passer par les port manettes, si je comprends bien. Du coup tu peux avoir un protocole de transfert adapté et bien plus efficace, c'est ca ? Par contre dans le code ASM je ne vois pas bien comment l'horloge SPI est envoyée. Ca marche comment ?

Depuis plusieurs années je cherchais à augmenter la vitesse de lecture des cartes SD en mode SPI.

En générant l'horloge par soft avec le 6809, nous avons atteint le maximum. Toutes les optimisations possibles ont été faites.
On peut utiliser le 6309 : moins de cycles par instruction et des registres supplémentaires. J'ai réalisé un prototype, le gain est d'environ 30%.
Malheureusement, dans le monde entier il n'y a que trois Thomson équipés du 6309 (dont un de mes MO5). Peu de collectionneurs sont capables de dessouder le 6809 pour le remplacer. L'expérimentation du 6309 est très intéressante, mais ce n'est pas la bonne solution

Reste la génération de l'horloge par des moyens matériels. Je l'étudiais depuis quelques mois, j'ai fini par trouver une solution satisfaisante :

- L'horloge est générée par un circuit de décodage d'adresse, en l'occurrence $A7BF (ou $E7BF pour les TO). Quand cette adresse est détectée sur le bus on génère un front descendant d'horloge, quand elle n'est plus présente on génère un front montant. Le décodage d'adresse est en logique TTL très basique : un 74LS00 et un 74LS133 suffisent.

- Le bus de données (en réalité deux bits seulement, le bit 0 pour l'écriture et le bit 7 pour la lecture) est interfacé par un buffer à trois états 74LS125 : une porte dans un sens pour le bit 0, une porte dans l'autre sens pour le bit 7. Chaque porte est commandée par un circuit NAND, avec en entrée le signal d'horloge inversé et le signal READ pour l'un, le signal d'horloge inversé et le signal WRITE (inverse de READ) pour l'autre.

Une seule instruction d'écriture génère le top d'horloge et envoie le bit 0, une seule instruction de lecture génère le top d'horloge et lit le bit 7. En voyant le schéma cette solution paraît évidente, mais c'est en fait le résultat de pas mal d'heures de réflexion. Avec 50 cycles pour lire un octet on arrive pas loin du maximum théorique pour la vitesse de lecture bit par bit.

Les prévisions :

- Dans un premier temps terminer la mise au point du prototype.
Au début il y avait un fonctionnement assez aléatoire : l'analyseur logique montrait de temps en temps un glitch de quelques nanosecondes sur le signal de l'horloge. J'ai résolu ce problème en m'inspirant du schéma de l'extension MO5 : un filtre sur chaque ligne du bus d'adresse avec une résistance de 100 ohms et un condensateur de 100pF. Il n'y a plus aucun glitch.
Ensuite j'ai eu d'autres problèmes de fonctionnement aléatoire. A l'oscilloscope on observait une grosse instabilité sur la ligne MOSI quand le 74LS125 était dans son état "haute impédance". Une résistance pull-up de 10K a supprimé l'anomalie. Je continue les tests intensifs pour détecter d'autres problèmes éventuels et arriver au schéma définitif.

- Ensuite développer le soft du contrôleur.
Il sera stocké dans une EPROM de 2K octets. Je vais m'inspirer fortement du contrôleur CS91-282, en essayant d'intégrer le programme de sélection dans l'EPROM pour éviter d'avoir à mettre sur la carte SD le fichier boot.sd. La grosse difficulté sera de faire tenir dans 2K octets le contrôleur et le programme SDSEL. Il n'y aura probablement pas la place pour mettre le logo SDDRIVE en haut de l'écran.

- Enfin réaliser un circuit imprimé et le montage dans un boîtier externe.
Il est prévu un boîtier plastique de 100x60x25 mm, relié par une nappe souple au connecteur d'extension Thomson. En option il y aura sur la nappe un connecteur supplémentaire (le même que dans mon tripleur de bus) pour un autre contrôleur Thomson. Une belle étiquette SDDRIVE, une fente pour la carte SD, une LED de mise sous tension et une LED d'activité compléteront le boîtier.

Alors la, chapeau bas!
C'est un projet qui a terme sera plus pratique que la version sdmoto. C'est vraiment une très bonne initiative...

Chouette projet !

Une seule instruction d'écriture génère le top d'horloge et envoie le bit 0, une seule instruction de lecture génère le top d'horloge et lit le bit 7.

C'est très astucieux!

En voyant le schéma cette solution paraît évidente, mais c'est en fait le résultat de pas mal d'heures de réflexion.

Oui ca parait simple dire qu'il suffit d'envoyer 'l'horloge au moment où l'on accède à l'adresse. Encore fallait-il y penser!

Perso j'aime bien SDSEL sur la D7 ca permet de pouvoir le remplacer en cas de bug. Mais si tu as besoin de compresser, il y a toujours EXOMIZER2 dont le décodeur 6809 ne prend que 181 octets si j'ai bonne mémoire ici/rawdecrs/6809. Bon par contre le code s'auto-modifie et il faudra l'adapter pour l'usage en rom.

[EDIT] Le montage ultime serait de carrément lire/écrire l'octet en $BF. J'imagine que là il faut de l'électronique bien plus complexe.

Pour lire 8 bits en parallèle le plus simple est d'avoir un Arduino en interface. Comme il est plus rapide que le 6809 (16 MHz au lieu de 1 MHz) il peut lire les 8 bits dans le même temps que le 6809 lit un octet. Et alors la vitesse de lecture de la carte SD devient identique à la vitesse de lecture de la RAM. Un MO5 avec 32 Go de RAM, en quelque sorte. Ca fait rêver, et je crois bien que ça pourrait être le sujet d'un prochain projet. Ce serait l'équivalent du montage pour SDANIM7, mais sans passer par le 6821, directement sur le bus. Et avec l'écriture en plus.

Mais ne brûlons pas les étapes. Dans un premier temps je termine la mise au point de SDDRIVE, c'est une grosse avancée technique et il faut absolument la finaliser. Aujourd'hui le prototype fonctionne parfaitement bien, les dernières anomalies relevées n'étaient en fait que des mauvais contacts vite réparés. J'attaque maintenant la programmation...

Ouah superbe

Bravo et félicitations pour ce nouveau périphérique Thomson

J'aimerais maîtriser aussi bien l’électronique que toi pour concevoir des extensions pour nos vieux ordis, j'ai déjà du mal à faire fonctionner une extension avec seulement de la RAM et de la ROM, alors un périphérique !!!!

Oh non, je ne maîtrise pas, je suis totalement autodidacte. J'ai pourtant fait des études, mais l'électronique n'était pas au programme. C'est comme toutes les techniques, on apprend avec l'expérience et petit à petit on arrive à des résultats. Mon premier émetteur Petites Ondes date de 1960, avec le jeu "Le Jeune Radio à l'Ecoute du Monde" de Gégé. Je l'ai encore, avec son unique transistor et son tube alimenté en 18V. Depuis j'ai nettement progressé. J'aime bien l'électronique, car contrairement à l'informatique il y a des phénomènes physiques subtils, particulièrement aux hautes fréquences. Il est simple de mettre au point un programme, plus difficile de supprimer un glitch dans un signal TTL. Heureusement il y avait de bons ingénieurs chez Thomson, je me suis inspiré de leur schéma du contrôleur de QDD de l'extension MO5. Sinon j'aurais eu beaucoup plus de mal.

Daniel a écrit : ↑24 nov. 2017 14:37Un MO5 avec 32 Go de RAM, en quelque sorte. Ca fait rêver, et je crois bien que ça pourrait être le sujet d'un prochain projet. Ce serait l'équivalent du montage pour SDANIM7, mais sans passer par le 6821, directement sur le bus. Et avec l'écriture en plus.

Enfin 1mo aurait déjà était très bien. C'est aussi un formidable projet. Mais...
Comment un simple 8bits qui ne comprend un système d'adressage que sur 16bits va réussir à lire dans une mémoire qui sera forcément sur 32bits?

Question sûrement idiote, mais ce périphérique sera-t-il uniquement Thomson, ou serait-il adaptable sur d'autres machines?