L'école Description du Memory Mapper (pour les programmeurs)
Question aux spécialistes:
Imaginons que le SLOT x est étendu et que dans un des subslot on a la RAM (mapper ou non).
Quand j'écris FF à l'adresse FFFF, j'écris dans le registre subslot mais aussi dans la RAM.
Quand le lis le registre subslot maintenant la RAM va déposé sur le bus de donnée FF, mais le registre subslot lui va déposer 00.
Du coup n'y a-t-il pas un un risque de peter la RAM avec se conflit de bus?
Je n'ai pas vu de mécanisme de protection pour ne pas activer le CS de la RAM en cas d'écriture à l'adresse FFFF.
Imaginons que le SLOT x est étendu et que dans un des subslot on a la RAM (mapper ou non).
Quand j'écris FF à l'adresse FFFF, j'écris dans le registre subslot mais aussi dans la RAM.
Quand le lis le registre subslot maintenant la RAM va déposé sur le bus de donnée FF, mais le registre subslot lui va déposer 00.
Du coup n'y a-t-il pas un un risque de peter la RAM avec se conflit de bus?
Je n'ai pas vu de mécanisme de protection pour ne pas activer le CS de la RAM en cas d'écriture à l'adresse FFFF.
TurboR GT (1Mo), CANON V20! ( en kit, modif 2+ en cours)
Pas encore retrouvés: V9990, Grafx9000, SUNRISE IDE 2x CF, SUNRISE MOONSOUND, FM PAC, MUSIC MODULE, NMS8280, SD SNATCHER,...
Lorsqu'un Slot primaire est étendu, une écriture à cette adresse écrit l'octet dans le registre des Slots secondaires (du Slot primaire corespondant), la RAM n'est plus accessible à cette adresse.
Une lecture à cette adresse donnera l'état des Slots secondaires en bits inversés (donc un XOR 255 est nécessaire pour avoir la bonne valeur). Il n'y a pas de conflit possible.
Au niveau hardware, peut-être que Jipé peut répondre. Edité par GDX Le 09/08/2014 à 16h06
Une lecture à cette adresse donnera l'état des Slots secondaires en bits inversés (donc un XOR 255 est nécessaire pour avoir la bonne valeur). Il n'y a pas de conflit possible.
Au niveau hardware, peut-être que Jipé peut répondre. Edité par GDX Le 09/08/2014 à 16h06
Concrètement, est-il possible de mettre 2 Mappers cartouche 4096ko (le max tant qu'a faire 
) dans chaque port cartouche avec le Mapper interne ramené a 4096ko et de bourré alternativement de donné ces Ram afin de pouvoir lire ,en selectionnant alternativement les Mappers , de grosses quantité de données?
Si oui, existe t-il des programmes pour cela? Ou ca reste a inventé?
Le fait de passer d'un bloc Mapper 4096ko a l'autre provoquera-t-il un plantage du MSX?
Meme si c'est certainement deja possible avec les interfaces CF ou un peu moin avec du SD , mais est-ce faisable avec des Mappers gérer en parallèle ? (meme si c'est pas forcement utile face des interfaces type CF/SD)
Je ne pensse pas forcement a une utilisation pour du EVA ou du MP3, mais une gestion du plus gros Mapper possible sectionner en 3 ou 4x4096ko pour avoir de gros fichiers.
Par exemple, sur un MSX2/2+ Edité par TurboSEB Le 09/08/2014 à 17h17
) dans chaque port cartouche avec le Mapper interne ramené a 4096ko et de bourré alternativement de donné ces Ram afin de pouvoir lire ,en selectionnant alternativement les Mappers , de grosses quantité de données? Si oui, existe t-il des programmes pour cela? Ou ca reste a inventé?
Le fait de passer d'un bloc Mapper 4096ko a l'autre provoquera-t-il un plantage du MSX?
Meme si c'est certainement deja possible avec les interfaces CF ou un peu moin avec du SD , mais est-ce faisable avec des Mappers gérer en parallèle ? (meme si c'est pas forcement utile face des interfaces type CF/SD)
Je ne pensse pas forcement a une utilisation pour du EVA ou du MP3, mais une gestion du plus gros Mapper possible sectionner en 3 ou 4x4096ko pour avoir de gros fichiers.
Par exemple, sur un MSX2/2+ Edité par TurboSEB Le 09/08/2014 à 17h17
MSX 1&2 + Moniteurs+divers (environ 0.70Tonnes)
Il existe déjà des extensions qui comportent plusieurs Memory Mapper, par exemple la cartouche Playsoniq.
Jusqu'à maintenant, à ma connaissance, seuls l'MSX-DOS 2 et l'MSX-View savent gérer plusieurs Memory Mapper. L'MSX-DOS 2 ne fait qu'ajouter quelques règles pour gérer les Mapper. Le développeur doit quand même se débrouiller lui-même pour son programme.
En pratique, avoir plusieurs Mapper sur MSX, ça ne sert pratiquement pas. Une interface HDD, CF ou SD est obligatoire pour tout charger en RAM suffisamment rapidement dans la RAM mais comme ce genre d'interface est suffisamment rapide pour charger au fur et à mesure du déroulement du programme autant faire comme ça, c'est plus simple.
Je me demande même si pour du EVA ou du MP3, le fait de gérer plusieurs Mapper n'est pas pénalisant. Edité par GDX Le 10/08/2014 à 01h31
Jusqu'à maintenant, à ma connaissance, seuls l'MSX-DOS 2 et l'MSX-View savent gérer plusieurs Memory Mapper. L'MSX-DOS 2 ne fait qu'ajouter quelques règles pour gérer les Mapper. Le développeur doit quand même se débrouiller lui-même pour son programme.
En pratique, avoir plusieurs Mapper sur MSX, ça ne sert pratiquement pas. Une interface HDD, CF ou SD est obligatoire pour tout charger en RAM suffisamment rapidement dans la RAM mais comme ce genre d'interface est suffisamment rapide pour charger au fur et à mesure du déroulement du programme autant faire comme ça, c'est plus simple.
Je me demande même si pour du EVA ou du MP3, le fait de gérer plusieurs Mapper n'est pas pénalisant. Edité par GDX Le 10/08/2014 à 01h31
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie