bon, je vois ce soir, que vous comprenez que l'erreur qu'on détecte sur nos émulateurs peut être dû à plusieurs causes...

@dlfrsilver : quand je dis que l'émulation z80 n'est pas à 4Mhz, je veux dire qu'elle n'émule pas 4 appel au z80 par cycle de gate array (16Mhz) en plus des wait memory (mais cela a été clairement réexpliqué par Gérald)... Il y a quelques programmes qui ne marchent donc pas comme il faut, voir pas du tout sur WinAPE ou Mame pour cela !
je ne remets pas du tout en cause leurs choix d'émulation, car il est porté sur la performance plutôt que sur l'exactitude hardware ! Mon émulateur est donc forcément 'plus lent' comme cela et je ne te parle même pas du mode debug qui gére chaque appel au gate array soit un tous les 16Mhz !!!

si tu veux de la documentation sur les timmings du hard cpc, les classeurs WEKA ont un super chapitre dédié à ce sujet où tu pourras voir que la clock du z80 est dérivé de celle du GA et que c'est le GA qui le pilote entièrement !

dans 99% des cas cela marche mais ... tiens au hasard, essaye cette demo : http://cpcrulez.fr/demostestDO_the_equalizor_demo-malibu.htm... sur un émulateur !!!

Il y a quelque chose qui cloche dans le wav et le cdt :
Le wav :
- En inversant le fichier, le loader trouve enfin le bon mot de syncro et ne plante plus directement. Maintenant, il charge les sous bloc comme la version tapir, et plante au même moment.

Le CDT (et le wav par la même occasion)
- Le plantage a lieu a la fin du chargement, lors de la vérification du checksum. Au lieu d’être lu a la fin du bloc, il est lu dans le début du suivant.
- En debuggant avec WinApe, je vois que le loader ignore le premier sous bloc (bloc 10 du CDT), car il reste bloqué dans l'attente d'un pulse de syncho (qui se trouve dans le block 9 du CDT)

Maintenant, en regardant le CDT avec tapir, ainsi que le wav sous Audacity, j'ai l'impression qu'il manque un bit.

Le 1er block est constitué :
- Une série de pulse basse fréquence (dont on se fout, tant quelle n'est pas trop basse)
- exactement 10 pulse haute fréquence (le loader les compte)
- 256 pulse de calibration 0/1 (pattern 55*8 du bloc 6 du cdt)
- le byte (0x20), contenu dans le bloc 6 du cdt, reset du CPC si pas bon
- la taille du bloc (2 bytes, partiellement contenu dans le bloc 6)
C'est la que ça se gâte : Il manque le lsb de l'adresse dans le block 6 et le loader le reconstitue avec le premier pulse du bloc suivant.

- vient ensuite un pulse de syncro long suivit d'un court (block 7)
- 3 byte (bloc 9)
- pulse de syncro long + 4 court + 4 long .....

Le problème :c'est que le block 7 devrais contenir le lsb de la taille. Le loader se prend les pied dans le tapis, se resynchronise, et charge ce qu'il peut ... et plante


Pour la peine, voici un cdt qui marche
(avec un bit de plus au debut du bloc 7 qui devient 1000, 1000, 2421, 2421, 1032, 1032 )

EDIT : mauvais fichier, identique a l'original. Fichier correct plus bas

césar à trouvé le bug aujourd'hui, et l'a corriger dans l'outil (problème d'encodage).

Je poste le nouveau CDT de Mask à tester, dites-moi si vous voulez le WAV correspondant.

_________________
SPS Community Expert (SPS CE) / SPS France

Ca passe, en emu (WinApe) et sur CPC464 reel.

Par contre, le problème de ton wav est du au fait que le loader se base uniquement sur la durée de l’état bas des pulse. La plupart des autre loader mesure la durée entre deux transition (haut/bas ou haut/bas).
Il n'y a rien dans le CPC qui peu corriger ça automatiquement.

Merci, César a trouvé exactement le même souci que toi pour Mask.

tu me dis si tu veux tester d'autres softs

_________________
SPS Community Expert (SPS CE) / SPS France

Pour résumer les dernières pages :

- Mask... Finalement, le premier dump n'était pas correct ? Effectivement, ceux postés sur cette page fonctionnent. Reste-t-il des choses à investiguer ?

