Мне видится следующее:
1. Проблемы с использованием сжатия вызваны тем, что драйвер распаковывает сжатые данные в момент поступления, поэтому при большом сжатии, большой скорости порта и медленном процессоре - "онлайновая" распаковка невозможна ( PDP-11/83 на скрости порта 9600 справляется без проблем ). Думаю, если разработать комбинированный "онлайн-офлайновый" алгоритм распаковки - максимальное сжатие в протоколе HX v2.0 можно будет увеличить с 256 до 65535.
2. Без использования сжатия - драйвер HX уже сейчас способен работать по двухпроводной линии без квитирования почти на любом процессоре и любой скорости порта. Максимальное количество байтов в секунду, которое может принимать драйвер зависит (конечно же) от скорости процессора и типа операционки ( при поддержке очереди таймера в ядре RT-11 - максимальная продолжительность критического цикла драйвера, выполняемого при получении каждого байта данных - увеличивается на добрую сотню команд ). Для точного определения максимальной скорости RAW-обмена в HX, в зависимости от используемого процессора и операционки - есть смысл написать тестовую программу HXTST.SAV.
3. Для начальной загрузки с HX0 можно сделать специализированную разновидность Boot-блока HX - BotHX0.bin, при передаче которого в УКНЦ - UKNCcomSender будет впечатывать в него дату и время сервера в формате RT-11 для установки в процессе загрузки.
4. Если научить UKNCcomSender реагировать на произвольно задаваемый промпт, то возможно его совместное использование с ODT_Loader для установки времени сервера в RT-11 при загрузке с HX0 ( при помощи BotHX0.bin ) на ДВК / PDP-11 ( и других компьютерах с Micro-ODT ).
5. В протоколе HX v1.1 не поддерживается формирование ( на стороне сервера ) и использование ( на стороне драйвера ) признака конца файла при операциях вблизи и за пределами границы образа. Исправить это можно и нужно в протоколе HX v2.0.
Ответить с цитированием