Искра-226/Файловая система: различия между версиями

Материал из Emuverse
Строка 76: Строка 76:


=== Пример ===
=== Пример ===
 
  0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
  10 80 00 31 00 3F 00 00 44 49 47 20 44 45 4D 20
  10 80 00 31 00 3F 00 00 44 49 47 20 44 45 4D 20
 
└───┘ └───┘ └───┘      └─────────────────────┘
Активная запись, программа, секторы 49…63, имя <code>DIG DEM</code>.
Активная запись, программа, секторы 49…63, имя <code>DIG DEM</code>.



Версия от 15:51, 11 августа 2026

Этот документ создан для Emuverse и распространяется на условиях лицензии CC-BY-SA-3.0.

Формат файлов BASIC 02 — способ хранения программ на дисках Искра-226. Файловая система унаследована от Wang 2200, представление программы — оригинальное и с Wang несовместимо.

Программа может храниться в двух видах: текстовом (плоский текст в КОИ-8) и токенизированном. Оба вида имеют одинаковую внешнюю структуру и различаются одним байтом в заголовочном секторе.

Общее устройство

На диске располагаются физические сектора размером 128 байт — 77 дорожек, 26 секторов на дорожке, одна сторона. Физические сектора попарно объединены в логические размером 256 байт со сквозной нумерацией. Далее везде будут подразумеваться логические сектора.

Файлу выделяется непрерывный диапазон секторов, границы которого записаны в «Указателе каталога». Раскладка внутри диапазона:

Сектор Содержимое
первый заголовок файла
следующие N поток содержимого
резерв, заполнен нулями
последний выделенный control record

Таким образом, любой файл занимает на диске как минимум на 512 байт больше, чем размер его полезных данных.

Размер файла на диске уменьшать нельзя, поэтому при перезаписи файла более коротким содержимым старые данные в хвосте не затираются. Там могут остаться читаемые фрагменты предыдущих версий файла, иногда в другом представлении. Их нельзя принимать за часть текущего файла, поэтому необходимо завершать обработку файла при нахождении первой control record.

Искра-226 поддерживает работу с двумя типами файлов: ПФ — «Программные файлы» и ФД — «Файлы данных». Программные файлы всегда содержат программу на Бейсике, в текстовом или упакованном токенизированном виде. Файлы данных, соответственно, данные, доступные из программ пользователя.

В соответствии с документацией, Искра-226 поддерживает прямой доступ программ к секторам диска, при этом к записанным таким образом дискам всё нижеизложенное может быть неприменимо, так как форматом хранения полностью управляет программа пользователя по своему усмотрению.

Указатель каталога

Начиная с 0 сектора на диске располагается «Указатель каталога».

Первые 16 байт содержат служебную информацию в следующем составе:

Смещение Размер Значение
0-1 2 размер Указателя каталога в секторах, 16 бит big-endian
2-3 2 номер последнего использованного сектора, 16 бит big-endian
4–5 2 размер тома (обычно 1000), 16 бит big-endian
6–15 10 нули

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

Запись каталога

16 байт, побайтово совпадает с Wang 2200.

Смещение Размер Значение
0 1 статус: 10 — активна, 11 — удалена (scratched), 00 — свободна
1 1 тип файла: 80 — программа, 00 — данные
2–3 2 первый сектор файла, старший байт первым
4–5 2 последний сектор файла, старший байт первым
6–7 2 не используются
8–15 8 имя файла, дополнено пробелами справа

Байт типа не различает текстовое и токенизированное представление: у обоих 80.

Указатель каталога всегда начинается с нулевого сектора диска; за ним идёт область каталога. Число секторов указателя задаётся при создании каталога оператором SCRATCH DISK параметром LS=, по умолчанию равно 24 и в дальнейшем не меняется; допустимы значения от 1 до 255. В нулевом секторе помещается до 15 записей, в остальных — до 16: первые 16 байт нулевого сектора занимает блок параметров диска. Номер сектора указателя, в который попадает имя файла, вычисляется функцией от самого имени, поэтому порядок имён в указателе не совпадает с порядком размещения файлов в области каталога.[1]

Оператор LIST DC выводит типы файлов как P (программный), D (файл данных), SP и SD (вычеркнутые из каталога программный и файл данных соответственно), что соответствует сочетанию байта статуса и байта типа в записи.[1]

Пример

 0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
10 80 00 31 00 3F 00 00 44 49 47 20 44 45 4D 20
└───┘ └───┘ └───┘       └─────────────────────┘

Активная запись, программа, секторы 49…63, имя DIG DEM.

Заголовочный сектор

Смещение Значение
0 01
1–8 имя файла, дополнено пробелами
9 признак формата записи, см. ниже
10–255 нули

Байт 9 — единственный признак, по которому различаются два представления программы. Наблюдались значения 20 (текстовое) и 21 (токенизированное), каждое на двух файлах.

Связь с параметрами оператора SAVE DC

Документация[1] описывает три параметра специальных форматов записи программы:

Параметр Действие
T программа записывается в оттранслированной форме — во внутреннем формате машины, что сокращает занимаемое место и время загрузки
P программа защищается от просмотра и записи; после загрузки возможно только выполнение, режим сохраняется до оператора CLEAR
G оттранслированная и защищённая форма одновременно

Отсюда следует, что текстовое представление — это режим по умолчанию, а токенизированное включается явным указанием параметра T. Термин «оттранслированная форма» в документации обозначает именно токенизированную запись.

Документированные значения байта 9 (в источнике он назван «признак защиты»):[2]

Значение Символ Защита Представление
20 пробел нет текстовое
21 ! нет оттранслированное
24 ¤ есть текстовое
25 % есть оттранслированное

Таким образом байт 9 — битовое поле: бит 0 — программа оттранслирована (параметр T), бит 2 — программа защищена (параметр P); сочетание обоих соответствует параметру G. Значения 22 и 23 не используются.

Значения 20 и 21 наблюдались на дисковых образах, 24 и 25 взяты из документации.

Секторы потока

Первые два байта каждого сектора потока — служебные, в содержимое не входят.

Байт 0 — позиция сектора:

Значение Смысл
02 первый сектор потока
8F промежуточный
03 последний

В токенизированных программах все секторы потока наблюдались с маркером 02; позиционная разметка 02/8F/03 подтверждена на текстовых файлах и на потоке значений переменных. Причина различия не установлена.

Байт 1 — только у программных секторов. Во всех исследованных потоках программы он равен 80.


Внимание

У секторов данных служебный заголовок занимает один байт, а не два. То, что во всех наблюдавшихся секторах данных на позиции 1 стоял 00, объясняется не разметкой потока, а тем, что это первый байт двухбайтового идентификатора значения, и 00 в нём означает числовой тип. Для сектора, начинающегося со строкового значения, значение будет другим. Использовать байт 1 как признак «программа или данные» нельзя; надёжный признак — байт 9 заголовочного сектора и байт типа в записи каталога.

Двухбайтовая длина служебного заголовка программных секторов подтверждается арифметикой: длины записей строк сходятся только при пропуске двух байтов на каждой пересекаемой границе сектора.

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

Маркер 03 имеет содержательный смысл: документация[1] описывает файл как область, в которой между последней записью данных и последним сектором файла остаются неиспользованные секторы, а концевая запись помечает сектор, откуда можно продолжать запись. Таким образом 03 — не просто «последний по счёту сектор», а граница записанной области, и всё, что лежит за ней до конца выделенного диапазона, к текущему содержимому файла не относится.

Control record

Лежит в последнем выделенном секторе, а не сразу за содержимым.

1C <длина: 2 байта, старший первым>

Остаток сектора — нули. Маркер 1C соответствует по роли байту 20 в Wang. Второй источник[2] описывает эту структуру как признак конца файла 1C, за которым во втором и третьем байтах сектора записано число реально занятых секторов, а остальные байты нулевые; последний сектор файла данных устроен так же, как последний сектор программного файла.

Документация[1] отдельно указывает, что последний сектор файла отводится под служебную информацию, а концевая запись занимает ещё один сектор, поэтому при создании файла его размер следует заказывать на два сектора больше, чем требуется собственно под данные.

Счётчик соответствует графе «Использовано», которую показывает оператор LIST DC. Согласно документации[1] он не поддерживается системой автоматически: значение заносит прикладная программа оператором DATA SAVE DC END, записывающим односекторную концевую запись в текущий сектор из таблицы устройств. Если признак конца данных не записан, в графе «Использовано» всегда стоит 00001; если записан — число реально использованных секторов.

Там, где значение выставлено, оно равно заголовок + секторы содержимого + сам control record, то есть совпадает с правилом Wang:

Файл Секторов содержимого Счётчик Ожидаемо
ФС 5 7 1+5+1 = 7
ДЕМ6 16 18 1+16+1 = 18


Внимание

Счётчик не является инвариантом файловой системы и при разборе ненадёжен. У #СТАТИСТ он равен 48 при 46 секторах содержимого — значение, по-видимому, осталось от предыдущей, более длинной версии программы, остатки которой лежат в резерве того же файла. У DIG DEM счётчик равен 6 при 5 секторах содержимого, то есть на единицу меньше ожидаемого; возможная причина в том, что там последней операцией была запись потока данных, а не программы. Границы файла следует брать из каталога, а конец данных определять по структуре записей.

Текстовое представление

Программа хранится плоским текстом. Кодировка — КОИ-8 (ГОСТ 19768-74): прописная кириллица в 0xE0–0xFF, строчная в 0xC0–0xDF. Номера строк записаны обычными ASCII-цифрами.

  • Разделитель строк — байт 85.
  • Строка не пересекает границу сектора; хвост сектора заполняется нулями.
  • Байт 24 ($) отображается на экране Искры как ¤.

Выбор 85 возможен именно потому, что кириллица занимает только верхнюю четверть кодовой таблицы и диапазон 0x80–0x9F остаётся свободным. К самой кодировке КОИ-8 это соглашение отношения не имеет и за пределами Искры не встречается.

Разбор: склеить содержимое секторов, отбрасывая по два служебных байта, разбить по 85, отбросить нули.

Пример

02 80 35 20 52 45 4D 20 F0 E5 F4 F2 E5 EE EB EF … 85 38 20 50 52 49 4E 54 …

Заголовок сектора, затем 5 REM ПЕТРЕНКО …, разделитель, 8 PRINT ….

Токенизированное представление

Сборка потока

Склеить содержимое секторов с байтом 1 равным 80, отбрасывая по два служебных байта у каждого. Далее смещения даны от начала полученного потока.

Пролог и таблицы

Поток начинается с трёх 16-битных длин, старший байт первым, за которыми следуют три таблицы:

Смещение Размер Значение
0 2 L1 — длина таблицы 1 в байтах, запись 8 байт
2 2 L2 — длина таблицы 2 в байтах, запись 4 байта
4 2 L3 — длина таблицы 3 в байтах, запись 4 байта
6 L1 таблица 1
6+L1 L2 таблица 2
6+L1+L2 L3 таблица 3

Программа начинается по смещению 6 + L1 + L2 + L3.

Проверено на трёх файлах:

Файл L1 L2 L3 Старт Первая строка
DIG DEM 24 20 0 50 0 GOTO 10
#СТАТИСТ 216 488 108 818 999 REM КОНЕЦ
ДЕМ6 392 256 0 654 10 REM "ДЕМ6". ГОРОСКОП

Формула даёт точную границу, эвристический поиск начала программы не требуется.

Таблица 1

Записи по 8 байт. Байты 0–1 — адрес, младший первым, строго возрастающий от записи к записи. Шаг между соседними адресами принимает значения 2, 4, 8, 12, 48, что соответствует размерам объектов: 2 байта — целочисленная переменная BASIC 02, 8 байт — число в BCD, кратные — массивы. Назначение байтов 2–7 не установлено.

Таблица 1 описывает переменные, объявленные в DIM, и номер записи в ней равен индексу переменной в коде. В файле ДЕМ6 три оператора DIM перечисляют индексы 0005, 0629 и 2A30, то есть 49 переменных подряд; L1 = 392 = 49 × 8. Совпадение точное.

Таблицы 2 и 3

Записи по 4 байта: <адрес: 2 байта, младший первым> <флаг> <байт>. Флаг принимает значения 10, 21, 80, 81, 90, 91, A0, A1. Встречаются записи с нулевым адресом — предположительно незанятые слоты. Формат записей в обеих таблицах одинаков, граница между ними определяется только счётчиками пролога.

Нумерация индексов сквозная: таблица 1 занимает индексы от 0 до (L1/8 − 1), таблица 2 продолжает нумерацию. В ДЕМ6 индексы 313F адресуют первые пятнадцать записей таблицы 2, и именно у этих пятнадцати адреса образуют непрерывный ряд с шагом 8 (8-байтовые числа BCD).

Оставшиеся записи таблицы 2 в коде не адресуются, а их количество равно числу записей таблицы 1 — 49 в ДЕМ6 и 3 в DIG DEM. Похоже, каждой размерной переменной соответствует второй дескриптор в низкой области памяти, однако на третьем файле это разбиение не проверяется, поэтому пока наблюдение, а не правило.


Внимание

Соответствие «индекс переменной в коде → имя переменной» не установлено. В таблицах имена в явном виде отсутствуют. Индексы, судя по наблюдениям, назначаются по порядку объявления и первого появления переменной: в #СТАТИСТ =00, N3=0E, N6=11, F1¤=12, E=1B, E7%=1C, U1¤()=30, F%=5C, N7=5D, W0=7D, U9%=81. Это главное препятствие для получения читаемого листинга.

Известно, что имена ограничены буквой с необязательной цифрой — оператор LIST V выводит переменные в алфавитном порядке от A до Z9, группируя их по типам: целые, действительные, символьные, затем массивы целых, действительных и символьных.[1] Такое имя укладывается в девять бит, что делает вероятным его размещение в паре «флаг + байт» записей таблиц 2 и 3. Порядок записей в таблицах при этом не алфавитный, а соответствует порядку объявления переменных.

Записи строк

Программа — последовательность записей, разделённых байтом FE. Перед первой записью разделителя нет.

<номер строки: 2 байта BCD> <len: 1 байт> <тело>

len считается включая сам байт len и до следующего FE. Следующий разделитель находится по адресу адрес(len) + len.

В отличие от текстового представления, записи пересекают границу сектора; два служебных байта нового сектора в длину не входят.

Операторы

Тело записи — последовательность операторов:

<токен глагола: 1 байт> <len: 1 байт> <операнды: len байт>

Здесь len — длина только операндов, сам байт len не считается. len = 00 означает оператор без операндов, например голый PRINT.

Наличие явной длины у каждого оператора позволяет разрезать программу на операторы, ещё не зная значений токенов. Эта особенность вынужденная: в отличие от Wang, где многословные команды собираются из нескольких токенов вперемешку с обычным ASCII и границы видны по самому потоку, у Искры весь текст программы переведён в токены и поток непрозрачен.

Пример разбора

Строка 2000 файла #СТАТИСТ, длина 0x54 = 84:

20 00 54
23 01 23                          GOSUB ' 35
4C 39 E3 1F «БУДЕТЕ …» DD 00 DD E3 12 «-[1] ИЛИ ДВУМЯ [2]» DD
                                  PRINT "…";F¤;"…";
41 01 5C                          INPUT F%
36 03 5D D9 0E                    N7=N3
24 06 0E D7 11 D3 20 01           IF N3<N6THEN2001
36 03 5D D9 11                    N7=N6

Сумма: 3 + 59 + 3 + 5 + 8 + 5 = 83, плюс байт длины = 84.

Таблица токенов

Глаголы

Основной массив значений восстановлен из прошивки интерпретатора (алфавитный список ключевых слов по смещению 0x1840 и 51-байтовый массив перестановки по 0x19B6). Отмеченные записи проверены или исправлены сопоставлением токенизированной и текстовой версий одной программы.

Токен Оператор Примечание
21 GOTO подтверждено
22 GOSUB подтверждено
23 GOSUB' в прошивочной таблице пропуск; значение выведено из данных
24 IF подтверждено
25 KEYIN
26 ON
27 DEFFN'
28 PRINTUSING в опубликованной таблице ошибочно указан GOSUB'; исправлено по данным
29 DATA подтверждено
2A SAVE
2B RENUMBER
2C CLEAR
2D LOAD
2E LIST
2F RUN
35 LET
36 (присваивание без ключевого слова) подтверждено
40 $GIO
41 INPUT подтверждено
42 STOP
43 AND(
44 READ подтверждено
45 BOOL
46 DIM подтверждено
47 CONVERT
48 PACK(
4A ADD
4B BIN(
4C PRINT подтверждено
4D ROTATE
4E COM
50 HEXPRINT
52 NEXT подтверждено
53 REWIND
54 SELECT подтверждено
55 BACKSPACE
56 REM подтверждено
57 FOR подтверждено
58 SKIP
59 END
5A DEFFN
5C RES
5D UNPACK( подтверждено
5E RETURN
5F TRACE
61 OR(
62 XOR(
64 INIT
6D COPY
74 DATA LOAD DC выведено из данных
75 DATA LOAD DC OPEN T выведено из данных
79 DBACKSPACE
7A DSKIP
7B LIMITS
7E MOVE
81 SCRATCH
83 VERIFY

Значения назначены не по алфавиту, а тематическими группами с запасом внутри каждой: управление ходом выполнения в 0x21–0x2F, ввод-вывод около 0x41–0x4C, дисковые операции в 0x74–0x83. Составные дисковые команды получают один токен на всю фразу, тогда как в Wang та же команда собирается из нескольких (DATA + LOAD + DC).

Документация[1] описывает также операторы DATA SAVE DC END, DATA SAVE DC CLOSE и DATA LOAD DC OPEN. Последний соответствует найденному токену 75, поэтому остальные с высокой вероятностью занимают свободные значения в диапазоне 0x70–0x78 — при разборе новых файлов имеет смысл проверять этот участок в первую очередь.

Операнды

Токен Значение Достоверность
00~BF ссылка на переменную по индексу подтверждено
D0 ) вероятно
D1 TO подтверждено
D3 THEN, далее 2 байта BCD — номер строки подтверждено
D4 > вероятно
D7 < подтверждено
D9 = подтверждено
DB # подтверждено
DC / вероятно
DD ; подтверждено
DE , подтверждено
E0 ссылка на массив, далее индекс переменной подтверждено
DF TAB( подтверждено
E2 шестнадцатеричный литерал HEX(…): E2 <len> <len байт> подтверждено
E3 строковый литерал: E3 <len> <len байт КОИ-8> подтверждено
E7 числовая константа: E7 <2 байта BCD>, диапазон 0–9999 подтверждено
E8 числовая константа: E8 <байт BCD>, диапазон 0–99 подтверждено
E9 * вероятно
EA + вероятно
EB ( вероятно
FE разделитель записей строк подтверждено

Числовые константы кодируются двумя токенами в зависимости от величины: E8 — один байт BCD (0–99), E7 — два байта BCD (0–9999). Представление дробных констант в исследованных файлах не встретилось. Номер метки в GOSUB' хранится двоичным, а не в BCD.

Индексация массивов

У обращения к элементу массива нет открывающей скобки: ссылка на переменную сама открывает список индексов, а D0 его закрывает.

01 32 D0        →  01(32)
2A 03 E8 01 D0 D0  →  2A(03,1)

Токен EB используется только как группирующая скобка в выражениях:

EB 34 E9 33 E9 E8 01 D0  →  (34*33*1)

Разборщик, ожидающий EB перед индексом массива, рассинхронизируется.

Поток значений переменных

Секторы, следующие за программой в токенизированном файле, содержат значения переменных, записанные в том же формате, что и обычные файлы данных. Структура описана в документации[1].

Служебная информация в секторе двух видов:

  • идентификатор сектора — 1 байт в начале сектора, значение 02 (признак данных);[2] под данные остаются 255 байт;
  • идентификатор значения — 2 байта перед каждым значением, содержат тип (числовое или символьное) и длину.

Размеры значений:

Тип Значение Со служебными байтами Значений в секторе
целое 2 байта 4 байта 63
действительное 8 байт 10 байт 25
символьное длина значения длина + 2

Значение, не помещающееся в секторе целиком, переносится в следующий сектор полностью. Элементы массивов записываются построчно.

Пример

В файле DIG DEM сектор данных начинается с идентификатора сектора 02, за которым идут 25 записей по 10 байт:

00 08 <8 байт значения>

Идентификатор 00 08 означает числовое значение длиной 8 байт. Двадцать пятая запись заканчивается на пятом байте от конца сектора, оставшиеся 5 байт не используются: 1 + 25 × 10 + 5 = 256. Расчёт сходится точно и подтверждает однобайтовую длину идентификатора сектора.

Алгоритм разбора

  1. Прочитать запись каталога: первый и последний сектор, тип должен быть 80.
  2. Прочитать первый сектор: проверить байт 0 = 01, взять имя, прочитать байт 9.
  3. Если байт 9 = 20: склеить содержимое секторов, разбить по 85, отбросить нули, перекодировать КОИ-8. Готово.
  4. Если байт 9 = 21: собрать поток из секторов с байтом 1 = 80; прочитать L1, L2, L3; перейти к смещению 6 + L1 + L2 + L3.
  5. Для каждой записи: номер строки из двух байтов BCD, длина из третьего, тело до следующего FE. Если по отсчитанной длине не оказалось FE — поток рассинхронизирован, разбор остановить.
  6. Тело разрезать на операторы по схеме <глагол><len><операнды>.

Байт длины в каждой записи и в каждом операторе даёт бесплатную проверку целостности на каждом шаге.

Отличия от Wang 2200

Wang 2200 Искра-226
Запись каталога 16 байт совпадает побайтово
Маркер control record 20 1C
Маркер заголовка 40 (50 для защищённых) 01
Маркеры секторов битовое поле в старшей тетраде отдельные значения 02/8F/03
Конец строки в программе 0D 00 00 FE как разделитель
Конец блока FD (EOB) / FE (EOD) не используется
Диапазон токенов 0x80–0xFB, 124 значения глаголы 0x21–0x83, операнды 0xD0–0xEB
Текст в программе ключевые слова в токенах, остальное обычный ASCII всё в токенах, ASCII только внутри строковых литералов
Переменные имена в открытом виде индексы в таблицу
Длина оператора отсутствует обязательный байт после каждого глагола

Таблицы токенов не имеют между собой ничего общего: систематического сдвига нет, совпадений по отдельным байтам нет. Инструментарий Wang для детокенизации переиспользовать нельзя. Совпадает только уровень файловой системы.

Вероятная причина расхождения — кодировка. В Wang верхняя половина таблицы свободна и отдана под ключевые слова; у Искры она занята кириллицей, поэтому глаголы перенесены вниз, а от литерального ASCII в потоке отказались полностью.

Не установлено

  1. Имена переменных. Главное препятствие для читаемого листинга. Возможный путь — сопоставление токенизированной и текстовой версий одной программы, если обе сохранились на диске.
  2. Полная таблица токенов: часть значений в диапазонах 0x30–0x34, 0x37–0x3F, 0x65–0x78 не занята в известной таблице.
  3. Представление дробных числовых констант.
  4. Байты 2–7 записи таблицы 1 и байты 2–3 записей таблиц 2 и 3.
  5. Природа двухбайтового хвоста без префикса в конце каждого оператора DATA (C9 04, EE 04, 00 00 в ДЕМ6): в длину оператора он входит, но ни под E7, ни под E8 не подходит.
  6. Причина различия разметки секторов между токенизированными и текстовыми потоками: в текстовых файлах наблюдается позиционная схема 02/8F/03, в токенизированных все секторы программы идут с маркером 02.
  7. Токены операторов DATA SAVE DC END и DATA SAVE DC CLOSE.

Примечания

  1. 1,0 1,1 1,2 1,3 1,4 1,5 1,6 1,7 1,8 Баласанян В. Э., Богдюкевич С. В., Шахвердов В. А. Программирование на микроЭВМ «Искра 226». — М.: Финансы и статистика, 1987. — 264 с.: ил. — разделы 5.1, 5.2, 11.5, 18.1, 18.4, 18.7.
  2. 2,0 2,1 2,2 Аладьев В. З. и др. Персональный компьютер «Искра-226». Архитектура и программное обеспечение: справочное руководство. — Киев, 1988. — структура программного файла и файла данных, значения признака защиты.

Источники

  • Баласанян В. Э., Богдюкевич С. В., Шахвердов В. А. Программирование на микроЭВМ «Искра 226». — М.: Финансы и статистика, 1987. — 264 с.: ил.
  • Реконструкция по образам дисков: файлы TRANSFER, ФС (текстовые), DIG DEM, #СТАТИСТ, ДЕМ6 (токенизированные).
  • Таблица глаголов — из прошивки интерпретатора, по материалам проекта elaranovikova/iskra226.
  • Аладьев В. З. и др. Персональный компьютер «Искра-226». Архитектура и программное обеспечение: справочное руководство. — Киев, 1988.
  • Структура файловой системы Wang для сопоставления — Wang 2200 Disk Organization.