ça ne marche pas chez moi, l'émulateur ne veut rien savoir. le chargement ne dépasse pas le premier bloc protégé, l'émulateur fige direct après.



le jeu va plus loin, effectivement, mais le jeu ne se charge pas. dès que la protection passe la clé, et tombe sur la dernière pause avant le gros bloc, le jeu fait un reset.



Je ne mélange rien du tout, et il n'y a rien d'aléatoire. Le SNA contient le loader déprotégé avec toutes les routines de protections bypassées, prêt à lire le gros bloc. Et même avec cette facilité la, l'émulateur plante.

ça n'a rien à voir avec une histoire de CPCE vs Caprice32 vs Sugarbox, mais avec un problème de gestion de pause et ou de blocs. La gestion ne se fait pas correctement, puisque dans le fichier CSW2 que tu génères, il y a une sorte de bug qui shoote une des pauses nécessaire à la protection. Sugarbox lit le fichier et execute le jeu alors que sur mon 464 ça entraine un reset dans la foulée !

Il faudrait vraiment je pense comme tu dis que tu te penches dessus.....



Le cdt avec csw ne possède pas la pause présente sur l'original, il marche certes, mais du coup le jeu n'est plus conforme à l'original, et ce n'est pas le but recherché pas vrai ?

_________________
SPS Community Expert (SPS CE) / SPS France

Pour illustrer mes propos voilà les visuels graphiques :

Photo 3 : Le WAV original de marmelade (celui de Rat Connection est identique trait pour trait) :

Photo 2 : le CSW de thomas avec la pause shootée et la clé collée au gros bloc

Photo 1 : la WAV converti à partir du CDT original de marmelade avec la pause avant et après la clé de protection, conforme au WAV original

_________________
SPS Community Expert (SPS CE) / SPS France

Bon, on tourne en rond.
Quand tu dis "l'émulateur plante", tu parles de quoi ? Le programme ? Ou observes-tu juste un reset de l'amstrad ? Ou l'amstrad est-il figé sur un écran noir/jaune/gris ?

J'ai fait la manip suivante :
- Dezip de la conf que tu mets un ou deux message au dessus
- selection de l'amstrad 464 FR dans la conf
- Reset pour bien faire
- drag'n'drop de rat connection en wav (15 mo)
- Ctrl-enter

Et le jeu se charge....

Les deux jeux plantent. Comme indiqué plus haut, Rat Connection en conf 464 FR (c'est bien celle-là que j'utilise), plante en CDT au bout de 8 secondes de chargement (et ce avec ta toute dernière mouture).

Marmelade va plus loin, je vois l'écran noir, le message qui dit chargement en cours veuillez patienter, l'écran devient bleu (signe que le décryptage s'est déroulé correctement, puis la clé est lue, et la le jeu reset).

J'ai déjà tout indiqué plus haut, je vois même pas pourquoi je réécris ici ce que j'ai déjà expliqué plus haut....



Tu te sers quel fichier wav, et converti à partir de quel outil ? Est-ce que tu peux le poster stp ?

_________________
SPS Community Expert (SPS CE) / SPS France

Celui que tu as posté ici :
viewtopic.php?f=2&t=5279&start=240#p29698

Le seul qui marche sur 464 si j'ai tout suivi..

Ok, j'ai repris mes 2 wavs, et comme indiqué plus haut :

- Marmelade plante au bout de 9 secondes, et fini par faire reseter Sugarbox (la 0.25b)
- Rat connection plante au bout de 9 secondes, et fini par faire reseter Sugarbox (la 0.25b)

9 secondes, c'est le temps nécessaire au chargement du premier bloc. Il y a un problème, et je pense que tu vas devoir mettre les mains dans le cambouis, car en programmation je ne peux pas t'aider

EDIT : ben ptet que si finalement, je viens d'examiner ce qu'il y a à 9 secondes dans chaque WAV, ton émulateur plante sur l'entête "illégal" du 2ème bloc. Il n'aime pas du tout le nom et le numéro du block.
à savoir :

[..............] Block 255 3

Si ce n'est pas le nom du bloc qui pose problème, ni le numéro de bloc, alors c'est le type du bloc qui ne passe pas. Comme tu peux le voir, "3" est une valeur illégale a cet endroit. Est-ce que ce ne serait pas lui qui serait la cause du crash ?

EDIT : je viens de spotter encore mieux que ça. Sur le WAV, à 9 secondes démarre le second bloc. En faisant CAT sous sugarbox, je viens de voir que ces 9 secondes correspondent à la fin du premier bloc.

La c'est fort de café, ça veut dire que dans le CDT, sugarbox "mange" la pause après le 1er bloc, et enchaine en lecture le 2ème !

Est-ce que tu peux regarder ça de plus près stp ?

_________________
SPS Community Expert (SPS CE) / SPS France

merci
mais en fait, je ne lis que le format cdt (pas csw ni wav !). Je n'avais pas trouvé d’intérêt à le coder par rapport au cdt à l'époque où j'avais implémenter l'émulation k7 !!!

différence notable sur les deux CDTs :

il n'y a plus de pause pour le dernier post de Marmelade (F) (1987) (464 only) (Basic v1.0) [Original] [TAPE].cdt (celui avec le bloc 14)
du coup, on ne détecte pas bien le début du fichier, si je mets le premier cdt "Marmelade (F) (1987) (464 only) (Basic v1.0) [Original] [TAPE].cdt" avec le bloc pause et le bloc 11 à la place du bloc 14 cela fonctionne !

celui que marche à de cdt Marmelade :

"Open CDT - id = ZXTape! - Version = 1.0" CDT.js:41:3
"block ID found = 20" CDT.js:64:1
4x "block ID found = 11" CDT.js:64:1
"block ID found = 12" CDT.js:64:1
"block ID found = 20" CDT.js:64:1
"block ID found = 11" CDT.js:64:1
"block ID found = ff"

l'autre cdt Marmelade qui marche pas à :
"Open CDT - id = ZXTape! - Version = 1.0" CDT.js:41:3
4x "block ID found = 11" CDT.js:64:1
"block ID found = 12" CDT.js:64:1
"block ID found = 20" CDT.js:64:1
"block ID found = 14" CDT.js:64:1
"block ID found = ff"

et Rat :
"Open CDT - id = ZXTape! - Version = 1.0" CDT.js:41:3
"block ID found = 20" CDT.js:64:1
4 x "block ID found = 11" CDT.js:64:1
"block ID found = 12" CDT.js:64:1
"block ID found = 20" CDT.js:64:1
"block ID found = 14" CDT.js:64:1
"block ID found = ff"


@dlfrsilver : -> est-il possible d'avoir un cdt de Rat Connection avec une pause au début et un bloc 11 à la place du bloc 14 pour test ?


et pour les deux cdts avec le bloc 14 :

Marmelade (F) (1987) (464 only) (Basic v1.0) [Original] [TAPE].cdt
zerobitpulselenght = 635
onebitpulselenght = 1270
Rat Connection (F) (1987) (464 only) (Basic v1.0) [Original] [TAPE].cdt
zerobitpulselenght = 400
onebitpulselenght = 1045

cela doit expliquer que Rat Connection est enregistré avec plus de bauds !?

comme je fais ensuite un Math.floor(length/3.5), cela tronque la partie décimale !
-> je vais essayer un Math.round(length/3.5) pour arrondir à l'unité la plus proche au cas où cela vienne de cela -> mais c'est la première cdt que je rencontre qui en aurait besoin !

nan, c'est pas ça ! arghhh !

@Denis : Voici une version "de test" pour valider que tu n'a pas le FDC branché (ca donne exactement ce que je vois en screenshot). Renomme ton ancien Sugarbox.exe, et mets celui-ci à la place.

Si tu as une popup qui pop, va valider que, dans ton fichier de config (CPC464FR.cfg sans doute, mais tu peux le vérifier dans le fichier Sugarbox.ini), tu as bien la ligne FDC=0 dans la section [Hardware] (apres la ligne PAL=0)


@Megachur : J'ai aussi ces problèmes d'arrondits (ça se voit sur les conversions : d'un wav correct vers un csw qui plante, par exemple). Je les ai pas encore résolu, mais j'y réfléchis : Faut ressortir ses math de compet' et ses incertitudes....

Confirmation que de base dans le fichier CPC464Fr.cfg, FDC est = à 0. De toute façon, s'il était visible, la protection se déclencherait en affichant le message "merci d'éteindre votre lecteur de disquette".

Et avec ce nouvel executable de sugarbox, j'ai toujours le problème au bout de 9 secondes. Même crash, même punition.

Par contre, le problème de décalage lié à la non prise en compte de la pause, ça c'est un problème.
C'est pas normal que sur le WAV généré par CDT2WAV j'ai le début du second bloc à 9 secondes, alors que toi tu as la fin du 1er bloc à ces fameuses 9 secondes.

La conclusion de ça, c'est bien qu'il y a un problème de prise en compte des pauses. Et comme ce programme ne tolère pas ça, et vu que la protection ne l'autorise pas, paf plantage et reset (il y a un timer dans le programme, qui vide les registres et reset la machine au moindre défaut de chargement).



Ah ok, je croyais que ce problème était résolu.....

_________________
SPS Community Expert (SPS CE) / SPS France

@Megachur : voilà un CDT de test avec un bloc 11 au lieu de 14.

Oui Rat se charge plus vite que Marmelade

_________________
SPS Community Expert (SPS CE) / SPS France

Merci !

Résultat du test -> reset également !
Cela exclu donc le problème de format différent des blocs pour le cdt !

Il va falloir dessassembler les deux loaders et voir ce qui est différent... on a peut-être un problème de timing quelquepart dans l'émulation ?!

peut-être une piste : j'ai fait un test d'augmenter la durée du pulse de la pause, effectivement dans ce cas, Marmelade ne passe plus !

Pour information, Cesar a lui-même désassemblé le loader des 2 jeux pour comprendre et voir à quoi il aurait à faire.

Et comme tu dis megachur, ça sent à plein nez un problème de timing, et donc de pause. On en revient à ce que je disais plus haut, la protection joue sur le timing justement, et si ça va pas reset ou crash.

J'ai eu le même souci au départ sur mon 464, j'ai vu que si je voulais charger le programme morceau par morceau, le programme n'aimait pas ça du tout. Si je separe les blocs, et que je les insére les uns après les autres, même si je fais attention, le programme reset sur mon 464. le jeu doit se charger d'une seule traite sans interruption.

_________________
SPS Community Expert (SPS CE) / SPS France

@denis : Bon, je reste sec sur le fait que ça ne fonctionne pas chez toi. Après avoir testé plusieurs config de pc, et même plusieurs utilisateurs, tous ont réussi à faire tourner ton wave de "Rat connection"

Du coup, je vais me reconcentrer sur ce fameux Rat connection (et pourquoi le cdt ne marche pas chez moi, alors que le wav, lui, fonctionne).

Dans ce cas qu'ils postent la version de sugarbox qu'ils utilisent et les paramètres annexes.
Par exemple j'utilise pas MAX, mais 100%, pour 100% conforme à la vitesse d'un CPC.



Je t'ai donné une piste de travail, Sugarbox semble ignorer/bugger/mal prendre en compte les pauses entre blocs (Voir mon explication quelque posts avant).

Comment tu les gères ces pauses ? Comment Sugarbox fait quand il en voit une arriver ?

_________________
SPS Community Expert (SPS CE) / SPS France

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.



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.




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).

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.

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).

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.
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 échantilloner des données qui sont continues, ce qui peut expliquer certains errement (et donc, un cdt qui passe et un wav qui ne passe pas, ou inversement).

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.

Ce ce que 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.