Орион-128: Разное

[barsik]

В любом случае отрисовку графики делают мимо п/п Монитора

Правильнее сказать мимо стандартных входов ROM-BIOS. Так делают только авторы ОРИОНА и их последователи, не понимающие, что п/п-ммы ПЗУ слишком убогие и не могут выполнять роль основного драйвера. Что вызвано фатальной ошибкой разработчиков, не понявших, что нужно ПЗУ более 2К, чтобы иметь хороший ROM-BIOS, что в значительной степени определяет качество машины.

На вектора ПЗУ загружаются драйверы разных шрифтов. И в них нет разрыва в 2 линии в графике фонта (почти как в РК86, но там это хоть имеет аппаратные причины, здесь же просто глупость). И в фонтах даже самых мизерных драйверов 4*8 и 5*10, и то есть псевдографика и она сплошная.

Кстати даже с фонтом с шагом в 8 байтов и знакоместе с высотой в 10 линий, выводится сплошная графика по вертикали. Используется принцип как в IBM PC в VGA, когда включён аппаратный фонт 9*14, а реальный фонт имеет размер 8*14. Тогда адаптер VGA повторяет в 9-й колонке содержимое 8-й колонки. Т.к в буквах 8-я колонка это межбуквенный интервал, то на буквы и цифры это не влияет, но псевдографику сохраняет сплошной. Точно также и здесь, только не по горизонтали, а по вертикали (не знаю понял ли кто-то, но не в этом суть).

В нормальных цветных оконных драйверах, когда открывается окно, рамочки там всегда чертятся псевдографикой. И так это на всех компьютерах в мире. И в моих драйверах есть функция окрытия окна, которая выполняется так. Сначала меняются оконные параметры. Затем содержимое нового окна сливается в буфер (буфер работает по принципу: последний зашёл первый вышел, что даёт возможность открывать море перекрывающихся окон и всё восстанавливать, причём в цвете). Затем окно очищается, раскрашивается, рисуется двойная рамка, на которой пишется заголовок окна. И всё это делает только один искейп-код (закрывает окно также один ESC-код), отчего писать программы при наличии оконного драйвера совсем просто. Не надо "шариться" по экрану отсчитывая адреса и рисуя там что-то внаглую (а для имитации закрытия единственного возможного окна, перерисовывая весь экран). И программа, например НОРТОН написанная для шрифта 6*10 годится и при других шрифтах и даже для машины с текстовым адаптером. Вот так устроены грамотные программы.

Вот стандартные ячейки оконности введённые в мониторе-2. Именно их используют все оконные драйверы, начиная с исторически первого драйвера для ОРИОНА В.Ивинских. К сожалению, те кто писал другие драйверы (кроме меня) никогда не дизассемблировали ROM-BIOS ОРИОНА, а авторы ОРИОНА, придумав это, до использования окон так и не добрались, что странно. ПЗУ оконность поддерживает, но программы не используют (возможно ушёл тот, кто это придумал). Именно оконностью, М2 кардинально отличается от М1.

.
HISCRN	EQU	0F3CFH	; НАЧАЛЬНЫЙ АДРЕС ОКНА (high byte)
WDTSCR	EQU	0F3D0H	; ШИРИНА ОКНА В БАЙТАХ
FRSTLN	EQU	0F3D4H	; N ПЕРВОЙ СТРОКИ ОКНА
SCHIGH	EQU	0F3D5H	; КОЛИЧЕСТВО СТРОК ОКНА

А если кому-то не хватает скорости, есть Z80. Да и при наличии желания легко турбировать КР580 в ОРИОНЕ до 3 МГЦ, причём при исправлении плющености экрана ОРИОНА. Как раз ставлю сейчас КР580 в ОРИОН (была собранная резервированная плата ОРИОНА, где всё запаяно ещё в 1994, она предназначалось для установки 8088, да так руки и не дошли), чтобы реализовать именно такую доработку ОРИОНА.

Допустим я хочу поставить свой загрузчик, который не ОРДОС, а что-то своё. Зачем мне в 07FDh лепить С3h ?

Несостоятельный довод. ПЗУ F800 устроено так, что по сбросу читает из ROM-диска именно 2К и делает JMP на BFFD. Т.е у Вас только 3 байта. Какую иную команду кроме JMP, вы можете туда поставить, чтобы не потерять управление? Так что на 7FD в ROM-диске всегда стоит C3. К монитору-3, Вы не подкопаетесь. Нет ничего в М2, что там было бы сделано лучше, чем в М3, т.к его делал грамотный программист.

Хотелось бы улучшить качество ROM-BIOS ОРИОНА

К сожалению, фатальные аппаратные ошибки при разработке ОРИОНА, не позволяют как-то существенно улучшить качество ROM-BIOS. В имеющиеся 2 кб ПЗУ, освободив в нём ~300 ячеек ничего путного не уместить. Хотелось бы иметь 12 кб, ну хотя-бы 8 кб. Но увы.

Что-то улучшить без аппаратных доработок нельзя. Самый простой и лобовой вариант, это напайка второго этажа РФ2, дающая дополнительные 2 кб. Конечно и это позволило бы как-то улучшить драйвер вывода, но не кардинально. Есть и ещё вариант, для бедных. Это "открытие" под-ПЗУ-шечного ОЗУ. Тогда ПЗУ отключается и становится нечитаемым, а вместо этого оказывается недоступное ранее ОЗУ текущей банки. При Z80 это не проблема, а при КР580 надо иметь какой-то порт управления (т.к системные регистры F800, F900, FA00, FB00 отключаются).

То, что под-ПЗУ-шечное ОЗУ по адресам F800, F8F8, F900, F9F9, FA00, FAFA портится при работе программ, не проблема (это легко учесть программно или даже сделать доработку по защите от записи). Расход деталей в варианте 1: РФ2, ТМ9, ЛА3. А в варианте для бедных - 2-3 корпуса логики (сам это я делал лишь на Z80, а на КР580 пока такой схемы нет).

Задаю вопрос. Есть ли у оставшихся пользователей ОРИОНА интерес к резкому улучшению ROM-BIOS ОРИОНА, что неминуемо требует расширения ПЗУ? Качественный ROM-BIOS резко упрощает разработку программ, при таком же резком повышении их качества и делает возможным даже новичкам в программировании делать красивые графические программы.

Есть ещё один вариант улучшения ROM-BIOS для программ в банке 0 (т.е для ORDOS и CPM-48К). Это придуманная прямо сейчас, идея оверлейного ROM-BIOS с размещением оверлеев, т.е драйверов экрана в банке 1. Никто этого ранее не делал, но это ненамного сложнее и немного тормознее. Это хорошая идея и она мне пригодится для ДОС в банке 0, т.к там мне фатально нехватает места для драйверов (~10 кб) и кода ДОС (~10 кб).

Ой... раз уж речь о аппаратных доработках, чуть не забыл ! Свою давнюю идею "перекорёживателя ОРИОНА", что вполне решает проблему ROM-BIOS. Суть работы перекорёживателя в том, что он перемещает плоскость графики в банку 1. Когда экран включён с C000 то всё как и ранее. Но если экран с 8000, то в банке 0 всё ОЗУ доступно программам, а в банке 1 на 8000 - плоскость цвета, а на 0000 - плоскость графики. Понятно, что при этом квазидиску B - кранты. Зато CPM-48К в банке 0 может работать на все 60К. ROM-BIOS грузится с ROM-диска. А ORDOS я могу переделать так, что диск B будет читаться из банки 2, а не 1 и так далее. Так что фантаты ORDOS не пострадают. Расход деталей 3 дешёвых TTL-корпуса.