Les nouveaux habitants prez de zone
Bonjour,
Je vous lis depuis longtemps, mais j'ai toujours eu la flemme de m'inscrire, et en plus je n'avais pas grand chose à raconter.
Je m'intéresse au retro-compoutine et j'ai un peu lu récemment de la doc sur le z80 qui me paraissait simple, et j'ai enchainé sur le msx2 qui me paraissait la machine z80 le plus sympa. Le tout en pensant que ça allait être facile et rapide de me faire un pacman.
Grosse erreur ! C'est super compliqué en fait
Donc je me suis inscrit, je lis les docs donc je ne pose pas des questions (trop) stupides, mais il y a des trucs vraiment je ne vois pas… c'est une inscription un peu intéressée, alors je préfère être honnête
Si vous avez des problèmes linux, je peux vous aider en échange
Je vous lis depuis longtemps, mais j'ai toujours eu la flemme de m'inscrire, et en plus je n'avais pas grand chose à raconter.
Je m'intéresse au retro-compoutine et j'ai un peu lu récemment de la doc sur le z80 qui me paraissait simple, et j'ai enchainé sur le msx2 qui me paraissait la machine z80 le plus sympa. Le tout en pensant que ça allait être facile et rapide de me faire un pacman.
Grosse erreur ! C'est super compliqué en fait
Donc je me suis inscrit, je lis les docs donc je ne pose pas des questions (trop) stupides, mais il y a des trucs vraiment je ne vois pas… c'est une inscription un peu intéressée, alors je préfère être honnête
Si vous avez des problèmes linux, je peux vous aider en échange
Salut Zone,
Bienvenu au village !
Si tu as besoin d'un coup de main n'hesite pas a demander.
Tu programmes en assembleur ?
Bienvenu au village !
Si tu as besoin d'un coup de main n'hesite pas a demander.
Tu programmes en assembleur ?
On est toujours ignorant avant de savoir.
Bienvenue Zone,
N'hésite pas à présenter ton projet de développement de la-boule-jaune-qui-a-faim-perdue-dans-son-labyrinthe-infesté-de-fantômes dans la rubrique du forum qui va bien ( la place des développeurs) ce qui permettra de te suivre et de t'aider. Je suis certain que des villageois vont te donner un coup de pouce avec entrain.
Quel modèle de MSX2 possède-tu ?
N'hésite pas à présenter ton projet de développement de la-boule-jaune-qui-a-faim-perdue-dans-son-labyrinthe-infesté-de-fantômes dans la rubrique du forum qui va bien ( la place des développeurs) ce qui permettra de te suivre et de t'aider. Je suis certain que des villageois vont te donner un coup de pouce avec entrain.
Quel modèle de MSX2 possède-tu ?
Rien ne se perd, tout doit se transformer.
salut a toi ... bienvenu parmis nous ... 
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
Merci pour l'accueil
Aoineko: j'apprends l'assembleur z80, que je ne connais pas du tout. Après quelques essais, je me suis décidé pour la doc Zilog UM008011-0816 (rev.2016).
Cylicano: mon modèle de MSX2 est OpenMSX ! J'ai d'ailleurs pour l'instant passé plus de temps à configurer celui-ci qu'à réellement programmer. J'utilise la branche git « imgui » (future nouvelle interface avec la lib imgui, beaucoup plus flexible que l'ancienne). Cet émulateur est vraiment bien, c'est d'ailleurs une des raisons de mon choix MSX pour programmer.
Aoineko: j'apprends l'assembleur z80, que je ne connais pas du tout. Après quelques essais, je me suis décidé pour la doc Zilog UM008011-0816 (rev.2016).
Cylicano: mon modèle de MSX2 est OpenMSX ! J'ai d'ailleurs pour l'instant passé plus de temps à configurer celui-ci qu'à réellement programmer. J'utilise la branche git « imgui » (future nouvelle interface avec la lib imgui, beaucoup plus flexible que l'ancienne). Cet émulateur est vraiment bien, c'est d'ailleurs une des raisons de mon choix MSX pour programmer.
L'assembleur c'est super cool, mais il faut beaucoup de patience et de rigueur pour arriver à faire des trucs cools.
Je prêche pour ma paroisse (et celle de ErciB) mais avec le langage C tu peux combiner structure de programme facile à lire et à modifier avec bout de code en assembleur quand tu as envie de t'amuser à optimiser une routine.
D'ailleurs, petit Cocorico, les deux grosses librairies C pour MSX viennent des membres du village :
- Fusion-C de EricB,
- MSXgl de... moi
Je prêche pour ma paroisse (et celle de ErciB) mais avec le langage C tu peux combiner structure de programme facile à lire et à modifier avec bout de code en assembleur quand tu as envie de t'amuser à optimiser une routine.
D'ailleurs, petit Cocorico, les deux grosses librairies C pour MSX viennent des membres du village :
- Fusion-C de EricB,
- MSXgl de... moi
On est toujours ignorant avant de savoir.
Ah c'est toi MSXgl, j'avais vu ça. C'est un gros travail intéressant, effectivement.
Mais pour l'instant, je préfère rester sur l'assembleur pur, c'est pour m'amuser.
Si je suis vraiment motivé et que j'ai un projet qui le nécessite, MSXgl est surement plus intéressant (pour avoir une chance de finir le projet au moins). Donc je ne dis pas non, mais pas tout de suite en tout cas
Mais pour l'instant, je préfère rester sur l'assembleur pur, c'est pour m'amuser.
Si je suis vraiment motivé et que j'ai un projet qui le nécessite, MSXgl est surement plus intéressant (pour avoir une chance de finir le projet au moins). Donc je ne dis pas non, mais pas tout de suite en tout cas
Chacun s'amuse comme il le souhaite.
Ceci dit, même en assembler je devrais pouvoir te donner un coup de main, même si ce n'est pas ma spécialité.
Comme dit Cylicano, quand tu te lancera dans un projet, hésites pas à créer un fil dédié et y poser tes questions.
Bonne découverte du MSX ! \o/ Edité par aoineko Le 12/10/2023 à 17h25
Ceci dit, même en assembler je devrais pouvoir te donner un coup de main, même si ce n'est pas ma spécialité.
Comme dit Cylicano, quand tu te lancera dans un projet, hésites pas à créer un fil dédié et y poser tes questions.
Bonne découverte du MSX ! \o/ Edité par aoineko Le 12/10/2023 à 17h25
On est toujours ignorant avant de savoir.
zone :
Merci pour l'accueil
Aoineko: j'apprends l'assembleur z80, que je ne connais pas du tout. Après quelques essais, je me suis décidé pour la doc Zilog UM008011-0816 (rev.2016).
Cylicano: mon modèle de MSX2 est OpenMSX ! J'ai d'ailleurs pour l'instant passé plus de temps à configurer celui-ci qu'à réellement programmer. J'utilise la branche git « imgui » (future nouvelle interface avec la lib imgui, beaucoup plus flexible que l'ancienne). Cet émulateur est vraiment bien, c'est d'ailleurs une des raisons de mon choix MSX pour programmer.
Aoineko: j'apprends l'assembleur z80, que je ne connais pas du tout. Après quelques essais, je me suis décidé pour la doc Zilog UM008011-0816 (rev.2016).
Cylicano: mon modèle de MSX2 est OpenMSX ! J'ai d'ailleurs pour l'instant passé plus de temps à configurer celui-ci qu'à réellement programmer. J'utilise la branche git « imgui » (future nouvelle interface avec la lib imgui, beaucoup plus flexible que l'ancienne). Cet émulateur est vraiment bien, c'est d'ailleurs une des raisons de mon choix MSX pour programmer.
Binvenue à toi.
Pour l'assembleur, deux livres:
Programmation du Z80 par Rodnay Zacks
Le livre du MSX2 (disponible dans la bibliothèque du Village)
Pour ton PAC MAN, tu peux commencer en BASIC pour commencer, c'est faisable et plus simple
Et tu peux aussi passer au BASIC KUN (X-BASIC, Turbo BASIC, c'est la même chose
)Dans quel mode tu veux le faire (screen)? mode texte, mode graphique, si mode graphique, alors lequel?
Tu veux le lancer depuis le DOS ou depuis le BASIC (pas la même origine en mémoire entre autre).
Par exemple si tu veux lancer depuis le BASIC, alors tu peux te simplifier la tâche en sélectionnant ton mode graphique et en chargeant tes fichiers images avec le BASIC.
Tu chargeras ton code assembleur avec un BLOAD et tu appellera ton code assembleur avec le BASIC aussi avec un DEFUSR et un USR()
Si tu veux lancer depuis le DOS, je dois pouvoir te trouver des exemples de routines pour charger des fichier en assembleur etc...
Je sais que les sources de X-TAZY trainent sur le net au format ZIP, tu trouveras ce qu'il te faut pour charger des fichiers sous DOS2.
Je dois avoir des sources autre part mais ou?
Bon courage
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,...
C'est noté pour les bouquins, merci.
Je veux programmer direct en assembleur, ça ne me fait pas peur
Je pensais au départ utiliser un mode du MSX2 (screen 4). Les modes bitmap sont tentants (pour un pacman en écran fixe, ça irait), mais autant s'habituer directement aux modes caractères.
À la réflexion, peut-être le faire en screen 1, c'est qu'un pacman après tout.
Pour sélectionner le mode graphique, c'est aussi simple qu'appeller init32 (0x6f) non ?
J'ai essayé (sans paramètres) et je suis bien passé en screen 1. Bon évidemment, tout reste à définir (table des caractères, sprites, palette éventuelle… mais ça peut se définir avant l'appel de init32 en écrivant à partir de 0xf3bd (si j'ai bien compris le doc des appels bios).
Pour le chargement du jeu, Je préfère (dans l'ordre):
rom (plus simple pour le joueur)
basic (que j'utilise quand même pour tester mes routines)
dos (je ne connais pas, c'est au format com ?)
Je me suis fait un petit script de développement pour contrôler OpenMSX depuis son interface sockets : je le lance et il compile mon source et si réussite, le lance depuis OpenMSX. Si le binaire fait moins de 16ko, il le lance avec un bload, sinon il insére le binaire comme une cartouche et fait un reset de la machine en mode rapide (ça lance la cartouche en moins d'une seconde, en accélérant au max tout le démarrage (notamment le logo), pratique).
J'ai récupéré quelques sources à étudier également
Edité par zone Le 17/10/2023 à 11h09
Je veux programmer direct en assembleur, ça ne me fait pas peur
Je pensais au départ utiliser un mode du MSX2 (screen 4). Les modes bitmap sont tentants (pour un pacman en écran fixe, ça irait), mais autant s'habituer directement aux modes caractères.
À la réflexion, peut-être le faire en screen 1, c'est qu'un pacman après tout.
Pour sélectionner le mode graphique, c'est aussi simple qu'appeller init32 (0x6f) non ?
J'ai essayé (sans paramètres) et je suis bien passé en screen 1. Bon évidemment, tout reste à définir (table des caractères, sprites, palette éventuelle…
mais ça peut se définir avant l'appel de init32 en écrivant à partir de 0xf3bd (si j'ai bien compris le doc des appels bios).Pour le chargement du jeu, Je préfère (dans l'ordre):
rom (plus simple pour le joueur)
basic (que j'utilise quand même pour tester mes routines)
dos (je ne connais pas, c'est au format com ?)
Je me suis fait un petit script de développement pour contrôler OpenMSX depuis son interface sockets : je le lance et il compile mon source et si réussite, le lance depuis OpenMSX. Si le binaire fait moins de 16ko, il le lance avec un bload, sinon il insére le binaire comme une cartouche et fait un reset de la machine en mode rapide (ça lance la cartouche en moins d'une seconde, en accélérant au max tout le démarrage (notamment le logo), pratique).
J'ai récupéré quelques sources à étudier également
Edité par zone Le 17/10/2023 à 11h09
zone :
Je pensais au départ utiliser un mode du MSX2 (screen 4). Les modes bitmap sont tentants (pour un pacman en écran fixe, ça irait), mais autant s'habituer directement aux modes caractères.
À la réflexion, peut-être le faire en screen 1, c'est qu'un pacman après tout.
À la réflexion, peut-être le faire en screen 1, c'est qu'un pacman après tout.
Attention que les modes 1 à 3 ne bénéficient pas des sprites MSX2 (c'est à dire multicolores). Ils ne sont disponibles qu'à partir du mode 4.
zone :
Je me suis fait un petit script de développement pour contrôler OpenMSX depuis son interface sockets : je le lance et il compile mon source et si réussite, le lance depuis OpenMSX. Si le binaire fait moins de 16ko, il le lance avec un bload, sinon il insére le binaire comme une cartouche et fait un reset de la machine en mode rapide (ça lance la cartouche en moins d'une seconde, en accélérant au max tout le démarrage (notamment le logo), pratique).
Alors ça, ça m'intéresse beaucoup.
Tu peux en dire plus ?
Edité par Metalion Le 17/10/2023 à 18h47
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)
Ce qui t'intéresse, c'est la façon de contrôler OpenMSX je pense ?
Il faut absolument lire ça: https://openmsx.org/manual/openmsx-control.html
Alors en gros, on peut le contrôler avec des pipes (depuis l'entrée standard) ou alors depuis des sockets.
J'ai utilisé pour ma part une socket « domain » (unix) , si tu es sous windows il faudra une socket « inet ». Dans les deux cas, le code est très similaire.
Je l'ai fait avec Lua (si tu connais pas, « ~= » correspond à « différent », voilà je crois que j'ai décrit le plus étrange de Lua ).
Donc il faut initialiser et récupérer le socket:
Alors il est important d'envoyer <openmsx-control> avant toute chose, une fois le socket obtenu.
Pour envoyer des commandes, j'utilise la fonction client_send :
xml_from_server est une bête regex pour interpréter ce que renvoie OpenMSX (qui lui ne cause pas Lua, donc faut extraire).
Une fois que tu as ta socket, tu peux envoyer des commandes.
Par exemple pour l'insertion de cartouches (je pense que c'est cette partie qui t'intéresse):
Donc là, l'astuce c'est after time 4 "set throttle on" qui rétablit la vitesse d'origine du MSX après 4 secondes de temps MSX. C'est ça qui est génial avec cette commande: ça va fonctionner de la même façon sur une vieille machine et sur le dernier proc de Intel refroidit à l'azote.
Je n'ai pas mis le code complet car il est un peu bordélique (éclaté sur deux fichiers, mélange de commentaires/variables en anglais et en français, ça serait à revoir… ) , mais si ça t'intéresse, je peux le fournir après un peu d'édition
Edité par zone Le 17/10/2023 à 19h50
Il faut absolument lire ça: https://openmsx.org/manual/openmsx-control.html
Alors en gros, on peut le contrôler avec des pipes (depuis l'entrée standard) ou alors depuis des sockets.
J'ai utilisé pour ma part une socket « domain » (unix) , si tu es sous windows il faudra une socket « inet ». Dans les deux cas, le code est très similaire.
Je l'ai fait avec Lua (si tu connais pas, « ~= » correspond à « différent », voilà je crois que j'ai décrit le plus étrange de Lua
).Donc il faut initialiser et récupérer le socket:
Code LUA :
function init_communication() pid = get_pid("openmsx") if pid ~= nil then local sockfile = "/tmp/openmsx-".. os.getenv("USER") .."/socket.".. pid client_socket = assert(socket.unix()) client_socket:settimeout(1,"b") assert(client_socket:connect(sockfile)) client_send ("<openmsx-control>\n") end return client_socket end
Alors il est important d'envoyer <openmsx-control> avant toute chose, une fois le socket obtenu.
Pour envoyer des commandes, j'utilise la fonction client_send :
Code LUA :
function client_order(order) client_send("<command>" .. order .. "</command>") xml_from_server = client_receive() result,text = xml_extraction(xml_from_server) --print ("result ",result) -- « ok » si tout va bien if string.match(result or "","nok") then print ("Error. Server has answered: ",xml_from_server) text="" end return text end
xml_from_server est une bête regex pour interpréter ce que renvoie OpenMSX (qui lui ne cause pas Lua, donc faut extraire).
Une fois que tu as ta socket, tu peux envoyer des commandes.
Par exemple pour l'insertion de cartouches (je pense que c'est cette partie qui t'intéresse):
Code LUA :
function load_rom(romname) if (romname ~= nil) then local order = 'set throttle off ; carta eject ; carta insert ' .. romname .. ' ; reset ; after time 4 "set throttle on"' client_order(order) else print ("load_rom() : you must give a file as parameter") end end
Donc là, l'astuce c'est after time 4 "set throttle on" qui rétablit la vitesse d'origine du MSX après 4 secondes de temps MSX. C'est ça qui est génial avec cette commande: ça va fonctionner de la même façon sur une vieille machine et sur le dernier proc de Intel refroidit à l'azote.
Je n'ai pas mis le code complet car il est un peu bordélique (éclaté sur deux fichiers, mélange de commentaires/variables en anglais et en français, ça serait à revoir… ) , mais si ça t'intéresse, je peux le fournir après un peu d'édition
Edité par zone Le 17/10/2023 à 19h50
Metalion :
Attention que les modes 1 à 3 ne bénéficient pas des sprites MSX2 (c'est à dire multicolores). Ils ne sont disponibles qu'à partir du mode 4.
zone :
Je pensais au départ utiliser un mode du MSX2 (screen 4). Les modes bitmap sont tentants (pour un pacman en écran fixe, ça irait), mais autant s'habituer directement aux modes caractères.
À la réflexion, peut-être le faire en screen 1, c'est qu'un pacman après tout.
À la réflexion, peut-être le faire en screen 1, c'est qu'un pacman après tout.
Attention que les modes 1 à 3 ne bénéficient pas des sprites MSX2 (c'est à dire multicolores). Ils ne sont disponibles qu'à partir du mode 4.
Pas grave si pas de sprites multi color, vu que de mémoire les personnages à l'écran étaient monochrome
Blague à part Metalion à raison, c'est:
1 - Plus joli pour les couleurs
2 - Plus de sprites sur une même ligne
3 - Palette MSX2
zone :
C'est noté pour les bouquins, merci.
De rien
zone :
Je veux programmer direct en assembleur, ça ne me fait pas peur
Bravo! par le coté obscure, tu ne t'es pas laissé séduire, ta formation commencé tu vas
zone :
Je pensais au départ utiliser un mode du MSX2 (screen 4). Les modes bitmap sont tentants (pour un pacman en écran fixe, ça irait), mais autant s'habituer directement aux modes caractères.
À la réflexion, peut-être le faire en screen 1, c'est qu'un pacman après tout.
À la réflexion, peut-être le faire en screen 1, c'est qu'un pacman après tout.
En bitmmap screen 5 c'est cool aussi
surtout pour faire des cloisons avec plusieurs couleurs (dégradées sur des pixels horizontalement adjacents) pas possible en screen 1, 2 et 4 (ou difficilement puisque un couleur par tranche de 8 pixels).Tu peux même faire des dingueries en screen 11 avec un V9958
zone :
Pour sélectionner le mode graphique, c'est aussi simple qu'appeller init32 (0x6f) non ?
J'ai essayé (sans paramètres) et je suis bien passé en screen 1. Bon évidemment, tout reste à définir (table des caractères, sprites, palette éventuelle… mais ça peut se définir avant l'appel de init32 en écrivant à partir de 0xf3bd (si j'ai bien compris le doc des appels bios).
J'ai essayé (sans paramètres) et je suis bien passé en screen 1. Bon évidemment, tout reste à définir (table des caractères, sprites, palette éventuelle…
mais ça peut se définir avant l'appel de init32 en écrivant à partir de 0xf3bd (si j'ai bien compris le doc des appels bios).Honnêtement, je ne sais pas plus, parce que je tapais directement dans les registres du VDP
Mais de mémoire il y a des entrées dans le BIOS que tu peux appeler avec une valeur dans le registre A et zou ça te change le mode vidéo du VDP.
zone :
Pour le chargement du jeu, Je préfère (dans l'ordre):
rom (plus simple pour le joueur)
basic (que j'utilise quand même pour tester mes routines)
dos (je ne connais pas, c'est au format com ?)
rom (plus simple pour le joueur)
basic (que j'utilise quand même pour tester mes routines)
dos (je ne connais pas, c'est au format com ?)
ROM: ORG 0x4000 avec header rempli, y a des exemples sur MSX.org (recherche sur gogol
"msx.org cartridge developpement" ou un truc dans le genre, peut-être "programming" à la place de dev...DOS: ORG 0x0100 et tout de suite ton code sans header
pas besoin de basic avec bload"xxx",r pour lancer ton code, juste xxx.com à l'invite du DOS (invite du shell pour les Linuxien ). pour les appels au BIOS tu utilises la fonction située je ne sais plus ou entre 0x0000 et 0x00FF qui permet de faire un INTERSLOT CALL.EDIT:
lien sur le WIKI MSX.org
https://www.msx.org/wiki/Develop_a_program_in_cartridge_ROM
zone :
Edité par
z80
Le 18/10/2023 à 10h52
Je me suis fait un petit script de développement pour contrôler OpenMSX depuis son interface sockets : je le lance et il compile mon source et si réussite, le lance depuis OpenMSX. Si le binaire fait moins de 16ko, il le lance avec un bload, sinon il insére le binaire comme une cartouche et fait un reset de la machine en mode rapide (ça lance la cartouche en moins d'une seconde, en accélérant au max tout le démarrage (notamment le logo), pratique).
J'ai récupéré quelques sources à étudier également
J'ai récupéré quelques sources à étudier également
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,...
Merci pour le lien sur msx.org, j'avais trouvé des infos sur ce site, mais pas ce lien.
Il y a beaucoup d'informations sur msx.org, mais on passe vite à côté des choses intéressantes (la preuve).
Je crois que je vais ouvrir un sujet pour continuer la discussion, car je me suis un peu éparpillé entre plusieurs sujets (ici, Pampas & Selena … ).
Il y a beaucoup d'informations sur msx.org, mais on passe vite à côté des choses intéressantes (la preuve).
Je crois que je vais ouvrir un sujet pour continuer la discussion, car je me suis un peu éparpillé entre plusieurs sujets (ici, Pampas & Selena … ).
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie