Pusher

А как в Мониторе и в Васике при записи на мафон идет обращение к триггеру: LDA или STA? И какой адресацией?

Не-не-не-не! Мы уже с Владимиром спорим об этом.
Вот пруфы:
http://forum.6502.org/download/file.php … ;mode=view (отсюда - http://forum.6502.org/viewtopic.php?f=4 … hilit=sta) - здесь прекрасно видно одно обращение (при STA $0D00)
http://www.emuverse.ru/wiki/MOS_Technol … ема_команд
http://www.defence-force.org/computing/ … /annexe_2/
http://www.westerndesigncenter.com/wdc/ … 5c816s.pdf

Абсолютная адресация, 4 такта, что LDA, что STA. Один такт - выборка опкода. Два такта - два байта-операнда - выборка адреса аргумента. Из общих 4 тактов остался один - выборка аргумента.

Каюсь - раньше тикал спикером записью, уже давно тикаю BIT $C030.

Дас ист фантастиш!

Дас ист фантастиш!

Звука нет и на семерке и на девятке (на реале проверялось), ну точнее именно звука раздвигающихся полосок. И вот почему было сделано записью и почему при таком раскладе он пропал и есть вопрос.
Т.е. в обсуждении в аське - мы почему-то пришли к мнению что Роман Бадер много где переделал на запись.
Но вот моя девятке, не смотря на теорию, молчит как партизан когда записью. Или где-то там чего-то шуршит - я сперва подумал что у соседей за стенкой агат :)

Теория с тем что просто приглушить звук хотелось - маловероятна. Ведь у него скорее всего Московская девятка была, а у них тумблер звука на задней стенке.

Ведь вопрос совсем не в пушере или какой-то там еще проге. Хотелось бы понять различаются ли в этом смысле агаты разных исполнений и заводов.

ЧИТД!

Пруф говорит, что "LDA (zp),Y" - 5* тактов: 1 такт - выборка опкода, 1 такт - выборка байта-операнда 0-й страницы, 2 такта - выборка абсолютного адреса из 0-й страницы, 1 такт - выборка аргумента по эффективному адресу (абсолютный + индекс). То есть одно обращение в последнем такте. * - если же индекс пересекает страницу (в эффективном адресе), то добавляется предпоследний такт с невалидным адресом - получаем 2 обращения.

В этом пруфе (стр. 43, 13 метод адресации) сказано, что "STA (zp),Y" - 6 тактов: 1 такт - выборка опкода, 1 такт - выборка байта-операнда 0-й страницы, 2 такта - выборка абсолютного адреса из 0-й страницы, 1 такт - невалидное чтение (потому что запись STA), 1 такт - выборка аргумента по эффективному адресу (абсолютный + индекс). Итого - два обращения в последних двух тактах.

Абсолют уже показывал... При таком обращении к триггеру глюка не должно быть.

PS. Как говорится, одна голова - хорошо, а Змей-Горыныч - лучше! ;)  "Адназначна!!!" (C)

А в новую версию никак нельзя добавить этот звук при раздвижении экрана?

Согласен с avivanov76 - что, в данном случае, даст это изменение игры? Исправить то, что мешает программе нормально работать - необходимость. Добавление звука туда, где его не было - совершенно неоправданное изменение программы. Тем более, как я считаю, это будет не совсем корректно по отношению к автору программы.

Нашёл ошибка в игрухе с чтением файла уровней:
Уровень в файле занимает 1.5 сектора.
У ранних версий игры файл уровней занимал: 80 уровней * 1.5 + 1 пустой сектор в начале файла = 121 сектор, у более поздних 170 уровней * 1.5 + 1 пустой = 256. Должно быть 256, реально 255.

Игруха использует досовский драйвер или btk'шный для доступа к дисководу, но файл ищет и читает сама.
Она его находит в каталоге, затем считывает все его TSL, собирая две таблицы адресов: номера треков всех блоков файла и номера секторов всех блоков файла.

Вероятно, из-за переполнения счётчика, если файл содержит 256 секторов, то игра считает его пустым - не даёт прочитать никакой уровень.

Но секторов 255. Поэтому читаются почти все уровни. Но последний - 170-й уровень попадает на 255й сектор файла и на 256й. 255й читается успешно, но 256-го нет, и игруха пытается читать диск в любом мусорном месте (ячейка таблицы не инициализирована). В эмуляторе это может быть и сектор 0/0 и 255/255 - как повезёт с загрузчиком и с мусором в памяти. Что было на реале - понятно.

Простое лечение: урезать файл на один сектор. В этом случае игрушка правильно понимает, что секторов 168. При этом 169 и 170й просто не пытается читать.

--

Но есть ещё один странный баг: если игрушка всё таки лезет на 255й трек (т.е. на 127 цилиндр) то олеговский эмуль почему-то у меня это схавывает (где-то по полминуты или больше напряженно думая), а у Игоря почему -то виртуальная машина зависает совсем. Если кому не лень - попробуйте у себя: pushernew из первого сообщения, ИГРА -> 170.

У меня версия 1.29.2. При выборе уровня 170 сначала минуту непрерывно идет звук чтения секторов, потом пять минут тишина, но редко редко раздается звук чтения сектора. Потом игра снова предлагает выбрать номер уровня (вроде ничего не ломается). Семерка и девятка ведут себя одинаково.

Ещё докидаю заметки про пушер, раз уж начали его полоскать:

==

В некоторых версиях есть проверка типа операционной системы.
По косвенным признакам проверяет, является ли система ИКП-base или BTK-base.
Быстропускалка ей кажется похожей на BTK, хотя, на самом деле, она больше похожа на DOS3.3.
В зависимости от результата pusher использует разные обращения к RWTS.

If $03E3^ == $A9 && $03E5^ == $A0 && $03E7 == $60 then IKP

В ИКП по этим адресам стоит загрузка адреса таблицы управления RWTS:
03E3 -   A9 05 ..   ")."    LDA   #05
03E5 -   A0 57 ..   " w"    LDY   #57
03E7 -   60 .. ..   "ю"     RTS

Код этой проверки находится где-то в первом секторе игрули,
обычно он вызывается как одна из первых подпрограмм.

Исправленные версии для Быстропускалки:

If $03E3^ == $A9 then IKP (т.е. обращения к RWTS будут через $3E3 и $3D9)
else BTK (обращения к RWTS по правилам BTK)

==

Файл уровней ищется собственным файловым менеджером, он использует две ДОСовких процедуры:
$3E3 и $3D9.

Имя файла уровней ищется в каталоге примерно здесь:

24B2 -   B1 D4 ..   "1T"    LDA   (D4), Y
24B4 -   F0 22 ..   "П."    BEQ   24D8
24B6 -   C9 FF ..   "IЪ"    CMP   #FF
24B8 -   F0 13 ..   "П."    BEQ   24CD
24BA -   A0 03 ..   " ."    LDY   #03
24BC -   A2 00 ..   ""."    LDX   #00
24BE -   B1 D4 ..   "1T"    LDA   (D4), Y
24C0 -   DD 0D 26   "].."   CMP   260D, X
24C3 -   D0 08 ..   "P."    BNE   24CD
24C5 -   E8 .. ..   "Х"     INX   
24C6 -   C8 .. ..   "H"     INY   
24C7 -   C0 21 ..   "@."    CPY   #21
24C9 -   D0 F3 ..   "PС"    BNE   24BE
24CB -   F0 0D ..   "П."    BEQ   24DA
24CD -   A5 D4 ..   "%T"    LDA   D4
24CF -   18 .. ..   "."     CLC   
24D0 -   69 23 ..   "иё"    ADC   #23
24D2 -   85 D4 ..   ".T"    STA   D4
24D4 -   90 DA ..   ".Z"    BCC   24B0
24D6 -   B0 BF ..   "0?"    BCS   2497
24D8 -   18 .. ..   "."     CLC   
24D9 -   60 .. ..   "ю"     RTS   

==

Ещё есть не бадеровский цветной пушер, для режима 128x128.

==

В разных версиях игры рабочие буфера расположены в совершенно разных местах.
При этом они объявлены в исходнике статически. Предполагаю это из того, что,
например, буфера таблицы расположения секторов PUSHER.LEVELS всегда выровнены по краю страницы (XX00).

Игруха категорически не предназначена для запуска под dos33, так как использует кучу памяти в регионе > $9000. В некоторых версиях прямо залезает на $BXXX.

==

Файл уровней - 121 блок (теперь выяснилось, что игруля сама понимает размер файла и он может быть произвольным в некоторых пределах).

Нулевой блок не используется, вероятно. Во всяком случае первые 256 байт.
В них входят первые 4 байта размера и длинны, но т.к. pusher читает файл своими процедурами,
эти байты не относятся к формату.

Уровни нумеруются от 1 до 80.
01й уровень находится в 1 и 2 блоках (пропуская 0-й блок)
80й уровень находится в предпоследнем и последнем блоке.

Чтение уровня происходит в буфер $9400..95FF.

Размер уровня (предположительно) - 32x30 элементов
Описание каждого уровня - $180 байт
Зашифрованы несколькими EOR

Первые $18 байт имеют различное назначение, в остальных закодирована карта уровня, по 3 бита на элемент.

  // нач поз    - buf[$00..$01]                                                                                     
  // контрольки - buf[$02..$03]                                                                                     
  // рекорд     - buf[$04..$08]                                                                                     
  // имя        - buf[$09..$17]                                                                                     

Кому надо - есть исходник на C, который умеет парсить файл уровней (генерирует PNG с картинками всех уровней). Для сборки нужна imlib2.

==

Заметки про сборник Пушер+Клондайк.

Привет от Бадера

Внутри следующие штуки:

- Загрузчик: представляет собой что-то вроде BTK, но с отключенной заставкой. Не знаю, сколько
там от реальной BTK, но по объёму и виду кода - там полноценная операционка, вроде
даже есть системный монитор, но так же и I/O для 140 и 800к дисков, и, похоже, виртуальный
диск.

- Где-то перед чтением VTOC физического диска ищется нечто, которое должно быть расположено
на 17-й дорожке, где-то после 8...9 сектора. Должно представлять собой сбой синхро,
байт $95 и ещё примерно 3 байта. Первая встретившаяся фигня пропускается, вторая
используется в дальнейшем как ключ для расшифровки файлов-игр (см метку LoadSel).

- На оригинале (полученном физическом диске) каталог был убит нахрен. CRC в порядке, но сектора заполнены мусором.
Следствие показало, что всё таки там ожидается именно обычный каталог. В образах
видны три T/S-листа, как раз соответствующие файлам klondike, pusher и pusher.levels.
Возможно, при загрузке будет игнорироваться точка загрузки, указанная внутри файлов,
но это не факт. Причем точка, заданная снаружи, кажется, совпадает с той, что указана
в файлах.

- После расшифровки ищется небольшая сигнатура внутри файлов и управление передаётся
почти на неё (а не на начала образов!). Если сигнатура не найдена до $8000-го адреса
- управление уходит примерно на него, в результате чего имеем BRK/HLT - по вкусу.

- Ошибка чтения файла-игры также не смущает декодер (он просто не проверяет флаг
результата) и дальше всё идёт по прежнему сценарию.

- Один из байт ключа копируется в адрес $200 (== $CA), но пока не обнаружено, чтобы он
где-то использовался. Его контроль происходит в теле игр.
Также могут проверяться $265 (== $A2), $266 (== $19) и $800 (== $0E) - это всё относится к локам.

- Ещё одна ячейка - $3A - там слот с парпортом с навешанной мышью. Если он есть,
например, во втором слоте, в $3A будет $20.

Resume: пока что механизм защиты видится довольно несложным. Сложность была лишь
в огромном объёме уникального кода, на анализ которого ушло почти шесть часов.

===============

В system\binstall есть инсталятор ключа, там же подробный разбор его логики.
Помимо описанных выше фенечек есть ещё ряд других, которые, вероятно, проверяются
уже внутри тел игр.

===============

AK:

Вроде то же самое, но, кажется, другие версии. Защита аналогична или неизвестно чем отличается.

===============

При очередном анализе выявился также следующий косяк:

Процедура "Bload??" (чтение B-файла в память) имеет ряд аргументов,
которые указывают точку загрузки. Точка вычисляет по различным алгоритмам,
выбор алгоритма определяется содержимым ячейки $61 (это вполне стандартное поведение
BTK-подобных систем, на основе которой сделан лоадер). Но Бадер где-то забыл
добавить инициализацию этой ячейки. Там должен быть 0, но в случае некоторого мусора
возможны варианты...

===============

KLONDIKE.FIL - дешифрованный, с инициализацей всех нужных ключей. Возможно, хвост
имело смысл обрезать - получилось бы на сектор короче.

===============

Образы в UnTested/ имеют не совпадающие файлы, но изучения их не проводилось.
Вроде бы ключ защиты фиксирован, но, быть может, существовали другие версии инсталяторов
с другими ключами - тогда и зашифрованные файлы будут отличаться даже при совпадении
кода программ.