Jelora.fr

Ordinateur 8 bits avec processeur Z80 - Épisode #2 : Un nom, un nouveau circuit de développement et de la mémoire

20190526_163549.jpg

Second article sur mon ordinateur 8 bits à processeur Z80 en cours de réalisation !
En avant pour la suite des aventures dans le monde merveilleux des ordinateurs 8 bits fait maison !



1) Un nom :

Parce que oui, il faut bien que cet ordinateur ait un nom et je suis très mauvais pour trouver des noms à mes réalisations ! Mon serveur minitel a presque 2 ans et s’appelle toujours "Serveur Minitel de Jelora", c’est dire !

Et puis, un soir, une révélation est apparue, il s’appellera le :
Big Cat Computer

Pourquoi "Big Cat Computer" ? Parce que j’aime bien les gros chats et j’aime bien ce nom. Voilà, c’est tout ! :)

Par ailleurs, il y a environ 2 semaines, j’ai commencé à gribouiller sur des post-it ce que pourrait être le logo de cette ordinateur au nom assez original.
J’ai commencé par dessiner des gros chats et puis je suis allé au fur à mesure sur quelque chose qui suivait des traits ronds à base de cercles.

20190708_235434.jpg
20190709_003451.jpg
20190721_163527.jpg

Ce n’est pas finalisé pour l’instant, mais je suis déjà content et ce logo me plaît avec ce gros chat rond qui dort comme un gros ordinateur qui fait son ronflement pendant qu’il tourne. Oui, parce que, comme c’est partit, je pense que mon ordinateur risque d’être assez imposant à la fin !



2) Nouveau circuit de développement et mise en place d’un circuit ROM/RAM de test :

J’ai décidé de refaire entièrement le circuit de développement.

Le précédent marchait mais le fait qu’il devait toujours y avoir une communication série avec le PC pour récupérer l’octet demandé par le CPU faisait qu’il n’était pas possible d’avoir des traitements très rapides par CPU. Je me souviens avoir estimé entre 150 et 1000 octets possibles par seconde, ce qui n’est pas terrible si on veut faire de gros traitements, comme par exemple des chargements graphiques.

Je suis donc partit sur l’idée que si on voulait que le code soit exécuté à vitesse réelle, il fallait qu’il soit lu dans une mémoire, en l’occurrence une ROM.

Mais l’idée d’avoir toutes les étapes mécaniques répétitives d’enlever la ROM du circuit, l’effacer, la reprogrammer puis la remettre dans le circuit allait être pénible à la longue. Déjà au bout de 4-5 fois ça l’est !

Durant les développements, une ROM reprogrammable électriquement, une EEPROM donc, va rester dans le circuit en permanence sans qu’on ait besoin de la manipuler mécaniquement.
Le circuit de développement va donc agir désormais comme circuit de programmation de ROM et va donc programmer les ROMs accessibles dans la plage mémoire du processeur.
Contrairement à l’ancienne version du circuit qui ne faisait que lire le bus d’adresse et de contrôle et écrire dans le bus de données, celui ci va prendre contrôle maintenant des différents bus en écrivant directement dessus pour manipuler les mémoires.
Mais comment prendre contrôle des bus avec un processeur en place et en fonctionnement ? Tout simplement en le mettant en RESET ! En effet, lorsqu’on met le processeur est en RESET et qu’on le maintient dans cet état, tous les bus sont à l’état haute-impédance. On peut donc faire ce qu’on veut avec !

Après démontage de l’ancien circuit et mise en place du nouveau, voici ce que ça donne :

20190420_215422.jpg

Et ça en schéma :
Prototype ordinateur 8bits Z80 - Circuit de développement.JPG
Version pdf : lien

Cela ressemble beaucoup à l’ancien circuit. En effet, il reprend presque tous les mêmes composants qu’avant, à savoir :
- un micro-contrôleur PIC16F876A (pdf) (au lieu du PIC16F873) cadencé à 18,432 Mhz (contre 4 Mhz avant)
- des bascules type-D 74LS373 (pdf)
- un adaptateur USB-série CH340G (pdf)
- des portes logiques inverseuses 74LS04 (pdf).

