[Перевод] Восстановление PDP 11/04. Ленточная станция TU60
Продолжение перевода статьи по восстановлению одной старой интересной машинки. В первой части наладили основной блок плат. Много тяжелых картинок. Курсивом мои комментарии.Стриммер TU60 и контроллер TA11В 70х DEC создали простую замену для перфолент, которая базировалась на разновидности простых аудио-кассет. TU60 вмещает два блока стриммеров. 50 метровая лента могла хранить до 100Кб: 
Вся логика привода содержится в 2х шестиконтактных платах (про это я писал ранее, унификация это хорошо):
На виде сверху можно заметить платы с аналоговой логикой, которая управляет моторчиками и считывает данные с магнитных головок. В отличии от обычных аудиокассет, приводы в TU60 не используют натяжной барабан для контроля скорости прохода ленты. Вместо него используются два независимых мотора. Один для перемотки кассеты и для того, чтобы держать её в натяжении. Второй, управляемый сервой, служит для протяжки ленты вперед (на самом деле, это адская схема. Когда кассета проигрывается либо просто находится на паузе, то первый мотор тоже включен. Скажем, один из них пытается мотать назад на 100 оборотов, а второй — вперёд на 110. И тогда более сильный побеждает, но, само собой, магнитной ленте это не очень нравится, поэтому даже не рекомендуется долго держать включенной данную станцию.). Скорость вращения второго мотора постоянна (не совсем корректно сказано, она постоянна при считывании ленты, но серва же! И скорость меняется в зависимости от задач. К примеру, при простое ленты, этот мотор в паре с первым, реверсным, мотором обеспечивает натяжение, то есть его скорость ниже чем при протяжке), битрейт на ленте — тоже, поэтому плотность информации меняется на протяжении всей длины ленты. Для кодирования данных TU60 использует манчестерский код.
Модуль контроллера TA11 представлен четырехконтактной Unibus-платой M7892 (про разные названия одной платы я тоже писал в прошлой статье):
Контроллер предоставляет простой интерфейс из двух регистров: коммандно-статусный (несмотря на частую практику, отдавать на чтение регистр в одном формате, а принимать на запись в другом, здесь всё не так. Это целостный регистр, но в котором одни поля — read-only, другие — write-only, но есть и смешанные read-write.), доступный по адресу 0177500, и буфер данных, расположенный на 0177502. Плата не просто посредник между TU60 и PDP-11, но так же содержит дополнительную логику — цепь работы с прерываниями и декодер адресов (он нужен для того, чтобы ловить обращения к регистрам).
Когда я начал играться с этим устройством, я сразу же столкнулся с проблемой. Кнопка перемотки, вроде бы, работала нормально. Но затем, внезапно, она сломалась. Было видно, что треугольная штуковина, которая соединяла ось мотора и кассету, спадала с оси. Согласно чертежам, здесь должен быть установочный винт #2–56 1/8» (дюймовый размер). Но его не было! И неясно было, как он мог пропасть. Второй привод имел ту же самую проблему (такого рода установочные винты крайне трудно найти в Швеции, ибо используем метрическую систему). Я вгляделся в схему более внимательно, и заметил на другой нижней треугольной сцепке надпись «loctite» вместо «установочный винт» (Loctite производит клей и прочую химию). Возможно, они просто использовали Loctite для обоих сцепок? В любом случае, я купил клей и, знаете что, это сработало просто отлично!
Тем не менее, диагностический тест ZTAA от Maindec не проходил. Первая проблема, которую я обнаружил, заключалась в DEC8881 драйвере, расположенном на управляющей плате, который не давал пройти сигналам EOT и BOT. Я заменил его на 7439, который я купил в Китае где-то за $3/штука. Занятно то, что когда я отпаял DEC8881, снизу он был маркирован как 7439! После этого диагностика стала проходить на втором стриммере, но не на первом. Не работала протяжка вперед, совсем. Шаг за шагом, я отследил неисправный драйвер с открытым коллектором 75452. Наконец-то, оба привода прошли ZTAA. Но не ZTAB…
Для того чтобы выяснить, что происходит при записи данных на кассету, я написал небольшую программу на ассемблере, которая непрерывно писала последовательность байт от 0 до 255 на протяжении всей ленты. Программа работала, поэтому я модифицировал её так же для чтения данных с ленты. Подключив логический анализатор к буферу данных, я получил постоянный поток байт 00, 01, 02, … FD, FE, FF, 00, 01. Чтение и запись работали!
Запускаем CAPS-11 Я получил образы лент с операционной системой CAPS-11. Загрузочная кассета содержала файл CTLOAD.SYS, который обеспечивал начальную загрузку самой ОС CAPS-11. Ну, может «операционная система» слишком громко сказано, CAPS-11 довольно простой парсер командной строки с функциями загрузки и сохранения файлов на кассету. Сама система находилась в файле CAPS11.S8K, и была слинкована для работы в окружении с 8 килословами памяти (память в PDP измерялась в словах процессора. Кстати, под это неплохо ложилась восьмеричная система, которая использовалась для задания чисел, главным образом, адресов.). Загрузочный процесс этой ОС достаточно сложен. Загрузочная область (расположенная по адресу 01000) называется CBOOT. Она пропускает первые 32 байта файла CTLOAD.SYS (который должен быть первым на ленте). Затем читает следующие 128 байт в память по адресу 0. Эта часть CTLOAD.SYS называется PRELDR. PRELDR выясняет размер доступной памяти и догружает весь CTLOAD.SYS в память по наивысшему возможному адресу. Догружаемый блок содержит CABLDR и CBOOT (зеркало). CABLDR это Cassette Absolute Loader, но, несмотря на название, формат читаемых файлов абсолютно тот же, что и для перфолент. Отсюда следует, что CAPS11.S8K имеет формат перфолент, и может быть легко загружен через PDP11GUI (про эту программу читать в прошлой статье). Однако, так как CABLDR использует регистр переключателя, который предоставляет программерская консоль, для определения того что и как загружать (в этом регистре, к примеру, можно было задать адрес перебазирования системы и грузить её по пользовательскому адресу), и, так как её у меня нет, то CABLDR останавливает машину с исключением несуществующей памяти.Использование PDP11GUI с начальным адресом 021510, позволяет увидеть приглашение CAPS-11. Система из начала 70х запущена в 2014. 40 лет:
Несомненно, что TU60 работает не очень хорошо.
Запуск C-кода на голой системе Для того чтобы разобраться с проблемой TU60, нужно чтобы этот аппарат мог просто повторять записанную последовательность операций в нужном порядке. Увы, но работа с диагностиками в XXDP довольно непредсказуема. Они могут печатать один и тот же код ошибки как для операций чтения, так и для операций записи. По крайней мере, я не могу точно определить, что идёт не так. Кроме того, при использовании логического анализатора, я могу проводить одинаковые замеры снова и снова, лишь немного меняя тестовые точки для исследования. Я решил, что лучший способ двигаться дальше, это написать свою собственную простую тестовую программку. До этого я писал крохотный код на ассемблере, который читал и писал данные на ленту. Но уже, даже с небольшим возрастанием объема кода, требовалось всё больше усилий на отладку, ибо я не очень опытный программист на ассемблере для PDP-11. Я люблю C.Что нужно для написания программ на Си? Конечно же, кросс-компилятор! Страница Diane Neisus вдохновила меня. Я скачал Binutils 2.24 вместе с GCC 4.8.2 и скомпилировал их.
Binutils:
src/configure --target=pdp11-aout --disable-nls make all sudo make install GCC: src/configure --target=pdp11-aout --disable-nls --without-headers --enable-languages=c make all-gcc sudo make install-gcc Затем мне нужен был файл с точкой входа для CRT — crt0.s. Я просто написал минимальный вариант который работал: .text .globl _main, ___main, _start
_start: mov $400, sp jsr pc, _main halt
___main: rts pc Так как форматированный вывод строк довольно полезная штука, я поискал и нашёл крохотную реализацию printf для встроенной разработки, которая вполне меня удовлетворяла. Компилируя библиотеку и пытаясь слинковать её, получил пачку сообщений о том, что множество функций не найдено — ___mulhi3, ___udivhi3 и другие. Функции использовались gcc вместо родных инструкций ассемблера PDP-11. Мне пришлось написать собственные версии этих простых функций, которые выполняли умножение, деление и взятие остатка.Теперь, во время компиляции с использованием флага -m10, используемого для создания PDP-11/10 совместимого выходного файла, компилятор рушился при генерации кода для конвертации short в long. Единственное решение, которое я нашёл, это компилировать под PDP-11/40 и затем вручную заменить те инструкции, которые не поддерживаются PDP-11/04, вроде SXT или ASHC.
После этого я был готов написать настоящий Hello world:
pdp11-aout-gcc -m10 -Ttext 1000 -msoft-float -nostartfiles -nodefaultlibs -nostdlib crt0.s printf.c test.c divmulmod.s pdp11-aout-objcopy -O binary a.out hello.dmp Я сообщил линкеру, что нужно перебазировать код на адрес 0×1000 или 010000, а затем использовал objdump для конвертации объектника в чистый бинарный файл.Сначала я пробовал этот файл запускать в эмуляторе E11, прежде чем включал реальное железо. Но вот скриншот запуска через PDP11GUI на настоящей машине:
Превосходно! Форматированный вывод работает как надо. Умножение, деление и взятие остатка так же выдают верный результат (Ну, на самом деле, не совсем. Оказалось, что функция взятия остатка содержит баг, который я должен был исправить). Теперь у меня был простой способ писать мои собственные тестовые программы на Си, которые нагружали бы мой старенький TU60. В конце концов, я думаю, что я могу написать программу, которая читает файлы через последовательный порт и пересылает их TU60, таким образом создавая загрузочные кассеты. В любом случая, я должен пропатчить CABLDR внутри CTLOAD.SYS, чтобы он не пытался читать регистр переключателя, что безусловно приводит к выбросу исключения. (Машина не имеет программерской консоли).
TU60EXERCISER
Я потратил несколько часов для написания маленькой программы, которую я назвал TU60EXERCISER: 
Теперь я могу проводить любые операции над приводом более простым путём, чем использование стандартных ZTA** программ. Тестирование READ команды выявило проблему на драйвере с открытым коллектором DEC8881 (это очередной DEC8881, а не тот который заменили ранее), которую я не заметил раньше, когда подключал логический анализатор напрямую к буферу данных TU60. Проблема заключалась в том, что CRC генерация либо, наоборот, проверка CRC сбоят. Я всегда получал ошибку CRC при чтении данных, даже когда они читались верно.
Исходник TU60EXERCISER’a можно найти здесь.
Поиск ошибок в логике работы с CRC Ниже расположены четыре фото, показывающие, что происходит, когда мы записываем символы «AB» на ленту, а 16-битная контрольная сумма генерируется. LSB данных пишется первым, и выставляется сигнал WRITED в активно-низкий уровень.Ключ к разгадке в том, что CRC генерируется сдвиговым регистром с обратной связью с входным сигналом проходящим через XOR-вентили для битов 15, 13 и 0.
Ошибка очевидна? Я не сразу её заметил, но спустя несколько часов я изучил фото снова и нашёл её!
Бит 5 застревает на высоком уровне. Но не всегда, как могут поправить меня остроглазые товарищи. В начале все биты в нуле. Правильно, но весь сдвиговый регистр находится в сброшенном состоянии из-за того, что ему подали сигнал очистки (на 8271, как и у многих других, есть пин очистки состояния). В этом случае выход верен, но, при последовательном входе данных в сдвиговый регистр, он выдаёт неверный результат. Он всегда сдвигается единичкой. Элемент реализуется чипом Signetics N8271, аналогичным Texas Instruments SN74179.
Я заказал новый из Болгарии (!).
Один шаг вперёд и два (три?) назад Меня ждало несколько неудач. После того, как я, наконец-то, получил 74179 из Болгарии и впаял его, а моя программа TU60EXERCISER, с соответствующей настройкой эмулятора, протестирована в E11, кассеты начали сбоить. Проявлялось это в том, что трение между головкой и лентой было настолько большим, что стриммер не мог перематывать их корректно. Кроме того, это приводило к ситуации, когда привод не мог ничего записать или считать из-за того, что движение ленты было прерывистым.Выяснилось, что это общая проблема старых кассет. У меня не было под рукой Deoxit D5 (специальный лубрикант для электро-механических соединений, использовался в статье по ссылке). Я попробовал силиконовый спрей от CRC, но он не дал какого-либо заметного эффекта.
Поэтому нужно искать новые кассеты. Я попытался сконвертировать стандартные аудиокассеты с помощью паяльника. В каком-то роде это работало, но почему-то иногда не детектировалось того, что перемотка достигла начала ленты. Стриммер просто продолжал перематывать на высокой скорости.
Но потом я, всё же, нашёл парня с Ebay из Германии, который продал мне 10 кассет Verbatim из термополимера по 1 евро каждая.
Когда они пришли, я сразу же бросился тестировать их, но тут оказалось, что компьютер больше не выдаёт мне командную строку эмулятора консоли. Что случилось? Подключив логический анализатор, я обнаружил, что машина останавливается после попытки исполнить инструкцию «mov» на 83-ей строке.
77 165046 005503 adc r3; R3=000000 C=1 78 165050 000303 swab r3; R3=000000 C=0 79 165052 001377 bne. ; br. if FAIL 80 81; ----------------------------------------- 82 83 165054 012702 165000 T2: mov #data0, r2; R2=165000 84 165060 011203 mov (r2), r3; R2=165000 R3=165000 Подключение щупов к шине микро-адреса показало, что, после шага выборки, процессор прыгает на микро-инструкцию по адресу 60 вместо 62 (обработчик режима source mode 2(при декодировании инструкций есть 8 режимов адресации операнда, а-ля регистр, непосредственное значение, etc. Здесь почему-то считался режим 0, вместо режима 2. Сам режим кодируется непосредственно в инструкции.)). Похоже что E88 не работает, так как её выход всегда 1, независимо от входа. Но, возможно, что также есть проблема с E77, так как она управляет шиной микро-адреса. В любом случае, у меня нет ни 7427, ни 74H01. Приятель-коллекционер из Швеции выслал мне 7427 для проверки.
Но, пока этот чип в пути, я могу использовать запасную процессорную плату для тестирования, дабы не терять времени.
Я начал проверку новых кассет, используя ZTAA-диагностику, которая прошла на отлично. Тогда я запустил ZTAB, которая тоже должна быть успешной, поскольку я исправил проверку CRC. Я запустил проверку и отошёл на полчаса. Когда я вернулся, звук, издаваемый стриммером, был другим, необычным, а консоль пестрела бесконечным ворохом ошибок. Второй привод вращался очень медленно. Выяснилось, что резина или пластик на шпинделе превратились в некий аморфный клей.
Я искал какую-либо замену этой резинке, но не смог ничего найти, что подошло бы тютелька-в-тютельку. Я пробовал два слоя велосипедной камеры шины. Я не был уверен, что такой тип резины достаточно мягок. Но, в любом случае, я должен был использовать хороший клей, для того чтобы приклеить резину на колесико шпинделя, потому что на плохом клею резинка достаточно быстро отлетала. Вторая проблема заключалась в том, что толщина велосипедной камеры непостоянна на всём вырезанном круге. Это может помешать, а может и нет. Сейчас посмотрим.
Я ходил и спрашивал сантехников, есть ли у них что-нибудь подходящее, но, к сожалению, они не смогли мне помочь.
Новая резиновая накладка на шпинделе Кстати, в тот момент мне пришёл 7427 для замены чипа на позиции E88, и процессор заработал! Через шведский форум по электронике я связался с человеком, который отправил мне резинку для шпинделя. Я смог снять старую, и приклеить новую на супер-клей.Теперь большинство диагностик проходят на обоих приводах, за исключением ZTAE, который же не проверяет ничего особенного?
Скрытый текст @ 007574 006574 006774 170617 @DD CLEARING MEMORY CHMDDA0 XXDP+ DD MONITOR 8K BOOTED VIA UNIT 0
ENTER DATE (DD-MMM-YY):
RESTART ADDR:033726 50 HZ? N Y
LSI? N
THIS IS XXDP+. TYPE «H» OR «H/L» FOR DETAILS .D
ENTRY# FILNAM.EXT DATE LENGTH START
000001 HMDDA1.SYS 22-MAR-80 17 000050 000002 HDDDA1.SYS 22-MAR-80 3 000071 000003 HUDIA0.SYS 22-MAR-80 6 000074 000004 UPD1 .BIN 22-MAR-80 12 000102 000005 UPD2 .BIN 22-MAR-80 16 000116 000006 HELP .TXT 22-MAR-80 26 000136 000007 HSAAA0.SYS 22-MAR-80 24 000170 000010 SETUP .BIN 22-MAR-80 26 000220 000011 GKAAA0.BIC 1-MAR-89 14 000252 000012 GKABC0.BIC 1-MAR-89 15 000270 000013 ZTAAC0.BIN 11-AUG-76 16 000307 000014 ZTABC0.BIN 11-AUG-76 17 000327 000015 ZTACC0.BIN 11-AUG-76 13 000350 000016 ZTADC0.BIN 11-AUG-76 16 000365 000017 ZTAEB0.BIN 11-AUG-76 13 000405 000020 ZTAFC0.BIN 11-AUG-76 2 000422 000021 ZTAHA0.BIN 11-AUG-76 6 000424 000022 ZKLAE0.BIC 11-AUG-76 14 000432 000023 ZDLAF1.BIN 12-MAR-77 17 000450 000024 ZDLBB0.BIN 11-AUG-76 16 000471 000025 ZDLCA0.BIC 11-AUG-76 19 000511 000026 ZDLDA1.BIC 29-JAN-77 19 000534 000027 ZDLOC0.BIN 17-AUG-76 4 000557 000030 ZKWKA1.BIC 29-JAN-77 27 000563
.R ZTABC0
MAINDEC-11-DZTAB-C
SWR = 000000 NEW =
TESTING DRIVE A | END PASS TESTING DRIVE B ` END PASS TESTING DRIVE A ` DATA PROBLEM PC TACS EXPECT RCV’D 010470 000004 000377 000122
x END PASS TESTING DRIVE B ` END PASS TESTING DRIVE A ` 000000 177500 001056 016632 @DD CLEARING MEMORY CHMDDA0 XXDP+ DD MONITOR 8K BOOTED VIA UNIT 0
ENTER DATE (DD-MMM-YY):
RESTART ADDR:033726 50 HZ? N Y
LSI? N
THIS IS XXDP+. TYPE «H» OR «H/L» FOR DETAILS
.R ZTAEB0
MAINDEC-11-DZTAE-B
SWR = 000000 NEW =
DRIVE A AND DRIVE B WILL BE TESTED *** FORMAT *** DRIVE A
001612 000000 001056 011646 @DD CLEARING MEMORY CHMDDA0 XXDP+ DD MONITOR 8K BOOTED VIA UNIT 0
ENTER DATE (DD-MMM-YY):
RESTART ADDR:033726 50 HZ? N Y
LSI? N
THIS IS XXDP+. TYPE «H» OR «H/L» FOR DETAILS .R ZTADC0
MAINDEC-11-DZTAD-C
SWR = 000000 NEW =
TESTING DRIVE A AND DRIVE B WRITE-FILE-GAP IMPROPER FLAG OCCURRED TEST ERROR PC PC TACS TADB 005636 010562 120140 000017
END PASS TESTING DRIVE B AND DRIVE A READ SHORT RECORD TEST ERROR BYTES PC PC TACS TADB LEFT 004742 011204 140144 000350 000006
BUFFER COMPARE BAD DATA READ TEST ERROR EXPT’D RCV’D BYTE PC PC TACS DATA DATA NUMBER 004746 010512 140144 000314 000357 000001
END PASS TESTING DRIVE A AND DRIVE B END PASS TESTING DRIVE B AND DRIVE A END PASS TESTING DRIVE A AND DRIVE B END PASS TESTING DRIVE B AND DRIVE A END PASS TESTING DRIVE A AND DRIVE B END PASS TESTING DRIVE B AND DRIVE A Следующий вопрос заключался в выборе подходящего носителя. У меня были только 2 оригинальные кассеты от DEC’a. Позже я получил несколько NCR-кассет от парня из Морокко. Видимо, они хранились в пустыне долгое время, потому что вся смазка испарилась. Verbatim-кассеты от парня из Германии выглядят довольно неплохо. Хотя у меня и были проблемы с прижимным устройством, сделанного из чего-то типа пены, которая со временем изнашивается. Наконец, у меня есть Maxell-кассеты, которые сбоят практически беспрестанно. Похоже, что лента не может выдерживать натяжение, создаваемое приводом, она рвётся после всего нескольких перемоток (о чём я, кстати, писал ранее).
Я так же пробовал конвертировать обычные аудио-кассеты, но с переменным успехом. Какие-то работали, какие-то — нет.
Следующий этап — записать CAPS-11 на кассету и запустить! Нужно лишь немного доработать TU60EXERCISER.
Наконец-то загрузка с кассеты После нескольких раундов отладки TU60EXERCISER (сейчас переименовано в to60tools), я, в конце концов, получил вариант, который позволял записывать данные на ленту. Теперь, интересно, загрузится ли PDP-11 с кассеты? После набора «CT» в эмуляторе консоли, стриммер сначала завращал кассету на короткий миг, но затем просто остановился. Я начал перечитывать мануал для CAPS-11 и заметил следующее:
PRELDR должен быть первой записью в первом файле на системной кассете. Этот предзагрузчик является небольшой программой, написанной в соответствии с «CBOOT Loader Format», которая достаточно продвинутая для того, чтобы определить размер памяти и загрузить последующие программы в верхние адреса памяти. CBOOT линкует, загружает в память по адресу 0 и запускает её автоматически. Карта памяти CAPS-11, на данном этапе загрузке, изображена в Figure E-3 как Memory Map #2.
Опирается ли PRELDR на то, что CBOOT, судя по схеме, расположен по адресу 01000? Я, конечно же, загружаюсь с ППЗУ.EDIT: настоящий источник проблемы найден благодаря приятелю-коллекционеру: CBOOT помещает TA11 CSR (командно-статусный регистр контроллера стриммера) в R0 (пользовательский регистр процессора), в то время как M9312 CT (M9312 — эмулятор консоли, CT — команда этого эмулятора, но в то же время это название микросхемы ППЗУ, которая содержит код загрузки с ленты. Команда лишь запускает код этого ППЗУ, но он автоматически пытается грузиться и при старте системы.) при загрузке заносит TA11 CSR в R1 (и номер стриммера в R0). PRELDR ожидает увидеть именно в R0 значение регистра TA11. Я должен пропатчить PRELDR для того, чтобы он мог грузиться непосредственно с CT-ПЗУ.
Я использовал E11 для сборки CBOOT из исходников и записал результат в файл CBOOT.BIN. После этого я загрузил его в память через pdp11gui и запустил с адреса 01000. Да! Кассета начала проигрываться в течении примерно полуминуты, и затем появился единственный символ ».». Я запустил CAPS-11!
.DI
--
CTLOAP SYS 19-FEB-14 CAPS11 S8K 25-NOV-13 DEMO PAL 25-NOV-13 EDIT SLG 25-NOV-13 LINK SRU 25-NOV-13 ODT SLG 25-NOV-13 PAL SRU 25-NOV-13 PIP SRU 25-NOV-13
? NO SENTINEL FILE
? SYNTAX ERROR
. Моя программа, для записи на ленту, не писала замыкающий файл, который должен быть последним на ленте. Тем не менее, сработало и так! CTLOAP.SYS — пропатченная версия CTLOAD.SYS, из который были удалены все обращения к регистру переключателя для того, чтобы программа заработала и на машинах только с операторской консолью.Археология старых кассет Для начала, я пропатчил CTLOAD.SYS для загрузки напрямую с CT ППЗУ на M9312, что крайне удобно. Никакой больше ругани при наборе команд или при заливке файла (9600bps, грустно всё это) начального загрузчика. Просто включить тумблер INIT, и стриммер начинает работу. Отлично. Выяснилось, что не только PRELDR нуждается в модификации, но нужно еще добавить инструкцию BR (безусловный короткий переход, -128…+127) для того чтобы, пропустить инициализацию регистра R0 в недрах CABLDR. Здесь патченная версия, если кому нужно.После загрузки CAPS-11, меня заинтересовало, что же на самом деле хранится на тех двух старых DEC-кассетах. Фото одной из них есть выше, она промаркирована как «S LMS 2 KOP». «KOP» может значить «KOPIA», КОПИЯ. Но, кроме этого, я не могу разобрать, что остальные символы значат. Она содержит какие-то файлы:
010000 051415 177714 000002 @CT
CAPS-11 V01–02
.DA 27-MAR-14
.DI CT1:
27-MAR-14
CTLOAD SYS 07-JAN-75 CAPS11 S8K 07-JAN-75 PIP SRU 07-JAN-75 EDIT SLG 07-JAN-75 LINK SRU 07-JAN-75 ODT SLG 07-JAN-75 PAL SRU 07-JAN-75 BASIC LDA 07-JAN-75
. В системе CAPS-11 кассета датирована январём 1975-го года. Файлы почти 40-летней давности. Я сделал копию и использовал свой пропатчанный загрузчик для её запуска. Она запустилась. Но не было никакой командной строки. Возможно, что софт был сконфигурирован под другую версию железе, отличную от моей.
Было бы занятно извлечь содержимое кассеты. Я продолжил работу над tu60tools. Опять же, долгая отладка при запуске на голом железе. Здесь нет никаких приятных глазу трассировок стека, когда возникает проблема с указателями. Наконец-то, TU60read была готова для чтения файлов с кассеты, и, вроде бы, даже работала. По крайней мере, она корректно считала файл, который я записал на кассету. Я использовал её для кассеты-копии, сделанной ранее, и получил следующие файлы:
CTLOAD.SYSCAPS11.S8KPIP.SRUEDIT.SLGLINK.SRUODT.SLGPAL.SRUBASIC.LDA
Я изучил бинарник CTLOAD.SYS. Он занимает 896 байт (7 блоков) вместо 1024. Но выглядит он полноценно. Дизассемблирование показывает, что большая часть кода идентична CTLOAD.SYS, идущем с CAPS-11.
BASIC.LDA похож на копию перфоленты с BASIC’ом. Запустив strings над этим бинарником, получил «PDP-11 BASIC, VERSION 007A». Аналогично для «CAPS11.S8K» даёт «CAPS-11 V01–02». Поэтому, я думаю, что эта кассета лишь немного отличается от оригинала.
После этого я попробовал сделать такое же исследование второй кассеты, но файловая система на ней была повреждена. Мне удалось откопать только этот кусок кода для PDP-8:
Скрытый текст TO +1 IF HIGH TEST DCA TEST TAD TABNO AND P777 DCA TABNO /SAVE TABLE NUMBER TAD LTAB DCA TCORE /SET CORE ADDRESS CLL CIF JMS I TABLE /READ LIMIT TABLES TABNO, 0 TCORE, 0 CLA CLL CDF TAD I BAND1 /FETCH NUMBER OF DCA B1 /CHANNELS FROM MEM0 TAD I BAND2 DCA B2 JMS I RSETDF IAC JMS COMWRD /FETCH BATCH TRAIN NO SPA CLA /RELOCATE OUTER BAND? JMP INNER /NO — INNER DCA CHNO /YES — SET 1: ST CHANNEL NUMBER TAD B1 /FETCH CHANNEL COUNTER JMP BOTH INNER, TAD B1 /CALCULATE FIRST CHANNEL NO CIA DCA CHNO TAD B2 /FETCH CHANNEL COUNTER BOTH, DCA CHCNT /SAVE COUNTER ON PAGE ZERO TAD P5 JMS COMWRD /FETCH CHANNEL NUMBER SNA /ZERO? JMP ALL /YES — TEST ALL ON ONE BAND TAD M1 /NO — SAVE CORRECT DCA CHNO /CHANNELNUMBER TAD M1 DCA CHCNT /SET COUNTER TO -1 SKP SINGLE, CLA IAC /SET AC TO 11 ALL, TAD P10 /SET AC TO 10 JMP I RELO /RELOCATE ACLEAR, DCA I TEMP /CLEAR RCLEAR IN COMMAND BUFFER ISZ TADDR /SET POINTER TO CORRECT CDF /ADD TERM IN TBTAB DCA I TADDR /ZERO ADD TERM JMS I RSETDF /RESET DATA FIELD NOP CMA DCA QCPFEL JMS I DCWAIT TAD QCP /INDICATE READY CIF CLL JMS I MONDSC /RETURN TO QCP HLT /SECURITY HALT COMWRD, 0 /ADD TERM IN AC TAD COMAND DCA TEMP /ADDR IN COMAND BUFFER TAD I TEMP /FETCH COMAND WORD JMP I COMWRD /TO AC AND RETURN
/CONSTANTS: BAND1, 66 /PAGE0, MEM0 BAND2, 67 / » » B1, 0 B2, 0 TEMP, 0 P3, 3 P4, 4 P5, 5 P10, 10 P50, 50 P51, 51 P52, 52 P54, 54 P55, 55 P77, 77 P777, 777 P3777, 3777 P6000, 6000 M1, -1 M2, -2 M2001D, -3721 QCP, 4023 /AUT OSTART QCP
$ Ладно. Теперь, когда машина запускает как надо, я приступлю к заключительной стадии этого проекта восстановления PDP-11: оживить LA30 Decwriter и запустить его совместно с PDP-11.
В третьей части статьи чиним терминал LA30 Decwriter.
