pico6502 Guide Technique

Vue d'ensemble

Architecture Matérielle

Schéma Bloc

┌─────────────────────────────────────────────────────────────────────────┐
│                            pico6502 Board (v2.3a)                       │
│                                                                         │
│  ┌───────────────┐   PIO 0: A0–A15, D0–D7      ┌───────────────────┐   │
│  │               │◄──────────────────────────►│  DIP-40 Interface │   │
│  │   RP2350B     │   PIO 1: cycle/ctrl/irq     │   (6502 socket)   │   │
│  │  (300 MHz)    │◄──────────────────────────►│  A0–A15, D0–D7   │   │
│  │               │   PIO 2: PHI1/PHI2 clock ──►│  PHI0/RNW/SYNC   │   │
│  │  Core 0       │                             │  IRQ/NMI/RDY/SO  │   │
│  │  (USB/IO/ESP) │                             └───────────────────┘   │
│  │               │◄──QSPI──►[ 8MB PSRAM ]                             │
│  │  Core 1       │◄──SPI───►[ 16MB Flash ]                             │
│  │  (6502 loop)  │                                                     │
│  │               │◄──FSPI──►┌───────────┐                              │
│  │               │◄──UART──►│   ESP32   │◄──SPI──►[ SD Card ]         │
│  └───────────────┘          │  (WiFi)   │──────────[ Web Server ]     │
│                             └───────────┘                              │
│  [ USB Hub ]──USB──►[ RP2350 USB Bridge ]                             │
└─────────────────────────────────────────────────────────────────────────┘

Composants Principaux

Attribution des GPIO

Interface Bus Bufferisée (v2.3)

• Des 74AHCT244 pilotent les lignes d'adresse et de contrôle vers le socket hôte.
• Un 74AHCT245 gère le bus de données bidirectionnel.
• Les horloges disposent de chemins aller et retour séparés : le firmware pilote CLK1/CLK2 (GPIO 31/32) vers les buffers et relit CLK1_IN/CLK2_IN (GPIO 26/29) du côté socket. La comparaison de la phase pilotée avec la phase retournée permet de distinguer un buffer mort d'une horloge morte — exactement la distinction que la carte v2.2 ne pouvait pas faire, et la raison d'être de la commande busdiag clk du shell de débogage.

Architecture Firmware

Organisation de la Mémoire Flash

Conception Dual-Core

Cœur d'Émulation CPU

Interface Bus PIO

Programmes PIO

Conventions des Signaux IRQ

Génération d'Horloge PHI1 / PHI2 — 6502 vs 6512

• Mode 6502 (cputype "6502" / "65C02") — le vrai composant contient le générateur d'horloge, le pico6502 joue donc ce rôle : la référence PHI0 de l'hôte arrive sur la broche 37 du socket (CLK0, GPIO 35) et le firmware génère et pilote PHI1/PHI2 en sortie à travers les buffers d'horloge (CLK1/CLK2, GPIO 31/32) avec la temporisation de non-chevauchement correcte.
• Mode 6512 (cputype "6512" / "65C12") — le 6512 n'a pas de générateur intégré ; l'hôte fournit les deux phases et le firmware se contente d'écouter. Un hold de libération de bus DBE est honoré dans ce mode.

Wait States et RDY

Architecture PIO — Comment les Cycles Bus 6502 Sont Recréés

• Échelle — le mode par défaut en roue libre. Après chaque descente authentique de PHI2, la SM attend tADS ([15] cycles), remet R/W au niveau haut, puis interroge sa FIFO sur quatre barreaux (jmp !osre avec des délais de 12, 12 et 24 cycles — interrogations aux cycles approximatifs 17/30/43/68). Un mot qui arrive à temps est piloté sur ce barreau ; la forme asymétrique maintient le pilotage au pire cas à ~206–215 ns, à l'intérieur de l'enveloppe du vrai composant, et la fenêtre se ferme à la dernière interrogation. En dessous d'une horloge système de 250 MHz, le chargeur met les délais à zéro (« mode fresh-fall »). Sans travail en file, la SM reste inactive jusqu'à la descente suivante.
• Burst — un mot de lecture peut demander jusqu'à six adresses consécutives. Le PIO n'a pas d'additionneur, X contient donc l'adresse inversée, mov pins, !x la pilote et jmp x-- la fait croître ; chaque octet est piloté sur le point de grille descente-plus-tADS suivant et déclenche le latch, de sorte que les octets d'instruction défilent à un cycle par octet avec zéro C dans la boucle.
• Gated (addr_gated) — le handshake classique sur IRQ PIO 0, désormais en trois instructions : la SM se gare, le Core 1 pousse le mot et la libère, et le pilotage a lieu à la descente authentique suivante avec la temporisation propre de l'échelle. Les accès E/S, les opérations sérialisées et les blocs lents mis en quarantaine l'utilisent.

• Burst d'opcodes et tampon harvest — g_burstSpec (6 par défaut depuis le pilote BBC) octets de burst d'opcodes spéculatif. Les octets déjà récupérés lorsqu'une opération bus a interrompu le flux sont conservés dans un tampon harvest de 8 entrées et servis aux fetches ultérieurs sans opération bus ; il est invalidé par les écritures dans sa plage, les sauts du flux, les resets et les barrières de carte mémoire.
• Shadow — un shadow write-through de 64 Ko plus une carte binaire de validité. La ROM se remplit paresseusement à partir du flux bus ; la fenêtre d'E/S n'est jamais mise en shadow. Une écriture dans le registre de pagination (ROMSEL, reconnu via pageregmask car il est partiellement décodé sur $FE30–$FE3F) invalide la région paginée. Les écritures hors de la fenêtre d'écriture shadow déclarée ne font qu'invalider — la découverte, avec Galaxians, que la ROM latérale ignore les écritures. Chaque octet dépilé du bus est comparé au shadow ; g_shadowMismatch doit être nul, et tout bloc de 256 octets qui diverge est mis en quarantaine sur le chemin gated pour le reste de la session.
• Serve — une fois prouvé (1,38 milliard d'octets servis sans la moindre divergence au cours des tests d'endurance, de pipetest et des jeux), un octet valide en shadow est renvoyé immédiatement au cœur pendant que le cycle bus réel se poursuit. Le bus reste identique octet pour octet à un vrai 6502 ; le cœur cesse de l'attendre.
• Écritures natives — les écritures sont des mots d'échelle fire-and-forget avec une barrière d'écriture en attente et une contre-pression de FIFO, propres vis-à-vis de l'oracle sous pipetest.
• Fetches fusionnés — m6502FetchOpcodeFused et les fetches d'opérande sont des appels directs remplaçant les paires de callbacks issue/collect, forcés inline sous optimisation partielle à l'édition de liens.
• Mode carte inconnue — sans fenêtre déclarée, pipelineFetch fait tout de même chevaucher le fetch de l'opcode suivant avec la fin de l'instruction courante.

• Discipline d'adresse — l'adresse ne change que sur une descente fraîche de PHI2 plus la mise en forme tADS, offrant un cycle hôte complet de setup d'adresse avant chaque échantillon de lecture.
• Écritures — SM de données asservie à R/W (pas de courses de fronts entre SM) ; un strobe par écriture.
• Lectures — le latch transparent : maintien nul, insensible à l'étirement, immunisé contre l'effondrement du maintien après écriture et le basculement du bus vidéo.
• Interruptions — la livraison IRQ/NMI n'avait jamais été implémentée ; /IRQ est désormais échantillonné en direct à chaque instruction avec une sémantique de niveau (corrigeant une IRQ fantôme passant par un vecteur invalide sur BREAK) ; l'initialisation du front /NMI a corrigé le vecteur de démarrage à froid vers $0D00.
• Reset — /RES anti-rebond sur 5 ms avec la séquence de reset exécutée après le relâchement (corrigeant le « premier BREAK ignoré ») ; un superviseur de mise sous tension maintient l'hôte en reset jusqu'à ce que les services du Core 0 soient opérationnels (plafond de 15 s) ; R/W est garé au niveau haut à l'initialisation ; le Core 1 est garé en RAM avant toute écriture flash.
• Compteur de cycles — un bouclage 32 bits figeait la machine après exactement 42 minutes ; l'arithmétique des tranches est désormais protégée contre le débordement.
• Horloges et tension — la persona Model B est livrée à 340 MHz / 1,20 V ; une autre unité a eu besoin de ~1,35 V pour 330 MHz (1,30 V se bloquait). La marge de tension est propre à chaque carte. Un démarrage qui se bloque retombe à 150 MHz.

Modèle Mémoire

Niveau 1 — SRAM RP2350 (Table de Dispatch Rapide)

