Пользователь
0,1
рейтинг
18 ноября 2014 в 17:30

Восстановление 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

Я сообщил линкеру, что нужно перебазировать код на адрес 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.
Перевод: Mattis Lind
@mark_ablov
карма
93,0
рейтинг 0,1
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (2)

  • 0
    Для начала, я пропатчил CTLOAD.SYS для загрузки напрямую с CT ППЗУ на M9312


    Это впечатляет гораздо больше чем KDE под FreeBSD! Вообще, читая эту статью я понял, что ощущали герои Lost попав в бункер Dharma Initiative из 70-х годов.
  • 0
    Все таки как мы, люди, привязываемся к технике. То, что изначально создается отслужить положенный срок и отправиться в утиль, становится чем то близким, родным. Вроде старой больной собаки, прожившей с тобой половину твоей жизни.
    Вот чем современней устройство, тем проще к нему относишься. Молодцы китайцы, не дают компьютерам нас поработить — просто не успеваешь к ним привыкнуть.

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