Ouai mais dans le bonux, y'a un cadeau (enfin y'avait, à mon époque).

Tiens Lone, j'ai la fleme de chercher, si tu réponds plus vite que ma recherche google, je prends.
Je ne connait pas du tout le format cdt mais, comment se fait t'il que si je regarde avec un editeur hexa un dump cdt
je ne voie pas les data en 'réel' comme je pourrais les voir dans un 'dsk'.

les disquettes, c'est de l'aléatoire, puisque le FDC peut prendre les données n'importe ou sur la disquette, tandis que les cassettes, c'est de la donnée séquentielle. Il faut partir du début de la bande, et aller vers la fin.

Ensuite qu'est-ce que tu appelles les données en réel ? Contrairement à ce que tu pourrais penser, on trouve assez régulièrement des données ou des portions de données identiques entre les versions disquettes et cassettes des jeux.

_________________
SPS Community Expert (SPS CE) / SPS France

En principe, tu peux en voir certaines en clair : Ca dépend, en fait, du type de block utilisé (se reporter au format TZX pour avoir plus de détails).

C'est certain que si le jeu utilise des blocs custom avec encodage MFM, ou encore de la donnée cryptée, tu ne verras rien.

C'est le cas des jeux speedlock, qui utilisent toute une batterie de système anti-hacking, et d'autres

_________________
SPS Community Expert (SPS CE) / SPS France

Ok, ca réponds à ma question.

Je viens de finir de dumper la compilation la sélection d'Ocean.

Voici les CDT et les WAV digitaux. Je ne fournis pas les WAV d'origine, car en mauvais état et pas utilisables tels quel.

_________________
SPS Community Expert (SPS CE) / SPS France

Messieurs, j'aimerais attirer votre attention sur l'information suivante :

J'ai traité aujourd'hui le jeu Daley Thompson Olympic Challenge pour Breitztiger (une version alternative).

Je viens de m'apercevoir que le lecteur qu'il utilise pour dumper ses jeux amstrad a un problème matériel.

Voici pourquoi : Le premier dump indique que la piste 0 du dump est modifiée. Ce qui m'interdit la génération d'IPF. Breitztiger utilise alors un autre lecteur pour redumper le jeu, me le soumet, et la, plus de piste 0 modifiée.

L'explication est simple : la disquette en elle-même est sale, crasseuse et lue tel quel par le lecteur, ce qui engendre un lag au niveau de la lecture des données.

Le fait est que pour détecter les jeux modifiés, l'outil se base sur la taille des GAP intersecteurs. Il suffit d'un seul dont la taille varie, pour mettre l'outil en alerte.

Donc, comme avec cet autre lecteur la piste 0 est lue correctement, il est facile de déduire que le lecteur utilisé en premier lieu par Breiztiger a un problème, surement aggravé par la saleté rencontrée par la tête de lecture.

Je l'ai donc encouragé à utiliser le lecteur qui lui a donné une lecture correcte de la piste.

PS : que ce soit sur Amiga, ST, CPC, C64 ou Spectrum, il est de la responsabilité du contributeur de dumper avec du matériel testé et révisé, et pour ne pas accentuer la fatigue des lecteurs de nettoyer systématique à l'alcool la surface des disquettes avant dump si ces dernières ne sont pas propres.

Aufit permet de vérifier visuellement l'état des disquettes.

Ne pas appliquer ces mesures ne peut conduire qu'à des erreurs voir à déclencher des faux positifs quand je génère les IPFs.

_________________
SPS Community Expert (SPS CE) / SPS France

Blup !

Je viens de mettre en ligne pour Hermol une trentaine de scan de très bonne qualitée (pour la plus part, 300 dpi et net)
de jaquette de jeux K7 pour Amstrad, il y a aussi des notices.

Je laisse Hermol faire ca sauce et le rendre dispo des qu'il aura mis la forme qu'il souhaite au package.

Denis, tu peux aussi aller sur ma page : http://sasfepu78.fr/scp/
te connecter et downloadé tous les nouveaux K7 que je viens de mettre en ligne
ca doit commencer a... voyons voir, un truc comme ca 4019, 4020
Les autres, je pense tu as déja fait.

Bien sur, tous ca se sont des DUMPs originaux de jeux CPC, sauvé en WAV et digitalisé depuis un CPC464 (on oublies la platine).

Et bonne année à tous.

Suite de mes pérégrinations avec les IPFs.

Je suis finalement parvenu à coder un générateur d'IPF. Pas forcément trivial, il y a une certaine tournure d'esprit à prendre (et la philosophie est un peu trop tournée vers les secteurs à mon gout), mais ça fonctionne a peu près.

