Inscription : 21 Août 2008, 16:03 Message(s) : 342
Tu sais, je me suis aussi cassé les dents il y a quelques temps dans le monde 'scene' du CPC. Pour avoir 'pratiqué' le même type de 'relation' sur atari et amiga, il faut avouer que sur CPC, c'est spécial. Mais bon... c'est comme ca ! Faut passer à autre chose, on ne peu pas forcer les gens.
Ou alors... avec un bon couteau OU une petite cuillere... à voir !
Hors sujet mais, vous avez déja cherché : SPS Amiga via google en mode recherche video ? On tombes que sur des videos X hard MAIS ILS FONT QUOI EXACTEMENT SPS ???
@giants : tes dumps des disquettes systèmes sont ils vierges ou avec des +? a chaque ligne ? edit : je viens de verifie c'est comme les miennes, toutes les pistes sont vues comme modifiees
@ldanieels : la communaute Amstrad est tres petite il est vrai mais il y a toujours moyen de dumper les disquettes lors de rassemblement je pense; perso j'amene mes lecteurs 3", le scp et le kryo lorsque je vais a la ReSeT a Coutances. Eliot relaye l'info sur le site comme quoi il y a moyen de dumper les disquettes amenées et cela se fait ... il est vrai que certain jeu ne seront plus trouvable ou bien le support trop abime, ils ont quand meme 30 ans !!! un grand merci pour le prêt de tes support a denis pour le plus grand plaisir de tous
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
dlfrsilver a écrit :
Citer :
juste un truc qui m'échappe sur votre échange à ce sujet...
de ma compréhension, le FDC calcule forcément un CRC quand il lit les DATA... par contre, si lors de l'écriture de la disquette on en a pas mis ou on en a écrit un faux, le FDC lit les deux octets après les datas et ressort une erreur adéquate si c'est pas les mêmes entre le CRC calculé et les 2 octets lus !! donc, si on veut pas d'erreur, il faut qu'il soit présent entre les données et le gap ?!?
Justement. Merci d'avoir posté sur le sujet. Ta réponse, et ce que tu dis illustre fondamontalement ce que je disais plus haut.
Toi, comme d'autres personnes ne voyez les choses qu'au travers du prisme de l'Amstrad. Pour comprendre les systèmes de protection contre la copie, il faut voir plus large, et connaitre d'autres machines.
Les pistes speedlock étaient gravées et/ou préparées soit sur un PC soit sur un Atari ST (forte probabilité que ce soit ce dernier, les jeux Speedlock Amstrad K7 étaient préparés via un Atari ST, d'après Bob Pape.
Quand on pense système ou pistes de protection physiques, on pense pistes indépendantes du système cible. C'est à dire que le système cible ne peut que lire les pistes, qui ont été écrites par une autre machine.
Oui, de base, sur des pistes générées par un amstrad CPC, ce que tu dis es vrai. Il y a un CRC automatiquement sur les pistes, on est bien d'accord.
Seulement voilà, dans le monde de la protection contre la copie, les règles usuels ne s'appliquent pas. Comme les duplicateurs sont entièrement paramétrables, tu peux leur faire graver tout et n'importe quoi.
C'est la que l'histoire des CRCs arrive : La personne qui crée le format de piste peut ou non mettre un checksum sur la piste ou pas du tout.
Un nombre de jeu plus grand que tu ne le penses n'utilise pas de CRC sur certaines pistes. J'expliquais à Kukulcan comme à Maxit que Samdisk ne supportant que les pistes avec CRC, dès qu'il en voit qui n'en ont pas, il se met à radoter, car si je ne me trompe pas, il cherche à en calculer un qui évidemment ne collera pas avec la somme réelle des données.
Citer :
Personnellement, je me suis juste pas mis à l'émulation de l'ipf car nous n'avons que très peu d'exemple d'ipf amstrad vu qu'il n'y a pas de distribution à ce jour plus large (cf les explications de dlfrsilver ) !!!
Pour c'est pas si compliqué, la lib prend tout en charge, l'émulation du FDC, le décodage des disquettes, la prise en charge du format de piste, etc, etc.
en fait, je pense que tu m'as lu un peu vite... comme je te l'ai écrit, j'ai vu l'émulation d'abord par rapport à ce que lit le FDC... donc je te le réécrit, le FDC lit deux données à la fin de la zone données, s'il ne trouve pas le CRC16 qu'il a calculé -> il renvoie une erreur (via les Status)... donc, cela n'est pas incompatible avec ce que tu as expliqué et le fait que sur le master d'origine et la machine qui a servit à fabriquer le disque on est fait ce qu'on veut avant !!! je comprends tout à fait le principe du master / de la machine de masterisation qui est indépendant de la machine (ou du FDC plus précisément) qui lira le disque original final !
d'ailleurs à ce jour, à part les quelques dsks que j'interprète mal car ils ne sont pas conformes ou mauvais dumps -> toutes les protections passent sans pb d'un point de vu émulation amstrad ! Je te rassure, la plupart de ces dsks sont souvent corrigés quand tu (vous) les refais ! Et je ne cesserai de vous remercier à chaque fois pour saluer votre travail et votre dévotion à fournir des dumps pour la préservation de ces merveilles ! J'en profite pour lancer un appel à un redump de la face B de prohibition (version 464) qui n'a pas la protection sur les dsks que j'ai trouvé !
Concernant le SPS , je considère depuis le début que leur entreprise est louable pour la préservation... Et comme ils ont commencé par les dumps amiga, j'ai donc naturellement contribué à leur début en obtenant le logiciel de dump sur amiga (j'avais l'amiga qui va bien pour le faire ) ! On peut toujours débattre sur des détails, mais cela à le mérite d'exister... c'est un peu comme internet, ça pourrait être mieux, c'est pas parfait, mais c'est déjà pas si mal vu tout ce qu'on peut en faire aujourd'hui !!!
Concernant l'utilisation de leur lib... le premier point, cela reste une dll compilée pour windows... quand on fait un émulateur en html5/javascript qui marche sur tous les navigateurs, os, pc et téléphone... cela reste dur à implémenter (à part si Lone m'explique comme interpréter l'ipf, et surtout le format CT-RAW où j'ai pas la spécif ). Ca c'est le point de vue technique à mon niveau de connaissance !
Le deuxième point, c'est que trouver des dsks ici sur cpcrulez ou ailleurs c'est facile... Les ipfs amstrad restent peu diffusés comme tu l'as expliqué...
Donc cela fait deux difficultés, du travail sur le code car je ne peux pas utiliser la library d'origine facilement + le fait que même si je le réalisais cela il n'y aurait pas bcp de personnes qui vont l'utiliser vu la rareté des ipfs amstrad dispo pour monsieur tout le monde !!!
Bref, il faut continuer à dumper,coder,etc. et à avoir la passion qui nous anime tous !!!
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
ldaneels a écrit :
Coup de gueule, oui. Mais après 15 ans à se faire mettre des bâtons dans les roues à chaque tournant (merci à Gauthier Morand qui continue de manipuler la vérité sur mon sujet, tu as ma haine éternelle), ça commence à peser & quand les discussions partent sur des grands sujets comme si ceux qui prêtent n'existaient pas, il y a de quoi. Mais il faut parfois remettre les choses en perspectives. On est bien loin du monde C64 où le projet GB64 rallie les (nombreux) fans de la machine dans un climat positif. Sur CPC, on a deux pelés et trois tondus vraiment intéressés à faire avancer les choses & le reste se bouffent entre eux. Un grand merci notamment à tous ceux qui participent activement à la mémoire du CPC. Enfin bon, je continue mon petit bonhomme de chemin & évite majoritairement les forums (sauf ce topic qui m'intéresse beaucoup au demeurant), donc pas de soucis. Pour MO5, je suis passé par là (j'ai même donné de nombreux logiciels), mais je ne suis pas trop sûr que ce soit la meilleure solution pour plein de raisons.
En tout cas, même si on est une poignée d'irréductibles à être derrière vous, je vous le réécrit : MERCI ÉNORMÉMENTpour tout ce que vous faite pour la préservation !
N'hésitez pas à demander notre soutien !!! on peut même créer un topic spécial merci (histoire de ne pas polluer ce magnifique sujet actuel) si cela contribue à vous remonter le moral... Vous verrez peut-être même, qu'en plus des irréductibles qui osent prendre un peu de leur temps pour vous aider/soutenir, un tas d'inconnus sont surement prêt à vous soutenir aussi par leurs mercis chaleureux et sincères !!!
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Merci à Loic pour son soutien, et bien entendu à nos généreux collectionneurs.
Concernant les IPFs ceux-ci embarquent de la compression. Je le confirme.
Sinon, les fichiers seraient beaucoup plus gros puisque les données sont stockées sous forme de bits.
Il se pourrait qu'à l'avenir d'ailleurs, les IPFs en terme de contenus soient encryptés en plus d'être compressés.
Pour la disponibilité des IPFs amstrad, j'ai juste eu des consignes, que j'applique parce qu'on me l'a demandé. Par contre, en récupérant les IPFs pour amstrad officiels, vous pourrez en faire ce que vous en voulez
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 21 Août 2008, 16:03 Message(s) : 342
Donc en clair, une fois un dump effectuée par une personne, celui-ci reçoit apres une version IPF de celui-ci (en partant d'eu principe que le dump est bon, qu'il n'a pas encore été fait, etc).
Cette version IPF reçu est 'officiel' : crc, id SPS La team SPS ne se donne pas le droit de diffuser cette IPF MAIS... que celui qui à crée le dump (et qui à donc reçu l'IPF) peu en faire ce que bon lui semble. C'est lui en quelque sorte qui sera responsable si probleme il y a (legalement j'entends) de sa difusion !
Inscription : 20 Août 2013, 18:03 Message(s) : 258
dlfrsilver a écrit :
Il se pourrait qu'à l'avenir d'ailleurs, les IPFs en terme de contenus soient encryptés en plus d'être compressés.
Et pourquoi les encrypter ? Pour que seul la SPS puisse les lire ? Ou seul ceux payant une licence à la SPS ?
Encryption et Preservation sont deux chose incompatible. Pour moi, un format de préservation doit être ouvert, donc documenté. Ce que ne semble pas être le cas.
Je suis d'accord avec Gérald, si le format devient de plus en plus ferme, non documente, pour que personne ne puisse l'utiliser par ses propres moyens comme est en train de le faire Thomas et d'autres, alors l'ipf annonce la fin avant d'avoir commencé à être vraiment utilisé
Il restera les dumps raw du kryoflux, qui sont utilisable assez facilement (cf les conversions que fait samdisk où il excelle ), car comme dit Giants la taille n'est plus un Probleme aujourd'hui (le set de mame avec chd depasse les 400go et pourtant pas mal de gens l'ont sur leur machine). Le flux raw compressé d'une face de disquette Amstrad doit faire environ 5mo maximum, donc parfaitement faisable de stocker tous les originaux sur une clé USB je pense.
Ensuite, même si certain pense qu'il soit utopique de lancer un nouveau format, différent projet ont commencé dans ce sens, et je pense qu'une poignée de personne motive peut abattre ce genre de travail sans Probleme n'en déplaise à quelque personne bien pensante ...
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Giants a écrit :
Donc en clair, une fois un dump effectuée par une personne, celui-ci reçoit apres une version IPF de celui-ci (en partant d'eu principe que le dump est bon, qu'il n'a pas encore été fait, etc).
Cette version IPF reçu est 'officiel' : crc, id SPS La team SPS ne se donne pas le droit de diffuser cette IPF MAIS... que celui qui à crée le dump (et qui à donc reçu l'IPF) peu en faire ce que bon lui semble. C'est lui en quelque sorte qui sera responsable si probleme il y a (legalement j'entends) de sa difusion !
C'est ca ?
Les IPF que je génère sont dit temporaire, c'est à dire qu'ils permettent à celui qui dumpe d'avoir dans l'immédiat un IPF de son original, par contre pour l'iPF officiel numéroté (la version diffusable), il faudra attendre qu'ils traitent ce qui aura été uploadé (ou autre chose, car vu le nombre de jeux passés en IPF, ça va leur faire une montagne de soft à traiter, mais bon, peut-être que le nouveau système permettra de batcher tout ça en un coup, à voir).
@Breiztiger : rien ne t'empêche de dumper pour d'autres utilisateurs, et ensuite de m'envoyer les dumps à traiter. Ca me ferait gagner bien évidemment du temps.
Je m'occupe personnellement de Loic, Antoine et Philippe, donc si tu veux dumper pour d'autres personnes qui ont des originaux CPC, you're welcome.
J'en profite aussi pour te demander d'utiliser systématiquement le fichier BAT que j'ai fourni il y a quelques temps, qui permet de renseigner la version du soft dumpé, retail, compil ou encore budget, avec l'année, et ainsi de suite. Ceci pour rester carré avec la préservation en elle-même, et savoir ce qui a été dumpé, et pour que l'on puisse s'y retrouver.
Clairement, et je le dis, si des gens viennent à générer eux même des IPFs, ça rentrera en conflit avec ceux générés officiellement, et la je ne garanti absolument pas la suite des évenements.
Je sais bien que l'IPF est un format partiellement ouvert, et en partie fermé. Faisons en sorte de l'utiliser au mieux, et de sauver un maximum de jeux CPC, le reste n'est qu'accessoire.
_________________ SPS Community Expert (SPS CE) / SPS France
Après quelques corrections de bug, j'arrive à lire 88 IPF sur les 91 que l'on a pu me fournir (immense merci à mes généreux prêteurs, ils se reconnaîtrons).
Les trois qui ne marchent pas ne fonctionnent pas mieux sur Caprice (qui me sert de référence). Il y a, entre autre, le fameux After Burner, qui marche quand on régénéré une disquette pourtant... Il va falloir débugger le loader sans doute pour comprendre ce qu'il veut...
Par contre, sur ces 91 ipfs, je n'ai toujours pas vu de compression. Elle existe dans un chunk utilisés par les ct-raw (le chunk "PACK", je le sais, mais je ne pense pas que ce fameux chunk soit utilisé dans les IPF (ou alors, ultra marginalement).
C'est d'ailleurs ma prochaine étape, qui va être un peu plus compliquée parce que là, je n'ai que le code source pour comprendre de quoi il retourne
Par ailleurs, j'ai cru comprendre que la SPS avait tendance à ouvrir le format (bonne nouvelle !) plutôt qu'à le refermer, même si, j'imagine, elle entend conserver sa numérotation et son référencement (après tout, pourquoi pas)
Megachur, si tu veux intégrer un loader ipf, on en recause entre nous : le mien fait moins de 600 lignes de C++ (et encore, plutôt bordélique verbeux, aéré (bordélique, quoi)). Rien de complexe, du coup.
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Lone a écrit :
Après quelques corrections de bug, j'arrive à lire 88 IPF sur les 91 que l'on a pu me fournir (immense merci à mes généreux prêteurs, ils se reconnaîtrons).
Tant que ça reste en off, c'est bon.
Citer :
Les trois qui ne marchent pas ne fonctionnent pas mieux sur Caprice (qui me sert de référence). Il y a, entre autre, le fameux After Burner, qui marche quand on régénéré une disquette pourtant... Il va falloir débugger le loader sans doute pour comprendre ce qu'il veut...
Je ne te le fais pas dire
Citer :
Par contre, sur ces 91 ipfs, je n'ai toujours pas vu de compression. Elle existe dans un chunk utilisés par les ct-raw (le chunk "PACK", je le sais, mais je ne pense pas que ce fameux chunk soit utilisé dans les IPF (ou alors, ultra marginalement).
En fait, elle y est, car le contenu des pistes n'est pas consultable en dehors du traitement par la lib. Cette info je l'avais lue au sujet des ipfs pour amiga, et il était dit que le contenu est compressé.
Citer :
C'est d'ailleurs ma prochaine étape, qui va être un peu plus compliquée parce que là, je n'ai que le code source pour comprendre de quoi il retourne
En fait, tu n'as accès qu'à la partie ouverte, c'est à dire la partie émergée de l'iceberg. La partie imergée est closed source, les routines, algo propriétaire ne sont pas public.
Citer :
Par ailleurs, j'ai cru comprendre que la SPS avait tendance à ouvrir le format (bonne nouvelle !) plutôt qu'à le refermer, même si, j'imagine, elle entend conserver sa numérotation et son référencement (après tout, pourquoi pas)
Oui ils ont donné l'accès aux informations capitales pour lire les ipfs via la lib, ce qui veut dire que oui la partie implémentation est ouverte, ceci dans le but d'accrocher la lib à un émulateur. Mais ça ne va pas plus loin. Le reste des infos est closed source.
Citer :
Megachur, si tu veux intégrer un loader ipf, on en recause entre nous : le mien fait moins de 600 lignes de C++ (et encore, plutôt bordélique verbeux, aéré (bordélique, quoi)). Rien de complexe, du coup.
L'incorporation de la lib à un ému comme dit Thomas, c'est pas bien compliqué quand on sait ce qu'on code. Tu devrais donc t'en sortir et y arriver
_________________ SPS Community Expert (SPS CE) / SPS France
Par contre, sur ces 91 ipfs, je n'ai toujours pas vu de compression. Elle existe dans un chunk utilisés par les ct-raw (le chunk "PACK", je le sais, mais je ne pense pas que ce fameux chunk soit utilisé dans les IPF (ou alors, ultra marginalement).
En fait, elle y est, car le contenu des pistes n'est pas consultable en dehors du traitement par la lib. Cette info je l'avais lue au sujet des ipfs pour amiga, et il était dit que le contenu est compressé.
Denis, je lis et décode les IPFs en intégralité. Sans utiliser la lib, mais avec mon propre code.... Et sans voir de compression.
Il y a une manip facile à faire pour le vérifier : - Prendre un ipf (par exemple, "after burner") - Prendre le dsk correspondant - Ouvrir le dsk avec un éditeur hexa (genre HXD) - Chercher une chaine de caractère (pour after burner, "SPEEDLOCK DISC" - en clair sur la piste 0) - Ouvrir l'IPF, et vérifier que l'on retrouve, tout aussi en claire (et donc, non compressée) ladite chaîne.
D'ailleurs, si l'on prend n'importe quelle partie d'un secteur du dsk, on le retrouve dans l'IPF... (On voit pas mal de "4E" typique des GAP, également)
Citer :
Citer :
C'est d'ailleurs ma prochaine étape, qui va être un peu plus compliquée parce que là, je n'ai que le code source pour comprendre de quoi il retourne
En fait, tu n'as accès qu'à la partie ouverte, c'est à dire la partie émergée de l'iceberg. La partie imergée est closed source, les routines, algo propriétaire ne sont pas public.
Ah ben pourtant, les sources sont dispo...
Citer :
Citer :
Par ailleurs, j'ai cru comprendre que la SPS avait tendance à ouvrir le format (bonne nouvelle !) plutôt qu'à le refermer, même si, j'imagine, elle entend conserver sa numérotation et son référencement (après tout, pourquoi pas)
Oui ils ont donné l'accès aux informations capitales pour lire les ipfs via la lib, ce qui veut dire que oui la partie implémentation est ouverte, ceci dans le but d'accrocher la lib à un émulateur. Mais ça ne va pas plus loin. Le reste des infos est closed source.
Ben ça a changé Denis, j'ai trouvé ces infos (chez l'excellent Dr Collzic) et les ai utilisées, pour supporter l'IPF sans librairie externe... Et sans trouver ça compliqué !
Inscription : 21 Août 2008, 16:03 Message(s) : 342
>breiztiger
Techniquement je suis d'accord avec toi, on à je pense ''sous le coude' des personnes capables de créer ce nouveau format. Le problème n'est pas majoritairement technique mais humain.
Beaucoup d'entre nous ont la trentaine bien trempé pour pas dire 40 Beaucoup d'entre nous ont une p'tite famille et pas beaucoup de temps libre. Du coup, Il faut l'envie et le temps et ça, ca c'est pas fait depuis 10ans, je ne voie pas pourquoi ça changerait maintenant.
Mais de toute façon, avec les p'tites ressources que l'on a actuellement, je dirais que ce n'est pas vraiment un problème. Le truc c'est de dumper un max d'originaux au 'format' Flux ET de proposer ceux si à tout le monde (via par exemple CPC-rulez ou autre, peu importe) Ensuite, via denis de SPS, ont peu valider la qualitée des dumps et crée des IPF et, par la suite, au cas où, si la situation venait à changer, (un nouveau format émergement), on n'aura pas besoin de tout re-dumper vue qu'on aura les archives FLUX.
On a un pré-team de 'Dumper' (voir message de denis plus haut) un peu partout en france. Pour que le projet avance, je pense qu'il ne faut pas attendre que l'on nous envoie des originaux mais aller les chercher la ou il y en a le plus.
Il faut chercher dans ces connaissance, en général dans le monde du CPC donc, des personnes ayant pas mal d'originaux et leur demander des prêts le temps de scan. Bien leur faire comprendre que ca serait fait une fois pour toute (format flux), et que ca n'a jamais été fait. Le but étant la préservation, pas le fonctionnement (le dsk le fait très bien cà).
Niveau confiance c'est assez facile à mètre quelque chose en place. Il suffit que la personne qui prête ces disk notes exactement ce qu'il envoie. on dump, et on lui renvoie EXACTEMENT la même chose (aucune perte).
Perso je vais essayer d'en parler a quelque personne autour de moi. Je vous propose d'en faire de même.
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 53 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
) !!! 
! Et je ne cesserai de vous remercier à chaque fois pour saluer votre travail et votre dévotion à fournir des dumps pour la préservation de ces merveilles !
je le réalisais cela 
!!!
), car comme dit Giants la taille n'est plus un Probleme aujourd'hui (le set de mame avec chd depasse les 400go et pourtant pas mal de gens l'ont sur leur machine). Le flux raw compressé d'une face de disquette Amstrad doit faire environ 5mo maximum, donc parfaitement faisable de stocker tous les originaux sur une clé USB je pense.
n'en déplaise à quelque personne bien pensante ...