30

J'ai bien galéré mais je suis enfin parvenu à afficher un sprite, j'ai mis mon code source par ici:
bjorn-nah/SCV_stuffGitHubYeno / Epoch Super Cassette Vision stuff! Contribute to bjorn-nah/SCV_stuff development by creating an account on GitHub.

J'ai enfin compris comment utiliser la console de débug de eSCV, ça m'a bien aidé ( la commande d permet de dumper la ram, par exemple "d 3400" permet de voir le contenu des registres du VDC)

J'ai essayé d'y donner un peu de mouvement mais je ne suis pas encore parvenu à faire un Wait sur la VBlank. J'ai bien vu qu'il y avait une fonction dans le scv_plogue_tester (WVBLANK) mais je me demandes s'il n'y a pas un truc du genre les interruptions du VDC ne sont pas activées.
avatar

31

Bah logiquement oui si tu as EI (enable interrupt) dans ton code. Je regarderai cette nuit.
avatar

32

EI et DI doivent se référer aux interruptions du CPU, pour celles du VDC je me demande s'il n'y a pas un bit correspondant à 0x3400.
Ou alors quelque chose au niveau de 0xFFFA ou 0x80 (cf. la doc d'Enri: http://www43.tok2.com/home/cmpslv/Scv/EnrScv.htm )
avatar

33

Je ne sais pas mais il y a un truc. Int2 qui revient dans la "permission" du VDC (bit3 de 0x3400) est à creuser. Autant sur du sprite qui se déplace à l'horizontale pas de problème mais oui problème sur du sprite vertical cela flicke a mort dès que tu dépasses un certain nombre (et selon le code) donc faut trouver à se caler sur Vblank mais pas encore réussi.
avatar

34

Je croyais avoir fait un essai avec le bit 3 mais c'est possible que je soit passé à coté d'un truc. La doc d'Enri parles de "référence ATB du sprite", perso ça ne parles pas.
J'ai mis à jour mon Git ou je suis parvenu a un truc en utilisant le contenu de 0xFFDB qui doit être un compteur de frames (les suivants sont des horloges). C'est pas ce que je souhaitais mais ça roule.
Par contre Je suis vraiment à la rue avec les opcodes de nec, je galère très fort.
avatar

35

Ok vu ton sprite ne flicke pas en effet mais c'est grace à 0xDDDB (int2 quelquechose wink ). D'ailleurs si tu t'amuse à créer un 2e attribut de sprite et qu'au lieu d'incrémenter Y tu incrémente X pour ce 2e tu verra que tes 2 sprites devraient se croiser sans problème et sans flicking. Mais 0xFFDB est en effet bizarre. Je viens de tester vite fait du coup pour voir avec plusieurs sprites et ton 0xFFDB mais cela flicke dans tous les sens. Mais bon ma routine est pas prévu comme cela à la base alors cela vient ptet d'ailleurs (ma routine de chargement de sprites en RAM est pourrie je charge chaque sprite un par un pour pouvoir avoir le contrôle et facilement modifier et tester). De plus j'ai du attribut sprites BG (background) et CH qui ne fait pas ce qu'il devrait faire pour ne pas arranger les choses. wink
Du coup je m'amuse à desassembler un jeu (AstroWars) pour voir un peu car il y a trop de trucs louches.
avatar

36

Up,
J'ai enfin résolu mes soucis de Vblank: ce n'était pas l’interruption qui était en cause mais je n'utilisait pas une adresse Ram "utilisateur" pour les variables...
En fait je me rend compte que la cartographie du Bus que j'ai n'est pas complète (http://www43.tok2.com/home/cmpslv/Scv/EnrScv.htm), j'ai essayé de mettre la main sur la zone utilisable (128B donc, j'espère juste que B c'est pour Bytes et pas Bits...)
Là j'utilise les adresses à partir de FF90h (info trouvée sur le plogue tester -- 0FF8X seems reserved, but not FF9X) mais quand je regarde le dump de la ram j'ai bien l'impression que la zone disponible est bien inférieure à 128o... :/

Edit/PS: il serait peut être judicieux de faire un fil de discussion à par pour le dev SCV?
avatar

37

Je m'auto-répond à propos des proutions de de coke774, il ne souhaites pas diffuser ses productions.

Domage, surtout qu'il fait aussi de belles pcb :3
avatar

38

Nouveau jeu de coke 774, Tanklion:
avatar

39

Merci pour ces infos Bjorn, c'est super intéressant. L'effet de rotation (bon, par saccade quand même) est chouette sur le jeu de tank !
Tu dis que le gars fait des PCB de ses jeux mais ne les diffuse pas ? C'est quand même bizarre de concevoir des jeux pour qu'ils ne soient joués par personne à la fin ! (gratuitement ou pas d'ailleurs c'est pas la question). Après il semble avoir mis ça en essai libre lors d'une convention, c'est déjà ça mais ça limite aux japonais sur place !
Par ailleurs, il a même adapté une manette 2 joysticks sur la SCV pour jouer à son jeu de tank : doit y avoir une gestion indépendante des déplacement et de la tourelle ! Excellente idée à la Robotron smile
avatarRevival Gamers : toute l'actu du jeu vidéo homebrew - demoscene - reportage - programmation - ...
http://cotegamers.com

40

Bonjour,

Comme je suis nouveau, je me présente rapidement: J'ai eu la Super Cassette Vision étant gosse et je l'adore encore.
Étant développeur je suis en train de faire un portage de l'émulateur eSCV sur Retroarch pour que ça puisse tourner sur plein de plateformes dont Recalbox sur Raspberry PI.

Mon projet comporte plusieurs phases:
1) Création de l'émulateur Libretro-EmuSCV
2) Extraction propre des ROM et scan des cartouches, boîtes et manuels
3) Création des outils de Dev
4) Injection des nouvelles ROM dans des cartouches physiques.

J'ai besoin d'aide pour les phases 2 et 4.
Est-ce que quelqu'un peut me dire de quel matériel j'ai besoin pour extraire la ROM d'une cartouche?
J'ai déjà toutes les ROM qui fonctionnent mais je voudrai refaire celle d'Astro Wars (les couleurs sont pas les mêmes entre la cartouche et la ROM que j'ai).
Et pareil dans l'autre sens pour mettre une nouvelle ROM dans une cartouche physique (écriture sur EPROM?)
avatar

41

Salut et bienvenu sur le forum
Je t'invites à te présenter plus grandement ici wink sections/172-2218-presentez-vous

Bravo pour ton projet.
Perso, je n'ai jamais eu de Super Cassette Vision et c'est une console assez confidentielle pour ma part.

Pour l'étape 2 et la partie scan, il faut trouver les personnes qui auraient du temps pour cela.
Pour l'extraction de la ROM, là je ne sais pas

Et pareil dans l'autre sens pour mettre une nouvelle ROM dans une cartouche physique (écriture sur EPROM?)
> il serait plus intéressant de se rapprocher de personnes qui éditent des jeux, le mieux est de refaire des PCB propre sur lesquels ont peut écrire le programme. (car utiliser des cartouches d'époque ,c'est un peu triste tout de même).