Sommaire
- Le contexte
- Les options existantes
- Le cahier des charges
- Nouvelles générations de composants
- Le logiciel
- Prochaines étapes
Bonjour!
Ce week-end j'ai construit un micro ordinateur. Je vous le présente.
Le contexte
Les micro ordinateurs (appelés parfois simplement "micros") sont apparus dans les années 1970. Ils sont nommés ainsi car ils sont plus petits que les mini ordinateurs, qui eux même sont plus petit que les ordinateurs de l'époque, qui occupaient à peu près l'espace nécessaire aujourd'hui à un supercalculateur.
En ce qui me concerne, j'ai pas mal utilisé un Amstrad CPC 6128 (plusieurs, en fait) quand j'étais plus jeune. Cette machine m'a permis de faire mes premiers pas en programmation BASIC, puis par la suite de me mettre à l'électronique pour réaliser plusieurs cartes d'extension (port USB, mémoire RAM et Flash, cartes son, …).
Il s'agit d'une machine relativement simple et sur laquelle on peut programmer en "bare metal": sans système d'exploitation et en adressant directement les composants électroniques. Le matériel est fixe et inchangé depuis longtemps et assez bien documenté aujourd'hui.
Dans l'informatique moderne, on ne parle plus trop de micro-ordinateur, le terme est passé de mode. Mais surtout, il existe peu de matériel aussi simple, ou alors, c'est très proche de ce qui se faisait dans les années 80: processeurs 8 bit ou 16 bit, quelques kilo-octets de mémoire, des composants assez peu compacts.
On trouve sinon des machines comme les Raspberry Pi (mais il y en a plein d'autres), qui proposent un matériel unifié et moderne, mais plutôt complexe à programmer en direct: l'utilisation d'un système d'exploitation est donc indispensable, et on perd l'intérêt (à mon avis) d'une machine simple sur laquelle on peut comprendre tout le fonctionnement, de l'électronique jusqu'au logiciel haut niveau.
Les options existantes
Quelques exemples de machines qui sont plus ou moins dans cet esprit:
- La plateforme RC2014 est une carte de base avec plusieurs ports interconnectés, sur laquelle on peut assembler des modules CPU, RAM, et autres cartes d'extension diverses. La version initiale utilise un processeur Z80 mais de nombreuses alternatives sont disponibles. On reste sur un systme 8 bit, minimaliste par rapport à la concurrence dans ce domaine, mais nécessitant tout de même un certain nombre de composants électroniques pour fonctionner (surtout si on veut y ajouter un écran et un clavier, par exemple)
- Des consoles basées sur les processeurs Atmel AVR8, comme la Gamebuino ou l'Arduboy. Ce sont plutôt des consoles de jeu et les capacités de la plateforme sont plutôt limitées (et souvent moins bonnes que les ordinateurs des années 80).
- Des systèmes comme l'Agon Light, qui propose un processeur eZ80 (un descendant du z80) et des capacités graphiques et sonores intéressantes, mais qui les implémente à l'aide d'un coprocesseur ESP32 plus puissant et rapide que le processeur principal, ce qui est tout de même dommage,
- Des ordinateurs comme le Mega 65 ou le ZX spectrum Next. Dans ce cas, l'idée est d'utiliser des FPGA (composants reprogrammables) pour implémenter une version améliorée d'ordinateurs existants. On retrouve donc les "sensations" d'un micro ordinateur des années 80, mais en réalité le matériel est beaucoup plus flexible (on peut d'ailleurs souvent le reprogrammer pour faire tout autre chose). De plus, le prix me semble excessif.
- Des machines comme le Raspberry Pi qu'on ne présente plus: elles sont peu coûteuses, mais le matériel est complexe et nécessite l'assistance d'un système d'exploitation et parfois de blobs binaires dont on ne sait pas trop ce qu'ils font.
Le cahier des charges
Aucune de ces solutions ne me convenant vraiment (et puis, j'avais envie de construire quelque choise moi-même), cela fait quelques temps que je surveille de temps en temps ce qu'il se fait dans les familles de microcontrôleurs et de systems-on-chips.
En effet, les ordinateurs des années 80 étaient construit à partir d'un "chipset", un ensemble de puces (parfois conçues par le même fabricant pour fonctionner ensemble, parfois un assemblage plus ou moins hétéroclyte). Mais aujourd'hui, l'électronique est beaucoup plus miniaturisée et ça ne devrait poser aucun problème d'avoir tout l'ordinateur dans une seule puce.
Les premiers exemples d'une telle intégration sont les "personal digital assistants", dont par exemple les machines de chez Palm, qui étaient basées au départ sur un composant Motorola Dragonball, regroupant un processeur Motorola 68000, un contrôleur d'écran, et divers autres composants (ports série, entrées/sortes pour quelques boutons, …). Cependant, sur ces composants, la mémoire reste un composant externe. Il faut donc un minimum de 3 puces pour réaliser un système complet: le system-on-chip, la RAM, et de la ROM ou mémoire flash permettant d'initialiser le système. De plus, on quitte le monde des systèmes 8 bit, et on se retrouve donc avec un bus d'adresse et un bus de données sur 32 bits chacun. Cela signifie un grand nombre de connexions (plus d'une soixantaine) entre ces 3 composants.
D'un autre côté, on trouve aujhourd'hui des familles de microcontrôleurs qui se rapprochent de la même idée mais intègre de la mémoire directement dans la même puce. Par conséquent, il ne reste que les entrées-sorties à connecter. Le système s'en trouve grandement simplifié. Mais, il y a un souci: ces composants sont conçus pour des utilisations où ils sont programmés une fois, avec un système fixe, puis installés dans des systèmes embarqués. En prévoyant au mieux quelques mises à jour de firmware. Le matériel est adapté à cette utilisation avec une RAM qui plafonne à quelques centaines de Kilo-octets, et par contre une mémoire flash relativement importante (on trouve facilement des composants avec 1Mo de mémoire flash). Parfois, il n'est même pas possible d'exécuter du code chargé en RAM, ou bien, si on peut le faire, son exécution est plus lente que l'exécution depuis la mémoire Flash.
Un exemple d'un tel système est la console Bitbox, qui prend le parti d'utiliser un "bootloader" qui va charger un programme depuis une carte SD, l'enregistrer dans la mémoire flash, puis l'exécuter. Une autre particularité de la Bitbox est d'utiliser un composant qui n'a pas de contrôleur d'écran intégré, la génération des signaux pour un écran VGA se fait donc par une utilisation astucieuse de timers et de canaux DMA pour envoyer les données à l'écran à la volée. Ceci permet une grande flexibilité de l'affichage, mais demande une programmation spécifique (il faut préparer le DMA pour envoyer les bonnes données à chaque ligne de l'écran), un peu similaire à la façon dont on pouvait programmer par exemple une console de jeux Atari 2600. La console Bitbox est fournie avec un SDK qui peut prendre en charge cette programmation et fournir un "framebuffer", cependant, la quantité de mémoire fait qu'on ne peut pas utiliser la résolution d'écran maximale avec un framebuffer. De plus, toute cette programmation consomme un pourcentage non négligeable des cycles CPU disponibles, ralentissant la machine. Le résultat est plutôt bon et certains jeux tirent assez bien partie de ces contraintes, on peut par exemple facilment programmer un mode texte ou un mode graphiques à base de tuiles et de sprites, comme ce qu'on trouve sur une console de jeu NES ou Megadrive.
J'avais installé ma Bitbox avec un petit écran VGA dans un étui pour tablette avec clavier USB, pour me fabriquer un genre d'ordinateur portable. Mais, il restait difficile de l'utiliser comme un ordinateur à proprement parler, à cause du système fonctionnant principalement en mémoire Flash.
Nouvelles générations de composants
Une évolution relativement récente est l'apparition de composants de type system-on-chip qui embarquent leur propre mémoire. Il s'agit cette fois non plus de mémoire statique comme dans les microcontrôleurs, mais de mémoire RAM DDR comme on en trouve sur nos ordinateurs classiques.
Cela permet enfin d'avoir des performances acceptables (mémoire RAM rapide permettant d'exécuter du code avec un CPU fonctionnant à plus de 1GHz) tout en gardant une conception de carte électronique simple. Il est possible de trouver de tels composants en boîtiers "QFP", ce qui signifie que toutes les connexions se font autour du composant, contrairement aux "BGA" ou les connexions se font sous toute la surface du composant. Ce changement de boîtier a deux conséquences: les systèmes BGA nécessitent un circuit imprimé à 4 couches ou plus, sinon il est impossible de faire passer toutes les pistes nécessaires à tout connecter. Et d'autre part, avec un boîtier QFP, il est assez facilement envisageable d'assembler soi-même une carte électronique avec du matériel assez simple (il faudra un pistolet à air chaud tout de même).
La partie haute fréquence du composant (l'interconnexion entre le CPU et la RAM) restant en interne, on peut réaliser le reste de la carte électronique sans trop rencontrer de problèmes.
Mon choix s'est porté sur le composant Allwinner V3s, et pour simplifier encore les choses, sur le module Lichee Zero qui fournit ce composant déjà assemblé sur une petite carte électronique avec les régulateurs de tension nécessaires et le minimum de connectique (un emplacement pour carte SD et un port USB).
Ce composant propose un processeur ARM simple coeur à 1.2GHz et 64Mo de RAM. C'est suffisant pour faire tourner un système Linux minimaliste, par exemple.
J'ai ensuite conçu une carte électronique servant de "base" à ce module pour avoir la connectique supplémentaire: VGA, Ethernet, USB, et une sortie son, ainsi qu'un port d'extension pour ajouter d'autres choses plus tard.
Le montage du Lichee Zero n'est pas aussi simple qu'il pourrait l'être: toutes les entrées-sorties sont sur le bord du module, en principe, on pourrait poser le module sur un autre circuit et le souder. Mais, le concepteur du Lichee Zero l'a rempli de composants électroniques sur ses 2 faces, donc ce n'est pas possible de procéder ainsi. Il a donc fallu prévoir un trou dans le circuit imprimé pouvant accueillir le module, tout en calculant juste pour que les "pads" de soudure ne soient pas trop éloignés.
Je l'ai ensuite installé à la place de la Bitbox dans mon étuit de tablette et connecté à l'écran VGA:
Le composant Allwinner V3s est assez bien pris en charge par les versions mainline de U-Boot et de Linux, de façon suffisante en tout cas pour arriver à démarrer le système depuis la carte SD.
Le logiciel
J'ai utilisé OpenEmbedded pour compiler facilement un système Linux minimaliste d'une vingtaine de Megaoctets. OpenEmbedded fait tout le travail de compilation de toolchains, de configuration du noyau, et de génération du système de fichier et de l'image de carte SD bootable. Il n'y a plus qu'à écrire l'image résultante sur une carte SD.
Je me suis pour l'instant concentré sur le bon fonctionnement de U-Boot sans trop toucher au système Linux. En particulier j'ai du récupérer des patchs pas encore intégrés dans la version officielle de U-Boot pour:
- L'affichage sur l'écran. Le composant V3s fournit une sortie de type "LCD parallèle". Je l'utilise avec quelques résistances judicieusement choisies (pas par moi, j'ai recopié un schéma existant d'un autre projet) pour obtenir un signal VGA. En plus des patchs, il faut ajuster le device tree (le fichier qui décrit le matériel présent) pour indiquer les timings à utiliser pour piloter l'écran (ceux qui ont manipulé les modelines pour X11 voient un peu le genre de choses à faire).
- L'USB et l'ethernet. Le support est en fait déjà présent dans U-Boot car les mêmes composants matériels sont utilisés par d'autres puces de chez Allwinner. Cependant, il y a un petit peu de "câblage" à faire pour que U-Boot établisse la correspondance entre ce qui est déclaré dans le device tree, les pattes du composant, et les drivers correspondants. Il a fallu également écrire un device tree pour ma carte électronique indiquant que oui, j'ai bien mis un port USB et un port Ethernet aux endroits prévus sur ce composant.
Voilà où on en est pour l'instant.
Prochaines étapes
Je ne sais pas si je vais conserver Linux sur ce système. Rien qu'avec un shell busybox et pas grand chose d'autre, environ la moitié de la RAM est déjà utilisée. Mais je ne sais pas encore quel autre système pourrait être intéressant.
Depuis le moment où j'ai commencé ce projet, la situation a évolué et de nouveaux composants sont disponibles. Par exemple, le Allwinner V3x qui dispose de 128Mo de mémoire, ou le T113 qui a lui aussi 128Mo de RAM, et en plus, un CPU à deux coeurs.
L'augmentation des capacités de ces composants tout-en-un va probablement se poursuivre. Il n'est pas impossible que d'ici quelques années on les trouve utilisés dans des smartphones qui seront ainsi moins chers et plus légers.
Pour ma part, je pense que j'ai déjà de quoi m'occuper avec cette carte électronique pour développer le logiciel permettant de l'utiliser confortablement. Cependant, si c'était à refaire:
- Mettre un bouton ON/OFF permettant de couper l'alimentation du CPU. Actuellement, il est alimenté par un port USB-B qui sert aussi à l'UART de debug, et la seule façon d'éteindre la machine est de tout débrancher. Ce qui n'est pas pratique quand on veut accéder aux logs sur le port série pendant le démarrage.
- Envisager l'utilisation d'un composant V3x ou T113 et faire assembler toute la carte directement par le fabricant du PCB, cela m'évitera de griller des cartes ou des composants en m'essayant à la soudure au pistolet à air chaud
- Il devrait être possible de concevoir une carte s'associant bien à un écran entre 3 et 4", et d'imprimer en 3D un boîtier pour le tout, pour se fabriquer un PDA de type Palm. Il faudrait cependant ajouter de quoi contrôler la charge d'une batterie, ainsi qu'une possibilité de connexion wifi?
# J'ai oublié
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 7.
Dans la liste des choses à améliorer:
[^] # Re: J'ai oublié
Posté par totof2000 . Évalué à 3.
Pourquoi faire simple quand on peut faire compliqué ? un hub USB externe ? :)
Je plaisante, je comprends le problème que tu évoques (plus pratique d'avoir quelques ports sur la carte plutôt que d'utiliser un hub externe), mais dans l'absolu, pour une première version, ce n'est absolument pas un problème.
[^] # Re: J'ai oublié
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
oui, c'est ce que je vais faire pour cette première version (ou alors je peux utiliser un clavier avec un hub USB intégré). Mais avoir un clavier + une souris + un port de libre pour le reste serait pas mal.
Et le hub USB est plus gros que l'ordinateur, ce qui est un peu dommage :)
# modules format SODIMM ?
Posté par totof2000 . Évalué à 4.
J'avais pensé à un moment faire ce genre de truc (mais manque de temps). PAr contre je pense que je me serais basé sur un module SODIMM. On trouve par exemple ceci mais il doit en exister d'autres ( exemple : Raspberry Pi Compute Module 4S.
[^] # Re: modules format SODIMM ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
Oui, si on veut utiliser un system-on-module, c'est le plus logique de prendre un module de ce type.
L'idée au départ était de faire une carte mère complète avec juste le composant dessus, mais finalement je n'ai pas trouvé de truc très facile à souder (là, c'est possible, mais l'espacement entre les pins est trop fin pour le faire au fer à souder classique).
Par contre ça devrait être possible de faire assembler la carte par un fabricant qui propose ce service, et à un coût assez faible même en petits volumes.
[^] # Re: modules format SODIMM ?
Posté par totof2000 . Évalué à 3.
J'avais fait les mêmes recherches, et j'en suis arrivé à la même conclusion que toi.
L'inconvénient c'est que si tu te plantes, c'est difficile de rectifier en déssoudant et récupérant les composants sur une autre carte :(. En plus de ça il y a aujourd'hui, avec les fréquences élevées des CPU modernes, des contraintes dans le routage des pistes pour éviter les parasites.
[^] # Re: modules format SODIMM ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
Je pense que ça se fait avec un pistolet à air chaud sur ces puces mais je n'ai pas essayé (je l'ai fait avec des composants avec un écartement de pattes un petit peu plus large, genre 0.8mm au lieu de 0.6).
Pour les fréquences, l'intérêt de ces puces avec la RAM intégrée c'est justement que toute la partie haute fréquence est entièrement contenue dans une seule puce. Donc, pas de problèmes de routage pour ce qui reste. Sauf si on veut faire de l'USB 3, de l'Ethernet Gigabit, une sortie vidéo en haute résolution (l'Allwinner V3s ne va pas au-delà de 1024x1024 pixels de toutes façons, ce qui est déjà pas mal), etc.
[^] # Re: modules format SODIMM ?
Posté par totof2000 . Évalué à 3.
Peut-être que ce genre d'adaptateur pourrait aider ? Je m'étais orienté vers ce type de composant lors de mes recherches.
[^] # Re: modules format SODIMM ?
Posté par cg . Évalué à 2.
Pour les tout petits composants, il y a la technique de mettre de la soudure sur toutes les pattes du composants en un coup, sans se soucier des courts-circuits, puis de venir absorber ce qui est en trop avec de la tresse à dessouder (desordering braid, qu'on peut substituer par du fil de cuivre multibrin fin). C'est un peu bourrin mais ça ne demande pas de matériel très spécifique. Il faut ensuite vérifier au testeur de continuité + loupe.
Par contre, c'est beaucoup plus facile sur une carte vernie fabriquée en usine : sur les cartes faites à la maison, les traces sont moins nettes et le cuivre "accroche" un peu, c'est moins facile et ça finit souvent en arrachant les pistes :-/.
[^] # Re: modules format SODIMM ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
Ça marche bien avec les composants qui ont des pattes assez rigides pour ne pas être endommagées en utilisant de la tresse à déssouder.
Personellement j'ai de meilleurs résultats avec:
Avec ça je soude sans problème des composants avec des pattes espacées de 0.8mm.
Mais là pour l'Allwinner V3s on est su un espacement de 0.5mm, ça devient plus compliqué, et en plus, il y a quand même pas mal de pattes donc le risque de court circuit devient plus important.
Le pistolet à air chaud permet en principe de faire ça:
Le matériel n'est pas beaucoup plus compliqué et pas très cher (et j'en ai déjà un que j'utilise pour déssouder les composants montés en surface, ce qui ne se fait pas vraiment avec un fer à souder classique).
Je n'ai pas encore testé cette méthode de la pate à souder, donc je ne sais pas à quel point c'est facile.
[^] # Re: modules format SODIMM ?
Posté par cg . Évalué à 2.
Ah pardon je n'avais pas compris que tu avais déjà le matériel. Avec de la pâte à braser ça fonctionne bien, avec un fer, une station à air chaud ou paraît-il plaque chauffante (on en trouve des thermostatiques pas trop chères maintenant, mais j'ai pas essayé).
Par contre la pâte à braser se conserve mal, normalement il faut la laisser au frais, et dans le frigo avec la bouffe c'est moyen, faut vraiment bien l'emballer.
# Cahier des charges
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Quel serait l'usage de ce microordinateur? A part le plaisir de le construire bien sûr.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Cahier des charges
Posté par vincent LECOQ (site web personnel) . Évalué à 5.
Je vois bien un truc à faire, mais je suis sûr qu'il y pense déjà:
[^] # Re: Cahier des charges
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
Pour Haiku, il n'y a pas assez de RAM :(
(essayer de le faire rentrer tout de même pourrait être intéressant, mais ce serait plus envisageable avec une puce contenant 128Mo…)
# Vers un "microcontroller" qui fait tourner linux ?
Posté par Aldebaran (site web personnel) . Évalué à 1.
Super projet félicitation !
J'aime beaucoup le côté soviétique de l'ensemble, je ne savais pas qu'on pouvait passé d'une sortie parallèle à vga aussi simplement, c'est du génie ! (c'est cette bidouille qui t'as servit ? https://olimex.wordpress.com/2012/06/12/low-cost-lcd-to-vga-adapter/)
Ça consomme combien au final (j'ai noté un schéma d'alimentation assez complexe) ?
[^] # Re: Vers un "microcontroller" qui fait tourner linux ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
C'est le même principe, oui.
Je me suis inspiré de la sortie VGA de la Bitbox et aussi de schémas d'autres projets à bases de puces Allwinner, j'ai découvert le forum https://whycan.com ou il y a plein de gens avec des projets de ce type (il faut utiliser un traducteur automatique pour naviguer, si on ne lit pas le chinois simplifié).
Mon implémentation va vraiment au plus simple: la sortie LCD du chip est directement branchée via quelques résistances sur le port VGA. Olimex a été un peu plus précautionneux avec un composant qui sert de "buffer", ce qui est probablement une bonne idée.
Ils ont aussi fait une conversion de niveau pour transformer le 3.3V en 5V pour les synchros horizontales et verticales, avec mon écran en tout cas ça ne semble pas nécessaire, la synchro à un niveau 3.3V est bien détectée.
Pour faire fonctionner le tout, il faut ensuite une "modeline" appropriée dans le device tree. Il faut définir les timings et ceux recommandés pour connecter directement une dalle LCD ne fonctionnent pas, ils utilisent une synchro horizontale beaucoup plus courte (une optimisation par rapport au VGA, qui prévoit le temps pour le faisceau d'électrons d'un écran cathodique de faire tranquillement son retour à la ligne…)
Il est également possible de générer avec une petite modification (et des timings différents) un signal RGB pour un connecteur péritel. Pour cela il faut ajouter une porte logique XOR entre les sorties HSYNC et VSYNC pour générer un signal de synchronisation unique.
Pour le HDMI (et le DVI, c'est pareil) c'est plus compliqué, il faut un HDMI transmitter comme par exemple celui ci: https://datasheet.lcsc.com/lcsc/1912111437_Lattice-SiI9024ACNU_C369574.pdf (j'en avais repéré un qui peut se souder à la main, mais je le retrouve plus).
Ou sinon, choisir une des puces Allwinner plus récentes qui propose directement une sortie HDMI, ça devient trop facile. Je ne sais pas s'il existe des ports HDMI facile à souder cela dit, mais on peut au pire se rabattre sur le DVI qui lui ne devrait pas poser trop de problème.
Pour le DisplayPort, je n'ai pas cherché, je n'ai pas d'écran compatible :)
# UXN ?
Posté par rakoo (site web personnel) . Évalué à 3.
Super projet dis donc !
Dans les micro-systèmes d'exploitation, un développeur sympathique a imaginé une stack qui s'appelle UXN, c'est une machine virtuelle qui est très facilement implémentable sur de très nombreuses architectures puisqu'il y a un nombre restreint d'opérations. Grâce à l'émulation une application tournera identiquement sur toutes les architectures: il y a par exemple un éditeur de texte (https://100r.co/site/left.html), une application de dessin (https://100r.co/site/noodle.html), et même un OS, potato (https://wiki.xxiivv.com/site/potato.html). Ça pourrait être des cibles intéressantes.
[^] # Re: UXN ?
Posté par fabricius . Évalué à 1.
UXN! J'ai pensé à la même chose. Pour ceux qui ignorent ce que c'est, un journal en parle très bien. En plus on retrouve un peu le coté "root" de la programmation d'il y a quelques décennies. Voir par exemple un effet un peu "demomaker" ici: My second attempt at Uxntal. Si vous etes curieux le code est ici.
[^] # Re: UXN ?
Posté par totof2000 . Évalué à 3.
Et pourquoi pas implémenter un environnement forth ?
# Années 80 avec 64 Mio de RAM ?
Posté par Christophe "CHiPs" PETIT (site web personnel) . Évalué à 3.
J'ai tendance à considérer que si ça fait tourner (GNU/)Linux, c'est trop puissant pour être comparable à une évolution des micros des années 80 ;-)
Je réfléchis, sans avoir toutes les connaissances techniques, à quelque chose à base de Raspberry Pi Pico (1 ou plusieurs), cf. https://github.com/CHiPs44/YetAnotherPicoComputer (en anglais), mais c'est vrai que 512 Kio ou 1 Mio seraient mieux que 256 pour se rapprocher d'un Atari ST ou d'un Amiga…
Je suis avec intérêt les avancées de Jonathan Pallant en Rust sur https://github.com/Neotron-Compute/.
[^] # Re: Années 80 avec 64 Mio de RAM ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5.
Je n'ai pas trouvé de composant tout-en-un avec 512Ko à 2Mo de RAM. Il faut donc choisir: faire un peu plus petit, ou un peu plus gros. Et les offres côté "plus petit" ne manquent pas.
Par contre j'ai un autre projet pour… plus tard… qui est de réécrire un OS pour l'ordinateur VTech Le Manager. C'est un proceseur 68000 (Dragonball pour être précis) avec 1 ou 2Mo de RAM.
Cela dit, il peut aussi faire tourner Linux
[^] # Re: Années 80 avec 64 Mio de RAM ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Les produits vtech sont sympathiques pour les enfants, mais fermés et privateurs.
A quand un microordinateur pour enfant à base d'Haiku ? :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Années 80 avec 64 Mio de RAM ?
Posté par Christophe "CHiPs" PETIT (site web personnel) . Évalué à 1.
Peut-être qu'il n'était pas sorti au moment de ta recherche, mais l'ESP32-S3 a 512 Kio de RAM interne, des versions avec 8 Mio de PSRAM supplémentaires en OctalSPI, et bitluni s'est bien amusé avec récemment : https://github.com/bitluni/ESP32-S3-VGA.
[^] # Re: Années 80 avec 64 Mio de RAM ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
Il n'a pas de contrôleur d'écran, ce qui oblige à en implémenter un en logiciel et canaux DMA/timers. C'est intéressant aussi (et je me suis bien amusé avec ça sur la Bitbox grâce au travail de Makapuf qui avait mis tout le nécessaire en place), mais si le but est de faire une machine facile à programmer en "baremetal", je pense que ce n'est pas le mieux. Par contre c'est plus flexible.
Cela dit, chacun peut construire ce qu'il veut avec le matériel de son choix :)
Et il y a d'autres solutions, par exemple j'ai envisagé un écran eInk, mais ça reste un peu cher pour l'instant et les écrans couleur ont un rafraîchissement beaucoup trop lent (30 secondes sur un écran de taille acceptable pour ce que je voulais faire). Mais peut-être dans quelques années…
[^] # Re: Années 80 avec 64 Mio de RAM ?
Posté par Yves (site web personnel) . Évalué à 1.
Et pourquoi donc ? Pour autant que je sache (je n’ai pas essayé, ayant à cette époque trouvé mon bonheur avec Mint-pas-Linux), il était possible de faire tourner Linux sur Atari STE.
# J'ai hâte de voir la suite.
Posté par Luc-Skywalker . Évalué à 1.
J'avoue que l'adaptateur LCD => VGA à coup de simples résistances, c'est assez bluffant. Mais j'imagine que cela peut tourner au cauchemar (valeurs des résistances, timings, rédaction du device tree …) et peut être qu'un oscilloscope ou un analyseur logique est indispensable pour déboguer tout ça.
Tu as eu besoin de l'un de ces appareils ?
Tu peux utiliser des connecteurs mâles et femelles pour te passer du trou dans le PCB ;-)
Pour ma part, j'en suis encore au stade débutant vaguement avancé au niveau électronique. Mais l'idée d'un micro fait maison me chatouille depuis quelques temps et j'en suis arrivé à me dire que le SOM LicheePi RV D1 et son Dock seraient une bonne base de départ pour moi.
Le DOCK, pour voir ce que l'on peut espérer du système fourni et le SOM qui est capable de fonctionner de manière autonome (il dispose d'un accès à une console série qui peut servir d'alimentation +5V) et permet de brancher un écran SPI.
Le tout pour environ 30$ chez Ali en version 512M.
L'autre option envisagée: une carte au format Raspberry Pi Zero. Moins aventurier, moins minimal mais sans doute moins galère (La BananaPi M2, la Radxa Zero sont dispo chez Armbian avec un noyau récent).
Au final, pour le moment, je préserve mes ressources et la planète !
Quelques unes de mes inspirations:
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: J'ai hâte de voir la suite.
Posté par Luc-Skywalker . Évalué à 1. Dernière modification le 06 septembre 2023 à 13:34.
Un vrai ordi DIY, "à 15$", à base d'Allwinner f1C100s
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: J'ai hâte de voir la suite.
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
Bonjour, j'avais raté ce commentaire.
Oui, un oscilloscope est utile, en particulier pour vérifier la configuration et les timings de la synchronisation horizontale et verticale (qui se configure depuis le device tree mais la documentation de linux-sunxi.org n'est pas à jour, j'ai du creuser un peu dans le code du pilote dans Linux). Le mien est un vieux truc à écran cathodique encombrant et qui ne fait que le minimum. Mais on doit trouver maintenant des oscilloscopes numériques qui feront assez bien le travail pour ce genre de choses.
Pour les choix de valeurs de résistances, j'ai surtout regardé ce que faisaient d'autres projets similaires, puis j'ai pris les résistances plus ou moins proches que j'avais en stock. Avec cette méthode je suis sûr d'être à peu près aux bonnes valeurs. Donc il n'y a pas trop de risque d'endommager le composant, juste d'avoir des couleurs "deformées" à l'écran.
Je précise aussi que je n'en suis pas à mon coup d'essai: j'avais écrit du code pour la bitbox qui utilise le même genre de système, j'ai fait du développement sur Amstrad CPC, machine où on joue pas mal avec le composant contrôleur vidéo pour plein de raisons, et j'ai aussi développé quelques morceaux de pilotes graphiques pour Haiku. Donc avec tout ça, j'ai une assez bonne compréhension de à quoi ressemble un signal VGA, ça aide bien!
[^] # Re: J'ai hâte de voir la suite.
Posté par Luc-Skywalker . Évalué à 1. Dernière modification le 09 septembre 2023 à 16:01.
Merci pour ta réponse.
C'est évident que je suis loin d'avoir tes compétences. Donc je reste très prudent.
L'oscilloscope, ce sera pour plus tard ;-)
J'ai trouvé ce produit sur Aliexpress: une carte LicheePi Nano vendue avec un écran LCD pour une vingtaine d'euros. A mon niveau, cela me semble plus "abordable".
Mais c'est 32M de RAM et 16M de mémoire QSPI seulement (Allwinner F1C100s ). Je ne sais pas trop ce que l'on pourrait espérer en terme d'utilité/performaces, tes retours ne semblant pas très positifs.
"Si tous les cons volaient, il ferait nuit" F. Dard
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.