YENO super cassette vision

[Secamfr]

@maaax Oui je sais en dezippant ça marche

[MaaaX]

@Secamfr
Je confirme que Retroarch n'extrait que le premier fichier qu'il trouve. Je vais voir s'il y a un moyen de lui demander de tout extraire sinon il faudra que je me charge de l'extraction moi-même.

Pour le son je viens de tester sur Pi0 en 8.0.1 et sur Pi3b+ et Pi4 en 8.0.2 et j'ai toujours les craquements à la place du son du canal PCM 1bit.
Tu as quoi comme matos et comme version de Recalbox?

PS: sur Recalbox PC le son est correct et je n'ai pas pu tester sur d'autres plateformes.

[Secamfr]

@maaax J'ai testé sur la 8.1-Beta9 sur Pi4...

[MaaaX]

Merci @secamfr
Je vais retester ça.
Pour les .ZIP contenant plusieurs fichiers je confirme que je vais devoir coder l'extraction...

[MaaaX]

Bonsoir,

Le problème de son (canal PCM 1bit) et de chargement des ROMs multifichiers (.0, .1, .2, .3) depuis une archive .zip sont réglés (EmuSCV v0.10.20220310130100).
Ca sera dispo dans la prochaine version de Recalbox.

@++
EPOCH84 (aka MaaaX ^^)

P.S.: pour les pressés les dernières versions d'EmuSCV pour Windows, Mac et Linux sont disponibles là: http://www.maaax.com/emuscv/binaries/last/

[Secamfr]

@maaax Merci, il n'y a plus qu'a attendre la nouvelle version de Recalbox

[MaaaX]

Hello world!

Comme (pas) promis voici quelques explications concernant mon émulateur EmuSCV.

Tout d'abords un peu d'Histoire... ouvrez la parenthèse... mode roman ON...

Non je ne suis pas parti de rien, ça aurait été trop de travail pour un seul homme, et le but c'était aussi que ça soit intégré "rapidement" à Recalbox. J'ai donc commencé mes recherches en testant les deux seuls émulateurs existants à ma connaissance: eSCV et MESS/MAME (initialement dans MESS qui a été intégré dans MAME ensuite).
Après inspection, il se trouve que MAME reprend simplement le code d'ESCV, avec des couleurs un peu plus jolies mais sans le canal audio PCM 1bit.

Je me suis donc tourné vers eSCV qui est le fruit du retro-engineering de Mr Enri et des recherches de TAKEDA Toshiya. Deux personnes que je ne peux que remercier et à qui je rends hommage ici. Sachant que la Super Cassette Vision n'était pas du tout documentée au départ, ils ont fait un travail titanesque sur plusieurs années pour décortiquer le matériel, comprendre son fonctionnement et finalement créer eSCV... il y avait encore beaucoup de zone d'ombre mais franchement chapeau parce que le fonctionnement de cette console d'apparence toute bête est tout sauf simple à comprendre.

L'émulateur eSCV avait donc le mérite d'exister mais il a été extrêmement difficile d'en trouver une version "récente" avec pas trop de corrections à faire pour que ça soit compilable rapidement et que ça fonctionne un minimum. Cet émulateur n'est bien sûr prévu que pour Windows au départ et a énormément de bugs et de lacunes mais c'est la meilleure base de départ que j'ai pu trouver.

Partant de là j'ai corrigé pas mal de bugs et surtout j'ai réécrit une bonne partie du code pour transformer l'émulateur autonome en un core Libretro qui puisse tourner sur un frontend Windows, Mac ou Linux (dont Recalbox qui est un Linux). Ca vous permet de bénéficier du rembobinage, de l'avance rapide, des sauvegardes, etc. bref de toutes les fonctions qu'on aime bien dans Recalbox.
Comme je suis quelque peu perfectionniste sur les bords j'ai fait énormément de recherches complémentaires sur les vraies consoles japonaises (EPOCH) et française (YENO) pour que mon émulateur colle encore mieux au comportement réel des machines.

Sans vouloir me vanter, grâce à tout le travail accompli, je pense vraiment qu'EmuSCV est le meilleur émulateur qui existe aujourd'hui pour la Super Cassette Vision... et il est dans Recalbox

Ceci dit j'ai encore quelques recherches à faire pour élucider les derniers mystères qui me résistent et quelques améliorations qui s'imposeront pour que mon émulateur soit enfin parfait (notez qu'EmuSCV n'est toujours pas en version finale, ça n'est pas pour rien).

Au passage je remercie Frédéric PETRUCCI, mon fournisseur officiel de cartouches SCV, @barbudreadmon qui m'a mis le pied à l'étrier du dev Libretro, @Bkg2k qui m'a beaucoup aidé pour l'intégration et l'optimisation dans Recalbox, ainsi que tous les gens comme les bêta-testeurs de Recalbox qui ont participé au projet de prêt ou de loin ( @Karlito si tu m'écoutes...).

Fin de ma grosse parenthèse. mode roman OFF.

...

[MaaaX]

..;

Pour commencer la partie "manuel utilisateur", il faut savoir qu'EmuSCV supporte toutes les consoles Super Cassette Vision (pour les puristes) plus un mode adapté pour améliorer l'affichage (pour les utilisateurs lambda).
Les options d'EmuSCV sont accessibles par l'item "Options" du menu rapide de Retroarch (hotkey+bouton du bas dans Recalbox pour accéder au menu rapide).
Toutes les options sont sur AUTO par défaut.

Option CONSOLE: elle permet de choisir le mode de fonctionnement général de l'émulateur et l'apparence du menu.
La valeur choisie a une incidence sur les autres options en AUTO.
- AUTO: équivalent à EPOCH pour l'affichage du menu.
- EPOCH: fonctionnement comme sur une EPOCH Super Cassette Vision japonaise (la normale). Menu anglais noir.
- YENO: fonctionnement comme sur une YENO Super Cassette Vision française. Menu français noir.
- EPOCHLADY: fonctionnement comme sur une EPOCH Super Cassette Vision LADY japonaise (la rose). Menu anglais rose.

Option DISPLAY: elle permet de choisir le cadrage de l'image.
Voir aussi l'option DISPLAYFULLMEMORY
- AUTO: équivalent à EMUSCV
- EMUSCV: cadrage adapté à l'émulation permettant de ne pas avoir les bugs d'affichage spécifiques aux vraies consoles.
- EPOCH: cadrage comme sur une console japonaise, avec les bugs correspondants. Notez qu'on voit les grands sprites qui disparaissent à gauche de l'écran pendant les scrolling (Lupin III) et des sprites normalement affichés tout à droite qui apparaissent parfois à gauche (Nebula)... comme sur les vraies.
- YENO: cadrage comme sur la console française avec une bande d'image supplémentaire affichée en haut (Doraemon) et une bande noire en bas... comme sur la vraie.

Option PIXELASPECT: elle permet de choisir le ratio largeur/hauteur des pixels.
- AUTO: équivalent à RECTANGULAR
- RECTANGULAR: pixels rectangulaires comme sur les vraies consoles.
- SQUARE: pixels carrés. Utile seulement pour faire des captures d'écran propres à étirer ensuite.

Option RESOLUTION: elle permet de choisir la résolution d'affichage et la qualité du menu.
Peut être utile pour avoir une image plus propre quand on est pas en Pixel Perfect et un plus joli menu. Plus la résolution est élevée, plus ça rame.
- AUTO: équivalent à LOW uniquement sur Recalbox. Pour les versions autres que Recalbox: LOW de PI 0 à PI 2, MEDIUM sur PI 3 et HIGH sur tout le reste (PI 4, WINDOWS, LINUX, MAC, etc.).
- LOW: basse résolution "d'origine" des vraies consoles (un peu adapté quand même pour avoir des pixels rectangulaires propres). Menu tout moche (pas pu faire mieux, désolé). Sur PI 0 ça rame un peu quand même.
- MEDIUM: résolution moyenne. Menu un peu plus joli. C'est le max qui passe sur PI3.
- HIGH: "haute" résolution. Joli menu. Ca rame plus mais ça passe bien à partir de PI4.

Option PALETTE: elle permet de choisir la palette des couleurs affichées.
- AUTO: équivalent à STANDARD.
- STANDARD: couleur normales des consoles.
- OLDNTSC: couleurs moches comme sur une vielle télévision NTSC japonaise (c'est pas pour rien que ce standard a eu le sobriquet de Never The Same Color). C'est comme ça que les Japonais ont connu la console et c'est pour ça que les couleurs étaient si moches dans eSCV.

option FPS: Nombre d'images par secondes. Ca correspond à la fréquence de la console.
- AUTO: 50 ou 60 selon la console choisie. 60 pour CONSOLE = AUTO
- EPOCH50: 60 FPS (60Hz comme sur les consoles japonaises)
- YENO60: 50 FPS (50Hz comme sur la console française)

Option DISPLAYFULLMEMORY: option rigolote qui permet d'afficher la totalité de la mémoire vidéo ou l'image normale.
Ca permet de voir ce que les développeur ont fait et que les joueurs n'ont jamais vu.
- AUTO: équivallent à NO
- YES: affiche toute la mémoire vidéo. Un cadre coloré indique la partie normalement affichée selon l'option DISPLAY choisie (vert pour EMUSCV, rouge pour les consoles EPOCH japonaises et bleu pour la console YENO française).
- NO: affiche l'image normale selon l'option DISPLAY choisie.

Option DISPLAYINPUTS: permet d'afficher ou de masquer l'état des contrôleurs (interrupteurs, boutons, clavier, manettes).
- AUTO: équivallent à NO
- YES: état des contrôleurs affiché.
- NO: état des contrôleurs masqué.

Option LANGAGE: option non utilisée pour le moment. Elle servira plus tard pour afficher la cartouche et le manuel correspondant à la langue choisie.
- AUTO: JP ou FR selon la console choisie.
- JP: Japonais
- FR: Français
- EN: Anglais, juste au cas où on traduirait l'étiquette des cartouches ou les manuels qui n'existent qu'en Japonais et éventuellement en Français pour les jeux qui sont arrivés chez nous.

CHECKBIOS: Permet d'activer et de désactiver le contrôle du BIOS par l'émulateur au démarrage.
- YES: Vérification du BIOS (checksum MD5)
- NO: Pas de contrôle

...

[MaaaX]

...

Pour finir voilà par où EmuSCV pêche encore:

Améliorer le mixage des différents canaux sonores: il n'est pas parfait, je sais. Par exemple le son de moteur qu'on peut entendre au démarrage de Wheely Racer qui est un mélange des trois canaux "noise" et il n'est pas encore tout à fait identique au son original.

Améliorer la restitution du canal PCM 1bit: ce canal va me rendre fou. C'est le canal qui restitue les sons échantillonnés: les voix et certains bruitages comme les voix dans Kung-Fu Road, Pole Position 2 et Star Speeder ou les saut dans Y2 Monster Land (ce son est horrible même en vrai).
Le PCM 1bit c'est hyper facile à restituer en analogique en envoyant intégralement le signal à un haut-parleur mais en programmation c'est un enfer à restituer correctement à cause du taux d'échantillonnage différent. Ca n'est pas encore parfait mais ne marche déjà pas trop mal sur EmuSCV. A titre de comparaison MAME ne gère pas du tout ce canal et ça fait parfois planter eSCV.

Comprendre le mécanisme limitant le nombre de sprites à afficher: je subodore l'existence d'un mécanisme qui limite le nombre sprites à afficher mais que je n'ai pas encore réussi à débusquer. Pour tous les jeux j'affiche donc tous les sprites sauf pour Kung-Fu Road ou je dois me limiter à peu près à la moitié si je ne veux pas que ça m'affiche plein de sprites moches partout. TAKEDA Toshiya avait contourné le problème dans eSCV en n'affichant pas les sprites de la partie haute de l'écran... du coup dans le deuxième niveau si vous faites un grand saut pour monter sur le mur et que vous faites encore un grand saut votre personnage disparaît un instant. Idem dans MAME.

Comprendre le mécanisme d'affichage d'un tout petit nombre restant de sprites: Cette console est vraiment tordue (je suis poli) et en gros la façon dont sont traités les sprites dépend de deux modes d'affichage et du numéro du sprite à afficher (plus un tas d'autres choses que je vous épargnerai ici).
Il reste encore deux cas où je n'ai pas encore réussi à comprendre comment afficher le sprite correctement:
- Dans Boulder Dash: dès le premier niveau on peut voir des diamants bleus et jaune dont les couleurs alternent régulièrement sauf que parfois certains diamants clignotent un instant, contrairement aux console ou ça alterne simplement. C'est juste que les infos que j'ai pour le sprite à un instant donné indiquent que je devrai afficher la couleur n°2 alors que la console continue d'afficher la couleur n°1 et inversement pour l'autre couleur... le pire c'est que dans d'autres jeux, pour les mêmes modes, le même sprite et tout et tout, j'ai bien le bon affichage... ça doit dépendre d'une autre info que je n'ai pas encore trouvée.
- Dans Lupin III: dans le dernier niveau la console affiche des briques (lignes blanches)... sauf que je n'ai aucune info à ce moment précis qui me dit que je dois afficher le sprite des briques...

A ma connaissance c'est à peu près tout.
Je continue mes expérimentations sur les vraies consoles et je vais bien finir par tout trouver.
Si vous avez la possibilité de comparer avec le matériel d'origine et que vous trouver des différences n'hésitez pas à me le faire savoir.

Des bisous... jouez bien...

@++
EPOCH84 (aka MaaaX ^^)

[Murdock]

Merci beaucoup pour votre retour, c'est hyper intéressant à lire le processus de compréhension de la console nécessaire au bon développement de l'émulateur !
Je trouve cela très intéressant à suivre, vous donnez beaucoup de détails en plus c'est top.

Merci à vous en tout cas pour votre investissement !
PS : je suis déjà fan de l'option "DISPLAYFULLMEMORY", c'est intéressant de voir que l'image n'est pas la même selon le pays de la console !

Si je puis me permettre, pourriez-vous mettre le git de votre projet dans votre signature ? J'ai votre projet en favori pour suivre, mais pour les nouveaux qui découvrent la console ou le projet, c'est tjs sympa d'y avoir accès facilement

[MaaaX]

Bonjour @Murdock et merci.
C'est toujours motivant d'avoir des retours positifs et sympas.

Pour le dépôt je ne peux malheureusement pas le mettre en signature parceque c'est limité à 255 caractères mais c'est là que ça se passe:
https://gitlab.com/MaaaX-EmuSCV/libretro-emuscv/

