Carte PICO Raspberry Atari 2600 multi roms

[Bricox]

Encore merci Andréa.

Je n'ai pas assez analysé en profondeur l'intégralité de ton code.
Je n'avais pas imaginé l'overclocking dynamique.

Je prends encore plus conscience de la qualité de ton travail et de tes partages.

[Bricox]

Je viens d'explorer ton projet PicoVideoCart.

Pour ce faire, le Pico doit fonctionner à 400mhz, à des vitesses inférieures, le système ne démarre pas.

Effectivement, 400 MHz est ici : https://github.com/aotta/PicoVideocart/ ... t.ino#L196

Code : Tout sélectionner

load_game(romFile);
 
if (!set_sys_clock_khz(400000, false)) { // 428000 is known to work on some devices
   blink_code(BLINK::OVERCLOCK_FAILED);
   // panic("Overclock was unsuccessful");
}

Juste après le load_game ...

[Bricox]

Il suffit de faire quelques tests avec des overclocks décroissants de 270 à 133 pour voir quand le 2600 cessera de fonctionner !

Bonne idée @aotta ...

Pour expérimenter l'effet de la fréquence du Pico sur la fiabilité de l'émulation ROM/RAM, je vais implémenter une fonctionnalité permettant de faire varier/afficher la fréquence sans recompiler/uploader le fichier UF2.

Le principe est d'ajouter un potentiomètre sur une entrée analogique et utiliser cette valeur pour paramétrer la fréquence.
J'utiliserai le nouveau mode Trace UART pour afficher la fréquence à chaque redémarrage.

[hlide]

Bonne initiative . Ça permettra d'affiner, même si à la moindre pétouille, il faudra quand même relancer la console mais ça reste infiniment meilleure que de reflasher .

[Bricox]

J'utiliserai un potentiomètre 10 tours avec cadran : https://fr.aliexpress.com/item/1005003981002645.html
Dans mes tiroirs, j'ai ce modèle, 3590s-2-103 : https://www.cdiscount.com/musique-instr ... 71163.html

multitoursCadran.jpg (20.03 Kio) Consulté 416 fois

Le cadran est gradué de 0 à 999, cela permet de fixer la valeur avant la mise sous tension.
Il suffit de connaître la correspondance cadran/fréquence qui, normalement, doit être linéaire.
Il faut juste réaliser un petit calcul pour obtenir cela :
000 cadran = 100 MHZ
600 cadran = 400 MHZ
Ce qui donne l'équation : Y cadran = 2 x (Fréquence - 100 MHz)
Exemple pour 275 MHz : Y = 2 x (275-100) = 350

[Bricox]

Avant de mettre en œuvre mon potentiomètre 10 tours, j'ai analysé les fonctions SDK des horloges du RP2040.

Après qques essais, je me suis rendu compte que seuls les multiples de 3 de la fréquence ne généraient pas cette erreur :
"System clock of %u kHz cannot be exactly achieved".

J'ai donc regardé en détail les 2 fonctions suivantes :

1. bool set_sys_clock_khz() dans C:\Program Files\Raspberry Pi\Pico SDK v1.5.1\pico-sdk\src\common\pico_stdlib\include\pico\stdlib.h

   Code : Tout sélectionner

   static inline bool set_sys_clock_khz(uint32_t freq_khz, bool required) {
       uint vco, postdiv1, postdiv2;
       if (check_sys_clock_khz(freq_khz, &vco, &postdiv1, &postdiv2)) {
           set_sys_clock_pll(vco, postdiv1, postdiv2);
           return true;
       } else if (required) {
           panic("System clock of %u kHz cannot be exactly achieved", freq_khz);
       }
       return false;
   }
   

2. check_sys_clock_khz() dans C:\Program Files\Raspberry Pi\Pico SDK v1.5.1\pico-sdk\src\rp2_common\pico_stdlib\stdlib.c

   Code : Tout sélectionner

   bool check_sys_clock_khz(uint32_t freq_khz, uint *vco_out, uint *postdiv1_out, uint *postdiv2_out) {
       uint reference_freq_khz = XOSC_KHZ / PLL_COMMON_REFDIV;
       for (uint fbdiv = 320; fbdiv >= 16; fbdiv--) {
           uint vco_khz = fbdiv * reference_freq_khz;
           if (vco_khz < PICO_PLL_VCO_MIN_FREQ_KHZ  || vco_khz > PICO_PLL_VCO_MAX_FREQ_KHZ) continue;
           for (uint postdiv1 = 7; postdiv1 >= 1; postdiv1--) {
               for (uint postdiv2 = postdiv1; postdiv2 >= 1; postdiv2--) {     // pourquoi postdiv2 = postdiv1 ? et pas postdiv2 = 7
                   uint out = vco_khz / (postdiv1 * postdiv2);
                   if (out == freq_khz && !(vco_khz % (postdiv1 * postdiv2))) {
                       *vco_out = vco_khz * KHZ;
                       *postdiv1_out = postdiv1;
                       *postdiv2_out = postdiv2;
                       return true;
                   }
               }
           }
       }
       return false;
   }
   

   et là, SURPRISE !!! PLL_COMMON_REFDIV est toujours égal à 1, alors que la datasheet du RP2040 permet la valeur 2, page 229/641.

   

   horlogeRP2040.png (35.77 Kio) Consulté 332 fois

   
   Avec la fonction SDK, voici ma simulation Excel => multiple de 3 uniquement :
   

   	RP2040	Possible
   FREF (quartz)	12 MHz
   REFDIV	_ 1 _	<=2
   FREF/REFDIV	12 MHz	>=5
   FBDIV	133	16-320
   FOUTVCO	1596 MHz	750-1600
   POSTDIV1	_ 4 _	1-7
   POSTDIV2	_ 1 _	1-7
   FOUTPOSTDIV	399 MHz
   FREF/REFDIV/POSTDIV1/POSTDIV2	+/- 3 MHz

   
   Alors que la datasheet RP2040 permet cela => multiple de 3 ET multiple de 2 :
   

   	RP2040	Possible
   FREF (quartz)	12 MHz
   REFDIV	_ 2 _	<=2
   FREF/REFDIV	6 MHz	>=5
   FBDIV	145	16-320
   FOUTVCO	870 MHz	750-1600
   POSTDIV1	_ 3 _	1-7
   POSTDIV2	_ 1 _	1-7
   FOUTPOSTDIV	290 MHz
   FREF/REFDIV/POSTDIV1/POSTDIV2	+/- 2 MHz

   
   Il suffit de modifier la fonction check_sys_clock_khz() pour offrir plus de fréquences possibles ...
   
   Bien évidemment, les fréquences multiples des nombres 1ers supérieurs à 3 restent inacccessibles : 5, 7, 11,13, 17, etc ...
   
   [EDIT d'ajustement]
   Avec la fonction SDK, voici ma simulation Excel => multiple de 3 ET multiple de 2 mais jusqu'à 266 MHZ , sinon le critère FOUTVCO n'est plus assuré :
   

   	RP2040	Possible
   FREF (quartz)	12 MHz
   REFDIV	_ 1 _	<=2
   FREF/REFDIV	12 MHz	>=5
   FBDIV	133	16-320
   FOUTVCO	1596 MHz	750-1600
   POSTDIV1	_ 6 _	1-7
   POSTDIV2	_ 1 _	1-7
   FOUTPOSTDIV	266 MHz
   FREF/REFDIV/POSTDIV1/POSTDIV2	+/- 2 MHz

[Bricox]

Revenons à la mesure de durée d'exécution de code RP2040.

J'ai commencé cette petite étude dans le sujet Minitel : viewtopic.php?p=253748#p253748

@hlide, tu m'as suggéré d'ajuster cette mesure en tenant compte de la durée d'exécution de l'outil, lui même.
J'ai trouvé 4 ticks
J'ai donc intégré cet ajustement dans ma mesure de durée.

@hlide, tu m'as suggéré de lancer le mode Trace UART dans le core0 qui ne réalise pas l'émulation ROM/RAM.
Je mesure donc la durée dans le core1 d'émulation ROM/RAM puis je passe la main au core1 pour le mode trace.
Ca fonctionne super bien, au moins jusqu'à une fréquence RP2040 de 360 MHZ ...
Bien plus que ce que me disait @aotta, mais peut-être parlait-il du mode trace USB ...

J'ai mesuré la modification de l'adresse de sortie de la DMZ avec un memcopy() => 600ns au mini à fréqPico=360 MHZ.

Code : Tout sélectionner

memcpy(&rom_tab[0xffb],&vector_tab[4],2);		// replace eternal loop address by game array address

La commutation, vers le binaire de jeu, n'est pas assurée dans ce délai.

[Bricox]

Défit : Réduction de la durée de modification de l'adresse de sortie de la DMZ.

Je vais scinder cette commutation en 2 étapes puis je donne le coup de grâce ...

1. Déclarer puis fixer l'adresse de l'adresse de sortie qui est constante :

   Code : Tout sélectionner

   uint16_t *jmp16Addr=(uint16_t*)(rom_tab+0xffb);
   

2. Réaliser une affection d'adresse (uint16_t), sans fonction

   Code : Tout sélectionner

   *jmp16Addr=*(uint16_t*)(vector_tab+4);			// commutation en 10ns pour freqPico=210MHz
   

J'ai divisé la durée par 60 ... => il faut bannir memcopy() pour ce type d'affectation

La commutation, vers le binaire de jeu, est maintenant assurée ...

Autre découverte :
En baissant la freqPico de 291 à 210 MHz, la console démarre le Splash Explorer à tous les coups.
Nous pourrons augmenter l'overclockage seulement après avoir charger le binaire de jeu.

[Bricox]

Bilan de l'émulation ROM/RAM :

1. Les fonctions de base sont validées, sans IRQ, sans DMA, sans reset hardware 6507 :
   - Démarrer le Splash Explorer.
   - Valider le principe d'utilisation d'une DMZ de 3 octets, avec sauvegarde/restitution des vecteurs de fin de cartouche.
   - Commuter avec fiabilité vers le binaire de jeu.
   .
2. Fonctions bonus :
   - Le mode Trace UART vers Putty, jusqu'à 360 MHZ, avec l'option Trace de tableaux.
   - Mesure de durée d'exécution de codes RP2040, avec une résolution de qques ns.

Code : Tout sélectionner

PicoFreq=210 MHz

rom_tab[ff0 to fff]
Index : 0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
 0ff0 : 09 18 10 30 08 04 0c 04 ff ff 4c 00 f0 f0 ff ff

Replace address=0.010 µs
Restore vectors=1.681 µs

rom_tab[ff0 to fff]
Index : 0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
 0ff0 : 09 18 10 30 08 04 0c 04 14 18 14 18 00 f0 00 00

[c52back]

Tu t'amuses comme un fou Bricox.
Bravo pour ton travail ,ne laisse pas tomber.

[6502man]

Merci pour le partage et les explications

[Bricox]

Avant de mettre en œuvre mon potentiomètre 10 tours, j'ai analysé les fonctions SDK des horloges du RP2040.

et là, SURPRISE !!! PLL_COMMON_REFDIV est toujours égal à 1, alors que la datasheet du RP2040 permet la valeur 2, page 229/641.

Mon analyse n'était pas complète, c'est un peu plus compliqué.

J'ai donc construit un graphique complet permettant de connaitre les multiples de fréquences d'horloge possibles du RP2040, dans 2 options :
- Les fonctions SDK standards, avec PLL_COMMON_REFDIV=1 uniquement.
- La fonction check_sys_clock_khz() complétée, permettant à PLL_COMMON_REFDIV de prendre les 2 valeurs 1 ou 2.

multiFreqClockRP2040.png (8.01 Kio) Consulté 141 fois

[Bricox]

Voici le bilan des tests de jeux:

Date	Time	Size	Name	Type	Test
24/12/1996	15:32	2048	olympic.bin		---
19/07/2000	20:52	4096	atlantis.bin	ground/air	_ oui _
27/04/2001	23:20	4096	raiders.bin	plane simul	_ oui _
24/12/1996	15:32	4096	pinball.bin		_ oui _
17/07/2000	13:45	4096	Space.bin	invaders	_ oui _
24/12/1996	15:32	4096	Pac-Man.bin	miam	_ oui _
28/12/2007	02:21	4096	Warplock.bin	space battle	_ oui _

Nous n'avons pas encore traité les jeux 2K.

[Bricox]

Bilan des mesures de durées critiques :

Replace DMZ address = 0.010 µs, soit 10 ns, pour commencer à sortir de la boucle éternelle DMZ du 6507.
Restore vectors = 0.057 µs, soit 57 ns, pour restaurer la zone de la DMZ(8 octets), en fin de cartouche.

Replace DMZ address to First Game address on bus = 2.667 µs, pour arriver à la 1ère adresse du jeu.

[Bricox]

Mon analyse n'était pas complète, c'est un peu plus compliqué.

J'ai donc construit un graphique complet permettant de connaitre les multiples de fréquences d'horloge possibles du RP2040, dans 2 options :
- Les fonctions SDK standards, avec PLL_COMMON_REFDIV=1 uniquement.
- La fonction check_sys_clock_khz() complétée, permettant à PLL_COMMON_REFDIV de prendre les 2 valeurs 1 ou 2.

Je n'étais pas satisfait de la 1ère version du graphique ... , j'ai :
- ajouté les valeurs mini et maxi pour chaque plage de fréquences.
- supprimé le multiple 12, correspondant à des fréquences trop élévées.
- renommé mes plages vertes qui correspondent uniquement à REFDIF=2, si REFDIF=1ou2 alors les plages rouges et vertes sont cumulées.

multiFreq2ClockRP2040.png (10.3 Kio) Consulté 69 fois