Цитата Сообщение от Error404 Посмотреть сообщение
Будет ли Монитор иметь константы в ОЗУ, описывающие геометрию экрана (как в Орионе) - на Орионе это позволяло уменьшать "область экрана драйвера" (вводить служебные строки, не попадающие под CLS и т.п.)?
Обязательно.
Цитата Сообщение от Error404 Посмотреть сообщение
Я правильно понял, будешь идти по возможности близко к стандартам VT-52?
Получается так. Очень полезная информация.
Цитата Сообщение от Error404 Посмотреть сообщение
Будут ли векторизированы в ОЗУ подпрограммы Монитора, адрес фонта в некоторой ячейке и т.д.? Это даст подключать пользовательские драйвера и фонты... Например для CР/M 64х25 - это мало, неудобно. Надо 80х25, т.е. по любому в CP/М придется подгружаемый драйвер иметь.
Обязательно, причем по стандартным адресам. Например, режим совместимости КОИ7 + задаваемый адрес фонтогенератора позволит запустить ED^7000 без каких-либо проблем.

Самая громоздкая часть предполагается быть в ПЗУ, а в ОЗУ в стандартном месте загрузчика будет шлюз перехода. Но тем не менее, мы имеем еще 10КБ ОЗУ (за исключением 2КБ области загрузчика), так что места для драйверов хватит. Единственное, о чем я еще пока думаю, это правильное планирование этой HMA. Логично, закинуть ячейки вверх, а пользователю оставить непрерывный блок 0000-8FFF, без дырок. Но так же логично оставить ячейки в 8Fxx (для совместимости в том числе), а чтото системное подгружать в HMA (например ED^7000 работает в 7000 :3, на орионе я его переносил в А000 и даже прикручивал к ORDOS, заменив подпрограммы работы с мафоном на процедурки работы с диском В, а тут мы его можем загрузить, скажем, с D400, как у МХа, оставив тексту места вплоть до 8EFF). Поэтому, нужно будет обсудить данный момент.
Так же, нужно проанализировать все часто используемые ESC последовательности терминала и редко используемые (или не применимые в рамках Спеца) заменить на нужные отсутствующие.