La page de Mr Enri est là (détail technique en Japonais avec des choses fausses qu'ils ne connaissait pas à l'époque et que j'ai corrigé dans EmuSCV):
http://www43.tok2.com/home/cmpslv/Scv/EnrScv.htm

La page eSCV de TAKEDA Toshiya est là (historique de projet en Japonais):
http://takeda-toshiya.my.coocan.jp/scv/index.html

@++
EPOCH84 (aka MaaaX^^)

[Murdock]

@maaax Ah top, merci beaucoup pour les liens !
C'est toujours intéressant de voir les dépôts (je suis développeur aussi [souvent autour de V4L2] mais je n'ai aucune connaissance en matière d'émulation, seulement les principes de bases), mais c'est toujours intéréssant de suivre l'évolution d'un projet justement pour comprendre le fonctionnement.

Je vais jeter un oeil aux travaux d'origines, merci pour les ressources, c'est top !
Et bon courage pour la suite, n'hésitez pas à partager vos avancées comme vous l'avez fait, un régal !

[MaaaX]

Hello o/.

En relisant à nouveau le journal de développement de TAKEDA je suis tombé sur une note de janvier 2006 où il dit avoir résolu quelques problèmes d'affichage dont celui des des briques dans le dernier niveau de Lupin III, ce qui m'a redonné une lueur d'espoir et j'ai refait quelques recherches mais qui n'ont malheureusement rien donné.
Il n'y a rien qui aille dans ce sens dans le code le plus récent de TAKEDA et ça ne s'affiche pas non plus les briques dans eSCV. Est-ce qu'il y aurait eu une régression entre temps? C'est possible.
J'ai trouvé une vieille archive du projet de 2006, je regarderai entre midi et deux pour voir s'il y a quelque chose d'intéressant dedans.
Par acquis de conscience j'ai vérifié à nouveau les données présentes en mémoire pendant le dernier niveau mais je confirme qu'il n'y a aucune trace du sprite n°42 du contour des briques (le même que dans le niveau 1).
A un moment je pensais qu'il y ait peut-être un lien avec l'affichage du sprite n°43 qui est un rectangle plein qui sert à dessiner le fond des briques oranges du haut mais maintenant je ne pense pas car le sprite n°43 n'est pas utilisé pour les briques du bas.
La partie orange du haut est dessinée en deux lignes de plusieurs sprites n°43, une première ligne en mode 32x32 monochrome (sprite doublé en largeur et en hauteur) et une seconde ligne en mode 32x16 monochrome (doublé en largeur).
La partie orange du bas est dessinée à l'aide du mode graphique pour dessiner un grand rectangle orange.
Sur la vraie console ça donne ça:

En faisant l'inventaire des données en mémoire je me suis rendu compte qu'avec ma ROM il y a un gros "trou" rempli de 0 en plein milieu des données des sprites entre ce qui concerne le fond orange/violet et ce qui s'affiche dans le tunnel (personnage, ennemis, piège, etc.). Est-ce que ça correspond à la partie manquante?
J'ai à nouveau extrait les données de ma cartouche originale pour comparer mais c'est toujours pareil. C'est ok sur la console mais pas sur EmuSCV. Vu le mappage bizzaroïde des cartouches je vais regarder aussi de ce côté là des fois qu'il y ait plusieurs fois des données PRESQUE similaires à des adresses différentes ou qu'une partie des données serait masquée par une autre plage de données.
Pas d'autre idée pour le moment, aussi je laisse la question en suspens...

J'avance sur d'autres émulateurs mais je reviendrai bientôt pour la phase 2 de mon projet EmuSCV: injecter mon propre code dans une cartouche pour consolider les acquis et lever les derniers mystères de la console.

@++
EPOCH84 (aka MaaaX^^)

[MaaaX]

Hello.

En relisant à nouveau le journal de développement de TAKEDA je suis tombé sur une info de janvier 2006 où il dit avoir résolu quelques problèmes d'affichage dont celui des des briques dans le dernier niveau de Lupin III, ce qui m'a redonné une lueur d'espoir et j'ai refait quelques recherches mais qui n'ont malheureusement rien donné.
Il n'y a rien qui aille dans ce sens dans le code le plus récent de TAKEDA et ça ne s'affiche pas non plus les briques dans eSCV. Est-ce qu'il y aurait eu une régression entre temps? C'est possible.
J'ai trouvé une vieille archive du projet de 2006, je regarderai entre midi et deux pour voir s'il y a quelque chose d'intéressant dedans.
Par acquis de conscience j'ai vérifié à nouveau les données présentes mémoire pendant le dernier niveau mais je confirme qu'il n'y a aucune trace du sprite n°42 du contour des briques (le même que dans le niveau 1).

Il y a peut-être un lien avec l'affichage du sprite n°43 qui est un carré plein qui sert à dessiner le fond des briques oranges du haut.
Cette partie est dessinée en deux lignes de plusieurs sprites n°43, une première ligne en mode 32x32 monochrome (sprite doublé en largeur et en hauteur) et une seconde ligne en mode 32x16 monochrome (doublé en largeur).
Quel est le mécanisme qui pourrait bien relier l'affichage des deux sprites... aucune idée pour le moment, aussi je laisse la question en suspens...

J'avance sur d'autres émulateurs mais je reviendrai bientôt pour la phase 2 de mon projet EmuSCV: injecter mon propre code dans une cartouche pour consolider les acquis et lever les derniers mystères de la console.

@++
EPOCH84 (aka MaaaX^^)

[MaaaX]

Hello,

Ca y est j'ai enfin "résolu" le problème d'affichage des briques du dernier niveau de Lupin III.

Je n'ai rien trouvé dans le code d'eSCV de 2006. Au niveau des sprites il est fonctionnellement identique au dernier code en date.
J'ai redémonté à nouveau ma cartouche de Lupin III mais rien de particulier à signaler au niveau du mappage: une bête EPROM 16Ko en deux banques de 8Ko.
Du coup j'ai réextré encore une fois les données de la ROM et j'ai retesté sur eSCV... toujours pas de briques... incompréhensible.
Et là d'un coup ça a fait TILT: j'extrayais et je testais sur mon PC Windows car le logiciel de mon lecteur/programmateur d'EPROM ne tourne que sur Windows mais j'avais plein de copies différentes des ROMs un peu partout sur cet ordi avec des noms de répertoires similaires. J'ai donc fait un grand ménage pour être sûr de ne pas me mélanger les pinceaux dans les répertoires. J'ai réextré encore la ROM et j'ai retesté sur eSCV... oh miracle! des briques... Enfin! J'avais donc bien fait une confusion entre les multiples répertoires, entre les extractions, les comparaisons et les tests.
J'ai retesté la ROM fraîchement extraite sur EmuSCV avec juste une petite modif du contrôle MD5 de mon émulo pour permettre le chargement de la nouvelle ROM et là aussi les briques étaient bien présentes... Alleluia!
Un mystère de moins à résoudre. C'est donc la ROM lupin3.bin en circulation qui ne contenait pas les fameuses briques. Ma ROM avec les briques sera nommée lupin3a.bin.
Je n'ai malheureusement pas encore réussi à injecter correctement la ROM lupin3.bin dans une vraie cartouche pour m'assurer que les briques sont bien absentes aussi sur la console mais je n'en suis pas très loin.

Un grand merci à @Murdock pour m'avoir fait replonger dans les archives malgré lui.

@++
MaaaX^^

[flomartin]

Merci de nous faire vivre ton avancée, c'est vraiment super intéressant à lire.

Les dev de Recalbox devraient en faire de même, c'est passionnant.

Et bravo pour ton émulateur, du super beau boulot !

[Murdock]

Ce travail de fourmi pour trouver le soucis... félicitations ! Surtout que dans ce genre de situations, on remet plutôt en cause le code de l'émulateur plutôt que le dump de la cartouche !

Top ces avancées, merci à vous.

PS : @flomartin , c'est vrai que je serais curieux aussi d'avoir un peu plus les prémices de Recalbox, mais leur dernier post sur le blog concernant le RGB Dual était vraiment intéressant, peut-être d'autres postes de ce type verront le jour !

[MaaaX]

Pour ceux que ça intéresse voilà comment je procède pour l'extraction des ROMs:

• Dépose de la ROM
  
  La ROM qui est dans le cas présent EPROM NEC uPD23128AC simple écriture de 16Ko (128 kilobits, 16384 mots de 8 bits).
  
• Extraction des données
  
  
• Comparaison des données de la ROM fraîchement extraite avec celles de la ROM en circulation. Ici on voit que les données sont différentes pour le même jeu.
  
• Test de la nouvelle ROM sur eSCV
  
• Test de la nouvelle ROM sur EmuSCV
  

[Secamfr]

@maaax Ultra passionnant toutes ces infos, surtout pour moi qui découvre cette machine

On attends plus que la rom corrigé Merci !

[leZone]

@akkeoss bonsoir, mon post intitulait "pour info", la solution alternative était déjà connue, je remontait juste l'info