Inscription : 20 Août 2013, 18:03 Message(s) : 258
Citer :
tiens tiens... on commute les banks mémoire avec &c1 envoyé au PAL pour savoir s'il y a 64ko supplémentaire !
--> je vous laisse comprendre et conclure !!!
Conclure que le loader n'a pas charger la musique en ram d'extension alrs quelle est présente ? Ca on le savait déjà Le détection de l'extension par le jeu une fois chargé marche sur émulateur, il me semble que c'est le loader oublie quelque chose, non ?
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
Gerald a écrit :
Citer :
tiens tiens... on commute les banks mémoire avec &c1 envoyé au PAL pour savoir s'il y a 64ko supplémentaire !
--> je vous laisse comprendre et conclure !!!
Conclure que le loader n'a pas charger la musique en ram d'extension alrs quelle est présente ? Ca on le savait déjà Le détection de l'extension par le jeu une fois chargé marche sur émulateur, il me semble que c'est le loader oublie quelque chose, non ?
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
breiztiger a écrit :
denis,
serait il possible d'avoir le wav d'origine ?
merci d'avance
Je ne l'ai plus. Le jeu a brulé dans l'ancienne maison de mes parents.
Le CDT n'est pas du tout en cause. Au contraire, le premier que j'avais généré avec samp2cdt était mauvais, parce que l'outil ne calculait pas correctement les valeurs des timings utilisés.
Ce nouveau CDT crée à l'aide du CSW tiré du WAV que j'avais fait (je ne l'ai plus, à l'époque je n'avais pas assez d'espace disque, je l'ai effacé).
Qu'est-ce que tu cherches à savoir exactement ? Le WAV digital que j'ai fourni est une réplique 100% exacte du CDT (grâce aux 2 nouveaux outils de césar).
Y a t'il quelque chose qui ne va pas ?
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Megachur a écrit :
Gerald a écrit :
Citer :
tiens tiens... on commute les banks mémoire avec &c1 envoyé au PAL pour savoir s'il y a 64ko supplémentaire !
--> je vous laisse comprendre et conclure !!!
Conclure que le loader n'a pas charger la musique en ram d'extension alrs quelle est présente ? Ca on le savait déjà Le détection de l'extension par le jeu une fois chargé marche sur émulateur, il me semble que c'est le loader oublie quelque chose, non ?
très bonne analyse ! BRAVO !
Merci pour toutes ces informations
Donc dit de manière simple, c'est quoi au final qui coince ? Le jeu fonctionne en mode 64k sur mon 464+ si je retire la X-mem.
j'ai un souci, comme indiqué sur un autre topic, j'ai le cable pour connecter la X-mem sur un 464 standard, le problème c'est qu'elle n'est pas vue par mes 464, à cause d'un problème de contact :/
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 20 Août 2013, 18:03 Message(s) : 258
dlfrsilver a écrit :
Je te mets sur la piste : dans tout les émulateurs, pour une raison inconnue, le programme active avant le moment T la musique après avoir détecté les 128k présents.
Problème : La musique n'a pas encore été chargée, résultat la routine fait un saut dans une grosse quantitée de zéros de la bank 7 => plantage complet du programme.
ça pue un problème de timing ou d'émulation de timing lié au gate array et au système de gestion de bank de RAM, qui est incorrect en l'état. Le pire c'est que tout les émulateurs, ceux qui ont une émulation z80 100% bonne ou ceux qui n'ont pas le set d'instruction 100% bon ont le même problème.
Merci de ton aide pour ce problème d'émulation
Je viens de tester (entre autre) le .wav Sur 464 sans extension mémoire : OK Sur 464 avec extension mémoire (XMEM) : KO, ecran noir
En même temps que le chargement, j'avais mon analyseur logique prêt a déclencher au moindre accès à la RAM d'extension. Le premier accès se fait pour le test, juste avant le grand saut dans le vide (en 6000 / C4), voir le message de Megachur.
Après analyse du/des loader, j'en conclus que : - le loader ne teste pas la présence de la RAM d'extension - le loader ne charge rien en mémoire d'extension
- le code principal ne transfert rien en RAM d'extension non plus
Inscription : 28 Août 2008, 23:41 Message(s) : 270
Citer :
Il y a une différence entre le 464 avec extension mémoire et le 6128 lors de l’utilisation du mode C3. En mode C3, le bloc 7 est visible entre 0x4000 et 0x7ffff. Sur un 464, si la ROM haute est active, c'est la ROM qui est visible, pas la RAM d'extension. Par contre les écritures se font dans la RAM.
Je pense que tu voulais plutôt écrire que le bloc 3 est visible entre 0x4000 et 0x7FFF, et non pas le bloc 7 (qui lui devient aussi visible entre 0xC000 et 0xFFFF avec le mode "C3"). Ceci étant dit, par rapport à la situation, le test de la ram est réalisé en utilisant C1 et non C3, en utilisant C000.
Il y a pas mal de trucs louches dans le loader et même après. Il ne semble cependant faire aucun test de mémoire avant de démarrer en &38. A moins que ce soit le programme principal qui soit sensé charger après le test de la ram... A noter que lors de l'appel en &6000, on arrive en &8000 ou on retombe sur un changement de mode via CALL BC0E... mais qui va lui même faire un RST 08, qui vient d'être dévié, et qui sert au jeu à tester une touche....
dlfrsilver, es tu certain que c'est bien le cdt que tu as mis en ligne qui se charge sur ton vrai 464 avec extension et qu'il utilise les 128 k?
Si tu confirmes, il faudrait savoir quelle partie aurait du continuer à charger le reste (avant ou après le transfert du code en 240), sachant que le code principal contient aussi des routines de chargement cassette (il suffit de chercher LD B,&F6 / LD A,&10)
Inscription : 28 Août 2008, 23:41 Message(s) : 270
Citer :
Sur 464 avec extension mémoire (XMEM) : KO, ecran noir
Le post de Gerald remet donc en question le cdt. Reste à savoir si dlfrsilver reconfirme ou pas que le cdt fonctionne bien sur un 464+ avec extension (et si oui, si il utilise les 128 k ou pas)
Inscription : 20 Août 2013, 18:03 Message(s) : 258
Longshot a écrit :
Citer :
Il y a une différence entre le 464 avec extension mémoire et le 6128 lors de l’utilisation du mode C3. En mode C3, le bloc 7 est visible entre 0x4000 et 0x7ffff. Sur un 464, si la ROM haute est active, c'est la ROM qui est visible, pas la RAM d'extension. Par contre les écritures se font dans la RAM.
Je pense que tu voulais plutôt écrire que le bloc 3 est visible entre 0x4000 et 0x7FFF, et non pas le bloc 7 (qui lui devient aussi visible entre 0xC000 et 0xFFFF avec le mode "C3"). Ceci étant dit, par rapport à la situation, le test de la ram est réalisé en utilisant C1 et non C3, en utilisant C000.
Tu as raison, je me suis emmêlé les pinceaux ! Ce que je voulais dire, et de façon générale, sur un 464 avec extension mémoire le mode c3 a un effet de bord non present sur un 6128. Quand la ROM haute est activée, elle devient visible aussi en 0x4000-0x7fff.
Ici, le programme n'utilise que les mode C1 (pour le test) et C4.
Longshot a écrit :
Il y a pas mal de trucs louches dans le loader et même après.
Pour etre louche, il est louche. Entre les test Multiface, le sabotage du FDC, et le code modifié en plein chargement
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Longshot a écrit :
Citer :
Sur 464 avec extension mémoire (XMEM) : KO, ecran noir
Le post de Gerald remet donc en question le cdt. Reste à savoir si dlfrsilver reconfirme ou pas que le cdt fonctionne bien sur un 464+ avec extension (et si oui, si il utilise les 128 k ou pas)
Messieurs, le CDT que j'ai fourni tout comme le WAV ont été généré par un nouvel outil de génération de CDT, dont la base de création a été le constat suivant:
1) les timings des cassettes ne sont pas fixes, contrairement à ce que faisait samp2cdt. Ils sont variables.
Avec ce nouvel outil, les timings présents dans la cassette d'origine et que l'on retrouve dans la WAV tiré de la cassette originale, se retrouvent en bout de chaine dans le CDT.
je m'explique : quand je dumpe dorénavant un jeu, je récupère un fichier WAV, que je sauvegarde sur mon disque dur. Ensuite, j'examine le signal du fichier WAV, afin de déterminer le niveau de bruit/crasse.
Si le niveau de bruit est correct, j'utilise un premier outil qui compresse le WAV en CSW1. Ce nouveau petit outil garde intact les timings internes du WAV. Vient ensuite le nouvel outil, dont les routines de détection et d'encodage sont infiniment plus pointues que celles de samp2cdt.
La ou samp2cdt avait du mal à décoder, et générait même des fois des CDTs avec les speedlock qui ne marchait pas ou bien mal, tout ça c'est terminé. Non seulement l'outil fait le travail en une seule passe, mais en plus on a une bien meilleure vue sur les données qu'on obtient.
Son gros point fort, c'est qu'un CDT généré par cet outil, peut être converti en mode lossless en CSW1, qui avec le premier outil de conversion WAV=>CSW1 permet aussi de faire l'inverse, soit CSW1=>WAV.
Ce dernier WAV est identique en terme de contenu au CSW1, qui lui même était identique dans son contenu au CDT.
Ce qui veut dire que les CDTs approximatifs, avec des valeurs calculées approximativement, et ayant de la perte en sortie, c'est terminé.
J'ai testé et traité plus de 600 jeux au moment ou je vous parle de ça.
Il permet de plus de générer des CDTs 100% identiques au contenu des cassettes de jeux auparavant impossible à faire : les jeux operasoft super dur à dumper sont pris en charge, ainsi que la protection UNILODE par exemple, qui est utilisée sur les trivial pursuits.
Si le dump tiré de la K7 est bon, alors un CDT master est faisable
Autre point positif, cet outil permet également de vérifier la viabilité d'un CDT ancienne génération crée avec samp2cdt.
Si la réversion en WAV est incorrecte (car les routines étant plus précises et plus pointues), ça veut dire que le CDT dont il est issu a des timings foireux..... je vous laisse deviner la suite (faut redumper...)
Concernant ce CDT, il marche en mode 64k sur les 2 464 que j'ai à la maison, et sur mon 464+ sans la X-mem.
Avec la X-mem de toto, le jeu se charge en mode 128k, c'est à dire au lieu que le jeu m'affiche un message après le chargement du gros bloc 'STOP THE TAPE', j'ai un autre écran qui apparait à la place, et qui m'affiche 'OCEAN BEACH VOLLEY', avec plus bas 'LOADING DATA', et une ligne en dessous 'SEARCHING 1', qui est rapidement remplacé par 'LOADING X', X étant le numéro du bloc à charger. S'ensuit le chargement à la chaine des 9 blocks correspondant à chaque pays, et à l'issue du chargement du bloc 9, j'ai le message 'STOP THE TAPE', la musique démarre, et il n'y a plus aucun chargement.
Comme je l'ai indiqué, le CDT et le WAV sont totalement hors de cause. S'ils ne fonctionnaient pas, je ne les aurait jamais posté pour commencer, et ces derniers ont été dument vérifiés.
je vais vous poster une photo de l'écran quand on passe en mode 128k.
Pour la protection speedlock utilisée, bien entendu, je suis au courant qu'il y a une routine anti-multiface impossible à esquiver, un brouilleur de FDC pour empêcher le transfert des données sur disquette, quand au code modifié en plein chargement ça m'étonne pas non plus c'est typique
_________________ SPS Community Expert (SPS CE) / SPS France
Inscription : 29 Août 2007, 12:04 Message(s) : 2009 Localisation : seine et marne 77
Giants a écrit :
D'où l’utilité de garder quelque part la 'source' du dump original. Wav pour les K7, Flux pour les disquettes.
La grande différence, c'est que la ou un dump en flux est utilisable en disquette, plus de 90% des wavs ne sont pas utilisables en l'état.
C'est pour ça que je ne les fournis pas tel quels, ils sont trop sales et ne fonctionnent pas bien souvent sur les émulateurs, car ils n'ont pas de routine émulant la capacité qu'on les vrais CPCs de pouvoir filtrer le signal.
Et ici Giants, il n'y a pas de problème côté CDT et WAV, il s'agit d'un problème d'émulation, et non documenté. L'amstrad CPC possède encore des zones d'ombres, et certains logiciels font encore de la resistance.
Encore dernièrement, J'en ai discuté avec Syx, y a encore des bugs (exemple dernièrement avec Winape, qui pourtant disait posséder un set d'instruction 100% parfait, hé ben raté, il a spotté un bug.)
L'amstrad CPC, malgré sa simplicité apparente, utilise comme tout ordinateur (Amiga, ou ST ou C64 lol) des fonctions inconnues et non documentées, que ce soit avec le z80, ou les autres puces, ou encore l'architecture même de la machine.
Problème : les programmeurs ont désossé les machines, découvert des fonctions ou des particularités et les ont exploitées quand ils ont conçu les jeux. Conséquence, si l'émulateur ne tient pas compte de ça, certains jeux ne fonctionnent pas correctement.
Et ici c'est un cas typique.
Je joins les photos que j'ai prise de mon 464+ avec la X-mem au cul, plus les écrans de chargement du mode 128k.
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
_________________ SPS Community Expert (SPS CE) / SPS France
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 28 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum
Connexion
Inscription
FAQ
