Cette catégorie traite de développements récents destinés à nos vieilles machines, applications, jeux ou démos... Amis programmeurs, c'est ici que vous pourrez enfin devenir célèbres!
ARDDRIVE est un nouveau projet de contrôleur de disquette utilisant des fichiers images sur carte SD. Par rapport à SDDRIVE, le débit passe de 20 000 octets/seconde à 250 000 octets/seconde, grâce à un Arduino accédant à la carte SD en mode SPI et échangeant les données avec l'ordinateur Thomson en parallèle sur 8 bits.
Ne rêvez pas, ce périphérique miracle n'existe pas encore, mais il est à l'étude. Pour commencer toute la partie logicielle a été développée, ainsi que l'émulation par dcmoto. Le gain de vitesse est spectaculaire. Je n'ai encore aucune certitude sur la faisabilité matérielle, il faut attendre la suite des essais.
Il faut 4 cycles au 6809 pour lire un octet. Pendant ce temps, l'Arduino à 16MHz dispose de 64 cycles. A-t-il le temps de lire 8 bits sur la carte, sachant que la transmission SPI est prévue en "hard" dans le microcontrôleur ATmega328P ? Là est toute la question...
Franchement, tout le monde se demandait pourquoi la dernière mouture se branchait sur le bus pour ne transmettre qu'un bit à la fois... après il faut bien garder des billes pour faire perdurer la franchise, mais pour les connaisseurs, ça sentait déjà à plein nez la nouvelle version "++mieux", 100.000 fois plus rapide, etc., et on se doute qu'en attendant les vingt pages de péripéties déjouées une à une avec brio par le héros dans un nouvel épisode qui sent le réchauffé, le glorieux "happy end" est forcément déjà plus ou moins dans la boîte... enfin tant mieux pour les fans qui ne s'en lassent pas, chacun ses goûts en matière de cinéma, et bon film !
Même si ce n'est pas possible avec l'Arduino le concept reste intéressant. Si je n'y arrive pas un autre membre du forum pourra peut-être faire la même chose avec un microcontrôleur plus puissant. L'intérêt n'est pas tellement pour utiliser les logiciels commerciaux Thomson, ils se chargent assez vite avec SDDRIVE. C'est surtout pour développer des démonstrations inédites. C'est la même vitesse que la RAM, sauf que là c'est en séquentiel, donc plutôt adapté au streaming.
Le principe est similaire à SDDRIVE : quand $A7BF (ou $E7BF sur TO) est détecté sur le bus d'adresse un signal d'horloge est envoyé à l'Arduino. Le sens de transmission est donné par le signal /W du Thomson. Les huit bits sont lus ou écrits via le bus de données.
L'Arduino se contente de faire la transformation parallèle-->SPI ou SPI-->parallèle. Toute la logique d'envoi des commandes à la carte SD et de traitement des réponses est assuré par le programme de l'EPROM du contrôleur, exactement comme dans SDDRIVE.
@nicolho, tu sembles très confiant comme si tout était gagné d'avance... Moi je suis plus mitigé.
Rien, mais vraiment rien ne garanti que l'arduino soit capable de tenir les contraintes même en y travaillant beaucoup. C'est pour ca je que dis "Espoirs". Le soft sur arduino est du C. Les timings ne sont pas toujours prédictible (ca peut varier suit à un chamgent de compilo C). Impossible de maitriser les cycles. J'aurais tendance à dire que c'est même une difficulté supplémentaire d'ajouter une couche logicielle intermédiaire. Pour un truc comme ca j'aurais plus vu une solution 100% hardware "simple" où l'on controle tout avec un convertisseur série-parallèle entre la carte SD et le 6809.
On va voir si Daniel arrive à dompter l'arduino pour avoir un truc fiable et reproductible ou si ce sera une curiosité experimentale.
L'idéal serait de pouvoir explorer plusieurs solutions en parallèle pour la conversion série/parallèle. J'ai choisi l'Arduino car je connais un peu, c'est facile à trouver et très peu cher. D'autres solutions, soit purement électroniques, soit avec d'autres microcontrôleurs ou fpga, auraient probablement plus de chances d'aboutir, mais ça dépasse un peu mes compétences.
C'est un challenge qui mérite d'être tenté juste à titre personnel. Si le projet aboutie je ne suis pas persuadé que nous pourrons tirer davantage que la sdDrive (ou alors ce sera un poil mieux). La machine a tout de même ses limites et ce qui a été fait est déjà très bien...
Il va falloir considérer l'accès direct au port autant que ce peut au lieu de digitalRead/Write. Ces fonctions font des accès intermédiaires dans des tables pour traduire un pin standard en registre de port qui vont bouffer allègrement des cycles. J'ai pu atteindre 48 Ko de transféré à un Z80 en moins de 20 s en faisant cela (série sur 1-bit) : je crois que le facteur limitant était plutôt du côté Arduino que le Z80 (sauf à avoir mal calculer les cycles, il avait quand même une marge pour tourner plus vite car en moyenne j'avais 3 boucles d'attente sur un changement de pin - ce qui laissait entendre que l'Arduino était plus à la traîne).
Il va falloir considérer un double tampon, voire triple pour que l'Arduino ait le temps de lire/écrire un buffer en une passe pendant que les octets lus/écrits par le 6809 soit capturés au rythme de ce dernier. Grosso modo, la gestion des buffers se faisant dans "loop()" et l'accès à un octet dans une interruption enclenchée par une lecture ou écriture d'octet du 6809 à des endroits précis de préférence pour éviter d'interrompre l'Arduino sur des accès mémoire sans rapport. Éventuellement, un système de cache. Là pareil, autant utilisé l'interruption bas niveau et port direct.
J'ai un projet similaire que je souhaite porter sur ma série SHARP mais avec plus de possibilités :
- l'Arduino est connecté au bus Z80 avec deux modes.
- mode slave : dans ce mode, l'Arduino écoute les attentes du Z80 comme un contrôleur. Il pourra simuler une petite ROM (probablement lente) entre $E800-$EFFF -éventuellement ailleurs aussi.
- mode master : éventuellement, il peut requérir que le CPU lui donne l'accès maître au bus (/BUSREQ) pour accéder à l'ensemble des périphériques comme la DRAM, la VRAM, etc. Il pourrait ainsi charger ou sauvegarder directement des blocs de donnée en DRAM lus/écrits du SD, servir de DMA, sauvegarder une partie de le VRAM pour afficher un OSD et restituer la sauvegarde une fois fini avec l'OSD. Les possibilités sont nombreuses.
Daniel a écrit : ↑10 avr. 2019 17:49
Le principe est similaire à SDDRIVE : quand $A7BF (ou $E7BF sur TO) est détecté sur le bus d'adresse un signal d'horloge est envoyé à l'Arduino. Le sens de transmission est donné par le signal /W du Thomson. Les huit bits sont lus ou écrits via le bus de données.
L'Arduino se contente de faire la transformation parallèle-->SPI ou SPI-->parallèle. Toute la logique d'envoi des commandes à la carte SD et de traitement des réponses est assuré par le programme de l'EPROM du contrôleur, exactement comme dans SDDRIVE.
ok, j'avais zappé cette partie. Donc effectivement tu te sers de l'Arduino pour juste faire cette conversion et donc pas besoin d'un truc surpuissant.
Par contre, ouais port direct autant que possible.
Oui, je n'envisage pas autre chose que l'accès direct au port D en lecture et écriture. Par contre j'ai été trop optimiste : l'instruction de lecture ou d'écriture du 6809 dure bien 4 cycles, mais l'adresse est présente sur le bus d'adresses pendant un cycle seulement, c'est trop court pour lire ou écrire 8 bits de la carte SD.
J'étudie une autre solution : pour lire un octet, on met deux instructions de lecture à la suite.
- La première instruction déclenche la lecture de la carte SD, mais l'octet lu est ignoré par le programme appelant car il n'est pas encore prêt.
- La deuxième instruction, quatre cycles plus tard, lit l'octet de la carte (en supposant que l'Arduino ait eu le temps de le préparer).
Le débit est divisé par deux, mais ça a plus de chances de marcher.
En écriture il n'y a pas le même problème. L'octet est acquis immédiatement par l'Arduino, qui a tout le temps de l'écrire ensuite sur la carte.
Daniel a écrit : ↑11 avr. 2019 13:15
l'instruction de lecture ou d'écriture du 6809 dure bien 4 cycles, mais l'adresse est présente sur le bus d'adresses pendant un cycle seulement, c'est trop court pour lire ou écrire 8 bits de la carte SD.
comment tu acquières l'accès à un octet côté Arduino ? via une interruption ? ou au travers d'un polling actif dans loop() ?
EDIT: par lecture tu parles d'une lecture côté 6809 ? L'arduino n'a pas le temps de lire cette adresse et donc le 6809 fait deux lectures consécutives pour que l'Arduino ait le temps de répondre avec l'octet demandé ?
Daniel a écrit : ↑11 avr. 2019 13:15
J'étudie une autre solution : pour lire un octet, on met deux instructions de lecture à la suite.
il n'y a pas un équivalent /WAIT pour laisser au contrôleur le temps de lire cette adresse ?
Quand le 6809 lit l'adresse $A7BF l'Arduino a le temps de détecter la demande de lecture (par polling ou interruption, j'essaierai les deux méthodes), mais pas le temps en 1 µs de lire l'octet de la carte et de le renvoyer via le port D. Il faut donc une première lecture pour demander l'octet, puis une deuxième pour le lire 4 µs plus tard. Enfin c'est ce que j'imagine, reste à tester...
C'est vague... mais je me demande s'i ne faudrait pas une RAM à double accès entre le Thomson et l'arduino (bref: un buffer, une boite à lettre) combiné de l'electronique pour faire appaitre cet octet de mémoire à la bonne addresse coté thomson (cet electronique est déjà présente dans SDDrive je ne me m'abuse). L'arduino est averti quand cette ram est lue, et y stocke le prochain octet, ou dans l'autre sens il est averti que le 6809 y a écrit et y lit une nouvelle valeur. Bon par contre ca complexifie le montage.
Je vais commencer par mesurer le temps nécessaire à l'Arduino pour lire ou écrire un octet sur la carte. Quand on le saura il sera plus facile d'imaginer des solutions.
Espérons!
après il faut bien garder des billes pour faire perdurer la franchise, mais pour les connaisseurs, ça sentait déjà à plein nez la nouvelle version "++mieux", 100.000 fois plus rapide, etc., et on se doute qu'en attendant les vingt pages de péripéties déjouées une à une avec brio par le héros dans un nouvel épisode qui sent le réchauffé, le glorieux "happy end" est forcément déjà plus ou moins dans la boîte... enfin tant mieux pour les fans qui ne s'en lassent pas, chacun ses goûts en matière de cinéma, et bon film ! 