Evidemment, je mets un ID de dump fantaisiste, un ID de créateur tout aussi fantaisiste (dommage par ailleurs qu'on n'ai pas une chaîne ascii plutôt qu'un ID).

Pour le moment, tout n'est pas (encore) correctement créé, mais j'ai réussi à faire passer quelques jeux tout de même.

Mon test est assez succinct : Je charge un jeu quelconque (en dsk ou ctraw), je le sauve en ipf, et je teste le chargement avec caprice version capslib.

Il me manque évidemment le test le plus important pour un IPF, qui est l'écriture sur un disque.
En PJ vous trouverez deux IPF générés par mes soins (rien à voir avec la sps !), si quelqu'un d'équipé peut tester le redump sur un support, ça serait pas mal (si ça ne marche pas, un dump kryoflux ou ctraw m'intéresse au plus haut point !)

Pour les autres, ça peut vous permettre de donner à manger à votre caprice32_IPF ou votre sugarbox (mais rien de spectaculaire la dedans), ou de voir que le format permet de voir les données assez clairement (par rapport à n'importe quel format MFM, ou un RAW Kryoflux, par exemple)

Si vous avez des questions sur le sujet, je commence à être calé.

Au passage, une petite doc sur le format ct-raw est dispo ici :
http://www.cpc-p0wer.com/cpcarchives/in ... es&num=386
Pas forcément très complète, mais qui ne demande qu'à répondre aux questions !

Ne perds pas ton temps, ton outil sera caduque d'ici peu de temps. La lib n'a pas été ouverte pour que les gens puissent générér tout et n'importe quoi, et pire encore, faire des IPFs depuis un DSK.

C'est une ineptie totale.

_________________
SPS Community Expert (SPS CE) / SPS France

Moi je veux bien tester ton truc, pour le fun
Mais comme denis à dit... générer des IPF (peu importe officiel ou pas) à partir de Dsk....j'ai loupé un truc. (ou c'est juste pour le test)
A partir de Ct-raw j'en sais rien si ca tiens la route car je ne connais pas ce format mais a partir d'un dsk...
Bref, on vas dire que c'est pour le test.

Bon je test mais sans conviction.
Marche pas sur un vrai CPC6128 tes deux images

C'est gravé sur une disquette 3p réel à partir de Kryoflux sous Windows10 le tout avec l'interface Wildezutz 0.7
Et il écrie avec cette commande :

DTC.exe -f"e:\fs.ipf" -e43 -d0 -dd1 -w

barb.ipf = catalogue ok (barb1a), le jeux se charge (barbarian) et on peu jouer.
fs.ipf = catalogue OK (DISK), le jeux se charge (Flying Shark) et on peu jouer.

Voila : Dump effectué, va regarder tes MP

Les IPF générés sont corrects (ceux qui marchent), et pas plus soumis à l'obsolescence que ceux générés par l'actuel outil (même version de format).

Par ailleurs, ne nous méprenons pas : Le format IPF n'est qu'un format de description de disque, destiné à faire un master. Une sorte de dsk destiné à la génération d'un disque si vous voulez.

A partir de là, on peut bien le générer à la main, via un dsk, un ct-raw ou bien autre chose que ça ne changerait pas grand chose.

Son but est bien de (re)construire une disquette (mais pas d'en faire une copie exacte).

D'ailleurs, c'est pas pour rien que cpc-p0wer mentionne IPF et dsk dans ses formats : Un pour l'émulation facile, l'autre pour la regénération de disquette. Il ne manquerait qu'un format scp ou kryoflux pour la préservation elle-même (mais bon, ça prendrait autre chose comme place...)

Je pense que ce que voulais dire denis par obsolescence c'est que pour l'instant la seul façon normal de lire les IPF
sur n'importe quel emulateur est la LIB SPS.

L'outils que tu fait n'est pas 'standard' et pour l'instant, n'est pas en libre download et si il l'est, il le sera uniquement sur CPC
et que sur Suguar Box (du moins dans un premier temps)

Ok, les IPF que tu fait fonctionneront tjs vue que ton les lies avec ta routine.

Mais si demain, SPS crypter ses IPF ET modifie ca lib (comme déja dit pas denis)....
Bein Toutes les anciennes images IPF ne seront plus 'valide' car pas crypté et detecté en 'non valide' pas la nouvelle lib SPS
(Crypter 8000 images n'est pas un problème pou moi en script alors pour une team comme sps... je ne pense pas que ca leur pose de probleme).

Les seuls que l'on pourra 'lire' seront les anciennes images IPF (et non complète car, sur CPC, on commence seulement le re-dump)
et les images IPF re-creer via ton outils.

TOUTES les nouvelles images IPF crypté .... ca sera dans le cul la balayette. (si j'ai bien tout compris).

Je reviens donc sur mon précédent mail ou je disait...
Sachant que la team en question est très alerte sur ce sujet et pas vraiment Open aussi sur ce sujet.
Pourquoi en parler ici dans un forum public ?! Ca me parait...suicidaire.

Quand l'on pose un copyright sur un truc, que l'on vends la box en question un prix assez élevé, que l'on donne
des informations au compte goutes et quelque années après, non complète, c'est qu'il y a une réel volonté de protéger le Truc en question.
Là, a mon avis, tu prends un risque.

Et je dit ca sans partie pris, je ne suis pas de SPS *
* Ceci dit, j'aurais bien aimé

Petite inversion entre little et big endian.
Le big endian, c'est MSB first, le little c'est LSB first.
Le Z80 est little endian, comme les x86. Les 68k/PPC sont big endian.

Merci de la précision Gerald, j'ai (souvent) inversé les deux.

@Giant, je ne sais pas si la SPS a vraiment une volonté de crypter et fermer leur format. Les forum kryoflux (plus ou moins leur camps de base) me laissent plutôt croire le contraire.

Je pense qu'ils n'ont pas pour but de fermer le format (tout montre plutôt le contraire), mais de maîtriser leur manière de récupérer les dumps, via un processus maitrisé (récupération des dumps via des gens de confiance uniquement)

Par ailleurs, je doute qu'ils aient plus qu'un intérêt poli pour le cpc (et sans doute aucun pour Sugarbox en particulier), leur truc, c'est plutôt ST/Amiga manifestement.

Ils ne sont surement pas aussi méchant que l'on le croit