• Предыстория
• Специальные замечания
  
• Формат данных на ленте
• Логический
• Кодирование
• Кодирование слов
• Поля файла
• Cинхропоследовательность
• Маркер начала
• Заголовок
• Данные
• Контрольная сумма
• Конечная синхропоследовательность
• Алгоритм чтения
• Утилита bkread
• Ключи командной строки
• Пример сессии чтения
• Дополнения
  
• Утилита dasm
• Ключи командной строки
• Файлы форсированых установок
• Утилита focal2txt
• Работа с утилитой
• Компиляция и портирование программ

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

Логически данные (записанный файл) выглядят на ленте так:
 

Стартовая синхропоследовательность

Маркер начала

Заголовок

Данные

Концевая синхропоследовательность

С точки зрения читающей программы стартовая настроечная последовательность представляет собой 10000₈ нулевых одиночных импульсов (один импульс - один период сигнала см. рис.). Длина (продолжительность) такого импульса в дальнейшем определяет "эталонную единичную длину" для всех последующих данных.

Рисунок. Одиночный импульс.

Маркер начала это 10₈ нулевых одиночных импульсов, заголовок - 24₈ байт информации о записаном файле и следующие за этим 10₈ нулевых импульсов, данные - это, собственно, данные файла, заканчивающиеся двухбайтовой контрольной суммой, концевая настроечная последовательность - 400₈ нулевых одиночных импульсов. Все элементы, кроме массива данных, заканчиваются синхроимпульсами, за которыми следует единичный бит (синхропоследовательностью).

Каждый бит кодируется двумя импульсами - информационным и синхронизирующим. Нулевой бит кодируется двумя одинаковыми импульсами одиночной длины (см. рис.). Первый импульс своей длительностью определяет значение бита ("0"), второй - синхронизирующий.

Рисунок. Нулевой бит.

Рисунок. Единичный бит (реально).

Рисунок. Единичный бит (идеально).

Рисунок. Синхропоследовательность.

Рисунок. Последовательность бит "1010"

Теперь можно рассмотреть поля файла отдельно.

Внимание! Данные длиной в слово хранятся и записываются в БК в формате LSB (младший байт первый), что следует учитывать при написании или портировании утилит работы с файлами под системы, использующие MSB формат (большинство RISC систем).

Как уже указывалось, в начале файла записывается настроечная последовательность из 10000₈ нулевых одиночных импульсов, которая используется для детектирования начал файла и настройки ПО на скорость воспроизведения данных. В конце настроечной последовательности записывается синхропоследовательность.

Маркер начала, как это следует из косвенных данных к которым у меня был доступ, должен содержать параметры записи (типа, инверсии данных, порядка байт и пр.). Однако, так-как в реальных условиях никакие опции не используются, и не заложены в алгоритмы работы драйвера магнитофона БК, можно считать, что он содержит 10₈ нулевых одиночных импульсов и синхропоследовательность в конце.
Заголовок содержит следующие поля:
 

Данные так же записываются сплошным потоком бит без разделителей байтов в потоке.

В конце записываемого массива данных помещается двухбайтовая контрольная сумма, которая получается в результате 16 разрядного беззнакового суммирования с переносом всех байтов массива данных. В терминах ассемблера алгоритм подсчета контрольной суммы выглядит так:

        MOV    START, R1
        MOV    LENGTH, R2
        CLR    R0
LOOP:   MOVB   (R1)+, R3
        BIC    #177400, R3     ; СБРОС СТАРШИХ БИТ В СЛУЧАЕ ПЕРЕНОСА ЗНАКА
        ADD    R3, R0
        ADC    R0              ; УЧЕСТЬ ВОЗНИКНОВЕНИЕ ПЕРЕНОСА
        SOB    R2, LOOP
        ...                    ; R0 СОДЕРЖИТ КОНТРОЛЬНУЮ СУММУ

Сразу за контрольной суммой записывается импульс шестикратной длительности, назначение которого - точно обозначить конец данных и вызвать гарантированную ошибку в случае пропуска данных при чтении.

Назначение конечной синхрополедовательности мне не известно и не понятно.

• Алгоритм чтения

1. Анализировать сигнал, пока на входе не появится группа из NSTART однородных импульсов.
2. Настроить временные интервалы на основе среднего из NTUNE последующих интервалов.
3. Продолжить чтение импульсов до синхропоследовательности.
4. Прочесть маркер начала и убедиться в его правильности.
5. Прочесть заголовок и убедиться в его правильности.
6. Прочесть данные.
7. Подсчитать контрольную сумму и убедиться в правильности считывания данных.

• Некоторые пояснения

1. Константы NSTART и NTUNE в оригинальном драйвере равны 4000₈ и 200₈ соответственно. Хотя искуственное разделение непрерывной настроечной последовательности может показаться неразумным, связано оно с определенными особенностями функционирования контроллера DRAM на КР1801ВП13, которые при работе программы записи на МЛ могут в начале последовательности ускорить работу ЦП за счет временного уменьшения времени доступа к оперативной памяти как результата работы алгоритмов (все временные задержки при записи формируются программными циклами), в результате чего при чтении могли бы неправильно быть вычислены счетчики, ответственные за измерение длительности импульсов. Однако, при чтении фактически пропускается NSTARTимпульсов, что гарантирует прохождение интервала времени, достаточного для стабилизации скорости, а счетчики формируются уже на основе последующих NTUNE импульсов.
2. Видимо для упрощения, в оригинальном драйвере длина маркера не контролируется, алгоритм пропускает все импульсы единичной длины до появления синхропоследовательности.
3. Аналогично, в оригинальном драйвере не проверяется значение следующего за синхроимпульсом бита в синхропоследовательности, алгоритм просто читает (и пропускает) следующий за синхроимпульсом бит.

bkread читает информацию с магнитофона через аудиовход. Вызов утилиты производится следующей командой:

$ bkread [ключи] [имя]

• Ключи управления аудиовходом:
• -r число - число задает коэффициент усиления картой входного сигнала. Значение должно находиться в пределах от 0 до 100 (минимальное и максимальное усиление). Если ключ -r не задан, то коэффициент усиления зависит от особенностей ОС. В случае Solaris коэффициент усиления остается равным последнему, установленному одной из утилит (в т.ч. и bkread).
• -m число - коэффициент усиления цепи мониторинга входного сигнала. Значение должно находиться в пределах от 0 до 100 (минимальное и максимальное усиление). Если ключ -r не задан, то коэффициент усиления зависит от особенностей ОС. В случае Solaris коэффициент усиления остается равным последнему, установленному одной из утилит (в т.ч. и bkread).
• -R число - задать альтернативный коэффициент дискретизации аудиоданных, число соответствует количеству снимаемых с карты за секунду значений. Задается либо в виде точного значения (-R 96000), либо в тысячах (-R 44), что оставлено для совместимости с версией 1. Значение по умолчанию - 44100 (т.е. -R 44100, CD quality).
• -A спец. файл  - задать альтернативное аудиоустройство, полезно если у вас установлено более одной аудиокарты или используются нестандартные имена файлов устройств.
• -M спец. файл  - (только под Linux!) задать альтернативное микшерное устройство, полезно если у вас установлено более одной аудиокарты или используются нестандартные имена файлов устройств.
• Ключи управления анализатором:
• -a число - задает максимальное количество адаптаций скорости при чтении файла. В bkread используется адаптивный алгоритм анализа сигнала, позволяющий по ходу чтения динамически изменять скоростные коэффициенты, что позволяет компенсировать неравномерность скорости воспроизведения (записи) на магнитофоне. По умолчанию количество таких адаптаций неограничено.
• -e число - задает уровень нуля. По умолчанию нулевому уровню соответствует среднее значение между максимальным и минимальным значениями амплитуды, выдаваемыми аудиокартой. В некоторых случаях, например при искажениях сигнала или при помехах бывает полезно сместить уровень со среднего значения в одну из сторон. Значение должно лежать в пределах от 0 до 255 так-как bkread использует 8-битный режим ввода.
• -s число - задает количество единичных импульсов, используемых при определении синхропоследовательности. По умолчанию используется число 3140₈ (несколько меньше принятого в драйвере МЛ БК - 4200₈). Впоследствии число разделяется на количество импульсов, необходимых для получения среднего значения длительности единичного импульса по формуле (n/21₈) и количество импульсов для детектирования настроечной последовательности по формуле (n-n/21₈) соответвенно.
• -p 0|1 - задает какую часть полупериода на входе считать единичным импульсом - отрицательную (0) или положительную (1). По умолчанию используется положительная часть.
• Ключ -v включает режим вывода расширенной диагностики (автор всегда задает этот ключ, поскольку наблюдать за происходящим довольно интересно). Пример сессии чтения приведен ниже. Читается содержимое монитора БК.

$ ./bkread -v -r 80 -m 20 -e 132 MONITOR
Opening /dev/dsp as sound device...
Opening /dev/mixer as mixer device...
Recording level set by "IGain" (12)
Monitoring device is "Line " (6)
Fragment size set to 4096 bytes
Audio:    recording gain = 60
Audio:    monitor gain = 40
Audio:    sample_rate = 44100
Audio:    edge level = 128
Analyzer: synchro tuning pattern count = 1632
Analyzer: max. number of adaptations set to unlimited

Listening for header synchros (S=1536; T=96)...
Synchros detected. Pattern length = 7.
Pattern length after tuning = 8.
Patterns lengths: 0 = 8; 1 = 16.

Signal Period Analyzer Line (2..40):
--000000000111111111111SSSSSSSSSSSSSSSS
---------------------------------------
000000001111111111222222222233333333334
234567890123456789012345678901234567890

File Name = "MONITOR         "
Data Length =  20000 (octal).
Data Address = 100000 (octal).
Tape Checksum =  17341 (octal).
Data Checksum =  17341 (octal).
Saving file to: MONITOR (8214 bytes).

Listening for header synchros (S=1536; T=96)...
^CSignal (2) received. Program stopped.

$ dasm [-a | -b | -c | -f forced_file] tape_file

• -a указывает необходимость вывода ASCII кодов;
• -b указывает необходимость вывода байтовых кодов
• -c отменяет пословный вывод кодов.

; Disassembler V01.5.1 BK 001x-xx (bkread)
; Alexander "las" Lunev
; Start address = 100000
; Length = 20000
; Tape file name: MONITOR           
;       Command Operand(s)              Address  Codes
;
$START$:JMP     MONITOR                 !100000: 000167 000254 167 000 254 000 "w.?."
 EMT_4P:.WORD   100742                  !100004: 100742 342 201 "??"
 EMT_6P:.WORD   101010                  !100006: 101010 010 202 ".?"

Ключ -f задает файл форсированных меток, т.е. если (как правило ;) дизассемблер неверно интерпретирует участки кода как данные или как коды, когда они таковыми не являются, то можно форсировать интерпретацию данных в нужном представлении.

Сам файл устанвок имеет достаточно примитивный формат:

<type> <addr> <label>
...

d 100004 EMT_4P
d 100006 EMT_6P

Внимание! dasm - достаточно примитивная утилита, которая не будет совершенствоваться или исправляться в дальнейшем, ввиду подготовки к выходу более совершенного JDasm, идущего в составе JavaPDP. Это, однако не мешает любителям программирования на C модифицировать и дополнять программу с целью приведения ее в "божеский вид".

$ focal2txt tape_file

$ make