Aller au contenu

La console

Trois chiffres comptent pour un jeu plus que tous les autres de cette page : le budget de composition par scanline (une ligne trop chargée s'affiche périmée, et le budget est par ligne, pas par écran), la display list de 256 entrées par trame, et le pool de 320 Kio d'art résident. Toutes les limites avec lesquelles un jeu vit sont réunies dans Constantes et limites.

640 × 480 à 60 Hz, 8 bits palettisé, 3 000 pixels de sprites opaques par scanline mesurés, sur trois RP2350B genlockés à 252 MHz.

Vidéo

Résolution 640 × 480 à 60 Hz (4:3), 18,4 Mpx/s actifs
Sortie HDMI / DVI
Profondeur 8 bits par pixel, palettisé : index → table de mélange → RGB565 → RGB888 sur le câble
Palette une palette de 256 index, sans banques. Partition par défaut — un réglage du bundle, par jeu, pas du câblage : index 0 réservé (transparent), 190 couleurs opaques (1-190), une encre système (191, le blanc de la fonte arcade 8×8 intégrée) et 64 rangées d'effets (192-255); un jeu peut échanger des rangées d'effet contre des couleurs opaques
Table de mélange 65 536 × RGB565, 128 Ko, reconstruite sur la puce depuis la palette : une lecture par pixel résout transparence, opacité, translucidité, additif, ombre et priorité devant/derrière, sans branchement
Sprites 3 000 pixels de sprites opaques par scanline mesurés sur la carte, environ 2 200 mélangés, soit à peu près 90 sprites opaques de 32 px de large par ligne
Tailles quelconques et animées ; pas de grille de tuiles fixe
Art résident un pool de 320 Kio dans la SRAM de RP2 (450 Ko visés), tenu par RP1 : pages de 64 octets, bitmaps chargés depuis la NOR de RP2 à la demande par des ordres de chargement portés par le paquet de la display list, pas de déchirure grâce à une quarantaine de trois trames
Display list 256 entrées de 16 octets par trame, envoyées par RP1 en SPI au VSYNC avec la palette, la caméra du fond et les écritures dans la carte de tuiles, et jusqu'à 16 ordres de chargement (paquet de 6 928 octets, 2,22 ms)
Bus de surimpression 16 bits à 42 MHz entre le moteur de sprites et le mélangeur ; 484 lignes par trame : 480 lignes de pixels plus quatre blocs de contrôle portant la palette et la caméra, les modes de mélange, les écritures de la carte de tuiles, et un réservé
Plans sprites en surimpression sur le fond, priorité devant/derrière par pixel
Fond carte de tuiles 8 × 8 défilée par le mélangeur depuis sa NOR, ou carte torique de 128 × 64 tenue par le jeu : la caméra du fond et les écritures de tuiles sont pilotées par le jeu et voyagent avec la display list, un mode texte sans coût de display list
Latence deux trames plus le balayage, déterministe ; pas de déchirure par construction

Pour comparaison, une Neo Geo tient 1 536 pixels de sprites par ligne, à peu près la moitié.

Calcul

Processeurs 3 × RP2350B, double Cortex-M33 chacun, six cœurs au total
Horloge 252 MHz sur les trois
Synchronisation genlock depuis un oscillateur MEMS de 12 MHz partagé sur les broches XIN
SRAM 520 Ko par puce, 1,5 Mo au total

Stockage

NOR 3 × 16 Mo, une par puce sur son port XIP dédié : atlas de sprites, fond, code
Débit mesuré 33 Mo/s, soit 550 Ko rechargeables par trame
Amovible carte micro-SD sur RP1 (FAT32), avec détection de carte : les jeux vivent dans papydeck/games/<nom>/, un dossier chacun, insérée à chaud

Lancer un jeu compile son bundle d'art dans la NOR de RP2 et de RP3 : quelques secondes la première fois, environ deux secondes depuis le cache de la carte, et rien du tout quand la NOR le tient déjà. C'est un modèle de cartouche, pas un modèle d'écran de chargement.

Audio

Conçu, pas encore implémenté : le mélangeur tourne en mode DVI pour l'instant.

Numérique îlots de données HDMI générés par RP3, aucun composant en plus
Analogique DAC I2S sur RP1 : jack 4 pôles et un amplificateur classe D de 2,5 W sur 4 Ω
Fréquence d'échantillonnage 48 kHz, par un diviseur PIO exact depuis 252 MHz

Les deux voies existent parce que beaucoup d'écrans de PC n'ont ni haut-parleurs ni sortie casque.

Connectivité

Sans fil Wi-Fi (station, réseau choisi et mémorisé sur la console ; HTTPS vers le serveur du projet), Bluetooth Classic (BR/EDR) et BLE
Manettes DualShock 4, DualSense, Switch Pro, 8BitDo… via Bluepad32
Filaire USB-C 2.0 sur RP1, la seule puce qui porte l'USB : console, mise à jour du firmware des quatre puces
Débogage trois connecteurs SWD, un par puce

Le Bluetooth Classic n'est pas une option de confort : c'est ce que parlent les manettes de salon. Un module BLE seul ne suffit pas.

La carte

Dimensions

60 × 60 mm, quatre trous de fixation.

Connecteurs

HDMI type A, USB-C 2.0, micro-SD avec détection de carte, jack audio 4 pôles avec interrupteur, connecteur haut-parleur, manettes/clavier/souris en Bluetooth.

Un bouton utilisateur.

Alimentation

5 V par l'entrée USB-C.

L'alimentation USB seule ne suffit pas au cas nominal

Un port USB annonce 500 mA par défaut, et la carte ne négocie rien sur ses lignes CC. Soit le firmware mesure ces lignes pour savoir ce qui est disponible, soit l'alimentation vient d'ailleurs.

État

Tourne sur la carte V1 alpha : sortie HDMI genlockée ; le moteur de sprites avec son pool tenu par RP1 et ses intervalles opaques (3 000 pixels de sprites par ligne mesurés) ; le fond tuilé, un monde défilé depuis la NOR du mélangeur, ou un mode texte local piloté par le jeu ; les jeux depuis la carte micro-SD, chacun avec son bundle d'art compilé sur la console et installé dans les NOR (mis en cache sur la carte) ; un moteur de jeu (acteurs en virgule fixe, masque de collision, animations) partagé à l'octet près avec le simulateur du navigateur ; manettes Bluetooth avec appairage depuis le menu de la console, vibration et LED joueur ; Wi-Fi avec clavier à l'écran ; les jeux publiés listés et téléchargés sur la carte en HTTPS. Chiens de garde sur les trois puces et une sortie universelle (B ou le bouton de la console tenu 3 s).

Reste ouvert : l'audio, le compactage du pool, une identité pour la console (un ATECC608 sur la carte V1, qui signe vers le serveur), les scores envoyés au classement.