La Place des Développeurs Dev emulateur Minitel
Reprise du message précédent
Je pars du principe que tu as suivi le tuto pour la création d'un projet sur MSXgl.
Dans MSXgl, tu dois configurer la libraire pour l'émulateur que tu souhaites utiliser pour communiquer (malheureusement, ils n'utilisent pas tous le même système).
Tu dois éditer ton fichier de configuration de la librairie (msxgl_config.h) :
Code C :
//----------------------------------------------------------------------------- // DEBUG //----------------------------------------------------------------------------- // Debugger options // - DEBUG_DISABLE ................ No debug tool // - DEBUG_EMULICIOUS ............. Debug features for Emulicious // - DEBUG_OPENMSX ................ Debug features for openMSX using 'debugdevice' extension // - DEBUG_OPENMSX_P .............. Debug features for openMSX using PVM script (tools/script/openMSX/debugger_pvm.tcl) #define DEBUG_TOOL DEBUG_OPENMSX_P // <---- Change ici ! // Profiler options // - PROFILE_DISABLE .............. No profile tool // - PROFILE_OPENMSX_G ............ Profiler features for openMSX using Grauw script (tools/script/openMSX/profiler_grauw.tcl) // - PROFILE_OPENMSX_S ............ Profiler features for openMSX using Salutte script (tools/script/openMSX/profiler_salutte.tcl) #define PROFILE_TOOL PROFILE_DISABLE #define PROFILE_LEVEL 10
Ensuite, tu dois ajouter le module de Debug dans la liste des modules de ton projet.
Pour ça édite la configuration de ton projet (project_config.js) et ajoute "debug" dans la liste LibModules.
Par ex. :
Code JAVASCRIPT :
//-- List of library modules to build (array) LibModules = [ "debug", "system", "bios", "vdp", "print", "input", "memory" ];
Maintenant tu peux utiliser toutes les fonctions qui commence par DEBUG dans https://aoineko.org/msxgl-doc/#File:debug.h
Pour tester dans openMSX, le plus simple c'est de configurer MSXgl pour qu'il démarre automatiquement l'émulateur à la fin du build.
Dans ce cas, openMSX sera ouvert avec toutes les options qui vont bien (et notamment le script TLC sera automatiquement chargé).
Pour ça, il faut changer quelques options dans la configuration de ton projet (project_config.js) :
Code JAVASCRIPT :
// Pour forcer l'au-démarrage de l'émulateur: DoRun = true; //-- Start the program automatically at the end of the build (boolean) // Pour indiquer l'emplacement de l'émulateur (c'est le nom du fichier à exécuter mais tu peux omettre le .EXE): Emulator = `c:/ton_chemin/openMSX/openmsx`; //-- Path to the emulator to launch the project (string)
Enfin, pour la question de savoir où c'est affiché dans openMSX... et bien j'en ai aucune idée depuis qu'ils ont changé leur interface.
Je vais regarder... Edité par aoineko Le 04/01/2025 à 21h54
On est toujours ignorant avant de savoir.
@aoineko
Merci pour ton aide!
Oui, j'avais lu le tuto ! mais visiblement pas le fichier msxgl_config.h jusqu'au bout du bout.
J'ai donc modifié comme indiqué :
Alors, c'est mieux : si je place un
En revanche,
Bon, en tout cas, ca avance !
Merci pour ton aide!
Oui, j'avais lu le tuto ! mais visiblement pas le fichier msxgl_config.h jusqu'au bout du bout.
J'ai donc modifié comme indiqué :
Code :
#define DEBUG_TOOL DEBUG_OPENMSX_P
Alors, c'est mieux : si je place un
Code :
, ca fait bien un break.
DEBUG_BREAK()
En revanche,
Code :
affiche dans la fenêtre "Message log" de openMSX (ca semble s'affiche là donc), 4 jolis messages : "Warning: invalid address"
DEBUG_LOG("xxxxxxxx");
Bon, en tout cas, ca avance !
Ajoute ce paramètre dans la configuration de ton projet (project_config.js) :
Les explications, sont ici : https://aoineko.org/msxgl/index.php?title=Modules/debug#openMSX
Tu peux tester avec le projet Example en mettant DEBUG_TOOL à DEBUG_OPENMSX_P dans la configuration de la librairie (msxgl_config.h).
Comme on dit « chez moi, ça marche ».
Edité par
aoineko
Le 04/01/2025 à 22h18
Code JAVASCRIPT :
//-- Emulator extra parameters to be add to command-line (string). Emulator sotfware specific EmulExtraParam = `-script ${ToolsDir}script/openMSX/debugger_pvm.tcl`;
Les explications, sont ici : https://aoineko.org/msxgl/index.php?title=Modules/debug#openMSX
Tu peux tester avec le projet Example en mettant DEBUG_TOOL à DEBUG_OPENMSX_P dans la configuration de la librairie (msxgl_config.h).
Comme on dit « chez moi, ça marche ».
Edité par
aoineko
Le 04/01/2025 à 22h18
On est toujours ignorant avant de savoir.
Bon, j'ai pas mal cherché et me suis pris pas mal la tête !
Jusqu'à réinstaller SDCC avec la version que tu préconises sur ton site (4.2) et OpenMSX !
J'ai essayé le debug avec le fichier d'exemple : ca fonctionne effectivement !
J'ai fait un mini test comme cela, le truc basique de chez basique :
ca ne marchait pas, avec les fichiers de config de mon projet.
Donc j'ai bien cherché et il s'avère que ton exemple cré un ROM 32K.
Le mien, c'est un programme MSX-DOS 1.
Et ce qui pose problème et qui fait que le debug déconne complètement c'est lorsque j'ajoute l'extension -ext Mitsubishi_ML-30DC_ML-30FD
Le même soucis se produit avec ton exemple si on ajoute cette extension.
Est-ce normal que le debug ne fonctionne pas si cette extension est activée (pareil avec d'autres extension pour un floppy disk)?
Ou y a t il (encore) un truc que j'ai zappé ? (possible !)
Edité par ludojoey Le 05/01/2025 à 00h50
Jusqu'à réinstaller SDCC avec la version que tu préconises sur ton site (4.2) et OpenMSX !
J'ai essayé le debug avec le fichier d'exemple : ca fonctionne effectivement !
J'ai fait un mini test comme cela, le truc basique de chez basique :
Code :
void main() {
DEBUG_INIT();
DEBUG_BREAK();
DEBUG_LOG("Start debug");
DEBUG_LOG("Start debug fin");
}
ca ne marchait pas, avec les fichiers de config de mon projet.
Donc j'ai bien cherché et il s'avère que ton exemple cré un ROM 32K.
Le mien, c'est un programme MSX-DOS 1.
Et ce qui pose problème et qui fait que le debug déconne complètement c'est lorsque j'ajoute l'extension -ext Mitsubishi_ML-30DC_ML-30FD
Le même soucis se produit avec ton exemple si on ajoute cette extension.
Est-ce normal que le debug ne fonctionne pas si cette extension est activée (pareil avec d'autres extension pour un floppy disk)?
Ou y a t il (encore) un truc que j'ai zappé ? (possible !)
Edité par ludojoey Le 05/01/2025 à 00h50
La communication de débug avec openMSX se fait via les ports I/O 2Eh et 2Fh. A moins que l'extension que tu ajoutes utilise les mêmes ports I/O, ça ne devrait avoir aucune incidence. Je vais tester.
Aussi, note que SDCC 4.2.0 est inclu dans le package MSXgl donc tu n'as rien à installer de plus. Edité par aoineko Le 05/01/2025 à 11h30
Aussi, note que SDCC 4.2.0 est inclu dans le package MSXgl donc tu n'as rien à installer de plus. Edité par aoineko Le 05/01/2025 à 11h30
On est toujours ignorant avant de savoir.
Alors, d'après mes tests, tout fonctionne bien avec le projet Example en mode MSX-DOS 1.
Peut-être que ton problème vient du fait que tu utilises les machines CBIOS.
Pour la petite histoire, openMSX n'est fournis avec aucune ROM système pour des raisons légales.
Ils utilisent donc par défaut les BIOS du projet open source CBIOS qui malheureusement ne supporte pas encore les disques.
Pour que de base MSXgl fonctionne avec la version de openMSX de base, c'est CBIOS qui est sélectionné quand tu active l'option EmulMachine dans la configuration de ton projet (project_config.js), qui permet de sélectionner la génération de MSX qui s'adapte à ton choix pour ton projet.
Pour utiliser l'extension Mitsubishi_ML-30DC_ML-30FD, je te conseil cette configuration :
Et dans openMSX, tu séléctionnes une machine MSX1 sans disque comme le Canon V20 par ex. :
Pour plus d'infos sur les ROMs systèmes : https://aoineko.org/msxgl/index.php?title=Emulators#openMSX
Avec ça, le projet Example se lance bien sur un MSX1 en mode MSX-DOS1.
Petite astuces : Tu peux build le project Example (idem pour les Template) en mettant le nom du média cible dans la ligne de commande. Par ex.
- ROM de 32 KB : build ROM_32K
- Programme MSX-DOS 1 : build DOS
- Programme disque BASIC : build BIN_DISK
- Programme cassette BASIC : build BIN_TAPE
- Etc. (voir la liste des médias) Edité par aoineko Le 05/01/2025 à 12h12
Peut-être que ton problème vient du fait que tu utilises les machines CBIOS.
Pour la petite histoire, openMSX n'est fournis avec aucune ROM système pour des raisons légales.
Ils utilisent donc par défaut les BIOS du projet open source CBIOS qui malheureusement ne supporte pas encore les disques.
Pour que de base MSXgl fonctionne avec la version de openMSX de base, c'est CBIOS qui est sélectionné quand tu active l'option EmulMachine dans la configuration de ton projet (project_config.js), qui permet de sélectionner la génération de MSX qui s'adapte à ton choix pour ton projet.
Pour utiliser l'extension Mitsubishi_ML-30DC_ML-30FD, je te conseil cette configuration :
Code JAVASCRIPT :
//-- Force the MSX version of the emulated machine (boolean) EmulMachine = false; //-- Emulator extra parameters to be add to command-line (string). Emulator sotfware specific EmulExtraParam = `-ext Mitsubishi_ML-30DC_ML-30FD -script ${ToolsDir}script/openMSX/debugger_pvm.tcl`;
Et dans openMSX, tu séléctionnes une machine MSX1 sans disque comme le Canon V20 par ex. :
Machine > Select MSX Machine... > Canon V20 (FR) > Replace current machine > Make this the the default machine
Pour plus d'infos sur les ROMs systèmes : https://aoineko.org/msxgl/index.php?title=Emulators#openMSX
Avec ça, le projet Example se lance bien sur un MSX1 en mode MSX-DOS1.
Petite astuces : Tu peux build le project Example (idem pour les Template) en mettant le nom du média cible dans la ligne de commande. Par ex.
- ROM de 32 KB : build ROM_32K
- Programme MSX-DOS 1 : build DOS
- Programme disque BASIC : build BIN_DISK
- Programme cassette BASIC : build BIN_TAPE
- Etc. (voir la liste des médias) Edité par aoineko Le 05/01/2025 à 12h12
On est toujours ignorant avant de savoir.
Merci @aoineko , là le debug marche comme ca doit sous MSX-DOS1 !
Oui, pour le ROMs je savais, mais ce que je ne savais pas c'était que CBIOS ne supporte pas les disques, et, il faut le dire, openMSX me parait être vraiment super, mais pas forcément intuitif.
Pas évident de commencer, avec tous ces petits tracas.
Mais je persiste !
Tu es d'une aide précieuse !
Oui, pour le ROMs je savais, mais ce que je ne savais pas c'était que CBIOS ne supporte pas les disques, et, il faut le dire, openMSX me parait être vraiment super, mais pas forcément intuitif.
Pas évident de commencer, avec tous ces petits tracas.
Mais je persiste !
Tu es d'une aide précieuse !
Hello!
Bon, désolé, je reviens encore à la charge !
Cela fait 2 jours que je galère sur l'accès au floppy (toujours sous MSX-DOS1).
J'ai une fonction qui parcours le répertoire à la recherche de fichier en ".vdt".
Le soucis : de manière aléatoire, l'appel à "DOS_FindFirstFileFCB" plante totalement : le système freeze complètement, ou parfois, va retourner n'importe quoi (genre 50 fichiers trouvés, avec des noms hasardeux..) ou redémarrer en boucle.
Quand je dis aléatoire, cela signifie que, pour une version compilée donnée, cela va fonctionner tout le temps.
Mais il suffit que je rajoute, par exemple, un "if" dans mon code (même dans un endroit qui ne sera pas exécuté), et ca plante...
Voici le code de la fonction (pas propre du tout [nom de variable en "g_" alors qu'elle est local, etc..), mais je fais des essais divers pour essayer de trouver le soucis !)
Lors d'une exécution qui plante, voici la sortie :
Pensant que c'est probablement un problème de mémoire, genre mes variables qui débordent sur le code, j'ai regardé le fichier .map pour voir si ca avait l'air d'aller au niveau de la pile, ce genre de truc.
Je n'ai vraiment pas l'habitude de fouiller la dedans à vrai dire, donc pas sûr de bien comprendre.
et
Lien vers le fichier Map complet
Je comprends que la pile se situe en 681C, c'est cela ?
Si vous avez une idée du soucis, elle est la bienvenue !
Edité par ludojoey Le 07/01/2025 à 12h38
Bon, désolé, je reviens encore à la charge !
Cela fait 2 jours que je galère sur l'accès au floppy (toujours sous MSX-DOS1).
J'ai une fonction qui parcours le répertoire à la recherche de fichier en ".vdt".
Le soucis : de manière aléatoire, l'appel à "DOS_FindFirstFileFCB" plante totalement : le système freeze complètement, ou parfois, va retourner n'importe quoi (genre 50 fichiers trouvés, avec des noms hasardeux..) ou redémarrer en boucle.
Quand je dis aléatoire, cela signifie que, pour une version compilée donnée, cela va fonctionner tout le temps.
Mais il suffit que je rajoute, par exemple, un "if" dans mon code (même dans un endroit qui ne sera pas exécuté), et ca plante...
Voici le code de la fonction (pas propre du tout [nom de variable en "g_" alors qu'elle est local, etc..), mais je fais des essais divers pour essayer de trouver le soucis !)
Code :
u8 EMX_getFileList(c8 *fileList) {
DOS_FCB fcb;
u8 g_Buftmp[128];
DEBUG_PRINT("addrfilelist2=%x\n",(u16) fileList);
DEBUG_PRINT("addrfcb=%x\n",(u16) &fcb);
DEBUG_PRINT("addrbuf=%x\n",(u16) &g_Buftmp);
DEBUG_PRINT("size fcb=%d\n",sizeof(DOS_FCB));
Mem_Set(0, &fcb, sizeof(DOS_FCB));
Mem_Copy("????????VDT", &fcb.Name, 11);
DEBUG_LOG("memcopy ok\n");
DOS_SetTransferAddr(&g_Buftmp);
DEBUG_LOG("settransfert ok\n");
g_I = DOS_FindFirstFileFCB(&fcb);
DEBUG_LOG("findfirst ok\n");
if(g_I == DOS_SUCCESS)
{
Mem_Copy(&g_Buftmp+1,(c8 *)fileList,11);
*(fileList+11) = 0;
g_I = 1;
while(DOS_FindNextFileFCB() == DOS_SUCCESS) {
Mem_Copy(&g_Buftmp+1,(c8 *)(fileList+(12*g_I)),11);
*(fileList+(12*g_I)+11) = 0;
g_I++;
}
}
DOS_CloseFCB(&fcb);
return g_I;
}
Lors d'une exécution qui plante, voici la sortie :
Code :
addrfilelist=d476
addrfilelist2=d476
addrfcb=d3cd
addrbuf=d3f2
size fcb=37
memcopy ok
settransfert ok
(Le système est alors planté)
Pensant que c'est probablement un problème de mémoire, genre mes variables qui débordent sur le code, j'ai regardé le fichier .map pour voir si ca avait l'air d'aller au niveau de la pile, ce genre de truc.
Je n'ai vraiment pas l'habitude de fouiller la dedans à vrai dire, donc pas sûr de bien comprendre.
Code :
.....
00000100 s__CODE
00000221 l__HOME
0000095E l__DATA
00005BEB l__CODE
00005CEB s__HOME
00005F0C s__INITIALIZER
00005F0C s__RODATA
00005F2F s__DATA
00005F2F s__GSFINAL
00005F2F s__GSINIT
0000688D s__INITIALIZED
000068B0 s__BSEG
000068B0 s__BSS
000068B0 s__HEAP
0000F30F G$g_KANJTABLE$0_0$0 bios
0000F30F _g_KANJTABLE bios
0000F323 G$g_DISKVE$0_0$0 bios
0000F323 _g_DISKVE bios
0000F325 G$g_BREAKV$0_0$0 bios
0000F325 _g_BREAKV bios
0000F341 G$g_RAMAD0$0_0$0 bios
0000F341 _g_RAMAD0 bios
0000F342 G$g_RAMAD1$0_0$0 bios
0000F342 _g_RAMAD1 bios
0000F343 G$g_RAMAD2$0_0$0 bios
0000F343 _g_RAMAD2 bios
0000F344 G$g_RAMAD3$0_0$0 bios
0000F344 _g_RAMAD3 bios
0000F348 G$g_MASTER$0_0$0 bios
0000F348 _g_MASTER bios
0000F37D G$g_BDOS$0_0$0 bios
0000F37D _g_BDOS bios
0000F380 G$g_RDPRIM$0_0$0 system
0000F380 _g_RDPRIM system
0000F385 G$g_WRPRIM$0_0$0 system
0000F385 _g_WRPRIM system
0000F38C G$g_CLPRIM$0_0$0 system
0000F38C _g_CLPRIM system
....
et
Code :
0000681C G$g_StackAddress$0_0$0 memory
0000681C _g_StackAddress memory
Lien vers le fichier Map complet
Je comprends que la pile se situe en 681C, c'est cela ?
Si vous avez une idée du soucis, elle est la bienvenue !
Edité par ludojoey Le 07/01/2025 à 12h38
ludojoey :
Je comprends que la pile se situe en 681C, c'est cela ?
Non, c'est une variable alloué en RAM (en mode DOS, les variables sont allouées juste après le programme) qui permet de récupérer l'adresse actuelle de la pille via la fonction Mem_GetStackAddress().
Mais si tu es sur émulateur, le plus simple c'est de regarder la valeur du registre SP.
Dans le fichier .MAP, l'espace des variables commence à la section _DATA (dans ton exemple c'est 0x5F2F).
Pour en revenir à ton problème, si j'ai bien compris, d'une build à l'autre tu as soit un programme qui fonctionne à 100%, soit qui crash à 100% ; c'est bien ça ?
La fonction DOS_FindFirstFileFCB() n'est qu'un wrapper vers un appel au BDOS.
Code C :
u8 DOS_FindFirstFileFCB(FCB* stream) { stream; // HL __asm push ix // FCB pointer ex de, hl ld c, #DOS_FUNC_SFIRST call BDOS ld (_g_DOS_LastError), a pop ix __endasm; }
Il y a 2 options :
- Soit la fonction BDOS peut crasher si on lui donne une valeur d'entrée invalide (l'adresse du FCB) ; ça me semble assez probable vu que le BDOS peut écrire dedans, mais c'est facile à tester en exécutant ce code :
Code C :
for(u16 i = 0; i <= 0xFFFF; i++) DOS_FindFirstFileFCB((FCB*)i);
- Soit il y a eu un écrasement mémoire sur la zone de travail du BDOS avant l'appel. La table de saut du BDOS se trouve à l'adresse 0x0005. C'est moins simple à tester.
Ça ne devrait pas poser de soucis, mais tu devrais essayer d'allouer tes tableaux (FCB et buffer) en dehors de ta fonction.
Je n'alloue jamais de tableau dans les fonctions pour des raisons de performance (le compilateur se met à utiliser les registres d'index IX et IY qui sont très lents) donc c'est possible qu'il y ait des soucis que je ne connais pas.
Si ça corrige ton bug, j'essayerai de le reproduire pour voir comment cela pourrait être corrigé.
Voilà pour les idées pour le moment.
Edité par
aoineko
Le 07/01/2025 à 13h30
On est toujours ignorant avant de savoir.
Merci pour ton aide.
Malheureusement, là, je n'arrive pas à m'en dépêtrer, malgré encore une journée à chercher...
J'ai repassé mes variables en globales (mais je savais que cela ne changerai rien, car, à la base, elles étaient globales avant que je les mette en local "pour voir" si cela changerai quelque chose.)
J'ai viré le module "game", dont je n'avais pas vraiment besoin de toutes façons.
Je n'ai plus de plantage (pour le moment), mais impossible d’accéder au floppy (DOS_FindFirstFileFCB() renvoi 0xFF)
J'ai vidé mon programme de toutes ses fonctions, jusqu'à ce que le soucis se produise.
Arrivé à un certain point juste le fait de rajouter un ligne, par exemple un simple i=0 dans une fonction qui n'est même pas appelée fait que DOS_FindFirstFileFCB() renvoi 0xFF (appelé dès le départ dans le main()), avant toute chose).
En faisant des essais cet après-midi sur bout de code qui posait un soucis similaire celui c'est résolu en ajoutant comme option de compilation --max-allocs-per-node 5000
En mettant cette même option à mon programme principal, cela n'a malheureusement pas résolu le soucis (à part qu'avant de mettre cette option j'avais le droit à un beau message "Insert floppy in drive B" (ou similaire) lors de l'appel à DOS_FindFirstFileFCB() [je précise que je n'ai pas de drive B...], alors que maintenant j'ai seulement le 0xFF en retour...
Bon, de toutes façons je pars en déplacement demain, cela me fera une pause je crois !
J'ai le sentiment que cela est inextricable !
Malheureusement, là, je n'arrive pas à m'en dépêtrer, malgré encore une journée à chercher...
J'ai repassé mes variables en globales (mais je savais que cela ne changerai rien, car, à la base, elles étaient globales avant que je les mette en local "pour voir" si cela changerai quelque chose.)
J'ai viré le module "game", dont je n'avais pas vraiment besoin de toutes façons.
Je n'ai plus de plantage (pour le moment), mais impossible d’accéder au floppy (DOS_FindFirstFileFCB() renvoi 0xFF)
J'ai vidé mon programme de toutes ses fonctions, jusqu'à ce que le soucis se produise.
Arrivé à un certain point juste le fait de rajouter un ligne, par exemple un simple i=0 dans une fonction qui n'est même pas appelée fait que DOS_FindFirstFileFCB() renvoi 0xFF (appelé dès le départ dans le main()), avant toute chose).
En faisant des essais cet après-midi sur bout de code qui posait un soucis similaire celui c'est résolu en ajoutant comme option de compilation --max-allocs-per-node 5000
En mettant cette même option à mon programme principal, cela n'a malheureusement pas résolu le soucis (à part qu'avant de mettre cette option j'avais le droit à un beau message "Insert floppy in drive B" (ou similaire) lors de l'appel à DOS_FindFirstFileFCB() [je précise que je n'ai pas de drive B...], alors que maintenant j'ai seulement le 0xFF en retour...
Bon, de toutes façons je pars en déplacement demain, cela me fera une pause je crois !
J'ai le sentiment que cela est inextricable !
Si tu peux partager ton projet (GitHub par ex.), je peux jeter un œil.
A mon avis c'est pas grand chose... mais quoi...
Tu peux aussi me contacter sur Discord : https://discord.gg/C4A2kRzE9F Edité par aoineko Le 07/01/2025 à 20h46
A mon avis c'est pas grand chose... mais quoi...
Tu peux aussi me contacter sur Discord : https://discord.gg/C4A2kRzE9F Edité par aoineko Le 07/01/2025 à 20h46
On est toujours ignorant avant de savoir.
Hello!
Voici un premier (enfin, Xième !) jet de mon projet, à savoir un émulateur Minitel pour MSX1 (avec toutes ses contraintes quant au graphisme !)
La première étape est donc de pouvoir afficher plus ou moins correctement des fichiers videotex, à la norme CEPT2.
Pas facile, sachant qu'un écran videotex est composé de 25 lignes de 40 caractères de 8 pixels X 8 pixels, pour une résolution de 320 x 200, avec 2 couleurs parmi 8 par caractère.
Et scrolling vertical haut et bas pris en charge ainsi que les caractères double hauteur, double largeur et double taille.
Bref, pas du tout la résolution d'un MSX 1, c'est le challenge !
Deux possibilités s'offraient : afficher uniquement des lignes de 32 caractères et proposer un scrolling horizontal pour voir les 8 caractères manquants.
Ou redéfinir l'écran pour obtenir 40 caractères de 6 pixels de large.
J'ai choisi la deuxieme solution, la plus complexe !
Donc, les caractères sont de 6 pixels de large x 8 pixels de haut et dessinés "à cheval" entre chaque tuile avec un décalage variable cyclique.
Et les couleurs doivent suivre (comme elles peuvent !), avec la contrainte du Screen2 de 2 couleurs par ligne 8 pixels !
L'écran est donc de 40 caractères sur 24 lignes (et non 25 comme sur un minitel : la ligne 00 (celle du haut) est affiché en ligne 1).
J'ai repris la police de caractères des vrais minitels.
Voici le résultat pour le moment, soyez indulgent c'est mon premier projet (hors programmes en Basic en 1985) sur MSX (et même sur n'importe quel vieille machine !) :
Video Eminex 0.0.1
Alors, l'émulation est je pense correcte à 75%.
Plus la page est chargée en graphisme "complexes", plus cela est difficile pour obtenir un affichage correct.
On ne peut parfois (souvent) pas obtenir l'affichage comme on désirerai du aux contraintes de l'ordi.
Certaines choses ne sont pas émulées, pour le connaisseurs : séquences CSI, masquage, DRCS,...
Tout comme le clignotement, hors de portée je pense !
Le scrolling serait à revoir, tout comme la propagation des couleurs de fond et du soulignement ! (ca ne vous dit peut-être rien, mais bon !)
Tout comme une optimisation de la vitesse d'affichage (mettre toutes mes variables en globale serait parait-il bon pour cela...)
Je suis relativement content car le résultat est un affichage somme toute tout à fait utilisable.
Le prochaine étape (hormis optimiser ce qui est déjà fait), est la partie connexion.
Pour cela je pense utiliser la cartouche modem BadCat Wifi que j'ai.
Si j'arrive à obtenir une connexion telnet avec mon serveur, cela sera alors parfait !
Edité par ludojoey Le 15/01/2025 à 13h50
Voici un premier (enfin, Xième !) jet de mon projet, à savoir un émulateur Minitel pour MSX1 (avec toutes ses contraintes quant au graphisme !)
La première étape est donc de pouvoir afficher plus ou moins correctement des fichiers videotex, à la norme CEPT2.
Pas facile, sachant qu'un écran videotex est composé de 25 lignes de 40 caractères de 8 pixels X 8 pixels, pour une résolution de 320 x 200, avec 2 couleurs parmi 8 par caractère.
Et scrolling vertical haut et bas pris en charge ainsi que les caractères double hauteur, double largeur et double taille.
Bref, pas du tout la résolution d'un MSX 1, c'est le challenge !
Deux possibilités s'offraient : afficher uniquement des lignes de 32 caractères et proposer un scrolling horizontal pour voir les 8 caractères manquants.
Ou redéfinir l'écran pour obtenir 40 caractères de 6 pixels de large.
J'ai choisi la deuxieme solution, la plus complexe !
Donc, les caractères sont de 6 pixels de large x 8 pixels de haut et dessinés "à cheval" entre chaque tuile avec un décalage variable cyclique.
Et les couleurs doivent suivre (comme elles peuvent !), avec la contrainte du Screen2 de 2 couleurs par ligne 8 pixels !
L'écran est donc de 40 caractères sur 24 lignes (et non 25 comme sur un minitel : la ligne 00 (celle du haut) est affiché en ligne 1).
J'ai repris la police de caractères des vrais minitels.
Voici le résultat pour le moment, soyez indulgent c'est mon premier projet (hors programmes en Basic en 1985) sur MSX (et même sur n'importe quel vieille machine !) :
Video Eminex 0.0.1
Alors, l'émulation est je pense correcte à 75%.
Plus la page est chargée en graphisme "complexes", plus cela est difficile pour obtenir un affichage correct.
On ne peut parfois (souvent) pas obtenir l'affichage comme on désirerai du aux contraintes de l'ordi.
Certaines choses ne sont pas émulées, pour le connaisseurs : séquences CSI, masquage, DRCS,...
Tout comme le clignotement, hors de portée je pense !
Le scrolling serait à revoir, tout comme la propagation des couleurs de fond et du soulignement ! (ca ne vous dit peut-être rien, mais bon !)
Tout comme une optimisation de la vitesse d'affichage (mettre toutes mes variables en globale serait parait-il bon pour cela...)
Je suis relativement content car le résultat est un affichage somme toute tout à fait utilisable.
Le prochaine étape (hormis optimiser ce qui est déjà fait), est la partie connexion.
Pour cela je pense utiliser la cartouche modem BadCat Wifi que j'ai.
Si j'arrive à obtenir une connexion telnet avec mon serveur, cela sera alors parfait !
Edité par ludojoey Le 15/01/2025 à 13h50
Bravo pour le résultat qui ressemble beaucoup au Minitel (dans mon souvenir en tout cas ) alors qu'effectivement un écart de résolution de 320 à 256 pixels est un énorme défi ! 
Mais du coup, tu réinterprètes en temps réel les blocs 8x8 du format video-text en blocs 6x6 ?
Tu skip toujours les 2 mêmes colonnes et lignes, ou tu fais en fonction du contenu du bloc ?
Quand tu en seras à l'optimisation, je pourrais surement t'aider ; c'est ma spécialisation.
) alors qu'effectivement un écart de résolution de 320 à 256 pixels est un énorme défi ! Mais du coup, tu réinterprètes en temps réel les blocs 8x8 du format video-text en blocs 6x6 ?
Tu skip toujours les 2 mêmes colonnes et lignes, ou tu fais en fonction du contenu du bloc ?
Quand tu en seras à l'optimisation, je pourrais surement t'aider ; c'est ma spécialisation.
On est toujours ignorant avant de savoir.
c'est très impressionnant aoineko :
Bravo pour le résultat qui ressemble beaucoup au Minitel (dans mon souvenir en tout cas ) alors qu'effectivement un écart de résolution de 320 à 256 pixels est un énorme défi !
Mais du coup, tu réinterprètes en temps réel les blocs 8x8 du format video-text en blocs 6x6 ?
Tu skip toujours les 2 mêmes colonnes et lignes, ou tu fais en fonction du contenu du bloc ?
Quand tu en seras à l'optimisation, je pourrais sûrement t'aider ; c'est ma spécialisation.
) alors qu'effectivement un écart de résolution de 320 à 256 pixels est un énorme défi ! Mais du coup, tu réinterprètes en temps réel les blocs 8x8 du format video-text en blocs 6x6 ?
Tu skip toujours les 2 mêmes colonnes et lignes, ou tu fais en fonction du contenu du bloc ?
Quand tu en seras à l'optimisation, je pourrais sûrement t'aider ; c'est ma spécialisation.
La hauteur de mes caractères est de 8 pixels, donc pas de soucis sur les lignes.
Ce sont les colonnes le soucis !
Oui, au fur et à mesure de la lecture du fichier (ou de la réception des données donc), s'il y a un caractère à afficher (car on peut lire ou réceptionner également des séquences de controles) celui-ci est dessiné à la volé. Sachant qu'il fait 6 pixels de large, le 1er caractère correspond à la colonne 0 de l'écran MSX, sans décalage. Le second, toujours la colonne 0 de l'écran MSX, mais avec un décalage de 6 vers la droite, et donc un "débordement" de 4 pixels sur la gauche de la colonne 1. Le troisième sera en colonne 1, avec décalage de 4 à droite et débordement de 4 sur la colonne 2, etc, etc...
Le plus gros défi ce sont bien sûr les couleurs, surtout lorsqu'il s'agit des caractères semi-graphiques.
Avec les décalage, j'ai 2 couleurs de fond et 2 couleurs d'avant plan et le caractère est à cheval entre 2 tuiles.
Il faut voir si le fond de la partie à afficher de l'un correspond au fond de l'autre partie du caractère qui va rester par exemple, ou s'ils sont inversé.
Dans ce derniers cas, j'inverse les bits de la partie du caractère à afficher...
S'il la zone du caractère à afficher (ou celui qui est déjà en place dans la colonne MSX) est pleine ou vide, cela joue aussi.
Et quand il y a vraiment 4 couleurs distinctes, je regarde quel ensemble de 2 couleurs font les plus de pixels, pour les privilégier.
Et beaucoup de pages videotex jouent aussi sur l'inversion vidéo.
Enfin bref, des trucs comme ca.
Pour l'optimisation, j'ai déjà passé certaines variables en globales.
Bon, je vois pas trop la différence (enfin pour le code si, je trouve ca assez "dégueulasse" en fait !)
Après il est vrai que je ne suis pas habitué à forcément à faire le code le plus optimisé du monde (comme beaucoup de nos jours je pense, ceci à cause de la puissance du matériel actuel comparé à ce que l'on avait avant !).
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie