La Place des Développeurs Lire le contenu d'un fichier en ASM
Reprise du message précédent
Merci ; en fait j'ai déjà feuilleté cet ouvrage, mais c'est très techniques ; je m'y suis vite perdu.
De toute façon, je semble sur la bonne voie : j'ai réussi à Open un fichier (instruction 44h) sans erreur !!
Par contre, la, je bute sur le Read (instruction 48h).
Code TEXT :
Parameters: C = 48H (_READ)
B = 0 (File handle)
DE = C0BEh (Buffer address)
HL = 100h (Number of bytes to read )
Results: A = 0 (Error)
HL = 100h (Number of bytes actually read)
Erreur 0, 256 octets lu, tout semble ok... sauf qu'en C0BEh, aucun octet n'a était copié.
Une idée ?
On est toujours ignorant avant de savoir.
aoineko :
L'instruction, c'est dans le registre C, non ? De toute façon, ça plante tout autant.
L'instruction, c'est dans le registre C, non ? De toute façon, ça plante tout autant.
Oui, c'est bien C. (j'ai corrigé mon erreur au passage.)
La fonction que j'ai mise dans l'exemple est plus simple et marche bien. La ROM du disque s'initialise bien. Ça doit marcher pour toi aussi.
Revoici le même exemple mais avec une plus grosse image ;
file2vram.zip
J'ai juste mis une autre image plus parlante qui fait tout l'écran cette fois. Le reste ne change pas sauf les coordonnés de destination.
J'ai créée cette image avec cette méthode :
http://gigamix.jp/download/gigamix/koneta.php
Ça permet de faire un dessin pour le screen8 rapidement sur un Mac ou PC. L'image sera au format RAW donc il y a juste l'entête à ajouter avec un éditeur hexa.
En même temps voici une doc qui t'intéressera sûrement :
http://www.scribd.com/doc/24851173/MSX-Technical-handbook-3 Edité par GDX Le 27/04/2011 à 08h18
Dis donc, Aoineko ... Tu as l'air de patauger pas mal pour faire marcher ces routines d'accès disque
Est-ce que ce ne serait pas dix fois plus simple de passer ta ROM en MegaROM (c'est très facile), et de stocker tes circuits dedans ?
Est-ce que ce ne serait pas dix fois plus simple de passer ta ROM en MegaROM (c'est très facile), et de stocker tes circuits dedans ?
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 :
Est-ce que ce ne serait pas dix fois plus simple de passer ta ROM en MegaROM (c'est très facile), et de stocker tes circuits dedans ?
Je pense avoir enfin compris le système et j'ai l'impression de plus être très loin.
Et puis, l'idée est de pouvoir permettre à n'importe qui d'ajouter un circuit , chose qui se serait pas possible s'ils étaient dans la ROM.
Ceci dit, mon prochain jeu, je le ferai surement en MegaROM.
Edité par
aoineko
Le 27/04/2011 à 10h38
On est toujours ignorant avant de savoir.
Total respect pour ta tenacité sur le sujet 
En plus, tu as maintenant débroussaillé le sujet pour nous tous, ton expérience nous servira
En plus, tu as maintenant débroussaillé le sujet pour nous tous, ton expérience nous servira
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)
GDX :
Revoici le même exemple mais avec une plus grosse image
Bon, ton teste marche bien, mais j'arrive pas à l'intégrer dans mon environnement.
Le MSX Technical handbook - Part III dit :
Citation :
System calls can also be used from DISK-BASIC by using
the entry address of F37DH. For this case, store the machine codes in the
area allocated by the CLEAR statement and call its start address using the
USR function.
the entry address of F37DH. For this case, store the machine codes in the
area allocated by the CLEAR statement and call its start address using the
USR function.
Je sais pas ce qu'est la « zone alloué par le CLEAR », mais j'ai essayé de déplacer mon code de chargement en C000h, sans plus de succès.
A mon avis, le problème viens surtout du fait que ma ROM couvre la page 2 alors que le Disk System attend de la RAM à cet endroit.
Faudrait p'être que je switch le slot de la page 2 le temps de lire mon fichier...
On est toujours ignorant avant de savoir.
aoineko :
Tu aurais le code ASM ?
GDX :
Revoici le même exemple mais avec une plus grosse image
Tu aurais le code ASM ?
Tout était pareil sauf l'image et la coordonné de destination. L'image précédente était toute petite et ne représentait rien
aoineko :
Bon, ton teste marche bien, mais j'arrive pas à l'intégrer dans mon environnement.
Le MSX Technical handbook - Part III dit :
[quote=Citation]System calls can also be used from DISK-BASIC by using
the entry address of F37DH. For this case, store the machine codes in the
area allocated by the CLEAR statement and call its start address using the
USR function.
Bon, ton teste marche bien, mais j'arrive pas à l'intégrer dans mon environnement.
Le MSX Technical handbook - Part III dit :
[quote=Citation]System calls can also be used from DISK-BASIC by using
the entry address of F37DH. For this case, store the machine codes in the
area allocated by the CLEAR statement and call its start address using the
USR function.
Bon, J'ai trouvé le paramètre manquant. Le buffer de l'instrution BLTVD se place à la fin de la zone des variables qui est indiqué par l'adresse 0F6C6h. En mettant, 0C000h à cette adresse, le bank 2 reste libre et ça marche sans devoir déplacer ta routine de chargement vers le haut de la RAM et sans changer de Slot.
Quant à l'adresse de fin de ce Buffer, je suis pas sûr mais, je pense qu'elle doit être indiquée par l'adresse 0FC4AH qui contient l'emplacement du dernier octet disponible en RAM.
Sache aussi que plus le Buffet est petit, plus le chargement est long.
Tu tiens le bon bout cette fois.
Voici le programme de ce test :
Code ASM :
4010: di call #0138 ; RSLREG: Lit l'état actuel du registre du slot primaire. rrca rrca and #03 ld c,a ; Sauvegarde l'état du slot primaire du Bank 1 (qui contient la ROM) ld b,0 ld hl,#fcc1 ; Hl = 0fcc1h (pour slot 0) add hl,bc ; Hl = valeur pour slot actuel (EXBRSA) or (hl) ; met le bit 7 à 1 si Slot 0 est étendu ld c,a inc hl inc hl inc hl inc hl ld a,(hl) ; Lit l'état actuel du registre du slot secondaire du Slot actuel (EXPTBL) and #0c ; Garde l'état du slot secondaire du Bank 1 or c ; Ajoute l'état du slot primaire du Bank 1 ld (mem_slot),a ; Sauvegarde l'adresse du Slot de la ROM di ld h,a ld l,#f7 ld (#feda),hl ; place l'intruction RST 30 + numéro de slot + adresse de saut ld hl,#4040 ; dans le hook H.STKE ld (#fedc),hl ; pour revenir à l'adresse 04040h de la ROM ret 4040: ld hl,#4050 ld de,#8000 ld bc,#00d0 ldir ; Copie de la routine de chargement, du nom de fichiers et des données BLTVD. jp #8000 4050: ld hl,#c000 ld (#F6C6),hl ; Fin de la zone des variables = 0C000h ld a,#08 call #005f ; CHGMOD: Changement de mode d'écran. (A=8 donc screen8) ld hl,#80c0 ld de,#f562 ld bc,#000f ldir ; Entre le nom du fichier et son chemin ld ix,#019d ; Routine de transfère d'un fichier vers la VRAM (BLTVD) ld hl,#f562 call #015f ; EXTROM: Effectue un appel à la routine de la Sub-ROM. 4070: jr #4070 ; fin de l'exemple (reste sur place). 4100: ; (#80B0 par la suite) db 022h,"A:TEST.PIC",022h,00h ; L'entête du fichier TEST.PIC fait 4 octets (largeur, hauteur) 4110: ; (#80C0 par la suite) dw 080B0h db 0,0,00h,0,00h,0,0,0,0,0,0,0 ; données du BLTVD (qui sont copiées en 080C0h avec un ldir)
Et l'archive réactualisée :
file2vram.zip Edité par GDX Le 28/04/2011 à 16h21
J'essaye ça à midi; merci !
EDIT : J'ai pas résister et je viens de tester ; Ça marche presque !! En fait, je crois que ça écrase une partie de mes données en RAM. Faudra juste que j'essaye de voir comment limiter ce buffer. On y est presque.
Edité par
aoineko
Le 28/04/2011 à 08h03
EDIT : J'ai pas résister et je viens de tester ; Ça marche presque !! En fait, je crois que ça écrase une partie de mes données en RAM. Faudra juste que j'essaye de voir comment limiter ce buffer. On y est presque.
Edité par
aoineko
Le 28/04/2011 à 08h03
On est toujours ignorant avant de savoir.
aoineko :
Je sais pas ce qu'est la « zone alloué par le CLEAR »
CLEAR est une commande en BASIC qui défini (notamment) la zone de mémoire inutilisable par le BASIC. Elle est utilisée lorsqu'il y a une cohabitation entre le BASIC et des routines en assembleur, afin de bien définir les frontières.
Par exemple "CLEAR 256,&hD000" va réserver 256 octets pour les variables BASIC et va libérer l'espace mémoire au dessus de $D000 pour l'utilisateur.
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 "CLEAR 256,&hD000" va réserver 256 octets pour les variables BASIC et va libérer l'espace mémoire au dessus de $D000 pour l'utilisateur.
Par exemple "CLEAR 256,&hD000" va réserver 256 octets pour les variables BASIC et va libérer l'espace mémoire au dessus de $D000 pour l'utilisateur.
Ces valeurs ont l'air de se placer aux adresses suivantes :
0F421h pour 256
0F425h pour &hD000
Donc 0F425h indique peut-être la limite du buffer si ce n'est pas 0FC4Ah.
J'ai trouvé un site qui a l'air très intéressant :
http://msxbanzai.tni.nl/dev/faq.html
aoineko :
J'ai pas résister et je viens de tester ; Ça marche presque !! En fait, je crois que ça écrase une partie de mes données en RAM. Faudra juste que j'essaye de voir comment limiter ce buffer. On y est presque.
Ou alors, tu places ces données avant entre C000h et le Buffer. C'est plus simple. Edité par GDX Le 28/04/2011 à 11h40
GDX :
Marrant ça
Je faisait des recherches à l'instant pour tout à fait autre chose (les vitesses d'éxécution de HMMC), et je suis tombé sur ce site, sur cette page, que je ne connaissais pas non plus !
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)
GDX :
Ou alors, tu places ces données avant entre C000h et le Buffer. C'est plus simple.
Yep, bonne idée. Ça écrase plus mes données ET l'image s'affiche, mais elle est comme entrelacée (comme si y avait un décalage). Je pense que ça viens des params que je passe à la fonction BLTVD.
Y a une différence entre ce que j'avais compris de la doc et ce que tu as dans ton code :
| Adr | Doc | GDX |
|---|---|---|
| F562 | Adresse nom fichier | Adresse nom fichier |
| F563 | ||
| F564 | indéfini | 20h |
| F565 | 0 | |
| F566 | Destination X (0) | 20h |
| F567 | 0 | |
| F568 | Destination Y (0) | 0 |
| F569 | 0 | |
| F56A | indéfini | 0 |
| F56B | 0 | |
| F56C | 0 | |
| F56D | 0 | |
| F56E | 0 | |
| F56F | Doit être 0 | 0 |
| F570 | Doit être 0 | 0 |
D'où viennent ces 20h ?
On est toujours ignorant avant de savoir.
aoineko :
D'où viennent ces 20h ?
C'est une erreur commise lorsque j'ai repris ce que tu as désassemblé. C'est juste un petit décalage de 2 octets.
Le tableau est plutôt ça :
| Adr | Doc | GDX |
|---|---|---|
| F562 | Adresse nom fichier | Adresse nom fichier |
| F563 | ||
| F564 | inutilisé | 0 |
| F565 | 0 | |
| F566 | Destination X (0) | 20h |
| F567 | 0 | |
| F568 | Destination Y (0) | 20h |
| F569 | 0 | |
| F56A | inutilisé | 0 |
| F56B | 0 | |
| F56C | 0 | |
| F56D | 0 | |
| F56E | 0 | |
| F56F | ARG | Direction |
| F570 | LOGOP | Opérateur logique |
Quant au décalage, Il doit être causé par un header du fichier incorrecte. Edité par GDX Le 28/04/2011 à 16h24
GDX :
Quant au décalage, Il doit être causé par un header du fichier incorrecte.
Ca fait la même chose avec ton image (bien joli d'ailleurs
).Je vais faire plus de test ce soir ; j'ai pas encore eu le temps de creuser.
Merci.
On est toujours ignorant avant de savoir.
GDX :
L'image n'est pas décalée ! Voici la capture de l'écran :
Oui, ça marche nickel dans ton exemple. Dans mon jeu, que ce soit mon image ou la tienne, j'ai le même soucis ; j'en conclu que ça viens pas du header de l'image.
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie