pico6502 Guide du Developpeur

English

Remarque : Le projet pico6502 est en phase de developpement initial. Le framework de pilotes et le modele memoire sont entierement implementes et partagent la meme architecture que le picoZ80. Cependant, seule une persona BBC Model B de substitution existe actuellement — ce guide explique comment construire sur cette base pour ajouter vos propres pilotes. Lorsque le pico6502 est architecturalement identique au picoZ80, des renvois au Guide du developpeur picoZ80 sont fournis.

Vue d'ensemble

Le firmware du pico6502 est structure de maniere identique au firmware du picoZ80. Il utilise la meme architecture RP2350B double coeur, le meme modele memoire PSRAM, le meme systeme de configuration JSON et le meme framework de pilotes — les differences principales sont :
  • M6502CPU.c / M6502CPU.h remplacent Z80CPU.c / Z80CPU.h comme fichiers principaux de dispatch et de framework de pilotes.
  • Le 6502 n'a pas d'espace d'adressage E/S separe — il n'y a pas de tableau ioPtr[] et pas de section JSON iomap. Tous les peripheriques sont virtualises sous forme de blocs de type FUNC dans la carte memoire de 64 Ko.
  • L'interface bus PIO (M6502.pio) implemente l'horloge biphasee PHI1/PHI2 au lieu du modele a horloge unique du Z80.
  • Le repertoire cible de compilation est BaseM6502 au lieu de BaseZ80.
  • La cle de section CPU JSON est "6502" au lieu de "z80".
Tout le reste — le modele de file inter-coeurs, les callbacks de cycle de vie des pilotes (reset_ptr, poll_ptr, task_ptr), la table d'enregistrement virtualFuncMap[], les constantes de type de bloc memoire, la struct t_6502PSRAM, le protocole du coprocesseur ESP32 et le systeme de compilation — est partage avec la base de code du picoZ80.

Arborescence des sources

Tout le code source se trouve sous projects/tzpuPico/ dans la racine du depot. La disposition ci-dessous met en evidence les fichiers specifiques au pico6502 :
tzpuPico/
├── CMakeLists.txt                          Fichier de compilation de niveau superieur
├── src/
│   ├── CMakeLists.txt                      Fichier de compilation au niveau source — ajoutez les nouveaux fichiers pilotes ici
│   ├── M6502CPU.c                          *** FICHIER CLE : dispatch 6502, framework de pilotes, virtualFuncMap
│   ├── M6502CPU.h                          (historique — inclus via include/)
│   ├── M6502.c                             Initialisation PIO et points d'entree des cycles bus
│   ├── M6502.pio                           Programmes PIO : clock, addr, data, cycle, fetch, read, write, irq, nmi, so
│   ├── Z80CPU.c / Z80CPU.h                 Equivalent Z80 (non utilise pour les compilations pico6502)
│   ├── FSPI.c / FSPI.h                     Interface Flash SPI (partage)
│   ├── ESP.c / ESP.h                       Couche de communication ESP32 (partage)
│   ├── psram.c / psram.h                   Allocation et gestion PSRAM (partage)
│   ├── cJSON.c / cJSON.h                   Parseur JSON pour config.json (partage)
│   ├── include/
│   │   ├── M6502CPU.h                      *** FICHIER CLE : toutes les definitions de types et macros 6502
│   │   ├── M6502.h                         Definitions d'aide PIO
│   │   └── drivers/
│   │       └── BBC/
│   │           └── ModelB.h               En-tete du pilote BBC Model B (substitution precoce)
│   ├── drivers/
│   │   └── BBC/
│   │       └── ModelB.c                   *** PILOTE EXEMPLE/SUBSTITUTION (persona BBC Model B)
│   └── model/
│       ├── BaseM6502/
│       │   ├── CMakeLists.txt             Cibles de compilation par modele
│       │   ├── main.c                     Point d'entree (lancement Core 0 + Core 1)
│       │   ├── main_memmap_partition_1.ld Script de liaison pour le Slot 1
│       │   └── main_memmap_partition_2.ld Script de liaison pour le Slot 2
│       └── Bootloader/
│           ├── CMakeLists.txt
│           └── main.c                     Bootloader partage (meme que picoZ80)
└── esp32/
    ├── CMakeLists.txt
    └── main/
        └── ...                            Firmware ESP32 (partage avec picoZ80)

Differences cles avec le picoZ80

