et donc c'est quoi la réponse à la question de Longshot : ???

c'est donc << FF >> et à quelle adresse mémoire ?

Également, s'il n'y a que des FF = RST #38 et des 00 = NOP, cela ne permet pas de refaire un retour au call #6000... il doit donc y avoir autre chose que juste cet octet !?


Avec le super nouvel outil pour générer des CDTs top, il serait bien de penser à refaire le CDT de "rat connection", non ?

Bonne question....



Absolument ! Je vais convaincre César histoire d'avoir ça comme il faut

_________________
SPS Community Expert (SPS CE) / SPS France

J'ai fait un autre test sur un 6128Plus (un Frankenstrad pour être exact, carte mère 6128Plus + clavier/magneto 464).
Ecran noir avec les 128k interne ainsi qu'avec la XMEM.
J'ai aussi testé plusieurs Z80 : Zilog, ST, Mostek sans changement.

Comme l'a fait remarqué Longshot, un ret apres &6000 en ram C4, et ca marche.

L'ideal serait d'avoir acces au 464+ qui marche.

qui en dehors de moi en possède un avec une extension de RAM ?

_________________
SPS Community Expert (SPS CE) / SPS France

Longshot et Gérald quel est l'offset exact en ram ? &6000 ou une autre position ?

voici ce que je garde en mémoire si je reset le 464+ au clavier juste après le chargement réussi du gros bloc à partir de &6000 :

AB864540001113689CC9ADB743310001

Je vois dans cette liste le RET (C9) dont tu parlais, entre le '9C' et le 'AD'.

si nécessaire, et si tu veux bien me coder un petit programme, je suis même près à essayer de sauver l'intégralité du contenu de l'extension mémoire dans un gros bloc, que je sauverais ensuite sur une cassette, que je dumperais et donc je pourrais faire l'extraction du contenu sous forme de fichier binaire
que je pourrais poster ici.

Je suis équipé, je peux le faire

EDIT : j'ai réussi à faire planter le jeu je vous explique ce que j'ai fait :

J'ai rentré ce petit programme qui me donne l'accès à &6000 jusqu'en &600F :

OUT &7F00,&C4: FOR n=&6000 TO &600F: ? HEX$(PEEK(n),2);: NEXT: OUT &7F00,&C0

si je regarde le contenu de &6000 à &600F AVANT de lancer le jeu, ce dernier crash avec un écran noir exactement comme pour vous !

C'est de plus en plus zarbi......

_________________
SPS Community Expert (SPS CE) / SPS France

Ca n'est pas utile d'avoir le contenu de la ram après un chargement correct, car on peut déjà l'avoir.
Tu as peut-être altéré la ram en C4 si tu n'as pas protégé cette ram avec un MEMORY.
Je n'ai pas défini d'adresse précise pour le RET, sauf à ce qu'elle soit plus loin que les vecteurs appelés via &416 (en général la musique dispose de quelques points d'entrée au début du player).

Qu'y a t il exactement dans C4 à partir de &6000 lorsque tu démarres à froid. Uniquement des 00 et des FF ?
Et que se passe t il si tu remplis la ram de 0 en C4 avant de lancer le chargement ?

La routine située en &38 est plutôt étonnante.
A première vue, elle récupère les entrées clavier et teste quelques touches pour "redémarrer" en sortant salement de l'interruption.
Une série de &38 n'aurait comme seul effet que de générer de nombreux appels à cette routine. Le premier EI ouvre la possibilité que des interruptions interviennent au sein de son propre code selon le positionnement des &FF en ram.

C'est supporté depuis la version 1.0.0.0 datant de ....25/03/2008
25/03/2008: HxCFloppyEmulator 1.0.0.0
-> Add variable bitrate + flakey/weak-bits support: All copy protection are now supported

CF : http://hxc2001.com/download/floppy_drive_emulator/hxcfloppyemulator_soft_release_notes.txt


Par contre, effectivement, ça ne concerne QUE la version USB de la carte (que je doit être le seul à encore avoir), LOL

Le problème, c'est que ça n'est pas supporté par le format HFE... Du coup, je ne sais même pas quel format utiliser pour que ça marche. Des idées ?

Oui, demandé a jeff tout simplement.
Si il dit que c'est supporté au niveau H/W de la hxc version Usb
c'est que forcement c'est testé et fonctionnel.
Donc c'est que c'est supporté dans un des formats supporté par la carte.
ET la liste est longue...le mieux est donc, de lui demandé.

Bonjour

Je poursuis les tests de génération de CDTs à l'aide du nouvel outil de césar.

voici pour l'instant le résultat des courses :

l'outil supporte actuellement 17 systèmes de protection pour les jeux amstrad K7.

soit :

- Alkatraz (très utilisée sur la majeure partie des jeux US GOLD)
- Amstrad (les blocs standard)
- Bleepload 2 (à noter que la notation et numérotation changera totalement, car la nomemclature utilisée par samp2cdt était incorrect. Par exemple, Rick Dangerous n'est pas un Bleepload 2, mais un Bleepload 3)
- Gremlin loader 1 (Basil PD et Mickey par exemple)
- Gremlin loader 2 (Impossamole)
- Gremlin loader 3 (Mask. La encore le nom du système d'encodage utilisé devra être changé, car Mask n'utilise pas le même système qu'Impossamole en l'occurence)
- Microkey (bobsleigh de digital integration)
- Operasoft (Last Mission, Cosa Nostra, Livingstone, guillermo tell, mythos, goody, ulises)
- Poliload (AMC, Satan en version espagnole, Jabato, Aspar Grand prix, After the War UK)
- Ricochet (rick dangerous 2 par exemple)
- Spectrum (de très nombreux jeux, comme Beast, dynamite dux, deflektor, et d'autres)
- Unilode (tout les jeux d'Oxford Digital Ent., c'est à dire Les jeux trivial pursuit, yes prime minister, Gazza II d'empire)
- zydroload (utilisé sur les jeux infogrames tel que Light corridor, North and South, Hostages)

arrive enfin la plus utilisée de toutes, la protection speedlock. Sur amstrad, il n'existe en fait que 4 encodages différents.

le nouvel outil les référence comme ceci :

--speedlock1 (pour speedlock à encodage de type 1)
--speedlock2 (pour le type 2)
--speedlock3 (pour le type 3)
--speedlock4 (pour le type 4)

Le type d'encodage n'a rien à voir avec l'année par contre. Batman the movie est un speedlock type 2 par exemple.

Celà amènera aussi une réorganisation totale des noms de protection. Cela sera du genre :

- Speedlock [année] [version] [version de l'encodage]

Sur Batman the movie, ça donnera ceci : Speedlock 1989 encodage type 2.

Les blocs de données des jeux speedlock seront à présent encodés par défaut par l'algorythme appelé 'Custom' qui ne sont rien d'autres que des blocs turbo avec des timings propriétaires.

Maintenant passons aux 3 types de fichiers avec lesquels on pourra travailler quand l'outil sera rendu public par César :

le format WAV :
--------------------

On l'obtiendra en premier lieu en dumpant la cassette originale que l'on veut extraire afin d'obtenir un fichier master CDT. Le nouvel outil rejettera automatiquement les dumps crasseux, comparativement à samp2cdt, qui lui était vraiment relaché de ce point de vue. Point positif à l'opposé, ce qui sera accepté n'aura pas les problèmes de blocs sales qu'on avait avant. Un petit outil permettra de faire un nettoyage de base, ceci de manière à garder intact les timings du WAV.

Il permettra aussi le passage au format CSW du fichier WAV pour une meilleure portabilité, tout en gardant de la manière la plus propre qui soit les timings. Le format retenu est le CSW type 1, le type 2 n'apportant absolument rien qui soit utilise. Le format WAV en entrée sera du 8 bits mono 44khz.

le format CSW :
--------------------

Ce sera le format intermédiaire, qui fera l'articulation entre le format natif, WAV, et le format master, le CDT.

La grande nouveauté du nouvel outil d'encodage, sera donc son aptitude à convertir un CDT en CSW, et le petit outil de nettoyage lui fera le passage de CSW en WAV.

on aura donc :

WAV<CSW<CDT et en réversion CDT<CSW<WAV

Ce qui est le plus important à retenir, est que le contenu du CDT sera exactement ce qui se trouvait dans le fichier WAV de départ, c'est à dire les timings seront exactement reportés dans le CSW, et qui seront à leur tour injecté par l'outil d'encodage dans le CDT final.

On pourra faire la réversion autant de fois qu'on le souhaitera, les données seront les mêmes peut-importe le format du fichier.

Point Bonus : les vieux CDTs pourris générés par samp2cdt seront automatiquement révélés, car la réversion ne fonctionne qu'avec un CDT correct (soyons clair, samp2cdt calculait à la one again les valeurs dont ne sait ou, donc ce sera très aléatoire point de vue résultat). Un certain nombre de CDT générés avec samp2cdt sont simplement mauvais.......

Il faudra donc refaire certains dumps, et cette fois, y aura plus de surprises avec des dumps claqués par l'outil de génération de CDT.

A noter aussi que lors d'une réversion de CDT vers CSW, puis CSW vers WAV, le WAV digital obtenu sera identique d'un point de vue pause et timings utilisés au WAV tiré de la cassette originale, avec une chose en moins : la crasse qui alourdissait ce dernier, n'étant pas présente dans le WAV digital, celui-ci se compressera bien mieux, et sera plus facilement proposable, voir pourquoi pas fourni avec les CDTs ?

Maintenant voici les résultats obtenus avec les nouveaux CDTs, CSW et WAV dans les quelques émulateurs testés :

CPCE : comme les timings sont à présent rigoureusement ceux des cassettes originales, certains jeux ne fonctionnent pas, ce qui est normal, puisqu'il avait été mis au point à un moment ou on utilisait samp2cdt.

Sugarbox : Tout les jeux en speedlock fonctionnent, pas de soucis en dehors de cas spéciaux comme Ocean beach volley. Les jeux en mode spectrum, ricochet, gremlin loader 1 et 2, poliload fonctionnent sans aucun problème.

Avec l'émulateur de Thomas, ça se gâte dès qu'on passe sur les jeux utilisant des encodages spéciaux.
je n'ai essuyé que des échecs avec la toute dernière version de l'émulateur avec les systèmes d'encodage Unilode, Operasoft, et gremlin loader 3. Alors la bonne blague, c'est que bien entendu, comme à présent les timings sont rigoureusement ceux des K7, y a plus de triche possible, soit l'émulateur enquille les données comme un vrai CPC, soit y a tout qui tombe par terre !

j'en suis au point ou par exemple, j'ai lancé Last Mission en CDT sous sugarbox, et l'écran de présentation est complètement flingué et coupé et deux. Ce qui veut dire qu'à l'issue du chargement, on a un bel écran rempli de pixels qui clignotent.

Ce jeu utilise l'encodage operasoft, qui est très simple en terme de stockage, il y a un loader en 2 bloc standard, suivi d'un bloc de type pure data. Sugarbox ne gère pas le format, et il ne gère pas non plus le jeu une fois réversé en CSW et en WAV digital.

Le wav digital fonctionne sur mes 464 et mon 464+....... mais pas sous sugarbox

j'ai eu un souci du même genre avec le jeu trivial pursuit nouvelle génération que j'ai acheté dernièrement et que j'ai dumpé et encodé avec l'outil. Le CDT généré fonctionne sous CPCE, caprice32, et une fois réversé en CSW puis WAV, ce dernier fonctionne sur vrai CPC mais pas sous sugarbox. L'émulateur lit le loader, et fait un reset à la lecture du bloc principal 'unilode'.

Enfin, je voudrais aborder le problème rencontré avec le format Gremlin loader 3, qui est utilisé sur le jeu Mask.

En avant propos je voudrais signaler ceci : nous avons découvert avec César que le fait d'avoir les timings exacts de la cassette dans le CDT fait que par exemple, mickey mouse comme Basil detective privé ou encore skate crazy n'ont plus besoin de l'option 'polarité' de CPCE. Avec les timings exact au lieu de timings sorti de la cuisse de jupiter, les jeux se chargent tel quel. Qui l'aurait cru ?

Sugarbox les charge sans souci, donc ça fait un truc en moins à gérer.

Néanmoins, le gremlin loader 1 et le gremlin loader 2 sont de complexité ascendante :

Les systèmes gremlin1, 2, 3 utilisent les polarités opposées. Le système Gremlin1 requiert des pilotes PAIRS tandis que les systèmes Gremlin2 et 3 ont besoin de pilotes IMPAIRS.

Par ailleurs, il n'y a pas de midsyncs avec le système gremlin1 (FOTY2, Mickey Mouse,Basil PD);
Le gremlin2 est à base de midsyncs courtes (Impossamole);
Le gremlin3 est à base midsyncs longues (Mask) ;

César a décodé le gremlin 3 entièrement, et c'est une vraie saloperie....

En tout cas, le CDT a exactement la même sonorité que la cassette, et le WAV digital tiré du CSW qui est lui même tiré du CDT fonctionne comme si on avait la vraie cassette, ça fait bizarre

Je les joints histoire que Thomas puisse voir ce qui ne va pas avec sugarbox, voir éventuellement l'émulateur de mégachur (que je ne peux pas tester malheureusement sur mon quadricore, c'est beaucoup trop lent).

Sous sugarbox, le WAV charge correctement de prime abord le premier ensemble de micro-blocs composant l'écran titre du jeu, et une fois le compteur arrivé à '000', ça fige sans raison, et l'émulateur fait un reset.

PS : convertir les CDT que j'ai uploadé en CSW ou en WAV avec les outils actuels ou sugarbox ne changeront rien au problème pour les jeux. Ils planteront exactement de la même manière.

_________________
SPS Community Expert (SPS CE) / SPS France

==> http://sasfepu78.fr/cgi-bin/Analyse_CDT.ksh?Last_Mission_F_loriciel
==> http://sasfepu78.fr/cgi-bin/Analyse_CDT.ksh?Trivial_Pursuit_Nouvelle_Generation_F_FaceA
==> http://sasfepu78.fr/cgi-bin/Analyse_CDT.ksh?Trivial_Pursuit_Nouvelle_Generation_F_FaceB

et Nbr de bloc > 4000 dans celui de mask... (PULSE SEQUENCE, PURE DATA BLOCK...)
D'ailleurs, ça à fait pété CPCTAPEXP... : Out Of memory, LOL

hé oui ahah ! Et il est impossible de faire autrement, le jeu est stocké sous cette forme
Il y en a quelques autres qui utilisent le même procédé.

Si tu veux les voir tous, utilise tapir plutôt que CPCtapeXP

Merci pour tes graphs !

_________________
SPS Community Expert (SPS CE) / SPS France

16 246 Blocs exactement pour mask
==> http://sasfepu78.fr/cgi-bin/Analyse_CDT.ksh?Mask

Ca en fait du monde...

Un tapir pour moi c'est ca =>

pour moi c'est ça tapir : http://www.worldofspectrum.org/pub/sinc ... pir1.0.zip

_________________
SPS Community Expert (SPS CE) / SPS France

le résultat de mes tests en mode 464 avec crtc 0 et 64ko sans FDC :

mask_nouveau CDT.7z [126.43 Kio] -> reset au bloc 1262 après le premier compteur !

trouvé 16247 blocs au total !!! je compte le bloc de commentaire

Last Mission (F) loriciel.7z [25.57 Kio] -> chargement bizarre de l'image de présentation - décalage ?! ne fait rien une fois chargé !?

décalage idem de l'image de présentation sur un autre ancien CDT testé -> bizarre !

Trivial Pursuit Nouvelle Generation_FR_Ubisoft_nouveau_CDT.7z [166.6 Kio] -> ok pas de problème !




il serait intéressant de fournir aussi les waves systématiquement aussi, juste pour voir si cela vient d'un traitement de mon émul particulier sur les CDTs ?!