Продолжение перевода статьи по восстановлению одной старой интересной машинки. В первой части наладили основной блок плат. Много тяжелых картинок. Курсивом мои комментарии.
Стриммер 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
Я сообщил линкеру, что нужно перебазировать код на адрес 0x1000 или 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.SYS
CAPS11.S8K
PIP.SRU
EDIT.SLG
LINK.SRU
ODT.SLG
PAL.SRU
BASIC.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.
Автор: mark_ablov
