Annexe technique · Accueil · English
Affirmations auxquelles on a cru avant de les réfuter, conservées pour ne pas les reprendre. La section A vient de la révision complète du 2026-11-03.
| Affirmation antérieure | Résultat |
|---|---|
| Le gestionnaire INT 0FEh manque ou est externe | C'est maup.exe EA 0x10628
(0x53:0xF8). |
Le segment 0x53 est une API far séparée |
0x53:0 est _main, 0x53:6 est
Game_Main, 0x53:0xF8 le gestionnaire. |
maup.exe utilise des overlays |
Aucune trace d'overlay ; 24 segments relogés ordinaires. |
Le texte est à chasse fixe et +0x66 inutilisé |
Vid_DrawGlyph ajoute +0x66 ; le décalage
+0x6A est temporaire. |
| L'atlas se lit en petit-boutien dans le fichier | Faux pour les décalages impairs : 47 glyphes sur 99. |
| Table indice-caractère inconnue | Résolu ; voir Texte et polices. |
| Les dialogues ne sont dans aucun fichier | Ils sont dans G3.CON enregistrements
0x28/0x29, compactés sur 5 bits. |
La sortie est en blocs de 0x400 avec
resynchronisation |
Le compteur ne fait qu'augmenter ; aucun effet sur le décodage. |
rec27_sub02 est un jeu de caractères de 4 112 o une
fois décodé |
C'est une image brute ; son premier u32 contient des octets de palette et de nombre. |
Font_LoadStrings charge des chaînes |
Il décode une image pour le script d'introduction. |
Les enregistrements .CON sont de la géométrie
vectorielle, sans texte |
Beaucoup sont des images en tuiles ; les enregistrements
0x28/0x29 sont du texte. |
wVidCanvas* est la cible du dessin |
Il est lu comme source de copie ; le dessin va dans
wPageSeg. |
ES écrit et DS lit le canevas |
C'est l'inverse pour les copies : ES:DI est la
source. |
bGlyphDirectStore == 1 signifie écriture directe |
1 choisit Vid_PutPixel. |
word_1A4F4 est l'origine du texte ;
wGlyphRowPitch est le pas |
Les deux contiennent la couleur du texte. |
Vid_BlitTile : CH lignes, CL
tuiles |
CH est la largeur, CL la hauteur. |
sub_10536 est un balayage de paragraphes |
C'est un test de port Sound Blaster. |
| Table des sites INT 0FEh | Quatre EA sur six étaient faux ; les six valent décalage de fichier
+ 0xF800. |
| Six numéros de services | Six sites, cinq services. |
| L'emplacement d'archive vient de la table des disques | Il vient de wConRecordToArchive. |
L'ouverture utilise 3D00h |
3D80h. |
| La liste de sentinelles compte 20 enregistrements | Six groupes, avec les enregistrements de chaque archive. |
| Neuf fichiers seulement ; rien ne manque | D'autres noms existent, dont G7.CON sous
condition. |
| La substitution s'applique quand le drapeau est positionné | Elle s'applique quand bSoundCard vaut 0. |
0x15/0x16 renvoient tous deux à 0x17 |
0x15→0x17, 0x16→0x14. |
INSERT DISK appartient à maup.exe |
Seul INSTALLE.EXE contient cette chaîne. |
INSTALLE.EXE fait 37 376 o |
12 684 o. |
Les 4 derniers Kio de maup.exe sont à zéro |
Seuls 1 458 le sont ; il y a aussi une signature de 29 octets. |
HNF.HUF dit lanxhor, HEY |
lankhor, URL ; le ROT-13 avait été mal
appliqué. |
La fin de HNF.HUF est identique octet par octet à
SND.HUF |
Le suffixe commun ne fait que 216 o. |
| Le code Turbo C ici n'utilise pas BP | Le classique push bp / mov bp,sp est courant : 160
occurrences brutes. |
0 bloc sur 312 passe try_decompress |
Deux blocs .CON passent, et tous les flux
.HUF se décodent. |
unk_1CBE8 |
Le décalage publié DS:27CB est EA
0x1CBEB. |
| Delphine Software ou Loriciels l'ont créé | Lankhor : les crédits de l'introduction le disent. |
sub_12722 est la tâche de fond, appelée depuis
0x1EFEB |
C'est Game_LoadAssets, appelé une fois depuis
0x1F1EB. 0x1EFEB ne contient aucun appel. |
SAUP.MAU est un bloc de sauvegarde, hors sujet |
C'est l'état de départ du jeu, chargé dans le bloc en
DS:166. |
| Le sous-enr. 0 des lieux a un format inconnu | Des palettes, puis une image normale en +0x40. |
MAUPITI1 ne fait que servir ou attendre en
résident |
Il contient la boucle de jeu, reprise par maup.exe en
0x1EF4D. |
MAUPITI1 « moteur d'enregistrements et d'arènes » avec
un rôle résident à part |
Il charge les enregistrements par les services ;
maup.exe s'occupe des fichiers. |
| Affirmation | Preuve |
|---|---|
Les conteneurs .HUF ne sont pas en ROT-13 |
Ils se décodent depuis les octets bruts. |
| Il n'existe pas de table de Huffman statique | L'arbre est adaptatif. |
| Le jeu n'affiche pas de texte par INT 10h | Les routines de caractères servent au chemin adaptateur et ligne de commande (non vérifié en entier). |
Vid_ArenaAlloc n'est pas une routine d'erreur
fatale |
Vérifié. |
0x7D00 est un nombre de mots pour une copie de page de
64 000 o |
Vérifié en 0x16FBF. |
Con_ResolveDestPtr EA 0x11C48 et
sub_13C80 sont des codes distincts |
Vérifié comme cibles d'appel distinctes. |
Ces tests mesuraient quelque chose de réel, mais n'appuient pas leurs anciennes conclusions :
.CON : les pixels sont codés en quartets et
par plages, selon de nombreux ordres de balayage.MAUPITI1 ne contient pas de texte », tiré d'un relevé
de l'ASCII imprimable : le texte du jeu n'est pas en ASCII, ce relevé ne
peut donc pas le montrer. Le texte est dans G3.CON ; que
MAUPITI1 contienne aussi des chaînes compactées n'a pas été
testé.MAUPITI1.EXESe décompresse depuis .olz en une image identique ; le
gestionnaire INT 0FEh n'y est pas ; 51 stubs ; 21 sites
INT 21h ; un iret ; aucun in,
out, INT 10h, INT 33h ; deux
rep movsb dans le runtime ; 7 suites imprimables ; les
fausses occurrences CD FE sont des déplacements ;
0x1335A empile la constante 83, sans rapport avec le
segment 0x53. Le nombre d'instructions varie selon l'outil
(IDA 29 083 ou 29 099 ; un balayage linéaire donne 29 145). Les noms de
runtime d'IDA, comme @Assign, n'ont pas été relus, mais le
code derrière n'a aucun appelant far.
Conclusions tirées de captures mémoire absentes de ce dépôt :
D-1F11.BIN, S8C76.BIN,
S7832.BIN.
Précédent : Noms · Suivant : Questions ouvertes · Annexe technique · Accueil