Inscription : 29 Août 2007, 12:04 Message(s) : 1989 Localisation : seine et marne 77
Citer :
Voici les instructions que j'ai données :
- Prendre la version de sugarbox d'ici : download/file.php?id=2047 (la dezipper dans un repertoire vierge) - Prendre la conf 464 FR - Prendre le wav suivant : download/file.php?id=2033 (rat connection) et le faire tourner (ctrl-enter) - Et le cdt suivant download/file.php?id=2029 (marmelade) et le faire tourner (ctrl-enter)
Dans ces deux cas, les jeux se sont correctement lancés.
De mon côté j'ai suivi à la lettre tes instructions, et j'ai même fait mieux : non seulement j'ai appliqué ce que tu as dis en faisant le test sur mon PC de bureau, mais j'ai fais aussi le même test sur mon PC portable. Dans les 2 cas, je rencontre le même problème, avec la même configuration. ça ne marche pas.
Et comme sugarbox est tout sauf complexe ou compliqué, choisir dans menu setting la config 464 FR (qui ne comporte donc pas d'accès FDC possible), et en checkant aussi que la fonction FDC est de 0 dans le fichier, puis en insérant le CDT ou le WAV, et cliquant sur PLAY puis en tapant RUN" suivi d'entrée au clavier ou encore CTRL+ENTER, j'obtiens toujours le même résultat :
sugarbox crashe à la fin du 1er bloc (9ème seconde), alors que le WAV et le CDT ont le 2ème bloc à la dite seconde. Donc la conclusion sur ce problème est simple :
comme j'ai constaté ce que j'ai écrit plus haut, ça veut dire que le bloc 1 et 2 sont collés quand sugarbox les traite, et ça n'est pas normal. Mon 464 au bout de 9 secondes de chargement, il lit le début du bloc 2 et pas la fin du bloc 1.
ça provoque une collision , et c'est comme si les deux blocs ne faisaient qu'un, ce qui est incorrect.
Citer :
Ce réglage n'a aucun impact : J'explique ci-après comment ça marche. La vitesse "100%" va juste ajouter des temps d'attente régulièrement, mais pas dans l'émulation : Entre deux frame par exemple. La vitesse du lecteur est elle définie par la vitesse du z80, grossierement.
Entendu, mais comme ça ne change rien, OK ça n'a pas d'impact sur notre problème.
Citer :
En fait, le coeur de l'émulateur se fiche pas mal des pauses et autres blocs : Il ne voit que ce que peux retourner la pin du PPI qui va bien. Donc, des 1 ou des 0 de durées différentes. La gestion du cdt, wav ou autres est donc toujours la même : Lors de la lecture du fichier, on calcule les durées de 1 ou de 0, l'unité de temps étant le 1/4 de microseconde (soit exactement un tick de z80).
Le pire c'est que tu le dis toi-même : l'émulateur se fiche des pauses. Je vais te dire ce que j'en pense :
Que tu aies de base choisi d'émuler très bas niveau, ok, c'est un choix tout à fait respectable. par contre ça complique sérieusement les choses, car si c'est simple de gérer des bits 0 et 1 à balancer sur le PPI, ça rend la gestion des pauses bien plus complexe. Comment mon 464 gère les pauses ?
Le contrôle moteur est un relais, et les relais prennent leur temps pour faire leur effet; le moteur du lecteur de cassette lui-même passe également un certain temps à démarrer et à s'arrêter. Cela a par exemple un effet important sur les cassettes de jeu de l'éditeur Opera: pour empêcher leur détecteur de bord trop sensible de lire le signal trailing du loader comme s'il faisait partie du pilote, il faut émuler quelques millisecondes de silence qui camouflent le dit signal trainant et empêcher le loader de pouvoir écouter quoique ce soit.
Le relais n'est lié au PPI, il prime sur lui. Si le relais arrête la cassette, toutes les tentatives de lecture sur le port cassette retourneront 0, et toutes les tentatives pour écrire dessus seront ignorées.
Il n'y a que quand le relais active le lecteur de cassette qu'il y a un flux de signal qui peut être géré en écoutant le port du lecteur de cassette.
Citer :
Dès que l'on a le moteur en marche, et la touche play enfoncée, on va donc mettre ces informations sur le PPI. Pour faire simple, a chaque tick de z80 (1/4 de microseconde), on va aller voir si on a un changement de niveau sur le ppi (de 1 -> 0, ou inversement). On met a jour le PPI en fonction de cela.
Oui mais les pauses, comment sont-elles gérés dans ton émulateur ? Comment les prends-tu en charge ?
Citer :
C'est tout. On est à un niveau nettement inférieur à celui du cdt (qui nous présente des données sous forme de blocs et de byte, là ou nous utilisons des intervales de temps entre les 1 et les 0). C'est d'ailleurs pour ça qu'on préfère le csw ou le wav, qui nous donnent les données brutes telles qu'on les souhaite (et telle que le CPC les voit, in fine - on emule au plus près de la machine).
Il n'y a pas de problème au niveau du chargement du PPI en bit 0 et 1. Concernant les fichiers CSW, enfin ceux que tu génères, je ne suis pas d'accord. J'ai visualisé celui de Rat, et il manque des pauses dedans, la clé de protection est collée au gros bloc, hors ça ne devrait pas être le cas. Il y a une pause avant et après la clé. C'est donc une anomalie, d'ou vient-elle ?
Citer :
Et donc, là ou on peut éventuellement voir une différence, c'est lors de la conversion des données du cdt vers ce niveau d'abstraction inférieur : On va tout reconstruire.
Justement, il y a ici aussi un problème. Ta reconstruction n'est pas rigoureusement identique à ce qu'on avait dans le CDT ou le WAV que j'ai généré. Ton fichier CSW ne correspond pas à ce que j'ai dans le CDT et le WAV que j'ai généré. Il y a des pauses qui manquent, la clé est collé au gros bloc, reprends les graphiques que j'ai posté juste avant on voit mes originaux, et ton fichier CSW ou la clé a "disparu" (collée quoi).
Citer :
Par contre, c'est une reconstruction qui, une fois les ambiguités de format levées, est assez systématique, même si ça n'est pas toujours exactement la même chose : Le passage en wav (par exemple) oblige a échantillonner des données qui sont continues, ce qui peut expliquer certains errements (et donc, un cdt qui passe et un wav qui ne passe pas, ou inversement).
J'en reviens à ce que je disais, si dans un CDT tu as une pause de 2450ms, cette dernière doit avoir un espace de silence de la même durée dans le CSW ou le WAV. Si tu ne reconstruis pas ou si ta routine ne le fait pas de façon systématique, forcément on aura des soucis à l'arrivée.
Citer :
En principe, on a pas mal bossé sur le cdt, et la conversion est dans l'ensemble assez correcte (on a une belle liste de jeu qui passent). On n'a pas de "grosse" erreur.
Oui c'est vrai, la le problème c'est les pauses, et sur les jeux avec protections sensibles, ça déconne.
Citer :
Ce que je compte faire, c'est ça : Comparer le cdt et le wav, pour voir où se situent les différences (il y en a forcément). Et à partir de là, patcher le cdt où les calculs de sugarbox (s'il s'avère que j'y trouve des inexactitudes) pour arriver à le faire fonctionner.
tu peux j'ai mis les graphs plus haut, compare mon WAV tiré du CDT original, à ton CSW à toi, tu verras qu'ils ne sont pas pareils. La clé est bien là, mais elle est collée au gros bloc.
Et le but n'est pas de patcher le CDT, il fonctionne très bien de base, le problème est sur sugarbox, c'est la qu'il faut corriger le problème, ce qui te permettra de faire tourner le CDT à ton tour.
_________________ SPS Community Expert (SPS CE) / SPS France
Bonjour à tous, Je viens d'envoyer un nouveau colis à Denis avec plein de bonnes choses à dumper. Au menu, Ubi Soft, Ere Informatique & pleins de logiciels rares. Encore une fois, un grand merci à Antoine Rozanski & Philippe Hernandez pour leur contribution au projet Gamebase CPC. Bon jeu,
Inscription : 29 Août 2007, 12:04 Message(s) : 1989 Localisation : seine et marne 77
Bien, après avoir reçu la semaine dernière le colis de Loic, avec ses jeux ainsi que ceux de Philippe Hernandez et et ceux de d'Antoine Rozanski, voici le résultat des courses :
en IPF : --------
Ariolasoft : -----------
- Hanse (VF)
Coktel Vision : ---------------
- Mewilo (G) - ADI CE1 Maths et Français
The Edge : -----------
- Garfield 2 - Winter's tail
Ere Informatique : -------------------
- Compil Gasol Hits - Harry & Harry - La boite de Rajmahal - Qin - l'enigme de l'Armée de Pierre - Quatre Saisons - Sram 1 et 2 - Stryfe Everlasting battle - Tobrouk 1942 - Crafton & Xunk - L'animalier
English Software : -------------------
- Elektra Glide
Grandslam : -------------
- Jagd Auf Roter Oktober (G)
Gremlin Graphics : -------------------
- North Star
Loriciels : ----------
- Cobra
Infogrames : -------------
- Reisende im Wind 1 et 2
Opera Soft : -------------
- Mithos
Ubisoft : ---------
- 3D Grand Prix - Gabrielle - La Chose de Grotemburg (pas trop tôt!) - Manhattan 95 - M'enfin - Zombi (v2)
Précision au sujet de ce dernier :
Sur cpc-p0wer, et CPC-rulez, la version de "Kris" est notifié comme étant la version 1, tandis que le dump de Maxit est notifiée comme étant la version 2. En fait c'est exactement le contraire
Le dump de Maxit est la version 1 et celle de Kris la version 2.
Pourquoi ? C'est le tout premier jeu édité par Ubisoft en 1986. La version 1 a été copiée et dupliquée sur CPC, on voit lors du dump que les 2 faces du jeu ont des tailles de gap non fixes, le signe indiquant l'écriture depuis un lecteur de CPC. A noter aussi qu'il n'y a pas de sauvegarde dessus.
A l'inverse, la version 2 utilise une protection différente, et là ubisoft est passé par un duplicateur industriel (KBI, c'est toi que je regarde ! ), raison pour laquelle j'ai pu générer un IPF de cette version.
Cette information n'est malheureusement pas visible par le biais de samdisk, mais on peut la voir en utilisant AUFIT.
Je vais donc voir avec Hermol et aussi Kukulcan pour faire intervertir le numéro de version.
U.S.Gold : -----------
- Rolling Thunder (ahem.... c'est pas ce que j'ai fais de mieux ) - Heroes of the lance - Impossible Mission II
Jeux modifiés : ----------------
- ADI CE1 (disquette programme, hélas) - Eden Blues (original écrasé par une version en fichier, j'adore) - Les 4 Saisons de l'Ecrit 6ème 3ème - Maracaibo (des fichiers ont été écris sur la disquette....) - Conspiration (sauvegardes de l'utilisateur) - Le Maitre Absolu (à moins d'avoir accès à un exemplaire jamais utilisé et non modifié, peine perdue) - L'oeil de set (sauvegarde de l'utilisateur) - Peur sur Amityville (sauvegarde de l'utilisateur)
Jeux non supportés : ----------------------
Discsys : ---------
- Aliens the computer game - Asterix and the Magic Cauldron - Dynamite Dan II - Into the eagle's nest - Les aventures de Jack Burton - Big Trouble in Little China - Tarzan
- 1001 BC a Mediterranean Odyssey (F) - Contamination (F) - Le Passager du Temps (F) - Pacific (F) - Scott Winder Reporter (F) - Theatre Europe (F) - One de titus
Autres non supportés : ------------------------
- Exit (encore !) - Le Maitre des Ames (s'automodifie, et en plus est protégé par clé GAP)
Jeux non dupliqués : ---------------------
- Mithos (Opera Soft) - Infernal Runner - L'aigle D'or - Alex Higgins' World Snooker - Forestland
Utilitaires en IPF: -----------------
- Grapho de CTS
Modifié : ---------
- Supercalc 2
Non supportés : -----------------
- Explorateur III (KBI-10!) - Ere du Verseau (KBI-10!)
Voilà pour ce batch en cours, les fichiers RAW sont dispos ci-dessous
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
_________________ SPS Community Expert (SPS CE) / SPS France
Super boulot une fois de plus. J'ai passé l'ensemble sur Sugarbox, pour voir, et donc :
- 93 disks sont ok A noter tout de même Elektra Glide qui n'aime pas les CPC FR (il faut une ROM UK (ou SP sans doute) pour que ça fonctionne)
- Les ADI... Je ne sais pas comment les lancer ? (pas de bas, de bin, pas de piste cpm....)
- Peur sur Amityville plante. Mais bon, je ne sais pas pourquoi... (surtout que l'original sur cpc-p0wer marche, donc ça ne doit pas être un problème de font - même si les deux sont manifestement des copies d'origines différentes)
Une fois que j'aurais vu celui là, je tacherais de poster une version à jour ( qui lance donc l'intégralité de tes dumps corrects !)
Inscription : 29 Août 2007, 12:04 Message(s) : 1989 Localisation : seine et marne 77
Lone a écrit :
Salut Denis,
Super boulot une fois de plus.
Merci
Citer :
J'ai passé l'ensemble sur Sugarbox, pour voir, et donc :
- 93 disks sont ok A noter tout de même Elektra Glide qui n'aime pas les CPC FR (il faut une ROM UK (ou SP sans doute) pour que ça fonctionne)
Effectivement, pour Elektra Glide, c'est un peu particulier
Citer :
- Les ADI... Je ne sais pas comment les lancer ? (pas de bas, de bin, pas de piste cpm....)
tu dois utiliser la face "lancement", puis tu passeras à la face "environnement", et pour finir tu peux utiliser une disquette matière, telle que Maths ou Français.
Le logiciel se lance par run"ADI" (face lancement).
Citer :
- Peur sur Amityville plante. Mais bon, je ne sais pas pourquoi... (surtout que l'original sur cpc-p0wer marche, donc ça ne doit pas être un problème de font - même si les deux sont manifestement des copies d'origines différentes)
Bien vu. Peur sur Amityville utilise apparemment la même protection que la Chose de Grotemburg. Et comme tu l'as dis toi même, je ne sais pas pourquoi le programme crashe.
De la même façon, j'ai un IPF de la face A, mais lui aussi plante de la même manière. Et d'après les pistes chargées par Sugarbox, c'est la protection qui plante et qui fait un reset.
Maxit avait plus ou moins indiqué sur la fiche de la chose de grotemburg le fonctionnement de la protection, qui fait un différentiel sur la taille du GAP#3 de la piste 0 et 39.
Si ça peut t'aider.....
Citer :
Une fois que j'aurais vu celui là, je tacherais de poster une version à jour ( qui lance donc l'intégralité de tes dumps corrects !)
Bien Logiquement Loic va m'envoyer encore d'ici la fin de la semaine si tout va bien un autre colis avec plein de jeux à dumper, et encore un autre suivra rempli de disquettes.
On avance, c'est bon tout ça !
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
Coucou !
Bon, grâce à un bon rhume des foins qui m'a réveillé très tôt ce matin, j'ai réussi à trouvé 1h afin d'ajouter les waves en lecture des k7 sur mon émulateur cpc !
Et cette après-midi, j'ai trouvé le temps le passer en mode 464 (sans fdc) afin d'essayer les waves des cdts qui ne passent pas...
et...
résultat : - Marmelade (F) (1987) (464 only) (Basic v1.0) [Original] [TAPE].wav - Rat Connection (F) (1987) (464 only) (Basic v1.0) [Original] [TAPE].wav - Footballer of the Year 2v3.wav
fonctionnent sans problème... (cf images ci-jointes).
j'en déduis que je n'ai aucun problème d'émulation autre (z80, ppi, GA, ou autres composants interne du cpc !) !
1) j'en déduis que l'inverse polarity ne sert à rien (ou n'existe pas réellement sur un cpc ?) ! et 2) la conversion en cdt ne fonctionne pas (ou l'utilitaire qui le permet ne fonctionne pas sur ce point = bug) ou 3) mon décodage du cdt ne fonctionne pas sur ce point !
comme je converti l'ensemble des samples (du wav ou du cdt) dans un format interne (comme Lone) qui est en gros : longueur1, 0 longueur2, 1 longueur3, 0 etc. je me dis qu'en comparant les deux, j'aurai peut-être l'endroit (vu que c'est au début) qui est différent entre l’interprétation du wave et celui de la cdt !?
sinon, est-ce que vous avez d'autres waves de k7 de jeux/compilation qui utilisent l'<<inverse polarity>> ou qui ne marchent pas sur un emulateur pour test ?
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Inscription : 29 Août 2007, 12:04 Message(s) : 1989 Localisation : seine et marne 77
Megachur a écrit :
Coucou !
Bon, grâce à un bon rhume des foins qui m'a réveillé très tôt ce matin, j'ai réussi à trouvé 1h afin d'ajouter les waves en lecture des k7 sur mon émulateur cpc !
Bien ça !
Citer :
Et cette après-midi, j'ai trouvé le temps le passer en mode 464 (sans fdc) afin d'essayer les waves des cdts qui ne passent pas...
et...
résultat : - Marmelade (F) (1987) (464 only) (Basic v1.0) [Original] [TAPE].wav - Rat Connection (F) (1987) (464 only) (Basic v1.0) [Original] [TAPE].wav - Footballer of the Year 2v3.wav
fonctionnent sans problème... (cf images ci-jointes).
Bien ces tests, le support des fichiers WAV est très simple, et ne nécessite pas grande chose.
Citer :
j'en déduis que je n'ai aucun problème d'émulation autre (z80, ppi, GA, ou autres composants interne du cpc !) !
Tout à fait pour ce qui est de la protection MBC K7.
Citer :
1) j'en déduis que l'inverse polarity ne sert à rien (ou n'existe pas réellement sur un cpc ?) ! et 2) la conversion en cdt ne fonctionne pas (ou l'utilitaire qui le permet ne fonctionne pas sur ce point = bug) ou 3) mon décodage du cdt ne fonctionne pas sur ce point !
La polarité inverse existe malheureusement, puisque les loaders gremlin y font appel.
C'est malheureusement le point 3) qui te concerne. Le format CDT est ultra compact et très bien conçu, le problème c'est qu'il demande en contre partie un plus gros investissement et support dans l'émulateur.
C'est tout l'inverse du WAV, c'est un format plus complexe, sur lequel on ne peut rien faire, la contrepartie c'est qu'il ne nécessite pas grand chose en terme de routines à ajouter dans l'émulateur.
J'avais vu dernièrement par exemple avec sugarbox, qu'il y avait un problème de pause. Et c'est pour ça que la protection crashait sur l'émulateur de Thomas.
Les pauses doivent être émulées correctement, sinon quand tu tombes sur une protection qui les "check", tu te fais mettre direct aux fraises si tu as un bug d'émulation de ce côté là.
Citer :
comme je converti l'ensemble des samples (du wav ou du cdt) dans un format interne (comme Lone) qui est en gros : longueur1, 0 longueur2, 1 longueur3, 0 etc. je me dis qu'en comparant les deux, j'aurai peut-être l'endroit (vu que c'est au début) qui est différent entre l’interprétation du wave et celui de la cdt !?
Voir mon explication juste avant. Pour la protection MBC, j'avais remarqué que sur le WAV de thomas la clé de protection digitale était collée au gros bloc crypté, alors que sur le wav original il y a une pause avant et après ce bloc.
Citer :
sinon, est-ce que vous avez d'autres waves de k7 de jeux/compilation qui utilisent l'<<inverse polarity>> ou qui ne marchent pas sur un emulateur pour test ?
Ben pas pour le moment, j'ai pas eu dans les derniers paquets de loic de cassettes avec des protections bizarre.
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
Après analyse des deux tableaux (wav et cdt) :
je constate que les longueurs des pulses ne sont pas les mêmes entre le wav et le cdt. ex pour Rat Connection : wave: GA : currentpulse=2607232 - DATA=0 cdt : GA : currentpulse=2627000 - DATA=0
soit une différence de 19768 !!!
ex pour Marmelade : wave : GA : currentpulse=2606107 - DATA=0 cdt : GA : currentpulse=2627000 - DATA=0 soit une différence de 20893 !!!
en fait, je constate qu'il y a des différences sur tous les pulses entre le wav et le cdt !
ce que je craignait s'avère donc vrai, les timmings de la cdt ne semblent pas bon !!? même s'ils sont prochent cela peut ne pas être suffisant pour le fonctionnement de certains loaders très précis !
est-ce que les outils de création de wave to cdt, loggue des informations à ce sujet quelquepart ?
Inscription : 29 Août 2007, 12:04 Message(s) : 1989 Localisation : seine et marne 77
Megachur a écrit :
Après analyse des deux tableaux (wav et cdt) :
je constate que les longueurs des pulses ne sont pas les mêmes entre le wav et le cdt. ex pour Rat Connection : wave: GA : currentpulse=2607232 - DATA=0 cdt : GA : currentpulse=2627000 - DATA=0
soit une différence de 19768 !!!
Attention ! Sur quel WAV et de quelle provenance tu te bases ? Si c'est celui que j'ai vu de Thomas avec la clé de protection collée au gros bloc crypté, mauvaise pioche !
Citer :
ex pour Marmelade : wave : GA : currentpulse=2606107 - DATA=0 cdt : GA : currentpulse=2627000 - DATA=0 soit une différence de 20893 !!!
Idem ! même question !
Citer :
en fait, je constate qu'il y a des différences sur tous les pulses entre le wav et le cdt !
ce que je craignait s'avère donc vrai, les timmings de la cdt ne semblent pas bon !!?
si c'est les WAV avec la clé de protection collée au gros bloc crypté, et qui ne sont pas bons, forcément ça ne correspondra pas avec les CDTs.
César sait exactement calculer les timings des cassettes. Et comme c'est lui qui a généré les CDTs, on peut lui faire confiance.
Citer :
même s'ils sont prochent cela peut ne pas être suffisant pour le fonctionnement de certains loaders très précis !
Comme je l'ai expliqué, les WAV générés depuis les CDTs que j'avais posté son érronés, les pauses ne sont pas insérées correctement dans les WAVs.
Citer :
est-ce que les outils de création de wave to cdt, loggue des informations à ce sujet quelquepart ?
Si tu utilises tapir, tu peux voir les timings et les définir si besoin est, voir changer la taille des pauses.
Cependant, aucun outil ne supporte la protection MBC, ce qui veut dire que la seule solution c'est d'utiliser un bytelogger.
_________________ SPS Community Expert (SPS CE) / SPS France
et les cdts de Marmelade (F) (1987) (464 only) (Basic v1.0) [Original] [TAPE].zip et Rat Connection (F) (1987) (464 only) (Basic v1.0) [Original] [TAPE].zip
que tu avais posté ici aussi !
si les cdts ou wave ne sont pas bons, est-il possible d'avoir les bons pour ces tests ?
et les cdts de Marmelade (F) (1987) (464 only) (Basic v1.0) [Original] [TAPE].zip et Rat Connection (F) (1987) (464 only) (Basic v1.0) [Original] [TAPE].zip
que tu avais posté ici aussi !
si les cdts ou wave ne sont pas bons, est-il possible d'avoir les bons pour ces tests ?
Si ce sont mes wavs à moi (générés par CDT2WAV de Markus Hohmann), ils sont bons et conformes à aux WAV originaux en terme de longueur de pauses entre les blocs.
Pour les CDTs, ceux-ci ont été générés à partir du bytelogger de cesar.
PS : il existe un moyen de tester directement des CDTs sans aucune conversion en WAV, il faut utiliser Tapir, un outil spectrum trouvable sur le net.
J'ai fait le test, mon CPC 464 fait tourner les deux CDTs sans problème.
_________________ SPS Community Expert (SPS CE) / SPS France
@megachur : Ah, le décodage de Wav... A la fois le plus facile ( a l'exception du csw ) et le plus complexe, pour peu que l'on veuille inclure le traitement du signal du 464...
Bref, belles avancées, et je vois qu'on a des conclusions semblable sur l'inversion de polarité, qui ne semble qu'un sous effet du traitement interne du 464 ( pour mémoire un, un test avait été fait sur un 464 réel, avec le même dumping passe sans soucis avec les deux types de polarité, là où nos ému ne le passait qu'avec un seul type. )
Il me semble d'ailleurs que le seul tremplin qui semblait avoir besoin de la polarité était basil, le détective.... Jusqu'à ce qu'un filtre ad hoc permette de le faire passer tel quel.
Cela dit, je pense que ta méthode est la bonne : comparer les longueurs des inversions et voir si on peut rapprocher le cdt de réalité ( au niveau en sortie de pause près, ce qui peut rester un point bloquant)
Inscription : 29 Août 2007, 12:04 Message(s) : 1989 Localisation : seine et marne 77
Lone a écrit :
@megachur : Ah, le décodage de Wav... A la fois le plus facile ( a l'exception du csw ) et le plus complexe, pour peu que l'on veuille inclure le traitement du signal du 464...
Bref, belles avancées, et je vois qu'on a des conclusions semblable sur l'inversion de polarité, qui ne semble qu'un sous effet du traitement interne du 464 ( pour mémoire un, un test avait été fait sur un 464 réel, avec le même dumping passe sans soucis avec les deux types de polarité, là où nos ému ne le passait qu'avec un seul type. )
Il me semble d'ailleurs que le seul tremplin qui semblait avoir besoin de la polarité était basil, le détective.... Jusqu'à ce qu'un filtre ad hoc permette de le faire passer tel quel.
Cela dit, je pense que ta méthode est la bonne : comparer les longueurs des inversions et voir si on peut rapprocher le cdt de réalité ( au niveau en sortie de pause près, ce qui peut rester un point bloquant)
au sujet de la protection "gremlin loader 2" j'ai retrouvé ça :
"Warning - due to the wrong concept of the loading routine (it detects the falling edge), all the double pulses must start with the EAR=0 pulse followed by the EAR=1 pulse!"
"Attention - à cause du concept erroné de la routine de chargement (elle détecte le bord tombat), toutes les doubles pulses doivent démarrer avec la pulse EAR=0 suivi de la pulse EAR=1 !"
info trouvée sur CPC-wiki, écrite par l'auteur de Winape :
"1. CNGSoft found that the tape polarity is important for loading. So the original is flakey too. 2. The loader peeks the screen and uses this to decrypt the code. So you can't have |TAPE:RUN" etc it must only be RUN" like if you press CTRL and ENTER on a CPC464."
"1. CNGSoft (César quoi) a découvert que la polarité de la cassette est importante pour le chargement. Et donc l'original est aléatoire/instable aussi. 2. Le loader vérifie l'écran et utilise ça pour décrypter le code. Vous ne pouvez pas taper pour cette raison |TAPE:RUN" etc il ne peut être lancé que par RUN" comme si vous faisiez CTRL et ENTER sur un CPC464."
autre élément au sujet de la protection trouvé en cherchant sur le net :
"Dans le code de rendu TZX/CDT qui gère les pauses après les blocs il y a également un commentaire:
// 31/04/2004: Ajouté ceci parce que c'est dans la spec TZX/CDT et à présent, en conjonction avec // les changements liés à la polarité mis en place pour 'basil the great mouse detective' et 'mask', // m_nPauseCountDown = TSTATESPERMSEC * 3;
soit T STATES PER MILLISECOND * 3.
Mais ce qui est écrit au dessus garde de base la bordure constante pendant un bloc de pause durant 3 ms avant de passer en état 'bas'. Le Format TZX/CDT a ceci:
Un bloc 'Pause' consiste en un niveau de pulse en état 'bas' d'une certaine durée. Pour s'assurer que la dernière bordure produite est correctement terminée il devrait y avoir au moins 1ms.
La pause du niveau opposé et seulement après la pulse peut passer en état 'bas'. A la fin d'un bloc 'Pause' le 'niveau de pulse courant' est en état bas (notez que la première pulse ne produira pas immédiatement une bordure). Un bloc de 'Pause' d'une durée de zéro est complètement ignoré, ainsi le 'niveau de pulse courant' ne changera PAS dans ce cas. Cela s'applique également aux blocs de 'Données' qui ont une durée de pause incluse après eux."
Et je crois que ce dernier bout de texte est l'explication que vous cherchiez tout les deux.
Vous comprenez maintenant mon argumentaire au sujet des pauses potentiellement 'buggées' ou 'pas correctement supportées' dans vos émus ?
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
Merci Lone et dlfrsilver pour votre aide, dumps et vos posts à ce sujet !
on est donc tous d'accord :
1) soit dans les cdts générés, il manque quelque chose pour que ça marche ! et donc à part si on le code en + dans nos émus, ça marche pas comme tous les autres (et j'ai quasiment tout testé les types de protections en cdts de cpc-p0wer) ! 2) soit on a pas la bonne doc sur les cdts, et il nous manque quelque chose à coder dans nos émus pour que ça marche à un endroit précis !
mais ce n'est pas un problème d'émulation des composants du cpc puisque sinon le wave ne marcherait pas (ouf!) !
en effet, un cpc 464 fait fonctionner : - le wave (idem que nous) - le cdt transformé en wave (est-il possible d'en obtenir un pour test sur ému ? quel est l'outil utilisé pour ce test, peut-être que lui sait bien décoder le cdt ?)
@dlfrsilver : sinon, vu la longueur du post et que certains sources ne sont plus bonnes, est-il possible d'avoir (lien ou direct download) : - les cdts waves 'propres' en question (pour les gremlins loader par exemple) - les cdts 'propres' pour Marmelade et Rat Connection - tout autre cas suspicieux !?
Je pense que ça intéressera aussi Lone et tout autre personne intéressé par l'émulation cpcienne !
concernant les explications, j'ai déjà codé depuis 1 an pour le décodage des cdts :
Code :
function pushPause(length) { if(length) { if(currentLevel) { pushPulse(1*3500);// In case the level is high, leave it for 1ms before bringing it low. } pushPulse(length*3500);// Then output the low pulse pause of given duration. currentLevel=false; } }
et sur les pauses = 0. je vais revoir mon code en ce sens vu la dernière explication pour voir si mon test if (length) fonctionne où si il faut pas mettre if(length>0) normalement c'est la même chose car si length=0 la condition est fausse !
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 184 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