Μετατροπή παιχνιδιών για το GX4000 - Οδηγός/FAQ

Γεια σας παιδιά. Με το ενδιαφέρον που υπάρχει για τη μετατροπή παιχνιδιών δίσκου σε κασέτα gx4000, σκέφτηκα να συγκεντρώσω έναν σύντομο (λοιπόν, στο μυαλό μου ξεκίνησε ως σύντομος) οδηγό/FAQ, εξηγώντας λεπτομερώς τις μεθόδους που χρησιμοποιώ. Και μια αποποίηση ευθύνης: ασχολούμαι με αυτό μόνο μικρό χρονικό διάστημα και μαθαίνω στην πορεία, οπότε παρακαλώ μην παίρνετε οτιδήποτε λέω ως θέσφατο, δεν είμαι σε καμία περίπτωση ειδικός στο υλικό του Amstrad. Ωστόσο, απολαμβάνω πάρα πολύ να μαθαίνω για αυτό το παλιό μηχάνημα και να προκαλώ τον εαυτό μου· μπορεί να γίνει ένα πολύ ικανοποιητικό και εθιστικό χόμπι.

Όταν αποφάσισα να κάνω την πρώτη μου προσπάθεια, διάβασα το πολύ καλό άρθρο του CPC fanzine εδώ: https://www.cpcwiki.eu/imgs/6/6f/CPC_Fanzine_-_GX4000_conversion.pdf

Αυτό το άρθρο έχει πολλές πολύ χρήσιμες πληροφορίες που με βοήθησαν να ξεκινήσω, και ήμουν πολύ τυχερός που το πρώτο παιχνίδι που επέλεξα να μετατρέψω, το Dynamite Dan, ήταν κατάλληλο για μετατροπή με τις μεθόδους που περιγράφονται. Δυστυχώς, υπάρχουν μερικές περιπτώσεις που το άρθρο δεν αναφέρει, και μάλιστα η πλειονότητα των παιχνιδιών που έχω μετατρέψει έκτοτε δεν θα μπορούσαν να μετατραπούν με τις μεθόδους αυτού του άρθρου.

Το άρθρο περιγράφει τη χρήση ενός hex editor για την αλλαγή ενός αρχείου δίσκου απευθείας, ώστε να γίνουν αλλαγές σε επίπεδο byte στον κώδικα του παιχνιδιού. Αυτό λειτουργεί μόνο σε περιπτώσεις όπου το πρόγραμμα δεν είναι ούτε συμπιεσμένο ούτε κρυπτογραφημένο. Για την πλειονότητα των παιχνιδιών που θα προσπαθήσετε να μετατρέψετε, το αρχείο δίσκου με το οποίο θα ξεκινήσετε θα είναι «σπασμένο» (cracked), και στους crackers αρέσει πολύ να κρυπτογραφούν και (ειδικά) να συμπιέζουν τις δουλειές τους. Παρόλο που με πρωτόγονες μορφές κρυπτογράφησης (συχνά χρησιμοποιώντας απλούς αλγόριθμους xor) μπορείτε να δουλέψετε αντίστροφα για να βρείτε ποια πρέπει να είναι τα bytes στον δίσκο (το έκανα αυτό με το Shogun), είναι πολύ επίπονο και απαιτεί έντονη συγκέντρωση και κρατημένες σημειώσεις. Δεν είναι μια διαδρομή που θα συνιστούσα.

Γιατί πρέπει συχνά να ξεκινάτε με μια cracked έκδοση αντί για την εμπορική; Σε πολλές περιπτώσεις, τα παιχνίδια δίσκου φορτώνουν δεδομένα από τον δίσκο σε κάποιο σημείο — ακόμα κι αν πρόκειται απλώς για μια οθόνη φόρτωσης. Πολλά μεγαλύτερα παιχνίδια φορτώνουν κάθε πίστα ξεχωριστά. Συχνά, τα εμπορικά παιχνίδια αποκτούσαν πρόσβαση στον ελεγκτή δισκέτας (FDC) απευθείας και όχι μέσω της AMSDOS ROM. Μόλις ένα παιχνίδι το κάνει αυτό, δεν μπορεί να μετατραπεί με το nocart, επομένως δεν θα τρέξει στο gx4000. Οι crackers συχνά έπαιρναν εμπορικά παιχνίδια και αντικαθιστούσαν την άμεση πρόσβαση στη δισκέτα με κλήσεις στο firmware της AMSDOS, καθώς αυτό επέτρεπε την παράκαμψη της προστασίας αντιγραφής κ.λπ. Έτσι, οι cracked εκδόσεις συχνά θα λειτουργούν με το nocart ως έχουν.

Υπάρχουν δύο αξιόπιστοι τρόποι για να ελέγξετε αν το αρχείο .dsk που έχετε χρησιμοποιεί το firmware ή όχι. Πρώτον, φορτώστε το στο Winape και μεταβείτε στο μενού «edit disk». Κάντε κλικ στο «show system files». Αν δείτε πολλαπλά αρχεία, υπάρχουν μεγάλες πιθανότητες να λειτουργήσει με το nocart ως έχει, καθώς χρησιμοποιεί τυπικά αρχεία AMSDOS με τυπικές επικεφαλίδες. Για να το επιβεβαιώσετε, μπορείτε να τρέξετε το παιχνίδι στο winape και να ορίσετε ένα breakpoint στον FDC (floppy disk controller) μέσω Debug → Breakpoints → Input/Output → Add → FDC Data. Όταν ο debugger σταματήσει όταν το παιχνίδι προσπαθήσει να φορτώσει δεδομένα, ρίξτε μια ματιά στο κάτω μέρος του debugger και δείτε αν είναι επιλεγμένο το πλαίσιο ελέγχου για το «Upper ROM». Αν είναι, αυτό είναι καλό γιατί σημαίνει ότι χρησιμοποιείται η AMSDOS.

Θα πρέπει να αναφέρω ότι δεν έχω δοκιμάσει κάθε εξομοιωτή που υπάρχει εκεί έξω, αλλά από αυτούς που έχω δοκιμάσει, το Winape είναι μακράν το καλύτερο για οποιοδήποτε είδος προγραμματιστικής εργασίας, παρόλο που έχει μερικά μικρά κολλήματα που θα ήθελα να αλλάξω.

Έτσι, μετέτρεψα μερικά παιχνίδια χρησιμοποιώντας τη χειροκίνητη μέθοδο επεξεργασίας αρχείων .dsk (χρησιμοποιώντας έναν hex editor, το HxD), αλλά το βρήκα απογοητευτικό καθώς ήταν πολύ δύσκολο να παρακολουθώ τις αλλαγές που γίνονταν, και αν κάνεις λάθος σε ένα byte θα μπορούσες να βρεθείς ξανά στην αφετηρία ή σε μια άγνωστη κατάσταση. Ως προγραμματιστής στο επάγγελμα, έχω συνηθίσει να χρησιμοποιώ συστήματα ελέγχου έκδοσης κώδικα όπως το git, ώστε να μπορώ να χωρίζω όλες τις αλλαγές μου σε μικρά commits και να μπορώ πάντα να βλέπω ένα ιστορικό με σημειώσεις για το τι έχω κάνει.

Έτσι, με το επόμενο παιχνίδι που μετέτρεψα, αποφάσισα να πειραματιστώ με μια εναλλακτική μέθοδο η οποία αποδείχθηκε επιτυχής, και αυτή είναι η μέθοδος που χρησιμοποιώ με κάθε παιχνίδι που έχω μετατρέψει έκτοτε.

