TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE

Giants · **Inscription :** 21 Août 2008, 16:03 **Message(s) :** 342

Tout a fait.
Mais ma remarque etait generique, pas en rapport avec le probleme en court.
Je pense qu'ils faut des personnes competentes sur cpc, et au vue des derniers posts ici, c'est le cas.
Je n'ai pas de doute aue vous allez trouver la raison et peu etre une solution.
Je suis ca en arriere plans

Lone · **Publié :** 31 Jan 2016, 20:34

Je ne vais pas discuter de ton outil, il parait très bien. Le dump parait aussi très bien.
Les émulateurs aussi (vu qu'ils émulent ce que fait un vrai 464, c'est à dire rien).

De deux choses l'une :
- Soit l'original marche sur un 464 a 128ko, et là, on a un problème de dump (vu qu'après dump, ça ne marche plus) avant même de parler émulation
- Soit l'original ne marche pas non plus, et donc tout est conforme (mon petit doigt me dit que l'on est dans ce cas là). Du coup, c'est sans doute un bug du jeu (à moins que ça ne soit voulu... ?)

L'autre point qui change, c'est tout de même ce fameux basic 1.1... Peut être un appel spécifique est-il fait dans le cas des 128ko détecté (je n'ai pas débuggé le jeu, ce sont des hypothèses) ?
Difficile à tester sur mon propre émulateur, vu que je n'émule pas le 464+, et que le basic 1.1+l'OS 464 donne un résultat... Inhabituel...

Longshot · **Inscription :** 28 Août 2008, 23:41 **Message(s) :** 270

Citer :

Sur 464 avec extension mémoire (XMEM) : KO, ecran noir

Quelle différence entre le 464-128k "Gerald" et le 464+-128k "dlfrsilver" vu que vous avez tous les deux une x-mem?
L'information importante, c'est que le chargement complémentaire a lieu après le loader.
Le message affiché pendant ce chargement est bien dans le code chargé. (2BA9 pour "LOADING LEVEL DATA")

Citer :

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

Il y a aussi le faux "RET Z" en mettant ED devant C8, et pour lequel l'émulateur Z80A ne se laisse pas "berner".

dlfrsilver · **Publié :** 31 Jan 2016, 20:37

Giants a écrit :

Tout a fait.
Mais ma remarque etait generique, pas en rapport avec le probleme en court.
Je pense qu'ils faut des personnes competentes sur cpc, et au vue des derniers posts ici, c'est le cas.
Je n'ai pas de doute aue vous allez trouver la raison et peu etre une solution.
Je suis ca en arriere plans

Oui je suis ravi que Longshot ainsi que Gerald aient participé, j'espère bien qu'ils pourront nous aider

dlfrsilver · **Publié :** 31 Jan 2016, 20:55

Longshot a écrit :

Citer :

Sur 464 avec extension mémoire (XMEM) : KO, ecran noir

Quelle différence entre le 464-128k "Gerald" et le 464+-128k "dlfrsilver" vu que vous avez tous les deux une x-mem?
L'information importante, c'est que le chargement complémentaire a lieu après le loader.
Le message affiché pendant ce chargement est bien dans le code chargé. (2BA9 pour "LOADING LEVEL DATA")

Citer :

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

Il y a aussi le faux "RET Z" en mettant ED devant C8, et pour lequel l'émulateur Z80A ne se laisse pas "berner".

Tu peux nous en dire plus au sujet du RET Z ?

Longshot · **Inscription :** 28 Août 2008, 23:41 **Message(s) :** 270

Citer :

Tu peux nous en dire plus au sujet du RET Z ?

Exemple d'un des décodeurs speedlock:

...
9A1C : LD A,R
9A1E : XOR E
9A1F : SUB(HL)
9A20 : DEC DE >>> Compteur de boucle
9A21 : LD (HL),A
9A22 : LD A,E >>> Début test DE
9A23 : INC HL
9A24 : OR D >>> Z=1 si DE=0
9A25 : RET Z ... mais codé comme ED CA
9A27 : NOP
9A28 : NOP
9A29 : JP NZ, boucle

Lorsqu'on arrive en 9A25 avec Z=1, le RET Z ne fonctionne pas à cause du préfixe ED.
Je pense que le désassembleur devrait éviter de le montrer comme un RET Z dans ce cas!

dlfrsilver · **Publié :** 31 Jan 2016, 23:11

Longshot a écrit :

Citer :

Tu peux nous en dire plus au sujet du RET Z ?

Exemple d'un des décodeurs speedlock:

...
9A1C : LD A,R
9A1E : XOR E
9A1F : SUB(HL)
9A20 : DEC DE >>> Compteur de boucle
9A21 : LD (HL),A
9A22 : LD A,E >>> Début test DE
9A23 : INC HL
9A24 : OR D >>> Z=1 si DE=0
9A25 : RET Z ... mais codé comme ED CA
9A27 : NOP
9A28 : NOP
9A29 : JP NZ, boucle

Lorsqu'on arrive en 9A25 avec Z=1, le RET Z ne fonctionne pas à cause du préfixe ED.
Je pense que le désassembleur devrait éviter de le montrer comme un RET Z dans ce cas!

en fait c'est voulu

y a la même chose sur certaines protections de l'amiga héhéhé

AsT · **Publié :** 31 Jan 2016, 23:57

@Longshot : quelle difference exacte entre Ret z (ed ca) et Ret z (c8) ?
Je pensais que c'etait la meme instruction du z80... D'après ce que je lis, il y aurait une certaine différence.

Longshot · **Inscription :** 28 Août 2008, 23:41 **Message(s) :** 270

Ce que je disais pour ED C8, c'est que le désassembleur devrait indiquer que l'instruction est non conventionnelle.

Je confirme que c'est le programme principal qui charge le reste du jeu.
En &FE4E, on a un EI suivi d'un JP &240. L'interruption en attente ne peut pas intervenir avant l'exécution du JP.
Elle se produit donc en &240. Au retour le code en &240 teste la ram disponible (&2DF=1 si ram)
La fonction qui permet d'appeler une routine en ram supplémentaire est en &416 (HL=adresse d'exécution en ram)
La fonction qui permet de charger tous les levels en ram si la ram supplémentaire est détectée est en &237A
On a :
&0283 : LD HL,&6000 ; adresse en ram ext
&0286 : CALL &416 ; appel si ram présente
&0289 : CALL &237A ; charge tout si ram présente

Si on met un RET en &7FFF de la banque C4, tout fonctionne correctement.
Le CALL &416 revient sans bobo, et tout est chargé.
Reste à trouver ou l'octet maudit manque réellement et pourquoi.

dlfrsilver

Longshot a écrit :

Ce que je disais pour ED C8, c'est que le désassembleur devrait indiquer que l'instruction est non conventionnelle.

Je confirme que c'est le programme principal qui charge le reste du jeu.
En &FE4E, on a un EI suivi d'un JP &240. L'interruption en attente ne peut pas intervenir avant l'exécution du JP.
Elle se produit donc en &240. Au retour le code en &240 teste la ram disponible (&2DF=1 si ram)
La fonction qui permet d'appeler une routine en ram supplémentaire est en &416 (HL=adresse d'exécution en ram)
La fonction qui permet de charger tous les levels en ram si la ram supplémentaire est détectée est en &237A
On a :
&0283 : LD HL,&6000 ; adresse en ram ext
&0286 : CALL &416 ; appel si ram présente
&0289 : CALL &237A ; charge tout si ram présente

Si on met un RET en &7FFF de la banque C4, tout fonctionne correctement.
Le CALL &416 revient sans bobo, et tout est chargé.
Reste à trouver ou l'octet maudit manque réellement et pourquoi.

Longshot, une question simple, toi qui connais très très bien le code z80, et l'amstrad.

Question à 200 euros pour toi : D'après toi, la Ram de l'amstrad au démarrage, c'est une étendue de zéro dans toutes les banks, ou bien il y a des patterns pré-déterminées présentes avec des octets particuliers qui ne sont présentes que dans les RAMs des vrais CPC, mais pas implémenté dans les émulateurs ?

J'ai cru voir que pour chacun des émulateurs, quand on initilialise le cpc émulé, c'est plus des zéros dans l'ensemble que les patterns présents d'origine.......

Si beach volley fait usage de ça, si c'est pas implémenté, dans le huh lulu !

Longshot · **Inscription :** 28 Août 2008, 23:41 **Message(s) :** 270

Citer :

@Longshot : quelle difference exacte entre Ret z (ed ca) et Ret z (c8) ?
Je pensais que c'etait la meme instruction du z80... D'après ce que je lis, il y aurait une certaine différence.

ED CA se comporte comme un "NOP", puisque lorsque Z vaut 1, l'instruction ne fait pas un RET.
ED CA prend autant de temps qu'un C8 (lorsque Z vaut 0)

AsT

dlfrsilver a écrit :

Longshot a écrit :

Ce que je disais pour ED C8, c'est que le désassembleur devrait indiquer que l'instruction est non conventionnelle.

Je confirme que c'est le programme principal qui charge le reste du jeu.
En &FE4E, on a un EI suivi d'un JP &240. L'interruption en attente ne peut pas intervenir avant l'exécution du JP.
Elle se produit donc en &240. Au retour le code en &240 teste la ram disponible (&2DF=1 si ram)
La fonction qui permet d'appeler une routine en ram supplémentaire est en &416 (HL=adresse d'exécution en ram)
La fonction qui permet de charger tous les levels en ram si la ram supplémentaire est détectée est en &237A
On a :
&0283 : LD HL,&6000 ; adresse en ram ext
&0286 : CALL &416 ; appel si ram présente
&0289 : CALL &237A ; charge tout si ram présente

Si on met un RET en &7FFF de la banque C4, tout fonctionne correctement.
Le CALL &416 revient sans bobo, et tout est chargé.
Reste à trouver ou l'octet maudit manque réellement et pourquoi.

Longshot, une question simple, toi qui connais très très bien le code z80, et l'amstrad.

Question à 200 euros pour toi : D'après toi, la Ram de l'amstrad au démarrage, c'est une étendue de zéro dans toutes les banks, ou bien il y a des patterns pré-déterminées présentes avec des octets particuliers qui ne sont présentes que dans les RAMs des vrais CPC, mais pas implémenté dans les émulateurs ?

J'ai cru voir que pour chacun des émulateurs, quand on initilialise le cpc émulé, c'est plus des zéros dans l'ensemble que les patterns présents d'origine.......

Si beach volley fait usage de ça, si c'est pas implémenté, dans le huh lulu !

Je peux te dire que sur les emulateurs (winape par exemple), la ram etendue est effacée ce qui n'est pas le cas sur un Cpc Classique où il peut rester un peu d'octets differents de 0 dans la ram étendue.

Edit : c'est pour cela que Madram teste plusieurs adresses différentes (donc plusieurs octets) pour effectuer ses tests mémoires sur OrgAms.

dlfrsilver

AsT a écrit :

dlfrsilver a écrit :

Longshot a écrit :

Ce que je disais pour ED C8, c'est que le désassembleur devrait indiquer que l'instruction est non conventionnelle.

Je confirme que c'est le programme principal qui charge le reste du jeu.
En &FE4E, on a un EI suivi d'un JP &240. L'interruption en attente ne peut pas intervenir avant l'exécution du JP.
Elle se produit donc en &240. Au retour le code en &240 teste la ram disponible (&2DF=1 si ram)
La fonction qui permet d'appeler une routine en ram supplémentaire est en &416 (HL=adresse d'exécution en ram)
La fonction qui permet de charger tous les levels en ram si la ram supplémentaire est détectée est en &237A
On a :
&0283 : LD HL,&6000 ; adresse en ram ext
&0286 : CALL &416 ; appel si ram présente
&0289 : CALL &237A ; charge tout si ram présente

Si on met un RET en &7FFF de la banque C4, tout fonctionne correctement.
Le CALL &416 revient sans bobo, et tout est chargé.
Reste à trouver ou l'octet maudit manque réellement et pourquoi.

Longshot, une question simple, toi qui connais très très bien le code z80, et l'amstrad.

Question à 200 euros pour toi : D'après toi, la Ram de l'amstrad au démarrage, c'est une étendue de zéro dans toutes les banks, ou bien il y a des patterns pré-déterminées présentes avec des octets particuliers qui ne sont présentes que dans les RAMs des vrais CPC, mais pas implémenté dans les émulateurs ?

J'ai cru voir que pour chacun des émulateurs, quand on initilialise le cpc émulé, c'est plus des zéros dans l'ensemble que les patterns présents d'origine.......

Si beach volley fait usage de ça, si c'est pas implémenté, dans le huh lulu !

Je peux te dire que sur les emulateurs (winape par exemple), la ram etendue est effacée ce qui n'est pas le cas sur un Cpc Classique où il peut rester un peu d'octets differents de 0 dans la ram étendue.

Edit : c'est pour cela que Madram teste plusieurs adresses différentes (donc plusieurs octets) pour effectuer ses tests mémoires sur OrgAms.

ahhhhh..... oh mais je viens de penser à truc là..... la X-mem, c'est pas de la RAM classique, c'est de la flashrom !!!! Elle viendrait pas de la la différence ?

Parce que dans les extensions des 464 genre DKtronics, c'est bien de la 4164-15 (DRAM), donc volatile, qui s'efface quand on coupe.

Doit y avoir une explication..... bon sang quelle différence il y a vraiment entre une DKtronics et une X-mem......

Longshot · **Inscription :** 28 Août 2008, 23:41 **Message(s) :** 270

Je crois que la plupart des intervenants ici connaissent très très très bien le cpc

Citer :

ou bien il y a des patterns pré-déterminées présentes avec des octets particuliers qui ne sont présentes que dans les RAMs des vrais CPC, mais pas implémenté dans les émulateurs ?

Sur un 6128, les rams ne sont pas initialisées par les roms en démarrage à froid. Le contenu m'a toujours paru instable et on ne peut donc pas se fier aux valeurs qui peuvent changer entre 2 démarrages. Peut-être que c'est différent sur une extension mais j'ai un doute.
C'est assez simple à vérifier en basic. D'ailleurs avant que tu charges le jeu sur le 464 avec la xmem, peux tu regarder quel est le premier octet que tu trouves différent de 0 à partir de &6000 ?

dlfrsilver

Longshot a écrit :

Je crois que la plupart des intervenants ici connaissent très très très bien le cpc

Citer :

ou bien il y a des patterns pré-déterminées présentes avec des octets particuliers qui ne sont présentes que dans les RAMs des vrais CPC, mais pas implémenté dans les émulateurs ?

Sur un 6128, les rams ne sont pas initialisées par les roms en démarrage à froid. Le contenu m'a toujours paru instable et on ne peut donc pas se fier aux valeurs qui peuvent changer entre 2 démarrages. Peut-être que c'est différent sur une extension mais j'ai un doute.
C'est assez simple à vérifier en basic. D'ailleurs avant que tu charges le jeu sur le 464 avec la xmem, peux tu regarder quel est le premier octet que tu trouves différent de 0 à partir de &6000 ?

J'ai déjà fait le test en fait

la ram est remplie de pattern du style 'FFFFFFFF00000000' à la chaine.

TOPIC DUMPS/JEUX PRESERVES AMSTRAD CPC DISK ET CASSETTE

Qui est en ligne ?