Кратко: при включении питания, с "GAME DISK A" считывается много информации (ДОС, все файлы и напрямую с треков 25-29 еще).
Потом загрузчик клянчит "GAME DISK B". С него считывается еще некоторое кол-во информации и стартует игра.
В процессе игры "GAME DISK B" должен оставаться в приводе - к нему будут постоянные обращения.
Каждый экран требует подзагрузки: один сектор - графическое описание комнаты и еще два сектора - спрайт персонажа (если он есть в этой комнате).
При переходе в зазеркалье, игра клянчит на "секундочку" дать ей "GAME DISK A" и вернуть "GAME DISK B", тоже самое при возвращении в страну чудес.
Это происходит потому-что в игре имеются два текстовых блока (tr25-29 и tr30-34), оба находятся на "GAME DISK A" и по очереди падают на одно и тоже место в ОЗУ. За всю игру таких переходов требуется только два.
Информацию которую удалось накопать на данный момент - весьма прозрачна и оставляет много вопросов.
Игра требует наличие Language Card (+16Кб), и реально использует все 64кб.
Вот конкретный кусок кода, именно кода алисы, который мутит с управлением Language Card:
Memset1:
5599 - AD 08 C0 "-.@" LDA C008
559C - AD 8B C0 "-.@" LDA C08B
559F - AD 8B C0 "-.@" LDA C08B
55A2 - 60 .. .. "ю" RTS
MemSet2:
55A3 - AD 08 C0 "-.@" LDA C008
55A6 - AD 83 C0 "-.@" LDA C083
55A9 - AD 83 C0 "-.@" LDA C083
55AC - 60 .. .. "ю" RTS
MemSet3:
55AD - AD 08 C0 "-.@" LDA C008 <==
55B0 - AD 82 C0 "-.@" LDA C082
55B3 - 60 .. .. "ю" RTS
c008 - адрес мне не знакомый, возможно, на каких-то моделях эпла актуален,
а вот c08x - это однозначное управление Language Card, игра щёлкает его по ходу игры, возможно,
что-то использует из ПЗУшного кода.
Похоже, что архив фраз хрантся в Language Card, но что-то она хочет взять из ПЗУ, поэтому щёлкает банками.
Например только стоит подойти к кролику (первому же встретившемуся персонажу) и началось щелканье...
==========================
Загрузка:
Вставляем первый диск и включаем питание.
Загружается ДОС с первых дорожек диска на 9800-bfff.
hello - как и любой бейсиковский файл, в адреса от 800. она мелкая, так что 800..900
windham - картинка, грузится сразу в видеоозу 400-7ff
game - 4000..8730
Потом с треков 25-29 (текстовый блок) читает информацию в ОЗУ (заливает в сегмент один (memset1))
она читает его в 200, а потом каждый сектор по отдельности раскидывает по памяти,
адреса сидят где-то во внутренней таблице.
Не удивлюсь, если это работает очень медленно на реальной технике. Натурально тасует.
Сектор читает, потом закидывает. Ещё читает - снова закидывает.
Зачем так - не понятно, но после кодированного текста уже нечему удивляться.
сперва по адресам от Dxxx до DExx
потом с 91xx..b5xx (это она dos сносит, но после b6xx идёт драйвер дисковода досовский - его она не трогает)
потом возвращется на exxx..ffxx
9100 - меню (start game)...
в 96xx лежат общие фразы из рекламы, до начала игры. "Бегай, прыгай" и т.д.
Дальше клянчит второй диск......
==========================
Второй диск:
Там чётко видно несколько фаз чтения, но прямое чтение почти не встречается.
В каждой фазе какие-то свои действия, судя по всему часть данных то ли закодированы, то ли заархивированы.
Т.е. нельзя сказать - вот этот сектор прочитался туда-то.
Ну, типа, читается сектор сперва в 0200, следующий в 0c00. А потом ещё одна пара также точно.
Но они же не просто так читаются, там какая-то процедура , которая вытаскивает эти данные, делает какие-то
битовые перестановки и сохраняет в другом месте.
И это уже разбор вручную получается.
------- Фаза 1 -------
Что-то копируется 0200 -> 0c00, 1 блок
Вероятно, что-то прочитанное ещё с первого диска
читаются как есть
3/9 - 0800
И теперь обратно: 0c00 -> 0200
Такое ощущение, что это некий каталог диска.
------ Фаза 2 -------
Читает от 3/$d группами по три сектора с каждого трека.
3/$d 3/$e 3/$f 4/$d 4/$e .................... 11/$f
Заполняет регион $0D00 .. $1Bxx, при этом выполняя какое-то преобразование, вроде бы два байта в один.
Преобразование выполняется на каждый второй прочитанный сектор
(т.е. два сектора читаются, затем преобразуются в один блок, затем ещё 2...).
После чтения и преобразования копирует 5 блоков с $0d00 на $1b00.
------ Фаза 3 -------
переключила банк в нулевой (memset2)
Читает 19/0..19/A -> D000
Здесь декодирование делается перестановкой бит в байтах в обратном порядке.
Затем на него накладывается ещё какой-то дикий алгоритм, который тасует какие-то биты в соседних байтах,
причем он берет данные из D000..D800, микширует с DA80 и там сохраняет результат.
------ Фаза 4 -------
Читает от 33/8 .. один сектор ?
После чтения сразу появляется заставка (она уже где-то ждёт)
Эту же фазу вызывают после заставки во время смены экранов
------ Фаза 5 -------
Читает ещё раз 3/9 (повторяется вызов фазы 1)
но это не прямой повтор, там какие-то ещё действия выполняются (не с диском).
======================================
Если с первым диском всё более или менее ясно, то на втором диске логика расположения и чтения данных просто дикая.
1) Возможно это всё затеяно ради сложности проги, видны отдельные процедуры перетасовки бит и байт, причем в разных фазах чтения они разные. И это уже явно какое-никакое шифрование. Так что автор, конечно, прятал ресурсы.
Не удивлюсь, если сам порядок чтения задан не в проге, а как бы очередной сектор содержит какую-то ссылку на следующий
ну и/или содержит адрес, в которую он будет загружен. Может вообще свою файловую микросистему?
2) Возможно также, что последовательность данных (описание игровых комнат) на диске, соответствует расположению комнат на карте игрового пространства. Ведь каждый новый экран требует обращения к диску, и желательно чтоб головка дисковода была где-то рядом с ожидаемым участком.
3) И еще одно, уже совсем фантастическое, предположение есть. Ведь игра вышла не только на apple][, но и на Сommodore64 (тоже 6502 и тоже две стороны FM диска по 170Кб). Может быть изначально был какой-то общий "стержень" адаптированный на различные системы. В таком случае всякие нелогичные моменты могут запросто быть.