Восстановление "Подземелья Черного Замка". (Страница 1 из 3)

НАПРАВО:

Аттач:

im-soft.OK.dsk                  - немного магии, многие файлы могут не читаться, но то что читается - скорее всего верно

im-agat.0.98cor.OK2.dsk         - сильное колдунство, многие файлы читаются, начинать изучение надо с этого диска

im-agat.1.02cor.Eim.dsk.rep.dsk - тут тоже многое читается, но некоторые файлы немного отличаются и, вероятно, эти отличия -- скорее ошибка.
im-agat.Eim.dsk.rep.dsk
Эти файлы нужно использовать, если с дисков OK файл прочитался, но там что-то похоже на ошибку или мусор.
Возможно, что с *rep* прочитается как раз правильно.

==

На всех дисках есть логическая ошибка:
Файлы "A" и "TEXT.ГИГАНТСКИЙПАОК" наложились по пространству ФС, так что какой -то точно повреждён.
А какой-то может и нет.

==

Не забываем, что dos33c2 может по нажатию:
- Shift-C - сравнить файлы под курсором на правой и левой панели.
- C - сравнить посекторно образы между правой и левой панелями.
- Ctrl-C - сравнить ВСЕ файлы побайтно между двумя панелями. И отметить те, которые различаются.

==

И ещё обрати внимание на аттач gp20..
Там тоже может найтись что-то стоящее.

v25:
Диск нестабильно читался, в финале получилось 5 копий с незначительными отличиями в некоторых секторах.
Кой что так и не удалось вытащить.
Копии равновероятны по части глюков, если файл на одной копии битый, на другой может быть не битым. Битый побайтно, а не посекторно!

На файловой системе есть ошибки !
Файлы s/SY и WZ пересекаются.
Так что не рекомендуется что-то записывать на него.

Вау! Супер! Начинаю операции сравнения

Вопрос по сравнению - если визуально 2 версии одного файла одинаковые (для бейсик это определяется достаточно просто на глаз, плюс можно сделать экспорт в текстовый вид и сравнить текст более мощными инструментами), но по Shift-C сравнению есть отличия которые за границей файла (по отчету dos33core2 - первый свободный файл по смещению NNNN)
И
у разных версий одного файла размер "неизвестной площади" разный - напр в конкретном случае это 3 байта (вычитка лучше) или $01BB байт (пре-вычитка),
беспокоиться не надо?
-----
Предварительные результаты хорошие - файлов стало больше, с 92 кол-во выросло до ~110. Для ранней версии обнаружились подверсии файлов с небольшими логическими отличиями в программе - помечаю их припиской к имени "OLDER.FIL" и сохраняю бок о бок с другими версиями. Более новые версии имеют тенденцию к большему кол-ву дисковых ошибок, но имея разные версии можно будет попытаться восстановить недостающие фрагменты (именно это помогло с Внешней Зоной восстановиться из микса разных версий).
-----
Часть файлов (по ошибке?) сохранены как тип T. При побайтовом сравнении с тип-A версиями отличий ноль.
Но заметил особенность dos33core2 интерфейса: при сравнении T с A по [Shift-C] переходит с побайтового на построчное сравнение... приходится выбирать из F9 меню побайтовое сравнение...
-----
На диске v20 открылись новые секторы каталога (начинаю вспоминать, что место в каталоге под описание файлов добавляется по требованию - в итоге каталог может быть раздроблен) - и всплыли разные версии файла "Направо", и что самое важное, заметил файл "ASM.НАПРАВО", в котором происходила интересная ассимиляция и начало моего переходного периода между бейсиком и ассемблером :) Самые первые шаги перевода массивов игры на ассемблер - изменен первый десяток строк, вся остальная часть - нетронутый бейсик (последней версии) и без дисковых ошибок (что еще важнее)!

Звучит здорово. Но способ экспортировать через dos33core2 в text с перекодировкой, а потом импортировать обратно в A файл - так сработает? Если да - то тоже обрежутся все бейсиковские хвосты в виде неиспользуемых переменных.

И кстати, самая прелесть текстовой RPG на бейсике - возможность с минимальными усилиями портировать на PC, просто сделав [автоматическую] минимальную правку синтаксиса. Я не разбираюсь в бейсиках, есть какой-то не умерший еще под Win, не такой монстроподобный как Visual Basic от MS? :)
----
Двигаюсь согласно рекомендации, после OK, "OK2 с сильным колдунством" неплохо так сократил кол-во сбойных файлов, при этом при посекторном сравнении ничего негативного не добавляется в "здоровых" секторах.
----
Выяснилось, что "ГИГАНТСКИЙ ПАУК.А", а также его вариация "ГИГАНТСКИЙПАОК.А" тоже имеют в своем составе полный комплект кода для запуска (аналогично "НАПРАВО.А") - я это делал для тестирования - в этой локации есть и бой с монстром, и лут, и артефакт для расширения лута (заплечный мешок повышенной вместимостии). Файл должен быть самодостаточным для запуска. Но я пока с бейсиками еще не тестировал.

Такое поведение, если под курсором в текущей панели - T файл. Но построчное сравнение T с А файлом (в другой панели) в режиме по умолчанию - бесмысленно. Правильнее такое сравнение по умолчанию давать только если обе панели указывают на T файл.

ура. im-agat.1.02cor.Eim.dsk.rep.dsk помог прочесть оставшийся сбойный сектор в ключевом "TEXT.НАПРАВО.А" и этот восстановленный сектор выглядит нормально (с точки зрения бейсика и логики программы).

Итого, единственный файл из относящихся к нетестовым с диска v20 (метка у диска "ЧЕРНЫЙ ЗАМОК ПН 07 08 95" - хотя это ничего не значит, я мог на диск с новой датой забэкапить старые файлы) - "ПОСЛЕ РАЗБОЙНИКОВ.A" (и на других дисках его нет).
im-agat.0.98cor.OK2.dsk забил 1 сектор как "CLEAR CLEAR CLEAR ...". rep вычитки возвращают на этот сектор ошибку "загрузка файла: t/s список: сектор 145/9 не читается". Ручная правка TSL поможет?
Ну и возможно этот файл есть в T виде на оставшихся двух дисках с ЧЗ поздней версии - еще не дошел до них.
------------------------------
В аттаче - последняя коллекция файлов ранней версии ЧЗ, теоретически годная для полноценного игрового процесса.
106 .А файлов комплектных (не факт что это полный список но файлы находящиеся недалеко от стартовой локации вроде на месте) - запускаться должно через TEXT.НАПРАВО.A и отдельно через TEXT.ГИГАНТСКИЙ ПАУК.А.
В директории BAD - три невосстановленных файла (ошибки чтения остаются). 2 файла непринципиальных, из комплекта только один - "TEXT.ПОСЛЕ РАЗБОЙНИКОВ.A".
В директории OLDER - нормально считанные, но более старые (другие) версии комплектных файлов.
В директории MISC - всякий хлам. тестовые файлы и файлы, где я в те годы пытался псевдокод "переделать" в простой текст, чтобы дальше модифицировать под ассемблер - в них искажены символьные имена итп.

TEXTБОЕВЫЕ ИСКУССТВА.FIL
TEXTПРАВИЛА ИГРЫ.FIL
TEXTПРЕДИСЛОВИЕ.FIL
Наверное, лучше подправить имена файлов - после TEXT вместо точки какой-то другой код.

Именно на нем нашелся файл ГИГАНТСКИЙ_ПАУК (с подчеркиванием) который имеет самую большую длину и 2 добавочные строчки в начале:

 1  IF ___PEEK = 4 THEN 98
 2 list14000$ = "ГИГАНТСКИЙ_ПАУК":

а во многих файлах правка ошибок. напр "ГОБЛИН НА БЕРЕГУ":

1410  PRINT "И НУЖДАЕТЕСЬ В ОТДАХЕ,НО ПОНИМАЕТЕ,ЧТО НАДО ТОРОПИТЬСЯ.

->

1410  PRINT "И НУЖДАЕТЕСЬ В ОТДЫХЕ,НО ПОНИМАЕТЕ,ЧТО НАДО ТОРОПИТЬСЯ.

В общем, часть файлов c этого диска более свежей версии.

Ничего стоящего к счастью. На этом диске следы того как я препарировал эппловские игрушки в поисках интересных картинок, графических и звуковых эффектов. Досталось Drol'у. :)
И тестировал эффекты изменяя их и ассимилируя понравившееся - если дать im-agat.0.98cor.b.dsk диску запуститься ([RUN SB, услышим сложный звуковой эффект в заставке External Zone)

140-01a, 140-01b - это диск с файлами ЧЗ. Я предвидел такое - поэтому первая строка файлов - REM "НАЗВАНИЕ ФАЙЛА". ;)
Эх, жалко что дату последней модификации для каждого файла стал ставить только начиная с External Zone.

140-16b - эппловская игрушка.

В эмуляторе есть несколько файлов палитр. Может, использовать файл для 16 цветов?

Отличная идея. Может даже оттенки серого. Теперь вижу, для чего эти палитры можно использовать на практике ;)

И кстати заметил неприятный факт для "16-ти цветного" 128x128 режима - цветов меньше 16, половина цветов повторяются... Видимо, для текстового режима так же. Неоправданная экономия дизайнеров железа. :(

    .db 0F0h,70h,0B0h,0D0h      ;СВЕТЛ (белый,белый,желтый,фиолетовый)
    .db 30h,0E0h,50h,90h      ;СВЕТЛО-СЕРЫЙ (желтый,голубой,фиолетовый,красный)
    .db 60h,0A0h,10h          ;ТЕМНО-СЕРЫЙ (голубой,зеленый,красный)
    .db 0C0h,20h,40h          ;ТЕМН (синий,зеленый,синий)
    .db 00h,80h              ;САМЫЙ ТЕМНЫЙ (черный,черный)

А в эмуляторе, соответственно, можно получить 8 дополнительных цветов (одновременно отображаются 16 разных) для 16-ти цветных режимов, верно?

Здесь хочется еще добавить, что эмулятору от Олега очень не хватает возможности вставки (эмуляции ввода с клавиатуры) текста из буфера обмена Windows.
EDIT: Но, в принципе, через тот же AHK можно сделать набивку текста в окно эмулятора. :)

Хорошее дополнение. Я уже хотел скриптик сварганить для их переименования. А тут вариант для ленивых :)

Ага, теперь понятно! Разница настолько минимальная в яркости, что делая эксперименты недавно (1 vs  9, 2 vs 0Ah, 3 vs 0Bh), на глаз даже не заметил - показалось, что цветов всего 8.
0 vs 8 (черный vs темно серый) и 7 vs 0Fh еще нормально, а по остальным цветам схалтурили :) напр., "грязно-желтый" vs желтый разница недостаточная, на примере других решений здесь обычно ожидаемо коричневый vs желтый.

Прошу меня простить за либеральность моих формулировок. :)
В цвете я оценивал только в эмуляторе. Но согласись, Alex, если бы распространенная цветовая гамма (которая диктовалась комплектным цветным монитором для Агат9) была "коричневый vs желтый", в эмуляторе мы увидели бы также ее.
В ч/б палитре 128x128x16 на мониторе мс 6105 (поправил) на глаз я, судя по своим комментариям в исходниках, тоже не мог различить разницу в яркости между 3 и 0Bh.
----------
На русской вики также есть фраза "256x256, 4 цвета из 16 возможных (4 палитры)".
Черта с два там выбор из палитры 16-ти возможных - в реальности один из режимов палитры - просто инверсный, где только черный заменен белым, остальные два - два цвета из четырех черные, черным заменяется либо зеленый либо красный, но во всех случаях выбор из палитры в 5 цветов...
И снова экономия там, где ее могло не быть.

Спасибо. Полезная табличка.
Интересно получается, у разработчиков Агата была теоретическая возможность расширить текстовый 32x32 режим, используя неиспользуемые 2 бита атрибутов. Понятно, что выйти за границы знакогенератора было бы технически сложно и неоправданно (чтобы реализовать подчеркивание, зачеркивание или еще какое-то выделение символов), но что насчет частоты мерцания? :)