MSX Village forum

L'école comprendre de zéro le fonctionnement d'une cartouche MSX

yabikoo33 Membre non connecté

Vagabond

Rang

Avatar

Inscrit le : 14/11/2020 à 17h25

Messages: 18

Le 15/11/2020 à 12h03
Bonjour à tous,

Hier j'ai ressorti d'un placard un MSX que je possède depuis des années et me suis mis en tête de jouer, seulement voilà, je n 'ai que deux cartouches très moyennes et après un rapide coup d'oeil sur ebay,j'ai vite compris que sauf à y vendre en échange un rein, il me serait financièrement difficile de me faire une collection de jeux sympas pour m'amuser :) .

Puisque j'ai déjà fait des cartouches pour différentes consoles , je me suis dit qu'en attendant je devrais pouvoir me faire la PCB d'une cartouche pour faire mes premiers essais.

Une cartouche ce n'est en général qu'une eprom à qui la console envoie des adresses et reçoit en échange les datas correspondantes .

Donc première recherche hier sur les mot clefs " MSX cartridge pinout " , et là premiers doutes , mais qu'est-ce que c'est que ces pins /CS1 /CS2 et /CS12 ?

Tout ceci m'a amené à continuer mes recherches et à trouver pleins d'infos très disséminées. Il me semble maintenant qu'il est impossible de comprendre le fonctionnement d'une cartouche MSX sans comprendre un minimum le fonctionnement de son hardware bien plus complexe ( et flexible ) que les autres systèmes 8bits.

J'aimerais ici vous faire un exposé de ce que je crois avoir compris pour le soumettre à votre critique éclairée et recevoir votre aide pour combler ce que je n'ai pas compris. C'est également le moyen de faire un point complet ,sur une seule page et en français de myriades d'infos disséminées en anglais sur le net . Merci d'avance pour cette aide précieuse :)



Donc en jetant un oeil sur cette page : https://www.chibiakumas.com/z80/platform3.php#LessonP25

j'ai commencé à comprendre que les MSX fonctionnent avec 4 slots numérotés 0 à 3 , chacun pouvant avoir 4 sous-slots .
Chaque sous-slot est en pratique une bank de 16Ko

Les slots 1 et 2 sont toujours dédiés aux ports cartouches , donc je suppose que si le MSX n'a qu'un seul port cartouche, le slot 2 est systématiquement condamné (il ne peut y avoir ni rom ni ram ni rien) ?

Les slots 0 et 3 sont librement exploitables selon le bon vouloir du fabricant, qui doit cependant utiliser au moins un sous-slot pour de la ram (donc 16K minimum) et un autre pour la rom interne (le basic je suppose) .

Ce qui fait que d'un modèle/marque d' MSX à l'autre ,la ram et la rom peuvent se trouver sur différents slots. J'ai lu par ailleurs que cela avait posé quelques problèmes d'incompatibilité avec certains jeux , puisque certains petits éditeurs ne pouvant tester que sur un ou deux MSX hardcodaient les maps de la ram et de la rom sans demander préalablement au msx leur position.
Cela signifie donc que la ram et la rom se trouvent en général à peu près tous sur les mêmes slots / sous-slots quel que soit le modèle ? quels sont ces emplacements récurrents ? y-a-t-il beaucoup de modèles qui y dérogent ?


Maintenant concernant l'adressage, la datasheet du Z80 me montre A0 à A15 soit 2^16=64Ko adressables partagés donc entre la ram et l'eprom de la cartouche . Le "système" MSX donne accès au Z80 à ces adresses par 4 banks de 16Ko .

Je suppose donc que le MSX dispose d'un mapper interne qui lui permet de router n'importe quel sous-slot vers n'importe laquelle de ces 4 banks accessible au Z80 ? Enfin non,je pense justement qu'il y a des limitations , du moins c'est ce que semblent signifier les présences de /CS1,/CS2 et /CS12

Je suppose donc qu'un codeur qui fait bien son boulot commence par lire une série de registres pour localiser la ram et éventuellement la rom voir les extensions potentiellement présentes dans les slots 0 et 3 . Il localise également la cartouche dans le slot 1 ou 2.

Ensuite je suppose qu'en fonction des informations reçues, il peut mapper ses 1,2,3 ou 4 banks disponibles dans la cartouche vers le Z80 . Je suppose également qu'il faut en permanence lui laisser au moins une bank de ram ? est-ce que cette bank réservée est fixe (du style C000-FFFF ) ? Cela signifie que le codeur peut avoir au maximum accès en permanence à 48ko et doit jouer sur le mapper interne pour accéder aux 16ko restants dans le cas d'une cartouche 64Ko ?

Pourquoi les cartouches démarrent elles en 0x4000 ou en 0x8000 plutôt qu'en 0000 ? Est-ce parce que par défaut au lancement de la machine c'est la rom interne qui occupe le map de la bank 0 ? Cela signifie donc qu'une fois la cartouche lancée , le codeur peut réattribuer cet espace pour un sous-slot de sa cartouche ou est-il finalement bloqué à deux sous slots en permanence soit 32ko ?

et concernant la ram ? Si le msx dispose de plus de 16ko, est il possible par exemple de mapper la mémoire supplémentaire par exemple sur la bank 8000-BFFF du Z80 ?

Je ne comprend pas bien /CS1 et /CS2 , tous deux offrent une plage de 16ko , alors pourquoi faire ? Est-ce que certains jeux de 16Ko seulement démarrent réellement sur la plage 8000 au lieu de 4000 ? Ou était-ce simplement pour permettre aux cartouches de gérer facilement 2 eproms de 16Ko plutôt qu'une seule de 32ko ?

Et donc concrètement si par exemple je décide de lancer un jeu de 16ko qui démarre à 4000, je peux par exemple utiliser une 27c128 avec le OE Branché sur /CS1 et CE sur /SLTSL.

On peut donc aussi faire un cartouche universelle 0-64Ko avec une 27C512 , en branchant OE sur /RD et CE sur /SLTSL. Il suffit de ne commencer la programmation qu'à ox4000 ou ox8000 pour certains jeux, c'est bien ça ? De toute façon si le MSX accède par exemple à la ram, /SLTSL restera à l'état haut ?

Mais du coup on pourrait aussi par exemple faire une cartouche polyvalente,à la fois cartouche simple,cartouche/ram et potentiellement extension de ram par exemple en utilisant deux fram style FM18W08 plutôt qu'une 27c512 :)

Je m'intéresserai aux mappers cartouche plus tard, ça me semble beaucoup plus simple en fait et j'ai pu voir que Jipe a déjà très bien défriché le sujet sur le forum.

Merci à tous ceux qui prendront le temps de lire ce pavé ,j'ai appris pleins de trucs ce Week end et je me suis bien amusé :) J’espère n'avoir pas écrit trop de bêtises et avoir pleins d'éclairages ;

j'espère aussi que le fruit de mes recherches est suffisamment clair,simple et bien résumé pour servir à d'autres débutants comme moi dans le monde du MSX.
   
Jipe Membre non connecté

Maire-adjoint

Rang

Avatar

Association

Inscrit le : 02/10/2009 à 19h41

Messages: 9391

Le 15/11/2020 à 13h36
d'abord merci pour le lien que je connaissais pas

le PPI 8255 est utilisé pour mapper les pages de mémoire de 16K

télécharge le service manual du sony HB75 qui utilise des composants classiques a cette adresse : www.msxarchive.nl/pub/msx/mirrors/hanso/service_manuals/sonyhp5575sm.pdf

le msx utilise des 74LS670 pour son memory mapper, il est utilisé a partir des MSX2 qui utilisent un chip MSX SYSTEM ou une partie du décodage est intégrée ( S3527 S1985 )

j'ai retrouvé mon schéma ici : https://docplayer.net/52880937-Msx-memory-mapper-with-simms-256k-to-4-mb.html

le memory mapper utilise les ports FC FD FE FF voir ici : http://problemkaputt.de/portar.htm#ioportsummary

pour faire simple pour les signaux suivants :
/CS1 sert pour les cartouches qui ont des mémoires de 16k de 4000h a 7FFFh -> 27C128
/CS2 sert pour les cartouches qui ont des mémoires de 16k de 8000h a BFFFh -> 27C128
/CS12 sert pour les cartouches qui ont des mémoires de 32k de 4000h a BFFFh -> 27C256

regarde sur le schéma du HB75

ces cartouches peuvent contenir des jeux ou des utilitaires

l'en-tête de la rom permet de voir l'identifiant d'une cartouche qui est 41h 42h suivi de son adresse de démarrage 10h 40h pour 4010h par exemple



:noel
Site web    
Jipe Membre non connecté

Maire-adjoint

Rang

Avatar

Association

Inscrit le : 02/10/2009 à 19h41

Messages: 9391

Le 15/11/2020 à 13h37
au fait tu as quoi comme MSX ;)


:noel
Site web    
aoineko Membre non connecté

Maire-adjoint

Rang

Avatar

Association

Inscrit le : 02/01/2011 à 21h17

Messages: 2077

Le 15/11/2020 à 17h02
Je vais pas pouvoir aider, mais je vais suivre cette discussion avec attention. :tea


On est toujours ignorant avant de savoir.
Github    
yabikoo33 Membre non connecté

Vagabond

Rang

Avatar

Inscrit le : 14/11/2020 à 17h25

Messages: 18

Le 15/11/2020 à 18h36
Hello JIPEMSX et merci pour cette réponse plus que rapide !

Je vais aller voir les specs du coup mais je crois que ce n'est rien de très original, j'ai un Toshiba HX-20 avec une touche cassée et je viens de retrouver un Sanyo 64K (je n'ai pas vu d'autre ref dessus) .

et effectivement,du coup je me suis amusé à ouvrir en hexa les fichiers roms que j'ai pu trouver; ... Wooo c'est un énorme chmilblik, elles démarrent d'à peu près n'importe quelle adresse de 0 à 8000h et même au-delà parfois. Bon, je vais déjà me faire un petit "homebrew player MSX en proto,rien d'extraordinaire,juste pour faire des tests sur des roms de 0 à 64K ; j'ai vu que ça existe déjà c'est sur,mais au moins je pourrais valider les dimensions de la PCB pour le jour où je ferai quelque chose de plus complexe.Je finis les schémas dans la semaine . Si ça intéresse quelqu'un d'autre et si ca marche, j'offrirai la carte (à souder soi-même) aux membres de l'asso et du forum qui le souhaitent juste contre les frais de ports ( ca devrait faire moins de 100gr en suivi ). Il faut compter une semaine pour le schémas et le routage et 10 jours de plus environ pour que mon fabricant chinois me la fasse. Donc je devrais pouvoir vous montrer une photo du proto pour décembre :)


En tout cas merci encore pour tous ces liens et ces infos, il y a encore du boulot avant de tout bien maîtriser :) . Je vais potasser tout ça et revenir vers vous dès que j'en ai compris d'avantage ou que vous m'apportez de nouvelles infos .

Ensuite j'aimerais comprendre les mappers coté cartouche , cette fois .J'ai vu sur le même site du lien un exemple au travers du konami SCC , ca à l'air très simple en fait , donc si j'ai bien compris ,konami utilise 32ko découpés en 4 banks de 8 ko :

Area Z80 Address Range Write Address to change bank
1 &4000-&5FFF &5000
2 &6000-&7FFF &7000
3 &8000-&9FFF &9000
4 &A000-&BFFF &B000

Donc on écrit simplement à l'adresse 5000 le numéro de bank sur 8 bits que l'on souhaite attribuer à la plage 1 ?
Donc on peut potentiellement avec ce mapper exploiter une eprom de 256 X 8k = soit 2mo max ? (27c160 par exemple)

Ai-je bien compris ? et si oui, tous les mappers sont-ils basés sur le même principe ?


   
aoineko Membre non connecté

Maire-adjoint

Rang

Avatar

Association

Inscrit le : 02/01/2011 à 21h17

Messages: 2077

Le 15/11/2020 à 20h31
Y a qq détails dans la section Les slots et le memory mapper de Pratique du MSX2.

Qu'entends-tu par « homebrew player MSX » ?


On est toujours ignorant avant de savoir.
Github    
jbkun Membre non connecté

Vagabond

Rang

Avatar

Inscrit le : 17/10/2020 à 22h48

Messages: 13

Le 15/11/2020 à 21h34
J'ai eu le même réflexe je suis allé voir dans la pratique du MSX. C'est vraiment la bible!

Je pense que Yabikoo33 évoque une PCB dans ce style :
https://www.ebay.fr/itm/274415164121
   
yabikoo33 Membre non connecté

Vagabond

Rang

Avatar

Inscrit le : 14/11/2020 à 17h25

Messages: 18

Le 16/11/2020 à 10h24
Encore un lien que je ne connaissais pas, en français, hyper simple et clair, je crois que j'ai trouvé mon bonheur :) Mais plus je découvre le msx plus je me dis que les programmeurs de l'époque étaient vraiment bon. Dès que leur jeu dépassait 16k de ram et/ou 32ko de rom cartridge ( mais surtout 16ko de ram),toutes leurs datas étaient sur des sables mouvants, surtout les variables !

Donc je comprend qu'effectivement, en utilisation normale le bios est sur la première plage tandis que la ram est sur la dernière plage. Il reste 32k pour la cartouche sur les 2eme et 3eme plages. Mais avec le système d'en-têtes que m'a décrit JP , j'ai pu voir que cette règle de "normalité" est allègrement bafouée (enfin concernant le bios qui visiblement semble être parfois placé sur d'autres plages , concernant la ram, je ne suis pas sur, je n'ai trouvé aucune rom qui démarrait après C000h) .

Mais avec cette super doc et le lien de aoineko, je me rend compte que tout existe et que je réinvente l'eau chaude en commençant par l'eau tiède :) .

Et oui jbkun ,c'est à peu près ce que j'évoquai , mais version 27C128/256/512 pour tester toutes les possibilités offertes par le msx.

Mais du coup vu que tout est maintenant si clair, je me demande si je n'ajouterai pas une empreinte du style TQFP100 pour pouvoir ajouter un CPLD et tenter aussi d'émuler les différents mappers existants. Il faudrait juste que je trouve une liste exhaustive des mappers existants et un résumé de leur fonctionnement. J'ai bossé ces derniers temps pour Neofid et émulé le mapper SSF2 que sega avait mis au point pour sa megadrive en l'extrapolant pour qu'il gère aussi de la Fram, du coup j'ai un peu d'expérience sur le sujet.

Ce serait super de faire une carte de développement hyper polyvalente et flexible, la plus simple et optimisée possible,avec peu de composants et des composants très communs, pour qu'elle coute très peu à produire. Et aussi de la Fram pour sauvegarder ce qu'on veut . L'idée serait qu'un petit développeur puisse aujourd'hui développer un jeu révolutionnaire en exploitant toutes les capacités du système , puis le distribuer sans se ruiner sur le Hardware . Ca ça n'existe pas je crois, et ce serait cool !
   
aoineko Membre non connecté

Maire-adjoint

Rang

Avatar

Association

Inscrit le : 02/01/2011 à 21h17

Messages: 2077

Le 16/11/2020 à 11h30
yabikoo33 :
Il faudrait juste que je trouve une liste exhaustive des mappers existants et un résumé de leur fonctionnement


Alors, je sais pas si elle est exhaustive, mais tu as déjà une bonne liste ici : https://www.msx.org/wiki/MegaROM_Mappers

« empreinte du style TQFP100 pour pouvoir ajouter un CPLD », c'est du chinois pour moi, mais j'ai hâte de voir ce que ça va donner ^^

Perso, en tant que développeur de jeux (sur consoles "modernes") un truc qui me manque vraiment sur le dev MSX c'est de pouvoir tester facilement sur le vrai hardware (du coup, je passe bcp de temps sur émulateur).
Ce qui serait génial, c'est une cartouche MSX que tu relis directement au PC via USB sur laquelle tu peux envoyer ta ROM ou ton DSK et faire des reboots.


On est toujours ignorant avant de savoir.
Github    
Jipe Membre non connecté

Maire-adjoint

Rang

Avatar

Association

Inscrit le : 02/10/2009 à 19h41

Messages: 9391

Le 16/11/2020 à 11h50
il faut en effet éviter de toucher a la page qui va de C000h a FFFFh car elle contient toutes les informations pour le fonctionnement : les variables systéme et les hook

par contre on peut la swapper pour un accés c'est ce que font les ROMS de 64k

il y a certains cartouches qui démarrent en 0000h mais elles sont rare par contre on a vu arriver dans les homebrew des jeux de 48k qui démarrent en 4000h et qui contiennent des datas de 0000h a 3fffh

la plupart des cartouches homebrew récentes avec mapper megarom sont basées sur la megaflashrom qui vient d'espagne : https://www.msxcartridgeshop.com/

pour voir l'intérieur regarde dans ce post : http://msxvillage.fr/forum/topic.php?id=950&pt=1

pour les cartouches de développement on a déja notre eric au village mais sur son site presque tout semble en rupture de stock

https://www.ebsoft.fr/shop/fr/15-materiel-msx


:noel
Site web    
yabikoo33 Membre non connecté

Vagabond

Rang

Avatar

Inscrit le : 14/11/2020 à 17h25

Messages: 18

Le 16/11/2020 à 13h39
Concernant Eric,c'est sympas,il référence effectivement tout ce qui peut être utile à un msxien. C'était juste histoire de pouvoir faire mes premiers tests et de faire faire directement mes premières cartes , ça permet aussi de me forcer à faire mes premières empreintes et à les valider,pour les avoir et les réutiliser lorsque j'attaque des choses plus complexes . En plus,les PCBds ce n'est pas le plus chère en électronique.

La megaflashrom semble vraiment bien optimisée , à prix plutôt correct pour une vente au détail confidentielle, rien à dire , mais je pense qu'elle revient trop chère pour une production de jeux . Déjà un FPGA spartan c'est aux alentours de 4 euros.Ensuite un spartan n'est pas 5V tolerant , ils compensent ca en mettant un réseau de résistance; pour moi ce n'est pas très bon ni pour l'ordi ni pour le FPGA. Pour bien faire , j'aurais plutôt mis des LVC245 ou des 4050 ; il y a quelques temps un français avait écrit un article à ce sujet qui se nommait "the danger of 3.3V flash in retro consoles" , je ne l'ai pas retrouvé et ne l'ai plus en tête mais ses explications me semblaient cohérentes.

L'idée serait plutôt d'utiliser un CPLD avec des pins 5V tolerant comme un XC95144XL, ça coute moins d'un euro et comme c'est 5V tolerant en entrée ,il peut également faire l'interface entre la mémoire flash et le MSX sans composant supplémentaire. C'est plus casse-tête à programmer car moins puissant qu'un FPGA mais je reste persuadé que ca permettrait de fabriquer une carte avec un mapper au choix , une carte flash et de la feram de sauvegarde pour un cout de revient aux alentours des 4-5 euros pour 200 ou 300 pièces .

C'est hyper important car un codeur qui décide de faire un super jeu risque de passer 6 mois ou plus sans revenu,durant le temps de son travail; pour qu'il puisse le faire et vendre le fruit de son boulot sous forme de cartouche pour un prix raisonnable,il faut que la cartouche lui coute un minimum. Donc petit objectif sympas : faire une carte de dev qui en production sera parfaitement sécure pour l'ordi et le moins chère possible pour le développeur. Après, aoineko , rien n'empêche d'ajouter une petite interface USB pour le programmer rapidement et voir presque en direct ce que ca donne :) .

L'idée c'est d'être dédié au développement et à la production d’œuvres nouvelles

Par contre,du coup, ce sera un peu plus long :)
   
yabikoo33 Membre non connecté

Vagabond

Rang

Avatar

Inscrit le : 14/11/2020 à 17h25

Messages: 18

Le 16/11/2020 à 14h56
et merci aoineko , il y en a pas mal en fait :) ; je vais tous les regarder , mais tant qu'à faire n'en retenir qu'un seul pour l'instant. Si possible un qui soit intégré dans un IDE ou équivalent populaire pour MSX et qui permette aussi de gérer de la sram. Lol j'espère juste qu'un jour un codeur exploitera tout ça :)
   
yabikoo33 Membre non connecté

Vagabond

Rang

Avatar

Inscrit le : 14/11/2020 à 17h25

Messages: 18

Le 04/12/2020 à 06h25
Salut à tous,
je vous tiens au courant de mon avancement,



donc déjà pour voir si ca marche,j'ai fait une petite carte 128in1 qui n'accepte que les roms de 0 à 64ko. Pour commencer par la base.L'idée était de se passer de /CS1 /CS2 et /CS12 .

J'ai reçu les protos cette semaine

J'ai donc fait un petit bout de code sous arduino qui ouvre chaque fichier msx, lit l'adresse 0x3h , soit le 4eme octet de chaque jeu et multiplie sa valeur par 0x100h. Il décale ensuite les adresses du code de la valeur trouvée puis enregistre le tout dans un nouveau fichier de 64Ko , ce, que la rom fasse 8,16,32 ou 64Ko. Je me suis pour cela fié à ce que m'a expliqué Jipe sur cet octet

Ensuite il concatene les 128 fichiers de 64ko ainsi générés dans un seul fichier de 8mo/64mb.


Pour faire ça j'ai utilisé un petit programmateur fait maison à base d'ESP32 :


Je n'ai pas mis le code ici mais s'il vous intéresse,je peux au moins en mettre des bribes (il fait plus de 1000 lignes car ce prog me sert pour pleins de choses : concaténation,byte swap,prog de diverses flash et je le fais évoluer à chaque fois que j'ai un nouveau besoin comme ici ). J'attend de recevoir des écrans pour le rendre complètement autonome. En attendant j'utilise un moniteur série via USB pour contrôler la bonne exécution du programme.

La flash programmée ici est une 29w640 (8mo/64mb) que j'ai monté sur un petit adaptateur maison :




Et enfin la carte principale :



comme la flash est en 3V il y a des lvc245A pour convertir les signaux 5V en 3.3V et un regulateur 3.3V.

Les switchs sont reliés aux pins d'adresses A16 à A22 soit 7 switchs pour 128 possibilités, ainsi la flash est simplement découpée en 128 banks.

Le proto a été assemblé hier

Ça semble très bien marcher :



(dsl pour l'encombrement,il va falloir que je trouve une place digne de ce nom aux MSX :)

Reste à tester tous les jeux pour s'assurer que le systeme marche sur tous les types de jeux jusqu'à 64ko , ce quelle que soit leur configuration.

On est très loin de tout ce qui existe c'est sur et il n'y a rien ici d'exceptionnel par rapport à tous les projets que j'ai vu sur le forum.

Mais ça m'a permit de voir que les vrais bons jeux font presque tous au moins 128Ko donc on va attaquer les mappers . En route vers une carte universelle de développement, ce n'est que le début :) .

Si un expert comme Jipe par exemple :) voulait bien faire office de beta testeur, je veux bien envoyer quelques cartes. J'attend juste de recevoir mes écrans pour que le programmateur soit complètement autonome.

Bonne journée à tous
   
Bastion Rebel Membre non connecté

Conseiller Municipal

Rang

Avatar

Groupe : Shoutbox

Inscrit le : 21/09/2013 à 07h42

Messages: 1302

Le 04/12/2020 à 06h58
salut super !!!

explique un peu la partie arduino ...ca m'interresse :top :top :top


TURBO-R FS-A1ST 512/128ko MSX2+ NMS 8250 F4 /Fix Audio /Ram 1/4Mb VDP9958 VRAM 192ko 2FDD SANYO WAVY PHC35J MSX2 NMS 8280 Ram 4Mb VDP9938 VRAM 192ko 2FDD NMS 8250 128/128ko 2FDD VG8235/39 128/128ko 1FDD SONY HB-F700D MSX1 MC810 32/16k VG 8020 64k HB75F 64k HX-22 64k RS232/ CX5M 32k HB501F EXT : My Exp 4X/[b] MegaFlashSCC 512ko/BERT R2/BEER CF/SUNRISE 2CF/FUNRICE V2.01/MAXIOL/MEGASCSI HDD-CD/SDMSX 1SD/FMPAC SRAM/NMS1205+1160/RS 232 Harukaze/GR8NET/DOS2/ HOMER V2 RAM512ko/Floppy Pack/MAXduino/ROM1664/FM Pak /GR8NET /AMIGA/ PC/ RaspB Pi(B) / ARDUINO
E-mail    
yabikoo33 Membre non connecté

Vagabond

Rang

Avatar

Inscrit le : 14/11/2020 à 17h25

Messages: 18

Le 04/12/2020 à 09h25
Salut , je vais essayer de résumer le code et de le commenter. J'oubliais,il génère aussi un fichier CSV pour me résumer les switchs correspondant à chaque jeu .

Voici une version simplifiée de la fonction,soit juste la partie qui :
- Ouvre un fichier
- Décale les datas si le 4eme octet n'est pas à 0x00h
- ajoute des 0xFFh si nécessaire à la fin pour que le nouveau fichier rentre pile poil dans une bank de 64Ko quelle que soit la taille du jeu (8ko,16ko,32,64 ou tout autre) .
-et enfin concatene les 128 fichiers de 64ko en un seul de 8mo/64mb.

Je précise que j'ai programmé cette fonction hier rapidement, elle n'est pas optimale ni très bien codée,mais ça marche :

Code CPP :
 
void msxconcatenation(){
 
        // Le fichier concaténé s'appellera fic.bin,s'il existe déjà on le supprime
        if(SD.exists("/fic.bin")){SD.remove("/fic.bin");Serial.println("suppression du fic.bin existant");}
 
 
        File track = SD.open("/fic.bin",FILE_WRITE); // On créé le fichier contenant la concaténation
 
        File msxdir = SD.open("/msx"); // les fichiers à concaténer sont dans le répertoire /msx
 
 
 
         byte gamescount = 0; //variable pour s'assurer qu'on ne dépasse pas les 128 jeux
        File msxgame = msxdir.openNextFile(); msxgame va prendre tour à tour la valeur de chacune des roms
        unsigned int countfilesize = 0;
        while(msxgame = msxdir.openNextFile()){ // Une boucle pour ouvrir les jeux un par un
          if(gamescount<128  && !msxgame.isDirectory() && (msxgame.size()<=65536)){ // si tout est ok
 
              uint8_t datasd[4];     // on va traiter les datas du fichier 4 octets par 4 octets
              const uint8_t memoriseoctet[4]={255,255,255,255}; // 4 octets de FF pour faire du remplissage en cas de besoin
              bool firstlaunch = true;  // au premier lancement de la boucle ci-dessous on va vérifier l'octet 4 et ne le faire
                                                   // qu'une seule fois
              unsigned int provicompte = 0; // pour compter les octets du fichier,cette variable est reinitialisée pour chaque
                                                            // nouvelle rom
              while(msxgame.read(datasd,sizeof(datasd)) && provicompte < 65536){ // tant qu'il y a des datas à lire dans le
                                                                  //fichier,on les envoi dans data à chaque passage dans la boucle
 
                            if(firstlaunch == true){ // Pour les 4 premiers octets uniquement
                                 int decal = datasd[3] * 0x100; // on lit la valeur du 4eme octet et la multiplie par 0x100h
                                 if(decal>0){
                                 provicompte = 4;   
 
                                 track.write(datasd,sizeof(datasd)); // on écrit quoi qu'il en soit sur les 4 1ers octets dans fic.bin
                                 countfilesize = countfilesize + 4;
 
                                       while(provicompte < decal){ // On remplit avec des 0xFFh l'espace de décalage (par exemple
                                                                                  // 0x4000h ou 0x8000h
                                             track.write(memoriseoctet,sizeof(memoriseoctet));// on écrit 4 octets par 4 octets
                                             countfilesize = countfilesize + 4; // et on incrémente 4 octets par 4 octets
                                             provicompte = provicompte + 4;
                                       }
                                 }
                            }
                            // Maintenant qu'on a fait le décalage nécessaire,on écrit les données
                            track.write(datasd,sizeof(datasd));
                            countfilesize = countfilesize + 4;
                            provicompte = provicompte + 4;
                            firstlaunch = false;
              }
             // On a fini d'écrire le code du fichier; si la nouvelle bank générée ne fait pas encore 65536 octets,
             // On la remplie de 0xFFh jusqu'à ce qu'elle soit à la bonne taille
              if(provicompte < 65536){
                while(provicompte < 65536){
                     track.write(memoriseoctet,sizeof(memoriseoctet));
                     countfilesize = countfilesize + 4;
                     provicompte = provicompte + 4;
                }
              }
 
              gamescount++;  // On va passer au jeu suivant dans la boucle
          }
        }
 
        Serial.print(gamescount);Serial.println(" jeux concatenes   "); // C'est fait 
}
 

Edité par yabikoo33 Le 04/12/2020 à 14h12
   
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie