Итак, подсовываем кодовый блок в TRD к хрусту. Можно вручную, из бейсика, так надежней и наглядней. Но можно и проще, например Total Commander с zx-плагинами, в нём можно из TAP в TRD копировать и обратно, вот только при таком копировании
обнуляется стартовый адрес, т.е. адрес первого байта блока, а значит в хрусте в графе "Depack-to" придется указывать нужный адрес.
File address - это адрес начиная с которого будет начинаться
сжатый блок, этот адрес желательно ставить повыше! Но так, чтобы сжатый блок всё-таки умещался до 65367, иначе otla заругается, и будет делать доп.файл, а если при этом у нас адрес депакера в буфере принтера (
по умолчанию в хрусте), то будет жопа. Как зараннее высчитать? Можно на глаз, но можно сделать пробную паковку, посмотреть какой длины блок получится и на калькуляторе отнять эту длину от 65367. В моем примере сделано на глаз. Почему адрес не 40000, а 40002? Да потому что я вставлю 2 байта перед блоком, эти два байта дадут черный бордюр.
Jump to - сюда вводим адрес так называемой точки входа, т.е. адрес запуска игры. После распаковки сам депакер сделает как бы RANDOMIZE USR xxxxx.
У меня был исходный блок с такими параметрами: 26496,28755
Я его сжал хрустом, получился файл: 40002,17326
Я этот "zip" гружу в память. Бейсиком (
как в примере) или проще дебагером (
ctrl+enter в спекуляторе) заношу в ячейку 40000 число 211, в 40001 - 254, потом сохраняю этот блок (
как TAP) с параметрами 40000,1732
8 (так как блок стал длиннее на 2 байта, которые мы прилепили "спереди"):
В otla, в главном экране, надо будет выставить CLEAR 2649
5, а USR 40000.
Два байта, дающие черный бордер я вставляю и перед сжатой картинкой, но это можно и не делать.
[свернуть]
Сообщение от JeRrS
Ответить с цитированием