Inscription : 21 Août 2008, 16:03 Message(s) : 342
On est pas dans le Code mais dans le header Amsdos du coup, j'ai un doute sur le bon endroit pour ce post... mais bon, on verra bien.
Je prends pour référence les infos que j'ai pu trouver sur un CDT d'un jeux, en l’occurrence RENEGADE III(voir image jointe) Ainsi que les infos données que l'on trouve dans la section 'SOFT 968 Section 9 (AMSDOS)' de Kevin Thacker et aussi la section 8 : SOFT 968 Section 8 (The Cassette Manager)
a savoir :
Code :
Bytes 0..15 Filename Padded to 16 bytes with nulls. Byte 16 Block number The first block is normally block 1 and block numbers increase by 1 on successive blocks. Byte 17 Last block A non-zero value means that this is the last block of a file. Byte 18 File type A value recording the type of the file (seebelow). Bytes 19..20 Data length The number of data bytes in the data record. Bytes 21..22 Data location Where the data was written from originally. Byte 23 First block A non-zero value means that this is the first block of a file.
Pièce jointe :
AMSDOS_Header.png
Dans l'image jointe je me retrouve bon sur le FILENAME et son EXT mais par la suite tout est décalé d'1 Byte.
Exemple, je ne trouve pas le 'DATA LENGTH' en Byte 19...20 mais en 20..21 'DATA Location' normalement en Byte 21...22 là, se trouve en 22...23 etc...
Je pense j'ai loupé un truc, clair !
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Inscription : 21 Août 2008, 16:03 Message(s) : 342
Je ne pense pas car, regarde :
et si on prends (plus en détail donc) la doc ==>
Code :
Byte 00: User number ==> $2C Byte 01 to 08: filename ==> R E N E G A D E (ca fait 8) Byte 09 bis 11: Extension Byte 18: type-byte Byte 21 and 22: loading address Byte 24 and 25: file length Byte 26 and 27: execution address for machine code programs Byte 64 and 65: (file length) Byte 67 and 68: checksum for byte 00 to byte 66
De plus le $2C, c'est que j'obtiens quand je décode le CDT alors on pourrais penser à une erreur sur mon code mais Si on regarde sur le site de cpc-p0wer, on trouve la meme chose http://cpc-p0wer.com/CdtView.php?fiche= ... g=0#block1
A moins que l'on est faux tout les deux (possible ceci dit). Apres... a quoi correspond ce $2C... alors la... Mais peu importe la doc que l'on prends, on parle bien d'une donnée en Bytes0 (user number dans la 1er donc) et (Filename Padded to 16 ... dans l'autre) Sauf que... 2C comme debut de nom de fichier... ca le fait pas. Le nom de fichier de ce DCT est a coup sur RENEGADE (ca commence par un R pas $2C) Ca met donc bien le 'filename' en Byte1 et pas Byte0
' Header beep. ' 257 bytes Type Cass_BEEP1 SYCHRO1(255) As Byte 'FFh SYCHRO2 As Byte 'FEh Cass_BTypeTag As Byte ' ID: 2Ch=header block, 16h=data block End Type
Donc, ton fichier n'est pas un fichier DATA!
Et après, dans la foulée, t'as ça...
Citer :
' 260 bytes 'Format of CPC Header blocks Type CassHeader
' [00-0F] Filename (unused bytes zero filled) Cass_Name(15) As Byte
' [10] Block-number (01..NN) Cass_BlocID As Byte
' [11] Last block flag (FFh=last block, 00h=other block) Cass_FFend As Byte
' [12] Filetype: ' 00h basic program ' 01h encrypted basic program ' 02h Binary(program Or Data) ' 16h ascii data Cass_FTypeTag As Byte
' [13-14] Block length (1..2048) Cass_LENGHT As Uint ' (800 -> next Bloc (B15=1) else bloc lenght.
' [15-16] Block loadaddress (destination address in RAM) Cass_LDadd As Uint ' first=&0100 sd=+&0800... n+&0800
' [17] First block flag (FFh=first block, 00h=other block) Cass_FFStart As Byte
' [18-19] Total file length (length of all blocks) (zero for ascii files) Cass_gLENGHT As Uint ' Global lenght. '(Remember, the size of 64 bytes is rounded up to 256 bytes)
' [1A-1B] Startaddress (for binary programs) Cass_BinAdd As Uint
' [1C-3F] Unused Cass_Spacer(227) As Byte
Cass_CRC As Uint ' ???? Cass_ENDtag As Byte ' =3 End Type
L'explication est correcte : en fait sur ne cassette, derrière pilote & sync, tu as ce byte qui indique quel type de bloc est utilisé : ici, 2c = Header. Derrière, on a les 16 octets de nom, le numéro de bloc, etc.
Le 2c indique ce qui suit, sans en faire partie ( d'où ton décalage de 1)
Simplement ce que te donne les docs Amstrad sont l'implementation sur la cassette physique; et dans le cdt, il y a ce fameux octet qui détermine le type de bloc, ici 2c qui correspond a un header.
L'explication donnée est bonne simplement vous n'etes pas au même niveau d'abstraction
Inscription : 21 Août 2008, 16:03 Message(s) : 342
ah merci. Voila, avec vos deux completement d'informations c'est clair.
En faite, vous m'avez tous toutes les brides pour mieux comprendre. Hermol, en effet pas de User sur la bande donc on commence 1 Byte plus comme tu l'avais dit d'ailleurs.
Les Derrière, on a les 16 octets de nom, m'ont orienté plus vers la seconde doc (ou ils disent exactement la même chose) que la 1er que j'ai sité plus haut, merci donc Lone
Et ce qui à été beaucoup plus clair pour moi, ce sont tes explications breiztiger, a savoir : ...docs Amstrad sont l'implementation sur la cassette physique
Sans oublier bien sur Xavier, qui malgré une explication pas clair POUR MOI (c'est pas une critique hein ) Permis par la suite (grâce aux info des deux autres), de mieux comprendre et de me servir de la description que tu as donnée.
Thks à tous, à plus qu'a finir mon p'tit scripts d'analyse CDT
Oui, Pardon, c'était du Visual Basic... J'aurais du le traduire en C# !
C'est ton "un BIT" qui me trouble...
Citer :
SYCHRO2 As Byte 'FEh
Bon, effectivement ça fait 1 Bit... "11111110" au lieu des "11111111" que l'on a avant! Et la lecture s'accroche sur le bit mou, en quittant les BITs durs. Puis, c'est la lecture du type de bloc... Enfin..... ton "BIT" me trouble...
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 20 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum
Connexion
Inscription
FAQ
)
