YENO super cassette vision
-
Bonjour.
Merci pour les encouragements
Le projet n'a pas beaucoup avancé pendant le confinement mais je m'y remet tranquillement.
J'avais réécrit le projet en objet au début du confinement et j'avais déjà commencé à intégrer eSCV mais j'ai un souci avec les logs qui génèrent des erreurs de segmentation. C'est certainement dû au fait qu'on soit maintenant dans une classe plutôt que dans une simple fonction (problème de fonction pas statique?).
J'ai aussi changé d'IDE (environnement de développement intégré) pour passer sur Studio Code mais je ne sais pas comment déboguer mon projet (point d'arrêt, pas à pas, évaluation de variable, etc.).Voilà donc les travaux en cours ou très bientôt en cours:
- Trouver comment déboguer avec Studio Code voire rechanger d'IDE (peut-être qu'il me faudra écrire un frontend Libretro pour pouvoir déboguer, je ne sais pas encore). SI QUELQU'UN UTILISE DÉJÀ UN ENVIRONNEMENT PRATIQUE ET MULTI-PLATEFORME (Windows, Mac, Linux) JE SUIS PRENEUR.
- Résoudre mon problème de plantage, voire réécrire ma classe si besoin mais j'aimerai autant éviter.
A suivre...
@++
MaaaX ^^ -
Je pense que @barbudreadmon peut peut-être t'orienter pour ce qui est de l'IDE et du debuggage.
Bravo pour le projet en tout cas, et j'espère que d'autres suivront ta voie pour d'autres émulateurs qui manquent toujours à l'appel du coté Retroarch (et c'est pas ce qui manque!)
-
@Bkg2k j'utilise un éditeur très banal (geany sous linux) et les outils de debug classiques (gdb et les sanitizers inclus dans gcc/clang)
-
@Bkg2k et @barbudreadmon : Merci les gars, vous m'avez mis sur la bonne piste.
Je n'avais jamais utilisé gdb en ligne de commande (toujours utilisé dans un IDE graphique) mais ça y est je peux enfin déboguer correctement.
Un grand merci.Et cerise sur le gâteau j'ai trouvé comment configurer Visual Studio Code pour lancer la compilation (bluild, clean, rebuild...) et déboguer avec gdb directement dans l'éditeur.
Je vais pouvoir avancer plus vite et trouver d'où vient mon erreur de segmentation intermittentes sur les logs.
A suivre...
@++
MaaaX ^^ -
Bonjour,
C'est aussi ma première console, je suis content de voir qu'un dev est en cours.
Je suis pressé de pouvoir la retrouverN'ayant pas de compétence en dev, je suis dispo si besoin de beta testeur.
-
Bravo pour le boulot,et aussi pour avoir communiquer des détails sur le développement ici. C'est toujours passionnant de voir un truc naître comme ça.
-
Salut salut.
Le projet a pris un gros coup de frein depuis le confinement car j'ai des travaux perso à finir le plus rapidement possible (ma voiture principale pour tout dire) mais pas d'inquiétude je devrai pouvoir me remettre normalement sur le projet d'ici fin septembre.
De toute façon dès que ça avance un peu significativement je met les infos ici, comme d'hab.Sinon j'ai fait l'acquisition des deux consoles japonaise et française ainsi que de certains jeux qui présentent pour moi un intérêt nostalgique ou technique afin de pouvoir comparer l'émulateur à la réalité.
@++
-
Bonjour tout le monde.
Bonne nouvelle: je me remets activement sur le projet.
Prochaines news vendredi comme à l'accoutumée.En attendant si quelqu'un a la notice de Basic Nyumon et peux me la scanner ça serait cool.
@++
MaaaX ^^ -
Bonjour,
Good news, le projet emuSCV avance bien .
J'ai presque fini l'intégration du moteur RetroPC sur Linux C'est grossomodo la structure dans laquelle "tourne" l'émulateur eSCV... ainsi que plein d'autres émulateurs d'ailleurs...
Il me reste une bricole de code à régler pour récupérer le nom des classes mais c'est secondaire car c'est utilisé uniquement pour le débogueur intégré de RetroPC.Je ne suis pas encore passé partout mais l'intégration de eSCV se passe bien aussi. Normalement tout est déjà intégré, je n'ai pas d'erreur de compilation mais il reste encore un gros boulot pour tout tester.
Il reste à faire:
-
La semaine prochaine je devrai pouvoir enfin charger le BIOS et une ROM pour voir si ça tourne comme attendu en débogage pas à pas (pour le moment il n'y a rien de visible pour le commun des mortels hormis pour moi dans le code avec mon débogueur).
-
Il faut que je fasse tout le code de la partie "OSD" de RetroPC (c'est le terme utilisé dans RetroPC).
C'est ce qui est chargé de faire l'interface entre eSCV/RetroPC et l'extérieur (Libretro, Recalbox et vous ) pour tout ce qui est entrées (clavier, joysticks) et sorties (vidéo et son).
Pour le moment c'est une juste coquille vide. J'ai bien toutes les fonctions qui sont créées mais elles ne font encore rien.
Ça ne devraient pas être une étape trop compliquée vu que tout le boulot sera au final délégué à l'API Libretro (donc à Recalbox). J'ai déjà fait plein de tests et je sais déjà quoi faire pour que ça marche.
Arrivé là les premiers jeux devraient être enfin être jouables . -
Il faudra faire aussi en sorte que ça tourne sur Retroarch PC et Mac en plus de Linux.
Même si pour Recalbox c'est Linux qui nous intéresse, je tiens à ce que ça reste crossplatform et si je le fais au fûr et à mesure j'ai moins de risque d'avoir des régressions. -
Il faudra ensuite compiler une version pour Recalbox (du boulot Bkg2k et la team Recalbox) mais normalement si ca tourne sur Linux ca devrait bien se passer.
-
Enfin la cerise sur le Mac Do, il faudra que je fasse une interface jolibô pour pouvoir régler les options directement dans l'émulateur... mais on peut démarrer sans ça avec des options "standards".
Ouf!
Voilà! Des news la semaine prochaine. Des bisous.
Bon week-end
@++
MaaaX ^^ -
-
J'en bave déjà.......
Merci encore pour tout ton travail!! -
Bonjour les ami(e)s,
Alors j'ai tout petit peu en avance:
- le BIOS "upd7801g.s01" se charge bien dans emuSCV et il tourne sans cartouche, donc à priori sur le test vidéo avec les espèces de ballons que certains d'entre-vous connaissent.
- Je n'ai pour le moment chargé qu'une seule cartouche, celle de Astro Wars, et ça tourne aussi sans problème.
Comme à l'origine on peut charger n'importe quel fichier en tant que BIOS dans eSCV, avec les conséquences imprévisibles que ça peut engendrer, je vais rajouter une sécurité en faisant un contrôle sur le hash MD5 du contenu du fichier.
A ma connaissance il n'y a que 2 BIOS en circulation pour la Super Cassette Vision "bios.rom" et "upd7801.s01" mais qui sont en réalité le même fichier avec des noms différents ça ne devrait pas poser de problème.Il faut que je me batte un petit peu avec les chemins de recherche de eSCV pour les adapter à Libretro/Recalbox mais ça va le faire.
Prochaine étape: développer la partie vidéo de l'OSD RetroPC pour que ca affiche ENFIN quelque chose
Peut-être des news demain, sinon le vendredi suivant.
@++
MaaaX ^^PS: je cherche toujours le manuel de Basic Nyumon...
-
Superbe initiative de votre part ! Merci beaucoup pour votre détermination et votre partage, je suis les news de ce projet avec beaucoup d'attention !
-
Petit point rapide:
- le contrôle du BIOS est ajouté
-
Hello,
L'affichage a pris bien moins de temps que ce que je pensais
Avant de passer à la suite j'ai encore du boulot sur la partie qui gère l'émulation de la puce EPOCH-TV1 afin de pouvoir émuler l'affichage de la console YENO en plus de celui des consoles EPOCH (pour mémoire l'affichage est différent sur les consoles JP et FR).
Et puis c'est un peu brut de fonderie pour le moment et je vais bien sûr améliorer tout ça.Je voudrais revenir aussi sur la gestion de la config.
Pour le moment j'utilise celle de eSCV qui est basée sur un fichier .INI mais je vais modifier ça pour que ça soit complètement intégré à Libretro/Recalbox.
Et enfin il faut que ce que j'ai fait tourne aussi sur Mac et Windows en plus de Linux (oui sur la photo c'est un Mac mais avec un Linuxmint dessus).Des news ASAP.
Des bisous.
@++
MaaaX ^^ -
Bravo encore une fois ! J'adore suivre les projets comme ça (j'aimerai voir un peu plus les coulisses de recalbox d'ailleurs, mais bon), c'est passionnant !!
-
Bordel je suis comme un fou!!!
ça va me rappeler trop de souvenir ses conneries!!!! -
@MaaaX Wahou, super et merci de nous faire découvrir ou redécouvrir la Yeno Super Cassette Vision.
C'est très intéressant d'ailleurs de lire l'avancer de tes travaux
-
Bonsoir amis retrogamers,
Voici les dernières news du front sur le projet EmuSCV:
- Je suis d'ores-et-déjà en mesure de gérer la surface d'affichage de toutes les consoles (les 2 JP et la FR), et même un peu plus car la zone d'image gérée est en fait beaucoup plus grande que ce qui est affiché au final à l'écran.
En gros ça fonctionne comme ça: plusieurs fonctions dessinent les textes, les blocs et les graphiques dans une zone mémoire de 320x320 pixels appelée "text buffer" utilisant 16 couleurs. Une autre fonction dessine les sprites dans une autre zone mémoire appelée "sprites buffer" (320x320, 16 couleurs). Ensuite on mixe les deux buffers en copiant d'abord le "text buffer" en mémoire vidéo avec les 16 couleurs affichées puis le "sprites buffer" mais en 15 couleurs, la couleur 0 servant de couleur transparente.
La couleur 0 est le bleu qu'on peut apercevoir subrepticement quand on fait un reset sur console (puisqu'on remplit la mémoire vidéo avec la couleur 0).
Notez qu'il y a léger décalage quand on fait la composition des deux buffers (cadre bleu sur l'image suivante: "text buffer", rectangle rouge: "sprites buffer").
Si on voulait tout afficher il faudrait avoir une résolution de 324x322, ce qui est assez loin de la résolution finale affichée à l'écran. Je ne peux pas vous mettre de vidéo ici mais les sprites vont parfois assez loin hors de la zone visible à l'écran.
Pour ceux qui se demande combien on affiche de sprites en même temps sur le test vidéo, en vrai ça donne ça (certains ballons sont invisibles car de la même couleur que le fond):
- Il reste un gros souci à régler pour Kung-Fu Road qui présente des bugs graphiques. Il faut que je creuse pour savoir si c'est un problème de eSCV, l'émulateur sur lequel je me base, où si c'est la ROM qui est pourrie. TAKEDA Toshiya, le créateur de eSCV, avait botté en touche en bidouillant le cadrage et en ne dessinant pas la partie haute du "sprites buffer" pour cette cartouche afin que les faux sprites s'affichent hors de l'écran. D'après mes tests je crains qu'il y ait un risque pour que ça écrive des données la ou ça ne devrait pas, il faut absolument que je résolve ce bug et j'ai commandé le matériel pour pouvoir réextraire le contenu des puces de MA cartouche d'origine pour vérifier ( ). Au passage la ROM que j'ai pour Astro Wars n'a pas les mêmes couleur que sur la vraie version (mais là j'ai la cartouche en double).
- Autre petite chose bien moins grave: je n'ai pas les bugs d'affichage de la console Yeno avec les jeux Boulder Dash et Doraemon.
Il devrait y avoir des restants de texte en haut de l'écran que je n'ai pas du tout sur l'emulo. Ca n'est pas grave en soit mais je chercherai pourquoi afin d'émuler parfaitement toutes les consoles.
-
J'ai eu quelques soucis pour charger certaines ROM mais j'ai trouvé pourquoi: eSCV n'est pas capable de charger certaines ROM telles qu'on les trouvent sur Internet car il est nécessaire de placer les blocs de données à certain endroits précis de la mémoire. Si les blocs doivent être chargés dans l'ordre à partir du début de la mémoire tout va bien sinon ça ne tourne pas.
Sur les cartouches d'origine, l'ordre des banques et leur adresse mémoire étaient définies en dur par le cablage sur la PCB (la carte électronique dans la cartouche) or c'est une information qu'on a pas dans les fichiers ROM.
TAKEDA Toshiya avait rencontré le même problème et crée un format de fichier spécifique pour remettre à disposition cette info (format pas ou peu documenté et il faut faire tout le boulot de création du fichier à la main). Il fournit dáilleurs avec le code source quelques exemplaires de ROM modifiées qui elles se chargent donc bien.
Personnellement je trouve que son format est quelque peu restrictif si on veut pouvoir faire du homebrew plus tard.
Je suis donc en train de peaufiner mon propre format pour EmuSCV (.cart pour les cartouches et .sram pour les sauvegardes), format que je documenterai. Je fournirai un outil cross-plateforme pour ceux qui souhaite recréer eux-même les fichiers à partir des ROM en circulation. (Nous sommes bien d'accord que je n'ai légalement pas le droit de fournir ni le BIOS, ni aucune ROM). -
Et sinon je n'ai pas du tout eu le temps de mettre le nez dans le recodage de la config pour l'intégrer totalement au fonctionnement de Libretro/Recalbox.
Encore merci à Fred pour les quelques photos du manuel de BASIC Nyumon qu'il doit m'envoyer (Fred lis ces lignes, ne m'oublie pas ).
Prenez soin de vous et à la semaine prochaine pour de nouvelles aventures.
@++
MaaaX ^^ - Je suis d'ores-et-déjà en mesure de gérer la surface d'affichage de toutes les consoles (les 2 JP et la FR), et même un peu plus car la zone d'image gérée est en fait beaucoup plus grande que ce qui est affiché au final à l'écran.
-
Bonsoir tout le monde,
Un petit point pour vous dire où j'en suis du développement de l'émulateur EmuSCV:
- Le format de fichier est créé et ne devrait plus trop bouger. Finalement c'est du .CART pour les cartouches et du .SAVE pour les sauvegardes des cartouches avec piles.
Je n'ai pas encore pu créer les fichiers pour toutes les ROMs mais les jeux suivants fonctionnent sur la démo (pas de manette active pour le moment pour tester plus) :
Astro Wars
Astro Wars II
Basic Nyumon + sauvegarde
Boulder Dash
Comic Circus
Dragon Ball
Doraemon
Dragon Slayer + sauvegarde
Elevator Fight
Kung-Fu Road
Lupin III
Mappy
Milky Princess
Miner 2049er
Nebula (2 versions)
Professional Wrestling
2 jeux me résistent encore un peu:
Pole position 2
Pop & Chips
J'ai déjà réussi à les faire tourner dans eSCV donc il n'y a pas de raison... je vais trouver.-
En plus du format de fichier propriétaire je vais ajouter la possibilité de charger les ROMs brutes de fonderie, si elles passent directement tant mieux. Pour les ROMs connues ça créera le fichier .CART correctement formaté à la volée (le .SAVE est créé automatiquement pour les jeux avec sauvegarde).
-
J'ai trouvé d'où venait le problème de couleurs sur Astro Wars: c'est un "bug" de eSCV et Mame. En fait mes prédécesseurs Takeda et Enri n'avaient pas trouvé comment était gérés la couleur des sprites 2 couleurs et ils avaient mis en place une solution qui marchait la plupart du temps mais pas pour Astro Wars qui use et abuse de ce type de sprites... mais j'ai trouvé
Je n'ai pas encore fini de saisir l'ensemble des palettes de couleurs mais c'est en cours et ça fonctionne bien.
-
J'ai aussi corrigé le masquage des sprites tout en haut de l'écran. Dans eSCV, Takeda masquait un peu trop de sprites, ce qui ne gênait pas sur la version japonaise mais du coup il manquait des sprites en haut de l'image avec le cadrage de la version européenne (les étoiles sur les deux Astro Wars par exemple).
-
J'ai réussi à récupérer presque tous les "bugs" d'affichage d'origine qu'on trouvait sur plusieurs jeux.
o Le texte en trop en haut dans Doaemon et Boulder Dash sur la console Fr (pas le même cadrage que la console Jp pour lequel le jeu a été développé).
o Le sprite en trop en bas à gauche dans Nebula sur la console Jp (c'est le dernier sprite de droite des pyramides qui déborde de la ligne et se retrouve affiché à gauche)
o Certains grands sprites qui disparaissent à gauche sur la console Jp quand le décor défile (Kung-Fu Road, Nebula, Lupin III, etc.)
-
Pour les sprites supplémentaires moches de Kung-Fu Road, j'ai opté pour la solution utilisée par eSCV et Mame, à savoir que dans certains modes graphiques on n'affiche tout simplement pas les sprites sur une bande en haut de l'écran.
Je ne pense pas que ça soit la solution idoine (vous chercherez "idoine" dans le dico ) mais ça fera l'affaire en attendant que je puisse injecter du code dans une vrai cartouche et tester du code sur mes consoles (c'est prévu mais c'est un peu long et compliqué à faire). -
J'ai presque fini de déterminer le cadrage des consoles Jp (cadre rouge) et Fr (cadre bleu).
Il faut que j'arrive à faire tourner Pop & Chips pour avoir des repères vraiment précis mais ça va venir.
Le cadrage d'EmuSCV sera entre les 2, comme expliqué précédemment.
Juste pour le fun je vous ai mis des captures où on voit ce que les joueurs ne voyaient jamais. Et une de plus pour la route
Je vous donnerai d'autres news la semaine prochaine si j'ai suffisamment avancé sinon dès que possible.
@++
MaaaX ^^ - Le format de fichier est créé et ne devrait plus trop bouger. Finalement c'est du .CART pour les cartouches et du .SAVE pour les sauvegardes des cartouches avec piles.
-
PS: Le "bug d'origine" qui me reste à retrouver c'est le texte supplémentaire en haut.de l'écran dans Boulder Dash. Maintenant il y a bien des caractères mais au lieu d'avoir plein de carrés vides j'ai quelques carrés plein. Je vais regarder si ça vient de la font des caractères ou si c'est un bug de la fonction de dessin "semi-graphique". Ceci-dit c'est pas grave du tout