Pas d'espace d'adressage E/S separe

La difference architecturale la plus importante est que le 6502 n'a pas d'instructions IN/OUT et pas de signal IORQ. Chaque peripherique doit apparaitre quelque part dans la carte memoire de 64 Ko. Dans le picoZ80, les peripheriques virtuels peuvent etre enregistres via memioPtr[] (mappes en memoire) ou ioPtr[] (mappes en E/S). Dans le pico6502 il n'y a que memioPtr[] — mais puisque tous les acces peripheriques passent par le bus memoire, cela couvre tous les cas.
La struct t_6502PSRAM n'a donc pas de tableau ioPtr[]. La configuration JSON n'a pas de tableau "io". La boucle de dispatch dans M6502CPU.c verifie uniquement le tableau _membankPtr[] et, pour les blocs MEMBANK_TYPE_FUNC, appelle le handler memioPtr[] correspondant.

Differences de l'interface bus PIO

Le 6502 utilise un schema d'horloge biphasee non chevauchante. PHI0 est une entree d'horloge externe ; le RP2350 genere PHI1 et PHI2 a partir de celle-ci via une machine d'etat PIO 2 dediee (m6502_clock_6502). C'est different du Z80 qui utilise un signal CLK unique.
Bloc PIO Machines d’etat Objectif
PIO 0 m6502_addr, m6502_data Bus d’adresses (A0-A15), bus de donnees (D0-D7)
PIO 1 m6502_cycle, m6502_fetch, m6502_read, m6502_write, m6502_irq, m6502_nmi, m6502_so Sequencement des cycles bus et surveillance des signaux de controle
PIO 2 m6502_clock_6502 Generation d’horloge biphasee PHI1/PHI2 a partir de PHI0 externe
La convention IRQ differe legerement de l'interface PIO du Z80 :
Drapeau IRQ Signal Signification
IRQ 0 Adresse/debut de cycle Nouveau cycle bus 6502 — adresse valide sur front montant PHI1
IRQ 1 Phase donnees Bus de donnees actif — lecture ou ecriture selon RNW
IRQ 4 NMI Interruption non masquable activee
IRQ 5 IRQ Interruption masquable activee
IRQ 6 SO Broche Set Overflow activee
IRQ 7 Sortie de boucle Requete de sortie de boucle d’execution Core 1

Programmation PIO — Comment le code C pilote les cycles bus

Le pico6502 utilise le meme mecanisme out exec que le picoZ80 pour l'injection dynamique d'instructions, mais avec des instructions 32 bits (out exec, 32) au lieu de 16 bits. Le code C sur le Core 1 pousse des sequences d'instructions PIO pre-encodees dans le FIFO TX de la SM de cycle pour controler chaque transaction bus.
Le flux de coordination pour un cycle de lecture memoire 6502 :
                  Core 1 (code C)               Machines d'etat PIO
                  ─────────────                 ──────────────────
    1. Resoudre l'adresse                       m6502_cycle: IRQ 0 active
       depuis la carte memoire                    (en attente de PHI2 bas)
                  │
    2. Pousser addr → TX FIFO ──────────────→ m6502_addr: recoit addr
       Effacer IRQ 0                              produit A0–A15 sur les broches
                  │
    3. Pousser les instructions ─────────────→ m6502_cycle: out exec, 32
       de cycle (sequence de                      execute: set R/W̄ haut, SYNC bas
       lecture) dans le FIFO                      execute: wait PHI2 haut
       TX de la SM de cycle                       execute: verifier RDY
                  │
    4. Attendre le RX FIFO ←────────────────  m6502_data: echantillonne D0–D7
       (octet de donnees du bus)                  sur front descendant PHI2
                  │
    5. Lire les donnees du                     m6502_cycle: JMP start_cycle
       RX FIFO                                    (pret pour le prochain cycle)
                  │
    6. Dispatcher vers PSRAM
       ou handler de pilote
Pour les cycles d'ecriture, le Core 1 pousse l'octet de donnees dans le FIFO TX de la SM m6502_data apres l'adresse. La SM de donnees pilote D0-D7 pendant la phase PHI2 haut, puis met le bus de donnees en tri-state quand PHI2 tombe. La SM de cycle met R/W̄ a l'etat bas pour indiquer une ecriture.
Pour une explication detaillee des fondamentaux PIO, du mecanisme out exec et des modeles de coordination des machines d'etat, voir le Guide technique du picoZ80 — Architecture PIO en profondeur. Les differences PIO specifiques au 6502 sont :
  • out exec 32 bits — permet l'encodage complet d'instruction PIO incluant les champs de side-set et de delai dans un seul push FIFO.
  • Synchronisation par phase d'horloge — les SM de cycle se synchronisent sur les fronts de PHI2 (wait 0/1 gpio CLK2) au lieu d'un signal CLK unique.
  • Pas de BUSREQ/BUSACK — le 6502 n'a pas de mecanisme de requete de bus, il n'y a donc pas d'equivalent de la SM Z80 z80_busrq.
  • RDY au lieu de WAIT — les etats d'attente sont inseres en verifiant la broche RDY apres le front montant de PHI2, au lieu de la broche /WAIT du Z80 au front descendant T2.

Struct t_6502PSRAM

Equivalent a t_Z80PSRAM dans le picoZ80, mais sans le tableau ioPtr[] :
// src/include/M6502CPU.h (simplifie)
typedef struct {
    uint8_t      RAM[MAX_MEMORY_BANKS * MEMORY_PAGE_SIZE]; // 64 banques x 64 Ko = 4 Mo zone RAM/ROM
    MemoryFunc   memPtr[MEMORY_PAGE_SIZE];                  // 64K redirection lecture par octet (type PTR)
    MemoryFunc   memioPtr[MEMORY_PAGE_SIZE];                // 64K tableau handlers mappes memoire (type FUNC)
    // NOTE : pas de ioPtr[] — le 6502 n'a pas d'espace E/S separe
} t_6502PSRAM;

Signature de la fonction handler

Le typedef MemoryFunc est le meme que pour le picoZ80 :
// Handler appele pour les blocs MEMBANK_TYPE_FUNC a chaque acces
typedef uint8_t (*MemoryFunc)(M6502CPU *cpu, bool read, uint16_t addr, uint8_t data);

// Parametres :
//   cpu  — pointeur vers la struct M6502CPU (acces PSRAM, etat, files via celui-ci)
//   read — true pour un cycle de lecture 6502 (RNW=1), false pour un cycle d'ecriture (RNW=0)
//   addr — adresse 16 bits qui a declenche ce handler
//   data — octet ecrit (significatif uniquement quand read=false)
// Retour :
//   octet a placer sur le bus de donnees (significatif uniquement quand read=true)
Parce qu'il n'y a pas d'espace E/S, il n'y a pas de typedef IOFunc separe — MemoryFunc gere tous les acces peripheriques.

Framework de pilotes

Le framework de pilotes dans M6502CPU.c est structurellement identique au framework de pilotes du picoZ80. Referez-vous a la section Guide du developpeur picoZ80 — Framework de pilotes pour la description complete de :
  • La table d'enregistrement virtualFuncMap[] et comment le champ JSON "name" est mis en correspondance avec une fonction d'initialisation de pilote.
  • Le typedef VirtualFunc et la recherche M6502CPU_getVirtualFunc().
  • Le flux d'initialisation en deux passes (passe de validation puis passe de configuration).
  • Les callbacks de cycle de vie des pilotes : reset_ptr, poll_ptr, task_ptr.
Les seules differences de nommage sont :
picoZ80 pico6502 Notes
struct Z80CPU struct M6502CPU Memes champs, meme disposition
Z80CPU_getVirtualFunc() M6502CPU_getVirtualFunc() Meme logique de recherche
Z80CPU_cpu() M6502CPU_cpu() Point d’entree de la boucle principale Core 1
Z80CPU_readMem() M6502CPU_readMem() Dispatch de lecture memoire
Z80CPU_writeMem() M6502CPU_writeMem() Dispatch d’ecriture memoire
Z80CPU_readIO() Pas d’equivalent — le 6502 n’a pas d’espace E/S
Z80CPU_writeIO() Pas d’equivalent — le 6502 n’a pas d’espace E/S
cpu->_z80PSRAM cpu->_6502PSRAM Pointeur vers la struct PSRAM

Boucle de dispatch Core 1

La boucle principale du Core 1 dans M6502CPU_cpu() suit le meme modele que le picoZ80. A chaque cycle bus du 6502 :
  1. Attendre IRQ 0 (adresse valide sur PHI1).
  2. Lire l'adresse 16 bits depuis le FIFO RX de PIO 0.
  3. Rechercher _membankPtr[addr >> 9] pour obtenir le type de bloc, la banque et la base.
  4. Determiner RNW (read/not-write) depuis le PIO de controle.
  5. Dispatcher selon le type de bloc : PHYSICAL (passer a l'hote), RAM (lecture/ecriture PSRAM), ROM (lecture seule PSRAM), FUNC (appeler memioPtr[addr]), PTR (rediriger via memPtr[addr]).
  6. Si lecture : placer le resultat sur le bus de donnees via le FIFO TX de PIO 0. Attendre IRQ 1 (phase donnees). Si ecriture : lire les donnees depuis le FIFO RX de PIO 0 apres IRQ 1.
  7. Appeler poll_ptr pour chaque pilote enregistre (environ tous les ~2048 cycles).
// Dispatch simplifie M6502CPU_readMem / M6502CPU_writeMem
uint8_t M6502CPU_readMem(M6502CPU *cpu, uint16_t addr)
{
    uint32_t entry = cpu->_membankPtr[addr >> 9];
    uint8_t  type  = (entry >> 24) & 0xFF;
    uint8_t  bank  = (entry >> 16) & 0xFF;
    uint32_t base  = (entry & 0xFFFF) << 9;

    switch(type)
    {
        case MEMBANK_TYPE_RAM:
        case MEMBANK_TYPE_ROM:
            return cpu->_6502PSRAM->RAM[(bank * MEMORY_PAGE_SIZE) + addr];

        case MEMBANK_TYPE_FUNC:
            if(cpu->_6502PSRAM->memioPtr[addr] != NULL)
                return cpu->_6502PSRAM->memioPtr[addr](cpu, true, addr, 0);
            return 0x00;

        case MEMBANK_TYPE_PTR:
            if(cpu->_6502PSRAM->memPtr[addr] != NULL)
                return cpu->_6502PSRAM->memPtr[addr](cpu, true, addr, 0);
            return 0x00;

        case MEMBANK_TYPE_PHYSICAL:
        default:
            return 0xFF;  // Pass-through vers le materiel reel de l'hote
    }
}

Ecrire un nouveau pilote

Le processus pour ecrire un pilote pico6502 est identique a celui du picoZ80 decrit dans le Guide du developpeur picoZ80 — Ecrire un nouveau pilote. Les six etapes sont les memes :
  1. Creer un fichier d'en-tete dans src/include/drivers/<Family>/MyDriver.h
  2. Creer un fichier d'implementation dans src/drivers/<Family>/MyDriver.c
  3. Ajouter le fichier source a src/CMakeLists.txt
  4. Inclure le pilote dans M6502CPU.c sous une garde #ifdef INCLUDE_<FAMILY>_DRIVERS
  5. Enregistrer le pilote dans virtualFuncMap[] dans M6502CPU.c
  6. Ajouter une entree de pilote JSON dans config.json
La difference cle est qu'au lieu d'un parametre Z80CPU *cpu, toutes les fonctions recoivent un parametre M6502CPU *cpu, et vous accedez a la PSRAM via cpu->_6502PSRAM au lieu de cpu->_z80PSRAM. Il n'y a pas de slots ioPtr[] a installer — tous les peripheriques virtuels sont enregistres dans memioPtr[].

Template de pilote minimal

Ce qui suit montre un pilote de peripherique 6502 minimal — un 6522 VIA (Versatile Interface Adapter) virtualise a l'adresse 0xC000–0xC00F :
// src/include/drivers/BBC/VIA6522.h
#ifndef VIA6522_H
#define VIA6522_H

#include "M6502CPU.h"

int VIA6522_Init(M6502CPU *cpu, t_drvConfig *drvConfig, int pass);

#endif
// src/drivers/BBC/VIA6522.c
#include "../../include/M6502CPU.h"
#include "../../include/drivers/BBC/VIA6522.h"

// --- Etat interne ---
typedef struct {
    uint8_t  regs[16];      // Registres internes VIA (ORB, ORA, DDRB, DDRA, T1CL, T1CH, ...)
    bool     irqPending;
} t_VIA6522State;

static t_VIA6522State ViaState = { .irqPending = false };

// --- Handler memoire (appele pour chaque acces a 0xC000–0xC00F) ---
static uint8_t VIA6522_Handler(M6502CPU *cpu, bool read, uint16_t addr, uint8_t data)
{
    uint8_t reg = addr & 0x0F;   // Le VIA a 16 registres internes

    if(read)
    {
        return ViaState.regs[reg];
    }
    else
    {
        ViaState.regs[reg] = data;
        // TODO: implementer la logique timer, registre a decalage, port selon les besoins
        return 0;
    }
}

// --- Handler de reset (appele quand le systeme hote se reinitialise) ---
static uint8_t VIA6522_Reset(M6502CPU *cpu)
{
    memset(&ViaState.regs, 0, sizeof(ViaState.regs));
    ViaState.irqPending = false;
    return 0;
}

// --- Fonction d'initialisation (appelee pendant le parsing de la configuration JSON) ---
int VIA6522_Init(M6502CPU *cpu, t_drvConfig *drvConfig, int pass)
{
    if(pass == 0)
    {
        // Passe de validation — verifier seulement que le nom correspond
        return (strcasecmp(drvConfig->name, "via6522") == 0) ? 1 : 0;
    }

    // Passe de configuration — installer les handlers
    // Installer le handler pour les 16 registres VIA a 0xC000–0xC00F
    for(uint16_t addr = 0xC000; addr <= 0xC00F; addr++)
    {
        cpu->_6502PSRAM->memioPtr[addr] = VIA6522_Handler;
    }

    // Enregistrer le callback de reset
    cpu->reset_ptr = VIA6522_Reset;

    debugf("VIA6522: Initialise a 0xC000–0xC00F\n");
    return 1;
}

Configuration JSON

Pour activer le pilote VIA6522, ajoutez un bloc FUNC a la carte memoire et une entree de pilote :
{
  "rp2350": {
    "6502": {
      "memory": [
        { "enable":1, "addr":"0x0000", "size":"0xC000",
          "type":"RAM",  "bank":0, "task":"", "file":"" },
        { "enable":1, "addr":"0xC000", "size":"0x0010",
          "type":"FUNC", "bank":0, "task":"via6522", "file":"" },
        { "enable":1, "addr":"0xE000", "size":"0x2000",
          "type":"ROM",  "bank":0, "task":"", "file":"/ROM/bios.rom" }
      ],
      "drivers": [
        { "enable":1, "name":"via6522" }
      ]
    }
  }
}

Enregistrement dans virtualFuncMap

Ajoutez une entree a la table virtualFuncMap[] dans M6502CPU.c. La chaine name est mise en correspondance sans distinction de casse avec le champ JSON "name" du pilote :
// Dans M6502CPU.c — ajouter a virtualFuncMap[]
static const t_VirtualFuncMap virtualFuncMap[] = {
    { "BBCModelB", BBCModelB_Init },   // entree existante
    { "via6522",   VIA6522_Init   },   // votre nouveau pilote
    { NULL, NULL }                     // terminateur
};

Modification de CMakeLists.txt

Ajoutez le nouveau fichier source et activez-le via une definition de compilation dans src/CMakeLists.txt :
# Dans src/CMakeLists.txt
target_sources(tzpuPico PRIVATE
    ...
    drivers/BBC/ModelB.c        # existant
    drivers/BBC/VIA6522.c       # votre nouveau pilote
)

target_compile_definitions(tzpuPico PRIVATE
    INCLUDE_BBC_DRIVERS=1
)

Compilation et test

# Depuis la racine du projet
./build_tzpuPico.sh

# Flasher via stockage de masse USB
cp build/bin/model/BaseM6502/BaseM6502_0x10020000.uf2 /media/$USER/RPI-RP2/

# Ou OTA : telecharger via http://<device-ip>/ota-rp2350.htm

Modeles de hooks memoire

Parce que le 6502 n'a pas d'espace E/S, tous les modeles de hooks utilisent memioPtr[]. Les modeles sont les memes que ceux decrits dans le Guide du developpeur picoZ80 — Modeles de hooks memoire, avec le modele de handler de port E/S remplace par un handler mappe en memoire a n'importe quelle plage d'adresses. Les modeles cles pour les pilotes 6502 sont :

Bloc FUNC — Peripherique virtuel

Installer un handler pour une plage d'adresses contigue. C'est le modele standard pour toute l'emulation de peripheriques 6502 :
// Installer le handler pour la plage d'adresses 0xD000–0xD0FF (bloc peripherique de 256 octets)
for(uint16_t addr = 0xD000; addr <= 0xD0FF; addr++)
{
    cpu->_6502PSRAM->memioPtr[addr] = MyPeripheral_Handler;
}

Interception d'ecriture RAM

Intercepter les ecritures dans une region RAM tout en permettant les lectures depuis la PSRAM. Utile pour observer les acces a la page zero ou detecter les ecritures a des adresses specifiques :
// Le handler intercepte les ecritures ; passe les lectures a la PSRAM
static uint8_t ZeroPage_Intercept(M6502CPU *cpu, bool read, uint16_t addr, uint8_t data)
{
    if(read)
    {
        // Lecture normale depuis la PSRAM
        return cpu->_6502PSRAM->RAM[addr];
    }
    else
    {
        // Ecriture dans la PSRAM et mise a jour de l'etat shadow
        cpu->_6502PSRAM->RAM[addr] = data;
        MyDriver_OnZeroPageWrite(addr, data);
        return 0;
    }
}

// Dans init : definir le type de bloc a FUNC et installer le handler
cpu->_membankPtr[0x0000 >> 9] = MEMBANK_ENCODE(MEMBANK_TYPE_FUNC, 0, 0x0000);
cpu->_6502PSRAM->memioPtr[0x0000] = ZeroPage_Intercept;
// ... repeter pour chaque bloc de 512 octets dans la plage

Adresses eparses / individuelles

Pour du materiel ou seules quelques adresses comptent dans une region plus large (ex. un decodeur d'adresse 4 bits), installer le handler uniquement sur ces adresses specifiques et laisser le reste retourner 0xFF ou des donnees PSRAM :
// Seules les adresses 0xFFFE et 0xFFFF (vecteur de reset du 6502) sont interceptees
cpu->_6502PSRAM->memioPtr[0xFFFE] = ResetVector_Lo_Handler;
cpu->_6502PSRAM->memioPtr[0xFFFF] = ResetVector_Hi_Handler;

Persona BBC Model B (substitution)

Le seul pilote actuellement present dans le firmware du pico6502 est la persona BBC Model B (src/drivers/BBC/ModelB.c). C'est une substitution en phase precoce qui demontre le modele d'enregistrement de pilote mais n'implemente pas encore le materiel complet du BBC Micro — le 6845 CRTC, les 6522 VIA, le 6850 ACIA, la puce teletext SAA5050 et l'ULA ne sont pas virtualises.
Le BBC Model B est une premiere cible appropriee pour le pico6502 car il utilise un 6502 standard a 2 MHz, possede du materiel bien documente et repose entierement sur des peripheriques mappes en memoire — ce qui s'aligne naturellement avec le modele de peripheriques base sur FUNC du pico6502. Lorsque la persona sera complete, elle devra virtualiser au minimum :
Adresse Largeur Puce Fonction
0xFC00–0xFCFF 256 o 6845 CRTC Timing video / generateur d’adresse memoire
0xFE00–0xFE0F 16 o 6522 VIA A VIA systeme (clavier, son, RTC)
0xFE40–0xFE4F 16 o 6522 VIA B VIA utilisateur (port parallele, E/S utilisateur)
0xFE60–0xFE6F 16 o 6850 ACIA Interface serie
0xFC00–0xFCFF 256 o SAA5050 / ULA Teletext / ULA video
0xFE30 1 o ROM select Registre de selection de banque ROM laterale

Interaction Core 0 / Core 1

Le modele de file inter-coeurs est identique a celui du picoZ80. Referez-vous au Guide du developpeur picoZ80 — Interaction Core 0 / Core 1 pour la description complete et l'exemple de code. La seule difference de nommage est que la file est accedee via un pointeur M6502CPU *cpu au lieu de Z80CPU *cpu.
Regle cle : les callbacks handler et poll s'executent sur le Core 1. Toute E/S fichier, commande UART vers l'ESP32 ou autre operation bloquante doit etre postee au Core 0 via cpu->requestQueue. Les resultats sont retournes via cpu->responseQueue et traites dans task_ptr.

Pieges courants

  • Installer un handler dans ioPtr au lieu de memioPtr. Le pico6502 n'a pas de tableau ioPtr[]. Tous les handlers de peripheriques vont dans memioPtr[]. Tenter d'utiliser ioPtr[] causera une erreur de compilation ou un comportement indefini.
  • Attendre un appel de dispatch E/S. Il n'y a pas de M6502CPU_readIO() ou M6502CPU_writeIO(). Si vous portez un pilote Z80 qui utilise ioPtr[], deplacez tous ces handlers vers memioPtr[] aux adresses memoire appropriees.
  • Bloquer dans un handler. Tout appel a debugf, sleep_ms ou fopen depuis un handler bloquera le Core 1 et corrompra le timing bus du 6502. Utilisez la file inter-coeurs pour toutes les operations bloquantes.
  • Nom virtualFuncMap non concordant. Le champ JSON "name" est mis en correspondance sans distinction de casse avec la table virtualFuncMap[] dans M6502CPU.c. Une faute de frappe dans l'un ou l'autre sautera silencieusement le pilote. Ajoutez un debugf temporaire dans M6502CPU_getVirtualFunc() pour diagnostiquer.
  • Erreur d'un dans la plage du handler. Utilisez addr <= endAddr pas addr < endAddr + 1 — cette derniere risque un debordement d'entier a 0xFFFF. Utilisez addr <= 0xFFFF avec une variable de boucle uint32_t si la plage s'etend jusqu'au sommet de la memoire.
  • Oublier de definir le type de bloc a FUNC. Installer un handler dans memioPtr[] n'a aucun effet si les entrees _membankPtr[] correspondantes indiquent toujours MEMBANK_TYPE_RAM ou MEMBANK_TYPE_ROM. Appelez toujours MEMBANK_ENCODE(MEMBANK_TYPE_FUNC, ...) pour chaque bloc de 512 octets dans la plage de votre handler.
  • reset_ptr non efface lors de l'arret du pilote. Si votre pilote est reconfigure a l'execution et que le callback de reset n'est plus valide, effacez cpu->reset_ptr a NULL avant de reinitialiser, sinon le Core 1 appellera un pointeur de fonction obsolete lors du prochain reset.

Sites de reference

Ressource Lien
Page du projet pico6502 /pico6502/
Manuel d’utilisation du pico6502 /pico6502-usermanual/
Guide technique du pico6502 /pico6502-technicalguide/
Guide du developpeur picoZ80 /picoz80-developersguide/
Page du projet picoZ80 /picoz80/
Fiche technique du RP2350 datasheets.raspberrypi.com
API Multicore du Pico SDK raspberrypi.github.io/pico-sdk-doxygen
Fiche technique du MOS 6502 archive.org
Guide materiel BBC Micro stardot.org.uk
Bibliotheque cJSON github.com/DaveGamble/cJSON

Avis reglementaire sans fil

Cet appareil incorpore un module sans fil ESP32-S3-PICO-1 qui emet dans la bande ISM 2,4 GHz, ce qui en fait un emetteur intentionnel au regard des reglementations de radiofrequences dans le monde entier (y compris FCC Part 15 Subpart C aux Etats-Unis et la Directive Equipements Radio 2014/53/EU dans l'Union europeenne).
Bien que le module ESP32-S3-PICO-1 lui-meme possede des certifications reglementaires prealables (FCC, CE et autres), ces certifications au niveau du module ne s'etendent pas automatiquement a un produit fini qui incorpore le module. L'exemption de module pre-certifie permet aux hobbyistes individuels de construire un nombre limite d'appareils pour un usage personnel, experimental ou educatif sans obtenir d'autorisation d'equipement separee.
Limitations importantes
  • Les appareils assembles ne doivent pas etre vendus, proposes a la vente, offerts ou distribues de quelque maniere que ce soit a des tiers, sauf si le produit fini a ete teste independamment et a obtenu sa propre autorisation d'equipement (ex. FCC ID, marquage CE avec evaluation d'un organisme notifie) dans la juridiction concernee.
  • La construction de ce projet pour un usage personnel en quantites limitees est generalement autorisee en vertu des dispositions pour hobbyistes et usage experimental (ex. FCC § 15.23), a condition que l'appareil ne cause pas d'interferences nuisibles.
  • Les exigences reglementaires varient selon les pays. Les constructeurs en dehors des Etats-Unis doivent consulter leur autorite nationale des radiofrequences pour les regles applicables.
Responsabilite du constructeur
Il est de la seule responsabilite du constructeur de s'assurer que tout appareil construit a partir de ces conceptions est conforme a toutes les reglementations de radiofrequences applicables dans sa juridiction. L'auteur fournit ces conceptions pour un usage personnel, educatif et de hobbyiste et ne garantit pas qu'un appareil construit a partir de celles-ci satisfait aux exigences reglementaires pour la distribution commerciale.