Concernant une 'coupure' de la ligne du ppi quand le relais est activé
maintenant que je pense au schéma dans ma tête, effectivement, il n'y a pas de coupure proprement dit.
La 'ligne' est tjs précente entre le circuit de lecteur de bande et le PPI peu importe l'état du relais sur le CPC

Mais encore une fois, on joue sur les mots
Il arrive quoi sur le ppi dans ce cas la ?
Rien du tout vue que ce qui lui arrive vient de la tête de lecture et tête de lecture bloqué par justement ce relais (du moins en réel)
Alors à part du bruit.......

En faite, c'était quoi le but de ce programme ?
Si c'était pour montrer l’inertie que prends le moteur a l’arrêt ou démarrage via le relais
comme dirait l'autre, tu prêches un convertible

Mais je ne pense pas que cela est quoi que ce soit comme incidence sur une protection, quoi que... entre deux blocs... au ms pret...
Non non, je ne pense pas finalement car Cette inertie n'est pas proprement défini sur les CPC, c'est pas dans les spec.
Comme on parle de ms, cette inertie dépends de pas mal de chose au final.

- La bande elle même et la force qu'elle induit sur le mécanisme de translation de bande.
- Le moteur du lecteur de cassette du CPC
- La courroie du mécanisme mécanique du lecteur
etc...

Tout ca est vraiment propre a chaque CPC, sans compter le nbr de personne qui se servait de magneto externe sur CPC6128 pour jouer au jeux 464
et ca marchait... et Pourtant, ce n'était pas pour la plus part des magnéto Amstrad et cette valeur d'inertie en question, n'était a coup sur pas du tout la même sur un vrai CPC.
Je pense que l'on s’égare, le problème ne vient surement pas de là.

Avec un adaptateur ?


Devine
Il n'est pas nécessaire d'avoir un CPC, savoir lire un schéma suffit

Le programe a le meme comportement sur un CPC et un emulateur, a condition de l'enregistrer sur une cassette. Ce que je voulais montrer c'est que l'utilisation d'un adaptateur peut jouer des tours !

@gerard

belle demonstration

et bonne formation sur le relais du lecteur de cassette

pour etre dans la meme situation sur emulateur et sur cpc il faudrait reccreer une vrai cassette "qui tourne et s'arrete" suivant l'etat du relais

ce que ne fait pas nos "cassettes numériques"

EDIT : oups gerard m'a grillé

@gerald
>Devine
>Il n'est pas nécessaire d'avoir un CPC, savoir lire un schéma suffit

Tout à fait, c'est pour ca que j'ai maj mon post au dessus, je me suis souvenu du schéma.
Mais la question était pour Lone mais j'imagine que la réponse est la même, il a du regarder le schéma

Vivi, avec adap. k7, c'était le but du programme il me semble, testé ça.


breiztiger : Sur un WAV non original (comprendre, refait), je veux bien, c'est pas jouable, mais sur un CDT, les blocs de pausent sont indiqué
y'a aucun player de CDT qui rejoue le fichier en prenant compte des bloc de pauses ?

moi je dirai plutôt que lorqu'on lit les données K7 sur le PPI port B, on obtient toujours un 0 ou un 1.... sur le bit 7 !

il ne change que si la tête de lecture change cette valeur sur l'interface RD DATA du lecteur de K7 !

Pourtant d'un point de vue strictement hardware, rien n'arrive au PPI en terme de données si électriquement y a pas d'activité, ça c'est une certitude.

Comme Giants a sondé logiquement le PPI sur son 464, je suppose que la réponse qu'il t'a faite est exacte.



J'ai comme l'impression que ce qui concerne la polarité est manifestement quelque chose qui n'est pas documenté, à te lire c'est comme si t'en avais jamais entendu parler, pourtant la polarité existe pour les jeux K7 du spectrum, du C64, et du CPC. T'as pas idée des saloperies qu'un programmeur peut faire avec la polarité sur CPC point de vue protection contre la copie, voir Mask entre autre, mais pas que

Les loaders de Mask, impossamole, ou encore basil si tu les désassembles montrent parfaitement qu'ils la gère, et pire il la vérifient.



Un état haut retourne toujours un 1, un état bas 0. En fin de bloc, si c'est 0 ça devient un 1 avec l'inversion de polarité, quand la polarité inverse n'est pas émulée, le 0 en fin de bloc reste à 0 alors que le loader attends un 1 = kabooom ! plantage.



Je n'ai jamais vu ça, et ça je peux te le confirmer, aucun jeu commercial ne m'a jamais posé problème avec le relais / PPI / activation du moteur.

De plus, le processus de dump se fait de manière indépendante de la plateforme visée (le cpc quoi), ce qui veut dire que lorsque je dumpe, je prends ce qui est sur la cassette, le reste n'a aucun importance.

Et clairement de par mes tests à moi sur mon matériel, le PPI ne traite que si on lui envoie des données. Si on lui envoie rien, même si le moteur est actif, la machine ne bouge pas d'un iota.

Ce qui veut dire que sur un émulateur, si ce dernier feede en continu, c'est pas normal.

et concernant l'adaptateur K7, comme le contrôle moteur est absent, c'est moi qui met en pause sur le logiciel, mais point de vue timings, vitesse de lecture, et données ça ne change absolument rien.

Je dumpe depuis 2003, on est en 2016, et y a jamais eu le moindre problème, par contre côté émulateur, on essuie les platres, et je me demande si on en sortira un jour avec un logiciel PC reproduisant au final parfaitement le CPC.

Mais quoi qu'il en soit, je vous vois venir, vous cherchez à trouver un biais côté hardware pour justifier que les CDTs et WAV sont trafiqués, tout ça pour prouver que vos émulateurs tournent correctement.

Je vous ramène au point de départ, tout fonctionne parfaitement bien sur le vrai hardware et pas sur les émulateurs

Tiens j'ai discuté avec BDCiron ce jour, je lui ai raconté le problème rencontré, il m'a confié qu'il a le même problème avec le père Wilson pour Winape. Tout les timings de cet ému sont faux, et pire comme BDC passe son temps à pondre des démos qui utilisent des cas non documentés, elles ne fonctionnent pas sur Winape, et comme par hasard, il botte en touche, ses réponses à BDC "c'est putain tu fais chier, c'est tes démos qui déconnent (alors qu'elles fonctionnent très bien sur un CPC plus)".

C'est quoi le but, on vise à émuler la machine précisement comme un vrai CPC, ou bien on reste sur une émulation approximative et bancale ?

Pour finir, il me l'a dit lui-même, "tes CDTs ou WAV fonctionnent sur un CPC 464 ? Oui ? Alors c'est un problème d'émulation, ils peuvent retourner le problème dans tout les sens, y a une couille dans leurs émulateurs et c'est à eux de débugger".

_________________
SPS Community Expert (SPS CE) / SPS France

La tete de lecture n'est pas bloquée par le relais. Si il n'a pas de variation de champ magnétique devant la tête, le filtre passe haut de l'ampli va converger vers son point de repos, et l'entree du PPI restera stable. Et c'est l’émulation de ce filtre passe haut (et du trigger de Schmitt derrière) qui devrait résoudre les problèmes de polarité ...

Pas de facon voulue, mais dans le cas de LastMission si. Le loader prend la fin de son propre block pour le debut du suivant. C'est pas une protection, c'est juste du code pas préparé au comportement de l’émulateur.

>La tete de lecture n'est pas bloquée par le relais. Si il n'a pas de variation de champ magnétique devant la tête, le filtre passe haut de l'ampli va converger vers son point de repos, et l'entree du PPI restera stable. Et c'est l’émulation de ce filtre passe haut (et du trigger de Schmitt derrière) qui devrait résoudre les problèmes de polarité ...
En effet mais on revient à la même chose que l'on dit tous, pas avec les mêmes mots mais la même chose, Y'a rien qui arrive ou qui devrait arriver au ppi dans ce cas.

>Pas de facon voulue, mais dans le cas de LastMission si. Le loader prend la fin de son propre block pour le debut du suivant. C'est pas une protection, c'est juste du code pas préparé au comportement de l’émulateur.

Soit, c'est donc pas correctement emuler dans ce cas.


HS : Vous regarder pas machmalo à la télé ? Il passe dans le JT, il va nous sauver...
ou pas en faite.

Disons que, sans être électronicien, je comprends les schémas. Ca aide pour écrire un émulateur ! Par ailleurs, quand tu regardes le hard, comment il est fait, et comment la lecture de cassette fonctionne, ça tombe sous le sens.



Je suis d'accord : L'émulateur idéal doit avoir le fonctionnement identique à un CPC, à condition de lui donner les mêmes données d'entrées. Et, si le format CDT est idéal, un vrai CPC ne lit pas de fichier CDT.

Il faut parfois faire des concessions (et déterminer où se situer par rapport au vrai hard, ce qui est un mélange de compromis entre facilité d'émulation, précision, facilité d'utilisation, etc)

Le problème se pose surtout pour les cassettes, ou on a une électronique difficile à émuler qui va transformer le signal en entrée (qui va être, pour simplifier, un nombre réel compris entre -1 et 1) et celui sur le ppi (assimilable à un entier entre 0 et 1). Sachant que, du fait des propriétés de filtre du matériel, une valeur à -0.05 pourra être décodée comme un 1 ou un 0...


@dlfrsilver : La polarité existe. Dans le sens ou le loader de Mask attend un '0' PPI puis un '1'. (alors qu'en principe on se contente de l'inversion).
C'est son inversion que je trouve ... Etrange.... (un '0' deviendrait subitement un '1')

Tout est documenté, c'est le schéma du CPC/lecteur de casette. Par contre si on ne sait pas l’interpréter ....
J'ai déjà expliqué, il y a bien longtemps, comment fonctionne l'ampli de du lecteur (2 étage d'amplification avec filtre passe haut et passe bas + trigger de Schmitt). Avoir un état stable (c'est a dire pas de transition) pendant un certain temps implique quand meme un changement d'etat à la l'entree du PPI.

Le test teste le contraire : le PPI prends les donnée qu'on lui envoie, même moteur arreté.
Aucun émulateur ne feede en continu ...

Tu devrais arreter de te faire des films !

En attendant, certains jeux ne fonctionnent pas, donc si je croise ça avec le fait que tu dis savoir lire des schémas, j'en déduis donc que ce sont des processus non documentés que tu n'émules pas.

Quand on comprend de A à Z comment une machine fonctionne, on ne doit avoir aucun souci pour coder un équivalent logiciel.

Si je prends le cas de mes collègues de mame, qui codent les drivers qui permettent à l'émulateur de piloter le les pcb jamma virtuel, clairement c'est la fête à neuneu, tu peux avoir le schéma, et être incapable d'implémenter un comportement donné parce que pas mal de parties des pcbs, les puces mais aussi l'intéraction des puces entre elles et du hardware, c'est des boites noires, tu peux avoir une émulation CPU 100% parfaite, du chip graphique aussi, mais si tu te rates sur les timings, et sur les comportements qui ne sont pas écrit sur le schéma d'une PCB donnée, tu l'as dans l'os !

ça arrive régulièrement Et mame aujourd'hui émule au ras du métal, c'est bien la preuve que tu peux avoir tout bon partout, et que ça continue de merder sur l'émulation de certains jeux



ça c'est vraiment bidon Thomas comme excuse. Autant avant bon ok, les CDTs étaient fait à la one-again, les timings sortis d'on ne sait ou. Mais plus maintenant.

Et qu'un jeu comme Last Mission qui en dehors de stocker son programme principal dans un bloc pure data, est un format standard, c'est difficile de comprendre ce qui foire.

Le format CDT est complet, et permet de reproduire toute les subtilités présentes dans les cassettes, que ce soit les loaders et les protections ainsi que le stockage des données qui va avec. Maintenant dis moi que c'est pas évident de coder une routine qui va permettre de traduire le CDT en données numériques compréhensible par le CPC en bout de ligne, ça on peut l'entendre.



Justement. Cette fois avec César, on a choisi de faire les choses de manière carrée, c'est à dire non pas en se reposant sur les émulateurs, mais sur le vrai hardware. Y a eu trop de liberté de prise avec les émulateurs. quand ça marchait chez les uns ça marchait pas chez les autres, franchement marre !



Justement comme tu en parles, parlons-en : le CPC n'effectue qu'un filtrage léger. J'ai examiné les WAV que m'a envoyé JMD1200, qui ont été enregistrés depuis les pins de sorties de son 464, hé bien y a encore de la crasse dans ces WAV !

Le CPC lit de toute façon aussi bien un signal de forme "analogique" que "numérique".



César appelle ça dans le cas de Mask la "polarité opposée". Ni Basil ni Impossamole n'utilise ce principe.

_________________
SPS Community Expert (SPS CE) / SPS France

Pas de facon voulue, mais dans le cas de LastMission si. Le loader prend la fin de son propre block pour le debut du suivant. C'est pas une protection, c'est juste du code pas préparé au comportement de l’émulateur.[/quote]

Ce que je pige pas, c'est que le premier bloc de 263 octets est suivi d'une pause de 40ms, ensuite y a le bloc de 779 octets, contenant le code en lui-même du loader, puis le CPC éxecute le loader en question, et il y a un temps pendant lequel le z80 du CPC peut traiter, une pause de 6805ms avant d'arriver au bloc du programme principal d'une taille de 64608 octets (65ko quoi).

Il n'y a donc absolument aucune raison que les émulateurs se prennent les pieds dans le tapis. Il y a le temps nécessaire pour que chaque opération se déroule sans accro.

_________________
SPS Community Expert (SPS CE) / SPS France

Bon, perso, je voudrais juste réexpliquer quelque chose :

d'abord tous les émulateurs cpc ne sont pas au même niveau d'émulation. je m'explique : on a d'un côté des émulateurs plus proche du vrai hardware, c'est à dire qu'il émule le coeur du cpc, le gate array à 16Mhz, le Z80 à 4 Mhz, l'ay et le crtc à 1Mhz, etc.... C'est le cas de mon emu, et de celui de Lone...

et puis de l'autre des ému comme WinAPE et mame par exemple (aller vérifier dans le source de amstrad.c de Mame, j'y étais au commencement et comme dirais quelqu'un, je sais de quoi je parle) ) qui émule tout à 1Mhz ! pourquoi cette approche, parce qu'elle est basée sur une approche de performance et pas forcément sur l'exactitude du hardware !

Également, il ne faut pas oublier, qu'on a pas non plus ouvert tous les chipsets pour en faire une belle photo de l'intérieur et du réingénéring propre et compréhensible !!!

Si on prends exemple sur le crtc 6845 par exemple, l'émulation de mame est une catastrophe si on la compare au comportement réel du hardware et des différents types de crtc que l'on connait !

une autre anèdocte, quand on a fait le réingénering de l'AY : le doc du constructeur disait le contraire de ce que le hardware faisait exactement l'inverse :

// The datasheets say that the chip counts down. --> it's wrong if you study the internal chipset http://privatfrickler.de/blick-auf-den-chip-soundchip-general-instruments-ay-3-8910/

de plus !

pour en revenir au sujet qui nous intéresse, notre soucis, c'est que le PPI fourni au programme z80 qui lit le contenu de la K7 des 0 et des 1.

a) Comment on alimente cela ? en lisant le wav ou le cdt fourni en entrée !

par exemple pour traduire un wav en 0 et 1 à 4Mhz pour les fournir au PPI :

un wav c'est à 44100 Hz généralement

donc à un moment, je dois calculer quand je dois envoyer une nouvelle valeur au ppi, pour cela, je calcule :

tape_cpc_freq=4.0;// 4Mhz
wav_cpc_TState=Math.round(tape_cpc_freq*1000000.0/wav_freq);

ce qui donne dans notre cas : 90,702947845804988662131519274376

qui est arrondi pour l'instant dans mon cas !

b) A quoi ca sert ?

a me donner le longueur d'un pulse minimum... en multiple de 4Mhz c'est à dire la plus petite unité à laquelle le PPI sera fourni !

je calcule cela car j'utilise le même moteur pour construire ces pulses de 0 ou 1 entre le CDT et le WAV...

pour rappel sur CDT les pulses sont en 3.5Mhz (3.5Mhz (frequency of data in zxtape format))
alors qu'en WAV, c'est moi qui les calculs et les mets en 4.0 Mhz direct !

donc forcément, avec les arrondis, on peut imaginer des différences entre un CDT et un WAV à ce niveau !!!!

ensuite, je regarde en lisant le wave - PCM,
si la nouvelle valeur lue est supérieur à 0x80
j'enverrai 0 au ppi
sinon
j'enverrai 1 au ppi
et j'envoie valeur d'une durée qui correspondra à un multiple de 4Mhz !

c) donc si b) est faux, ça a rien à avoir avec l'émulation cpc des composants après, c'est soit le wav qui n'est pas au bon timming soit b) qui n'est pas correctement codé !
ce qui explique qu'on cherche pas forcément un bug d'émulation de composant, mais plutôt dans la préparation des données qui vont être envoyé au cpc.

--> si on prend l'exemple de mask, j'ai l'ancien cdt qui marche sans pb...ce qui prouve que si on envoie les données au ppi avec le bon timming attendu par le programme z80, celui-ci fonctionne sans pb et donc l'émulation des composants hardware du cpc est ok !

--> si on prends last mission, l'ancien cdt provoque le même pb de décalage -> cela vient donc soit des calculs timmings (calculé en b)) ou sinon d'autre chose dans l'émulation qui ne fonctionne pas comme attendu !

je confirme, je ne vois que des bandes bleu/noir dans le border sur mon emu.

Je plussoie avec ce que tu viens de dire Megachur.

Néanmoins, on joue sur les mots concernant le mot BUG.
Pour moi, un 'bug' est tout simplement un programme, un code qui ne fait pas ce que l'on attends de lui, ce que l'on voudrais avoir comme résultat.
C'est, pour 99% du temps, un probleme de code et donc de 'probleme' entre la chaise et l'écran.

Heureusement que toute personne qui code fait des erreurs, c'est comme ca que l'on avance, que l'on devient meilleurs.
Un dev ou quelqu'un qui code et qui n'a jamais fait d'erreur... en plus de 30 ans de pratique, j'amais vue.

Perso, j'utilise plus le terme 'ca bug', pour dire, ca part en couille
et pas,y'a un bug (même si j'ai du utiliser aussi ce terme quelque fois).
Tout ca pour dire, L'emulateur ne me donne pas comme résultat (écran, donnée, jeux...), le résultat que j'attendais PAR RAPPORT à mon matos d'origine.
Pour moi, c'est juste ce que je veux dire.

Pour Mame comme tu le dit, c'est beaucoup plus compliqué.
y'a PCB et PCB... On prends un bon vieux jeux et l'on va se retrouver à emuler du 74ls a gogo et un pov Z80... Point
et ca... on maitrise depuis belle lurette, c'est que des composants, les 74ls, très maitrisé en terme d'emulation.
émuler par contre une CPS3... c'est pas la même chose qu'un commando.
De plus, le code ou plutot les codes sur mame sont développé par un ensemble de personne.
Sur un emulateur de type CPC, en général, y'a que 1 ou 2 DEV qui porte le projet.

Je pense vraiment qu'il est très difficile de comparer le Dev sur Mame et Cpc.

Pour clore cette histoire de PPI, j'ai pour avoir l'esprit tranquille, testé quand même PHYSIQUEMENT ce que l'on voie sur le schéma.
Je confirme que, peu importe l'état du moteur du lecteur CPC et donc l'état du relais.
SI des données sont envoyé sur la tête de lecture, elles sont transmissent au PPI

Apres... bien sur que sur un CPC normal avec une K7 normal c'est pas possible (ou alors avec un gros tournevis pour faire tourner à la main, en forcant comme un boeuf)
Bien sur que les données ne sont pas traité plus loin, mais.... elles arrivent à la porte.
et cognent : Toc Toc
A QUELQU'UN ???!