J'ai réussi à prendre la prendre de présentation .Grâce au stockage de winape entre &c000 et &ffff .Le seul truc ,c'est qu'après pour savoir où se trouve le prog principal il faut savoir où il débute ( adresse où sont stockées les données lors de la lecture de la cassette ) , la taille et l'adresse d'execution
Je veux bien un coup de main ..... ( ca me sera instructif )
" page de présentation" pas " prendre de présentation" enfin vous m'aurez compris ....
Bonsoir,
Les softs Alternative ne sont pas franchement plombés. Il suffit de détourner le loader K7 et sauvegarder sur disque et le tour est joué.
Première chose à faire, transférer le premier programme binaire du CDT sur un .DSK. Ca se fait "à l'ancienne" avec un soft de transfert genre Transformateur 3000, Speedmaster ou même le module K7>disc de Discology.
Ensuite, noter les adresses d'implantation et d'exécution du programme transféré, le charger dans Winape puis faire un beau <F7> pour jeter un oeil sur son code.
Suite au prochain épisode, je mange ma soupe, et c'est dur de taper en même temps sur le clavier .
Inscription : 15 Juin 2009, 09:00 Message(s) : 190
Jusque là c'est ok. C'est après que ca se corse , où je trouve d'une manière générale l'adresse d'implantation des données , la longueur du fichier et l'adresse d'execution ( j'imagine que c'est un jp XXXX mais c'est pas forcé .....)
Les CALL #A4D9 servent à définir une palette de couleur. Les CALL #A441 servent à lire un bloc de données depuis la cassette, avec IX en adresse de début et DE en longueur. le JP #0EF7 est le point d'entrée du programme.
Je regarderai plus en détail après, faut que je mange moi aussi
Demoniak nous mâche le travail . Le source est clair comme de l'eau de roche.
Le soft charge trois fichiers monoblocs.
La page écran de 17ko (IX=&C000 DE=&4000, on en déduit IX=implantation et DE=longueur des données)
Le programme principal et des données supplémentaires qui ont le bon goût d'écraser la ram réservée au système.
Ca va donc être un peu plus compliqué que prévu pour récupérer le soft car il utilise à vue de nez toute la ram une fois chargée. Le plus simple est de procéder en récupérant chaque fichier un par un. Après le chargement du fichier, on initialise le système disque (le fameux vecteur &BCCE), et on sauvegarde les données chargées.
Ca ne posera aucun problème pour la page écran. Pour le programme principal, il faudra décaler son adresse d'implantation (en &0040 au lieu de &0000 par exemple) pour ne pas "paumer" la zone de ram &0000-&00040.
Pour la partie secondaire du programme, il faudra aussi modifier son adresse d'implantation (en &0040 ?).
Le plus compliqué au final sera de faire un chargeur disque pour ces fichiers. L'usage d'un compacteur se montrera salvateur pour cela. La difficulté est liée au fait que toute la ram (sauf la plage utilisée par le chargeur K7) doit être "restaurée". La facilité consiste à utiliser de la mémoire étendue, mais on doit normalement pouvoir s'en sortir avec 64ko en utilisant des outils adaptés.
On commence le sérieux.. Dans les fichiers ci-joints, il y a ce qui faut pour transférer l'image de présentation du jeu. Un source d'une routine de sauvegarde sur disquette. Une image .DSK avec mes travaux du samedi matin .
Transfert du loader de Postman Pat. J'ai utilise TRANSCODE, un soft commercial (si si) pas génial, mais ça suffit. Il te donne les adresses utiles du fichier transféré (en décimal hélas).
Tu aurais aussi pu trouver ces informations avec n'importe quel logiciel de gestion de fichiers un tant soit peu ambitieux (Disc'o'Magic par exemple, ou Discology, il y a largement le choix).
Création routine de sauvegarde de la page écran C'est une routine de sauvegarde de la mémoire sur disquette (autre transfert de jeu K7), que j'ai adaptée : le source est SAVER1.ASM. La routine est implantée dans une zone de la mémoire qui n'est pas utilisée/écrasée par le loader. De façon très conventionnelle, j'ai choisi &BE80. La routine est un peu adaptée au loader de Postman Pat (changement de l'emplacement de la pile mémoire, blocage de l'interruption RST &38).
Ensuite, on bricole un petit programme Basic qui fait les opérations suivantes :
1) charger la routine SAVER1.BIN en mémoire 2) charger le loader du jeu sur la cassette 3) détourne le loader cassette juste après le chargement de l'image de présentation 4) sauvegarde la zone mémoire voulue
c'est pas plus compliqué que cela .
Sur ce, douche ! On verra la suite plus tard, je te laisse le temps de digérer tout ça...
T&J/GPA
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Inscription : 15 Juin 2009, 09:00 Message(s) : 190
Pou la page de présentation , j'avais fait simple sauvegarde dans l assemble de winape de la zone &c000 à &ffff
reset de l'emu avant de loader dans l assembleur la zone &c000 à &ffff petite ligne basic cls:call &bb06:j'introduis la morceau de code sous f7:save"ecran",b,&c000,&4000
bon comme vous avez dit le logiciel se paye le luxe vicieux d'écraser la zone &0 jusqu'a &4000
pas gentil ca
donc j'ai dans un premier temps mis un call &bb06 dans le loader après chaque chargement pour avoir en mémoire le code ... Je vais surement couper le prog principal en plusieurs bouts pour , a coup de ldir remettre ca d'equerre .
Inscription : 20 Août 2007, 18:21 Message(s) : 5103
part1 &0000-&A400 part2 &A000-&FFFF , les choses ce corse pour le loader , comment charger autant de donnée sans utiliser les banks , ni les vecteurs system (ils sont écraser par les sprites du jeux)
Attention: j'ai remarquer qu'il rester des données non charger en fin du .cdt
La solution comme le disait Tom&Jerry c'est de compacter les différents fichiers. Je peux m'en occuper, si je trouve un peu de temps avec tout ce que j'ai à faire en ce moment
Inscription : 20 Août 2007, 18:21 Message(s) : 5103
j'ai packer avec exomizer, ca donne 22960 octets pour la partie 1 et 9205 par l'autre ... je suis toujours septique ... En posant les données compacter en haut de la mémoire ,pendant le dé-compactage les données vont ce chevaucher et planter le tout
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
hERMOL a écrit :
j'ai packer avec exomizer, ca donne 22960 octets pour la partie 1 et 9205 par l'autre ... je suis toujours septique ... En posant les données compacter en haut de la mémoire ,pendant le dé-compactage les données vont ce chevaucher et planter le tout
tu as qu'à découper en deux ou plusieurs fichiers compactés !
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 42 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
.