Mais avec ce circuit de programmation de ROM, il fallait bien quelque chose à programmer. J’ai donc mis en place un premier circuit mémoire avec :
- une EEPROM 28C64 (pdf) de 8Ko qui va faire office de ROM boot accessible de l’emplacement 0000 à 1FFF
- une SRAM 6264 (pdf) de 8Ko accessible de l’emplacement 2000 à 3FFF
De quoi m’amuser suffisamment dans un premier temps.

20190420_215430.jpg

Schéma :
Prototype ordinateur 8bits Z80 - ROM boot 8Ko et RAM 8Ko.JPG
Version pdf : lien

Pour l’instant, il n’y a que ces deux mémoire mais à savoir que, dans le futur, je souhaite organiser la mémoire par morceaux de 8 Ko comme suivant :
- 0000 à 1FFF : ROM boot 8Ko contenant un système de base avec différentes routines communes, telles qu’écrire sur l’écran, lire le clavier ou accéder au lecteur de disquette et qui seront accessibles aux autres programmes.
- 2000 à 3FFF : SRAM 8Ko utilisée par le code la ROM boot.
- 4000 à 5FFF : 1er bloc de 256 x SRAM 8Ko ou 256 x ROM 8Ko accessibles par bank-switching
- 6000 à 7FFF : 2e bloc de même type
- 8000 à 9FFF : 3e bloc de même type
- A000 à BFFF : 4e bloc de même type
- C000 à DFFF : 5e bloc de même type
- E000 à FFFF : 6e bloc de même type

Ce qui fait en tout 24584 Ko, soit un peu plus de 24 Mo, de mémoire accessible directement ou par bank-switching par le CPU.

Pourquoi une telle organisation ?
La ROM boot doit être toujours présente car elle permettra de lancer l’interface de base au démarrage et, comme dit précédemment, elle contiendra un ensemble de routines utiles aux autres programmes. Donc il faut qu’elle soit là tout le temps.
La SRAM 8 Ko suivante devra être tout le temps présente aussi vu qu’elle contiendra les données utilisés par le code de ROM boot.
Pour l’instant, cela tel que décrit me convient mais si dans l’avenir, si je me retrouvais à avoir beaucoup de routines communes, peut-être que je mettrais en place un système de bank-switching avec un moyen de démarrer sur la bank 0 au moment du démarrage de la machine ou lors d’un RESET.
J’ai décidé ensuite d’avoir des blocs de 8Ko qui seront soit de la RAM ou de la ROM afin de convenir aux besoins différents logiciels. Je ne veux pas de configuration fixe, je préfère quelque chose qui s’adaptera au mieux suivant la situation.
Les ROMs seront des logiciels préchargés, comme par exemple une interface BASIC ou un logiciel d’édition musicale. Ils pourront utiliser plus ou moins de ROM. Certains pourront tenir dans une seule ROM, d’autres sur deux ou trois ou plus. Le reste de la plage mémoire sera ensuite attribué dans la RAM de façon dynamique via des registres qui détermineront si on a une RAM ou une ROM. Le choix de la ROM ou la RAM accessible par bank-switching se fera via un autre registre spécifique pour chaque bloc de 8Ko.
Il y aura donc :
- un registre de 6 bits pour déterminer si chaque bloc est de la RAM ou de la ROM. Un bit 0 ou 1 dira si c’est une RAM ou une ROM.
- un registre de 8 bits par bloc pour sélectionner la bank de RAM ou de ROM.


Bon, c’est pas tout, mais tout ce bouzin, comment ça marche ?
D’un point de vue hardware, on a des bascules type D 74LS373 qui permettent d’appliquer divers états sur le bus d’adresse ou sur le bus de contrôle et d’appliquer ou de récupérer l’état du bus de données.

Quand on n’est pas en écriture de ROM et qu’on laisse le processeur tourner, les bascules du cricuit de développement ont leurs sorties en état haute-impédance. De ce fait, elle n’ont aucun agissement sur le reste de l’ordinateur.

