Auteur Sujet: Un bidouilleur français créé un ordinateur en partant de zéro : A2Z  (Lu 18718 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Un bidouilleur français créé un ordinateur en partant de zéro : A2Z

J’ai découvert un projet assez sympa : Un bidouilleur amateur français, [F4HDK], a créé un ordinateur en partant réellement de zéro. D’où le nom du projet "A2Z".



Même le processeur et la carte graphique sont spécifiques et ne ressemblent à rien qui existe ; il a codé ces composants spécifiques sur un FPGA. Un FPGA, c’est un composant électronique que l’on peut reconfigurer, et dans lequel on peut implanter une électronique complexe.

Voici la carte :
(cliquez sur l'image pour zoomer)


Le CPU a son propre jeu d’instruction. Il a inventé son langage basic et codé le compilateur qui va avec.
Au final, ça donne un petit ordinateur qui ressemble à un vieux PC des années 80; apparemment ça a les performances d’un 80286, donc c’est bien lent. Mais son intérêt était uniquement l’apprentissage par la pratique, rien de plus. J’imagine la quantité de travail nécessaire pour aboutir à un tel résultat.



Tout le projet est open source, et on peut même télécharger un émulateur qui tourne sous Windows, très simple à utiliser, j'ai testé.
Il y a aussi un jeu de voiture qui ressemble à Micro-Machines, et qu’il a encore une fois recodé intégralement dans son langage basic en partant de zéro.

Petite vidéo de démonstration :


Le site est assez intéressant à lire, ça n’est pas trop hardu. Ca ne ressemble pas aux articles universitaires par exemple.
=> http://f4hdk.free.fr/A2Z_computer/


Il a eu droit à un post sur le blog hackaday : http://hackaday.com/2017/01/13/fpga-computer-covers-a-to-z/

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Un bidouilleur français créé un ordinateur en partant de zéro : A2Z
« Réponse #1 le: 26 mai 2017 à 08:39:20 »
Carte électronique de développement

[F4HDK] a réalisé la carte de développement lui-même en wrapping, car il n’a pas réussi à trouver une carte FPGA disposant de 2Mo de SRAM. Il voulait impérativement disposer de SRAM, pour la simplicité.

Composants principaux :
- FPGA : Wave Share Core EP4CE6 breakout board (ALTERA Cyclone IV FPGA with 6000 logic cells) avec ROM de boot interne de 2ko
- SRAM : 4 x CY7C1049 (512k x 8 bits) accessible par mot de 8 ou 16 bits
- FLASH : Micron N25Q128A (16MB)

Les performances sont proches d’un 80286 des années 80.

Dos de la carte :
(cliquez sur l'image pour zoomer)


Carte fille, avec 2Mo de SRAM : La carte SRAM utilise des mémoires CMS, plus compactes.


Côté composants, le câble à wrapper est traversant, et vient directement se soudé sur les broches des mémoires CMS. Côté connecteur, il utilise du wrapping classique. La densité de câblage est élevée, avec 120 interconnexions wrappées.

Le Dos :



Caractéristiques générales

Le cœur :
- Jeu d’instruction RISC très basique
- Aucune gestion d’interruption
- Cache 128 x 16bits
- Bus de donnée 16 bits
- Bus externe d’adresse 24 bits
- Opérations arithmétiques et logiques : entiers 16bits

Vidéo :
- Partie graphique VGA 640 x 480, 256 couleurs, palette fixe. Mémoire vidéo partagée avec le CPU, comprise dans la RAM 2Mo.
- Gestion double buffer pour la fluidité
- Partie texte : 80 colonnes x 30 lignes, en surimpression par rapport au graphique

Autres périphériques :
- Interface SPI 8 bits, pour une mémoire FLASH 16Mo
- Interface série mono-directionnel émulée par soft (bit banging) pour liaison avec le PC de développement. Il n’y a pas d’acquittement, pas de demande de répétition, ou de contrôle de flux de la part du récepteur (A2Z).
- Interface clavier PS/2

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Un bidouilleur français créé un ordinateur en partant de zéro : A2Z
« Réponse #2 le: 26 mai 2017 à 08:48:12 »
Schéma global :



Le cœur est un RISC 16bits, avec un décodage d’instruction très simple.
C’est du RISC, donc sans microcode. Les opérations sont donc très élèmentaires. Le CPU, en lui-même, est incapable de générer des opérations complexes. Toute la complexité que l’on trouve dans le microcode sur un CPU CISC, se retrouve dans le compilateur. C’est le compilateur qui va générer une séquence d’instructions élèmentaires à partir d’une instruction plus complexe. Le code exécutable généré est donc très volumineux, beaucoup plus que pour un CPU CISC, mais ça n’est pas un problème, vu les 2Mo de RAM.

La fréquence d’exécution n’est pas optimale : La carte devrait en théorie faire tourner tout l’ordinateur à 50MHz. A une telle fréquence, les 3/4 du temps sont alloués au cœur, et 1/4 est alloué au VGA. On a donc l’équivalent d’un cœur seul à 37MHz.
[F4HDK] a rencontré d’énormes problèmes de stabilité à 50MHz, certainement dus à la non maîtrise des « timing constraint » du FPGA. A 25MHz, avec une répartition 50% / 50% entre cœur et VGA, donc un équivalent d’un cœur à 12MHz, soit 3 fois moins performant que prévu, c'est stable.


La carte vidéo génère un signal VGA 640 x 480 60Hz.
Elle est composée de 2 parties :

1) Partie graphique, 256 couleurs.
La palette est fixe : sur les 8 bits [F4HDK] alloue 2 bits à chacune des 3 couleurs (R, V, B), et 2 bits pour la luminosité.
La palette vient alimenter 3 convertisseurs numériques/analogiques 4 bits fait avec des composants discrets.
La mémoire vidéo est partagée avec le CPU, comprise dans la RAM 2Mo. On alloue 50% du temps à la carte vidéo, et 50% du temps au CPU. La vitesse d’exécution du CPU est donc fortement réduite.
[F4HDK] gère un double buffer vidéo : on peut dessiner une image pendant qu’une autre est affichée. Sur ordre du logiciel, le basculement d’une image à l’autre se fait entre 2 balayages d’écran. Cela permet d’obtenir des mouvements fluides et sans « rayures » dans les animations. Il n’y a aucune accélération hardware graphique (gestion de sprites ou autre), tous les graphiques sont générés par logiciel.

2) Partie texte :
80 colonnes x 30 lignes, en surimpression par rapport au graphique. Avoir une sortie texte, c’est très pratique pour débugger un ordinateur, et commencer à coder les premiers programmes.

Les 3 parties (cœur, VGA graphique, et VGA texte) doivent être parfaitement synchronisées entre elles.


Rom de Boot :
C’est en fait une RAM de 2ko interne au FPGA, qui contient initialement le programme Bootloader. C’est le premier périphérique que [F4HDK] a utilisé. C’est avec cette  RAM que [F4HDK] a codé les premiers programmes, sans aucun autre périphérique. L’outil « in system memory content editor » d’ALTERA permet d’écrire et de lire dans cette RAM à la volée, à la façon d’un « émulateur de RAM / EPROM ». Remarque : le bootloader n’est pas émulé dans l’émulateur.




Interface PS/2 :
Comme le CPU ne sait pas gérer les interruptions (c’est volontaire pour simplifier le CPU), [F4HDK] a été obligé d’introduire une petite FIFO entre l’interface PS/2 et le CPU, pour être certain de ne rater aucune information issue du clavier. 
Il y a donc en sortie du PS/2 un flag pour indiquer que la FIFO contient des données, et la lecture des données de la FIFO en elle-même.


Interface série mono-directionnel :
Il n'y a pas d’interface série à proprement parler. Juste 2 bits d’entré et 2 bits de sortie du style GPIO. [F4HDK] émule par logiciel l’interface série : c’est du bit-banging. Seule la partie RX est codée, pour télécharger des données depuis le PC de développement vers A2Z.
Le choix du bit-banging limite fortement le débit (56 Kb/s). En hardware, il aurait été possible de multiplier la vitesse par 10.
Il n’y a pas d’acquittement, pas de demande de répétition, ou de contrôle de flux de la part du récepteur (A2Z).


Interface SPI :
L’interface SPI maître sert (pour l’instant) uniquement à raccorder la mémoire Flash 16Mo externe au FPGA.
La configuration de l’interface est volontairement fixe, pour des raisons de simplification : les transferts se font sur obligatoirement sur 8 bits, et la fréquence est de 12.5MHz.
[F4HDK] utilise 2 shift registers : un pour la lecture (MISO) un pour l’écriture (MOSI).
L’adresse mémoire est volontairement identique pour la lecture (MISO) et pour l’écriture (MOSI) sur le port SPI, même si les buffers sont  physiquement différents ; ça permet d’économiser des instructions de changement d’adresse dans le code exécutable, et donc d’accélérer le tout.
Chaque écriture du CPU vers le périphérique SPI déclenche une « transaction » de 8 bits automatiquement sur le port SPI sans autre intervention (ça réduit le nombre d’instructions nécessaires). Donc le shift register de lecture se remplit aussi à chaque transaction 8 bits.

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Un bidouilleur français créé un ordinateur en partant de zéro : A2Z
« Réponse #3 le: 26 mai 2017 à 09:11:59 »
Chaîne de développement logiciel

Le compilateur est un compilateur croisé, tournant sur PC, qui digère du code A2Z_Basic et produit du code Assembleur. Il était hors de question de faire un « compilateur natif » (= qui puisse tourner sur A2Z lui-même), ça aurait été beaucoup trop complexe.



Le cheminement séquentiel du compilateur :
1 ) Stockage des lignes : On stocke le fichier source (A2Z basic) sous forme d’un tableau de lignes de code source (chaque ligne est une instruction ou déclaration séparée)
2 ) Configuration : On cherche la « directive » permettant de configurer l’exécutable : taille mémoire allouée au code et aux variables, et adresse mémoire de départ (l’exécution commence à une adresse fixe).
3 ) Fonctions, première passe : On balaye une première fois le code source, à la recherche des fonctions (subfonctions, fonctions ASM, et macros). Dans la pratique, on cherche la première (celle qui déclare la fonction) et la dernière ligne (endfunct) de chaque fonction. Pour chaque ligne de code, on identifie à quelle fonction elle appartient. La première fonction déclarée doit être le « main », et c’est la fonction qui sera exécutée en premier.
4 ) Gestion des #define : On remplace les définitions (#define ) par leur valeur réelle. C’est de la manipulation de chaine de caractères, rien de plus.
5 ) Déclaration des variables : On balaye une nouvelle fois le code source à la recherche des déclarations de variables. Pour chaque variable, on stocke ses caractéristiques (type, taille 1, taille 2), et la fonction à qui elle appartient. Une variable qui est déclarée en dehors d’une fonction est automatiquement considérée comme « globale » (fonction zéro).  On vérifie en même temps qu’il n’y a pas de doublon de déclaration (au sein d’une même fonction), et que la taille totale de RAM allouable n’est pas dépassée.
6 ) Allocation des variables : On alloue ces variables à l’espace RAM dédié (64ko maxi), de manière fixe.  Dans le même temps, les valeurs des constantes sont traitées.
7 ) Fonctions, 2ieme passe : Pour chaque déclaration de fonction (donc première ligne de la fonction), on recherche et on mémorise les entrées et sorties de cette fonction. Une fonction peut avoir plusieurs variables d’entrée et plusieurs variables de sortie. Ces variables doivent impérativement être déclarées à l’intérieur la fonction, donc elles doivent appartenir à la fonction.
8 ) Décodage des instructions : C’est la partie la plus lourde et la plus complexe. C’est la seule partie qui génère réellement du code exécutable. Une valeur qui peut être élaborée à partir d’une variable, d’une constante, d’un registre (ou cache), ou d’une opération arithmétique ou logique elle-même calculée à partir d’une combinaison de tout ça. L’analyse des expressions est récursive, ce qui permet de traiter des formules et conditions complexes. Le résultat de cette expression pourra servir à alimenter une variable, un registre (ou cache), un passage de paramètre à une fonction, ou une condition (if / while / for). Pour toutes les lignes d’instruction, on balaye le code source à la recherche des instructions, et on génère le code exécutable à la volée. On compte également à la volée la taille/position du code exécutable généré, ce qui permettra par la suite de savoir où faire les branchements = renvois d’exécution (renvoi conditionnel et inconditionnel).
9 ) Gestion des branchements = renvois : Pour tous les renvois (goto, for, next, if while) et appels de fonctions, on donne l’adresse RAM réelle (dans le code exécutable) vers laquelle renvoyer l’exécution. Ce n’est que maintenant qu’on peut le faire, car il faut auparavant avoir compté la position (dans le code exécutable) de chaque instruction.
10 ) Génération du fichier ASM : Le fichier ASM généré est une concaténation de 2 choses : le code exécutable, et les constantes.

Remarque : Il existe 3 types de fonctions différentes :
- Les « subf », des sous fonctions classiques, dont les appels et retours sont gérés dans la pile d’exécution.
- Les « ASMf », ou « fonctions ASM », même si elles peuvent contenir autre chose que du code ASM. C’est une fonction de dernier niveau, de bas niveau ; elle ne peut pas en appeler une autre. L’adresse de retour du programme n’est pas gérée dans la pile d’exécution, mais dans un emplacement fixe en Cache. Les appels et retours sont donc beaucoup plus rapides à exécuter. C’est très utile pour les fonctions appelées très fréquemment.
- Les Macros : code répétitif qui est remplacé tel quel dans le code exécutable.

Les différents types de fichiers manipulés :
- .bas : fichier code source basic
- .obj : fichier d’information sur les déclarations et allocations de fonctions et de variables (pour débug manuel)
- .asm : fichier assembleur
- .conf : fichier de configuration pour bin_generator : contient la taille et la position des données à transférer.
- .bina : fichier de donnée à transférer en RAM, utilise le protocole/format bootloader
- .bien : fichier exécutable à transférer en RAM, utilise le protocole/format bootloader
- .binc : concaténation de plusieurs bina/bine
- .bmpA2Z : format intermédiaire pour les images bitmap, telles que stockées en RAM


Le Basic A2Z_Basic

Le langage A2Z_Basic est inventé par [F4HDK] est volontairement différent de ce qui existe. D’abord pour le fun, mais aussi et surtout pour simplifier la vie au compilateur. La syntaxe ressemble à du C ou du Basic, mais en beaucoup moins riche.

Les détails sont sur http://f4hdk.free.fr/A2Z_computer/3_2_A2Z_basic.html

Anonyme

  • Invité
Un bidouilleur français créé un ordinateur en partant de zéro : A2Z
« Réponse #4 le: 26 mai 2017 à 23:17:49 »
Pour info,

Tutoriel pour la création d'un compilateur avec Lex et Yacc : (cliquez sur la miniature ci-dessous - le document est au format PDF)


Ce document explique comment construire un compilateur en utilisant Lex et Yacc.
Lex et Yacc sont des outils utilisés pour générer des analyseurs et des analyseurs lexicaux.


Source : http://epaperpress.com/lexandyacc/

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Un bidouilleur français créé un ordinateur en partant de zéro : A2Z
« Réponse #5 le: 27 mai 2017 à 08:07:34 »
Émulateur sur PC

[F4HDK] a développé un émulateur codé en C, qui tourne sous Windows mais qui est portable sur d’autres OS que Windows, avec des modifications mineures. Il permet de s’amuser facilement avec son projet, sans avoir à créer la carte électronique. Cela permet aussi de développer rapidement les applications A2Z, sans avoir besoin de les télécharger sur l’ordinateur réel.

C’est un émulateur « fonctionnel » qui cherche à imiter le comportement d’A2Z, sans forcèment simuler dans le détail les composants hardware d’A2Z. [F4HDK] nous dit que cette partie a été plus facile à coder que ce qu'il ne pensait.

Le bootloader n’est pas émulé dans l’émulateur. L’équivalent du bootloader côté émulateur est directement codé en C, et prend les mêmes fichiers que ceux envoyés par le port série.

L’émulateur respecte la vitesse du processeur réel, en exécutant 52083 instructions toutes les 16ms, puis en faisant une pause jusqu’à la fin des 16ms. Cela correspond à la fréquence de 12.5MHz du processeur (4 tops d’horloge par instruction).

Pourquoi exécuter des instruction toutes les 16ms ?  C'est pour correspondre au rafraîchissement à 60Hz des graphiques (idem VGA 60Hz).

Limitations :
- La mémoire Flash est émulée de manière très basique, toutes les subtilités n’ont pas été codées. Donc attention si vous recodez le bas niveau de la gestion de la Flash : ce qui fonctionnera dans l’émulateur ne fonctionnera peut-être pas en condition réelle.
- Le clavier émulé est un clavier français AZERTY. Ca fonctionnera mal avec un clavier QWERTY.

Vue de l'écran après le boot et après avoir appuyé deux fois sur la flèche vers le bas :


Guide d’utilisation de l'émulateur :

L’appel de l’émulateur à partir d’une fenêtre terminal (invité de commande windows) peut prendre des paramètres en option
- En l’absence de paramètres, l’émulateur va directement charger l’OS à partir de la Flash
- Les paramètres correspondent aux noms de fichiers bine, bina ou binc que vous voulez charger et exécuter. Attention, les fichiers sont chargés dans l’ordre d’apparition dans la ligne de commande. Si vous chargez plusieurs fichiers, il faut impérativement mettre le fichier exécutable en dernier.

En cours d’exécution, vous pouvez :
- F4 : mettre en pause
- F5 : reprendre l’exécution
- F7 : rebooter
- F9 : charger un nouveau fichier en RAM, comme le ferait le bootloader série. Cette fonction est utile notamment pour mettre à jour le contenu d’un fichier A2Z à partir d’un fichier bina bien ou binc de windows. La manipulation se fait dans l’OS A2Z.

Tous ces logiciels ont été conçus en C, pour fonctionner sous Windows, tout en étant un maximum portables. [F4HDK] fournis tout le code source et les exécutables.
- ZIP contenant toutes sources et exécutables du projet (open source)
- Microsoft Visual Studio 2013 redistributable package 32bits (nécessaire, même sur un Windows 10 64bits)

Les détails sont disponibles sur http://f4hdk.free.fr/A2Z_computer/

Il est possible de faire tourner cet émulateur Windows dans un autre émulateur :


vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Un bidouilleur français créé un ordinateur en partant de zéro : A2Z
« Réponse #6 le: 27 mai 2017 à 08:08:05 »
Système de fichier, explorateur de fichiers

Système de fichiers :

Le système de fichiers est très simple. Il est basé sur une FAT (file allocation table).
Chaque entrée de la FAT contient les informations suivantes :


L’index d’une entrée FAT, c’est tout simplement sa position dans la table de FAT.
La limite est de 1024 entrées FAT, c’est largement suffisant pour les 16 petits Mo.

Le système gère évidemment la structure arborescente du système de fichiers grâce au champ "folder".
Remarque : La FAT est la portion de la Flash ré-écrite le plus souvent. Chaque modification dans le système de fichier (déplacement d’un fichier, renommage, suppression) engendre une écriture de la FAT. Pour éviter d’écrire tout le temps sur les mêmes secteurs de la Flash (chaque secteur est limité à 200 000 écritures), [F4HDK] utilise un mécanisme d’emplacements de FAT tournants : 8 emplacements différents écrits à tour de rôle, avec un index permettant de déterminer l’entrée FAT la plus fraîche.
C’est un peu inutile vu la faible utilisation de cet ordinateur, mais ça m’amuse.
Vu la petite taille de la FAT (64ko), elle est constamment chargée en RAM.

Limitations :
- Le système ne gère pas la fragmentation des fichiers. S’il n’y a pas suffisamment d’espace contigu pour créer un nouveau fichier, le fichier ne sera pas créé.
- Un fichier a une taille fixe, déclarée une fois pour toute. La taille ne peut pas être modifiée à postériori



L’organisation de la flash 16Mo :



Interface homme machine – explorateur de fichiers :

[F4HDK] n'a pas voulu d’interface en « ligne de commande ». Il a codé une interface graphique/texte simple où l’utilisateur sélectionne les dossiers ou fichiers qu’il veut manipuler, avec les flèches du clavier, un peu à la façon de « Norton Commander ».



On peut réaliser toutes les fonctions basiques d’un explorateur de fichiers : couper, copier, coller, renommer, créer un dossier, un fichier, etc...

On peut aussi « ouvrir » un fichier, ce qui va déclencher :
- Pour un programme : chargement du programme en RAM et exécution du programme
- Pour un fichier de type texte ou image : l’OS ouvre le « programme par défaut » de gestion des images ou du texte, qui à son tour va ouvrir le fichier en question.

Attention, pour trouver le programme de gestion du texte et des images, les fichiers exécutables des programmes utilisés doivent impérativement avoir l’index FAT suivant, car c’est ce qu’utilise A2Z_OS
- Text Editor : index 2
- Image viewer : index 3



Dans le menu, une commande particulière permet de « raffraichir  / télécharger » le contenu du fichier depuis le PC vers la flash, de 2 manières différentes  (choix proposé 1 ou 2):
- Choix 1 Sur A2Z réel : depuis la liaison série, avec le même protocole que le bootloader. Attention, tous les fichiers téléchargés doivent se terminer par une commande bootloader « goto », qui sert juste à détecter la fin du transfert, et ne sera pas exécutée. Donc après le transfert via port série d’un fichier bina, il faut rajouter le fichier « goto.bien » qui fait le job.
- Sur l’émulateur : depuis fichier windows bina, bien ou binc.

Le transfert du fichier se fait via la fonction F9 de l’émulateur.
Attention, le transfert doit impérativement être effectué avant de valider la sélection « choix 2 » dans l’OS.


OS ou pas OS ?

Ce n’est donc pas un véritable système d’exploitation, car il n’y a aucune couche d’abstraction hardware. Chaque application embarque ses drivers pour accéder directement au hardware (drivers mémoire SPI par exemple), et est donc relativement indépendante d’un OS.

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Un bidouilleur français créé un ordinateur en partant de zéro : A2Z
« Réponse #7 le: 27 mai 2017 à 08:12:57 »
Application N°1 : Éditeur de texte

L’éditeur texte permet le scrolling vertical, le comptage des lignes, le retour à la ligne automatique sans coupure de mot.

2 touches de fonction :
- Sauvegarder le fichier en cours : F10
- Quitter : F12



Limitations :
- La fonction copier-couper-coller n'est pas encore implèmentée.
- La taille des fichiers est limitée à 50ko
- L’éditeur texte en lui-même ne sait pas créer de fichier, ni sauver un fichier sous un autre nom. Il ne sait tout simplement pas manipuler la FAT.  Ces manipulations doivent donc être effectuées dans l’OS, avant ou après avoir édité le contenu.



C’est le logiciel que [F4HDK] a codé en premier, cela a permis de développer et débugger toute la gestion de texte, la gestion du clavier (interprétation des codes clavier PS/2) qui est relativement complexe.



vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Un bidouilleur français créé un ordinateur en partant de zéro : A2Z
« Réponse #8 le: 27 mai 2017 à 08:19:01 »
Application N°2 : Visionneuse photo

C'est un logiciel très simple, qui affiche les images à l’écran, et qui peut faire défiler les images parmi celles contenues dans le dossier à partir duquel on a ouvert la première image.

Les transitions entre images sont réalisées à l’aide du double buffering : on dessine une image pendant qu’une autre est affichée. Sur ordre du logiciel, le basculement d’une image à l’autre se fait entre 2 balayages d’écran.

Démarrer l'application directement va afficher un message d’erreur :


La méthode est de ne pas ouvrir l’application mais un fichier image.

Il y en a plusieurs dans l'émulateur :


Bien sur on est limité a la résolution 640 x 480 et surtout les 256 couleurs avec une palette fixe (il n'est pas possible de choisir les 256 couleurs dans une palette de 65536 couleurs)


vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Un bidouilleur français créé un ordinateur en partant de zéro : A2Z
« Réponse #9 le: 27 mai 2017 à 08:21:45 »
Application N°3 : Visionneuse de carte

C'est un peu plus complexe que pour une photo.

Une carte IGN de 7Mo est présente dans l'émulateur, découpée en dalles de 256x256 pixels.

Pour chaque mise à jour de position visualisée (à l’aide des flèches), le logiciel détermine la liste de dalles à afficher, puis dessine les dalles déjà en mémoire RAM vers le frame buffer caché,  puis commute le double buffering, et enfin il charge les éventuelles dalles manquantes depuis la Flash vers la RAM, et les affiche à leur tour vers le frame buffer affiché.



On comprend mieux avec la vidéo :


vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Un bidouilleur français créé un ordinateur en partant de zéro : A2Z
« Réponse #10 le: 27 mai 2017 à 08:32:21 »
Application N°4 : Le jeu micromachines

C’est un jeu de voiture vu de dessus, style micromachines.



C’est, de loin, l’application la plus sympa, et celle qui montre le mieux les capacités graphiques de A2Z.

Touches clavier :
- Flèche droite / flèche gauche : direction
- A : accélérateur / Q : Frein et marche arrière
- F12 : quitter



Avec une fréquence CPU de 25MHz, avec une répartition 50% / 50% entre cœur et VGA, donc un équivalent d’un cœur à 12MHz, on est limité à jouer dans une fenêtre de 320x240 pixels.

Le terrain/le circuit est créé à partir de dalles. Les dalles graphiques et les dalles formant les obstacles n’ont pas la même taille :
- 64x64 pixels pour les obstacles
- 128x128 pixels pour le fond graphique du circuit

Les matrices de dalles sont des tableaux 2D de 40x40 ou 80x80.
 
Le circuit est conçu sur papier:


Les textures utilisées :



Si vous souhaitez en savoir plus, je vous invite a aller sur son site http://f4hdk.free.fr/A2Z_computer/

Il est possible de contacter son auteur via f4hdk [at] free.fr
Il lit aussi ce forum.

trekker92

  • Abonné Free adsl
  • *
  • Messages: 806
Un bidouilleur français créé un ordinateur en partant de zéro : A2Z
« Réponse #11 le: 27 mai 2017 à 16:28:42 »
holy shit...

ce qu'il a inventé doit ressembler à ce qu'apple et ibm avaient dans leurs sous sol dans les années 80/90.. et je suis persuadé que ca reste dans leurs archives...

niveau industriel, ca doit pouvoir trouver son utilisation dans les applications basiques et fiables..

mais c'est clair qu'il a pas du y passer qu'un an.. concevoir du circuit imprimé au logiciel..

allez dix ans supplèmentaires et il nous sort un iphone opensource :) :) ;)

ps: moulte petites ent francaises ont essayé de commercialiser un ordi made in france.. mais pas en allant concevoir chaque composant à ce point..waoh