// 32-bit membankPtr encoding
// Bits 31–24: MEMBANK_TYPE_xxx constant (bit flags)
// Bits 23–0:  24-bit PSRAM pool address of the block (bank × 64KB + block base)
//             — for PTR blocks, the memPtr[] table index; for PHYSICAL, the host address
//   e.g. 16K virtual RAM at $4000 in bank 0:
//   membankPtr[blk] = (MEMBANK_TYPE_RAM << 24) | (blk * MEMORY_BLOCK_SIZE);

Niveau 2 — PSRAM (8 Mo)

typedef struct {
    uint8_t      RAM[MAX_MEMORY_BANKS * MEMORY_PAGE_SIZE]; // 64 banks × 64KB = 4MB RAM/ROM area
    MemoryFunc   memPtr[MEMORY_PAGE_SIZE];                  // 64K per-byte read redirect (PTR type)
    MemoryFunc   memioPtr[MEMORY_PAGE_SIZE];                // 64K memory-mapped handler array (FUNC type)
    // Note: no ioPtr[] — 6502 has no separate I/O space
} t_6502PSRAM;

Niveau 3 — Flash (16 Mo)

Types de Blocs Mémoire

Référence de Configuration

esp32.core

esp32.wifi

rp2350.core

rp2350.6502[ ] — Partitions CPU

rp2350.6502[n].memory[ ]

rp2350.6502[n].drivers[ ]

Entrée rom[] :

Framework de Périphériques Virtuels

Signatures des Handlers

// Memory / peripheral handler — installed in memioPtr[addr]
// Called for every access to a MEMBANK_TYPE_FUNC block
typedef uint8_t (*MemoryFunc)(M6502CPU *cpu, bool read, uint16_t addr, uint8_t data);

// Driver init function — registered in virtualFuncMap[]
// Called twice: pass=0 (validation), pass=1 (configuration)
typedef int (*VirtualFunc)(M6502CPU *cpu, t_drvConfig *drvConfig, int pass);

Écrire un Pilote de Périphérique

1. Créez une fonction handler avec la signature MemoryFunc. Le handler reçoit read=true pour les cycles de lecture 6502 (RNW=1) et read=false pour les cycles d'écriture (RNW=0).
2. Créez une fonction d'initialisation avec la signature VirtualFunc. Lors de la passe de configuration (pass=1), installez votre handler dans cpu->_6502PSRAM->memioPtr[addr] pour chaque adresse occupée par votre périphérique.
3. Enregistrez le nom du pilote et la fonction d'initialisation dans la table virtualFuncMap[] de M6502CPU.c.
4. Ajoutez une entrée de type FUNC dans le tableau memory de config.json pour la plage d'adresses.
5. Ajoutez une entrée de pilote dans config.json avec le champ "name" correspondant.

Coprocesseur ESP32

Carte SD

Serveur Web

Protocole de Commandes

Débogage SWD — RP2350

• L'ELF du firmware principal est build/bin/model/Base6502/Base6502_0x10020000.elf (et non BaseZ80).
• L'entrée add-auto-load-safe-path de ~/.gdbinit doit référencer Base6502.

Configuration d'OpenOCD

sudo cp rp2350_tzpu.cfg /usr/local/share/openocd/scripts/target/
openocd -f interface/cmsis-dap.cfg -f target/rp2350_tzpu.cfg -c "adapter speed 5000"

Configuration de GDB

set history save on
set history filename ~/.gdb_history
set history size 65536
add-auto-load-safe-path build/bin/model/Base6502/.gdbinit:build/bin/model/Bootloader/.gdbinit

# Bootloader — Core 0
cd build/bin/model/Bootloader
cp ../../../../.gdbinit.bootloader.3333 .gdbinit
gdb-multiarch Bootloader.elf

# Bootloader — Core 1 (separate terminal)
cd build/bin/model/Bootloader
cp ../../../../.gdbinit.bootloader.3334 .gdbinit
gdb-multiarch Bootloader.elf

# Main firmware — Core 0
cd build/bin/model/Base6502
cp ../../../../.gdbinit.3333 .gdbinit
gdb-multiarch Base6502_0x10020000.elf

# Main firmware — Core 1 (separate terminal)
cd build/bin/model/Base6502
cp ../../../../.gdbinit.3334 .gdbinit
gdb-multiarch Base6502_0x10020000.elf

ESP32 — Débogage USB

openocd -f board/esp32s3-builtin.cfg

