CPC Rulez :: Consulter le sujet - TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE

dlfrsilver a écrit :

Petit bonus, pour les possesseurs de carte kryoflux, Orion Prime en version UK et SP en IPF.

Hello, je ne sais pas si ces ipfs ont été testés mais pour ma part... il y avait un problème sur l'émulateur cpcepower... :oops:

Après investigation, il se trouve que dans l'ipf, les données de la fin du dernier secteur sont à cheval sur l'index de la piste...et dans ce cas le code du lecteur de disquette renvoyait deux fois le même octets lors du passage sur l'index ce qui provoquait une erreur de CRC bien sûr !

--> Corrigé maintenant même si j'ai des doutes... :magic:

est-ce vraiment le cas ? n'y-a-t-il pas eu interprétation et mauvais placement de l'index hole de la piste par l'outil de SPS lors de la génération de l'ipf ???
--> Surtout que le même disque au format eDSK fourni n'est pas du tout comme cela, le secteur est bien positionné pas sur l'index !!!

est-ce que ces ipf fonctionnent sur un cpc une fois remis sur une disquette 3p avec la Kryoflux !? Quelqu'un a-t-il fait ce test !? :kissed:

Ensuite, ça c'est pas bloquant... pour info, le CT-RAW du secteur &ba - track 1 - comporte une erreur (il manque clairement quelques octets des données qui visiblement peuvent être reconstruite qu'avec la 4ième révolution du secteur - seul Sugarbox est capable de le faire visiblement ;-)

coucou Lone :magic:

et bien sur l'outil de la SPS pour la génération des ipfs et samdisk puisque le eDSK est bon.)

je ne sais pas pourquoi, mais ces CT RAWs n'ont que 4 révolutions... alors que la plupart ont 5 révolutions, bizarrerie...

Triste nouvelle : Sugarbox part dans le décor dès que le premier bloc Gremlin loader 3 est chargé.

On en revient à l'histoire et au problème de la bascule de la polarité, l'émulateur est toujours incapable de la faire, résultat, l'émulateur fait un reset !

dlfrsilver a écrit :

Moi qui pensais l'histoire de la bascule de polarité enterré...
On n'a toujours pas le moindre indice aussi bien matériel que logiciel, de l'existence de cette fameuse bascule.
Il n'est donc pas prévu que je fasse quelque chose dans ce sens.

Corriger des inexactitudes sur les timings du cdt ou des wav, oui par contre (mais sans doute pas dans l'immédiat)

Donc, ce n'est pas un dump WAV valide, car il est pris après le traitement analogique du CPC et non avant. Cela veut aussi dire que si une gestion de polarité existait (ce dont je doute), elle serait déjà appliquée au WAV que tu fournis... Bref... Le fait que ça fonctionne sur un 464 et pas sur Sugarbox est probablement plus lié à un soucis de timing qu'autre chose !

Ils sont fort ces ingénieurs Amstrad.... Réussir à cacher un composant boite noire, que personne n'a jamais décrit nul part (à part Denis !) et qui détecte les loaders gremlins pour inverser la polarité, dans le but de planter les émulateurs qui seront écrits 30 ans plus tard, quelle prouesse !

Ceci dit, je rigole, mais personne ne prétend que le dump n'est pas bon. Personne, non plus, ne prétend qu'il s'agit d'un problème de dump (sans doute pas). On est bien d'accord qu'il s'agit d'un problème d'émulateur, qu'il faudra traiter (si possible sans bidouille du type "inverser la polarité)

2/ Il suffit de l'enfourner dans le ppi d'un 464. Autant dire que la manip est accessible à pas grand monde...

On peut avoir un plan du montage d'extraction et de réinsertion ? Des fois qu'une inversion ait eu lieu à ce moment là... ?

le CSW passe sans aucun filtrage dans CPCE.

dlfrsilver a écrit :

le CSW passe sans aucun filtrage dans CPCE.

Pourquoi passer par le format CSW ? Il me semble que CPCE lit les wav, non ?
Quand tu dis "sans aucune filtrage", parles-tu de l'inversion de polarité de cpce ? (je ne vois que ça, vu que le csw c'est du signal 0 ou 1, difficile à filtrer donc..)

Alors pourquoi ça marche pas...aie, aie, aie :magic:

c'est bien simple... :oops:

tout d'abord, comme le dit dlfrsilver, il n'injecte pas ce wav directement sur le ppi de son cpc... puisqu'il passe par une k7 digitale et la tête de lecture de son 464+ et de la circuiterie jusqu'au PPI !
--> donc, qui prouve qu'électroniquement le signal n'est pas changé dans tout cela !???

Ensuite, je dis que ce dump n'est pas conforme à la k7 originale...

les dumps wav ou cdt 'officiel' de Mask de dlfrsilver fonctionne très bien...

et au fait, quel intérêt de supporter ce dump au format wav fait/enregistrer on ne sait comment quand on l'a déjà propre ce dump ??? --> c'est quoi le rapport avec de la préservation, si ce dump ne passe même pas dans CSW2CDT pour donner un beau cdt conforme au master original !?

et pour rappel des infos de ce wav, c'est pas vraiment standard :

INFO: WAVE : This file is in PCM Format - channel =1 - sampling frequency =44100 Hz - bytes per second =88200 - bytes by capture =2 - bits per sample =16

je le convertirai bien d'abord en wav propre avant de l'essayer à nouveau -> je ne sais pas qui peut/à le temps pour le faire !

Généralement, un bon dump wav est comme cela stéréo :
INFO: WAVE : This file is in PCM Format - channel =1 - sampling frequency =44100 Hz - bytes per second =44100 - bytes by capture =1 - bits per sample =8

La circuiterie filtre, enfin enleve les parasites, le truc usuel. ensuite, le signal n'est pas changé.

J'en veux pour preuve, mon 464 gère l'inverse de polarité en interne comme un grand. Ce que ne font pas les émulateurs.

Si César a mis ce petit hack de gestion de l'inversion de polarité, c'est parce qu'il ne sait pas exactement lui même quel composant s'occupe de faire ça.

donc c'est bien ce que je disais...le signal est filtré...légèrement modifié/filtré en analogique avant de devenir des tensions converties en 0 et des 1 au niveau du PPI...

si l'inversion de polarité existait...il faudrait pouvoir le prouver électroniquement !

quels sont les jeux en k7 concernés !? et si oui, comment cela ce fait-il qu'il fonctionne sans rien faire sur d'autres émulateurs comme le mien !?

Plusieurs points d'explication : je ne filtre pas du tout le wav en entrée ! donc si c'est crade et pas un joli dump fonctionnel -> normal que ça marche pas !

après, j'ai fait un choix sur la détermination des 0 et des 1 logiques qui sont envoyés au ppi :

Code :

                  if(sample_newvalue>0x80) {
                     sample_lastvalue=0; // negative
                  } else {
                     sample_lastvalue=1; // positive
                  }

donc pour faire simple, si le niveau du signal n'est pas suffisamment haut >0x80, ça peut aussi expliquer le pb !

après, sans rentrer dans le détail, en fait rien à voir avec cela : j'ai revu tout mon code de décodage du wav... je l'ai optimisé et j'ai pu prendre en compte plus précisément ce format de capture 'exotique' et...

le wav fonctionne maintenant sur l'émulateur... :winner:

, le chargement jusqu'au jeu qui se lance sans pb !

donc le dump est bon (mais cela on le savait déjà puisque fonctionnel sur cpc464 de dlfrsilver ;-)

)

comme quoi cela a du bon d'avoir des dumps, même bizzare, puisque j'ai pu revoir et améliorer le code de décodage de wav !

bon, super je vais faire quelques tests de non régression pour m'assurer que tout est bon par ailleurs sur les autres wavs.

par contre, zut

!!!

j'ai rien fait pour l'inversion de polarité ce qui comme tout chose : si on a pas prouver qu'elle existe, elle n'existe donc pas ou alors on peut s'en passer :magic:

Auteur :	dlfrsilver [ 26 Nov 2017, 17:44 ]
Sujet du message :	Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
Megachur a écrit : dlfrsilver a écrit : Petit bonus, pour les possesseurs de carte kryoflux, Orion Prime en version UK et SP en IPF. Hello, je ne sais pas si ces ipfs ont été testés mais pour ma part... il y avait un problème sur l'émulateur cpcepower... Salut, oui, et les IPFs gravés se lisent très bien Citer : Après investigation, il se trouve que dans l'ipf, les données de la fin du dernier secteur sont à cheval sur l'index de la piste...et dans ce cas le code du lecteur de disquette renvoyait deux fois le même octets lors du passage sur l'index ce qui provoquait une erreur de CRC bien sûr ! --> Corrigé maintenant même si j'ai des doutes... J'ai également testé les IPFs sur sugarbox, ça marche niquel Citer : est-ce vraiment le cas ? n'y-a-t-il pas eu interprétation et mauvais placement de l'index hole de la piste par l'outil de SPS lors de la génération de l'ipf ??? --> Surtout que le même disque au format eDSK fourni n'est pas du tout comme cela, le secteur est bien positionné pas sur l'index !!! Les eDSK c'est autre chose. Citer : est-ce que ces ipf fonctionnent sur un cpc une fois remis sur une disquette 3p avec la Kryoflux !? Quelqu'un a-t-il fait ce test !? Moi je réécris sur disquette 3.5". Les 3 pouces sont trop vieilles..... Citer : Ensuite, ça c'est pas bloquant... pour info, le CT-RAW du secteur &ba - track 1 - comporte une erreur (il manque clairement quelques octets des données qui visiblement peuvent être reconstruite qu'avec la 4ième révolution du secteur - seul Sugarbox est capable de le faire visiblement coucou Lone et bien sur l'outil de la SPS pour la génération des ipfs et samdisk puisque le eDSK est bon.) je ne sais pas pourquoi, mais ces CT RAWs n'ont que 4 révolutions... alors que la plupart ont 5 révolutions, bizarrerie... L'important, c'est qu'en bout de ligne ça fonctionne et proprement.

Auteur :	dlfrsilver [ 26 Nov 2017, 17:52 ]
Sujet du message :	Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
Hello, j'ai une information pour Thomas, au sujet de sugarbox, mais aussi Mégachur, s'ils me lisent tout les deux. Un contributeur m'a envoyé un dump fonctionnel de Mask au format WAV, directement enregistré grâce à un montage soudé sur son 464 pour récupérer le signal du PPI. Triste nouvelle : Sugarbox part dans le décor dès que le premier bloc Gremlin loader 3 est chargé. On en revient à l'histoire et au problème de la bascule de la polarité, l'émulateur est toujours incapable de la faire, résultat, l'émulateur fait un reset ! Donc Thomas, à quel moment tu comptes régler ce problème qui empoisonne aussi bien le chargement CDT des logiciels Gremlin loader 1 et 3 ? Je mets en PJ le WAV en question que le contributeur m'a envoyer, ce dernier fonctionne sur un vrai 464, il doit donc obligatoirement marche sur un émulateur.

Auteur :	Lone [ 27 Nov 2017, 10:08 ]
Sujet du message :	Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
dlfrsilver a écrit : Triste nouvelle : Sugarbox part dans le décor dès que le premier bloc Gremlin loader 3 est chargé. On en revient à l'histoire et au problème de la bascule de la polarité, l'émulateur est toujours incapable de la faire, résultat, l'émulateur fait un reset ! Moi qui pensais l'histoire de la bascule de polarité enterré... On n'a toujours pas le moindre indice aussi bien matériel que logiciel, de l'existence de cette fameuse bascule. Il n'est donc pas prévu que je fasse quelque chose dans ce sens. Corriger des inexactitudes sur les timings du cdt ou des wav, oui par contre (mais sans doute pas dans l'immédiat)

Auteur :	TotO [ 27 Nov 2017, 11:51 ]
Sujet du message :	Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
Donc, ce n'est pas un dump WAV valide, car il est pris après le traitement analogique du CPC et non avant. Cela veut aussi dire que si une gestion de polarité existait (ce dont je doute), elle serait déjà appliquée au WAV que tu fournis... Bref... Le fait que ça fonctionne sur un 464 et pas sur Sugarbox est probablement plus lié à un soucis de timing qu'autre chose !

Auteur :	dlfrsilver [ 27 Nov 2017, 12:17 ]
Sujet du message :	Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
Lone a écrit : dlfrsilver a écrit : Triste nouvelle : Sugarbox part dans le décor dès que le premier bloc Gremlin loader 3 est chargé. On en revient à l'histoire et au problème de la bascule de la polarité, l'émulateur est toujours incapable de la faire, résultat, l'émulateur fait un reset ! Moi qui pensais l'histoire de la bascule de polarité enterré... On n'a toujours pas le moindre indice aussi bien matériel que logiciel, de l'existence de cette fameuse bascule. Il n'est donc pas prévu que je fasse quelque chose dans ce sens. Corriger des inexactitudes sur les timings du cdt ou des wav, oui par contre (mais sans doute pas dans l'immédiat) bien sur que non elle n'est pas enterrée ! C'est pas parce que tu ne veux pas la traiter qu'elle n'existe pas. Le WAV qui m'a été envoyé et que tu as téléchargé fonctionne sur un vrai 464, et il a été généré via le 464 du contributeur. Le CPC sait à quel moment il doit effectuer la bascule de la polarité. le jeu se charge ainsi sans problème. La bascule de la polarité est un effet type boite noire, mais alors quel composant s'en charge, c'est la question..... Comme le système de bascule de polarité n'existe pas dans sugarbox, au moment ou le loader du jeu s'attends à la dite bascule, le résultat ne correspond pas à ce qui est attendu.

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

TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE https://cpcrulez.fr/forum/viewtopic.php?f=2&t=5279	Page 108 sur 138

Auteur :	dlfrsilver [ 27 Nov 2017, 12:22 ]
Sujet du message :	Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
TotO a écrit : Donc, ce n'est pas un dump WAV valide, car il est pris après le traitement analogique du CPC et non avant. Cela veut aussi dire que si une gestion de polarité existait (ce dont je doute), elle serait déjà appliquée au WAV que tu fournis... Bref... Le fait que ça fonctionne sur un 464 et pas sur Sugarbox est probablement plus lié à un soucis de timing qu'autre chose ! salut, le dump est valide. il suffit simplement de l'enfourner dans le PPI d'un 464. La gestion de la polarité est réelle, puisque la protection gremlin loader 3 est basée en partie dessus (il y a d'autres aspect particulièrement complexe qui rentrent en ligne de compte). Le loader de Mask est basé sur cette bascule de polarité. en gros quand le premier bloc au format Gremlin loader 3 est chargé, la polarité est en état haut. Le CPC passe en hardware l'état à bas au moment du chargement du bloc qui suit. Si le loader s'aperçoit que l'état est à haut, il reset directement le CPC ! j'ai testé le WAV en question sur mon propre 464, ça marche sans aucun problème. donc : problème d'émulateur.

Auteur :	Lone [ 27 Nov 2017, 12:54 ]
Sujet du message :	Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
Ils sont fort ces ingénieurs Amstrad.... Réussir à cacher un composant boite noire, que personne n'a jamais décrit nul part (à part Denis !) et qui détecte les loaders gremlins pour inverser la polarité, dans le but de planter les émulateurs qui seront écrits 30 ans plus tard, quelle prouesse ! Ceci dit, je rigole, mais personne ne prétend que le dump n'est pas bon. Personne, non plus, ne prétend qu'il s'agit d'un problème de dump (sans doute pas). On est bien d'accord qu'il s'agit d'un problème d'émulateur, qu'il faudra traiter (si possible sans bidouille du type "inverser la polarité) Pour être constructif : 1/ Si le dump fonctionne sur ton 464, il n'est pas du tout emu-friendly : - Read error sur CPCE (1.95) - reset sur caprice forever des le début - Sugarbox ne dépasse pas le premier compteur à 0 (sauf si j'inverse la sortie du wav, là, le jeu se lance ) - le wav crash cpc++ - Il ne semble pas de charger sur Winape et arnold ? 2/ Il suffit de l'enfourner dans le ppi d'un 464. Autant dire que la manip est accessible à pas grand monde... On peut avoir un plan du montage d'extraction et de réinsertion ? Des fois qu'une inversion ait eu lieu à ce moment là... ?

Auteur :	dlfrsilver [ 27 Nov 2017, 13:20 ]
Sujet du message :	Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
Lone a écrit : Ils sont fort ces ingénieurs Amstrad.... Réussir à cacher un composant boite noire, que personne n'a jamais décrit nul part (à part Denis !) et qui détecte les loaders gremlins pour inverser la polarité, dans le but de planter les émulateurs qui seront écrits 30 ans plus tard, quelle prouesse ! La bascule de polarité n'est décrite nulle part, pourtant le CPC la fait comme un grand, ainsi que le 6128. est-ce que c'est le PPI qui gère ça ? ou bien le relais que le 464 et le 6128 possèdent en commun ? Citer : Ceci dit, je rigole, mais personne ne prétend que le dump n'est pas bon. Personne, non plus, ne prétend qu'il s'agit d'un problème de dump (sans doute pas). On est bien d'accord qu'il s'agit d'un problème d'émulateur, qu'il faudra traiter (si possible sans bidouille du type "inverser la polarité) Je parle de bascule, mais en fait il s'agit bien d'une inversion de la polarité. C'est ce que césar avait découvert en désossant le loader de Mask. Pour être constructif : 1/ Si le dump fonctionne sur ton 464, il n'est pas du tout emu-friendly : - Read error sur CPCE (1.95) - reset sur caprice forever des le début - Sugarbox ne dépasse pas le premier compteur à 0 (sauf si j'inverse la sortie du wav, là, le jeu se lance ) - le wav crash cpc++ - Il ne semble pas de charger sur Winape et arnold ? Citer : 2/ Il suffit de l'enfourner dans le ppi d'un 464. Autant dire que la manip est accessible à pas grand monde... On peut avoir un plan du montage d'extraction et de réinsertion ? Des fois qu'une inversion ait eu lieu à ce moment là... ? facile de l'envoyer dans le PPI d'un 464. tu utilises une cassette digitale connectée à un PC insérée dans le lecteur du 464. pour le lire sous CPCE, j'ai juste à passer le WAV dans le format CSW à l'aide de CSW0 fournit avec l'outil CSW2CDT que j'ai mis au point conjointement avec César. Mais si tu veux un plan du montage de l'extraction, aucun souci, je vais le demander au contributeur. ensuite : ---------- le CSW passe sans aucun filtrage dans CPCE. je confirme que sugarbox charge le loader, passe au 1er bloc gremlin loader 3, et reset dès la lecture du 2ème bloc gremlin loader 3. je n'utilise pas CPC++ pour l'émulation de cassettes, caprice forever plante comme tu l'indiques, quand à Winape, c'est pas l'émulateur que j'utiliserais pour charger mes cassettes, ce dernier n'étant pas du tout fidèle. Pour Arnold je ne sais, je n'ai pas testé. En tout cas, est-ce que tu as remarqué que ce WAV n'a aucun signal visible si tu le charges dans goldwave ou tout autre outil permettant de charger un fichier audio ?

Auteur :	Lone [ 27 Nov 2017, 13:40 ]
Sujet du message :	Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
dlfrsilver a écrit : le CSW passe sans aucun filtrage dans CPCE. Pourquoi passer par le format CSW ? Il me semble que CPCE lit les wav, non ? Quand tu dis "sans aucune filtrage", parles-tu de l'inversion de polarité de cpce ? (je ne vois que ça, vu que le csw c'est du signal 0 ou 1, difficile à filtrer donc..)

Auteur :	Megachur [ 27 Nov 2017, 18:58 ]
Sujet du message :	Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
Alors pourquoi ça marche pas...aie, aie, aie c'est bien simple... tout d'abord, comme le dit dlfrsilver, il n'injecte pas ce wav directement sur le ppi de son cpc... puisqu'il passe par une k7 digitale et la tête de lecture de son 464+ et de la circuiterie jusqu'au PPI ! --> donc, qui prouve qu'électroniquement le signal n'est pas changé dans tout cela !??? Ensuite, je dis que ce dump n'est pas conforme à la k7 originale... d'ailleurs les dumps wav ou cdt 'officiel' de Mask de dlfrsilver fonctionne très bien... et au fait, quel intérêt de supporter ce dump au format wav fait/enregistrer on ne sait comment quand on l'a déjà propre ce dump ??? --> c'est quoi le rapport avec de la préservation, si ce dump ne passe même pas dans CSW2CDT pour donner un beau cdt conforme au master original !? et pour rappel des infos de ce wav, c'est pas vraiment standard : INFO: WAVE : This file is in PCM Format - channel =1 - sampling frequency =44100 Hz - bytes per second =88200 - bytes by capture =2 - bits per sample =16 je le convertirai bien d'abord en wav propre avant de l'essayer à nouveau -> je ne sais pas qui peut/à le temps pour le faire ! Généralement, un bon dump wav est comme cela stéréo : INFO: WAVE : This file is in PCM Format - channel =1 - sampling frequency =44100 Hz - bytes per second =44100 - bytes by capture =1 - bits per sample =8

Auteur :	dlfrsilver [ 28 Nov 2017, 01:00 ]
Sujet du message :	Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
Lone a écrit : dlfrsilver a écrit : le CSW passe sans aucun filtrage dans CPCE. Pourquoi passer par le format CSW ? Il me semble que CPCE lit les wav, non ? Quand tu dis "sans aucune filtrage", parles-tu de l'inversion de polarité de cpce ? (je ne vois que ça, vu que le csw c'est du signal 0 ou 1, difficile à filtrer donc..) CPCE ne sait pas lire en direct le WAV, étant donné que ce n'est pas un WAV classique. Il ne peut lire le jeu qu'une fois passé en fichier CSW. Quand je dis sans aucun filtrage, c'est à dire que j'utilise CSW0 sans commutateur de filtrage. c'est à dire CSW0 Mask.wav Mask.csw, par opposition à csw0 -f 600 8000 Mask.wav Mask.csw L'inversion de polarité n'a rien à voir dans tout ça, c'est autre chose.

Auteur :	dlfrsilver [ 28 Nov 2017, 01:10 ]
Sujet du message :	Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
Megachur a écrit : Alors pourquoi ça marche pas...aie, aie, aie c'est bien simple... tout d'abord, comme le dit dlfrsilver, il n'injecte pas ce wav directement sur le ppi de son cpc... puisqu'il passe par une k7 digitale et la tête de lecture de son 464+ et de la circuiterie jusqu'au PPI ! --> donc, qui prouve qu'électroniquement le signal n'est pas changé dans tout cela !??? La circuiterie filtre, enfin enleve les parasites, le truc usuel. ensuite, le signal n'est pas changé. J'en veux pour preuve, mon 464 gère l'inverse de polarité en interne comme un grand. Ce que ne font pas les émulateurs. Si César a mis ce petit hack de gestion de l'inversion de polarité, c'est parce qu'il ne sait pas exactement lui même quel composant s'occupe de faire ça. Citer : Ensuite, je dis que ce dump n'est pas conforme à la k7 originale... Le contributeur l'a généré à partir de sa cassette original en la lisant sur son CPC 464. Il a soudé 2 fils rattachés à une prise audio connectée sur son PC, avec laquelle il a enregistré la cassette sous goldwave au fur et à mesure que son 464 déroulait la bande. Citer : les dumps wav ou cdt 'officiel' de Mask de dlfrsilver fonctionne très bien... Tout à fait Citer : et au fait, quel intérêt de supporter ce dump au format wav fait/enregistrer on ne sait comment quand on l'a déjà propre ce dump ??? --> c'est quoi le rapport avec de la préservation, si ce dump ne passe même pas dans CSW2CDT pour donner un beau cdt conforme au master original !? La protection Gremlin Loader 3 est pour le moment WIP dans csw2cdt. générer des CDTs avec la version non public que j'utilise est affreusement compliqué à faire. Mask est composé de plus de 14000 micro-blocs, engoncés en plus dans des parasites. Citer : et pour rappel des infos de ce wav, c'est pas vraiment standard : INFO: WAVE : This file is in PCM Format - channel =1 - sampling frequency =44100 Hz - bytes per second =88200 - bytes by capture =2 - bits per sample =16 je le convertirai bien d'abord en wav propre avant de l'essayer à nouveau -> je ne sais pas qui peut/à le temps pour le faire ! Généralement, un bon dump wav est comme cela stéréo : INFO: WAVE : This file is in PCM Format - channel =1 - sampling frequency =44100 Hz - bytes per second =44100 - bytes by capture =1 - bits per sample =8 Je suis d'accord, je l'ai signalé au contributeur, qu'il fallait du 8 bit mono 44khz.

Auteur :	Megachur [ 28 Nov 2017, 07:23 ]
Sujet du message :	Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
dlfrsilver a écrit : La circuiterie filtre, enfin enleve les parasites, le truc usuel. ensuite, le signal n'est pas changé. J'en veux pour preuve, mon 464 gère l'inverse de polarité en interne comme un grand. Ce que ne font pas les émulateurs. Si César a mis ce petit hack de gestion de l'inversion de polarité, c'est parce qu'il ne sait pas exactement lui même quel composant s'occupe de faire ça. donc c'est bien ce que je disais...le signal est filtré...légèrement modifié/filtré en analogique avant de devenir des tensions converties en 0 et des 1 au niveau du PPI... si l'inversion de polarité existait...il faudrait pouvoir le prouver électroniquement ! quels sont les jeux en k7 concernés !? et si oui, comment cela ce fait-il qu'il fonctionne sans rien faire sur d'autres émulateurs comme le mien !? Plusieurs points d'explication : je ne filtre pas du tout le wav en entrée ! donc si c'est crade et pas un joli dump fonctionnel -> normal que ça marche pas ! après, j'ai fait un choix sur la détermination des 0 et des 1 logiques qui sont envoyés au ppi : Code : if(sample_newvalue>0x80) { sample_lastvalue=0; // negative } else { sample_lastvalue=1; // positive } donc pour faire simple, si le niveau du signal n'est pas suffisamment haut >0x80, ça peut aussi expliquer le pb ! après, sans rentrer dans le détail, en fait rien à voir avec cela : j'ai revu tout mon code de décodage du wav... je l'ai optimisé et j'ai pu prendre en compte plus précisément ce format de capture 'exotique' et... le wav fonctionne maintenant sur l'émulateur... , le chargement jusqu'au jeu qui se lance sans pb ! donc le dump est bon (mais cela on le savait déjà puisque fonctionnel sur cpc464 de dlfrsilver ) comme quoi cela a du bon d'avoir des dumps, même bizzare, puisque j'ai pu revoir et améliorer le code de décodage de wav ! bon, super je vais faire quelques tests de non régression pour m'assurer que tout est bon par ailleurs sur les autres wavs. par contre, zut !!! j'ai rien fait pour l'inversion de polarité ce qui comme tout chose : si on a pas prouver qu'elle existe, elle n'existe donc pas ou alors on peut s'en passer !?

Auteur :	Megachur [ 28 Nov 2017, 07:33 ]
Sujet du message :	Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
bon, c'est tout bon pour la non régression... tout fonctionne : Rat Connection (F) (1987) (464 only) (Basic v1.0) [Original] [TAPE].wav et Marmelade (F) (1987) (464 only) (Basic v1.0) [Original] [TAPE].wav + les dumps de jmd pas filtré du tout !

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

Auteur :	dlfrsilver [ 28 Nov 2017, 09:03 ]
Sujet du message :	Re: TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE
Citer : donc c'est bien ce que je disais...le signal est filtré...légèrement modifié/filtré en analogique avant de devenir des tensions converties en 0 et des 1 au niveau du PPI... Le CPC le fait automatiquement. Citer : si l'inversion de polarité existait...il faudrait pouvoir le prouver électroniquement ! Le loader repose sur ce principe. c'est une preuve suffisante Citer : quels sont les jeux en k7 concernés !? et si oui, comment cela ce fait-il qu'il fonctionne sans rien faire sur d'autres émulateurs comme le mien !? Samurai Trilogy par exemple Les jeux utilisant le gremlin loader 3 ne sont pas nombreux. Citer : Plusieurs points d'explication : je ne filtre pas du tout le wav en entrée ! donc si c'est crade et pas un joli dump fonctionnel -> normal que ça marche pas ! après, j'ai fait un choix sur la détermination des 0 et des 1 logiques qui sont envoyés au ppi : Code : if(sample_newvalue>0x80) { sample_lastvalue=0; // negative } else { sample_lastvalue=1; // positive } donc pour faire simple, si le niveau du signal n'est pas suffisamment haut >0x80, ça peut aussi expliquer le pb ! après, sans rentrer dans le détail, en fait rien à voir avec cela : j'ai revu tout mon code de décodage du wav... je l'ai optimisé et j'ai pu prendre en compte plus précisément ce format de capture 'exotique' et... le wav fonctionne maintenant sur l'émulateur... , le chargement jusqu'au jeu qui se lance sans pb ! Bien Oublie pas de me l'envoyer au passage que je le teste Citer : donc le dump est bon (mais cela on le savait déjà puisque fonctionnel sur cpc464 de dlfrsilver ) comme quoi cela a du bon d'avoir des dumps, même bizzare, puisque j'ai pu revoir et améliorer le code de décodage de wav ! bon, super je vais faire quelques tests de non régression pour m'assurer que tout est bon par ailleurs sur les autres wavs. par contre, zut !!! j'ai rien fait pour l'inversion de polarité ce qui comme tout chose : si on a pas prouver qu'elle existe, elle n'existe donc pas ou alors on peut s'en passer !? Tu as peu être trouvé par hasard la formule "magique"