[DCMOTO] Emulation du générateur de son SN76489
Modérateurs : Papy.G, fneck, Carl
[DCMOTO] Emulation du générateur de son SN76489
Nouvelle version de développement 2023.01.29 --> http://dcmoto.free.fr/emulateur/index.html
Par rapport à la version 2023.01.28, il y a deux changements :
- Retour au coefficient correct pour obtenir la bonne fréquence (je n'ai pas vérifié, il faudrait faire des mesures précises)
- Ajout de la sélection de l'adresse dans la boîte de dialogue Options
La lecture (trop rapide de 6,98% selon Bentoc) n'a pas de rapport avec l'émulation du SN76489. Elle dépend uniquement de la fréquence d'horloge du processeur 6809. Dans dcmoto cette fréquence est synchronisée avec la carte son, il est surprenant qu'il y ait un tel écart. Si c'est vraiment le cas, on peut corriger en jouant sur la fréquence du processeur dans la boîte de dialogue Options.
Toutes les remarques ou suggestions pour améliorer l'émulation sont les bienvenues.
Par rapport à la version 2023.01.28, il y a deux changements :
- Retour au coefficient correct pour obtenir la bonne fréquence (je n'ai pas vérifié, il faudrait faire des mesures précises)
- Ajout de la sélection de l'adresse dans la boîte de dialogue Options
La lecture (trop rapide de 6,98% selon Bentoc) n'a pas de rapport avec l'émulation du SN76489. Elle dépend uniquement de la fréquence d'horloge du processeur 6809. Dans dcmoto cette fréquence est synchronisée avec la carte son, il est surprenant qu'il y ait un tel écart. Si c'est vraiment le cas, on peut corriger en jouant sur la fréquence du processeur dans la boîte de dialogue Options.
Toutes les remarques ou suggestions pour améliorer l'émulation sont les bienvenues.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
Re: [DCMOTO] Emulation du générateur de son SN76489
Merci Daniel,
J'ai remarqué que la différence de vitesse de lecture variait en fonction du lecteur que j'utilise.
La différence entre les lecteurs est le temps passé dans l'IRQ à décompresser le flux d'une manière plus ou moins sophistiquée.
Je me demande si le problème ne vient pas du fait que le temps passé dans l'IRQ ne serait pas pris en compte dans le nombre de cycles écoulés du 6809 utilisés pour synchroniser les cycles du SN76489.
Rendant ainsi une lecture plus rapide.
J'ai remarqué que la différence de vitesse de lecture variait en fonction du lecteur que j'utilise.
La différence entre les lecteurs est le temps passé dans l'IRQ à décompresser le flux d'une manière plus ou moins sophistiquée.
Je me demande si le problème ne vient pas du fait que le temps passé dans l'IRQ ne serait pas pris en compte dans le nombre de cycles écoulés du 6809 utilisés pour synchroniser les cycles du SN76489.
Rendant ainsi une lecture plus rapide.
Re: [DCMOTO] Emulation du générateur de son SN76489
Si les IRQs ne sont pas désactivées, il y a une explication : dcmoto n'émule pas la souris, le clavier et le crayon optique au niveau matériel. Il y a donc des routines complètement ignorées. Pour en tenir compte j'ai ajouté des temporisations très grossièrement estimées, et ça peut provoquer des écarts.
Les routines suivantes sont concernées : lecture position souris, lecture boutons souris, lecture du clavier, lecture position crayon optique. Je compte arbitrairement 32 cycles pour chaque opération, c'est probablement en-dessous de la réalité, au moins pour certaines d'entre elles. Si ces routines sont appelées, c'est certainement la cause de l'écart de vitesse. Pour corriger il faudrait faire une estimation plus sérieuse. En attendant, un ajustement de la vitesse du processeur (dans les options) peut masquer le problème.
Les routines suivantes sont concernées : lecture position souris, lecture boutons souris, lecture du clavier, lecture position crayon optique. Je compte arbitrairement 32 cycles pour chaque opération, c'est probablement en-dessous de la réalité, au moins pour certaines d'entre elles. Si ces routines sont appelées, c'est certainement la cause de l'écart de vitesse. Pour corriger il faudrait faire une estimation plus sérieuse. En attendant, un ajustement de la vitesse du processeur (dans les options) peut masquer le problème.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
Re: [DCMOTO] Emulation du générateur de son SN76489
Je n'utilise pas ces routines, j'ai paramétré une irq à 19967 cycles sur une routine personnalisée.
Cette routine envoie les ordres au chip son.
J'ai réalisé quelques tests en ajoutant une temporisation dans l'IRQ de 4000 cycles ou 8000 cycles, la lecture est toujours trop rapide mais l'effet est atténué.
J'essaye d'investiguer et te tiens au courant.
Cette routine envoie les ordres au chip son.
J'ai réalisé quelques tests en ajoutant une temporisation dans l'IRQ de 4000 cycles ou 8000 cycles, la lecture est toujours trop rapide mais l'effet est atténué.
J'essaye d'investiguer et te tiens au courant.
-
- Messages : 7986
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [DCMOTO] Emulation du générateur de son SN76489
Le timer est un sujet complexe: viewtopic.php?f=24&t=7743
L'écart de 6% mesuré dans le BPM est énorme, ca correspond environ à 1200 cycles cpu. C'est trop grand pour être issu de correctifs de l'ordre de 32 cycles. Ca correspond plus à une durée où l'on aurait bloqué l'IRQ pour faire un traitement. Sauf que si on bloque une IRQ, ca ralentie sa fréquence, pas l'accélérer au point de jouer 6% trop vite. J'suis perplexe.
En outre, en toute logique, le timer fonctionnant en mode continue (on ne doit pas le relancer), ralentir le traitement de l'IRQ ne devrait pas perturber sa période.
L'écart de 6% mesuré dans le BPM est énorme, ca correspond environ à 1200 cycles cpu. C'est trop grand pour être issu de correctifs de l'ordre de 32 cycles. Ca correspond plus à une durée où l'on aurait bloqué l'IRQ pour faire un traitement. Sauf que si on bloque une IRQ, ca ralentie sa fréquence, pas l'accélérer au point de jouer 6% trop vite. J'suis perplexe.
En outre, en toute logique, le timer fonctionnant en mode continue (on ne doit pas le relancer), ralentir le traitement de l'IRQ ne devrait pas perturber sa période.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: [DCMOTO] Emulation du générateur de son SN76489
je ne peux pas vous aider pour solutionner le problème mais je ne doute pas que Daniel trouve d'où il vient.
par contre j'ai une idée, je ne sais pas si elle est réalisable : dcmoto serait il capable de jouer la musique 1bit pu 6bits vers l'extension musique et jeux directement vers la nouvelle carte son ? au moins pour les jeux qui utilisent la fonction play du basic ou du moniteur ?
une sorte de conversion a la volée?
et pour la vraie carte son, dcmoto serait il capable d'écrire dans un fichier log les notes des musiques jouées dans les jeux?
les notes pourraient ensuite être converties pour la vraie carte son.
un peu comme tous les gens qui ont extrait les musiques SID des jeux commodore c64.
par contre j'ai une idée, je ne sais pas si elle est réalisable : dcmoto serait il capable de jouer la musique 1bit pu 6bits vers l'extension musique et jeux directement vers la nouvelle carte son ? au moins pour les jeux qui utilisent la fonction play du basic ou du moniteur ?
une sorte de conversion a la volée?
et pour la vraie carte son, dcmoto serait il capable d'écrire dans un fichier log les notes des musiques jouées dans les jeux?
les notes pourraient ensuite être converties pour la vraie carte son.
un peu comme tous les gens qui ont extrait les musiques SID des jeux commodore c64.
Re: [DCMOTO] Emulation du générateur de son SN76489
On ne peut pas envoyer du son 1 bit ou 6 bits vers le SN74489. Il sait uniquement générer du son en sortie à partir de commandes en entrée.
Dans l'ordinateur Thomson les quatre différentes sources de son : buzzer, cna, cassette audio et contrôleur externe sont mixées pour être envoyées au téléviseur ou au moniteur via la péritel. L'émulateur dcmoto réalise la même opération (sauf qu'il ne traite pas le son audio de la cassette) et envoie le résultat mixé vers la carte son du PC. Il est facile d'enregistrer cette sortie dans un fichier .wav pour l'analyser ensuite.
Je ne sais pas s'il est possible, à partir d'un fichier .wav, de composer automatiquement une séquence de commande pour la carte son. Ce n'est pas du domaine de l'émulation. Il faudrait ouvrir un nouveau sujet de discussion.
Dans l'ordinateur Thomson les quatre différentes sources de son : buzzer, cna, cassette audio et contrôleur externe sont mixées pour être envoyées au téléviseur ou au moniteur via la péritel. L'émulateur dcmoto réalise la même opération (sauf qu'il ne traite pas le son audio de la cassette) et envoie le résultat mixé vers la carte son du PC. Il est facile d'enregistrer cette sortie dans un fichier .wav pour l'analyser ensuite.
Je ne sais pas s'il est possible, à partir d'un fichier .wav, de composer automatiquement une séquence de commande pour la carte son. Ce n'est pas du domaine de l'émulation. Il faudrait ouvrir un nouveau sujet de discussion.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
Re: [DCMOTO] Emulation du générateur de son SN76489
Alors ne serait-il possible d'intercepter les notes en $E81E et de les écrire dans un fichier (pour les logiciels et jeux qui utilisent cette entrée du moniteur) et aussi de convertir les notes $E81E vers la nouvelle carte son ? (avec une option dans dcmoto).
on pourrait alors voir la différence de rendu pour un même jeu ou logiciel.
bien entendu je sais que beaucoup de jeux ne passent pas par cette routine.
on pourrait alors voir la différence de rendu pour un même jeu ou logiciel.
bien entendu je sais que beaucoup de jeux ne passent pas par cette routine.
Re: [DCMOTO] Emulation du générateur de son SN76489
Oui et non, il existe des versions de cette puce dont la broche NC est AUDIO_IN qui permet de mixer ce son entrant à celui produit par cette puce. Le SHARP MZ-800 et MZ-1500 le font. La seule chose qui me semble bizarre, c'est qu'ils parlent de SN76489A dans leur schémas - une version supposée avoir NC et non AUDIO_IN.On ne peut pas envoyer du son 1 bit ou 6 bits vers le SN74489.
Voir ici le schéma.
-
- Messages : 7986
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [DCMOTO] Emulation du générateur de son SN76489
Ce n'est pas un problème de justesse de note je crois. Mais de temporisation.
Par comparaison avec la référence il a été mesuré que les beats (le fameux BPM) arrivent un peu trop vite sous DCMoto. Cela est lié à la fréquence d'appel des routines du "player". Cette fréquence est fixée par le timer callé à la période d'une VBL (19968 µs).
De mon coté j'ai fait de mesure de la précision du timer et de l'IRQ par analyse spectrale d'un signal à 440Hz. Le pic est très pointu et précis. Je ne relève pas l'écart de 6% mesuré sur une musique complexe.
Bon par contre j'ai un truc, mais il se fait tard. J'en parlerais demain.
Par comparaison avec la référence il a été mesuré que les beats (le fameux BPM) arrivent un peu trop vite sous DCMoto. Cela est lié à la fréquence d'appel des routines du "player". Cette fréquence est fixée par le timer callé à la période d'une VBL (19968 µs).
De mon coté j'ai fait de mesure de la précision du timer et de l'IRQ par analyse spectrale d'un signal à 440Hz. Le pic est très pointu et précis. Je ne relève pas l'écart de 6% mesuré sur une musique complexe.
Bon par contre j'ai un truc, mais il se fait tard. J'en parlerais demain.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: [DCMOTO] Emulation du générateur de son SN76489
Je laisse la primeur de l’explication de ce qui a été trouvé hier soir à sam. après une séance de 4h de debug et de recherches qui ont fini par être payantes. Merci à fxrobin et a sam !
Je confirme juste que le problème n’est pas du tout lié a l’émulation du nouveau chipset sonore (encore merci Daniel), ni à la routine de lecture que j’utilise.
Je confirme juste que le problème n’est pas du tout lié a l’émulation du nouveau chipset sonore (encore merci Daniel), ni à la routine de lecture que j’utilise.
Re: [DCMOTO] Emulation du générateur de son SN76489
Merci à tous les trois pour vos recherches. C'est en étudiant les comportements anormaux que l'on peut faire progresser l'émulation, et j'apprécie énormément votre aide. Nous sommes tous impatients d'avoir les explications...
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
-
- Messages : 7986
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [DCMOTO] Emulation du générateur de son SN76489
Je crois que nous avons bien cernés le problème, et comme signalé par Bentoc, ca n'est pas lié aux changements récents, ni aux trucs "évident". Pour tout dire c'est assez subtil, mais nous avons trouvés un programme qui permet de mettre en évidence le soucis de façon certaine:
Ce programme semble complexe, mais est en réalité très simple. Il émets un BEEP, puis attends environ 120 000 000 cycles(*) et émets un second BEEP puis rends la main.
____
(*) Bon en réalité c'est quelques cycles de plus, mais pour simplifier on va dire 2 mins car les cycles en plus sont négligeables par rapport à la précision souhaitée.
Si on le lance on peut chronométrer le temps entre les deux BEEPs. Un chronomètre manuel suffit, mais perso j'utilise audacity pour enregistrer le son et repérer par horodatage la durée entre les deux BEEPs. Ca convient tout à fait et c'est très pratique car ca réduit l'imprécision du chrono manuel.
Si on lance le BIN (voir fichiers joints) depuis le basic sur TEO ou Téodore, il y a exactement 2mins entre les deux beeps. Pas de soucis, c'est ce qui est prévu.
Si on fait pareil avec la dernière version de DCmoto2023.01.29, on mesure: Oui : sensiblement 1m50s, soit 10 secs trop vite pour 2 minutes. Dix secondes c'est peu (7-8%), mais c'est suffisant pour être mesurable avec fiabilité. Au fait ces 7-8% ne vous rappellent rien ? Si si, on est dans la même fourchette de l'erreur de BPM, sauf que ce coup-ci il n'y a pas d'IRQ ou de carte son en jeu. C'est du pur comptage de cycles.
On a vérifié les trace de DCMoto, il n'y a aucune erreur de cycle, mais ce qu'on a remarqué c'est que la dérive est lié à la fréquence d'échantillonnage dans les options de DCMoto. A 25kHz on mesure 9-10secondes d'avances sur 2mins; mais à 12.5kHz, il n'y a plus que 4-5secondes d'avance. A 6.25 on tombe autour de la seconde. A 3.125 on n'arrive plus à mesurer d'écart.
Autre chose trouvé: le phénomène d'avance ne se produit pas avec dcmoto_20170714, mais en revanche il est déjà là sur la version dcmoto_20170903. Cela limite sérieusement les changements qui ont introduits le phénomène. Force est de constater qu'il est ancien, et il fallait l'oreille de musiciens pour s'apercevoir qu'un truc n'allait pas au niveau des timings de DCMoto dans certains cas.
A remarquer: le nombre de cycles moyens consommé par les instructions de la boucle entre en jeu. Si au lieu de faire 40 PSHS de 15cycles, on en fait seulement 10 mais 4x plus de tours de boucle, ou si l'on fait des PSHS plus petits (5 cycles) mais en plus grand nombre, il n'y a quasiment plus d'écart mesurable.
Tout ceci pourrait suggérer une histoire d'arrondis ou de PGCD entre la fréquence d'échantillonnage et le quanta de cycles des instructions de la boucle (25kHz=40cycles par échantillons et 40 se divise mieux en 5 cycles qu'en 15 cycles).
Code : Tout sélectionner
8000 org $8000
8000 main
8000 34 09 PSHS DP,CC
8002 1A 50 ORCC #$50
8004 C6 07 LDB #7
8006 BD E803 JSR $E803 ; beep
8009 108E 0014 LDY #20
800D loop1
800D 8E 2710 LDX #10000
8010 loop2
8010 34 7F pshs CC,D,X,Y,DP,U ; 15
8012 35 7F puls CC,D,X,Y,DP,U ; 15
8014 34 7F pshs CC,D,X,Y,DP,U ; 15
8016 35 7F puls CC,D,X,Y,DP,U ; 15
8018 34 7F pshs CC,D,X,Y,DP,U ; 15
801A 35 7F puls CC,D,X,Y,DP,U ; 15
801C 34 7F pshs CC,D,X,Y,DP,U ; 15
801E 35 7F puls CC,D,X,Y,DP,U ; 15
8020 34 7F pshs CC,D,X,Y,DP,U ; 15
8022 35 7F puls CC,D,X,Y,DP,U ; 15
8024 34 7F pshs CC,D,X,Y,DP,U ; 15
8026 35 7F puls CC,D,X,Y,DP,U ; 15
8028 34 7F pshs CC,D,X,Y,DP,U ; 15
802A 35 7F puls CC,D,X,Y,DP,U ; 15
802C 34 7F pshs CC,D,X,Y,DP,U ; 15
802E 35 7F puls CC,D,X,Y,DP,U ; 15
8030 34 7F pshs CC,D,X,Y,DP,U ; 15
8032 35 7F puls CC,D,X,Y,DP,U ; 15
8034 34 7F pshs CC,D,X,Y,DP,U ; 15
8036 35 7F puls CC,D,X,Y,DP,U ; 15
8038 34 7F pshs CC,D,X,Y,DP,U ; 15
803A 35 7F puls CC,D,X,Y,DP,U ; 15
803C 34 7F pshs CC,D,X,Y,DP,U ; 15
803E 35 7F puls CC,D,X,Y,DP,U ; 15
8040 34 7F pshs CC,D,X,Y,DP,U ; 15
8042 35 7F puls CC,D,X,Y,DP,U ; 15
8044 34 7F pshs CC,D,X,Y,DP,U ; 15
8046 35 7F puls CC,D,X,Y,DP,U ; 15
8048 34 7F pshs CC,D,X,Y,DP,U ; 15
804A 35 7F puls CC,D,X,Y,DP,U ; 15
804C 34 7F pshs CC,D,X,Y,DP,U ; 15
804E 35 7F puls CC,D,X,Y,DP,U ; 15
8050 34 7F pshs CC,D,X,Y,DP,U ; 15
8052 35 7F puls CC,D,X,Y,DP,U ; 15
8054 34 7F pshs CC,D,X,Y,DP,U ; 15
8056 35 7F puls CC,D,X,Y,DP,U ; 15
8058 34 7F pshs CC,D,X,Y,DP,U ; 15
805A 35 7F puls CC,D,X,Y,DP,U ; 15
805C 34 7F pshs CC,D,X,Y,DP,U ; 15
805E 35 7F puls CC,D,X,Y,DP,U ; 15
8060 30 1F LEAX -1,X
8062 26 AC BNE loop2 ; 10000*4*10*15 = 6s
8064 31 3F LEAY -1,Y ; 6s * 20 = 2mins (et des poussieres)
8066 26 A5 BNE loop1 ; $800D
8068 BD E803 JSR $E803 ; beep
806B 35 89 PULS DP,CC,PC
8000 end main
____
(*) Bon en réalité c'est quelques cycles de plus, mais pour simplifier on va dire 2 mins car les cycles en plus sont négligeables par rapport à la précision souhaitée.
Si on le lance on peut chronométrer le temps entre les deux BEEPs. Un chronomètre manuel suffit, mais perso j'utilise audacity pour enregistrer le son et repérer par horodatage la durée entre les deux BEEPs. Ca convient tout à fait et c'est très pratique car ca réduit l'imprécision du chrono manuel.
Si on lance le BIN (voir fichiers joints) depuis le basic sur TEO ou Téodore, il y a exactement 2mins entre les deux beeps. Pas de soucis, c'est ce qui est prévu.
Si on fait pareil avec la dernière version de DCmoto2023.01.29, on mesure: Oui : sensiblement 1m50s, soit 10 secs trop vite pour 2 minutes. Dix secondes c'est peu (7-8%), mais c'est suffisant pour être mesurable avec fiabilité. Au fait ces 7-8% ne vous rappellent rien ? Si si, on est dans la même fourchette de l'erreur de BPM, sauf que ce coup-ci il n'y a pas d'IRQ ou de carte son en jeu. C'est du pur comptage de cycles.
On a vérifié les trace de DCMoto, il n'y a aucune erreur de cycle, mais ce qu'on a remarqué c'est que la dérive est lié à la fréquence d'échantillonnage dans les options de DCMoto. A 25kHz on mesure 9-10secondes d'avances sur 2mins; mais à 12.5kHz, il n'y a plus que 4-5secondes d'avance. A 6.25 on tombe autour de la seconde. A 3.125 on n'arrive plus à mesurer d'écart.
Autre chose trouvé: le phénomène d'avance ne se produit pas avec dcmoto_20170714, mais en revanche il est déjà là sur la version dcmoto_20170903. Cela limite sérieusement les changements qui ont introduits le phénomène. Force est de constater qu'il est ancien, et il fallait l'oreille de musiciens pour s'apercevoir qu'un truc n'allait pas au niveau des timings de DCMoto dans certains cas.
A remarquer: le nombre de cycles moyens consommé par les instructions de la boucle entre en jeu. Si au lieu de faire 40 PSHS de 15cycles, on en fait seulement 10 mais 4x plus de tours de boucle, ou si l'on fait des PSHS plus petits (5 cycles) mais en plus grand nombre, il n'y a quasiment plus d'écart mesurable.
Tout ceci pourrait suggérer une histoire d'arrondis ou de PGCD entre la fréquence d'échantillonnage et le quanta de cycles des instructions de la boucle (25kHz=40cycles par échantillons et 40 se divise mieux en 5 cycles qu'en 15 cycles).
- Pièces jointes
-
- TST.zip
- Cas de test.
Faire LOADM"TST",,R et mesurer le temps entre les deux BEEP (environ 2 minutes) - (9.28 Kio) Téléchargé 38 fois
Dernière modification par __sam__ le 30 janv. 2023 11:39, modifié 7 fois.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: [DCMOTO] Emulation du générateur de son SN76489
Excellent j'adore l'analyse technique faite par SAM
En tout cas félicitations à vous pour avoir trouver ce bug
En tout cas félicitations à vous pour avoir trouver ce bug
-
- Messages : 7986
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [DCMOTO] Emulation du générateur de son SN76489
Ah oui j'ajoute que le moteur de jeu de Bentoc utilise beaucoup ces instructions consommant pas mal de cycles (PSHS <plein de regs>) pour déplacer ou effacer des blocs en mémoire. C'est grace à cela qu'on s'est enfin rendu compte du phénomène d'accélération de l'émulation.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos