MSX Village forum

La Place des Développeurs Lire le contenu d'un fichier en ASM

aoineko Membre non connecté

Conseiller Municipal

Rang

Avatar

Groupe : Shoutbox

Inscrit le : 02/01/2011 à 21h17

Messages: 2820

Le 26/04/2011 à 22h37

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.
Github    
GDX Membre non connecté

Conseiller Municipal

Rang

Avatar

Inscrit le : 17/01/2011 à 08h52

Messages: 3004

Le 27/04/2011 à 07h24
aoineko :


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
   
Metalion Membre non connecté

Conseiller Municipal

Rang

Avatar

Inscrit le : 23/12/2009 à 15h32

Messages: 1494

Le 27/04/2011 à 09h06
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 ?



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)
   
aoineko Membre non connecté

Conseiller Municipal

Rang

Avatar

Groupe : Shoutbox

Inscrit le : 02/01/2011 à 21h17

Messages: 2820

Le 27/04/2011 à 10h38
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.
Github    
Metalion Membre non connecté

Conseiller Municipal

Rang

Avatar

Inscrit le : 23/12/2009 à 15h32

Messages: 1494

Le 27/04/2011 à 12h08
Total respect pour ta tenacité sur le sujet :top
En plus, tu as maintenant débroussaillé le sujet pour nous tous, ton expérience nous servira :D ^^


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)
   
aoineko Membre non connecté

Conseiller Municipal

Rang

Avatar

Groupe : Shoutbox

Inscrit le : 02/01/2011 à 21h17

Messages: 2820

Le 27/04/2011 à 14h11
GDX :
Revoici le même exemple mais avec une plus grosse image




Tu aurais le code ASM ? ^^



EDIT : C'est bon, j'ai désassemblé. Edité par aoineko Le 28/04/2011 à 00h30


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

Conseiller Municipal

Rang

Avatar

Groupe : Shoutbox

Inscrit le : 02/01/2011 à 21h17

Messages: 2820

Le 28/04/2011 à 01h32
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.


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.
Github    
GDX Membre non connecté

Conseiller Municipal

Rang

Avatar

Inscrit le : 17/01/2011 à 08h52

Messages: 3004

Le 28/04/2011 à 06h11
aoineko :
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, 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
   
aoineko Membre non connecté

Conseiller Municipal

Rang

Avatar

Groupe : Shoutbox

Inscrit le : 02/01/2011 à 21h17

Messages: 2820

Le 28/04/2011 à 07h55
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. :top Edité par aoineko Le 28/04/2011 à 08h03


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

Conseiller Municipal

Rang

Avatar

Inscrit le : 23/12/2009 à 15h32

Messages: 1494

Le 28/04/2011 à 09h21
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)
   
GDX Membre non connecté

Conseiller Municipal

Rang

Avatar

Inscrit le : 17/01/2011 à 08h52

Messages: 3004

Le 28/04/2011 à 11h34
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.


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. :top


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
   
Metalion Membre non connecté

Conseiller Municipal

Rang

Avatar

Inscrit le : 23/12/2009 à 15h32

Messages: 1494

Le 28/04/2011 à 14h14
GDX :
J'ai trouvé un site qui a l'air très intéressant :

http://msxbanzai.tni.nl/dev/faq.html


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)
   
aoineko Membre non connecté

Conseiller Municipal

Rang

Avatar

Groupe : Shoutbox

Inscrit le : 02/01/2011 à 21h17

Messages: 2820

Le 28/04/2011 à 15h12
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 ? :hum


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

Conseiller Municipal

Rang

Avatar

Inscrit le : 17/01/2011 à 08h52

Messages: 3004

Le 28/04/2011 à 16h14
aoineko :
D'où viennent ces 20h ? :hum


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
   
aoineko Membre non connecté

Conseiller Municipal

Rang

Avatar

Groupe : Shoutbox

Inscrit le : 02/01/2011 à 21h17

Messages: 2820

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. :top


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

Conseiller Municipal

Rang

Avatar

Groupe : Shoutbox

Inscrit le : 02/01/2011 à 21h17

Messages: 2820

Le 28/04/2011 à 17h37
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.
Github    
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie