pico6502 Guide du Developpeur
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 JSONiomap. Tous les peripheriques sont virtualises sous forme de blocs de typeFUNCdans 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
BaseM6502au lieu deBaseZ80. - 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 exec32 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
/WAITdu 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
VirtualFuncet la rechercheM6502CPU_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 :
- Attendre IRQ 0 (adresse valide sur PHI1).
- Lire l'adresse 16 bits depuis le FIFO RX de PIO 0.
- Rechercher
_membankPtr[addr >> 9]pour obtenir le type de bloc, la banque et la base. - Determiner RNW (read/not-write) depuis le PIO de controle.
- 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 viamemPtr[addr]). - 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.
- Appeler
poll_ptrpour 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 :
- Creer un fichier d'en-tete dans
src/include/drivers/<Family>/MyDriver.h - Creer un fichier d'implementation dans
src/drivers/<Family>/MyDriver.c - Ajouter le fichier source a
src/CMakeLists.txt - Inclure le pilote dans
M6502CPU.csous une garde#ifdef INCLUDE_<FAMILY>_DRIVERS - Enregistrer le pilote dans
virtualFuncMap[]dansM6502CPU.c - 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 dansmemioPtr[]. Tenter d'utiliserioPtr[]causera une erreur de compilation ou un comportement indefini. - Attendre un appel de dispatch E/S. Il n'y a pas de
M6502CPU_readIO()ouM6502CPU_writeIO(). Si vous portez un pilote Z80 qui utiliseioPtr[], deplacez tous ces handlers versmemioPtr[]aux adresses memoire appropriees. - Bloquer dans un handler. Tout appel a
debugf,sleep_msoufopendepuis 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 tablevirtualFuncMap[]dansM6502CPU.c. Une faute de frappe dans l'un ou l'autre sautera silencieusement le pilote. Ajoutez undebugftemporaire dansM6502CPU_getVirtualFunc()pour diagnostiquer. - Erreur d'un dans la plage du handler. Utilisez
addr <= endAddrpasaddr < endAddr + 1— cette derniere risque un debordement d'entier a0xFFFF. Utilisezaddr <= 0xFFFFavec une variable de boucleuint32_tsi 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 toujoursMEMBANK_TYPE_RAMouMEMBANK_TYPE_ROM. Appelez toujoursMEMBANK_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_ptraNULLavant 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
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.
- 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.
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.