La Place des Développeurs Les ROM Mapper les mieux supportés
Hello,
Ayant fini le clean de ma Lib, j'ouvre un nouveau chantier : le support des ROM Mapper pour pouvoir créer des jeux de plus de 64 Kb.
J'ai trouvé plein d'infos sur comment ces Mapper fonctionnent (c'est assez simple... comme me l'a souvent répété Metalion
) mais il me manque quelques infos :
1. Quels types de mappers et quelles tailles sont supportés par les cartes Flash ? J'imagine que ça dépend des cartes et de leur capacité, mais si par ex. on veut rester compatible avec 90% des cartes Flash utilisé par la communauté, quel type/taille faut-il viser ?
2. Comment les émulateurs détectent-ils les mappers ? Y-a-t-il des moyens de les "aider" pour la détection ?
3. Dans un Mapper ASCII-8, par ex., une donnée qui se trouverait dans le 10e segment aura une adresse vers 14000h dans le fichier ROM ; Pour y accéder, j'imagine qu'il faut "traduire" cette adresse dans l'espace ou sera placé ce segment ? Si on place le 10e segment dans la 4e "page" de la ROM, il faudra que l'adresse soit vers A000h. C'est bien ça ?
En tout cas, un nouveau monde s'ouvre à moi (oui, c'est pas trop tôt)
Ayant fini le clean de ma Lib, j'ouvre un nouveau chantier : le support des ROM Mapper pour pouvoir créer des jeux de plus de 64 Kb.
J'ai trouvé plein d'infos sur comment ces Mapper fonctionnent (c'est assez simple... comme me l'a souvent répété Metalion
) mais il me manque quelques infos :1. Quels types de mappers et quelles tailles sont supportés par les cartes Flash ? J'imagine que ça dépend des cartes et de leur capacité, mais si par ex. on veut rester compatible avec 90% des cartes Flash utilisé par la communauté, quel type/taille faut-il viser ?
2. Comment les émulateurs détectent-ils les mappers ? Y-a-t-il des moyens de les "aider" pour la détection ?
3. Dans un Mapper ASCII-8, par ex., une donnée qui se trouverait dans le 10e segment aura une adresse vers 14000h dans le fichier ROM ; Pour y accéder, j'imagine qu'il faut "traduire" cette adresse dans l'espace ou sera placé ce segment ? Si on place le 10e segment dans la 4e "page" de la ROM, il faudra que l'adresse soit vers A000h. C'est bien ça ?
En tout cas, un nouveau monde s'ouvre à moi (oui, c'est pas trop tôt)
On est toujours ignorant avant de savoir.
les mappers supportés par les cartes sont
- Konami 8 / Konami SCC taille maximum de la ROM 512K
- Ascii8, Taille max de la ROM 2048K le plus souvent 1024K
- Ascii16, Taille max de la Rom 4096K, le plus souvent 2048K
toutes les tailles intermédiaires sont supportées.
Les émulateurs vérifient si la rom est dans leur base de données pour déterminer le mapper.
Il y a des techniques pour identifier automatiquement le mapper, mais (je crois) que ce n'est pas fiable à 100%.
Si le mapper n'est pas connu on peut le choisir manuellement.
Edité par ericb59 Le 22/12/2021 à 07h21
- Konami 8 / Konami SCC taille maximum de la ROM 512K
- Ascii8, Taille max de la ROM 2048K le plus souvent 1024K
- Ascii16, Taille max de la Rom 4096K, le plus souvent 2048K
toutes les tailles intermédiaires sont supportées.
Les émulateurs vérifient si la rom est dans leur base de données pour déterminer le mapper.
Il y a des techniques pour identifier automatiquement le mapper, mais (je crois) que ce n'est pas fiable à 100%.
Si le mapper n'est pas connu on peut le choisir manuellement.
Edité par ericb59 Le 22/12/2021 à 07h21
D'après le code source de OpenMSX, il semblerait que la détection dépend des adresses appelées pour changer les segments du Mapper.
- KONAMI : 4000h, 8000h et A000h
- KONAMI SCC : 5000h, 7000h, 9000h et B000h
- ASCII 8K : 6000h, 6800h, 7000h et 7800h
- ASCII 16K : 6000h et 7000h / 77FFh
Il y a quelques cas problématiques, mais personnellement, vu que j'imagine utiliser les Mapper surtout pour switcher la dernière Bank il ne devrait pas y avoir d'ambiguïté.
Surtout que dans mon code de boot (ctr0), je vais initialiser chaque segment donc les adresses de switch de chaque branche vont être appelé au moins 1 fois.
- KONAMI : 4000h, 8000h et A000h
- KONAMI SCC : 5000h, 7000h, 9000h et B000h
- ASCII 8K : 6000h, 6800h, 7000h et 7800h
- ASCII 16K : 6000h et 7000h / 77FFh
Il y a quelques cas problématiques, mais personnellement, vu que j'imagine utiliser les Mapper surtout pour switcher la dernière Bank il ne devrait pas y avoir d'ambiguïté.
Surtout que dans mon code de boot (ctr0), je vais initialiser chaque segment donc les adresses de switch de chaque branche vont être appelé au moins 1 fois.
On est toujours ignorant avant de savoir.
aoineko :
c'est assez simple... comme me l'a souvent répété Metalion
aoineko :
Comment les émulateurs détectent-ils les mappers ? Y-a-t-il des moyens de les "aider" pour la détection ?
Comme l'explique Eric, effectivement, les émulateurs recherchent dans le code les écritures sur les adresses clé des mapper.
J'ai déjà remarqué que parfois la détection est meilleure si il y a écriture sur les 4 adresses clé dans le code.
aoineko :
Dans un Mapper ASCII-8, par ex., une donnée qui se trouverait dans le 10e segment aura une adresse vers 14000h dans le fichier ROM ; Pour y accéder, j'imagine qu'il faut "traduire" cette adresse dans l'espace ou sera placé ce segment ? Si on place le 10e segment dans la 4e "page" de la ROM, il faudra que l'adresse soit vers A000h. C'est bien ça ?
Il n'y a rien à traduire. Lorsque le switch est fait, les données se retrouvent "physiquement" à l'adresse du bank sélectionné. Il suffit donc qu'à la compilation, toutes les adresses utilisées dans cette page soient bien celle du bank où elle sera sélectionnée.
Par exemple, si ta page 12 est prévue pour être sélectionnée à l'adresse 0C000h, et que le code de cette page commence comme ça :
Code :
erase:
ld a,(y)
add 2
...
Il faut évidemment que la valeur de ton label "erase" soit égale à 0C000h.
MSX1: Daewoo DPC-200 / Yamaha CX5M
MSX2: Sony HB-F9P
MSXVR
Vidéo: V9990 (GFX-9)
Audio: MSX-Music (FM-PAC) / MSX-Audio (Audiowave) / OPL4 (Monster Sound FM Blaster) / OPNB (Neotron)
Metalion :
Par exemple, si ta page 12 est prévue pour être sélectionnée à l'adresse 0C000h, et que le code de cette page commence comme ça :
Il faut évidemment que la valeur de ton label "erase" soit égale à 0C000h.
Par exemple, si ta page 12 est prévue pour être sélectionnée à l'adresse 0C000h, et que le code de cette page commence comme ça :
Code :
erase:
ld a,(y)
add 2
...
Il faut évidemment que la valeur de ton label "erase" soit égale à 0C000h.
Je vais devoir compiler mes segments indépendamment et re-merger les binaires ensuite.
Je vais essayer de trouver une façon "pratique" de faire ça en C.
On est toujours ignorant avant de savoir.
Citation :
Comme l'explique Eric, effectivement, les émulateurs recherchent dans le code les écritures sur les adresses clé des mapper.
J'ai déjà remarqué que parfois la détection est meilleure si il y a écriture sur les 4 adresses clé dans le code.
J'ai déjà remarqué que parfois la détection est meilleure si il y a écriture sur les 4 adresses clé dans le code.
Nan ! Je crois pas avoir dit ça
Pour open MSX, il y a le fichier softwaredb.xml qui se trouve dans le dossier /share/
qui reprend l'intégrale des ROM connues, Homebrew récent compris.
Le type de mapper est intégré dans la fiche descriptive de chaque ROM. Une ROM est reconnue par son Hash.
Quand on a sorti en format ROM le jeu "Code Name : Intruder" OpenMSX était incapable de trouver le type de mapper du jeu. Il fallait l'ajouter à cette base de données pour qu'il se lance correctement avec le mapper ASCII16.
Bon, en vrai j'ai fait la partie la plus facile (crt0 et adaptation de l'outil de génération des ROM).
Il me reste à trouver un moyen élégant de définir le contenu des différents segments de la ROM, de générer les binaires, puis de les concaténer pour créer la ROM.
Autant dire qu'il me reste du pain sur la planche.
On est toujours ignorant avant de savoir.
ericb59 :
Nan ! Je crois pas avoir dit ça
Non, c'est vrai.
J'ai un peu ... interprété
Au sein de la communauté MSX, plusieurs personnes ont déjà proposé d'établir un standard de fichier qui ajouterai au fichiers megarom, un entête de quelques octets qui définirait le mapper utilisé. Personnellement, je trouve que c'est une excellente idée, mais elle ne semble pas avoir de succès.
La megarom de "No Back Down" pour MSXdev21 utilise le mapper ASCII8 et comporte 8 pages (64Ko). Cela a posé un problème aux émulateurs, car apparemment, il font aussi des tests sur la taille du fichier. Comme aucune megarom commercialisée avec le mapper ASCII8 ne fait 64Ko (alors que c'est théoriquement possible), ils ne reconnaissaient pas le mapper.
MSX1: Daewoo DPC-200 / Yamaha CX5M
MSX2: Sony HB-F9P
MSXVR
Vidéo: V9990 (GFX-9)
Audio: MSX-Music (FM-PAC) / MSX-Audio (Audiowave) / OPL4 (Monster Sound FM Blaster) / OPNB (Neotron)
Metalion :
La megarom de "No Back Down" pour MSXdev21 utilise le mapper ASCII8 et comporte 8 pages (64Ko). Cela a posé un problème aux émulateurs, car apparemment, il font aussi des tests sur la taille du fichier. Comme aucune megarom commercialisée avec le mapper ASCII8 ne fait 64Ko (alors que c'est théoriquement possible), ils ne reconnaissaient pas le mapper.
Oui, j'ai vu ça dans les sources d'OpenMSX.
Je vais supporter les mapper ASCII 8 & 16 et Konami avec & sans SCC mais dans tous les cas, la taille minimale sera de 128 KB.
Pour le format, finalement j'ai trouvé une solution plus élégante sans passer par aucun fichier de config.
Quand je build une ROM avec un mapper, je cherche des fichiers avec un format particulier pour assembler automatiquement les différents segments.
Par ex., pour mon programme sample, j'ai :
Code TEXT :
s_ascii8.c // First 32 KB of the ROM (segment #0 to #3) s_ascii8_s4_b3.c // Segment #4 Bank #3 s_ascii8_s15_b3.c // Segment #15 Bank #3
L'outil de build va d'abord compiler et linker s_ascii8.c qui contient les premiers 32K, et donc les segments 0 à 3 pour un mapper ASCII 8K.
Ensuite, il va chercher pour chaque segment restant ( [N] de 4 à 15 pour une ROM ASCII-8 de 128KB) s'il existe un fichier de la forme s_ascii8_s[N]*.c .
S'il existe, il compile le fichier en utilisant comme adresse de début le numéro de banque présent dans le nom du fichier (B1, B2, B3 ou B4) et ajoute le segment au fichier binaire.
S'il n'existe pas, l'outil ajoute un segment vide au fichier binaire.
Comme ça, si je veux ajouter à ma ROM ASCII-8 des données dans le segment 8 qui sera visible dans la bank 3 (0xA000~0xBFFFF), j'ai juste à créer un fichier s_ascii8_s8_B3.c , mettre quelques données dedans et relancer l'outil de build.
J'ai pas trouvé plus simple.
On est toujours ignorant avant de savoir.
Bon les gars, j'ai une sacré longueur de retard 
Quand tu auras fini avec ta ROM 48K, je te ferai un topo complet.
Tu verras, c'est beaucoup plus simple qu'il n'y parait.
Tu verras, c'est beaucoup plus simple qu'il n'y parait.
On est toujours ignorant avant de savoir.
Pour info, et si tu ne connais pas aoineko, la librairie de Retro Deluxe (a laquelle personnellement je ne pige rien, mais qui doit être très bien), supporte les mappers ASCII8/16 et Konami (il me semble).
https://github.com/retrodeluxe/rlengine-msx Edité par ericb59 Le 24/12/2021 à 15h28
https://github.com/retrodeluxe/rlengine-msx Edité par ericb59 Le 24/12/2021 à 15h28
Oui, je connais.
Elle ne supporte que le mapper ASCII-8.
C'est un avis très personnel, mais je trouve que la lib est assez bordélique.
De toute façon, normalement j'ai tout ce qu'il faut pour gérer "simplement" (de mon point de vue en tout cas) les jeux avec n'importe quel mapper.
Elle ne supporte que le mapper ASCII-8.
C'est un avis très personnel, mais je trouve que la lib est assez bordélique.
De toute façon, normalement j'ai tout ce qu'il faut pour gérer "simplement" (de mon point de vue en tout cas) les jeux avec n'importe quel mapper.
On est toujours ignorant avant de savoir.
Citation :
Elle ne supporte que le mapper ASCII-8.
Ha ok... Me semblait en avoir vu un autre mais ca doit être ailleurs.
Citation :
C'est un avis très personnel, mais je trouve que la lib est assez bordélique.
p'têt pour ca que j'y pige rien alors
Citation :
De toute façon, normalement j'ai tout ce qu'il faut pour gérer "simplement" (de mon point de vue en tout cas) les jeux avec n'importe quel mapper.
Après moi je dirais que gérer un seul mapper ça suffit largement.
C'est bon, ça marche !
J'ai fait une ROM avec un Mapper ASCII-8 de 128K avec :
- Les 4 premiers segments qui fonctionnent comme une cartouche 32K.
- Et les 12 autres segments (une cartouche de 128K = 16 segments de 8K) ou on peut ajouter des données en C en nommant juste son fichier source comme il faut.
Dans l'exemple, j'ai créer 2 fichiers, un pour le segment #5 et un pour le #10.
Le programme de sample switch chacun des segments dans la bank #3 (A000h~BFFFh) et lis les premiers octets.
J'ai mis une chaine de caractère dans chaque segment pour que ce soit plus facile de visualiser que le switch a fonctionné.
J'ai pas de machines sous la main mais j'ai testé sur tous les émulateurs (OpenMSX, BlueMSX, fMSX, Meisei, Emulicious et même ruMSX) et tout fonctionne bien.
Voici le fichier s_ascii8.rom si quelqu'un peut tester sur une MegaFlashROM à l'occaz.
Bon réveillons !
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie