Inscription : 29 Août 2007, 12:04 Message(s) : 1990 Localisation : seine et marne 77
Citer :
Parce que le DSK c'est mal. En fait, je ne vois que le CDT qui soit pire (et que j'ai d'ailleurs refusé de gérer dans ACE).
La taille n'est vraiment plus un soucis de nos jours (même sur MorphOS), et je préfère privilégier une émulation fidèle basée sur des formats raw (fichiers audio pour les K7 et HFE pour les D7) plutôt que de m'embêter à gérer des formats sans queue ni tête comme le DSK ou le CDT.
Bonjour, sans être aussi fan que Breitztiger du format DSK, c'est un format quand même bien pratique, ce malgré ses imperfections et ses à peu près.
Par contre, là ou je m'inscris en faux, c'est pour le CDT. Celui a conçu ce format a eu une idée de génie. Le format CDT est l'équivalent des IPFs : Pourquoi ?
Tout simplement parce qu'il est totalement 'libre' en terme de description de format de bloc.
Concrètement : les ID d'entête (pilot tone, bit 0 et 1 et ainsi de suite), correspondent à ce qu'on trouve dans une cassette originale. Ensuite, la description des blocks est elle aussi parfaitement au point.
Si tu pars du principe que ce système est imprécis, ou est buggé, tu te trompes lourdement. J'ai aidé et je suis en même temps co-auteur avec CNGSOFT de l'outil csw2cdt, qui permet de faire des encodages totalement propres des jeux ou utilitaires en K7.
Les anciens outils comme samp2cdt, et consort faisaient un encodage dégueulasse et imprécis, sans parler du support complètement foireux des protections.
Aujourd'hui au moment ou je te parle, les CDTs générés par csw2cdt sont absolument niquels. On injecte dans les CDTs exactement ce qui se trouve dans l'extraction des données faite depuis une cassette originale.
Et quand tu me parles de format RAW ou brut, j'en déduis que tu fais partie de ces zozos qui s'imaginent qu'on peut mettre en fichier, comme ça tranquille, sans s'assurer de la validité des données qu'on met dans le dit fichier RAW et hop. Heureusement que les gens comme moi qui s'assurent de la préservation du patrimoine de l'Amstrad CPC on ne part pas de ce principe là.
L'analyse des données est un impératif et un impondérable, on ne peut y déroger en se disant "vas-y c'est bon là, hop je prends ma cassette, je la lis et je la sauvegarde".
Ca pardon du terme, mais c'est la préservation pour les débiles ou les mongoles. On ne peut pas et mieux on ne doit pas utiliser uniquement des enregistrements bruts, car les supports ont 30 ans, ont des erreurs qu'il faut corriger avec des outils spécialisés, etc etc etc.
Le format DSK n'est pas parfait du tout, approximatif, mais il a une chose de bonne : la vue sur le fait que les données soient bonnes ou pas bonnes. Avec un format RAW, tu n'as rien de tout ça.
Avec le format CDT, comme les protections sont décrites, on sait si les blocs sont bons, érronés, ou bien encore si ils ont des checksums ou des CRCs. toutes ces informations sont nécessaires, et avec un format RAW ou brut, c'est pas possible.
On ne peut pas extraire des données, et faire ensuite les choses en aveugle. Le CPC a trop souffert de ça, avec des dumps de merde (on a été obligé de les refaire).
Idem pour les CDTs, ça fait depuis presque 3 ans que les jeux K7 doivent être redumpés, car samp2cdt a fait de gros dégats (jeux qui fonctionnaient pas sur un vrai CPC).
Donc vas-y, explique-moi quel est ton problème vis à vis du format CDT, je suis tout à ton écoute.
_________________ SPS Community Expert (SPS CE) / SPS France
Désolé, je ne suis pas un zozo. Fais attention, tu vas tomber du cheval... Mais bon, trop de hors sujet. Ce fil de discussion concerne Sugarbox, évitons de le polluer.
Inscription : 29 Août 2007, 12:04 Message(s) : 1990 Localisation : seine et marne 77
OffseT a écrit :
Désolé, je ne suis pas un zozo. Fais attention, tu vas tomber du cheval... Mais bon, trop de hors sujet. Ce fil de discussion concerne Sugarbox, évitons de le polluer.
Je ne vais pas tomber du cheval. J'ai passé un peu plus de 2 ans à travailler avec un programmeur sur un outil d'encodage de CDT.
Je dis d'accord avec toi si tu parlais des CDTs générés avec samp2cdt, mais zozo si tu parles des nouveaux CDTs.
Si tu veux faire un retour sur CSW2CDT, vas-y, César et moi on est ouvert à tout retour utilisateur.
Sugarbox gère actuellement très bien la quasi majorité des titres K7 en CDT.
Techniquement, quel est ton problème ?
_________________ SPS Community Expert (SPS CE) / SPS France
Bon, ça avance : La partie de code qui gère les formats de disquette compile sous Ubuntu avec G++ en version 7.2 (j'utilise un peu de C++17 pour me faciliter le portage (std::path !))
Ca plante ensuite (toujours sous Ubuntu), donc j'ai encore un peu de taff (sans compter que je voudrais bien le refactorer un peu avant de le githuber) mais ça progresse.
Petite mise à jour en v0.30. Essentiellement une correction des problèmes rencontrés sur les cassettes (c'est beaucoup plus fiable !). Un peu de refactoring également.
J'ai, en outre, migré sur github : Plus facile à maintenir (la gestion de site internet ne m'intéresse que très peu), et tout le monde peu télécharger peinard, ce qui n'était pas le cas avec free. Pour le moment, pas de source, ça viendra un jour ou l'autre.
Inscription : 27 Jan 2010, 09:04 Message(s) : 117 Localisation : Barcelona, España
Salutations !
J'essaie de faire fonctionner Sugarbox 0.30 en configuration 6128 + X-MEM sous Windows 10 64, et tout ce que j'obtiens c'est un reboot infini. J'aperçois vite fait cet écran :
Pièce jointe :
CaptureSugarbox.PNG
... mais je ne suis pas capable de faire quoi que ce soit. Quelqu'un aurait-il une idée de dépannage ?
Merci d'avance !
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Salut Lone, J'espère que tu es toujours dans les parages, j'aurais besoin de toi pour les commandes de l'ini de Sugarbox. J'essaie d'intégrer Sugarbox à Gamebase CPC, mais je n'arrive pas à tout gérer par l'ini. Existe-t'il une fonction ini ou ligne de commande pour autolancer une disquette ? Pour insérer une cassette ? Merci d'avance,
Normalement, une gestion de la ligne de commande est possible. Elle est désactivée depuis quelques versions, mais je vais la remettre rapidement. Les options sont les suivantes : -sna SNAPATH : load a snapshot -drivea DISKPATH : load a dump in drive A -driveb DISKPATH : load a dump in drive B -config CONFIGPATH : load the specified configuration -fullscreen : start with fullscreen activated -command "COMMAND" : start emulation an paste the "COMMAND"
Ces options devraient suffire à démarrer la config que l'on souhaite, avec le jeu voulu. Je peux assez simplement rajouter un -tape pour gerer également une cassette. Le plus gros sera de remettre tout cela d'aplomb et de tester un peu tous les cas de configurations (et un peu la version aussi, qui a pas mal été chahutée dernièrement)
Salut Thomas, Merci pour ta réponse, c'est parfait ! J'attends donc la version remaniée de Sugarbox afin de pouvoir tester tout ça Je suis aussi preneur pour -tape, ça me plait bien. Puisqu'on est sur le sujet des cassettes, est-ce qu'il existe une fonction ini ou ligne de commande pour charger une cassette ? On a FDx_Path dans l'ini et -drivex en ligne de commande, mais rien pour les cassettes. Si ça ne représente pas trop de travail, est-ce que tu pourrais également dupliquer toutes les lignes de commande dans l'ini, afin que je puisse avoir un visuel de toutes les commandes possibles ? En parlant de Sugarbox, tu continues à développer l'émulateur ou tu as abandonné ? J'avoue que ce serait dommage, tu as tellement accompli... En tout cas, merci pour ton aide,
Je n'ai pas abandonné le développement de Sugarbox. En fait, je fais pas mal de toilettage pour étendre un peu ses possibilités : A partir d'un coeur unique et portable, je génère l'application windows elle même (que j'ai bon espoir de porter sous Linux/max d'ici peu), mais aussi la version raspberry pi, un core libretro, et quelques utilitaires (SugarConvDsk et SugarConvTape) pour convertir les formats.
J'ai également passé beaucoup de temps sur les optimisations, que ça tourne sans ralentissement sur la pi3.
Je vais rendre le tout open source (c'est partiellement le cas) dès que ça sera un peu plus clean.
Une fois tout ceci fait, je reprendrais les avancées fonctionnelles et tâcherais de tenir toutes les promesses que j'ai faites
Salut Thomas, Merci pour ta réponse, ça a l'air super. Il me tarde de voir la nouvelle mouture de Sugarbox. Je suis également très intéressé par la version Raspberry Pi. Il semblerait que j'aie enfin une bonne raison d'en prendre un (non pas qu'il n'y en aie pas, mais avec Sugarbox sur Pi, ça devient essentiel). C'est super aussi que tu fasses un core Libretro, ça fait plaisir d'avoir plus de micro-ordinateurs dans RetroArch Trop de consoles là-dedans... A plus,
Inscription : 11 Juin 2010, 12:49 Message(s) : 228
ldaneels a écrit :
Salut Thomas, Merci pour ta réponse, ça a l'air super. Il me tarde de voir la nouvelle mouture de Sugarbox. Je suis également très intéressé par la version Raspberry Pi. Il semblerait que j'aie enfin une bonne raison d'en prendre un (non pas qu'il n'y en aie pas, mais avec Sugarbox sur Pi, ça devient essentiel). C'est super aussi que tu fasses un core Libretro, ça fait plaisir d'avoir plus de micro-ordinateurs dans RetroArch Trop de consoles là-dedans... A plus,
Loïc
Après, il existe déjà plusieurs core Amstrad sous Retroarch. C'est surtout super de profiter de la grande compatibilité et précision de Sugarbox.
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 7 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