maya.sh - ordinateurs

D'où vient le fond blanc (« light mode ») sur les écrans d'ordinateur ?

2025-11-26T00:00:00+01:00

À l'origine un toot j'ai fait une page comme on me l'a si gentiment suggéré.

Aujourd'hui il y a une tendance du « dark mode » qui a commencé autour de l'éditeur de code Sublime Text (si je me souviens bien) dans les années 2010 et s'est étendue au web et aux environnements de bureau. Le mode sombre est associé à l'imaginaire du hacker nourri par les souvenirs des terminaux vidéo des années 80 et des ordinateurs en mode texte.

Si on remonte dans le passé il y a eu une époque avant les moniteurs où les ordinateurs renvoyaient leurs réponses sur téléimprimante (TTY). Les premiers terminaux vidéo avaient pour vocation de remplacer la sortie papier en la simulant : le texte apparait en bas de l'écran puis remonte comme un rouleau et le texte qui était tout en haut disparait. L'ordinateur reçoit et retourne des caractères encodés dans un format numérique et le terminal qui possède une mémoire et un générateur de caractères s'occupe du dessin, de l'affichage et de l'effacement des lettres à l'écran.

Les micro-ordinateurs apparus à la fin des années 70 (par exemple Apple II) ont intégré le terminal vidéo à leur architecture, il suffisait alors de juste connecter le micro-ordinateur à un moniteur ou une télévision. Cette intégration a permis plus de flexibilité en permettant la modification des caractères en mémoire ainsi que leur position dynamiquement (plutôt qu'un simple mode « rouleau ») notamment pour les transformer en graphismes de jeu vidéo rudimentaires. Plus tard les micro-ordinateurs ont incorporé en plus des modes graphiques permettant de contrôler l'écran pixel par pixel plutôt que caractère par caractère mais le manque de mémoire de machines comme le VIC 20 ou le Commodore 64 contraignait les modes graphiques à des très gros pixels, rendant le mode texte toujours indispensable pour des applications de productivité comme le traitement de texte.

Les premiers terminaux vidéo utilisaient des tubes cathodiques monochromes verts (phosphore P1) ou ambres (P3), le texte était alors sur fond sombre je pense pour éviter l'usure du tube et éviter l'inconfort de lire du texte sur un rectangle lumineux vert ou orange - certains terminaux et moniteurs avaient toutefois une option pour inverser l'image. Les moniteurs ambres et blancs (phosphore P4) ont longtemps cohabité ; par exemple le fameux VT100 (1978) avait déjà un tube blanc, le VT320 (1987) lui était disponible dans les trois couleurs.

Du côté des micro-ordinateurs il y a eu une grande variété de codes couleurs. Le Apple II affichait son mode texte par défaut sur fond noir, le Commodore 64 sur fond bleu, le ZX81 en noir sur gris et le VIC 20 en bleu sur blanc. Le PC, conçu pour être utilisé notamment avec des écrans monochromes ambres ou verts, a ses modes texte par défaut sur fond noir. Certaines stations Sun des années 90 ainsi que les ordinateurs NeXT puis les premiers Mac avec OpenFirmware avaient leur mode texte sur fond clair.

Le premier ordinateur à permettre des applications graphiques (et qui possède une souris !) est le Xerox Alto en 1973. Son écran monochrome en orientation portrait utilisait du phosphore P4 (blanc) et l'environnement était entièrement noir sur blanc comme le seront les ordinateurs Lisa et Macintosh dans la décennie suivante. Ces ordinateurs partagent aussi la caractéristique de ne plus avoir de mode texte avec un générateur de caractères : l'écran affiche simplement une matrice de pixels. Xerox a très certainement choisi le noir sur blanc pour imiter la feuille de papier car le Alto (comme le Macintosh plus tard) possédait un écran de 72 DPI en pixels carrés conçu pour la composition de documents en WYSIWYG : le document apparaît à l'écran identique à ce qu'il sera une fois imprimé.

Dans les années 90 les environnements de bureau ont commencé à proposer des options de personnalisation permettant d'obtenir un « dark mode », déjà Windows 3.1 offrait des modes "inversés" à l'époque adaptés aux écrans à cristaux liquide des premiers ordinateurs portables. Windows 95 puis les versions suivantes avec leur thème "classique" offraient deux thèmes de couleur sur fond noir. Ces thèmes n'étaient cependant pas populaires parce qu'à cette époque de nombreux logiciel programmaient en dur certaines couleurs de leur interface plutôt que d'utiliser celles du système, ce qui rendait l'affichage inconsistant avec parfois des libellés difficiles ou impossibles à lire.

Du coup pour répondre à la question que je me suis posée : ça viendrait bien du Xerox Alto en 1973, comme presque tout finalement !

Partage de fichiers AppleTalk et internet entre Macintosh avec Netatalk et NetBSD

2025-11-11T00:00:00+01:00

Pour partager des fichiers entre mes Macintosh j'avais l'habitude de passer par mon serveur FTP configuré localement sur mon NAS ou en copiant les fichiers sur la carte MicroSD de mon BlueSCSI. C'est pas pratique parce qu'on perd le fork de ressources des fichiers ce qui implique de les compresser par exemple en .sit et ça demande pas mal de manipulations pénibles.

En ce moment j'utilise principalement 4 machines :

mon ordinateur principal sur une version récente de Mac OS ;
un PowerMac G3 sur Mac OS 9 connecté en Ethernet ;
un Macintosh LC475 sur Mac OS 7.5 connecté en Wifi à travers le BlueSCSI (émulation Daynaport) ;
un Macintosh SE sur le système 6.0.7.

J'ai trouvé un peu par hasard un boitier Micro AsantéPrint conçu pour permettre à un Macintosh d'accéder à des imprimantes situées sur un réseau Ethernet, le boitier se branche au port série de l'ordinateur et fait simplement une conversion LocalTalk (AppleTalk sur port série) vers EtherTalk (AppleTalk sur réseau Ethernet).

AppleTalk est le protocole réseau historique du Mac, supporté nativement par toutes les versions du système, il permet de mettre en place très facilement des partages de fichiers entre deux machines branchées directement ensemble par un câble série ou entre plusieurs machines reliées au même réseau.

AppleTalk n'est pas du TCP/IP, le support de TCP/IP dans Mac OS se fait via MacTCP pour les systèmes 6 et 7 puis via OpenTransport à partir de Mac OS 7.5. AppleTalk n'est plus supporté par les dernières versions de macOS mais les partages de fichiers AppleShare le sont toujours à travers TCP/IP (afp://) !

Pour en revenir au Micro AsantéPrint : ma première difficulté a été de l'alimenter en électricité. Je l'ai reçu sans son transfo d'origine et sur l'étiquette c'est marqué 12V alternatif ! Finalement j'ai démonté un vieil adaptateur secteur linéaire qui trainait chez moi, j'ai enlevé tous les composants pour garder juste le transformateur qui sort 10 ou 20V~ selon comment on se branche, je me suis branchée de sorte à avoir 10V~ à vide (8,5 en charge), c'est du bricolage mais ça fonctionne très bien !

D'un côté le AsantéPrint est connecté au Macintosh SE par le port série mini-DIN et de l'autre il est connecté au réseau local en Ethernet. Aucune configuration ni installation de pilote n'est nécessaire. Mes Macintosh se voient entre eux mais le SE ne peut toujours pas accéder à mon FTP ni à Internet parce qu'il ne communique qu'en AppleTalk ou en encapsulant TCP/IP dans AppleTalk via MacTCP et le Asanté fait juste la conversion entre le port série et l'Ethernet. D'après ce que je comprends un vrai adaptateur réseau SCSI comme le Daynaport émulé par le BlueSCSI fonctionne nativement en TCP/IP, genre il a une adresse MAC (mdr) et comprend quels paquets lui sont adressés.

Mes objectif étaient donc les suivants :

mettre en place un partage AppleShare sur mon NAS accessible en permanence sur n'importe quel Macintosh et aussi sur mon ordinateur moderne ;
accéder au réseau local en IP et à Internet depuis le Macintosh SE avec le boitier AsantéPrint.

Et après pas mal de temps j'y suis arrivée !

Pour réussir cette mission nous allons avoir besoin des trois mousquetaires ~~de la distribution~~ : le logiciel serveur Netatalk, la passerelle MacIPgw et le système d'exploitation NetBSD !

J'ai choisi NetBSD parce qu'il offre toujours le support du protocole AppleTalk ! C'est compilé dans le noyau de la release x86 mais c'est pas le cas pour toutes les architectures !

Mise en place de la VM dans TrueNAS

Configuration du réseau

La VM doit être mise en réseau en mode bridge, c'est normalement plutôt simple à mettre en place mais j'ai pas mal galéré avec ça sur TrueNAS donc je vous donne les étapes :

dans l'interface web, aller dans System/Network ;
retirer l'IP fixe de l'interface réseau physique ;
cliquer sur Add puis ajouter une interface bridge ;
donner à l'interface bridge l'IP qu'on a retiré à l'interface physique ;
dans Bridge Members ajouter l'interface physique.

Une fois que c'est fait, il faut appliquer les paramètres et redémarrer la machine parce que la connexion ne se réinitialise pas toute seule. En expérimentant j'ai perdu la connexion au NAS plusieurs fois mais ces paramètres sont modifiables facilement depuis une interface semi-graphique accessible depuis la machine en connectant un clavier et un moniteur.

C'est important que la VM soit en mode bridge parce qu'elle doit apparaitre sur le réseau local comme si c'était une machine physique comme les autres. Chez moi le NAS est sur 192.168.1.100 et la VM est sur 102.

Moi j'utilise des IP fixes mais je pense que vous pouvez passer par des IP attribuées par DHCP sans problème, par contre dans ce cas configurez le serveur DHCP pour que les IP ne bougent pas sinon ça va être chiant !

Création de la VM

La mise en place de la VM ensuite se fait simplement, il faut la mettre en réseau sur le bridge qu'on s'est éreintés à configurer, lui donner un peu de mémoire, un peu d'espace disque et une image ISO de NetBSD.

Le système consomme environ 50 Mo de mémoire quand on ne lui demande rien, c'est certainement pas mal de mettre un peu plus, 1 Go fait largement l'affaire.
L'OS et les outils prennent au total 650 Mo d'espace disque sachant que les Macintosh de l'ère 68k ne gèrent pas les volumes d'une taille supérieure à 2 Go (c'est géré et limité par Netatalk) vous pouvez faire vos math.

Installation et configuration de NetBSD

NetBSD c'est du UNIX un peu à l'ancienne mais c'est pas chiant du tout ! C'est ma première expérience avec cet OS et j'ai bien aimé !

L'installation se fait simplement en suivant les étapes du programme d'installation, j'ai choisi le partitionnement par défaut et une installation minimale (c).

Toujours dans l'installation, après la mise en place du système de base, c'est important de configurer le réseau (a) en choisissant un hostname et il faut que l'IP ne bouge pas, moi j'ai spécifié l'IP manuellement. Vous pouvez en profiter pour activer le serveur SSH (g) et éventuellement créer un utilisateur autre que root - si vous le faites c'est su pour passer en root. La config du serveur SSH est dans /etc/ssh/sshd_config comme sur Linux je crois.

Après l'installation vous pouvez revenir au programme d'installation avec la commande sysinst !

NetBSD utilise par défaut pkgsrc pour gérer les paquets, il faut ajouter une source :

# PKG_PATH="http://ftp.fr.netbsd.org/pub/pkgsrc/packages/NetBSD/$(uname -p)/$(uname -r|cut -f '1 2' -d.)/All/"
# export PKG_PATH

Maintenant vous pouvez télécharger et installer des paquets avec pkg_add ! Une bonne occasion pour installer un éditeur de texte un peu moins chelou que l'espèce de vi fourni par défaut, moi j'ai installé vim mais nano est aussi disponible.

Il existe aussi l'outil pkgin de plus haut niveau pour installer, supprimer et surtout mettre à jour les paquets comme le font apt ou dnf mais il n'est pas installé par défaut et n'est pas indispensable ici donc je vais pas m'embêter avec ça.

Installation et configuration de Netatalk

En un coup de cuillère à pot :

# pkg_add netatalk

Si c'est ok on a du texte qui nous indique que des scripts sont dispo dans un dossier d'exemple. Ces scripts qui servent à contrôler les services peuvent aller dans /etc/rc.d/ ! Pas de systemd ici, surtout ne dites rien à Lennart 😎

# cp /usr/pkg/share/examples/rc.d/timelord /etc/rc.d/timelord
# cp /usr/pkg/share/examples/rc.d/papd /etc/rc.d/papd
# cp /usr/pkg/share/examples/rc.d/netatalk /etc/rc.d/netatalk
# cp /usr/pkg/share/examples/rc.d/macipgw /etc/rc.d/macipgw
# cp /usr/pkg/share/examples/rc.d/atalkd /etc/rc.d/atalkd
# cp /usr/pkg/share/examples/rc.d/a2boot /etc/rc.d/a2boot
# cp /usr/pkg/share/examples/netatalk/netatalk.pam /etc/pam.d/

On ne va pas se servir de tous les services mais une fois qu'ils sont dans rc.d on peut facilement les démarrer ou les arrêter comme on le souhaite. Le fichier pam sert pour l'authentification centralisée je crois, moi je m'en sers pas mais si jamais on peut le retrouver facilement.

atalkd est le démon AppleTalk (indispensable)
netatalk est le serveur de fichiers AppleShare/AFP
macipgw est une passerelle qui décapsule/encapsule IP dans AppleTalk
a2boot est un serveur de boot pour faire démarrer un ordinateur Apple II à travers le réseau
papd est un serveur d'impression AppleTalk
timelord est un serveur de temps pour synchroniser l'heure

La configuration de Netatalk se passe dans /usr/pkg/etc/netatalk/afp.conf, je vous montre mon fichier :

[Global]
hostname = NetBSD
appletalk = yes
afp listen = 192.168.1.102
uam list = uams_clrtxt.so uams_guest.so

[mac]
volume name = Partage NetBSD
path = /afp
legacy volume size = yes
unix priv = no
invisible dots = yes

hostname : c'est le nom de machine qui apparait dans le Sélecteur sur Macintosh
appletalk : le partage est accessible à travers un réseau AppleTalk (et pas juste à travers IP)
afp listen : l'IP du serveur (pour monter le partage avec afp://192.168.1.102 sur macOS moderne !)
uams_clrtxt.so : le partage est accessible aux utilisateurs du système avec leur nom d'utilisateur et mot de passe
uams_guest.so : le partage est aussi accessible en invité, sans mot de passe
volume name : nom du partage (on peut en faire plusieurs pour chaque machine)
path : dossier du volume, pensez à le créer et lui donner les bonnes permissions de manière chirurgicale (un bon vieux chmod 777 t'as compris)
legacy volume size : parce que Mac OS 7.1 et inférieur ne gère pas les volumes de plus de 2 Go
unix priv = no : on va pas se casser le cul avec les permissions
invisible dots : rend invisible les fichiers cachés UNIX sur les clients Macintosh classiques

Ça suffit déjà pour le partage de fichiers ! Pour tester il faut démarrer atalkd et netatalk :

# service atalkd onestart
# service netatalk onestart

Ensuite vous démarrez un Macintosh connecté au même réseau, vous allez dans le Sélecteur et vous devriez voir le partage apparaître ! Réciproquement, avec la commande nbplkup vous devez voir le Macintosh apparaître !

netatalk# nbplkup
                    192.168.2.1:IPGATEWAY                          65280.58:72
                         NetBSD:AFPServer                          65280.58:128
                       netatalk:netatalk                           65280.58:4
                       netatalk:Workstation                        65280.58:4
           AsantéPrint 94765C9A:AsantéPrint                        65295.15:252
                   Macintosh SE:Macintosh SE                       65295.16:253

Pour que Netatalk se lance automatiquement avec la VM il faut ajouter dans /etc/rc.conf les deux lignes suivantes :

atalkd=YES
netatalk=YES

Le partage doit aussi être accessible sur macOS moderne en allant dans le Finder, menu Aller puis Se connecter au serveur (ou juste Cmd-K) puis en rentrant l'adresse afp://...

Le serveur apparait automatiquement sur le Macintosh !

Sur macOS 26.0 je dois rentrer l'adresse IP manuellement

Passerelle AppleTalk - TCP/IP

Cette partie traite de la configuration de MacIPgw pour permettre à mon Macintosh SE d'accéder aux autres machines en IP et à Internet en passant par le boitier AsantéPrint. Si vous avez un BlueSCSI ou n'importe quelle vraie carte réseau ce qui suit n'est pas nécessaire.

On part du préalable que le Macintosh est connecté sur un réseau Ethernet à travers une liaison série LocalTalk et que les outils MacTCP et MacTCP Ping téléchargeables ici sont présents.

Au commencement, Dieu créa un tunnel et activa le IP forwarding. Ce fut le premier jour.

# ifconfig tun0 create
# sysctl -w net.inet.ip.forwarding=1

Normalement en faisant ifconfig vous voyez votre tunnel tun0 sans IP et down, c'est normal il sera autoconfiguré par MacIPgw.

Dieu configura MacIPgw. Ce fut le deuxième jour.

On crée le fichier /usr/pkg/etc/netatalk/macipgw.conf avec :

[Global]
network = 192.168.2.0
netmask = 255.255.255.0
nameserver = 192.168.1.100

Pareil vous adaptez la config, dans network j'ai choisi un sous-réseau en 192.168.2.x mais vous pouvez mettre ce que vous voulez. Le nameserver c'est le DNS, le mien est sur 100 mais vous pouvez mettre 8.8.8.8 par exemple (Google 😡)

Dieu mit en place un NAT. Ce fut le troisième jour.

Pour que les paquets destinés au Macintosh arrivent à destination on configure un NAT.

Dans /etc/npf.conf :

map wm0 dynamic 192.168.2.0/24 -> 192.168.1.102 

group default {
    pass in all
    pass out all
}

Vous adaptez en remplaçant 192.168.1.102 par l'IP de votre VM, 192.168.2.0 par le sous-réseau et wm0 par le nom de l'interface réseau principale telle qu'affichée dans ifconfig.

Puis on applique la config et on lance npf :

# npfctl reload
# npfctl start

Dieu dit « lançons la passerelle ! » et cela se passa ainsi. Ce fut le quatrième jour.

On lance la passerelle :

# service macipgw onestart

Maintenant sur le Macintosh il faut configurer MacTCP :

pour l'adresse IP n'importe quoi dans le sous-réseau ira genre 192.168.2.15 (au pif)
dans Options :
- obtenir l'adresse manuellement
- passerelle 192.168.2.1
- DNS : mettre . (un point) dans domaine et l'IP d'un DNS genre 8.8.8.8 (Google 😡)

Après avoir redémarré, vous pouvez ouvrir MacTCP Ping et essayer de ping une adresse random. Côté NetBSD on peut voir ce qui se passe avec tcpdump !

La commande ci-dessous permet de voir les paquets AppleTalk qui atteignent la VM (pensez à adapter wm0).

# tcpdump -i wm0 -n atalk

La commande ci-dessous permet de voir les paquets convertis par MacIPgw dans le tunnel. Si vous voyez quelque chose là-dedans c'est que la passerelle fonctionne ; il faut que le Macintosh soit démarré après la mise en route du service macipgw !

# tcpdump -i tun0 -n

La commande ci-dessous permet de voir les paquets destinés à une adresse (par exemple celle d'un ping) une fois ressortis du tunnel. Si le NAT fonctionne, l'origine du paquet est affichée comme 192.168.1.102 (dans ma config) ; si vous voyez l'origine réelle 192.168.2.x alors il y a un problème et le ping finit probablement en timeout.

# tcpdump -i wm0 -n dst 8.8.8.8

Dieu regarda tout ce qu'il avait fait, et il constata que c'était très bon. Il persista la configuration.

# echo create > /etc/ifconfig.tun0
# echo net.inet.ip.forwarding=1 >> /etc/sysctl.conf

Dans /etc/rc.conf :

macipgw=YES
npf=YES

Les connexions FTP en mode actif ne sont pas possibles à travers le NAT c'est pour ça que Fetch sur le Macintosh renvoie une erreur liée à PORT, je n'ai pas trouvé de solution mais je n'ai plus besoin d'utiliser le FTP.

Pour conclure

Les partages AppleShare sont hyper pratiques ! J'aurais vraiment du me pencher sur ça plus tôt. C'est pas si dur à configurer une fois qu'on a pris les outils en main et la possibilité de partager des fichiers entre des Macs de n'importe quelle époque sans plus jamais avoir de souci du fork de ressource qui se barre c'est juste magique.

La possibilité de se connecter en IP depuis une liaison LocalTalk c'est très pratique aussi : juste deux câbles à brancher, pas de pilote à installer et rien à démonter.

Le seul inconvénient du LocalTalk c'est sa faible vitesse, environ 200 kb/s d'après ce que j'ai lu, la vitesse a l'air similaire à celle du lecteur de disquettes.

Si comme moi vous aimez les Macintosh 68k vous avez peut-être déjà entendu parler de NetBSD parce que c'est je crois le seul UNIX (avec A/UX) qui fonctionne sur cette architecture !

« Loin du tumulte moderne des grandes distributions linux et de systemd il existe encore des petits coins de paradis paisibles où il fait bon vivre comme le petit village de NetBSD où d'authentiques artisans unixiens façonnent leur système d'exploitation comme autrefois ! »

En cas d'erreur ou de problème je vous encourage à m'écrire sous ce toot pour que je puisse corriger la page ou vous aider 👇

Post by @mayasynth@eldritch.cafe

View on Mastodon

Fabriquer un adaptateur ADB→USB pour clavier Macintosh

2025-09-03T00:00:00+02:00

Depuis la nuit des temps nous utilisons des claviers pour écrire à l'ordinateur. Avant ça on écrivait les bits sur les disquettes directement avec des aimants mais c'était vite devenu très galère ; pour cette raison l'ingénieur Fulgence Clavier (le grand-père de l'acteur !) a inventé le clavier en 1922 [source].

Le bus universel utilisé par tous les ordinateurs modernes est l'USB, un des premiers ordinateurs l'ayant introduit pour les périphériques étant l'iMac en 1998. Les Macintosh plus anciens utilisaient un autre bus, l'ADB, introduit à l'origine sur l'Apple IIgs en 86 puis sur tous les Mac sortis à partir de 87.

Il existe beaucoup d'adaptateurs pas chers pour connecter d'anciens périphériques PC en prise PS/2 sur des ordinateurs USB mais ce n'est pas le cas pour l'ADB. L'adaptateur le plus populaire est le Wombat qui supporte la conversion dans les deux sens et permet aussi de brancher des claviers et souris USB sur un Macintosh mais il coûte 40$ sans compter la livraison depuis les US, les taxes et la douane.

J'ai donc tenté de réaliser pour vous un adaptateur pas cher qui m'a coûté environ 5€ de composants. Cet adaptateur permet seulement d'utiliser un clavier ADB sur un ordinateur en USB, pas l'inverse.

Fabrication de l'objet

J'ai utilisé ces composants :

un Arduino Pro Micro (un clone AliExpress) ;
une prise femelle mini-DIN 4 broches ;
une résistance de 1000 ohm ;
trois fils de 3 cm max ;
un câble USB ;
275 cagettes de pommes.

Pour commencer j'ai coupé trois fils d'un peu moins de 3 cm, dénudés de chaque côté. Ensuite j'ai identifié les broches DATA, VCC et GND sur le port mini-DIN pour savoir où souder les fils, ça se fait avec le multimètre en mode continuité.

Pour avoir un ensemble solide j'ai utilisé les broches offertes avec l'Arduino pour y souder les deux grosses patounes du mini-DIN en faisant attention de ne rien mettre en court-circuit, c'est du gros bricolage mais ça fait totalement le taf ! Ensuite j'ai soudé les fils sur le port de manière perpendiculaire pour pouvoir les connecter facilement.

Enfin j'ai cherché la broche PD0 sur la carte, elle correspond au numéro 3 sur le PCB. J'ai ajouté la résistance entre 3/PD0 et VCC sous le PCB puis j'ai soudé les fils.

Programmation de la carte

J'ai installé QMK avec mon gestionnaire de paquets :

brew install qmk/qmk/qmk

Après j'ai lancé le setup puis la compilation du fichier pour l'adaptateur :

qmk setup
qmk compile -kb converter/adb_usb/rev1 -km default

Enfin j'ai flashé l'Arduino : je l'ai branché puis j'ai exécuté :

qmk flash -kb converter/adb_usb/rev1 -km default

Au message Waiting for USB serial port - reset your controller now j'ai déclenché le reset en reliant brièvement RST et GND - les deux broches contigües juste au-dessus de VCC côté port USB - j'ai fait ça avec une petite pince mais on peut aussi utiliser un trombone.

Ça a fonctionné du premier coup et j'ai pu connecter un clavier ADB pour écrire cette page. :)

Liens

ADB-to-USB Keyboard Converter, page Github du firmware ADB-to-USB
QMK Firmware, Quantum Mechanical Keyboard Firmware
Archive du wiki Deskauthority, wiki de référence pour les claviers

Analyse des nouveaux titres rechargeables des transports de Toulouse

2025-08-02T00:00:00+02:00

Au mois de mars 2025, le réseau de transports Tisséo a introduit un nouveau support de titre de transport remplaçant l'ancien support magnétique. Les nouveaux tickets, similaires à vue d'œil, offrent deux avantages : ils ne se démagnétisent pas et permettent le rechargement plusieurs fois. Utilisatrice occasionnelle du réseau, j'en ai vite profité pour faire remplacer mon ancien carnet magnétique de 10 trajets qui avait arrêté de fonctionner au bout de 5 validations par un ticket rechargeable.

Contrairement à la RATP/IDFM qui a vraisemblablement réutilisé la technologie Calypso des pass Navigo pour les supports Navigo Easy le réseau Tisséo comme d'autres villes en France a choisi une solution moins chère avec ces tickets en carton : ils sont vendus au prix de 20 centimes en plus du prix des titres. Les cartes Navigo Easy sont elles vendues 2€ à Paris. L'inconvénient du ticket en carton, en plus de sa relative fragilité matérielle, est le nombre limité de recharges : Tisséo indique plus de 30 fois ainsi qu'un maximum de 50 titres simultanément.

La (relative) simplicité technique de ces nouveaux tickets en fait un excellent cas d'exemple pédagodique du fonctionnement du NFC ! Cette page va surtout se concentrer sur la manière dont sont codées les données et comment leur intégrité en est assurée.

Les données d'un tag ST25TB

Chaque titre en carton contient un tag NFC ST25TB de STMicroelectronics d'une capacité de 512 bits. La mémoire est divisée en 16 blocs de 32 bits sur lesquels l'écriture est libre à une subtilité près.

Trois blocs supplémentaires sont présents :

deux blocs UID0 et UID1 en lecture seule sur lesquels sont inscrits un identifiant unique de 64 bits, le numéro est imprimé en décimal à l'arrière du ticket en carton et semble être séquentiel dans l'ordre de fabrication ;
un bloc OTP (one time programmable) dont les bits 16 à 31 (en comptant à partir de zéro) définissent l'état de lecture seule des blocs 0 à 15 respectivement. Par défaut à 1, le passage de ces bits à 0 passe les blocs concernés en lecture seule et cette opération est irréversible.

Tous les blocs sont par défaut accessibles en lecture et écriture et le tag ne contient aucun mécanisme de contrôle d'accès. Toutefois les blocs 5 et 6 sont spéciaux, ce sont des compteurs de décrémentation : ils sont initialisés avec les valeurs FF FF FF FF et ne peuvent être mis à jour qu'avec une valeur inférieure.

Toute la sécurité anti-fraude de ces supports repose sur trois choses :

l'UID en lecture seule qui assure l'impossibilité de cloner un titre ;
les compteurs de décrémentation qui s'assurent qu'on ne peut pas remettre un ticket dans son état d'origine ;
des signatures calculées à partir de l'UID et des compteurs qui s'assurent que les données inscrites sont bien authentiques, c'est à dire encodées depuis un automate de vente disposant d'une clé secrète pour les calculer.

Arrière d'un ticket

Structure d'un ticket

Pour rendre la lecture plus claire j'ai mis les octets de poids fort côté gauche.

    0: 61 40 20 30   Système et distribution
    1: 25 09 16 24   Distribution
    2: 04 1F 6A C4   Distribution
    3: FA A2 28 08   Usage A
    4: CC F3 83 E9   Usage A
    5: FE 00 00 09   Compteur 1
    6: FF FF FF FC   Compteur 2
    7: 00 05 E0 FA   Usage A
    8: C0 00 18 43   Usage A
    9: C4 12 B6 AF   Usage A
   10: FA A1 08 08   Usage B
   11: C2 F3 83 EB   Usage B
   12: 00 00 A0 00   Usage B
   13: 00 00 18 43   Usage B
   14: C4 00 CE 3F   Usage B
   15: 91 B5 61 9F   Signature
  OTP: FF FF FF FF   Bloc OTP
UID 0: D0 02 33 7F   Première partie de l'UID
UID 1: 6F 2D 0E 69   Deuxième partie de l'UID

Les blocs 0, 1, 2 contiennent des données de distribution qui ne changent pas après l'émission d'un ticket ;
les blocs 3, 4, 7, 8, 9 et 10 - 14 contiennent respectivement les usages A et B, chaque usage contient une signature de 16 bits à sa fin, ils stockent alternativement les informations du dernier et avant-dernier passages ;
le bloc 5 contient un compteur ici divisé en deux parties : les trois octets de poids faible sont décrémentés de 1 à chaque validation d'un nouveau titre (pas en correspondance), l'octet de poids fort est décrémenté à chaque rechargement. Ce dump est un titre « 10 déplacements » qui a été chargé une seule fois et dont un seul titre a été utilisé. Lors de l'achat la valeur du bloc 5 était FE 00 00 0A.
le bloc 6 contient un autre compteur dit de swap, il est décrémenté lors de chaque utilisation (chargement ou validation), dans cet exemple il a été décrémenté lors de l'achat puis deux fois puisque validé deux fois (dont une fois en correspondance), le dernier bit de ce bloc permet de définir quel usage va être écrasé à la prochaine validation ;
le bloc 15 contient une signature pour les données de distribution, cette signature ne change que lors d'un rachat de titres (elle est calculée entre autres en fonction de l'octet de poids fort du bloc 5).

Le choix de réserver 5 blocs par usage en sacrifiant la taille des données de distribution est un choix de Tisséo, d'autres partitionnements sont possibles et décrits dans la norme.

Extraction et interprétation des données

Norme Intertic

Ces titres de transports sont encodés à la norme Intertic, plus précisément :

la norme Afnor NF P99-410 qui définit les règles Intertic en elle-mêmes et leur principe de formatage ;
la norme Afnor NF P99-416 qui définit comment encoder les règles Intertic sur différents supports en fonction de leurs limites, notamment les tickets ST25TB.

Intertic est la version « allégée » d'Intercode, une autre norme prévue pour les cartes d'abonnement qui possèdent plus de mémoire. Il existe aussi Interbob pour normaliser les échanges entre les systèmes informatiques et Transmodel pour les bases de données.

Le formatage des données sur un titre peut être complexe parce qu'Intertic est très flexible et peut s'adapter aux règles de différents réseaux de transports. Les données sont inscrites sur chaque titre de manière séquentielle mais entre ces données il arrive que des champs spéciaux indiquent quelles données optionnelles sont présentes ou absentes. Heureusement la quantité de mémoire très réduite du titre rechargeable impose une certaine simplicité. En réalité pour les titres rechargeables Tisséo, à une exception près, les données sont situées à des emplacements fixes ce qui les rend faciles à décoder.

Système et distribution

Pour extraire les informations générales d'un titre, il faut lier les blocs 1, 2 et 0 dans cet ordre puis les découper :

Bloc 1 : 001001010000 100100010110 001001 00
         A            B            C      D...

Bloc 2 : 000001 0000011111011010 1011000100
                E                F...

Bloc 0 : 0110 00010 10 00000001 0000 0001 10000
              G     H  I        J    K    L

Lettre	Taille (bits)	Signification	Valeur
A	12	Code pays	0x250 (France)
B	12	Autorité organisatrice	0x916 (Tisséo)
C	6	Version de contrat	9
D	8	Fournisseur de contrat	1
E	16	Tarif de contrat	2010
F	14	Date de fin de contrat	2028-01-05
G	5	Définit le formatage
H	2	Définit le formatage
I	8	Exploitant	1
J	4	Vide
K	4	ID du jeu de clés (système)	1
L	5	ID de partition (système)	0x10

Les dates sont codées sur 14 bits, en nombre de jours depuis le 1er janvier 1997 ;
les données de « contrat » sont liées aux normes Intercode et Intertic, je ne connais pas en détail leur signification ;
la date de fin de contrat sert ensuite pour calculer les dates des usages ;
le tarif définit le type de titres chargé, 2010 sert à indiquer qu'il s'agit de titres 10 déplacements, c'est cohérent avec le comportement de l'automate qui m'autorise uniquement un rechargement par 10 sur mon ticket non vide - c'est très bête comme limitation mais mon intuition est que le tarif permet aussi de faire la différence entre un titre unitaire et un titre aéroport ou journée par exemple (on ne peut charger qu'un seul type de titre) ;
les signatures sont calculées au moins en fonction de l'UID, de l'ID de partition, de l'ID du jeu de clés et du tarif ;
l'ID de partition sert à décrire le type de partitionnement utilisé parmi plusieurs possibles décrits dans la norme Intertic, le partitionnement 0x10 permet d'avoir des usages de 5 blocs.

Le ticket qui m'a été échangé contre l'ancien magnétique a été chargé avec des « déplacements SAV », je ne peux pas le recharger*

Nouveau ticket rechargeable avec 10 titres disponibles, dumpé ici en exemple, je ne peux ajouter que des titres similaires (des lots de 10)

Normalement je suis supposée pouvoir charger le type de titre que je souhaite une fois que la carte est vide, j'ai tendance à penser que le bug qui m'empêche de recharger ma première carte est causé par le type de titre non disponible à l'achat (déplacement SAV, tarif 2060).

Usages

Découpage du usage B pour l'exemple, c'est pareil pour le A :

Bloc 10 : 1111101010 10000100001 00000001 000
          A          B           C        D...

Bloc 11 : 11  00001 01111 001110 00001111101011
              E     F     G      H

Bloc 12 : 00 0000000000000010 10 000000000000
          I  J                K  L...

Bloc 13 : 00 00000000000000 0001 10000100001 1
             M              N    O           P...

Bloc 14 : 11 0001 000000 000 0 1100111000111111
             Q    R      S     Signature

Lettre	Taille	Signification	Valeur usage B	Valeur usage A
A	10	Date de validation	2025-04-16	2025-04-16
B	11	Heure de validation	17:37	18:13
C	8	Exploitant	1	1
D	5	Nature	3 (métro)	3 (métro)
E	5	Type de validation	1 (validation entrée)	6 (correspondance)
F	5	Définit le formatage
G	6	Définit le formatage
H	14	ID de ligne	1003 (ligne C)	1001 (ligne A)
I	2	Direction	-	-
J	16	Code station (optionnel)	2	23
K	2	Définit le formatage
L	14	ID de ligne précédente	-	1003 (ligne C)
M	14	ID de ligne encore précédente	-	-
N	4	Définit le formatage
O	11	Heure de 1e validation	17:37	17:37
P	3	Définit le formatage
Q	4	Nombre de passagers	1	1
R	6	Nombre de trajets	1	0
S	3	Nombre de correspondances	1	0

La date est codée en nombre de jours à soustraire depuis la date de fin de contrat de la partie distribution ;
différents codes nature existent, notamment 1 pour le bus, 3 pour le métro, 4 pour le tramway, 5 pour le train, etc. Sur Tisséo, la ligne C et le câble Téléo sont indiqués comme des métros ;
le champ direction est rempli pour le bus et le tramway : 1 pour l'aller et 2 pour le retour ;
le champ du code station n'est indiqué que pour une validation sur un portique, c'est le seul champ qui est présent de façon optionnelle sur ces tickets ; lors d'une validation dans un bus ou un tramway il n'est simplement pas présent (pas juste vide), ce qui décale toute la lecture des champs suivants !
lorsqu'un ticket vierge est édité par un automate de vente, l'usage A est signé ~~et contient une heure de validation et de première validation à 23h59~~ (màj : le bug a été corrigé 😂)
le nombre de « trajets » semble être la même chose que le nombre de correspondances.

Identifiants internes

Le tableau suivant référence les différents codes station que j'ai repérés au fil du temps. Le réseau de Toulouse est un des rares (le seul ?) ou on valide en correspondance dans le métro, ce qui permet au valideur de toujours connaître la ligne empruntée. Je ne vois pas de lien avec les données GTFS disponibles en open data, ce sont des identifiants internes. J'ai l'impression que les stations sont par ordre alphabétique ?

ID	Ligne	Station
1	C	Arènes (gare)
2	C	Colomiers (gare)
23	A	Arènes
24	A	Argoulets
25	A	Bagatelle
26	A	Balma – Gramont
27	A	Basso Cambo
28	A	Bellefontaine
29	A	Capitole
31	A	Esquirol
33	A	Jean Jaurès
36	A	Marengo SNCF
43	A	Saint-Cyprien
44	B	Barrière de Paris
45	B	Borderouge
46	B	Canal du Midi
51	B	Jeanne d'Arc
52	B	Jean Jaurès (depuis la B)
53	B	Jean Jaurès (depuis la A)
54	B	Jean Jaurès (depuis l'extérieur)
55	B	La Vache
57	B	Palais de justice
59	B	Ramonville
64	B	Saint-Michel
65	B	Trois Cocus
83	Téléo	Université Paul Sabatier

Ce tableau référence l'ID de chaque ligne dans le système, là encore ça ne correspond pas aux données GTFS. Pour les autobus, c'est juste le numéro de la ligne de bus.

ID	Nom commercial de la ligne
24	Bus aéroport
835	Bus relai métro B
1001	Métro A
1002	Métro B
1003	Train Arènes-Colomiers (ex ligne C)
1005	Tramway T1
1007	Câble Téléo

Ce tableau référence les ID correspondant aux tarifs, c'est à dire les différents types de tickets qu'on peut charger sur un titre rechargeable. La liste n'est pas exhaustive, il m'en manque quelques uns. Il n'y a pas forcément de différence de prix entre deux tarifs, par exemple deux déplacements coûtent le même prix qu'un seul déplacement chargé en deux fois.

ID	Type de billet
2005	1 déplacement
2007	1 déplacement dernière minute (à bord)
2010	10 déplacements
2020	2 déplacements
2037	3 jours ?
2060	1 déplacement (SAV)
2062	? déplacements
2090	1 déplacement aéroport (à bord)

Sécurité du support

La décrémentation du bloc 5 de manière similaire à un automate est possible mais invalide la signature du bloc 15 et rend le titre illégitime.

On pourrait penser que changer l'horodatage du dernier usage pour simuler une correspondance pourrait éviter la décrémentation d'un titre lors de la validation mais chaque usage est protégé par sa propre signature.

Impossible aussi d'escalader de tarif par exemple en achetant un titre « 1 déplacement » et en le transformant en ticket aéroport parce que son authenticité est protégée par la signature du bloc 15.

Attaque par arrachage (tearing)

Il reste l'hypothèse de remonter dans le temps en réinitialisant le ticket dans un état passé. Ça nécessite d'incrémenter le compteur 5, c'est normalement matériellement impossible mais les tags ST25TB sont sensibles aux attaques par arrachage, ça a fait l'objet de recherches depuis plusieurs années et les réseaux de transport sont supposés être informés.

Actuellement le seul moyen pour un réseau de transport de se prémunir au mieux est de vérifier au maximum la cohérence des informations du titre plutôt que juste faire confiance aux compteurs.

Exemples :

un titre dont le nombre de voyages disponibles est égal au nombre de déplacements achetés doit avoir les deux zones d'usage vierges dont une des deux signée (celle qui ne sera pas écrasée en premier) ;
un titre « 1 déplacement » qui n'a été chargé qu'une seule fois ne doit pas avoir un swap supérieur à 5 (une recharge + 4 validations possibles par voyage), le nombre passe à 41 pour un ticket de 10 voyages ;
un titre ne doit pas contenir plus de voyages qu'il n'est possible d'en acheter, par exemple si l'automate permet d'acheter au maximum 5 voyages « 1 déplacement » séparément il ne devrait pas y avoir plus de 5 voyages sur le ticket (je ne connais pas la limite réelle) ;
le nombre de voyages doit être cohérent avec le nombre d'achats, par exemple si 3 voyages au code tarif « 1 déplacement » sont disponibles cela implique au minimum 3 achats décomptés, si 15 voyages au tarif « 10 déplacements » sont disponibles ça implique au minimum 2 achats.

Dans leur note technique TN1530 de mai 2024 STMicroelectronics conseille :

Follow the recommendations provided in section Antitearing protection of “Best practices for security and privacy with ST25 NFC/ RFID Tags” (AN5493)

Ça nous mène à la note d'application AN5493 qui nous met déjà dans l'ambiance dès la page 2 :

ST25 NFC /RFID Tags devices are not certified products that can be used in entry level security applications. In case of needs of a more secure solution as in the transportation domain, for example, STMicroelectronics can propose the CD21 product portfolio using the certified secure ST31 IC family and compliant with all Calypso requirements.

Après nous avoir présenté les diverses fonctionnalités de différents tags de la série ST25 le même document - mis à jour en mai 2025 - nous précise dans la section 5.2.3.4 Antitearing protection (p. 28) :

It may not be sufficient in the applications that are often faced daily human threats and risks such as fraud. Certain enhanced attacks to cause an impact on the security automatic mechanism and to exploit vulnerability may occur and need to be thwarted by combining technical controls since ST25 series are not considered as security certified products and may not resist to advanced attacks.

C'est quand même abusé pour un système vendu spécifiquement pour les transports.

ST25TB product presentation, mai 2020 [pdf]

Première page du datasheet, février 2023 [pdf]

Enfin toujours dans la même section le document suggère quelques stratégies : utiliser des checksums pour assurer l'intégrité des données (oui mais quel rapport avec mon potiron ?), utiliser des signatures (déjà fait) ou faire des vérifications côté serveur, ce qui est probablement la seule stratégie viable à terme mais techniquement très compliqué pour un réseau de transports.

Pour conclure, Tisséo utilise la norme Intertic de manière optimale pour assurer le respect des contraintes de la tarification dans la mémoire réduite du ST25TB512 mais cette technologie n'offre pas un niveau de sécurité adapté à l'usage qui en est fait. Les cartes Pastel utilisées pour les abonnements permettant déjà de charger des titres unitaires, en vendre des non-nominatives comme fait IDFM avec le Navigo Easy ou les réseaux de transport du Québec avec la carte Opus aurait garanti un meilleur niveau de sécurité malgré un coût du support plus élevé. Les nombreux réseaux de transports en France qui utilisent le ST25TB s'exposent aux mêmes problèmes.

Pour en apprendre plus

Décodeur de titres rechargeables Tisséo par votre serviteuse
Script de décodage Intertic générique, gentilkiwi
FAQ des tickets rechargeables, Tisséo
Near Field Chaos, outil pour lire et écrire librement sur les tags ST25TB !
[PDF] La NORMALISATION un outil pour l’INTEROPÉRABILITÉ de la billettique dans les transports publics, Certu (PDF, 2008)
[PDF] Datasheet du ST25TB512-AT
[PDF] ST25TB series NFC tags for fun in French public transports, gentilkiwi
[PDF] Tears for fears, breaking an RFID counter

Logiciels et jeux indispensables : tout pour bien démarrer sur Macintosh 68k

2025-07-29T00:00:00+02:00

Cette page regroupe différentes ressources pour bien débuter dans l'univers du Mac 68k, j'y ai ajouté pas mal d'explications sur le fonctionnement de ces machines.

Ce qui est à télécharger ici vient parfois du net, parfois de disquettes qui trainent chez moi ; dans tous les cas j'ai testé chaque archive et j'ai refait la plupart des images disques pour m'assurer qu'elles fonctionnent et que celles qui sont supposées être bootables le soient réellement. Ce sont dans la mesure du possible des logiciels en français.

Je mets à jour cette page de temps en temps, en cas d'erreur n'hésitez pas à m'écrire à cette adresse.

Sommaire

💾 Logiciels système
💡 Utilitaires
🧩 Extensions et tableaux de bord
🎨 Logiciels
🎲 Jeux
📁 Transférer les fichiers
⚙️ Principes du Mac OS classique
🚀 Outils pour les machines d'aujourd'hui
📕 Différentes gammes et générations de Mac 68k
🔗 Ressources

💾 Logiciels système

Système 6.0.7

Pour les machines 68000 l'OS le plus fluide est le système 6. La dernière version est la 6.0.8 mais je ne l'ai pas trouvée en français, elle est identique à la 6.0.7 à part pour la gestion des imprimantes donc je propose la 6.0.7.

Le système 6.0.7 est compatible avec tous les Macintosh 68000 à l'exception du 128K, du 512K et du PowerBook 100.

Image HDA pour BlueSCSI
Image bootable qui contient les 4 disquettes du système 6.0.7 et les utilitaires DiskDup Pro, Resedit, Stuffit Deluxe 3.5 et Font/DA Mover.
Disquettes au format DD 800 Ko
Archive contenant 4 disquettes du système 6.0.7 version française (claviers AZERTY et QWERTY US) : Système et Utilitaires 1 sont bootables, cette dernière contient des utilitaires de disque.

Màj : correction des images DD dont il manquait des accessoires et polices, retrait des images HD qui étaient corrompues.

Pour activer le multitâches il faut sélectionner le volume de démarrage sur le bureau, aller dans le menu Rangement, cliquer sur Fixer le démarrage... puis choisir MultiFinder.

Un fichier System supplémentaire est disponible ci-dessous (rubrique Extensions) pour ajouter les dispositions de clavier canadiennes ! Il est fourni sur une image séparée pour que tout puisse rentrer sur des disquettes de 800 Ko.

Système 7.1

Pour les machines 68020 et plus rapides le système 7 apporte une compatibilité avec plus d'applications, un multitâches intégré à l'OS (plus besoin d'activer le multifinder), les polices TrueType, le glisser-déposer sur les icônes d'applications, des améliorations dans AppleTalk, dans la gestion des imprimantes et une interface en couleurs !

Le système 7 introduit aussi le support de plus de 8 Mo de RAM grâce à l'adressage 32 bits des CPU 68020, 30 et 40. Pour les Mac dont la ROM n'est pas compatible il existe Mode32.

La mise à jour 3.0 corrige simplement des bugs.

Image HDA pour BlueSCSI
Image bootable contenant toutes les disquettes d'installation pour le système 7.1 en version française et la mise à jour 3.0 ; contient aussi Disk Copy 6.3.3, Stuffit Expander 5.5, l'utilitaire de disques Apple patché et les outils Norton pour partitionner, défragmenter et diagnostiquer les disques. Il faut monter toutes les images en même temps, lancer le programme d'installation depuis la première disquette puis recommencer pour la mise à jour 3.0. Le programme d'installation a une option Personnaliser qui permet d'installer un système plus léger adapté uniquement à la machine et dépourvu des pilotes d'imprimantes.
Disquettes au format HD 1,44 Mo
Archive contenant directement les différentes disquettes. La disquette Installation 1 boote sur le programme d'installation directement, Utilitaires 2 boote sur un Finder et contient des utilitaires pour formater et partitionner des disques durs mais de marque Apple uniquement (version patchée toutes marques disponible plus bas).

Les Macintosh sortis après le système 7.1 ont besoin d'un System Enabler pour booter le système, c'est un fichier à glisser dans le Dossier Système du disque sur lequel vous venez de faire l'installation. L'image bootable ci-dessus en contient plusieurs dans son dossier système, ils sont aussi présents dans la disquette Mise à jour 3.0 disque 2. Vérifiez dans ce PDF celui dont vous avez besoin ou au pire mettez-les tous.

Mac OS 7.5.3

Pour les machines 68030 et 68040 puissantes Mac OS 7.5 ajoute quelques fonctionnalités supplémentaires comme une barre de réglages en bas de l'écran pour notamment changer le volume, des fonds d'écran, AppleScript, un meilleur glisser-déposer et les outils MacTCP et OpenTransport pour se connecter à Internet. La plupart de ces nouveautés peuvent être installées manuellement et individuellement dans 7.1.

La version 7.5 introduit la marque Mac OS et l'écran de démarrage avec le logo Picasso.

Mac OS 7.5.3
Image de CD bootable au format Toast (pris en charge par le BlueSCSI et par Basilisk II) en français, contient Disk Copy 6.3.3 et Stuffit Expander 5.5.

Versions à éviter

Le système 7.0 parce qu'il est moins optimisé et offre une compatibilité logicielle moins bonne que le 7.1.
Mac OS 7.6 parce qu'il n'apporte rien d'intéressant pour les Macintosh 68k - Apple achève à cette époque la migration vers l'architecture PowerPC. Cette version ne supporte plus les 68000, 68020 ni les machines avec une ROM 24 bits comme le SE/30 et les premiers Mac II.

Retour au sommaire

💡 Utilitaires

Disk Tools patché [hd.img]
Disquette bootable du système 7 contenant un outil de formatage et partitionnement patché pour fonctionner avec des disques durs de toutes les marques.
DiskDup Pro pour système 6 [macbinary]
Pour faire des copies de disquette ou monter des images sur le système 6 (ça doit fonctionner aussi sur le 7 mais Disk Copy 6.3.3 est plus ergonomique).
Font/DA Mover pour système 6 [macbinary]
Permet d'ajouter ou supprimer des polices et des accessoires de bureau au fichier System.
Disk Copy 6.3.3 [sit.macbinary] pour système 7, en français
Permet de monter des images de disquettes, d'imager des disquettes et inversement.
Stuffit Expander 3.5 pour système 6 et 7 [dd.img]
Décompresseur d'archives .sit et .hqx notamment, incompatible avec certaines archives trop récentes.
Stuffit Expander 5.5 [hd.img] pour système 7 et 68020 ou plus
Version plus récente de Stuffit qui offre une meilleure compatibilité avec certains fichiers .sit.
Fetch 2.1.2 [sit.macbinary]
Client FTP, la méthode la plus simple pour transférer des fichiers en réseau je pense.
Utilitaires Norton [sit.macbinary], en français
Utilitaires Norton 2.0 pour vérifier et effacer disquettes et disques durs. (rip perso)
Pilotes DaynaPORT [hd.img] [dd.img]
Disquette issue de l'image BlueSCSI Bootstrap. La version DD est dépourvue du fichier Diagnostics.sea. Note pour le système 6 : après avoir installé le pilote SCSI/Link et AppleTalk 58 il faut supprimer l'ancien Répondeur du dossier système car une verison plus récente avec le nom en anglais Responder a été ajoutée.
Fix-a-Fork [lien]
Permet de reconstituer le fork de ressources d'un fichier si celui-ci a été perdu lors d'un transfert à travers un système non-Mac (cf. ci-dessous). Ça permet de régler le problème des fichiers qui ne s'ouvrent pas ou dont le type n'est plus reconnu.
BlueSCSI Toolbox [lien]
Outils pour pour transférer des fichiers entre le volume Macintosh et le dossier shared de la carte SD du BlueSCSI, fonctionne aussi dans l'émulateur Snow pour échanger des fichiers avec le système hôte.

Retour au sommaire

🧩 Extensions et tableaux de bord

2020Patch [lien]
Patch pour pouvoir régler la date au-delà de 2019, sous forme d'extension pour le système 7.1 et au-delà, sous forme de patch à installer pour les systèmes plus anciens.
After Dark 2.0x [sit.macbinary]
Écrans de veille très cools 😎 (tout glisser dans le dossier Tableaux de bord) ~ c'est aussi un outil important parce que Mac OS classique ne possède aucune veille et une image fixe qui reste affichée trop longtemps sur un tube cathodique le marque physiquement, mon SE a la barre de menus gravée dans l'écran.
Apple CD-ROM patché [macbinary]
Extension Apple CD-ROM patchée pour supporter les lecteurs de différentes marques ainsi que ceux émulés ~ à glisser dans le dossier Extensions.
Smart Scroll [sit.macbinary]
Tableau de bord pour avoir des barres de défilement modernes dans le Finder et (quasiment) toutes les applications.
Apparence Platinum [sit.macbinary] pour système 7, en français
Offre au système 7 l'apparence de Mac OS 8 avec des fenêtres et des contrôles en relief ! L'archive contient une extension, un tableau de bord et deux polices à déplacer dans le dossier Polices du Dossier Système.
Échange PC - Macintosh [sit.macbinary] [hd.img] pour système 7.1, en français
Tableau de bord offert avec Mac OS 7.5 qui permet de lire et écrire des disquettes au format PC ~ à installer sur le système 7.1 uniquement. Pour le système 6 vous pouvez utiliser Apple File Exchange situé sur la disquette Utilitaires 2 ou Compléments Système.
Clavier canadien (CSA) pour système 7 [sit.macbinary]
À placer dans Dossier Système / System, ensuite la disposition de clavier deviendra disponible dans le tableau de bord Clavier.
Finder Options pour système 7.5.3 [sit.macbinary]
Ajoute des raccourcis clavier au Finder dont Commande-Suppr pour envoyer un fichier à la corbeille !
Programmer's Key [sit.macbinary]
Ajoute les raccourcis Ctrl-Cmd-Power (redémarrage dur) et Cmd-Power (console MicroBug) aux Macintosh de l'ère pré-Quadra/LC ; ça évite de devoir se procurer le « programmer switch » en plastique à clipser sur le côté du boitier :)
MacTCP [sit.macbinary]
Tableau de bord MacTCP 2.0.6 en français qui fonctionne aussi sur le système 6. L'archive inclut l'utilitaire MacTCP Ping pour tester sa connexion ! À partir de Mac OS 7.5 il est préférable d'utiliser OpenTransport normalement inclu dans le système.
Claviers canadiens et polices supplémentaires pour système 6.0.7 [dd.img]
Ce fichier System est à placer dans le Dossier Système en remplacement de l'ancien, il ajoute les dispositions de clavier ISO Canadien (CSA) et Canada Français en plus du AZERTY français et du QWERTY US. J'y ai aussi inclu des polices de caractères qui existaient sur les premiers systèmes Mac et qui ont disparu ensuite : Athens, Cairo, Los Angeles, New York, San Francisco, Seattle, Taliesin, Toronto, Venice.

Retour au sommaire

🎨 Logiciels

MacPaint 1.4 [macbinary], [manuel pdf], en français
La version originale de MacPaint par Bill Atkinson et Susan Kare ! Ce logiciel a défini le standard en terme d'UI pour tous les éditeurs d'image qui ont suivi. Nécessite que le Mac soit configuré avec l'affichage en noir et blanc. La loupe ne fonctionne que sur les Mac compacts traditionnels avec un écran en 512x348.

Certaines fonctionnalités de MacPaint sont cachées : par exemple une sélection est redimensionnable librement en maintenant la touche Commande enfoncée, aussi une sélection est « tamponnable » avec Option. Il est possible de faire plein d'autres choses (cf. le manuel pdf).

SuperPaint 3.5 [dd.img.zip]
Plus complet que MacPaint et plus léger que Photoshop tout en offrant la couleur et plein de fonctionnalités étonnantes, c'est mon éditeur d'images préféré pour Mac 68k. L'archive zip contient 4 images de disquettes DD, il faut toutes les monter puis lancer l'installation depuis la première disquette : dans Customize on peut choisir d'installer une version réduite pour les écrans monochromes. Nécessite un disque dur et 2 Mo de mémoire vive, 68020 ou plus conseillé.
KidPix 2.1 [sit.macbinary], en français
Logiciel de dessin pour enfants avec des bruitages rigolos !! Fonctionne aussi bien en monochrome qu'en couleurs !
ClarisWorks 2.1 [sit.macbinary], en français
Une suite bureautique qui offre traitement de texte, tableur, dessin bitmap, dessin vectoriel et même une mini base de données sur une seule disquette de 800 Ko ! Nécessite 2 Mo de mémoire. (rip perso)
Claris Organizer 2.0 [sit.macbinary] pour système 7, en français
Un agenda électronique je suppose ? (rip perso)
Claris MacDraw Pro 1.5 [sit.macbinary], en français, nécessite QuickDraw 32 bits
Logiciel de dessin vectoriel. Évolution de MacDraw II, lui-même évolution du MacDraw d'Apple, lui-même évolution de LisaDraw. (rip perso)
Microsoft Word 5.1 [sit.macbinary], en français
Le meilleur traitement de texte selon moi mais la version 5 est plus lente que la 4, à essayer de préférence sur un 68030 ou plus. (rip perso)
Microsoft Excel 4 [sit.macbinary], en français
Le fameux tableur pour faire du travail productif avec des chiffres et des formules. (rip perso)

Retour au sommaire

🎲 Jeux

Shufflepuck Cafe [macbinary]
Un des rares jeux d'arcade pour Macintosh et un de mes préférés toute plateforme confondue ! Fonctionne sur 68000 mais plus fluide avec un CPU plus rapide.
Crystal Quest [sit.macbinary]
Il faut ramasser des cristaux sans se faire bolosser par les ennemis mais heureusement on peut leur tirer dessus. Ça se joue à la souris et c'est rigolo !
Prince of Persia [sit.macbinary couleur] [sit.macbinary monochrome]
Le fameux jeu de plateforme, la version couleur est adaptée aux résolutions LC (512x384) et 640x480.
SimCity [sit.macbinary] [manuel pdf]
L'archive contient deux disquettes : la première avec le jeu en monochrome, des villes et des scénarios ; la deuxième avec le jeu en couleurs et un éditeur de terrain. Nécessite 1 Mo de mémoire.
Dungeon of Doom [macbinary]
Un vieux RPG graphique avec une vue en tuiles 2D. J'ai testé un peu il a l'air assez cool ! C'est très vieux (1985), il se lance sur le système 6 avec un Macintosh 68000 mais c'est peu probable qu'il fonctionne sur des machines plus modernes.
The Tinies [sit.macbinary couleur] [sit.macbinary monochrome]
Un jeu de plateau inspiré de Sokoban (vous savez que je kiffe Sokoban). Il faut déplacer des espèces de M&Ms sur des cibles de même couleur mais s'ils se croisent ils explosent. Barre d'espace pour saisir une fripouille, ensuite on la déplace avec les flèches, et encore espace pour la lâcher. C'est marrant et la version couleur possède aussi des musiques cools !

Retour au sommaire

📁 Transférer les fichiers

Pour utiliser toutes ces pépites sur un vrai Mac le plus simple est d'utiliser un gadget moderne qu'on peut brancher à l'ordinateur pour émuler un vieux périphérique.

Moi j'utilise le BlueSCSI qui émule des disques durs, des lecteurs CD et même une carte réseau DaynaPort qui permet de connecter le Mac à Internet ! Mes images .hda et Toast ont été testées avec.
Il existe aussi le FloppyEmu qui émule les lecteurs de disquettes Apple II et Macintosh. Je n'en possède pas, je pense que pour n'importe quel Mac qui possède une interface SCSI c'est pas très utile. Mes images de disquettes .img ont été testées dans les émulateurs Mini vMac et Snow donc elles devraient fonctionner avec le FloppyEmu mais je n'ai pas testé, envoyez-moi un mail si vous l'avez fait !

Comment ouvrir les fichiers proposés au téléchargement ici :

Les paquets MacBinary (.macb) conservent un fichier dans son état d'origine avec ses métadonnées spécifiques au système de fichiers Macintosh, on peut les décoder avec l'outil Stuffit !
Les archives .sit (Stuffit) - format de compression le plus populaire sur Macintosh - permettent de gagner de la place et de transférer des arborescences complètes. Les archives ici sont elles-mêmes encapsulées en MacBinary, le logiciel Stuffit s'occupe du décodage puis de la décompression à la volée.
Les images de disquette .img peuvent être copiées sur de vraies disquettes, émulées par le FloppyEmu ou montées comme disquettes virtuelles avec DiskDup Pro (système 6) ou DiskCopy 6 (système 7).

Retour au sommaire

⚙️ Principes du Mac OS classique

Transfert de fichiers et fork de ressources

Sur Macintosh classique les fichiers ont deux parties : un fork de données et un fork de ressources. Le fork de données peut contenir n'importe quoi de manière non structurée, le fork de ressources contient lui des données structurées pour le Mac : il peut s'agit d'images, de texte, de paramètres... Lorsqu'un fichier est transféré sur un environnement non Mac (comme un serveur Web) ce fork de ressources est perdu. par exemple pour une application, le fork de ressources contient énormément de choses comme des morceaux de code exécutable, des graphismes, les éléments de l'interface utilisateur. Dans ce cas on doit conserver le fichier en entier avec ses deux forks. Pour faire ça on met les fichiers à transférer dans une image disque ou dans une archive.

Certains documents ne contiennent rien dans leur fork de ressources mais ne sont pas reconnues par leurs applications parce que les métadonnées type et creator ont elles aussi été perdues ; ce ne sont pas des morceaux du fork de ressources, ce sont juste des métadonnées du système de fichiers (comme la date de création) mais elles sont nécessaires parce que les applications Macintosh n'utilisent pas les extensions au nom de fichier contrairement à DOS et Windows. Dans ce genre de cas on peut facilement reconstruire cette métadonnée manuellement dans Resedit (File > Get File Info) ou automatiquement avec le très mal nommé Fix-a-Fork. C'est très utile pour les archives .sit qui ne seront pas reconnues par Stuffit si elles n'ont pas les bons codes.

Plusieurs formats d'archive et d'encodage existent pour Macintosh, ceci est une liste des plus courants :

Formats d'image disque à monter :

DiskCopy 4 (.dc42, .img, .image), le plus courant : se monte avec DiskDup Pro et DiskCopy 6
DiskCopy 6 (.img, .image) : se monte avec DiskCopy 6

Formats d'encapsulation pour conserver les deux forks (fichier unique) :

MacBinary (.bin, .macbin) : s'ouvre avec l'application du même nom, binUnpk (open source), Stuffit, BinHex 5.0 et plusieurs clients FTP
BinHex (.hqx) : pareil que MacBinary mais compatible ASCII pour faciliter l'envoi sur les vieux tuyaux (certains FTP et Usenet ?), les fichiers prennent du coup plus de place et sont plus longs à décoder ; s'ouvre avec BinHex 4.0, Tiny Transfer (freeware), et Stuffit notamment

L'outil SD Transfert du BlueSCSI ajoute aux fichiers un code type dérivé de l'extension et cette fonctionnalité est boguée avec les .sit mais aussi les .bin et .macbin empêchant de les ouvrir avec Stuffit. On peut contourner le problème avec les .sit en utilisant Fix-a-Fork et avec les .bin et .macbin en utilisant binUnpk (Fix-a-Fork étant aussi bogué dans ce cas de figure précis). Je contourne le problème à la source en vous proposant des images MacBinary sous l'extension .macb qui n'est pas standard.

Formats d'archive (contenant plusieurs fichiers) :

Stuffit < 5 (.sit) : se décompresse avec tous les outils Stuffit (abandonware)
Stuffit 5 (.sit) : se décompresse avec Stuffit 5.5, les anciennes versions affichent une erreur indiquant que le fichier est corrompu
Mar (.mar) : obscur équivalent à MacBinary mais sous forme d'archive, nécessite l'utilitaire du même nom
Compact Pro (.cpt) : assez peu utilisé, les fichiers s'ouvrent aussi avec Stuffit
Self-extract archive (.sea) : archive exécutable sauf si on a perdu son fork de ressource, dans ce cas elle peut tout de même s'ouvrir avec Stuffit après Fix-a-Fork

Dans le cas d'une archive .sit encodée en BinHex ou en MacBinary Stuffit enchaine automatiquement le décodage puis la décompression.

Le minimum pour ouvrir la plupart des fichiers :

Sur le système 6 avec un 68000 : Stuffit Expander 3.5 et DiskDup Pro
Sur le système 7 avec un 68020 ou plus : Stuffit Expander 5.5 et DiskCopy 6

Dossier Système

Le logiciel système est contenu entièrement dans un unique Dossier Système situé à la racine du volume (disque dur, disquette...). Toutes les disquettes bootables contiennent ce dossier, il suffit de le copier sur un autre volume pour le rendre lui aussi bootable.

Dans le cas où la manip échoue (pas de boot), déplacer ailleurs System puis le remettre dans le Dossier Système fait le taf généralement.

Pour installer un système complet sur son disque dur, c'est quand même mieux d'utiliser le programme d'installation, ça permet de choisir facilement les composants qu'on souhaite y mettre sans devoir faire le tri manuellement.

Un dossier système est valide s'il contient au moins Finder et System, il a alors une icône spécifique. Techniquement le dossier système peut avoir n'importe quel nom et se situer n'importe où sur le disque, il est marqué d'une manière particulière (et mystérieuse) dans le système de fichiers.

Extensions et tableaux de bord

Les extensions ajoutent des fonctionnalités au système, les tableaux de bord aussi mais ces derniers offrent en plus une interface pour effectuer des réglages. Les extensions sont représentées sous forme de pièce de puzzle et doivent se trouver dans le dossier Extensions du Dossier Système situé à la racine du disque. Les tableaux de bord doivent eux se trouver dans Tableaux de bord.

Lorsqu'une extension ou un tableau de bord est glissé sur le Dossier Système le Finder propose de déplacer l'élément automatiquement dans le bon dossier. Parfois l'élément peut avoir besoin d'être accompagné par un dossier qu'il faut déplacer manuellement (par exemple le dossier des écrans de veille d'After Dark qui doit aussi aller dans Tableaux de bord).

Les extensions (et tableaux de bord) sont chargées en mémoire en permanence, sur des systèmes avec peu de mémoire disponible ça peut vite la saturer. Il vaut mieux ne mettre dans les dossiers Extensions et Tableaux de bord que ce que l'on utilise et garder le reste à côté par exemple dans des dossiers Extensions désactivées et Tableaux de bord désactivés.

Il est possible qu'une extension empêche le démarrage du système, dans ce cas démarrer en maintenant la touche Maj enfoncée désactive temporairement toutes les extensions !

Les dossiers Extensions et Tableaux de bord n'existent qu'à partir du système 7, sur le 6 tout est en vrac dans le Dossier Système.

La ROM et la PRAM

Le premier Macintosh de 1984 a 128 Ko de mémoire vive, pour la soulager les composants de base du logiciel système ont été mis dans une autre puce, la ROM (read only memory). À l'origine d'une taille de 64 Ko, la ROM contient des routines (fonctions) pour lire et écrire sur les disques, afficher du texte et des formes à l'écran (les fameuses routines QuickDraw) et effectuer diverses tâches de base d'un système d'exploitation. Les routines sont accessibles à travers une table d'adressage qui elle est en mémoire vive, ça permet de dérouter des appels à la ROM pour patcher certaines routines.

Le Macintosh Classic contient un système complet avec un Finder en ROM, on peut booter dessus en appuyant sur Option-Commande-X-O au démarrage.

La ROM du Macintosh est analogue au BIOS d'un PC à la différence que les routines du BIOS, plus primitives, ne sont réellement utilisées que par DOS. L'intégration du logiciel système et de la ROM fait que cette dernière ne possède pas d'équivalent au setup d'un BIOS. Les réglages de l'ordinateur comme la date/heure et le disque de démarrage se font depuis les différents tableaux de bord du système en cours d'utilisation. Vous pouvez installer le système 7 sur un disque dur puis changer le volume sonore ou le réglage de la souris puis booter le système 6 depuis une disquette et vous verrez que le réglage est synchronisé. Ces réglages sont stockés dans une autre mémoire, la PRAM (parameter ram), et sont persistants par la pile dans la carte mère. Ça explique qu'il faille refaire le réglage de la souris à chaque démarrage sur un Mac dont la pile est morte, et d'ailleurs attention aux vieilles batteries parce qu'elles ont tendance à couler et l'acide détruit la carte mère.

L'astuce magique pour résoudre certains problèmes est de réinititaliser la PRAM en appuyant sur Option-Commande-P-R au démarrage ; le Mac refait alors bong une deuxième fois.

Les disquettes

Les Mac 128K et 512K ne gèrent que les disquettes simple densité de 400 Ko. Le Mac 512Ke, le Plus, le premier Macintosh II ainsi que le premier SE supportent en plus les disquettes de double densité de 800 Ko. Les machines plus modernes dont le Macintosh SE FDHD (ou SuperDrive), les autres Mac II* et le SE/30 entre autres gèrent en plus les disquettes HD de 1,44 Mo.

La capacité d'un Mac à gérer tel ou tel type de disquette dépend évidemment du lecteur branché à l'ordinateur mais aussi de deux autres choses : la ROM ainsi que le contrôleur du lecteur, la puce IWM (integrated woz machine) ou SWIM (super woz integrated machine) à l'ère des disquettes HD.

Par exemple un Macintosh SE de première génération sur lequel on connecte un lecteur HD ne sera capable de lire et d'écrire que des disquettes de 400 ou 800 Ko. C'est à prendre en compte lors de l'utilisation d'un FloppyEmu.

Avant l'arrivée du SCSI, Apple proposait un disque dur externe qui se connectait à l'interface du lecteur de disquettes : le HD20.

SCSI et volume de démarrage

Le port DB25 à l'arrière des Mac n'est pas un port parallèle, ce n'est pas compatible électriquement et brancher n'importe quoi dedans peut endommager le contrôleur. Il s'agit d'un port SCSI ! À partir du Macintosh Plus, tous les Mac 68k disposent d'un bus SCSI. Le port DB25 à l'arrière de la machine est connecté sur le même bus que le port 50 broches interne sur lequel est branché le disque dur pour les machines équipées.

Différents périphériques SCSI peuvent être utilisés en même temps par l'ordinateur en étant chainés les uns à la suite des autres. Chaque périphérique a un numéro entre 0 et 7, ce dernier numéro est réservé par le Macintosh. On peut donc connecter au maximum 7 périphériques SCSI sur une machine, ils seront numérotés entre 0 et 6, sachant que le disque dur interne (s'il y en a un) portera le numéro 0. C'est bien de le savoir pour l'utilisation du BlueSCSI où on doit attribuer soi-même les numéros des périphériques émulés.

Après une installation, une réinitialisation de la PRAM ou un changement de batterie c'est une bonne chose d'aller dans le tableau de bord Démarrage et de cliquer sur le volume de démarrage, ça évite à l'ordinateur de chercher un volume bootable sur le bus ! Sinon par défaut l'ordinateur démarre sur le premier volume bootable en commençant par le numéro le plus haut.

Pour forcer l'ordinateur à booter sur le premier volume SCSI bootable plutôt que sur le volume paramétré, il faut maintenir les touches Option-Commande-Maj-Retour au démarrage ; ça peut être utile si le système installé est cassé.

Retour au sommaire

🚀 Outils pour les machines d'aujourd'hui

Émulateurs

Mini vMac [lien]
Émulateur de Macintosh 68k simple, il suffit d'avoir une ROM nommée Mac OS ROM dans le dossier de l'application sur laquelle on glisse dessus une image de disquette ou de disque dur pour démarrer.
Basilisk II [lien]
Émulateur de Macintosh couleur 68020, 68030 et 68040. Prend en charge les CD-ROM, le réseau et permet de faire des dossiers partagés avec le système hôte.
Snow [lien]
Émulateur plus complet pour les 68000 jusqu'au SE FDHD et le Macintosh II. Il offre une UI très chouette qui permet de connaître le contenu des registres, de la RAM et de déboguer. Il permet de lire des images disques de plusieurs formats et de les enregistrer au format Moof. Contrairement aux deux autres il émule à vitesse réelle mais permet de faire pause ou d'accélérer.
Roms pour émulateurs [lien]
Cette archive contient tout plein de roms !

Utilitaires pour macOS

Disk Jockey [lien]
Outil pour créer et convertir des images de disquette et disque durs pour Mac, Apple II, Atari ST et Amiga entre autres. Utile pour convertir les images .dsk de certains émulateurs en .hda pour le BlueSCSI.
Applesauce [lien]
Logiciel pour le contrôleur de disque du même nom, on peut l'utiliser sans le matériel juste pour analyser des images de disquette et convertir les images Moof au format DC42.

Utilitaires pour Windows

HFS Explorer [lien]
Permet d'ouvrir des images contenant un système de fichiers HFS.

Retour au sommaire

📕 Différentes gammes et générations de Mac 68k

CPU, MMU et FPU : les trois mousquetaires de la carte mère

Les Macintosh 68k ont utilisé les CPU suivants :

68000 (Macintosh 128K, 512K, 512Ke, Plus, SE, Classic, Portable, PowerBook 100)
68020 (Macintosh II, LC)
68030 (Macintosh II*, LC II, LC III, SE/30, Classic II, Color Classic, PowerBook 140-180 et Duo 210-270)
68040/68LC40 (Macintosh LC 475, LC 5*, Quadra, PowerBook 190, 520-550 et Duo 280)

Deux composants sont associés (ou pas) au CPU : le MMU (memory management unit) permet à l'ordinateur de gérer la mémoire virtuelle ainsi que plus de mémoire physique que ce que le CPU permet d'adresser directement, le FPU (floating point unit) permet d'accélérer le calcul des nombres en virgule flottante. La présence de l'un ou l'autre peut impacter la compatibilité de certaines applications avec l'ordinateur bien que les applications qui refusent de démarrer sans FPU sont très rares.

Les Mac 68000 ne possèdent ni MMU ni FPU ;
le premier Macintosh II a un FPU mais pas un vrai MMU, le LC n'a ni l'un ni l'autre ;
les Mac 68030 ont tous un MMU intégré à la puce du processeur et parfois un FPU sur une autre puce ;
les Mac 68040/68LC40 ont tous un MMU intégré et les 68040 aussi un FPU intégré.

Les processeurs 68k fonctionnent à des vitesses d'horloge différentes :

tous les Mac 68000 fonctionnent à 8 MHz (sauf le Macintosh Portable à 16 MHz !) ;
les 68020 sont à 16 MHz ;
les 68030 sont à 16, 20, 25, 33 ou 40 MHz ;
les 68040/68LC40 sont à 20, 25, 33 ou 40 MHz.

Les Macintosh LC475 et LC575 sont overclockables de manière stable jusqu'à 40 MHz simplement par l'installation d'une extension ! Cf les topics sur 68kmla et TinkerDifferent.

Les premiers Mac ont des cartes mères avec des bus de données 16 bits parce que ça correspond à l'architecture du processeur 68000. Les 68020 et suivants sont des processeurs totalement 32 bits (registres, bus de données et d'adresses) mais pour des raisons d'économie certaines machines gardent un bus 16 bits : LC, LC II, Classic II et Color Classic. Avoir un bus 16 bits plutôt que 32 bits entraine une perte de performance de 25% environ par rapport à une machine similaire avec un bus 32 bits mais n'influe pas sur la compatibilité des logiciels.

Résolution d'écran et accélération graphique

Les Macintosh compacts monochromes ont une résolution de 512x342. Le Macintosh II, premier Mac couleur, a une résolution minimale de 640x480 à sa sortie. Le LC qui arrive 3 ans après pour offrir une alternative moins chère est vendu en bundle avec un moniteur de 12" à la résolution étrange de 512x384, ce qui rend certaines applications couleur conçues pour le Mac II incompatibles (tout ne rentre pas sur l'écran). Le Color Classic reprend cette résolution de 512x384.

Le premier Macintosh partage le même 68000 que d'autres machines comme l'Amiga, mais là où ce dernier possède d'autres puces pour fournir une accélération graphique, le Macintosh n'offre rien de ce genre. Le bitmap d'affichage est stocké directement en mémoire vive et c'est la responsabilité du CPU de mettre à jour les pixels en mémoire. Ensuite le circuit vidéo lit la mémoire 16 ou 32 bits (SE) à la fois pour rafraichir l'écran en empêchant le CPU d'accéder à la mémoire. (Guide to the Macintosh Family Hardware 2nd edition, pp. 66, 401)

Le Macintosh II possède une vraie carte vidéo avec de la mémoire dédiée qui permet d'afficher des choses à l'écran plus rapidement puisque le circuit vidéo n'a plus besoin de partager l'accès à la mémoire principale avec le CPU, les deux peuvent lire et écrire dans la mémoire vidéo en même temps. (p. 406) Un autre composant fait son entrée fracassante : le CLUT (color look-up table) qui contient un tableau de correspondances entre les couleurs du mode de l'ordinateur (monochrome, 16 couleurs, 256 couleurs...) et celles affichées à l'écran. Les Mac SE/30 et Classic II possèdent en partie cette circuiterie pour des raisons de performances et de compatibilité. Ça explique la présence de Color Quickdraw en ROM sur ces machines.

Comme sur d'autres plateformes, les couleurs sur Mac fonctionnent en palettes, lorsqu'un jeu demande à passer en 16 couleurs c'est parce qu'il peut définir librement quelles vont être ces 16 couleurs. Le système propose une palette de couleurs par défaut mais le jeu peut très bien choisir 16 teintes de rose par exemple.

Compatibilité des applications

La compatibilité d'une application avec un ordinateur dépend de :

version du logiciel système ;
présence des routines Color QuickDraw en ROM ;
résolution de l'écran et nombre de couleurs gérées ;
présence d'un MMU ;
présence d'un FPU (dans de rares cas).

En général qui peut le plus peut le moins sauf que certains programmes du début de l'ère Macintosh au milieu des années 80 tapaient à des endroits fixes dans la mémoire par exemple pour dessiner à l'écran plutôt qu'utiliser les routines prévues à cet effet. Quand le mappage de la mémoire a changé dans les Mac plus récents ça a posé problème.

Retour au sommaire

🔗 Ressources

Guides

System 6 Heaven, pour profiter à fond du système 6 !
C programming on System 6, tuto de développement C sur un vrai Macintosh Plus en vidéo

Logiciels

Macintosh Garden, énorme collection de jeux et logiciels
Macintosh Repository, l'autre énorme collection de jeux et logiciels
WinWorld, collection d'OS et logiciels pour Mac et PC
Grenier du Mac, jeux et logiciels dont beaucoup en français
BitCider, petite collection de jeux et logiciels en anglais
CDBVS Apple, vieux site avec plein d'OS disponibles en français et des utilitaires
Software for Macintosh Plus and Mini vMac, sélection intéressante de logiciels
The U-M Software Archives, des archives pour Mac mais aussi Apple II, Atari, etc.

Documents

Vintage Apple, plein de livres techniques d'époque et de manuels à télécharger en PDF
Monolithic Macintosh Technical Archive, encore des documents et aussi quelques logiciels
The MacDat Network, beaucoup de manuels de service et de schémas pour ordinateurs et périphériques Macintosh
[PDF] HW 26 - Macintosh Quadra Built-In Video, document essentiel issu d'un post Usenet pour comprendre les fonctionnalités vidéo de tous les Macintosh couleurs sortis après le Mac II, ce PDF décrit essentiellement comment réaliser un adaptateur VGA facilement (votre serviteuse a testé)

Culture

Folklore, histoires et anecdotes sur le développement du Macintosh par ceux qui l'ont créé
Apple Forever, musée virtuel Apple, le site est un travail inachevé figé dans le temps
Investigating MacPaint's Source Code, analyse historique et technique du code de MacPaint
The Long View, blog sur le Macintosh avec de beaux articles historiques et techniques

Numériser des cassettes VHS avec du vieux matériel et du logiciel libre

2021-01-11T00:00:00+01:00

En anglais on a l'expression rabbit hole pour parler d'un trou de lapin dans lequel on s'engouffre lorsqu'on veut résoudre un problème précis et qu'on se retrouve à devoir rechercher beaucoup de choses et faire face à des problématiques subséquentes.

Sauvegarder une vieille cassette vidéo fait partie de ces choses-là. Ça peut paraître simple de prime abord : on branche la sortie vidéo d'un magnétoscope sur un boitier d'acquisition relié à un ordinateur, on lance le logiciel, on démarre le magnétoscope et ça roule (ça déroule plutôt). En réalité les choses ont vite fait de se gâter.

Il y a quelques mois je suis tombée sur cet article terrifiant d'un homme essayant de numériser ses vidéos de famille. Après avoir galéré un bon moment il a préféré tout confier à un professionel. J'ai eu plus de chance avec mes expérimentations et mon matériel, alors je me suis dit que ce serait bien de raconter ça un petit peu.

Je n'ai pas de vidéo familiale à numériser mais ce qui m'intéresse c'est de sauvegarder en bonne qualité les génériques de télévision, de programmes, les éléments d'habillage graphique, les jingles et les mires ; des choses qui souvent ne sont pas toujours documentées ni archivées, du moins pas de manière publique et pratique.

Le matériel

Le magnétoscope que j'ai utilisé est un Panasonic Omnivision stéréo Hi-Fi de la fin des années 90. C'est une bonne période pour ces appareils, ils sont assez récents pour ne pas être trop usés, possèdent des fonctionnalités sophistiquées mais ils sont de meilleure qualité que les derniers appareils fabriqués dans les années 2000.

Pour le boitier d'acquisition, j'ai ce vieux Dazzle DVC100 de Pinnacle depuis presque 10 ans. À l'origine il me servait à regarder Canal+ en analogique à l'aide de K!TV avec le fichier key.txt et le plugin qui avec, la carte était connectée à un démodulateur satellite.

Premiers essais

Étant donné l'âge du boitier, j'ai commencé par installer les pilotes d'époque sur un ordinateur Windows.

J'ai commencé par tester l'acquisition par VLC et premier problème : pas de son. Évidemment je n'ai plus le disque du logiciel de capture propriétaire et payant inclus avec. Après quelques expérimentations avec des choses horribles comme AmaRecTV, je suis partie sur VirtualDub qui miraculeusement recevait le son de la carte. Problème, il y avait des saccades et le son se désynchronisait.

En faisant des recherches j'ai découvert que la solution recommandée était d'utiliser une carte d'acquisition de qualité genre Elgato à plus de 100€, ce que je trouve cher. Et avec du matériel prestigieux le problème aurait-il été résolu pour autant ? Pas sûr. J'ai lu que des problèmes de régularité dans la lecture pourraient provoquer des sauts de trame dans la capture. La magnétoscope est un dispositif mécanique avec des engrenages et des courroies qui s'usent. Pour régler le problème, il faudrait un magnétoscope doté d'un TBC (timebase corrector). Il existe des TBC ligne (pour corriger les effets de tremblement) et des TBC trame. On tape dans du matériel professionnel compliqué à trouver et cher en occasion (à moins de se lever à 6h du matin pour se taper toutes les brocantes et espérer avoir de la chance).

La difficulté à avoir du son m'a quand même fait douter sérieusement des vieux pilotes officiels. Après quelques recherches je suis tombée sur un pilote plus récent mis à disposition sur Reddit. Un progrès : j'ai pu avoir du son avec VLC. Mais là le comportement était étrange. En faisant une capture muette l'image était fluide. En activant le son la capture devenait saccadée, les saccades provoquant évidemment des sauts de trames et la désynchronisation du son.

Linux à la rescousse

Finalement j'ai sorti la clé USB de ma distribution fétiche, à savoir Fedora. L'installation était bouclée en 15 minutes montre en main. J'ai installé vite fait VLC et puis j'ai branché la carte. Non seulement elle est reconnue de suite, mais en plus le son fonctionne correctement et tout est fluide. 🥳

Je me suis senti un peu conne parce que j'aurais du essayer ça dès le début plutôt que me pourrir la vie avec les pilotes pour Windows comme si on était en 1999. Malgré l'absence de TBC, le résultat est très correct tant que la cassette n'est pas trop usée. VLC fait une capture brute du flux vidéo, sans compression ; ça prend vite beaucoup de place donc après avoir capturé mes extraits je les compresse avec Handbrake.

Méthode en résumé

Brancher le magnétoscope sur la carte d'acquisition elle-même connectée au PC ;
mettre en route le magnétoscope ;
ouvrir VLC, aller dans Média > Ouvrir un périphérique de capture ;
choisir les entrée audio et vidéo correspondant à la carte et spécifier explicitement la définition ;
le flux vidéo doit s'afficher, sur un magnétoscope moderne en général un écran bleu : activer la barre d'outils spéciale enregistrement (Vue > Contrôles avancés) ;
appuyer sur le bouton 🔴 ;
démarrer la lecture sur le magnétoscope ;
appuyer encore sur 🔴 pour arrêter ;
une fois qu'on a un bon gros fichier (par défaut enregistré dans ~/Vidéos), il faut l'encoder avec Handbrake, on peut en profiter pour le désentrelacer par la même occasion.

Concernant la définition

Pour la définition verticale, il faut choisir en fonction du standard vidéo, à savoir 480 lignes pour du NTSC ou 576 lignes pour du PAL/SÉCAM, pour une image complète. On parle ici des lignes visibles qui sont capturées par le dispositif, à ne pas confondre avec le nombre total de 525 ou 625 lignes (respectivement) comprenant le VBI sur la source analogique, ce qui ne nous intéresse pas.

Pour la définition horizontale c'est plus compliqué. En analogique il n'y a pas de pixels mais on parle de points par ligne, définissant une certaine netteté. Il est de coutume de dire que les VHS « ont 300 points par ligne ». Parfois par abus de langage on entend même des choses confuses comme « les VHS ont une définition de 300 lignes » ce qui est faux : le nombre de lignes ne change jamais.

La précision de chaque ligne est variable en fonction du type de magnétoscope utilisé pour enregistrer (VHS, S-VHS, Betamax...), de la source d'origine, du standard vidéo et de la qualité de la cassette.

Il est de coutume de numériser le signal avec des lignes de 720 pixels, quel que soit le nombre de lignes. C'est souvent comme ça sur les DVD. Un DVD en NTSC contient en général une vidéo à 720x480, pourtant ce n'est pas un ratio de 4:3, d'ailleurs c'est la même définition pour les DVD en 16:9. Il n'y a pas de rapport entre la définition en pixels et le ratio de l'image. Le ratio est défini séparément dans le fichier et le lecteur étire l'image correctement. On parle alors de pixels rectangulaires.

Pour une capture européenne, si la carte d'acquisition le permet vous pourrez peut-être numériser en 768 pixels de large. Si c'est le cas tant mieux, ça donnera des pixels carrés pour un ratio de 4:3 et c'est plus précis que 720 pixels. Dans tous les cas c'est mieux de prendre la valeur la plus haute.

Fréquence d'image

C'est mieux de prendre la plus haute possible relativement au standard vidéo pour ne pas avoir de saccades : c'est-à-dire maximum 25 images/s en Europe ou 29,97 pour du NTSC. En vidéo analogique traditionnellement on transmet une ligne sur deux à chaque trame. On transmet toutes les lignes paires, elles s'affichent sur la télévision qui laisse un vide à la place de chaque ligne impaire, puis à la trame suivante on fait l'inverse. Il y a respectivement 50 ou 59,94 trames par seconde. Lors de la capture vidéo, les deux dernières trames sont assemblées, résultant en une image entière assez laide avec un effet peigne. Au moment de l'encodage on va pouvoir faire un désentrelacement propre.

Avant et après le désentrelacement

Paramètres d'encodage

J'ai calculé que la vidéo brute prenait environ 1,2 Go par minute, c'est beaucoup. Après compression en très bonne qualité en H265 on passe à 25 Mo par minute sur un enregistrement avec un peu de neige. C'est à peu près la même chose pour le WebM avec codec VP9.

Encoder une vieille vidéo avec du bruit ce n'est jamais très optimal, il faut bien doser les paramètres pour garder une vidéo finale de bonne qualité et éviter qu'aux défauts historiques de la cassette ne viennent s'ajouter des macroblocs MPEG ignobles.

Dans Handbrake à l'onglet Dimensions, j'ai désactivé le rognage (zéro partout) et j'ai décoché Garder l'aspect dans Géométrie d'affichage. À la place j'ai spécifié une largeur d'affichage de 640 pour une vidéo NTSC de 480, de sorte que l'aspect d'affichage soit de 4:3. Sur une vidéo européenne j'aurais mis 768 à la place de 640. Il s'agit là du ratio, on ne modifie en rien la définition du flux vidéo.

Pour la compression en H265 j'ai choisi un facteur RF22 qui me donne un bon compromis entre le poids et la qualité. En WebM avec VP9/Opus la qualité CQ19 proposée par défaut semble être suffisante aussi. Le mieux c'est de faire des tests avec des petits extraits pour trouver le bon taux.

J'ai vu que Handbrake proposait des options intéressantes comme des filtres pour appuyer la netteté. Je n'ai pas tout testé parce que les encodages prennent du temps, mais il y a probablement moyen d'optimiser encore les rendus.

À propos du désentrelacement, normalement Handbrake détecte tout seul le type de vidéo et applique automatiquement les bonnes options. La méthode de désentrelacement par défaut me semble identique à Yadif. C'est peut-être plus sûr d'activer explicitement Yadif pour être certain que le désentrelacement se fasse partout et pas sur une détection dynamique.

Pour le son, il ne faut pas hésiter à l'encoder en bonne qualité, je mets au minimum 192 kb/s s'il s'agit d'une cassette avec le son Hi-Fi. Le son mono à l'ancienne est vraiment déplorable. Le son stéréo lui par contre est enregistré en FM avec une qualité honorable. Ça vaut le coup de se trouver un magnétoscope Hi-Fi stéréo pour cette raison-là.

Handbrake affiche dans l'onglet « Résumé » les options appliquées au fichier

Pour couper un extrait ou enlever un morceau de vidéo on peut utiliser Avidemux qui est un logiciel bien pratique, un peu dans la veine de VirtualDub à l'époque. Il permet de travailler sur des vidéos brutes ou encodées. Dans ce dernier cas, en faisant des coupures proprement sur des images clé, il est possible d'exporter un extrait de vidéo sans réencodage.

Pour conclure

On peut numériser des cassettes correctement sans matériel coûteux et en utilisant uniquement des logiciels libres. Ce n'est pas très compliqué mais ça peut prendre beaucoup de temps selon la longueur des vidéos et la puissance de l'ordinateur à disposition, la vitesse d'encodage en étant dépendante.

Je termine avec quelques extraits de captures qui m'ont permise d'être sûr que le son et l'image restaient synchonisés.

Un court extrait du Dîner de cons
(le petit décalage horizontal est un problème du transfert original)

Un extrait de Monstres inc. pour ceux qui se souviennent de la cassette bleue
(on voit la protection anti-copie Macrovision tout en haut)

Si vous avez des questions, des suggestions, que vous souhaitez apporter des précisions ou corriger une erreur, n'hésitez pas !

Liens et références

Personnaliser le listage des dossiers dans Apache

2020-09-05T00:00:00+02:00

Apache httpd est un super serveur Web qui propose un tas de modules pour faire ce dont on a besoin. En général sur les distributions Linux populaires il est préconfiguré pour afficher la liste des fichiers présents si on accède à un répertoire qui ne contient pas de fichier index.html ou index.php. Nous allons voir ici comment personnaliser cet affichage pour le rendre plus pratique et plus beau.

Je pars d'une distribution Debian, la configuration par défaut est différente sur d'autres systèmes comme par exemple FreeBSD.

Le listage par défaut de Apache

Processus d'affichage de l'index

Lorsqu'on demande l'accès à un chemin, le serveur va d'abord essayer de trouver un fichier d'index. S'il n'en trouve pas, il va déclencher le listage du dossier. Cet aiguillage se fait via le module mod_dir activé par défaut.

Dans le fichier /etc/apache2/mods-enabled/dir.conf on peut voir le contenu suivant :

<IfModule mod_dir.c>
        DirectoryIndex index.html index.cgi index.pl index.php index.xhtml index.htm
</IfModule>

C'est ici que sont définis les différents noms de fichiers pouvant être considérés comme index. Si un dossier contient plusieurs fichiers candidats comme par exemple index.html et index.php alors ce sera le premier de la liste qui sera affiché.

Ainsi si aucun fichier d'index n'est présent alors la génération de la page de listage va se faire par le module mod_autoindex mais à la condition que l'option Indexes soit activée pour le dossier.

Dans le fichier /etc/apache2/apache2.conf on trouve entre autres :

<Directory /var/www/>
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

Ici l'option est activée pour le répertoire par défaut /var/www/ et ses sous-dossiers.

Le module de listage

Les inconvénients de la configuration par défaut

Tout se passe dans le fichier /etc/apache2/mods-enabled/autoindex.conf qui contient par défaut un certain nombre de choses pour améliorer déjà pas mal l'aspect de la page, comme l'option FancyIndexing et HTMLTable qui créent un affichage enrichi et mis en forme dans un tableau HTML avec des colonnes de tri.

Sans ces options, mon dossier ressemble à cela :

Je suis satisfaite de l'affichage fancy mais je voudrais faire certains changements :

retirer la colonne de description qui ne sert à rien ;
retirer la ligne du bas qui contient la version du serveur et le domaine ;
ajouter un entête avec un titre ;
ajouter un lien pour revenir au domaine principal ;
rendre compatible l'affichage avec les mobiles ;
harmoniser un peu le style avec le reste du site.

Retrait des colonnes superflues

Le retrait de la colonne de description se fait très simplement en rajoutant l'option SuppressDescription à la directive IndexOptions située en début de fichier.

Pour gagner de la place et parce que les dates de fichiers sont rarement les bonnes, j'ai décidé de supprimer aussi la colonne Last modified avec SuppressLastModified.

L'entête et le pied de page

En ce qui concerne ces éléments, le module est réglé pour aller chercher des fichiers HEADER.html et README.html différents pour chaque dossier affiché. Moi je veux des fichiers uniques pour tout le domaine donc je configure les deux directives suivantes comme ceci :

ReadmeName /.footer.html
HeaderName /.header.html

Le / permet de réutiliser les mêmes fichiers partout dans l'arborescence. J'ai fait des fichiers cachés (ils commencent par un point) pour éviter leur apparition dans la liste.

Pour le moment mon entête contient seulement un bloc <h1> et mon pied de page un <a>.

Le mélange entre l'affichage d'une liste de ressources et un contenu directement sur la page me fait beaucoup penser au protocole Gopher des années 90 et son équivalent moderne Gemini.

Affichage mobile, favicon et titre d'onglet

Pour l'affichage mobile il faut rajouter une ligne dans le <head> et je vais en profiter pour ajouter un titre d'onglet et mettre un favicon.

Par défaut le serveur rajoute l'entête HTML suivant :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
 <head>
  <title>Index of /</title>
 </head>
 <body>

Pour désactiver cet entête automatique il faut rajouter l'option SuppressHTMLPreamble à IndexOptions. Ensuite on est libre de mettre le notre. À noter que du coup il faut rajouter les balises fermantes dans l'autre fichier, même si leur absence ne pose jamais problème dans la réalité.

Mon fichier .header.html ressemble maintenant à ça :

<!DOCTYPE html>
<html>
 <head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <link rel="icon" type="image/png" href="https://example.com/assets/favicon.png">
  <title>data.example.com</title>
 </head>
 <body>

L'encodage est par défaut en UTF-8 donc je ne fais que l'expliciter. C'est la propriété de viewport qui permet de corriger l'affichage.

Il existe une directive IndexStyleSheet pour spécifier une feuille de style CSS mais elle ne fonctionne pas avec SuppressHTMLPreamble, la solution est de spécifier un fichier CSS dans l'entête ou d'incorporer un bloc <style>.

Voilà le résultat final pour le moment. On ne peut pas tout personnaliser, par exemple pas possible de changer la langue des labels. En fouillant un peu on s'aperçoit que les labels sont codés en dur dans le fichier source mod_autoindex.c, par exemple pour les titres de colonnes à partir de la ligne 1584.

Le principal intérêt c'est d'utiliser un module par défaut qui génère des pages HTML, ce qui m'évite de devoir passer par des navigateurs de fichiers en PHP plus lourds et peut-être moins sécurisés.

Afficher une image en VGA mode 13h (assembleur x86)

2020-08-15T00:00:00+02:00

Depuis la nuit des temps, les PC possèdent différents modes texte et graphique. Chaque mode possède une résolution et un nombre de couleurs spécifique. Un de ces modes est assez facile à manipuler et permet d'afficher jusqu'à 256 couleurs en 320x200, il s'agit du mode 13h, populaire à l'époque des jeux et applications MS-DOS.

Ici on va voir pas à pas comment dessiner à l'écran sur DOS en utilisant l'assembleur Netwide (NASM) depuis un environnement de type Unix pour générer le fichier exécutable (on va travailler avec DOSBOX).

Les modes vidéo classiques pour PC sont nombreux et certains ne sont pas très intéressants ou alors complexes à manipuler, comme le mode 12h qui fournit du 640x480 en 16 couleurs mais planaire, c'est à dire que chaque canal (rouge, vert, bleu, fluo) doit être manipulé séparément. Le mode 13h auquel on va s'intéresser permet de manipuler intuitivement les couleurs et la position des pixels à l'écran. Il offre un bon compromis entre simplicité et agrément.

Je suis loin d'être experte ni en assembleur ni même en développement pour DOS, je voulais juste partager ce que j'ai appris et réussi à faire !

Un exemple de graphisme en mode 13h : Rayman pour DOS (1995)

Préparation de l'environnement

Pour commencer, on a besoin des outils suivants : NASM, Dosbox et un éditeur de texte.

Pour Fedora on installe ça comme ça :

sudo dnf install nasm dosbox

Pour macOS (en supposant que brew est préalablement installé) :

brew install nasm dosbox

Ensuite on se crée un dossier de travail, par exemple ~/workspace/dos/vga chez moi. Puis on configure Dosbox pour monter le dossier et y accéder au démarrage. On ouvre Dosbox une première fois pour vérifier que ça fonctionne, puis on édite le fichier de configuration (dont le nom peut changer selon la version).

Sur Fedora Linux il est situé dans ~/.dosbox/dosbox-0.74-3.conf, sur macOS dans ~/Library/Preferences/DOSBox 0.74-3 Preferences.

Tout à la fin dans la section [autoexec] j'ai rajouté les lignes suivantes :

mount C: ~/workspace/dos/vga
C:

Un premier programme

Dans le dossier on peut créer un fichier texte, disons main.asm. Voici un premier contenu :

org 100h

; Passage en mode 13h
    mov ax, 13h
    int 10h

; Attente appui touche
    mov ah, 00h
    int 16h

; On retourne au DOS
    ret

Les commentaires sont les lignes qui commencent par le point-virgule. On peut aussi rajouter un commentaire à la fin d'une ligne.

Ce que tout cela signifie

La notation hexadécimale

Les nombres qui possèdent un h à la fin sont des nombres héxadécimaux, donc en base 16. On les représente avec des caractères de 0 à F. Par exemple FF égale 255 et FFFF égale 65535. Par défaut, pour notre assembleur, un nombre est décimal, mais lorsqu'on va utiliser des interruptions ou des adresses mémoires on va utiliser des nombres héxadécimaux. C'est pratique parce qu'on sait qu'un nombre d'un ou deux caractères tient dans un octet (8 bits) et qu'un nombre de 3 ou 4 caractères tient dans un mot (16 bits). Il y a deux manières de les noter dans notre code :

Ajouter devant 0x, par exemple 0x100.
Ajouter après h, par exemple 100h. Dans ce cas, si le nombre commence par une lettre, il faut mettre un zéro devant. On n'écrira donc pas FFh mais 0FFh.

La directive `org`

Concernant org, il s'agit d'une directive et non pas d'une instruction (car org n'existe pas dans le processeur). Cette directive s'adresse à notre assembleur pour lui dire que notre programme doit commencer à un certain endroit (à 100h). Ainsi lors de l'assemblage, le programme va être adapté pour que les adresses internes correspondent bien à l'endroit où le DOS démarre notre programme. C'est une particularité du format d'exécutable COM, contrairement au EXE qui n'a pas besoin de ça et qui permet de faire des fichiers plus gros (+ de 64 kb), mais le EXE est plus compliqué pour la gestion de la mémoire ; ici on va travailler sur un fichier COM à l'ancienne.

Les instructions `mov`

Pour travailler avec le CPU, on utilise des petites zones de mémoire appelées des registres. Il est possible de faire des opérations (comme écraser, additionner, soustraire...) entre une cellule de RAM et un registre ou deux entre registres, mais pas entre deux valeurs en RAM.

Dans notre premier code, chaque mov écrit dans un registre la valeur indiquée. Si quelque chose était présent avant dans le registre, c'est écrasé par la nouvelle valeur. Ainsi le premier mov inscrit la valeur 13h (19 en décimal) dans AX, donc les 16 bits du registre contiennent 0013h.

Le deuxième mov inscrit la valeur 00h (0 aussi en décimal) dans le registre AH. Là il faut savoir qu'en fait le registre AX (qui fait 16 bits) est composé de deux demi-registres, qui sont AH (high) et AL (low) qui sont chacun de 8 bits. C'est pareil pour BX, CX et DX.

Ici on aurait pu éviter ce second mov étant donné que AH contenait déjà 00h et que rien ne vient modifier le registre entre temps, mais on l'a fait par clarté et pour ne pas casser le programme si on rajoute des instructions plus tard.

Les interruptions

De façon générale, le concept de l'interruption est... d'interrompre le déroulement régulier du programme pour effectuer une tâche prioritaire avant de retourner à ce qu'on faisait. Il en existe plusieurs types, par exemple les interruptions matérielles (une frappe clavier ou un clic de souris). Ici on va plutôt parler des interruptions logicielles qu'on déclenche nous-mêmes avec l'instruction int et qui nous permettent d'exécuter des procédures situées en dehors de notre programme ; soit fournies par le BIOS, soit par le DOS.

Dans notre code, la première interruption 10h permet de demander au BIOS de changer de mode vidéo. Elle prend deux paramètres : dans AH le service (ou fonction) voulu (nous on veut 00h pour le changement de mode) et dans AL le mode vidéo voulu (13h en l'occurence).

La seconde interruption 16h permet de travailler avec le clavier. Sa fonction 00h (paramètre AH) permet de demander la lecture d'un caractère et donc d'attendre que l'utilisateur appuie sur une touche. Elle ne prend pas d'autre paramètre mais renvoie dans AH et AL les codes de la touche appuyée (on ne s'en sert pas ici).

Avec le DOS on utilise souvent l'interruption 21h qui permet d'accéder à différents services du système.

L'instruction `ret`

Comme un CPU possède peu de registres, régulièrement on se retrouve obligé de stocker les valeurs des registres dans un coin pour bricoler autre chose, puis restaurer les anciennes valeurs pour retourner à ce qu'on faisait avant.

Pour jongler avec la mémoire, il existe un outil pratique : c'est la pile. C'est une zone de mémoire vive dans laquelle on empile les valeurs dont on va se resservir, puis qu'on dépile une fois qu'on en a besoin. C'est comme une pile d'assiette, c'est à dire que pour accéder à la troisième assiette il faut avoir dépilé les deux premières avant.

La pile est utilisée par plusieurs instructions !

Pour appeler une procédure on utilise l'instruction call qui stocke dans la pile l'adresse de la prochaine instruction à exécuter dans notre programme avant de sauter à l'emplacement de la procédure.
L'instruction ret fait l'inverse : elle est située à la fin d'une procédure et permet de revenir où on était en récupérant l'adresse stockée dans la pile.

Ce qui est intéressant dans le cadre d'un programme DOS, c'est qu'à l'ouverture d'un programme, le DOS empile automatiquement la valeur 0000. En faisant ret depuis le fil principal on exécute alors l'instruction située à l'emplacement 0000 de la RAM, et là le DOS y a situé automatiquement une interruption 20h qui sert à retourner à l'invite de commandes, donc à terminer proprement.

Raymond Chen explique ça en détail ici, son blog est excellent.

Création d'un exécutable

Pour créer le fichier exécutable, on assemble avec une commande :

nasm -o main.com main.asm

Ça crée un fichier COM exécutable pour DOS. Si tout se passe bien, l'assembleur n'affiche pas de message.

Dans DOSBOX, il suffit de taper main.com ou simplement main pour que le programme se lance. Tout ce qu'il fait, c'est afficher un écran noir. Une fois qu'on appuie sur une touche on revient au prompt mais le texte est gros et pixellisé : c'est normal, nous avons basculé en mode 13h et nous y sommes resté.e.s.

Pour que le programme retourne dans le mode texte par défaut (03h) avant de quitter on peut rajouter les lignes suivantes à la fin (mais avant le ret) :

; Retour en mode texte
mov ax, 03h
int 10h

On appelle la fonction 00h (changer de mode) pour le mode 03h, dans l'interruption 10h.

Afficher un pixel sur l'écran

On passe définitivement aux choses sérieuses !!! Ce qui est bien avec le DOS et le mode 13h, c'est qu'on peut se contenter de mettre un nombre dans une zone de mémoire pour colorer un pixel.

La zone de mémoire qui nous intéresse commence à l'adresse A000:0000 et s'étend sur 64000 octets (=320x200). Il s'agit d'un mode de 256 couleurs et un octet fait 8 bits ce qui est le nécessaire pour définir une valeur entre 0 et 255 (2ˆ8 = 256).

La palette par défaut en mode 13h [source]

Les couleurs sont arrangées dans cet ordre un peu bizarre parce que la palette est rétro-compatible avec le mode 16 couleurs (la première ligne). Il est possible de redéfinir la palette à partir des 262 144 couleurs disponibles (64ˆ3), ce qui est très pratique pour avoir des teintes personnalisées ou pour remplir les 8 dernières cases.

Autre chose bien pratique, on passe d'une ligne de pixels à l'autre sans coupure. Il n'y a pas de complexité liée au balayage. Ainsi, pour afficher un pixel pile au milieu de l'écran, on doit descendre de 100 lignes (100x320) et aller vers la droite d'une demi-ligne (320/2). Ce qui nous donne 32000 + 160 = 32160. Ce sera donc notre décalage par rapport à l'adresse de base.

VGA c'est pour Video Graphics Array, c'est littéralement de ça qu'il s'agit !

Les ordinateurs de cette époque, comme par exemple les différents IBM PS/2, avaient entre 512 Kio et 1 Mio de mémoire vive et certains étaient extensibles jusqu'à 4 Mio. Problème : les registres du Intel 8086 étaient de 16 bits tout au plus, ce qui permet de contenir des adresses allant jusqu'à 65535 (FFFF en hexadécimal) donc 64 Kio. Pour résoudre le problème, on utilise un système de segments et d'offsets. Contrairement à ce que voudrait l'intuition, les segments ne s'enchainent pas tous les 65535 octets mais plutôt tous les 16 octets. Ils se chevauchent, donc une zone mémoire peut être accessible par plusieurs adresses. Cf. cours de Benoît M.

Ce qui est essentiel ici c'est surtout de savoir que le framebuffer VGA commence au segment 0A000h et à l'offset 0000h.

Dans notre programme, juste après le passage en mode 13h, on ajoute la première partie de notre adresse dans le registre de segment ES (pour extra segment). On ne peut pas y écrire directement, on doit passer par un registre général.

mov ax, 0A000h
mov es, ax

La prochaine étape est d'indiquer l'offset que nous avons calculé. Pour cela on utilise DI (destination index) qui est un des différents registres d'offset disponibles sur le processeur. On peut y insérer directement la valeur en décimal calculée.

mov di, 32160

Enfin on peut choisir une couleur dans la palette (ici un genre de orange) et l'appliquer à notre pixel.

mov al, 058h
mov [es:di], al

Les crochets signifient que ES:DI est une adresse de mémoire à laquelle on veut écrire.

Affichage d'une ligne

Maintenant que nous avons un pixel nous pouvons utiliser une boucle pour générer une ligne. Les étapes suivantes seront l'affichage de plusieurs lignes pour composer un rectangle, puis enfin afficher notre image. Pour faire une boucle, on utilise simplement l'instruction loop.

Remplaçons notre ligne mov [es:di], al par la structure suivante :

mov cx, 50
ligne:
    mov [es:di], al
    inc di
    loop ligne

La ligne d'origine qui insère la couleur à l'écran est toujours la même, par contre des choses se sont rajoutées autour. La première chose notable est ligne:, il s'agit d'un label, c'est une sorte de marque-page qui marque un endroit dans le code. Ils permettent de facilement se repérer et d'y faire des sauts. Le rôle de l'instruction loop est de décrémenter CX puis de revenir au label tant que CX est plus grand que zéro. Ainsi on boucle 50 fois et le décompte est automatique. On a aussi une instruction inc di qui incrémente le registre DI à chaque passage pour avancer horizontalement octet par octet pour créer une ligne. On aurait aussi pu écrire add di, 1 , c'est pareil.

Affichage d'un rectangle

Pour afficher un rectangle on reste sur le même principe en faisant une boucle sur la boucle. La seconde boucle permet de descendre pour tracer la forme ligne par ligne. Problème : on ne peut pas imbriquer les utilisations de loop puisque cette instruction fonctionne en utilisant le registre CX (on ne peut pas en choisir un autre). Ce n'est pas grave, on peut utiliser un saut conditionnel qui fait à peu près la même chose.

Au dessus de mov cx, 50 on rajoute un registre BX qui contient le nombre de lignes (hauteur du rectangle) ainsi qu'un autre label.

mov bx, 30
colonne:

En dessous du loop, on rajoute aussi quelques instructions :

    add di, 320 ; on passe à la ligne suivante
    sub di, 50  ; on se remet au début dans la ligne
    dec bx
    cmp bx, 0
    jne colonne

En ce qui concerne add et sub la première instruction permet de passer à la ligne suivante (une ligne fait 320 pixels). La seconde instruction permet de revenir au début de cette même ligne. On pourrait très bien utiliser une seule instruction et faire add di, 270 mais séparer le processus en deux instructions peut être plus clair ou plus pratique pour plus tard.

Les trois dernières instructions sont équivalentes au loop, avec simplement l'utilisation du registre BX à la place de CX. jne signifie jump if not equal et va sauter au label indiqué tant que le résultat de l'instruction du dessus n'est pas l'égalité. Étant donné qu'on décrémente BX à chaque tour, au bout de 30 fois BX va égaler zéro et le jump ne fera plus effet.

Code complet entre le passage en mode 13h et l'attente clavier :

; affichage d'un rectangle
mov ax, 0A000h
mov es, ax      ; ES = segment du framebuffer VGA
mov di, 32160   ; milieu de l'écran (en base 10)
mov al, 058h    ; couleur orange clair
mov bx, 30      ; nombre de lignes
colonne:
    mov cx, 50  ; nombre de pixels par ligne
    ligne:
        mov [es:di], al
        inc di
        loop ligne
    add di, 320 ; on passe à la ligne suivante
    sub di, 50  ; on se remet au début dans la ligne
    dec bx
    cmp bx, 0
    jne colonne

Préparer une image pour l'afficher

Avant de pouvoir insérer une image dans le programme on doit la convertir en 256 couleurs dans la palette VGA. Je vous renvoie à ce tutoriel qui explique comme le faire avec GIMP. Vous pouvez jouer avec les options de luminosité et de contraste comme je l'ai fait pour avoir le meilleur rendu possible après conversion.

Réduction à 150x150 px

Le fichier converti

Ensuite il faut extraire les pixels du format BMP pour avoir une suite d'octets à insérer dans le programme. J'ai fait un script en Python pour ça : bmptovga.

Affichage d'une image

Quelques petites adaptations sont nécessaires pour afficher une image. Pour commencer on peut importer notre fichier .asm généré par le script dans le même dossier que main.asm puis l'importer dans notre programme. Pour cela, on ajoute la ligne suivante à la toute fin, après le ret.

%include "image.asm"

Pourquoi à la fin ? Pour éviter que cette partie de ressource image soit interprétée comme du code ; en effet, il n'y a pas de séparation stricte entre le code et les données. Une autre solution moins simple aurait été d'insérer un saut jmp et un label pour sauter par-dessus la ressource.

L'autre chose à modifier est notre position de début de dessin dans le registre DI. L'image fait 150x150 px, pour l'afficher centrée il faut qu'elle débute aux coordonnées (320-150)/2 ; (200-150)/2, ce qui nous donne 85;25. On convertit cette coordonnée avec la formule x + (320 * y), ce qui nous donne 8085.

Ensuite il faut modifier BX et CX qui sont respectivement à 30 et 50 pour les mettre tous les deux à 150 ainsi que sub di.

On peut déjà tester si c'est bon !

Plutôt que charger chaque couleur directement on peut indiquer l'adresse de la ressource image dans un registre. On peut donc retirer le mov al. La méthode consiste maintenant à aller chercher la valeur située à l'adresse du label image: (déclaré dans le fichier .asm), qui contient la couleur du premier pixel de l'image. En incrémentant notre registre, on se déplace d'adresse en adresse et à chaque fois on récupère le pixel correspondant.

Pour faire ça nous ne pouvons pas utiliser AL, c'est une limitation du processeur. Les seuls registres d'index disponibles sont BP, SI, DI et BX. Les deux derniers sont déjà utilisés mais SI est libre.

On remplace donc l'ancienne instruction qui donne la couleur par :

mov si, image

Dans le label ligne:, on extrait la valeur (le code couleur) à l'adresse située dans SI pour la stocker dans AL, on rajoute donc cette instruction juste après le label :

mov al, [si]

Les crochets signifient qu'on copie dans AL la valeur à l'adresse contenue dans SI, mais pas SI directement. La ligne suivante reste intacte, puisqu'on copie toujours notre valeur à l'adresse indiquée par ES:DI.

Ensuite on incrémente DI pour se déplacer de pixel en pixel sur la ligne. On va juste en dessous rajouter un incrément pour SI sous la forme inc si, pour se déplacer en même temps d'octet en octet dans l'image.

Maintenant tout est prêt et notre image va apparaître.

Fichiers complets : main.asm, image.asm.

Détails additionnels

Optimisation 16 bits

Plutôt que travailler octet par octet pour afficher l'image, on peut aussi profiter des registres 16 bits et travailler mot par mot. Dans ce cas, on utilise AX plutôt que AL dans la boucle ligne mais il faut alors remplacer inc di et inc si par add di, 2 et add si, 2 pour avancer de deux octets à la fois. Par conséquent, il faut diviser par deux la valeur de CX qui définit le nombre d'itérations de la boucle. En 75 itérations on parcourt 150 pixels.

    mov cx, 75
    ligne:
        mov ax, [si]
        mov [es:di], ax
        add di, 2
        add si, 2
        loop ligne

Utilisation d'une palette

On ne l'a pas vu ici pour des raisons de simplicité mais on pourrait utiliser une palette VGA personnalisée qui correspond mieux à l'image. L'inconvénient de cette approche, par exemple dans le cas d'un jeu, est qu'il faut changer de palette selon le contexte.

Ratio d'image

Le mode 13h fournit un canevas de 320x200 : ça correspond à un format 16:10, pourtant à l'époque du DOS les écrans étaient en 4:3, ce sont des pixels rectangles. On aurait pu étirer notre image horizontalement (anamorphose) pour compenser l'étirement vertical de l'affichage. DOSBOX a fait le choix par défaut d'afficher le mode 13h en pixels carrés.

Pour mon jeu de Sokoban, j'ai compensé le ratio en utilisant des sprites rectangulaires. Ce n'est pas le choix qu'a fait l'auteur de Planet X3, il a préféré garder des sprites carrés certainement pour plus de simplicité et le jeu reste très joli même en 4:3. Même chose pour SimCity. Cette vidéo parle bien du problème.

Planet X3 pour DOS

Pour aller plus loin

Tuto assembleur x86 de Benoit M. : il s’apparente surtout à un manuel, mais très complet et rédigé en français.
fysnet.net : plein d’articles sur la programmation pour DOS en assembleur et en C.
Ralf Brown’s Interrupt List : liste très complète d’interruptions du DOS et d’autres programmes.
VGA Color Palettes : palettes de couleurs par défaut des différents modes VGA.
256-Color VGA Programming in C : page didactique dédiée à la programmation en VGA sur DOS (exemples de code en C). (web archive)
PC DOS Retro : de nombreuses pages de documentation sur DOS, vers la fin on trouve une liste des scancodes complets pour le clavier. (web archive)
Atrevida Game Programming Tutorials : tutos sur la programmation de jeux pour DOS, certaines choses sont en C et d’autres en assembleur. (web archive)

Histoire et évolution du téléphone fixe

2020-05-14T00:00:00+02:00

Je fais cet article pour partager le fruit de mes recherches et de mon expérience sur comment utiliser un vieux téléphone sur une ligne numérique en 2019 avec toutes les fonctionnalités (sonnerie, réception d'appel et composition) et puis pour bavarder un peu sur le sujet.

J'adore l'appareil traditionnel, le téléphone à la papa, le poste électromécanique avec ses cloches qui sonnent pour de vrai, le combiné ergonomique et le cordon en spirale. Ces objets sont simples, bien conçus et très solides, ils tiennent le coup pendant des décennies ; après 40 ans souvent un simple nettoyage suffit pour les remettre en route.

Les téléphones traditionnels étaient éco-responsables sans même le vouloir. Comment ? Parce qu'ils n'étaient pas des objets de consommation. Le poste n'était pas vendu mais loué par la compagnie de téléphone qui l'avait conçu pour son réseau et généralement interdisait que l'on branche tout autre appareil non-approuvé sur la ligne. L'histoire du Carterphone aux États-Unis est très intéressante.

En France, le modèle S63, au début en gris puis plus tard en multiples coloris, au début en cadran rotatif puis plus tard à touches, a été distribué dans les foyers français de 1963 jusqu'à 1985. En Amérique du Nord, les modèles 500 (rotatif), 1500 (à 10 touches) puis 2500 (à 12 touches) ont équipé les foyers américains et canadiens pendant toute la seconde partie du XXe siècle.

Le modèle S63 français proposé en plusieurs couleurs

Téléphone Western Electric 2500

Vieille histoire

On prête souvent l'invention du téléphone à Graham Bell, en fait il semble vraiment que non, mais que bell signifie cloche reste une belle coincidence. L'histoire est compliquée mais en tous cas l'invention a d'abord été théorisée par Charles Bourseul que personne ne prenait au sérieux et qui n'aura jamais la célébrité de Bell.

Au début les téléphones n'avaient pas de cadran téléphonique, pour téléphoner on décrochait et on tombait directement sur l'opératrice qui reliait les correspondants entre eux en branchant des prises Jack (qui a été inventée à cette fin). Avec le développement du réseau il devenait nécessaire de donner des numéros aux abonnés, puis des numéros ou des noms aux bureaux de rattachement. On pouvait demander le Gutenberg 12 21 par exemple à Paris.

Le système manuel demandait beaucoup de travail et ne permettait pas un développement rapide du réseau. Les lignes arrivaient à saturation et les clients devaient attendre. Pendant longtemps le réseau manuel a côtoyé le réseau automatique. La France a du attendre 1978 pour que son réseau soit entièrement automatique.

Quand on a automatisé, on s'est servi des noms de répartiteur ou des noms de communes pour faire la correspondance avec les chiffres. Par exemple, Gutenberg-12-21 correspond à 488-12-21. C'est pour cela que les cadrans de téléphone ont des lettres sur chaque chiffre. En Amérique du Nord ces lettres servent à faire des numéros facilement mémorisables. Le 514-AUTOBUS donne toujours aujourd'hui les horaires d'autobus à Montréal par exemple.

Une astuce incroyable !!!

Les cadrans rotatifs fonctionnent en créant des petites coupures (des impulsions) sur la ligne. Une impulsion par chiffre est donnée : le chiffre trois donne 3 impulsions, le zéro donne 10 impulsions. Un cadran dépoussiéré et huilé devrait mettre une seconde pour faire les 10 impulsions du chiffre zéro. S'il est trop lent il est possible que le réseau n'interprète pas correctement le numéro.

Les premiers autocommutateurs étaient électromécaniques. Lors de la composition du numéro, les impulsions faisaient bouger des petites pièces successivement, ce qui menait à la connexion physique des lignes entre les deux abonnés.

Explication du commutateur électromécanique (en anglais)

Dans le plan de numérotation de l'Amérique du Nord on utilise des numéros à 10 chiffres. 3 chiffres pour l'indicatif régional qui représente généralement une ville ou une agglomération, 3 autres chiffres pour le numéro de central et 4 chiffres pour l'abonné. Quand on appelait à l'intérieur d'une même ville, on ne tapait que les 7 derniers chiffres (pas l'indicatif régional).

Pour que le central puisse faire la distinction entre les deux types de numéros, les chiffres respectaient une nomenclature particulière. L'indicatif régional portait obligatoirement 0 ou 1 comme chiffre du milieu, le numéro de central ne pouvait pas contenir 0 ou 1 comme chiffre du milieu et ni les indicatifs ni les numéros de central ne pouvaient commencer par 0 ou 1 ; entre autres règles. Le plan a été revu en 1995 pour permettre des codes supplémentaires (comme le 450 pour la banlieue de Montréal).

Les codes régionaux ont au départ été attribués en fonction de la densité de population des régions, qui avaient alors des numéros plus ou moins rapides à composer sur le cadran rotatif. Le code de New-York est le 212 (très rapide à composer), le code de l'Alaska est le 907 (très long à composer).

Aujourd'hui

L'hégémonie d'Internet a rendu possible le déploiement de la VoIP (voix à travers le réseau IP) ce qui permet beaucoup plus de flexibilité : possibilité de prendre des appels depuis son ordinateur ou son smartphone, réseaux d'entreprise internes faciles à gérer sans matériel complexe dédié, possibilité de passer par le Wifi, etc.

Le service historique avec ses commutateurs dans des grosses armoires on l'appelle le Réseau téléphonique commuté en France (RTC) ; il est analogique sur les derniers bouts mais le multiplexage de l'infrastructure a été numérisé dans les années 90. Dans de nombreux pays, il est en train de vivre ses dernières heures. On ne branche plus son téléphone sur la prise murale mais sur le routeur qui numérise le signal et le fait passer par le réseau Internet. Le réseau de lignes téléphoniques aura pour dernière et unique vocation de faire passer l'ADSL (en attendant son remplacement par la fibre) et le téléphone devient une simple activité d'Internet, similaire à une conversation audio Skype.

En France, boite de l'adaptateur pour le téléphone numérique IP d'Orange. Ce boitier est loué aux personnes qui n'ont pas d'abonnement à internet. Sur l'illustration on remarque un téléphone américain avec son étiquette caractéristique sous le clavier.

Avec la fermeture du service traditionnel on perd plusieurs choses :

l'auto-alimentation de la ligne : en cas de coupure d'électricité, la ligne traditionnelle restait active, ce qui était un gros avantage avant que les téléphones mobiles ne soient répandus ;
la composition par impulsions (les cadrans rotatifs) car souvent cette fonctionnalité a été abandonnée dans le passage au numérique, mais on va voir comment surmonter ça.

Se servir d'un vieil appareil aujourd'hui

Globalement, il suffit de le brancher comme un appareil moderne et ça doit fonctionner, à l'exception peut-être de la sonnerie ou de la composition de numéro, selon le clavier utilisé.

Je me suis aperçue qu'avec la Livebox 5 la prise pour le téléphone ne gère que les appareils numériques DECT et donc mon S63 ne fonctionne pas du tout dessus.

Trois modèles de clavier

Comme on l'a vu les téléphones à cadran rotatifs sont souvent incompatibles avec les équipements récents. Les téléphones plus modernes avec des touches numérotent par tonalités (DTMF), ces notes de musique qu'on entend à chaque appui.

Attention cependant, il a existé des téléphones à touches mais à numérotation par impulsions. C'est par exemple le cas des premiers postes S63 français à touches, ceux dépourvus de dièse et d'étoile. Dans ce cas, vous serez confronté au même problème que pour les téléphones rotatifs. Certains appareils plus récents (et électroniques) ont un petit switch pour commuter entre les deux modes de numérotation.

Si vous avez le téléphone par une « box » qui intègre des prises pour brancher un téléphone traditionnel, elles ne vous permettront probablement pas d'utiliser un cadran rotatif. Vous pouvez alors vous procurer un boitier comme le Rotatone à installer dans le téléphone S63, ce boitier va simuler un clavier numérique DTMF. Sinon, vous pouvez trouver un service VoIP qui ne vous impose pas son matériel, ainsi vous n'aurez pas à bricoler votre vieux téléphone. Moi je passe par OVH par exemple.

Si vous possédez un modem-routeur (ou les deux séparés) avec un boitier séparé pour brancher le téléphone, il s'agit d'un ATA (adaptateur de téléphone analogique). Si c'est un Cisco, il ne gère pas les téléphones rotatifs. Si c'est un GrandStream alors il y a des chances que cela fonctionne (je possède un vieux HT502), il faut vérifier. Dans les boitiers récents de cette marque, c'est documenté « pulse » et activable dans les paramètres de l'interface web. Une liste de marques et modèles est disponible ici.

Le coup de sonnerie

Les vieux appareils font vibrer un marteau contre deux cloches pour déclencher la sonnerie. Il se peut que le courant faible délivré par un équipement moderne ne soit pas suffisant pour des téléphones qui ont fait la guerre, mais en général en utilisant un ATA dédié ça devrait marcher. La documentation donne d'éventuels indices, en particulier le nombre de REN. Par exemple, mon GrandStream HT502 délivre 3 REN par ligne. Cela signifie qu'on peut brancher jusqu'à trois téléphones traditionnels sur la même ligne et qu'il y aura assez de courant pour les faire sonner.

Les appareils plus anciens (avant les années 60, notamment le Ericsson U43 en bakélite) peuvent ne pas avoir de sonnerie (on appelait ça un ronfleur). À cette époque en France, la sonnerie était un boitier vissé sur le mur.

Attention aussi à vérifier le réglage de sonnerie, souvent un cran, une roue ou une grosse vis en dessous de l'appareil. Il est possible qu'il soit en mode sourdine.

Brancher les fils

Aujourd'hui les téléphones utilisent partout le connecteur RJ11 (la prise carrée avec le clip qui se brise facilement). Cette prise est utilisée en Amérique du Nord depuis au moins les années 70, mais il est possible que vous tombiez sur un téléphone équipé d'une vieille prise Bell avec 4 gros plots, la « 4 prong phone jack ». Dans ce cas, je vous conseille de trouver un adaptateur vers RJ11 pour que le téléphone conserve son antique prise historique.

En France, les téléphones ont utilisé jusqu'à la fin des années 2000 la prise T, dont cet article décrit l'horreur que c'était. On trouve un peu partout des adaptateurs prise T vers RJ11. À partir des années 90, les téléphones étaient à prise détachable : RJ11 côté téléphone et prise T côté mur.

Internet en France à la campagne dans les années 2000 - 2010

Câbler son installation

Il est possible de brancher son téléphone à son ATA mais il est aussi possible de réactiver toutes les prises murales de la maison, par exemple pour avoir un appareil dans une chambre et un autre dans le salon.

En fonction du nombre de REN en sortie de ligne, on sait combien d'appareils anciens brancher au maximum dans la maison. Désactiver la sonnerie d'un appareil ne fait pas économiser de courant (par exemple, sur le Bell 500, un appareil en sourdine fait vibrer le marteau dans le vide).

Les prises de téléphone sont branchées en cascade dans un appartement et reliées à un réseau extérieur s'il n'a pas été démantelé :

si vous utilisez encore l'ADSL gardez une prise reliée au réseau extérieur évidemment mais coupée des autres prises ;
sinon coupez juste votre cascade de prises de l'extérieur ;
ensuite il suffit de brancher la prise du ATA ou de la box sur n'importe quelle prise pour alimenter toutes les autres.

Conclusion

À partir de l'histoire du téléphone, on peut dériver vers beaucoup d'autres choses et faire des mises en perspective intéressantes.

Jusqu'en 1982, la compagnie AT&T Corporation avait le monopole du téléphone aux États-Unis, ce qui a mené à son démantèlement en plusieurs compagnies à l'issue d'un procès antitrust intenté par le département de la justice. Est-ce que Google et Facebook pourraient subir le même sort ?
Les laboratoires Bell Labs (qui appartenaient à AT&T) ont été à l'origine de nombreuses inventions d'importance fondamentale comme le transistor, mais aussi le langage C et le système d'exploitation Unix.

Pour aller plus loin :

Je vous recommande le site Histoire des Télécommunications Françaises qui possède un contenu très riche !
Autre site dans l'ambiance : Le minitel et Alcatel

Les formats vidéo analogiques

2018-09-21T00:00:00+02:00

Je fais cet article pour essayer de simplifier les bases de la vidéo analogique. Je ne rentre volontairement pas dans les subtilités techniques (les calculs mathématiques, les histoires de fréquences et tout). Je fais ça à la sauce C'est pas sorcier sauf que je suis nulle en maquettes. C'est utile pour comprendre d'autres pages sur le site.

Si vous voyez des trucs qui vous paraissent louches ou mal expliqués faites-moi signe !

Fréquence

Le nombre de trames par seconde est basé sur la fréquence du courant électrique utilisé dans chaque région, pour des raisons historiques. C'est pour ça que l'Amérique du Nord a la télévision en 60 trames/s, parce que son courant électrique est de 60 Hz. Même chose pour l'Europe et son 50 Hz.

Plus la fréquence est élevée, plus l'image est fluide. Sur PC, au temps des moniteurs à tube, on avait des fréquences plus hautes que sur la plupart des écrans LCD de maintenant pour éviter le scintillement (jusqu'à 75 Hz au moins).

Résolution

La résolution d'un signal analogique ne se détermine pas en pixels mais en lignes, puisque l'essence du signal vidéo est une variation continue de tension électrique. On passe d'une ligne à l'autre avec une saute de tension appelée top ligne, et on passe de trame en trame avec un top trame.

Là aussi ça change selon les pays... Il y a fort longtemps en France la première chaine était émise en 819 lignes, les Anglais étaient eux en 405 lignes. Puis toute l'Europe s'est accordée sur le 625 lignes. L'Amérique du Nord et le Japon se sont mis quelques années plus tôt sur 525 lignes.

Les Anglais en 405 lignes, les Français en 819 lignes...

Subtilité : les télévisions à tube cathodiques n'affichent pas toutes les lignes. En effet, une partie de l'image est mangée par les bords de l'écran, on appelle ça l'overscan.

Amérique du Nord / Japon : 525 lignes dont 480 visibles
Europe : 625 lignes dont 576 visibles

En général, les télévisions mangent même quelques lignes supposées être visibles.

Les lignes en trop ont servi en télévision pour être affectées aux données de télétexte, au sous-titrage ou aux informations numériques pour les décodeurs Canal+ en France (pour l'actualisation des droits des abonnés).

Lignes invisibles de l'image, normalement hors de l'écran

Entrelacement

Il s'agit d'un énième bricolage technique qui date des débuts de la télévision et dont on n'arrive pas à se débarrasser. Pour faire court, c'est une astuce qui consiste à transmettre un affichage fluide (60 Hz par exemple) sans transmettre réellement une image complète à chaque 60e de seconde.

En fait avec l'entrelacement on transmet des demi-images. Sur une trame on transmet les lignes paires et sur la trame d'après on transmet les lignes impaires, contrairement au mode progressif où chaque trame consititue une image complète. En gros, qu'on transmette une image en 480i (480 lignes visibles entrelacées) ou en 240p (240 lignes visibles progressives), on fait passer la même quantité d'informations par seconde (le même nombre de lignes chaque seconde), mais répartie différemment.

i pour interlaced (entrelacé)
p pour progressive (progressif)

En Europe la télédiffusion analogique avait 625 lignes entrelacées, donc chaque 50e de seconde une trame de 312,5 lignes était transmise (oui ça fait des demi-lignes...). On détermine la fréquence ligne comme ça : 312,5 × 50 = 15625 Hz. Ça nous donne environ 15,6 KHz, et c'est ça le bruit très aigü qu'on entend lorsqu'une télévision est allumée. 😊

Traditionnellement la télédiffusion utilise l'entrelacé, les formats progressifs n'ont été utilisés qu'avec les jeux vidéo. Une télévision américaine conçue pour le 480i s'accomodera normalement du 240p : on lui indique que toutes les trames sont paires, c'est de là que vient l'effet de « scanline ». Pareil pour une télévision européenne conçue pour le 576i, elle doit fonctionner en 288p.

L'entrelacement ça fonctionne grâce à la persistance rétinienne.

Systèmes de couleurs

Je vais résumer ça très brièvement sans rentrer dans des détails techniques d'une autre époque (bien que les principes de ces systèmes de couleurs des années 60 se retrouvent aujourd'hui dans les méthodes de compression numérique).

Une image en couleurs peut être constituée à partir de trois composantes primaires rouge, vert et bleu. Par superposition de ces couleurs à différentes intensités on obtient toutes les couleurs.

Un écran à tube cathodique en couleurs est composé de trois faisceaux colorés rouge, vert et bleu qui parcourent la surface de l'écran en variant d'intensité.

Quand la télévision en couleurs a fait son apparition dans les années 50, il a fallu bricoler pour que les postes en noir et blanc puissent continuer à recevoir les émissions correctement, c'est pourquoi les ingénieurs de l'époque ont transmis la couleur en la modulant (en la « cachant ») sur le signal lumineux (celui en niveaux de gris). Les postes anciens continuaient d'afficher les programmes en convertissant la tension électrique du signal vidéo en lumière, et les postes couleur avaient en plus des circuits électroniques permettant de reconstituer les couleurs.

Donc on a besoin de trois composantes pour transmettre un signal couleur, mais l'un deux doit être le signal en noir et blanc (Y, la luminance). La deuxième composante est alors la différence de bleu par rapport à cette luminance (B-Y), et la troisième composante est la différence de rouge (R-Y).

L'espace de couleurs du système PAL est représenté ici à une lumière à 50% (centre) : la diff. de rouge est le vecteur vertical, la diff. de bleu est le vecteur horizontal.

Ensuite, on utilise la magie des ondes pour moduler à chaque ligne les composantes B-Y et R-Y sur le signal de luminance (Y). Ce qui ressort, c'est ce qu'on appelle un signal composite : dans un seul fil on a nos trois composantes pour que la TV reconstitue l'image en couleurs. Le processus dégrade légèrement la qualité de l'image.

Il existe dans le monde trois normes de codage de couleurs pour faire un signal composite : le NTSC (utilisé au Japon et en Amérique du Nord), le PAL (utilisé en Europe) et le SÉCAM (utilisé en France et en Russie). Le SÉCAM n'a jamais été utilisé par aucun fabricant de consoles de jeux vidéos (ou alors dans les années 70 peut-être...).

Tous ces systèmes sont incompatibles les uns avec les autres : lire une VHS couleur de type SÉCAM sur une télé en PAL donne une image en niveaux de gris et inversement. Les postes « multistandards » ont été popularisés dans les années 90.

Les différentes étapes de traitement d'un signal vidéo de la source jusqu'à l'antenne d'émission. C'est comme ça que fonctionne la télévision analogique traditionnelle.

Modulation

La dernière étape du schéma ci-dessus est la modulation « RF », c'est-à-dire que le signal vidéo est assemblé avec l'audio puis est placé sur une fréquence. Cela permet d'envoyer le signal sur les ondes.

On module le signal sur une fréquence. Pour se simplifier avec les chiffres on utilise des numéros de canaux qui dépendent de la norme de modulation utilisée. Par exemple en Amérique du Nord (modulation norme M) :

Canal 2 = 55,25 Mhz
Canal 3 = 61,25 Mhz
Canal 4 = 67,25 Mhz
et ainsi de suite...

Radio-Canada Montréal (CBFT) était modulée sur le canal 2 pour l'antenne du Mont-Royal, et sur le canal 4 pour la télédistribution par câble.

Les postes de télévision traditionnels n'avaient pas d'entrée vidéo externe et ne pouvaient recevoir du signal que via leur prise d'antenne. C'est pour cela que les anciens appareils électroniques (VHS ou consoles) pouvaient se connecter directement via la prise d'antenne, il fallait alors syntoniser (tuner) la bonne fréquence.

L'avantage de la modulation est qu'elle permet une énorme compatibilité avec toutes sortes d'écrans anciens, mais la qualité d'image est encore dégradée par rapport au signal composite (neige, écho, image qui bave...).

La console Super Nintendo américaine a une sortie composite en NTSC (la prise « Multi out ») puis une sortie antenne (le truc brun) qui sort le même signal NTSC mais modulé sur le canal 3 ou 4 (on peut choisir avec le switch).

Attention, il existe là encore plusieurs normes de modulation non compatibles entre elles ! Voici les principales : - Amérique du Nord, Brésil, Japon : norme M - France : norme L / L' - Europe de l'Ouest : norme B / G - Europe de l'Est, Chine : norme D / K - Grande-Bretagne : norme I

Heureusement depuis les années 90 les télévisions sont en général multistandards.

Affichage d'un signal norme L sur une télé en norme B. En norme L un haut voltage indique beaucoup de lumière et un bas voltage indique du noir, c'est l'inverse en norme B : c'est ce qui explique cette inversion de luminance. L'image saute constamment car la télé n'arrive pas à trouver les débuts de lignes ni de trames. (Oui c'est la tête de Ruquier !)

Prises

Je ne vais pas détailler tous les modèles de prises existants, mais uniquement quelques connecteurs remarquables.

Le RCA

C'est le connecteur le plus répandu partout dans le monde. Sa forme la plus courante c'est le cable avec les trois prises rondes jaune-rouge-blanc : le jaune pour la vidéo composite, les rouge et blanc pour le son stéréo.

On trouve aussi (en Amérique du Nord surtout) un cable RCA avec des prises rouge-vert-bleu pour faire transiter un signal vidéo directement en RGB (rouge - vert - bleu) ou parfois en YUV (luminance - diff. de bleu - diff. de rouge), chaque fil faisant passer une composante, on évite ainsi de moduler et la qualité est meilleure. Pour le son il faut ajouter un cable RCA audio (rouge-blanc).

On trouve aussi des connecteurs RCA sur les sorties modulateur de vieux appareils (ce qui peut créer la confusion).

Audio-vidéo en composite

Vidéo en composantes : RGB ou YUV

Le S-Vidéo

Dans le chapitre sur les systèmes de couleurs, on a vu que pour créer la vidéo composite on mélangeait un signal de différence de rouge (R-Y) et un signal de différence de bleu (B-Y) avec le signal de lumière (Y, la luminance). Le S-Vidéo est un standard intermédiaire entre le composite et le composante. En effet, il mélange ensemble les deux informations B-Y et R-Y mais conserve la luminance sur un fil séparé.

La qualité est très proche du composante donc bien meilleure que le composite car la télévision n'a pas besoin de faire le travail délicat de séparation de la chrominance sur la luminance.

La Péritel

Parfois appelée SCART ou « Euroconnector », cette invention française est devenue plus ou moins une norme européenne. La prise péritel permet de faire passer un signal soit en RGB, soit en YUV, soit en S-Vidéo, soit en composite, le tout avec le son en même temps.

Ainsi avec un appareil doté d'une sortie Péritel, on choisit le mode de sortie (le plus souvent RGB ou Composite) dans les menus de réglage.

Il y a un piège avec cette super prise ! Les broches qui servent au RGB ou au YUV sont les mêmes qui servent au S-Vidéo. Une télévision qui a deux entrées Péritel en a généralement juste une qui prend le RGB, l'autre prenant le S-Vidéo. Certains postes sophistiqués plus rares permettent de choisir manuellement le mode. Les télévisions qui n'ont une seule entrée Péritel ne sont généralement compatibles qu'avec le RGB, mais ça dépend d'un modèle à l'autre. Heureusement le composite fonctionne sur toutes les prises.

Attention aussi aux cables : certaines péritel ne sont cablées que pour le RGB, d'autres que pour le composite histoire de faire des économies.

Consoles de jeux

Les consoles de jeux ont souvent joué avec les standards classiques de télévision. Quelques particularités...

Le mode progressif

Le mode progressif consiste à n'envoyer que des trames paires. Ce n'est pas un standard de télévision mais une solution pour avoir une image plus fluide avec 50 ou 60 fps réels. Ça privilégie la fluidité plutôt que la définition visible. La NES et la Super Nintendo fonctionnaient comme ça, les autres consoles de cette époque aussi certainement.

La France

La France et la RDA ont été les seuls pays d'Europe de l'Ouest à fonctionner en couleurs SÉCAM (le reste de l'Europe étant en PAL). Étant donné que dans le pays la prise Péritel permettait de délivrer une image en RGB, les consoles anciennes (style NES, ou Master System) françaises avaient un cable spécial RGB, ce qui évitait aux fabricants d'y mettre un modulateur SÉCAM uniquement pour le marché français. Le signal RGB était parfois natif, ce qui donnait alors une belle qualité (par exemple avec la Sega Master System II) et parfois généré à partir du signal PAL interne (par exemple la NES).

Au milieu des années 90, les télévisions multistandards PAL/SÉCAM devenaient beaucoup plus répandues ; les premières consoles 3D étaient alors vendues en France comme dans le reste de l'Europe : avec une simple sortie composite PAL. Il existe une bricole pour la Nintendo 64 qui permet d'avoir une sortie RGB. La Dreamcast, avec le bon câble, sortait nativement en RGB.

Le fameux PAL 60

Les éditeurs de jeux travaillaient en général en norme américaine : c'est à dire en 480 lignes visibles à 60 trames/s. En Europe le standard était de 576 lignes visibles à 50 trames/s. Pour que le public européen puisse bénéficier de la fluidité originale de ces jeux, on proposait au joueur 50 ou 60 Hz (en réalité 576i/50Hz ou 480i/60Hz).

Le souci, c'est les anciens postes européens étaient incapables de gérer la résolution et la fréquence américaines, ce qui rendait impossible de jouer correctement. D'où la nécessité de demander au joueur à chaque début de jeu si sa télé était compatible avec ce format.

On avait cet écran à chaque début de jeu sur Gamecube européenne

Pour aller plus loin

La télévision : principes généraux
World Analogue Television Standards and Waveforms (web archive)
Le Sécam, comment ça marche ? (vidéo, 1962)

maya.sh - ordinateurs

D'où vient le fond blanc (« light mode ») sur les écrans d'ordinateur ?

Partage de fichiers AppleTalk et internet entre Macintosh avec Netatalk et NetBSD

Mise en place de la VM dans TrueNAS

Configuration du réseau

Création de la VM

Installation et configuration de NetBSD

Installation et configuration de Netatalk

Passerelle AppleTalk - TCP/IP

Pour conclure

Fabriquer un adaptateur ADB→USB pour clavier Macintosh

Fabrication de l'objet

Programmation de la carte

Liens

Analyse des nouveaux titres rechargeables des transports de Toulouse

Les données d'un tag ST25TB

Structure d'un ticket

Extraction et interprétation des données

Norme Intertic

Système et distribution

Usages

Identifiants internes

Sécurité du support

Attaque par arrachage (tearing)

Pour en apprendre plus

Logiciels et jeux indispensables : tout pour bien démarrer sur Macintosh 68k

Sommaire

💾 Logiciels système

Système 6.0.7

Système 7.1

Mac OS 7.5.3

Versions à éviter

💡 Utilitaires

🧩 Extensions et tableaux de bord

🎨 Logiciels

🎲 Jeux

📁 Transférer les fichiers

⚙️ Principes du Mac OS classique

Transfert de fichiers et fork de ressources

Dossier Système

Extensions et tableaux de bord

La ROM et la PRAM

Les disquettes

SCSI et volume de démarrage

🚀 Outils pour les machines d'aujourd'hui

Émulateurs

Utilitaires pour macOS

Utilitaires pour Windows

📕 Différentes gammes et générations de Mac 68k

CPU, MMU et FPU : les trois mousquetaires de la carte mère

Résolution d'écran et accélération graphique

Compatibilité des applications

🔗 Ressources

Guides

Logiciels

Documents

Culture

Numériser des cassettes VHS avec du vieux matériel et du logiciel libre

Le matériel

Premiers essais

Linux à la rescousse

Méthode en résumé

Concernant la définition

Fréquence d'image

Paramètres d'encodage

Pour conclure

Liens et références

Personnaliser le listage des dossiers dans Apache

Processus d'affichage de l'index

Le module de listage

Les inconvénients de la configuration par défaut

Retrait des colonnes superflues

L'entête et le pied de page

Affichage mobile, favicon et titre d'onglet

Afficher une image en VGA mode 13h (assembleur x86)

Préparation de l'environnement

Un premier programme

Ce que tout cela signifie

La notation hexadécimale

La directive org

La directive `org`

Les instructions `mov`

L'instruction `ret`