Index du Forum
IDENTIFICATION SERVEUR : 10.0.97.129 - CLIENT : 54.81.192.192

 FAQFAQ   RechercherRechercher   Liste des MembresListe des Membres   Groupes d'utilisateursGroupes d'utilisateurs   S'enregistrerS'enregistrer 
 ProfilProfil   Se connecter pour vérifier ses messages privésSe connecter pour vérifier ses messages privés   ConnexionConnexion 

Battlefield (SSG, 1986)

 
Poster un nouveau sujet   Répondre au sujet     Index du Forum -> PROTECTION MALEFIQUE
Voir le sujet précédent :: Voir le sujet suivant  
Auteur Message
qkumba



Inscrit le: 29 Jan 2012
Messages: 165

MessagePosté le: Lun 05 Déc 2016, 7:56    Sujet du message: Battlefield (SSG, 1986) Répondre en citant

This game is a war simulation between two sides. You can play different campaigns at different times in history. It has many details that must be set on each round, making it very configurable.

The disk uses a custom address prologue, volume number of 0, 4-and-4 data encoding, and only 10 sectors per track.

The first one is easy - we just change it to the standard prologue.
The third one is easy - we just write the data to only the first 10 sectors of each track.
The second one is the problem. Why? Because the memory usage is $200-ffff, and both banks.
The RWTS is three sectors long, and it supports writing to disk to save the game data.
Can we make a 6-and-2 RWTS with write support in only three sectors? Nooo, but we can get really close...

After many attempts, I fit a complete read/write/seek code in 512 bytes!
Plus another page for data (86 bytes to hold the 2-bit table, 106 bytes for decoding table, 64 bytes for encoding table). There is our three sectors. We are 256 bytes short. :-(

Ah, but we are lucky - $2xx is used as a scratch area to detect which disk is in the drive. We can use it, too.

But that's not all! The game allows to make a backup of itself. It formats the target disk in a protected format using a separate routine that writes an oversized bootsector ($177 instead of $156 nibbles). I spent a long time hunting for the bug in my write routines, never suspecting that it was done on purpose. The big sector is possible because the formatting routine leaves large gaps between the sectors, and the boot PROM does not verify the epilogue bytes. If we use standard gaps in order to fit all 16 sectors, then we have to trim the bootsector, too... but we don't need that option anyway, so I removed it from the menu. :-)

Some disassembly next time.
Revenir en haut de page
Voir le profil de l'utilisateur Envoyer un message privé Visiter le site web de l'utilisateur
toinet
Site Admin


Inscrit le: 15 Juin 2007
Messages: 2803
Localisation: Le Chesnay, France

MessagePosté le: Mar 13 Déc 2016, 18:52    Sujet du message: Répondre en citant

Congratulations, Peter, really!
Revenir en haut de page
Voir le profil de l'utilisateur Envoyer un message privé Visiter le site web de l'utilisateur
Montrer les messages depuis:   
Poster un nouveau sujet   Répondre au sujet     Index du Forum -> PROTECTION MALEFIQUE Toutes les heures sont au format GMT + 1 Heure
Page 1 sur 1

 
Sauter vers:  
Vous ne pouvez pas poster 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 voter dans les sondages de ce forum


Powered by phpBB © 2001, 2005 phpBB Group
Traduction par : phpBB-fr.com