YENO super cassette vision

[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

[barbudreadmon]

@MaaaX pour info, apparemment la team libretro voudrait intégrer ton travail en core officiel, mais le splashscreen avec le logo recalbox inclus dans l'émulateur leur pose un peu soucis, était-ce vraiment nécessaire ? Est-il envisageable de virer le splashscreen ou tout au moins le logo ?

[MaaaX]

Hello @barbudreadmon

Le logo/splash Recalbox au lancement de l'émulateur c'est un clin d'oeil à la team Recalbox qui m'a beaucoup aidé pendant le développement initial et quand il est sorti c'était d'ailleurs une exclusivité Recalbox.

Ceci dit le code est open source et ça n'est pas obligatoire du tout. D'ailleurs Batocera l'a intégré depuis à son système en remplaçant le logo Recalbox par un deuxième logo EmuSCV (dommage qu'ils ne m'aient pas contacté car on aurait pu faire ça bien plus proprement).

Si besoin je peux faire une petite modif pour qu'à la compilation le logo ne s'affiche que si une constante est definie genre #ifdef RECALBOX_LOGO etc.

[barbudreadmon]

@maaax said in YENO super cassette vision:

Si besoin je peux faire une petite modif pour qu'à la compilation le logo ne s'affiche que si une constante est definie genre #ifdef RECALBOX_LOGO etc.

Bonne idée. Impossible de complètement zapper le splashscreen ?

[MaaaX]

@barbudreadmon Tout est possible, tout est réalisable

[yannick49]

Salut, ça fait longtemps que je ne suis pas passer par ici!
en tout cas félicitation du travail accompli!!!

sinon question.........

J'essaie de le faire tourner sur Lakka installé sur ma SWITCH et je n'y arrive pas.
Une idée?

[MaaaX]

Salut @yannick49 !

Dabord merci

Moi aussi ça fait un moment que je ne suis pas passé par ici mais je bosse activement sur un projet d'émulateur un peu fou fou pour Recalbox qui finira bien par sortir un jour ou l'autre mais chut je ne communique pas dessus pour le moment (comme dirait BK: c'est comme le Fightclub, on n'en parle pas ). Je peux juste dire que c'est beaucoup plus chronophage que ce que je pensais au départ parce que je veux faire les choses bien et qu'en parallèle je bosse toujours sur le retro-engineering de la EPOCH Cassette Vision et sur mon projet autour de la EPOCH/YENO Super Cassette Vision (EmuSCV inclus) ^^

Pour répondre à ta question apparemment Lakka est bien un Linux mais c'est le processeur ARM Cortex de la Switch qui pose souci. Je pense que tu dois utiliser une version compilée pour un autre processeur alors qu'il te faudrait une version compilée pour Lakka et ce processeur en particulier (sans parler des éventuelles corrections à faire sur le code si besoin).
Perso je n'ai de quoi compiler que des versions Linux-PC, Windows-PC, OSX-Mac, PI OS-Raspberry PI 3 et PI 4 via GCC 10.
La team Recalbox compile les versions optimisées propres à son OS (=Linux) et aux plateformes supportées: Raspberry Pi 0, 1, 2 , 3, 4, PC, Odroïds, etc., tout ça via Buildroot (GCC 10).
Pour que ça puisse fonctionner chez toi il faudrait pouvoir compiler une version directement sur Lakka-Switch ou alors utiliser un cross-compiler pour pouvoir compiler pour ton architecture depuis une autre plateforme mais je n'ai malheureusement pas ça sous la main.

Ca ne resoud pas ton problème mais déjà tu sais pourquoi ça ne marche pas.

@++
EPOCH84 (aka MaaaX^^)

[MaaaX]

Salut les gens!

Ca fait un petit bout de temps que je ne suis pas apparu sur les écrans radars mais mes différents projets avancent bien (et accessoirement me prennent beaucoup de mon temps libre mais parce que je le veux bien ^^).

Concernant le projet autour de la Super Cassette Vision, j'ai presque fini le développement de l'assembleur RASM7801 pour le NEC uPD7801.
En Français ça signifie que j'ai presque terminé le programme qui permettra de compiler de nouveaux jeux pour la super Cassette Vision (programmes en langage Assembleur).
Un grand grand grand merci à Roudoudou pour le code de RASM (Roudoudou Assembler for Z80) que j'ai utilisé comme base pour mon compilateur RASM7801. Ca m'a fait gagner un temps considérable de ne pas avoir à tout réécrire from scratch. Au passage je garde le R de RASM comme clin d'oeil à Roudoudou.

Je disais donc que l'assembleur est presque terminé et il supporte maintenant le jeu d'instruction complet du NEC uPD7801 (pour ceux qui n'auraient pas suivi c'est le processeur de la super Cassette Vision) et j'ai pu compiler un premier programme et le faire tourner du premier coup.
Voilà les captures d'écran:

Ca n'est certes pas très impressionnant mais ça fonctionne et ça n'est premier pas pour de futurs homebrews.
comme a dit je ne sais plus qui: "un premier pas pour l'homme, un premier pas pour l'Homme".

A suivre...

See you soon...
MaaaX^^ (aka EPOCH84)