L'explication de César a été claire Pourtant Gérald. Le relais n'est pas actif immédiat, il y a un temps de laps avant qu'il ne fasse son effet d'un point de vue hardware.

Le problème est surtout logiciel ici. C'est le fonctionnement du loader de chez Opera soft qui déconne si ce qu'à expliqué César n'est pas émulé d'un point de vue hardware.



quand la lecture d'un bloc se termine, le signal est soit en état bas (0), soit en état haut (1) ;

La polarité est d'après les dernières informations qu'on a découvert avec César liée en partie aux timings.
suivant les valeurs que le créateur de la protection a utilisé, la polarité ou du moins son changement se fait grâce à eux.

Si ma mémoire ne me fait pas défaut, Mask nécessite des pilotes IMPAIRS. Ce qui veut dire que la récupération des timings originaux de la cassette sont impératifs pour que le chargement se déroule bien, mais ça veut dire aussi que la gestion de la polarité par le CPC doit être émulée.

Si c'est pas fait ou mal fait, le loader crashe le jeu.

Par exemple, sur le jeu mask, si un un bloc se termine en état bas, le CPC doit faire la bascule en état haut avant que la lecture du bloc suivant ne commence. Si le signal reste en état bas, dès que le bloc suivant commence à être lu, kaboom ! ça plante.

Mais comme César l'a expliqué, il faut que Thomas et Yoann désassemblent les loaders des jeux pour comprendre exactement pourquoi ça merde.

Les loaders pour faire simple attendent des réactions particulières du CPC émulé, hors, comme ça ne se produit pas, les résultats attendus sont faussés, ce qui provoque le crash logiciel.

_________________
SPS Community Expert (SPS CE) / SPS France

Le relais n'agit que sur le moteur. Si tu n'utilise pas une vrai cassette, il n'y a aucun effet. Si l’émulateur arrête immédiatement la lecture, effectivement il peut y avoir des problèmes.
Reste a évaluer le temps de réaction du moteur.
Un Wav (original, et non trafique) serait utile a la comprehension ....

De ce point de vue, je ne suis pas d'accord avec toi. sur mes CPC, même quand j'utilise une cassette digitale le relais fait son office, je l'entends "claquer".



Attends 2 secondes, pourquoi tu viens me parler de WAV original et non trafiqué alors que les WAV numériques que j'ai fourni sont justement non trafiqués et parfaitement originaux, et rigoureusement identiques d'un point de vue timing, vitesse et données au WAV brut initial, mais sans la crasse ?

tu peux m'expliquer le fond de ton raisonnement ?

Et comme césar l'a expliqué, le problème est d'abord logiciel avant d'être matériel. C'est parce que les loaders des jeux attendent un résultat/une réponse que l'émulateur ne fournit pas que ça crashe.

_________________
SPS Community Expert (SPS CE) / SPS France

Ce soir je te fait un cdt de test pour te le prouver
Le relais claque, mais n'a aucune influence sur les données arrivant par la tête de lecture.


Pour ma culture, je voudrais un wav original, pour VOIR le signal dont on parle. Le wav numerique que tu considere original est déjà interprété. Si il y a une erreur d’interprétation, personne ne la verra. Et STP évite moi 50 lignes pour me dire qu'il est parfait, ce n'est pas ce que je te demande.

Soit on prend le temps de documenter ce comportement de façon à ce que les auteurs d’émulateur puissent implémenter un comportement conforme, soit on fournit de quoi étudier ce comportement.
Pour l'instant la seule information qu'on a c'est :
- l'emulateur ne marche pas, il ne fait pas comme le vrai HW.
- (César/dlfrsilver) crois savoir ce qu'il manque, mais refuse de fournir autre chose que des "aux dernière nouvelle", ou désassemble le loader toi même pour voir ce qu'il attend.
- Un wav "original" vérifié par une méthode qui n'implique pas le fonctionnement normal d'un CPC (moteur n'a aucun effet avec une fausse cassette)

Tout ça ne fait pas avancer le schmilblick.

Je ne suis pas programmeur, ce n'est donc pas à moi de faire ça. Chacun son rôle.



Tout à fait.



Cesar sait exactement ce qui fait planter les loaders, c'est pour cette raison que je lui ai demandé.
J'ai posté les pré-requis, la balle est donc dans le camp des développeurs.

C'est aux développeurs de chercher l'erreur, c'est pas à moi de prouver quoi que ce soit.

Moi ma spécialité c'est le hardware point.



Je ne remets pas en question tes connaissances en tant que programmeur. Je note néanmoins (pas seulement toi) que vous faites une fixation sur ce que vous appelez WAV original (en gros celui qui contient le signal analogique numérisé). Le WAV numérique correspond exactement au DAT digital utilisé pour procéder à la duplication sur les cassettes.

Les masters K7 de l'époque n'étaient JAMAIS au format analogique, toujours numériques !

L'outil n'a fait que regénérer un master Digital sans erreur, donc réponds à ma question :

Ou est le problème ?

Je vais donc te faire une réponse à la BDCiron :

"Question simple : ça marche sur un vrai CPC ?"
"Oui ? Alors c'est un problème d'émulateur, fin de la discussion."

_________________
SPS Community Expert (SPS CE) / SPS France

j'ajoute à mon post précédent des informations complémentaires indiquant précisément ce que fait la chaine de passage du WAV brut vers le CSW puis vers le CDT :

1) je dumpe une cassette avec un lecteur qui n'est pas celui du CPC, et qui est bien plus performant

2) dump terminé, j'ai donc un WAV avec le signal analogique de la cassette

3) j'utilise le petit outil qui comprime le WAV en CSW. ce dernier est en fait un simple convertisseur 1 bit analogic-to-digital qui compresse les bits du WAV au format RLE. On a donc un contenu rigoureusement conforme au WAV brut originel (sauf la crasse ça va de soi).

4) j'utilise ensuite l'outil d'encodage de CDT, qui génère simplement les bordures (edges) d'après les timings du CDT, qui sont très exactement ceux qui sont écrit dans le fichier CSW précédemment crée.

Comme ces timings sont ceux du WAV "analogique" tiré de la cassette, on a bien en sortie un CDT correspondant exactement à tout point de vue à ce que contenait le WAV de la cassette dumpée.

Ce qui explique pourquoi mon 464 et mon 464+ exécutent sans sourciller le WAV numérique obtenu si je réverse le CDT en CSW puis en WAV numérique.

César m'a indiqué cependant une chose, c'est comme on aurait jamais accès au masters DAT digital qui sont la source des copies (les cassettes originales quoi), et vieillissante, on a pas d'autre choix que de filtrer les dumps wav analogiques originaux pour virer la merde qui parasite le signal analogique (c'est son gros défaut, le signal analogique était une source d'erreur et pas que potentielle malheureusement).

On perd de ce fait forcément un peu de la précision du matériau source, malheureusement on a pas le choix. Si on veut regénérer un Master à l'identique de ceux des éditeurs, il sera forcément digital et pas analogique.

_________________
SPS Community Expert (SPS CE) / SPS France

Une petite remarque quand même... Les premières DAT sont apparues en 1987.
Du coup, les masters étaient probablement en analogique comme pour la musique.

_________________
Cent Pour Cent

les masters DAT digital datent des années 80, effectivement, et j'ai trouvé ceci :

jusque début des années 1990, les duplicateurs de cassettes étaient des appareils analogiques et ils utilisaient une cassette master comme source, souvent cette dernière était un peu “mise en valeur” pour le format.

Les Duplicateurs digitaux commençèrent à devenir populaires fin 80 - milieu des années 90 et ces derniers utilisaient une source digitale, d'ordinaire un DAT ou un disque dur utilisant les premières génération d'ADCs/DACs.

Dans tout les cas, les jeux K7 amstrad cpc ont eu les deux systèmes. Ce qui est certains c'est que si les cassettes des années 80 veillissent pas super bien, c'est pas étonnant, l'analogique pour le stockage de données c'est vraiment pourri. A l'inverse, les cassettes gravées par les duplicateurs digitaux ont un signal de bien meilleure qualité.

Il suffit de comparer par exemple un jeu de loriciels de 86 avec un jeu U.S.Gold de 1991.

Shadow Dancer ou U.N. Squadron ont un signal absolument niquel, d'une propreté incroyable, sans compter qu'au vu des timings comme je le disais plusieurs pages en arrière, la machine utilisée par Ablex, le duplicateur d'USGOLD, traçait le signal sur bande en 48khz. Le résultat au final c'est que ces cassettes là n'ont quasiment pas besoin d'être filtrées, on peut les passer en CDT directement

L'analogique c'est bon surtout pour la musique

_________________
SPS Community Expert (SPS CE) / SPS France

Cadeau :
Le cdt contient deux fois le même fichier. Le second sera lu par le premier lors du test.

Sur un émulateur ou une vraie cassette, tu ne verra que des bandes bleu/noir dans le border.
Avec un adaptateur cassette et ton PC, tu ne verra que des bandes jaune/rouge dans le border. (Et le moteur sera à l’arrêt pendant ce temps)

Effectivement, j'obtiens des bandes jaunes/rouges dans le border via mon PC et l'adaptateur K7.

Cependant, effet amusant, quand je passe ton CDT dans CPCE, comme j'ai l'adaptateur K7 de connecté sur ma sortie haut parleur PC, dès que CPCE lit le CDT, j'obtiens des bandes bleu et noir sur mon CPC 464+

Est-ce que tu peux me dire techniquement le but de la manoeuvre ? qu'est-ce que tu as voulu me montrer par ce biais ?

_________________
SPS Community Expert (SPS CE) / SPS France

Pour moi ton programme ne montrer qu'une chose :
Que les émulateurs en question ne respectent pas le temps d’arrêt du lecteur cassette contrôlé par le relais.
AUCUNE donnée ne devrais arrivé au PPI lorsque tu etteinds logiquement ou physiquement le relais.
Et visiblement sur emulateur, c'est pas le cas.
CA pour moi, c'est un bug, erreur, on l'appel comme on veux, Ca ne devrait pas 'fonctionner' sur emulateur.

Jolie petit programme au passage

Que le moteur soit on ou off, le PPI recoit ce qui vient de la tete de lecture du magneto. Il faut quand meme avoir mis le magneto sur play, sinon la tete de lecture est deconnectée.
Ca peut avoir des effets non voulut lors de la vérification par le bias d'un adaptateur.
- Si le loader arrête le moteur pendant un temps X supérieur à la pause entre la fin du loader et le début du block suivant, tu rate le block suivant.
- Si le loader arrête le moteur entre deux bloc collés l'un à l'autre pendant un temps très court, cela crée une distorsion avec une vrai bande, pas avec l'adaptateur. Il me semble qu'Elite (le jeu, pas la boite) compense cet effet entre les block. Mais je n'arrive plus a mettre la main sur mon dump ...


Sinon, pour les bandes bleues sur ton CPC pendant que tu lance l’émulateur, c'est normal. La routine ne s’arrête jamais et passe au du rouge au bleu après la mise en route du moteur

Tu devrais le lancer sur un vrai CPC ...
La seule chose que l’émulateur ne fait pas comme il faut, c'est de simuler l'inertie du moteur au démarrage et a l’arrêt.
L'inertie fait que la bande avance encore un peu apres coupure du moteur, et inversement, les donnée n'arrive pas tout de suite a sa mise en marche. Ca se remarque avec le prog sur emulateur ou il y a un peu de bordure bleu/noir puis une pause puis un gros bloc.
Les bordures au debut sont les 'reste' du programme qui vient d'etre chargé.

Au niveau du Z80, la lecture sur le PPI retourne soit un 0, soit un 1, quelque soit l'état du moteur, de la tête, ou autre. Il n'y a pas a proprement parler de données qui arrivent, mais plutôt des données qui changent.


Pour Gérald : Le débat sur la polarité vient du fait que dlfrsilver soutient que le CPC sait inverser par un biais inconnu (mais apparemment reproductible) , le sens des données de la cassette. Ainsi, un "haut" va retourner, la plupart du temps un 1 et, si cette fameuse inversion de polarité est active, un 1.

Gerald, c'est ce que j'ai fait, testé sur shugar et ensuite sur mon 464 à coté de moi.

On joue sur les mots mais effectivement, il n'y a pas de 'données' qui arrivent sur le ppi comme tu dit Lone.
Ceci dit, une suite de 0 ou de 1 si c'est pas des Data, faudra revoir quelques définitions sur le web.

Tu affirmes que le ppi reçoit des infos peu importe que l'était du relais ?
Question, comment peux tu affirmer ca sans être électronicien et avoir un cpc ? (pareil, c'est une question, pas un pic)
Moi j'ai quand même un doute à ce sujet, je testerai ca demain histoire de valider pour moi, ce que tu vient de dire.
> Last time, je pense que tu as raison sur ce sujet.

En faite, concernant la 'réception' des 'données' sur le PPI, je soutient qu'il ne devrait rien recevoir sur l’émulateur
Alors encore une fois, on joue sur les mots, données, réception... peu importe en faite.

Le programme devrais avoir EXACTEMENT le même effet sur un CPC que sur un émulateur.
Si le programme en question ne fait pas exactement la même chose, c'est qu'il y a un problème sur l’émulation.
CA... vous pouvez re-tourner la question dans tous les sens et sortir ce que vous voulez comme argument.
C'est indécrottable.