Inscription : 29 Août 2007, 12:04 Message(s) : 1990 Localisation : seine et marne 77
breiztiger a écrit :
bizarre je viens de le lancer sur la version que j'ai et pas de plantage ?!?
Merci. Je viens de vérifier, on a donc 2 versions différentes de cet éducatif. Ton original n'est pas modifié, par contre ton CT-raw est corrompu.
Donc ton original est surement une (v2), et celle de Loic la (v1). Ils ont du faire un second master et mettant directement l'amorçage CPM 2.2 pour pas que les utilisateurs se fassent chier à utiliser une disquette tierce.
Je ne vois que les pistes 0 à 27, les pistes 28 à 41 ne sont pas dedans, et l'Analyseur me renvoie un message d'erreur me disant que le CTraw est corrompu.
Tu peux le refaire et le réuploader ? Merci
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
Lone a écrit :
@Megachur : L'indication "bit/byte" se trouve dans la donnée "blockFlag" du block descriptor : Le bit 2 indique "DataInBit". S'il est à vrai, on a des données en bit (et non en byte).
Le format est bien fait : On retrouve un champs de bits facilement, et tout est encodable automatiquement (sans interprétations supplémentaires)
Dans le fichier en question, on en trouve, je pense, une occurence en &D3F : Le 07 indique un forward GAP, un backward GAP, et des données en bit.
Pour les infos manquante de l'en-tête, c'est un parti pris : Vu qu'on génère à partir de n'importe quoi (y compris aucun format source !), le CRC n'a pas forcément de sens. Idem sur le creator ID (je ne prétends pas faire des "faux" IPF officiels - Je laisse donc la SPS gérer ses ID). Ou alors il faudrait que j'obtienne un ID pour Sugarbox (et autre ) !
Pour la date, je le confesse, c'est juste que j'ai zappé la conversion.
ok, si je continue le décodage alors avec ton indication sur blockflag :
Code :
dataHead=0x22 0x22 & 0x05 -> 1 bytes de longueur de datas (CAPS_SIZE_S=5) quand c'est égal = 0 c'est qu'on lit au moins un octet de longueur de data ;-) ! lecture de la longueur = 0x08 avec le blockFlags&0x0x4 à true -> longueur en bits = 1 bytes ! 0x22 & 0x1f -> 0x02 = bytes de data (CAPS_DATAMASK=0x1f) vont suivre
FE
22 30 ok, 30 bits = 6 bytes de data ! 00 00 C1 02 DC 3B
41 02 26 12 54 92 54
0x41 & 0x1f -> 0x01 = bytes de sync (CAPS_DATAMASK=0x1f) vont suivre
c'est pas des bytes de synchro pour moi mais du gap ou des datas !? longueur = 0x0226 = 550 bits = 69 bytes arrondi (la formule arrondie pour passer en bytes utilisée est normalement "(dataSize+7)>>8) "!
donc pour moi, plusieurs points négatifs sur le codage : comme tu codes tous en MFM déjà, tu devrais entre en type = 0x04 RAW DATA et pas en bytes Sync ou data (qui doit être utilisé que pour les 6 bytes de sync en MFM) ! de plus, tu codes en bits plutôt qu'en bytes donc raison de plus pour être en raw !
pour les bytes DATA et GAP, comme ils sont censés être en DATA et pas en MFM_DATA, on doit les transcoder normalement en MFM ! --> si tu mets des datas et gap directement en MFM, tu ne respectes pas le codage annoncé !
ou alors, on considère que quand on est en longueur bits, on est toujours en MFM, mais je n'avais pas vu cela dans le code 'officiel' !?
en tout cas, c'est ce qui diffère aujourd'hui entre les ipfs 'Sugarbox' et ceux officiels !!!
Megachur : Il est probable que mes "types" ne soient pas forcément corrects, parce qu'ils ne sont pas nécessaire (ni forcément pertinent). On a déjà vu mainte fois un octet dans un GAP être également des données de secteur (voir même des données de plusieurs secteurs différents !). J'ai pas forcément fait trop d'effort sur le sujet...
Inscription : 29 Août 2007, 12:04 Message(s) : 1990 Localisation : seine et marne 77
Lone a écrit :
Pas mieux sur le fichier, breiztiger...
Megachur : Il est probable que mes "types" ne soient pas forcément corrects, parce qu'ils ne sont pas nécessaire (ni forcément pertinent). On a déjà vu mainte fois un octet dans un GAP être également des données de secteur (voir même des données de plusieurs secteurs différents !). J'ai pas forcément fait trop d'effort sur le sujet...
Question : est-ce que tu as bien utilisé la commande :
Tout est passé ok sur la version en cours (bientôt dispo). Je reprend l'ensemble des ctraw vu ici pour vérifier le support, pour le moment, rien à signaler (et plus de régressions !)
Inscription : 29 Août 2007, 12:04 Message(s) : 1990 Localisation : seine et marne 77
Je joins à présent l'archive CDT
Liste K7 :
- Astro Attack - Automec - Basil The Great Mouse Detective - Bataille pour Midway - Boulder Dash (version mirrorsoft et Beyond Software) - Boulder Dash III - Boulder Dash IV Hi-Tec - Bridge-It - Canadair - Computer Maniac's 1989 Diary - Contamination - Crafton & Xunk - Danger Mouse in Double Trouble - Danger Mouse in Making Whoopee - Fighting Warrior - Galachip - Ghost Hunters - Haunted Hedges - Imagination - Jet Set Willy - The Fina Frontier - La Foret Infernale - Les Ripoux (version 64k) - Meganova - Meurtres Sur L'Atlantique - Mike Gunner - Moto Driver (loriciels) - Mr Freeze - Night Shade - Rebel Planet - SOS Space - Sirwood - Soul Of A Robot - Space Hawks - Spy vs Spy - Sultan's Maze - The Apprentice - The Galactic Plague - The Jewels Of Darkness - The Tomb Of Kuslak - Tobrouk 1942 (FR) - Viaje Al Centro Della Tierra
Tout ces dumps ont été traité avec le futur nouvel outil de César, qui sortira d'ici le début de l'année qui vient (sauf si César décide de le sortir pour noel lol).
Voici les caractéristiques :
* Les timings sont très précisément calculés (à l'inverse de samp2cdt qui fait nawak) * détection automatique et intelligente des systèmes de protection * Un grand nombre de système de protection sont supportés : - Alkatraz - Amstrad CPC (custom ou non) - Bleepload 2 - EH services (utilisé sur Knight Force, Dick Tracy, Wild Streets, The One) - Gremlin 1 (utilisé sur Basil the great mouse detective, mickey mouse, skate crazy) - microkey (Steve Evans' Z, Boblsleigh....) la protection est correctement gérée (pas comme samp2cdt !) - Operasoft (tout les jeux comme Livingstone, Cosa Nostra, Goody, Sol Negro, Mutan Zone, Sirwood....) - Poliload (AMC, After the war, Rescate atlantida, Michel Futbol) - ricochet (Octoplex, Rick Dangerous II....) - sinclair spectrum (fichiers et blocs par défaut) - spectrum variant 1 (1600 bauds) : thing bounces back, masters of the universe, pacmania, chubby gristle.... - spectrum variant 2 (1800 bauds) : Abu Simbel Profanation, Game Over, Afteroids, Humphrey......
Les speedlocks ont intégralement été désossés, y compris ceux qui sont spéciaux.
Le CPC ne possède que 3 types de speedlock cassette. Chacun ayant un fonctionnement interne différent, et possédant plusieurs variantes.
Csw2cdt les supporte tous, César ayant fait le reverse engineering de tout les loaders des jeux speedlock, via les redumps des cassettes de Loic.
Fini les cdts bouseux de samp2cdt qui généraient des bugs, maintenant c'est du passé
Reste enfin :
- Unilode : Sailing, Trivial Pursuit, Yes Prime Minister..... - Zydroload : Hostages, North and south, The Light Corridor - Puffy's Saga : cas spécifique, traité à part entière.
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
Lone a écrit :
Pas mieux sur le fichier, breiztiger...
Megachur : Il est probable que mes "types" ne soient pas forcément corrects, parce qu'ils ne sont pas nécessaire (ni forcément pertinent). On a déjà vu mainte fois un octet dans un GAP être également des données de secteur (voir même des données de plusieurs secteurs différents !). J'ai pas forcément fait trop d'effort sur le sujet...
En fait, tout dépend de ce que tu veux au final ... générer des ipfs qui ne fonctionnent que sur Sugarbox ou les autres émulateurs / outils ? si c'est pour un max d'autres 'émulateur', il faut bien se conformer aux règles sauf à ce qu'ils gèrent les mêmes exceptions que Sugarbox à ce sujet !
Megachur : Il est probable que mes "types" ne soient pas forcément corrects, parce qu'ils ne sont pas nécessaire (ni forcément pertinent). On a déjà vu mainte fois un octet dans un GAP être également des données de secteur (voir même des données de plusieurs secteurs différents !). J'ai pas forcément fait trop d'effort sur le sujet...
En fait, tout dépend de ce que tu veux au final ... générer des ipfs qui ne fonctionnent que sur Sugarbox ou les autres émulateurs / outils ? si c'est pour un max d'autres 'émulateur', il faut bien se conformer aux règles sauf à ce qu'ils gèrent les mêmes exceptions que Sugarbox à ce sujet !
En fait, quand j'ai développé le writer d'IPF, il n'y avait que la lib de la sps pour les relire... ( Soit caprice ipf' et sugarbox anciennes version en terme d'émulation) Plus le kryoflux bien sur. Ils ont donc été mes juges de paix pour déterminer le correct de l' incorrect. Vu le faible niveau de doc, j'ai donc fait comme j'ai pu, sachant que je génère des ipf' fonctionnels pour le kryoflux ( hors bugs résiduels). Pour ces types précis, je vais tâcher d'améliorer la sauce, pour peu qu'on arrive à savoir précisément ce qu'ils signifient.
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 10 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