Большинство старых компьютеров имеют в своём составе последовательный порт, поэтому имитатор блочного устройства ( диска с секторами по 512 байт ) с последовательным интерфейсом - часто может быть использован с ними для загрузки программ.
При разработке протокола HX преследовались две основные цели:
1. Передача блочного обмена по последовательному каналу.
2. Передача терминального обмена по тому же самому каналу.
В результате появилась технология, позволяющая использовать последовательный порт не только для загрузки программ, но также и для загрузки операционной системы и даже для загрузки операционной системы через порт её системного терминала.
...
В своём развитии протокол HX прошёл следующие этапы:
HX v1.1 - добавлена поддержка сжатия при чтении.
HX v2.0 - порядок байтов при передаче слов заголовков и контрольных сумм приведён в соответствие с порядком байтов при передаче данных ( little-endian ), 16-битный номер блока заменён на 32-битный, счётчик слов в операциях чтения и записи заменён на счётчик байтов.
HX v2.1 - сервер при записи перестал дополнять неполные блоки нулями (на диск пишется ровно столько байтов, сколько было передано). При запросе чтения, переходящем через размер образа диска, смонтированный в приводе - возвращаются только реально прочитанные байты. При запросе записи, переходящем через размер образа - пишутся только "умещающиеся" байты и возвращается признак конца файла.
HX v2.2 - в протоколе появилась поддержка указания желательного типа сжатия в запросах чтения сжатых данных.
HX v2.3 - добавлена поддержка команды TU58 "передать загрузчик для привода 0". Теперь, после получения байтов "\x04\x08\x00" - сервер передаст первые 512 байтов образа, подключенного к нулевому приводу.
HX v2.4 - добавлена поддержка спецкоманд. Добавлены спецкоманды: EcHo, BrEaK, VeR.
...
В архитектуре протокола HX реализованы следующие основные идеи:
1. Сервер только отвечает на запросы клиента.
2. Клиент никогда не отвечает на ответы сервера.
3. Вся информация, необходимая для контроля версий, содержится в каждом запросе клиента.
4. Все версии протокола, начиная с 2.1 - обратно совместимы ( клиент, поддерживающий HX v2.1 - сможет работать с любой последующей версией сервера ).
5. Сервер (в общем случае) является фильтром, вырезающим из потока байтов пакеты блочного обмена и пропускающим терминальный обмен без изменений. Все принимаемые сервером байты запроса клиента сохраняются и в случае ошибочного опознавания запроса там, где его не было - возвращаются в терминальный обмен. В некоторых реализациях данное требование может не соблюдаться.
...
Протокол HX имеет следующую структуру:
1. Весь обмен осуществляется в виде пакетов.
2. Все пакеты (кроме спецпакета №1 и спецпакета №2) имеют контрольную сумму. Контрольная сумма передаётся в двух последних байтах пакета.
3. Пакеты могут быть трёх основных типов:
--- 1) Короткий пакет с заголовком, начинающимся с байта длины пакета. Короткий пакет c нулевым байтом длины - это спецпакет №1.
--- 2) Длинный пакет с заголовком, начинающимся с двух байтов длины пакета. Длинный пакет с двумя нулевыми байтами длины - это спецпакет №2.
--- 3) Упакованный поток - не имеет заголовка. Структура упакованного потока зависит от используемого типа сжатия.
4. Запрос клиента начинается байтом SOH. Значение байта SOH зависит от покления запрашиваемого протокола HX. Для протокола поколения 2 - это байт 01.
5. Второй байт запроса клиента - байт типа пакета. Клиент посылает три типа пакетов:
--- 1) Короткий пакет, начинающийся с байта 0375.
--- 2) Длинный пакет, начинающийся с байта 0376.
--- 3) Спецкоманда, начинающаяся с байта 0373.
6. После байта типа пакета и одного или двух байтов длины пакета располагается тело пакета, завершаемое контрольной суммой. Контрольная сумма считается 16-разрядным суммированием байтов пакета между длиной и контрольной суммой ( не включая ни длину, ни контрольную сумму ). Спецкоманды не оформлены в пакеты и получают от сервера специальные ответы.
7. Первый байт тела запроса клиента определяет вид пакета. В HX 2.2 есть только один вид запроса клиента - команда ( байт вида пакета 'C' ).
8. Следующий байт после C задаёт команду клиента.
Для коротких пакетов это:
--- 1) R - чтение несжатых данных.
--- 2) r - чтение сжатых данных.
--- 3) s - запрос размера диска.
Для длинных пакетов это:
--- 1) W - запись несжатых данных.
9. Затем передаётся байт номера привода и, для запросов чтения и записи - 4 байта номера блока и 2 байта счётчика байтов.
Читать и писать лучше всего кусками, кратными размеру блока ( 512 байт ). Однако, возможно и чтение, и запись любого количества байтов ( от 1 до 65525 ) от начала любого блока.
10. После получения от клиента спецкоманды EcHo - сервер будет возвращать клиенту все получаемые от него байты, включая завершающий нулевой байт.
11. После получения от клиента спецкоманды BrEaK - сервер отправит клиенту сигнал BREAK.
12. После получения от клиента спецкоманды VeR - сервер отправит клиенту два байта версии и ревизии протокола ( сейчас это: 002 ; 004 ).
Что происходит дальше словами описать трудно, поэтому в приложении находится исходный текст ( на С++ ) фильтра HX v2.2 и исходный текст ( на MACRO-11 ) драйвера HX.SYS для RT-11.
...