YENO super cassette vision

[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)

[Bkg2k]

@maaax Un petit compilateur C maintenant?

[MaaaX]

ZELDA sur Super Cassette Vision:
https://youtu.be/lZKGjGliqrk?si=vLDCsItAEYD2F8Ix