Lorsqu’on souhaite écrire des données en ROM, les bascules type D de sortie (celles qui permettent d’appliquer quelque chose sur un bus) quittent leur mode haute-impédance en passant /OE (Output Enable inversé) à 0 et on applique les valeurs suivantes sur les bus :
- bus d’adresse à 0
- tous les bits du bus de contrôle à 1 sauf RESET à 0 pour mettre le CPU en RESET et laisser le champ libre au circuit de développement
- bus de données à 0

Après cela, lorsqu’un ordre d’écrire un octet en ROM est reçu par le microcontrôleur, il se produit les actions suivantes :
- l’adresse mémoire est appliquée sur le bus d’adresse
- l’octet correspondant sur le bus de données
- les bits /MREQ et /WR sur le bus de contrôlent passent à 0 pendant un certain temps (temps d’écriture en ROM)
- puis /MREQ et /WR repassent à 1.
Ceci recommence en boucle pour chaque nouvel octet à écrire en ROM.

Lors de la vérification de ce qu’il a été écrit en ROM :
- l’adresse mémoire à vérifier est appliquée sur le bus d’adresse
- les bits /MREQ et /RD sur le bus de contrôlent passent à 0
- la puce bascule type D de sortie (IC9) pour le bus de données passe en haute impédance et c’est la puce bascule type D d’entrée (IC10) qui prend le relais qui va récupérer la valeur sur le bus pour que le microcontrôleur la récupère ensuite en l’envoi au PC via la liaison série.
- puis /MREQ et /RD repassent à 1.
Ceci recommence en boucle pour chaque nouvel octet à lire/vérifier en ROM.

Une fois le processus d’écriture en ROM terminé, les bascules type D de sortie et d’entrée repassent en haut-impédance, le bit RESET du bus de contrôle n’est plus à 0 et donc le processeur redémarre et exécute le code fraîchement enregistré.

D’un point de vue logiciel, comme dans l’ancienne version du circuit, on a un microcontrôleur qui reçoit des instructions via l’interface série.
Les commandes possibles sont les suivantes :
- TEST : qui retourne toujours "OK" et qui permet juste de savoir si le microcontrôleur répond.
- START : démarre une séquence de programmation et active le RESET du processeur.
- END : termine une séquence de programmation et désactive le RESET du processeur.
- WRITE<adressHigh><adressLow><longueur>\r<octet0><octet1><octet2>...<octetN> : permet d’écrire un ensemble d’octets (maximum 256), avec longueur = longueur de l’ensemble – 1, à partir de l’emplacement mémoire définit par les valeurs adressHigh et adressLow qui définissent l’adresse 16 bits avec adressHigh pour les 8 bits haut et adressLow pour les 8 bits bas.
- READ<adressHighDebut><adressLowDebut><adressHighFin><adressLowFin> : permet de lire un ensemble d’octets en mémoire et de les retourner via le port série à partir de adressHighDebut/adressLowDebut jusqu’à adressHighFin/adressLowFin
- WRITEDELAY<delayHigh><delayLow> : définit le temps d’écriture nécessaire pour chaque octet en ROM via une valeur arbitraire. Cette valeur est comprise entre 0 et 65535 et correspond à un nombre d’itérations d’une boucle d’attente afin de laisser suffisamment de temps à chaque octet de s’écrire. Cette valeur est à définir suivant le modèle de ROM. Par exemple, il est de 400 pour une EEPROM AT28C64B-15PU.

La configuration série a été mise à jour.
Avec le passage de la fréquence du  microcontrôleur de 4 MHz à 18,432 MHz et la modification de la configuration dans le code, on passe d’un débit à 9600 bits/s à un débit à 230400 bits/s !
Je ne vais revenir sur comment on configure le port série sur le microcontrôleur, mais en suivant le tableau ci-dessous et comme vu dans l’article précédent, avec un quartz de  18,432 MHz et en appliquant la valeur 4 au registre de configuration SPBRG, on peut obtenir un débit de très exact de 230400 bits/s.

calcul_valeur_vitesse_transmission_serie.JPG

Ce débit très rapide permet de faire des transferts d’ensemble d’octets à écrire beaucoup plus rapidement et ainsi de réduire le temps d’écriture final.

Mes premiers essais en écrivant quelques octets par secondes ont été concluant. :)

...
--:-- / --:--
  • Télécharger ...
    • Qualité
      -

      Par la suite, en essayant d’aller de plus en plus vite sur le temps d’écriture, je me suis retrouvé face à un problème, j’obtenais des données corrompues à la relecture.
      Cela était dû à un temps d’écriture par octet trop rapide. Pour l’EEPROM AT28C64B que j’utilise, celui-ci est de 1 ms.
      Après application d’un temps d’écriture suffisant, les données se sont bien écrites.

      Au final, le circuit passe plus de temps à attendre que chaque octet soit bien écrit qu’à recevoir les données par voie série.

      Mais je me retrouve avec des temps écriture de 48 secondes pour 8 Ko ! Donc je suis plutôt satisfait ! :)

      Test écriture random à 18.432Mhz.JPG

      Vu qu’il est possible d’écrire seulement à un emplacement spécifique sur une certaine longueur, quand je ferai mes mises à jour du code, je pourrai envoyer seulement ce qui été modifié. Ce qui permettra de faire des écritures très rapides si peu de code est modifié à chaque fois.

      Code source du micro-contrôleur : lien
      Code source code Java sous Eclipse : lien



      3) Horloge système :

      Ah ! La définition de l’horloge système, ça c’est une sacré histoire.

      Au départ, j’avais tout simplement mis un quartz de 8Mhz parce que j’avais des Z80 qui allaient à 8Mhz sans trop me poser de question. Quand je lançais du code en ROM, je voyais que ça avait l’air stable puis voilà. Je me disais que ça faisait déjà une bonne base pour commencer.

      Mais j’avais également des Z80 pouvant aller jusqu’à 20MHz, les dernières versions du modèle ayant étés produites. Qu’elle vitesse ! Cela parait dérisoire face aux fréquences en GHz des ordinateurs de nos jours mais passer de 8Mhz à 20Mhz, ça représentait un sacré bon en avant. Surtout que, même si c’est "que" 20 MHz, ça reste quand même pas mal d’instructions par secondes qui sont traitées et il faut quand même les écrire toutes ces instructions !

      20190616_152901.jpg

      Après avoir eu un circuit bien stable à 8Mhz, j’ai voulu tester à 20Mhz. Je me suis commandé des oscillateurs quartz 20Mhz et j’ai changé mon Z80 8MHz contre un Z80 20Mhz, je met tout ça en place et là ... Ah ben ça marche pas bien ! L’ordinateur a des fonctionnements complètement aléatoires se terminant souvent par un HALT à un moment ou un autre. Même pire : je me rends compte par la suite que l’EEPROM avait été effacé. Mais comment ça a pu arriver ?!
      Bon ... Je reprogramme la ROM avec le circuit de développement, celui-ci me dit que tout est OK en la relisant les données après l’écriture de celles-ci et le CPU est relancé. J’obtiens à nouveau des fonctionnements aléatoires et une EEPROM qui s’efface.

      Je pense qu’il est très facile de comprendre que le processeur va trop vite pour la ROM et que celle ci n’a pas le temps de charger une donnée demandée sur le bus de données.
      Et donc, le CPU finit par faire n’importe quoi, dont écrire à des endroits de la ROM où il y a du code.

      Mais d’un point de vue très technique, ça donne quoi ? Et bien là, pour comprendre pourquoi ça marche pas, il faut se plonger dans les tableaux de valeurs et les diagrammes des temps d’accès l’EEPROM et du CPU.

      D’abord ceux de lecture de l’EEPROM, j’utilise actuellement une EEPROM Atmel AT28C64B-15PU (pdf).

      memory_access_timing_28c64.JPG

      En regardant le tableau de valeurs, on voit que la valeur "tACC", correspondant au temps qu’il se passe entre le moment où une adresse est donnée à la ROM et où celle ci retourne la valeur, est de maximum 150 ns. Donc pour être sûr que la donnée est bien retournée, il faut prendre en compte le fait que cette EEPROM met 150 ns à traiter une demande.

      Maintenant, avec le diagramme d’accès mémoire en lecture par le Z80 (pdf) :

      memory_access_timing_z80_read.JPG

      On voit entre le moment où le CPU donne une adresse mémoire et le moment où il récupère ce qui se trouve sur le bus de données (temps symbolisé ici par "tRD"), il se passe l’équivalent de 2 cycles d’horloge /CLK (0,75+1+0,25 cycles entre le début et la fin de "tRD").
      A 20 MHz, un cycle d’horloge, qui est une période de l’oscillateur à quartz, est de 50 ns.
      Ce qui veut dire que pour qu’une donnée soit bien récupérée par le CPU, il faut que celle ait été retournée par l’EEPROM dans un temps équivalent au maximum à 2 cycles d’horloge, soit 100 ns.

      Ah tiens ! A 20 Mhz, je dois avoir ma donnée en moins de 100 ns sauf que ma EEPROM AT28C64B-15PU met 150 ns à le faire ! Voilà pourquoi j’avais des fonctionnements aléatoires du CPU.

      Pour palier du coup à ce problème, il faudrait donc une ROM avec un temps d’accès de maximum 100ns.
      Et heureusement, ça existe ! Mais j’en ai pas pour l’instant ... Donc ce sera pour la prochaine fois ! ;)

      Ensuite, il ne faut pas oublier qu’un ordinateur n’est pas fait que de ROM, il y a aussi de la RAM et du coup, celle-ci devra elle aussi avoir un temps d’accès de lecture de maximum 100 ns.

      Bon, ok pour la lecture, c’est fait.
      Mais un CPU, ça écrit aussi en mémoire ! Et justement en RAM !
      Si on s’attaque à la partie écriture en mémoire du diagramme d’accès mémoire du Z80 :

      memory_access_timing_z80_write.JPG

      On voit, cette fois ci, qu’entre le moment où l’adresse est donnée et le moment où l’écriture mémoire est terminée avec l’arrêt de /MREQ et de /WR, il y a 2,5 cycles d’horloge, soit 125 ns pour une horloge système à 20 Mhz.

      Il faut donc que la RAM ait enregistré la donnée en moins de 125 ns.
      Mais on a vu précédemment que le temps d’accès en lecture devait être au maximum de 100 ns, la RAM devra du coup elle aussi avoir des temps d’accès de 100 ns aussi bien en lecture qu’en écriture.

      Comme dit  précédemment, j’utilise une EEPROM Atmel AT28C64B-15PU (pdf) et en RAM, j’utilise une Hitachi HM6264LP-15 (pdf), une RAM statique.

      20190721_131659.jpg

      Ces deux types de mémoires ont un temps d’accès de 150 ns, ce qui est trop long pour du 20 MHz. Il faudra donc les remplacer par des versions ou des modèles plus rapides.
      Pour la SRAM, je ne pense pas que ça soit compliqué à trouver à prix raisonnable, il existe justement une version 100 ns du modèle que j’ai actuellement sous la référence HM6264P-10 et HM6264LP-10 ou carrément en encore plus rapide les MCM6264 (pdf) qui vont entre 12 et 35 ns !
      Par contre, en EEPROM 2864, je n’ai pas trouvé de modèle ayant un temps d’accès en dessous de 120ns. Pour aller à 100ns, il faut passer au UV EPROM avec, par exemple la référence M27C64A-10F1 (pdf). Ce qui n’est pas très pratique pendant les développements avec réécritures en ROM fréquentes mais ce sera très bien pour quand le code d’une ROM sera terminé.

      Donc, avec ces limitations techniques, je pense partir avec un possibilité de fréquence CPU modifiable.
      Le temps des développements, soit je reste sur des EEPROM à 150 ns ou à 120 ns. Ce qu’il veut dire, qu’avec 2 cycles d’horloge correspondant au temps d’accès en lecture, j’aurais soit 75 ns ou 60 ns par cycle, c’est à dire une fréquence d’horloge système de 13,33 MHz ou 16,66 MHz au maximum. Ce qui est déjà pas mal !
      Une fois les développements terminés, je pourrais passer à des UV EPROM à 100 ns et là, le CPU pourra tourner à pleine puissance à 20 MHz !

      Après, je peux tenter de remplacer la ROM par une SRAM ayant le même pinout mais je vais perdre ce que j’ai enregistré lors de l’arrêt de l’ordinateur. Il faudra juste que je fasse une reprogrammation complète au début de chaque séance de développements.

      Bref, il reste plus qu’à tester !

      Je garde toujours le petit oscillateur NE555 (pdf) qui me génère du 35 Hz pour pouvoir faire des tests et visualiser ce qu’il se passe sur les LEDs d’affichage des bus.

      20190721_145323.jpg

      La sélection de la fréquence voulu est faite pour l’instant avec un simple fil (fil blanc sur la photo) qu’on change de position entre le NE555 et l’oscillateur à quartz. ;)

      Schéma :
      Prototype ordinateur 8bits Z80 - Circuit CPU -  Horloge système - Affichage bus.JPG
      Version pdf : lien



      4) Petites améliorations :

      - L’alimentation :

      Pendant les améliorations du circuit de développement et suite à l’ajout de la ROM et de RAM, je me suis retrouvé, de temps en temps, face à un problème. Par moments, lorsque j’écrivais en ROM, le circuit semblait partir écrire d’un coup vers une autre zone mémoire sans aucune raison particulière.

      J’ai essayé de chercher partout dans le code du micro-contrôleur d’où ça pouvait venir mais rien à faire. Même quand je faisait une écriture très lente de la ROM pour bien visualiser ce qu’il se passait via les LEDs d’affichage des bus, je voyais bien que l’écriture se faisait au bout d’un moment, et toujours le même, vers une autre zone mémoire.

      Puis, à moment, je suis rendu compte d’un fait. Je commence à avoir pas mal de composants qui sont alimentés en même temps, ça doit consommer pas mal ! L’alimentation entre mes différentes plaques d’essais sont liés simplement par deux fils, un rouge pour une alimentation positive et un noir pour la masse.

      20190525_001434.jpg

      Vu que la consommation générale commence à augmenter, il se pourrait que les fils que j’ai mis ne soit pas assez gros.

      J’ai alors décidé de mesurer la différente de tension entre l’endroit où la masse arrive depuis mon alimentation de labo et le point de masse le plus éloigné dans le circuit. Normalement, celle-ci doit être quasiment nulle vu qu’on est sensé avoir du 0V partout vu qu’il s’agit de la masse.

      Voici le résultat obtenu à l’oscilloscope :

      DS1Z_QuickPrint9.jpg

      J’ai carrément une différence de 1V en moyenne ! Et suivant comment les LEDs clignotent sur le circuit, je voyait cette différence de tension bouger !

      Bon ok, les fils d’alimentation sont un peu trop justes ! :D

      N’ayant pas de plus gros fil rigide sous la main pouvant rentrer dans les petits trous des plaques d’essais, j’ai donc quadruplé les fils entre chaque plaque et là ... Il y avait plus du tout de différence de tension entre les deux points de masses mesurés et le circuit de développement s’est enfin mis à marcher correctement !

      20190721_174024.jpg

      Donc il faudra prévoir large niveau câblage de l’alimentation pour la version finale de l’ordinateur.


      - Rajout d’une LED d’accès sur le port de sortie :

      Ce n’est pas l’amélioration du siècle mais avoir une petite LED (la verte sur la photo) qui indique quand le CPU tente d’accéder au port en écriture, comme celles lorsqu’on accède à la ROM ou à la RAM, c’est quand même bien pratique.

      20190721_144746.jpg

      ...
      --:-- / --:--
      • Télécharger ...
        • Qualité
          -

          Schéma :
          Prototype ordinateur 8bits Z80 - Port de sortie 0 à leds.JPG
          Version pdf : lien



          5) Et ensuite ?


          - Composants achetés à tester :

          Depuis le précédent article, je me suis commandé quelques composants que j’aimerais bien avoir dans mon ordinateur :

          20190721_151628.jpg

          Les puces sonores SN76489 (pdf), AY-3-8913 (pdf) (variante du AY-3-8910 mais sans port de sortie 8 bits générique, la puce sonore qui fait juste puce sonore) et YM2612 (pdf) : J’ai envie de pouvoir faire de la création sur mon ordinateur et de pouvoir faire de la musique et des jeux vidéos avec de la musique générée par des composants avec de belles sonorités.

          Le contrôleur de lecteur de disquette Zilog FDC Z765 (pdf) : Je souhaite pouvoir utiliser des disquettes 3"1/2 et 5"1/4 avec mon ordinateur. Pourquoi ? Pour le fun ! C’est tout ! Donc j’ai cherché des contrôleurs et j’ai trouvé celui là ainsi que ses équivalents chez d’autres marques.

          Le contrôleur de clavier VT82C42 (pdf) : Il faudra bien un clavier à cet ordinateur pour pouvoir y faire des trucs non ? Ce composant a été assez utilisé jusque dans les années 90 dans les PC comme contrôleur clavier pour y relier un clavier DIN ou PS/2.
          Donc avec un vieux clavier d’occaz et ce contrôleur, il y a moyen de faire des trucs sympas !
          Surtout que j’ai testé un vieux clavier DIN avec touches mécaniques, que j’avais récupérer il y a des années, sur mon PC retro ayant justement un contrôleur clavier VT82C42 et ça marche ! Donc ça promet des trucs biens ! ;)

          20190612_182225.jpg


          - Futurs composants :

          Dans les composants pas encore achetés mais que j’aimerais bien tester, il y a la puce Dallas DS12885, dont j’avais parlé ici, une horloge RTC, qui est l’équivalent de la puce DS12887 mais sans la pile intégrée non remplaçable.
          Ça a l’air d’être un chouette puce de gestion d’horloge mais le coup de la pile lithium interne qui ne peut pas être replacée facilement, c’est pas top. Donc je pense partir sur le modèle sans pile auquel je vais relier une pile remplaçable qui sera sur un support à côté.

          20190721_151807.jpg

          Je parlais plus haut de m’amuser avec des disquettes 3"1/2 et 5"1/4 mais pourquoi pas pousser le délire encore plus loin et utiliser aussi des disquettes 8" ?
          J’en ai justement un certain stock que j’avais acheté il y a des années sur eBay parce que je trouve que ces grosses disquettes sont classes. (Oui c’est mon seul argument et il me convient !)
          Dans le choix du lecteur de disquette, il faut faire attention. Beaucoup de lecteurs de l’époque utilisaient des moteurs synchrones basés sur la fréquence du secteur pour faire tourner les disques à la bonne vitesse. Sauf que, de nos jours, on trouve plus facilement des lecteurs de disquettes 8" aux US qu’ailleurs et donc en 120V/60Hz ! Pas vraiment compatibles par chez nous du coup.
          Heureusement, certains modèles utilisaient des moteurs continues 24V, tel que le Shugart 860.
          Reste à voir ensuite comment contrôler ces lecteurs (est-ce que le Zilog FDC Z765 va le faire ?) et s’ils vont réussir à lire et écrire sur mes disquettes, surtout qu’il y en a certaines dont je serais curieux de voir ce qu’il y a dedans ... ;)

          20190721_175920.jpg


          - Création d’un logiciel de développements

          Maintenant que j’ai un circuit de développement bien avancé, je vais pouvoir m’attaquer au logiciel qui va permettre justement de faire du développement pour processeur Z80 pour ma machine. Ce sera, en gros, un logiciel de développement classique, permettant de compiler du code et de l’envoyer dans la ROM de l’ordinateur. Voilà !



          Suite au prochain épisode ... ;)

          Ajouter un commentaire

          Nom/Pseudo :

          *

          Email :

          Site web :

          Commentaire :

          *

          Vérification:


          *