- Last mission, j'ai cru voir passer un message sur une accélération du wav pour arriver à le passer... Par ailleurs, j'ai effectivement des comportements différents quand je "differe" mon demarrage/arrêt de cassette. A 200ms, ça ne lit pas grand chose (ça s'arrête après le premier bloc), a 100, ça reste figé sur un écran noir/bordure vert à la fin du chargement, à 50, ca reset avec l'écran splitté, à 1 ms, ca reste figé sur l'écran de fin de chargement a la fin du chargement...
Je vais voir si je n'ai pas un bug, mais je suis intéressé si vous avez un wav qui fonctionne sur plein de 464 (histoire de pas chercher dans le vent)

Le WAV que j'ai posté de Last Mission fonctionne sur mon 464+. Pour Mask au final c'est bon, le bug a été trouvé et squashé. Le CDT posté fonctionne sur mon 464+ correctement.

_________________
SPS Community Expert (SPS CE) / SPS France

@Gérald : je reviens sur un 'vieux' post d'hier de ta part sur l'inertie du moteur lors d'une commande start ou stop.

-> De combien on estimerait cela, de l'ordre de 25ms ? ou quelques microseconds ?


côté de mon émulation CDT : mask_nouveauCDT_fixed.cdt et MASK1-UK-700-5100.CDT ne marchent pas...et reset au même endroit après que le premier compteur arrive à 000 !

@dlfrsilver : du coup, je veux bien le wav 100% conforme aussi pour test !

je dois avoir un problème d'arrondi ou autre dans la conversion du cdt en durée de pulse 0 et 1 !? ou pas d'inertie sur l'arrêt du moteur de k7 ?

Si tu veux aller dans ce sens, il aussi prendre le temps de commutation du relais...
pour moi, chercher dans cette voies n'a aucun sens, voir plus haut pourquoi.

Pour Last Mission, au moins 60ms pour être sur de passer le trailer du loader avant de charger le reste.
Des que j'ai mis la main sur une cassette a sacrifier, je fait des mesures.

Bien vu , c'est pas le bon, voila une update: Mais le dernier qu'a posté dlfrsilver fait la meme chose.

Pour appuyer le probleme d'inertie moteur non émulé de last mission, j'ai supprimer le trailer du bloc du loader.
Maintenant ca passe sur WinApe.

Le terme que vous utiliser n'est pas correcte.
Je ne dit pas que ce problème n'existe pas, attention, je dit, ce que vous chercher et que vous avez nommer N'EXISTE PAS

Je site : UN Problème d'inertie du moteur.

Il n'existe pas de lecteur de k7 embarqué sur un CPC6128, l'on passe/passait par un magnéto externe pour lire les jeux.
Jeux qui fonctionnaient très bien en externe au passage.

Par contre, le relais et sont temps de commutation existe bien sur les CPC

Ce que je vous chercher a 'définir' au niveau temps n'est tout simplement pas quantifiable précisément.
Ce que vous appeler LE temps d'inertie du moteur est la distance parcourue par la bande entre le moment où elle reçoit l'ordre de s’arrêter et qu'elle s’arrête réellement.
On est d'accord que ce temps existe et qu'il est mesurable en ms mais...

Il n'est pas 'générique', fixe, quantifiable précieusement
La valeur que vous allez définir (même si effectivement il faudra en mètre une, ne sera pas objectif).

Cette distance, ce temps n'est pas quantifiable précieusement car il dépends de beaucoup trop de paramètre mécanique non maitrisé et non définie.
Cela fonctionne comme une voiture qui freine, plus elle va vite, plus ca distance de freinage sera grande.
Comme nous le savons tous, la distance de freinage dépends de beaucoup de paramètre (route et voiture).

Cette vitesse de déroulement de bande n'est pas 'fixe' au ms prêt
Elle dépends :

- De l'état du moteur bien sur et de son calibrage (y'a matos et matos)...
- L'état physique de la courroie d'un lecteur a un autre et d'une marque à une autre.
- Je passe aussi la mécanique qui influence forcément les chose.
- La k7... Selon la force que la bande va produire sur la mécanique de l'ensemble (tête, translation bande, rotation engrenage de bande, position de la bande...)
Cela n'exercera pas la même force sur la translation 'a vide' (le freinage).

Ce que vous essayer de mesurer, de quantifier peu tres bien être de l'ordre de 25ms sur un lecteur CPC464, comme de 200ms sur mon lecteur de CPC464.
Comme d'ailleurs d'autres valeurs sur d'autre matos.

De plus, vous essayer de régler le tout par rapport à comportement d'1 jeu.
Ce n'est pas une bonne idée

Il me semble que mask ne passe que sur un cpc 464 avec 64ko (et sans fdc ça je sais plus ?) ! en tout cas c'est comme cela que je le teste !

en fait, quand le programme envoi le stop au moteur de K7, via le ppi, le moteur ne doit pas s'arrêter immédiatement et donc entraine encore pour un petit temps la bande sur la tête de lecture...

même si c'est 25ms... cela peut permettre au ppi de récupérer une autre valeur 0->1 ou 1->0 !?

on l'oublie souvent mais au dessus de l'électronique / le hardware, le but est de faire de la belle algèbre de Boole avec des 0 et des 1 des ou et des et (je vois déjà les jeux de mots se dessiner avant la St Valentin ) ce qui au final permet à un/des processeurs d'exécuter un programme et de donner des commandes aux autres puces !

Clairement Winape est tout sauf un modèle à suivre pour la lecture des cassettes. C'est bien le dernier émulateur que j'utiliserais pour ça.

Clairement, la vitesse de défilement virtuel de la bande doit être ajustée dans l'émulateur, en faisant une comparaison avec un CPC 464.

Next, Mask fonctionne sur 464,664,6128 et CPC plus à condition de faire ceci avant de lancer le jeu :

CLS:poke &C2d4,&C0:poke &374,&00 suivi d'entrée
puis taper RUN" et entrée.

ceci est lié à la protection du loader, qui vérifie qu'on ait bien tapé au clavier RUN" suivi de entrée.

Avec ce petit patch pour le loader, tu fais tourner tout les jeux protégés par la gremlin loader 2 & 3 (mask, samurai trilogy, pour ne citer qu'eux) sur CPC 464+.

_________________
SPS Community Expert (SPS CE) / SPS France