Ξεκινώ με ένα κενό project στο CPCTelera. Ίσως είστε εξοικειωμένοι με αυτό το εξαιρετικό εργαλείο, είναι ένας μεταγλωττιστής C (c compiler) για τον amstrad που δημιουργεί ένα αρχείο .dsk. Υπάρχουν πολλά έγγραφα οδηγιών αν το αναζητήσετε στο Google.

Υπάρχουν δύο δυνατότητες τώρα με οποιοδήποτε παιχνίδι: είναι τα αρχεία συμπιεσμένα ή όχι. Για να το μάθετε, τρέξτε το παιχνίδι (το πραγματικό παιχνίδι όπου παίζετε) και παύστε την εκτέλεσή του οπουδήποτε με το F7. Στον debugger θα δείτε την τρέχουσα διεύθυνση εντολής (PC) με τα bytes του opcode στα δεξιά. Ανοίξτε το αρχείο .dsk σε έναν hex editor και αναζητήστε τη χούφτα των bytes ξεκινώντας από εκεί που κάνατε παύση. Αν τα βρείτε στο αρχείο .dsk και όλα ταιριάζουν, τέλεια, τα δυαδικά αρχεία (binaries) πιθανότατα δεν είναι συμπιεσμένα και μπορείτε να προσπεράσετε το επόμενο κομμάτι.

Αν είναι συμπιεσμένα, είναι λίγο πιο δύσκολο, καθώς πρέπει να εντοπίσετε το ακριβές σημείο όπου η αποσυμπίεση ολοκληρώνεται και το παιχνίδι ξεκινά. Ο ευκολότερος τρόπος για να το κάνετε αυτό είναι να τρέξετε το παιχνίδι (π.χ. run "disc) και να ορίσετε εκ των προτέρων ένα breakpoint στο WinAPE στην πραγματική διεύθυνση έναρξης. Μπορείτε να το βρείτε αυτό στον disc editor, κάνοντας δεξί κλικ σε ένα αρχείο, επιλέγοντας «Properties» και κοιτάζοντας το Exec Address.

Τώρα θα μιλήσω για τη χρήση AI για τον σχολιασμό και τη σημείωση της αποσυναρμολόγησης (disassembly), που είναι το πιο χρήσιμο εργαλείο στη γκάμα μας. Το να γίνει αυτό με το χέρι είναι δυνατό, αλλά είναι μια τεράστια, χρονοβόρα και απογοητευτική εργασία — όχι πραγματικά βιώσιμη αν έχετε δουλειά, οικογένεια ή άλλα χόμπι. Έτσι, μόλις σταματήσετε κάπου στην αρχή ή μέσα στη ρουτίνα αποσυμπίεσης, περιηγηθείτε στον debugger, συνήθως προς τα εμπρός στη μνήμη και συνεχίστε για περίπου 0x1000 bytes. Γενικά μέχρι να δείτε ένα «RET», αλλά η διεύθυνση τέλους δεν είναι καθοριστική καθώς μπορείτε να πάρετε περισσότερα αργότερα. Κάντε Shift-κλικ για να επιλέξετε αυτό το μπλοκ εντολών, μετά δεξί κλικ και «Disassemble». Απλώς πατήστε OK στο παράθυρο διαλόγου. Πατήστε F3 για να εμφανιστεί ο assembler αν δεν εμφανίστηκε αυτόματα. Τώρα έχετε τον πηγαίο κώδικα, αλλά σε μια πολύ ακατέργαστη μορφή, η οποία είναι ουσιαστικά άχρηστη χωρίς να χωριστεί σε ρουτίνες και να σχολιαστεί διεξοδικά.

Μόλις έχετε τον ακατέργαστο κώδικα assembly από το WinApe, αντιγράψτε και επικολλούμε τον σε ένα νέο αρχείο στο project σας (ξεκινήστε έναν νέο φάκελο/project στο git για κάθε παιχνίδι που μετατρέπετε). Χρησιμοποιώ μια ονοματολογία όπως “GameZ0x1000-0x2000.raw.asm”. Στη συνέχεια, χρησιμοποιήστε ένα εργαλείο AI με μια συγκεκριμένη εντολή (prompt) για να το μετατρέψετε σε κάτι αναγνώσιμο. Δεν χρειάζεται να πληρώσετε χρήματα για εργαλεία AI! Τα δωρεάν είναι απολύτως επαρκή. Αυτά που χρησιμοποιώ είναι το Opencode και το Freebuff, και τα δύο παρέχουν μια ποικιλία μοντέλων που μπορείτε να χρησιμοποιήσετε εντελώς δωρεάν. Είναι εξαιρετικά εύκολα στη ρύθμιση και τη χρήση. Επιλέξτε το πιο ισχυρό διαθέσιμο μοντέλο στη μέγιστη ρύθμισή του (ρωτήστε το AI αν δεν είστε σίγουροι ποιο είναι το καλύτερο). Θα συμπεριλάβω την εντολή που χρησιμοποιώ παρακάτω, μπορείτε να τη βάλετε σε ένα αρχείο και είτε να κάνετε αντιγραφή/επικόλληση είτε να υποδείξετε στο εργαλείο AI αυτό και το αρχείο .asm:

“For the z80 code block at (your file path), designed to run on the Amstrad CPC, add inline comments showing high-level functions and separate into subroutines, with a header for each major/minor subroutine describing its purpose. Alter any labels to be more descriptive, but retain the address at the end of the label. At the top of the file add a summary comment with a bullet point list of the major functions contained within. Output the commented disassembly as a single block without dropping any instructions or data into a new file beside the existing. Try to identify any areas that are actually data and not code where possible. Refer to the firmware manual here if necessary for ROM calls etc: https://www.cantrell.org.uk/david/tech/cpc/cpc-firmware/firmware.pdf”

Μόλις το AI κάνει τη δουλειά του, θα έχετε κάτι ελπίζω αναγνώσιμο που μπορείτε να αναλύσετε. Αν έχει κάνει κακή δουλειά ή οι ρουτίνες δεν φαίνονται σχετικές με την αποσυμπίεση και την εκκίνηση του παιχνιδιού, απλώς πάρτε ένα άλλο τμήμα της μνήμης και επαναλάβετε, ή δοκιμάστε ένα άλλο εναλλακτικό μοντέλο AI.

Ελπίζουμε ότι θα δείτε κάτι όπως αποσυμπίεση δεδομένων και μετά JP 0xXXXX για την πραγματική εκκίνηση του παιχνιδιού (ή της οθόνης τίτλου του). Στην εμπειρία μου υπάρχει σχεδόν πάντα μια εντολή JP XXXXX που είναι το σημείο εισόδου σε αυτό που θα υπήρχε στο εμπορικό παιχνίδι. Πολύ συχνά είναι ένας στρογγυλός αριθμός όπως 0x100 ή 0x500 καθώς στους προγραμματιστές αρέσει να επιλέγουν στρογγυλούς αριθμούς. Μια άλλη εναλλακτική για την εύρεση του σημείου εισόδου είναι να τρέξετε την πραγματική εμπορική έκδοση και να δείτε από πού εκκινεί πραγματικά εξετάζοντας τις ιδιότητες του αρχείου δίσκου.

Μόλις έχετε το σημείο εισόδου του παιχνιδιού (το οποίο είναι απλό αν δεν έχετε συμπιεσμένη/κρυπτογραφημένη έκδοση), μπορείτε να κάνετε dump τα περιεχόμενα της RAM βάζοντας ένα breakpoint σε αυτή τη διεύθυνση.

OK, αυτό γίνεται πολύ μεγαλύτερο από ό,τι σχεδίαζα, οπότε αν κάποιος ενδιαφέρεται για περισσότερα, ενημερώστε με και θα συνεχίσω να γράφω παρακάτω ή θα το μεταφέρω σε ένα άρθρο στο wiki!

5 «Μου αρέσει»