xtensa-esp32s3-elf-gdb esp32/build/main.elf
(gdb) target extended-remote :3333

Système de Compilation

Cibles de Compilation

Commandes de Compilation

# Set up (once) — from project root
export PICO_PATH=/path/to/pico-sdk
./get_and_build_sdk.sh

# Standard release build of the 6502 model
./build_tzpuPico.sh 6502

# Debug build
./build_tzpuPico.sh 6502 DEBUG

# ESP32 only (using Docker idf54 alias)
cd projects/tzpuPico/esp32
idf54 build

# Flash RP2350 via USB mass-storage (BOOTSEL mode)
cp build/bin/model/Bootloader/Bootloader.uf2 /media/$USER/RPI-RP2/
cp build/bin/model/Base6502/Base6502_0x10020000.uf2 /media/$USER/RPI-RP2/

# Flash ESP32 (initial, via esptool)
esptool.py --chip esp32s3 --port /dev/ttyUSB0 --baud 460800 \
  write_flash 0x0   esp32/build/bootloader/bootloader.bin \
             0x8000 esp32/build/partition_table/partition-table.bin \
             0x10000 esp32/build/main.bin

Architecture du Shell de Débogage

Diagnostics de Mise en Service — busdiag et piodbg

• busdiag — un instantané de chaque signal du socket et de contrôle des buffers plus les bus d'adresses et de données ; busdiag clk mesure PHI0 / PHI1_IN / PHI2_IN et les compare (distinguant un buffer mort d'une horloge morte) ; busdiag watch [n] prend n instantanés rapides.
• busprobe <addr> [count] — relit une adresse en boucle pour exposer des lignes de données instables ; busverify <addr> <len> [passes] — relecture sûre pour la ROM d'une plage, signalant les lectures instables et les divergences fetch/read ; memtest avec un mode decay pour les défauts de rafraîchissement.
• bustest [loops] et wrtest [secs] [mode] [addr] — pilotent des motifs marqués sur R/W, la phase PHI2 et OE_CLK pour la caractérisation à l'analyseur logique ; busstate — PC des machines d'état, FSTAT et drapeaux IRQ en direct pour l'analyse des blocages (il a prouvé que les expériences de pipeline côté C ayant échoué se garaient proprement — le défaut était une corruption de données, pas un interblocage) ; piodbg — le dump du PIO.
• writestrobes <1|2>, iopark on|off, readsettle <0-31>, readphase latch|hi|lo — les boutons A/B en direct ; buspipe avec on|off, fetch, rungs <1-4>, burst <1-6>, iochase, iorange <lo> <hi>, serve, natwr, wrregion, wrhold <0-31>, wrverify <lo> <hi>|off, slowclr, stats ; pipetest <iters> — le banc oracle d'opérations bus mixtes du Core 1.
• cpustat — instructions/s et cycles émulés/s par rapport à l'horloge hôte mesurée (appeler deux fois pour obtenir un taux) ; cpuprof — histogramme du temps par instruction par classe de bus. Les statistiques optionnelles (g_dbgStats, recensement par classe d'opération, causes de ratés, histogrammes de latence) coûtent 3–5 % et sont désactivées par défaut ; sans le shell de débogage, elles sont exclues de la compilation.
• bbc (BBC6502 uniquement) — état de la persona ; mask <0|1>, socket <n> <0|1>, cmosdef, oscheck, tape sel|next|rew|trace|on|off, fdc (état, y compris le composant et la carte) / fdc <drive> <file|eject> [A|B] [auto|ssd|dsd|mmb|adf|adl|dds|ddd] / fdc trace on|off, mmc (état) / mmc trace on|off, net (état : trames, UDP entrant/sortant, acks, délais dépassés, coût SPI par datagramme, latence de réponse) / net trace on|off / net tick <us>.

Assembleur / Désassembleur

Tests de Conformité

make -C src/test/M6502 run

• ADC/SBC binaires sur l'ensemble des 256 × 256 × 2 combinaisons opérandes/retenue, vérifiées par rapport à l'arithmétique C ordinaire.
• ADC/SBC décimaux (BCD) sur toutes les paires BCD valides.
• CMP sur l'ensemble des 256 × 256 paires.
• L'aller-retour complet désassemblage → assemblage sur les 256 opcodes, avec des exemptions explicites et listées pour les encodages dupliqués.

Sites de Référence

Avis Réglementaire sur les Communications Sans Fil