CPC Rulez :: Consulter le sujet

Non, le soucis est sur la longueur : 6489 octets donne 103824 bit (MFM), ce qui est beaucoup pour une piste.
Pourquoi est-ce ainsi ?

Parce qu'en comparant ce que fournit la SPS et ce qui est généré depuis l'edsk, on voit que le secteur est positionné beaucoup plus près du trou d'index dans le cas de l'IPF.

L'info est disponible dans l'Offset-Info du dsk... Mais cette donnée n'étant fiable que relativement (c'est à dire entre deux secteur), et n'ayant qu'un unique secteur dans chaque piste, on ne s'en sert pas. Du coup, placement standard du secteur, et piste bien longue.

Il faudrait tester l'écriture d'un tel IPF pour valider que l'on est dans les tolérances du FDC.

On pourrait tenter également une prise la non utilisation, sur certain seuils, d'un IAM (comme ç'est sans doute le cas ici) pour améliorer la conversion.

J'ai re-créer les deux dumps via DTC, à savoir la pre-release IPF de BlackTiger et la version IPF de lone patché.
J'ai le même résultat sur mon CPC6128 d'origine, à savoir :

cat m'affiche un message comme quoi il faut faire un run"disk, chose que je fait.
1 chargement qui affiche assez rapidement un image du jeux BlackTiger
Suivi d'un petit accès disk (assez rapide) et d'un autre un chouille plus long (c'est quand même rapide, il ne charge pas beaucoup de donnée)
Capcom présent... apparaît, on appuie sur une touche, on choisie de jouer au clavier (j'sais plus ou est mon joy), je set les touches, le jeu se lance
et on comprendre pourquoi y'a pas eu beaucoup de chargement... Mon dieu que c'est moche...

mais c'est pas le sujet

Toutes les fonction du perso fonctionne (avancer, sauter...)
Bref, dans les deux cas, le jeux fonctionne.

Après... je ne connaît pas cette protection (Hexagone) ni ce jeu sur le CPC (je le connais uniquement en arcade ou c'est une bombe).
Denis, peux nous en dire plus sur la protection Hexagone en général et plus précisément sur la protection Hexagone sur ce jeux
y'a t'il, d'après toi, d'autre 'check' de celle-ci durant la phase de jeux ou durant le chargement des prochains niveaux ?

Car j'avoue... je suis pas joué très longtemps (c'est vraiment moche, les dev de l'époque ont bien bâclé le travail, enfin je trouve)
Ca serait une bonne idée d'en refaire une 2017, un peu comme la nouvelle version de R-type parce que la...

Concernant notre 'problématique' et sujet de discord IPF, Si dans l'INFO HEADER de l'ipf tu m’étais 00 à la valeur d'encoderType au lieu du 02 actuel, à savoir 'unknown' Ah non.... ca changerait l'interprétation dans les champs IMGE... merdeuuu....

ba t'es officiellement un faussaire alors

* * je déconne hein, je veux pas relancer le débat à ce sujet.

Auteur :	Giants [ 15 Jan 2017, 15:22 ]
Sujet du message :	Re: SugarConvDsk
Pour info, j'ai mis à jour mes scripts en ligne sur l'Analyse de fichier IPF, je passe en V3.6 J'ai ajouté sur chaque TRACK l'analyse effectué par Aufit 1.3 Et si on clique sur cette bandelette-analyse, on a l'affichage complet de l'analyse d'Aufit une copie d'écran : Pièce jointe : 3.6_1.png Dispo tjs au même endroit : http://sasfepu78.fr/Analyser.html Firefox conseillé ! Pour l'instant, juste les deux images que nous sommes en train d'analyser/parler ont été MAJ avec la derniere version de mon script, à savoir la 3.6 Les autres analyses en ligne ayant été faite avec une version ultérieure de mon script, ces images/analyse d'aufit n'y sont pas intégrée. Ca sera chose faite, semaine prochaine : pour l'instant c'est uniquement dispo sur : http://sasfepu78.fr/cgi-bin/IPFanalyse. ... _Tiger_SPS http://sasfepu78.fr/cgi-bin/IPFanalyse. ... iginal_Dsk

Auteur :	Lone [ 15 Jan 2017, 22:08 ]
Sujet du message :	Re: SugarConvDsk
Un quick fix : Le même IPF (Black Tiger) sans les problèmes de tracks inconnus. Est-ce mieux ?

Auteur :	Giants [ 15 Jan 2017, 23:42 ]
Sujet du message :	Re: SugarConvDsk
Je test ça demain, là j'suis mort, j'ai codé jusqu’à maintenant pour integrer les rapport d'aufit le plus clairement aux pages que génères mes scripts. la, c'est bon, le design me plaît. Je test Ton fichier demain matin. LAST : tiens, j'ai remarqué un bug dans mes scripts, si j'ai deux requêtes en même temps, ça foire. Faut que je change les fichier tempo, que je rajoute un truc... demain...

Auteur :	Giants [ 16 Jan 2017, 10:21 ]
Sujet du message :	Re: SugarConvDsk
Heu... La structure IPF semble pire... 2s... Ok, la version de DrCoolzip d'ipfreader en ligne n'es tjs pas corrigé (pour le bug multiple de 8), donc log généré forcément incorrecte. Et comme j'ai changé de H/W pour mon serveur wab et j'ai perdu mes source d'ipfinfo modifié, je passe tjs pas ipfreader sous windows pour generer le 1er log. On re-créer donc ce log avec ta version d'ipfreader, on sauve le tout et on relance mon script. Je te laisse comparer, Déjà au 1er coup d'oeil, ça à supprimé mes warnings sur les dernières pistes ce qui est déjà un plus. ==> http://sasfepu78.fr/cgi-bin/IPFanalyse. ... k_QuickFix et http://sasfepu78.fr/cgi-bin/IPFanalyse. ... _Tiger_SPS PS : Passage en version 3.6b, #Add protection detected by aufit on each track & aufit Track Information.

Auteur :	Lone [ 16 Jan 2017, 20:26 ]
Sujet du message :	Re: SugarConvDsk
Ca semble pas mal... Mais la réécriture fonctionne-t-elle ? Et surtout, le jeu réécrit fonctionne-t-il sur le CPC ?

CPC Rulez https://cpcrulez.fr/forum/

SugarConvDsk https://cpcrulez.fr/forum/viewtopic.php?f=8&t=5844	Page 13 sur 14

Auteur :	Giants [ 16 Jan 2017, 21:23 ]
Sujet du message :	Re: SugarConvDsk
Alors la re-écriture du jeux via l'exe officiel de SPS, à savoir DTC.EXE fonctionne.* Par contre, est ce que le jeu fonctionne sur un vrai CPC ou sur Emulateur... Ca, pas mon rayon, faut demander a quelqu'un d'autre. * On peu aussi passer par le GUI wildewutz qui est plus accessible que la ligne de commande pour re-creer une disquette à partir d'un IPF avec l'interface Kryoflux

Auteur :	Lone [ 16 Jan 2017, 21:27 ]
Sujet du message :	Re: SugarConvDsk
Sur émulateur, il fonctionne (j'ai testé quand même !). Que ca soit via la lib SPS ou ma lib perso.

Auteur :	Giants [ 16 Jan 2017, 23:23 ]
Sujet du message :	Re: SugarConvDsk
Bein en tout cas... Si on compare, au niveau IPF, le dump SPS pre-release et ta derniere version du fichier généré en IPF C'est assez blufant quand on pense que l'on par d'un EDSK. Ca reste un dump NON-original, pas un master on est d'accord mais pour moi, au vue des tous mes logs de l'IPF Ca ressemble grave. Un jolie faux en quelque sorte Par contre, je ne sais pas si tu as regardé mes logs mais : Tu as systématiquement un LGT Long Track - 64xx bytes (cette info vient d'aufit) alors que sur l'ipf de pre-release IPF, je n'ai pas ce message. On a bien, que ce soit sur ton nouveau IPF généré et sur l'IPF de pre-release SPS les messages IIF-ISL Invalid ID Field: 6 in an Invalid Sector Length (ISL) T0x.0-S1 DCE DATA CRC Error T0x.0-S1 NSD F8 is a Non-Standard DAM mais le message LGT Long Track - 64xx bytes est présent uniquement sur ton IPF. Sais pas trop pourquoi au vue des logs, ca tiens a pas grand chose au vue de la taille de la track... ou je fait fausse route, c'est possible.

Auteur :	dlfrsilver [ 16 Jan 2017, 23:45 ]
Sujet du message :	Re: SugarConvDsk
La densité peut-être ?

Auteur :	Lone [ 17 Jan 2017, 10:26 ]
Sujet du message :	Re: SugarConvDsk
Non, le soucis est sur la longueur : 6489 octets donne 103824 bit (MFM), ce qui est beaucoup pour une piste. Pourquoi est-ce ainsi ? Parce qu'en comparant ce que fournit la SPS et ce qui est généré depuis l'edsk, on voit que le secteur est positionné beaucoup plus près du trou d'index dans le cas de l'IPF. L'info est disponible dans l'Offset-Info du dsk... Mais cette donnée n'étant fiable que relativement (c'est à dire entre deux secteur), et n'ayant qu'un unique secteur dans chaque piste, on ne s'en sert pas. Du coup, placement standard du secteur, et piste bien longue. Il faudrait tester l'écriture d'un tel IPF pour valider que l'on est dans les tolérances du FDC. On pourrait tenter également une prise la non utilisation, sur certain seuils, d'un IAM (comme ç'est sans doute le cas ici) pour améliorer la conversion.

Auteur :	Giants [ 17 Jan 2017, 11:33 ]
Sujet du message :	Re: SugarConvDsk
Moi je veux bien la disquette fraichement creer dans un vrai cpc mais, je suis sencé 'rechercher' quoi ? Si le jeu fonctionne ? si c'est pas le cas, au vue de la protection sur ce jeu, je suis sencé voir quoi ?

Auteur :	Giants [ 17 Jan 2017, 12:06 ]
Sujet du message :	Re: SugarConvDsk
J'ai re-créer les deux dumps via DTC, à savoir la pre-release IPF de BlackTiger et la version IPF de lone patché. J'ai le même résultat sur mon CPC6128 d'origine, à savoir : cat m'affiche un message comme quoi il faut faire un run"disk, chose que je fait. 1 chargement qui affiche assez rapidement un image du jeux BlackTiger Suivi d'un petit accès disk (assez rapide) et d'un autre un chouille plus long (c'est quand même rapide, il ne charge pas beaucoup de donnée) Capcom présent... apparaît, on appuie sur une touche, on choisie de jouer au clavier (j'sais plus ou est mon joy), je set les touches, le jeu se lance et on comprendre pourquoi y'a pas eu beaucoup de chargement... Mon dieu que c'est moche... mais c'est pas le sujet Toutes les fonction du perso fonctionne (avancer, sauter...) Bref, dans les deux cas, le jeux fonctionne. Après... je ne connaît pas cette protection (Hexagone) ni ce jeu sur le CPC (je le connais uniquement en arcade ou c'est une bombe). Denis, peux nous en dire plus sur la protection Hexagone en général et plus précisément sur la protection Hexagone sur ce jeux y'a t'il, d'après toi, d'autre 'check' de celle-ci durant la phase de jeux ou durant le chargement des prochains niveaux ? Car j'avoue... je suis pas joué très longtemps (c'est vraiment moche, les dev de l'époque ont bien bâclé le travail, enfin je trouve) Ca serait une bonne idée d'en refaire une 2017, un peu comme la nouvelle version de R-type parce que la... Concernant notre 'problématique' et sujet de discord IPF Si dans l'INFO HEADER de l'ipf tu m’étais 00 à la valeur d'encoderType au lieu du 02 actuel, à savoir 'unknown' Ah non.... ca changerait l'interprétation dans les champs IMGE... merdeuuu.... Y'a tjs le champs reserved de 12 bytes ou tu pourrais mètre quelque chose de spécifique mais bon... le jour ou la team SPS décide d'utiliser ce champ... ca sera mort. ba t'es officiellement un faussaire alors * * je déconne hein, je veux pas relancer le débat à ce sujet.

Auteur :	dlfrsilver [ 17 Jan 2017, 13:20 ]
Sujet du message :	Re: SugarConvDsk
Lone a écrit : Non, le soucis est sur la longueur : 6489 octets donne 103824 bit (MFM), ce qui est beaucoup pour une piste. Pourquoi est-ce ainsi ? Non le souci est la densité. Les pistes d'un dump original de black tiger ne dépassent pas 6293 octets en longueur totale, y a pas 6489 octets de données..... enfin pas exactement. Quand j'examine les pistes via Aufit, je m'aperçois que les pistes sont de couleur bleue, ce qui indique une écriture avec variation de densité. Celle-ci est gérée par le format IPF. Chaque piste contient plus données dans un espace plus réduit. Comme tu ne le gères pas, ça explique pourquoi tes pistes font 200 octets de plus. Citer : Parce qu'en comparant ce que fournit la SPS et ce qui est généré depuis l'edsk, on voit que le secteur est positionné beaucoup plus près du trou d'index dans le cas de l'IPF. Oui ce qui est parfaitement normal. Le format "Hexagon 1800" est parfaitement décrit dans l'outil d'analyse, donc RAS. Citer : L'info est disponible dans l'Offset-Info du dsk... Mais cette donnée n'étant fiable que relativement (c'est à dire entre deux secteur), et n'ayant qu'un unique secteur dans chaque piste, on ne s'en sert pas. Du coup, placement standard du secteur, et piste bien longue. Ce n'est pas à proprement parler un secteur. C'est un moyen de protection, permettant de mettre le FDC du CPC aux fraises. Le FDC voit le bout de 512 octets déclaré, et laisse tomber toutes les données qui suivent, qui pour lui sont dans une énorme zone GAP de 5278 octets (ou un peu plus). Samdisk logge tout les infos d'une piste hexagon (ou speedlock) dans un énorme secteur de taille 6. Citer : Il faudrait tester l'écriture d'un tel IPF pour valider que l'on est dans les tolérances du FDC. Si tu t'intéressais un peu à l'Atari ST, tu aurais déjà la réponse à ta question. Le FDC du CPC peut gérer des pistes d'une taille allant jusqu'à 6700 octets, exactement comme l'Atari ST, si ces pistes sont dupliquées avec une machine industrielle. 6400 c'est parfaitement jouable pour un CPC, si on écrit le disque avec une carte kryoflux, la précision en écriture faisant en plus des merveilles. Citer : On pourrait tenter également une prise la non utilisation, sur certain seuils, d'un IAM (comme ç'est sans doute le cas ici) pour améliorer la conversion. Traficoter ?

Auteur :	dlfrsilver [ 17 Jan 2017, 13:29 ]
Sujet du message :	Re: SugarConvDsk
Giants a écrit : J'ai re-créer les deux dumps via DTC, à savoir la pre-release IPF de BlackTiger et la version IPF de lone patché. J'ai le même résultat sur mon CPC6128 d'origine, à savoir : cat m'affiche un message comme quoi il faut faire un run"disk, chose que je fait. 1 chargement qui affiche assez rapidement un image du jeux BlackTiger Suivi d'un petit accès disk (assez rapide) et d'un autre un chouille plus long (c'est quand même rapide, il ne charge pas beaucoup de donnée) Capcom présent... apparaît, on appuie sur une touche, on choisie de jouer au clavier (j'sais plus ou est mon joy), je set les touches, le jeu se lance et on comprendre pourquoi y'a pas eu beaucoup de chargement... Mon dieu que c'est moche... mais c'est pas le sujet Le soft est affreusement lent oui c'est clair. Citer : Toutes les fonction du perso fonctionne (avancer, sauter...) Bref, dans les deux cas, le jeux fonctionne. pas de souci. Citer : Après... je ne connaît pas cette protection (Hexagone) ni ce jeu sur le CPC (je le connais uniquement en arcade ou c'est une bombe). Denis, peux nous en dire plus sur la protection Hexagone en général et plus précisément sur la protection Hexagone sur ce jeux y'a t'il, d'après toi, d'autre 'check' de celle-ci durant la phase de jeux ou durant le chargement des prochains niveaux ? La protection Hexagon comme la protection speedlock permettant le stockage de données reposent sur un principe tout simple : 1) une partie logicielle : un encryptage dynamique des données. Tu coupes le flux en cours de décryptage, tu peux resetter ton CPC. 2) une partie physique : ces pistes écrites sur des ordis PCWs dotés de FDC spéciaux jouent sur le principe qu'un CPC gère principalement les données en mode secteur, tandis que les machines de duplication elles gèrent en mode piste uniquement. L'astuce étant de mettre un bout de secteur mal déclaré en tête de piste pour mettre le FDC du CPC aux fraises. Il ne lit que les 512 premiers octets du secteur, et tout le reste est vu comme une immense zone GAP. Comme le CPC ne sait pas non plus copier les zones GAP (et en particulier aussi grosses), la copie est un échec garanti. Citer : Car j'avoue... je suis pas joué très longtemps (c'est vraiment moche, les dev de l'époque ont bien bâclé le travail, enfin je trouve) Ca serait une bonne idée d'en refaire une 2017, un peu comme la nouvelle version de R-type parce que la... Si y avait besoin j'ai tout les graphismes du jeu rippé proprement de l'Arcade avec toutes les bonnes palettes dans un coin. Citer : Concernant notre 'problématique' et sujet de discord IPF, Si dans l'INFO HEADER de l'ipf tu m’étais 00 à la valeur d'encoderType au lieu du 02 actuel, à savoir 'unknown' Ah non.... ca changerait l'interprétation dans les champs IMGE... merdeuuu.... lol Citer : ba t'es officiellement un faussaire alors * * je déconne hein, je veux pas relancer le débat à ce sujet. Bah je pense que c'est ça en fait

Auteur :	Giants [ 17 Jan 2017, 17:08 ]
Sujet du message :	Re: SugarConvDsk
si il y a plus de donnees su une piste que le standard, ca veux dire qu'ils ont surrement 'ralentie' le moteur du fdc au moment d'ecrire ces donnees, enfin j'imagine, c'est une methode, on peu aussi 'accelerer' l'ecriture avec un fdc specifique, enfin...j'imagine aussi. Ce que je trouve drole, c'est qu'au final, on retrouve plus de donnees que la 'normal' sur un media ca veux dire que les media utiliser lors de la creation via traceuse donc (tracer, traceur, raceuse ?) etaient de meilleurs qualitee que la moyenne ? Ou, que physiquement, sur nos disquettes 3p, on 'pourrait' contenir plus d'info. ca ne serait pas un probleme de 'desnité' du support mais bien une limitation au niveau du fdc sur le cpc !? Ce qui est drole dans tout cas, c'est que le cpc arrive a lire cette...hummm...finesse de 'gravure' mais n'arrive pas a l'ecrire... ca a ete voulus d'apres vous a la conception du fdc ? c'est a dire que le fdc du cpc ai des meilleurs capacité H/W en lecture qu'en ecriture. ou c'est peu etre comme ca sur toutes les becanes ?

Page 13 sur 14	Le fuseau horaire est UTC+1 heure
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/