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

[Denn]

Вот потому-то монитор-3 по всем позициям всегда лучше.

ROM-диск в М3 определяется по наличию байта C3 в ROM-диске по адресу 7FD

И чем это "лучше"?

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

Как раз наоборот, алгоритм проверки первых двух байтов на различия весьма удачный. В случае отсутствия ПЗУ мы читаем "00 00", в случае пустой ПЗУ - "FF FF", в случае физического отсутствия порта ROM-диска читаем два одинаковых байта "мусора", и только в случае осмысленных данных производим загрузку. Т.е. фактически корректно обрабатываем все реальные ситуации.

- - - Добавлено - - -

...и риссовать рамки псевдографикой нельзя (оттого их при М2 всегда рисуют внаглую).

В Мониторе изначально нет псевдографики в принципе. Да и рисовать графику (в т.ч. рамки) с помощью тормозного 6-пиксельного драйвера - это издевательство над трудящимися
В любом случае отрисовку графики делают мимо п/п Монитора.

[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-корпуса.

[Denn]

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

Актуально на машинах с быстрым (аппаратным) выводом символов. Но не на Орионе.

А если кому-то не хватает скорости, есть Z80. Да и при наличии желания легко турбировать КР580 в ОРИОНЕ до 3 МГЦ

На 10 МГц Ориона-ПРО 6-битный вывод символов тормозной.

Несостоятельный довод. ПЗУ F800 устроено так, что по сбросу читает из ROM-диска именно 2К и делает JMP на BFFD

Да, действительно, я уже забыл про эту "фишку" с запуском через "верхушку".

[Error404]

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

Отвечая только за себе - не особенно интересно. Т.к. всегда чего-то не хватит, и надо будет расширять какие-нибудь функции присадкой на вектора ROM-bios. А раз так, то не лучше ли сразу иметь загружаемый в ОЗУ драйвер, который как минимум не нуждается в перепрошивке ПЗУ при его модификации. Собственно поэтому всегда использовал только минимальное ПЗУ с загрузчиком, остальное грузил с носителя.

Есть небольшая ниша для расширенного ROM-биос в моих нуждах - если надумаю делать версию UZIX стартующую "на голом Орионе", а не из под CP/M, и тогда можно использовать подпрограммы из ROM. Но опять же, консольного ввода и вывода хватит уже того что был в М3, а 80х25 там все равно не будет (т.к. это надо использовать экраны в начале ОЗУ). Оконные функции тоже врядли нужны - Uzix или CP/M про них не в курсе и не используют, а приложение должно работать через ядро ОС (и поэтому содержать оконный код в себе) чтобы быть совместимым кросс-платформенно.

Хорошая иллюстрация - ОрионПРО, где всяких функций в РОМ-БИОС имеется предостаточно, но ими не пользуется никто.

[barsik]

Есть ли у оставшихся пользователей ОРИОНА интерес к резкому улучшению ROM-BIOS ОРИОНА?

Отвечая только за себе - не особенно интересно

Вам не интересно, потому что Вы не фанат ORDOS и не используете других ДОС в банке 0. А в системах, что работают не в банке 0, проблем с качественным и удобным драйвером нет, для загрузки драйверов есть целая банка 0 (за вычетом экрана).

А пользователям ORDOS и других ДОС в банке 0 всё это недоступно, отчего они и вынуждены пользоваться только "родным" убогим драйвером из ROM-BIOS, который вообще ничего не умеет, кроме как выводить символы КОИ-7 с вертикальным разрывом в 2 линии, отчего не может рисовать даже псевдографику (не говоря уж о том, чтобы открывать-закрывать окна и двигать спрайты). Благодаря убогости ROM-BIOS, ОРИОН с точки зрения программирования для банки 0, фактически низведён до цветного РК86 с сменяемым шрифтом.

А программ для ОРИОН-ПРО с использованием его возможностей не писали потому что программисты для ОРИОНА просто не "пережили" переход на ОРИОН-ПРО. Все программисты ненавидят возиться с железом (т.к программирование намного интереснее). Поэтому все знакомые мне программисты предпочли уйти с ОРИОНА, чем "трахаться" много лет с его сборкой и настройкой. Да и настроить ОРИОН-ПРО из тысяч сумели единицы.

не лучше ли сразу иметь загружаемый в ОЗУ драйвер, который как минимум не нуждается в перепрошивке ПЗУ при его модификации

В этом-то и проблема. Куда в ORDOS или другой ДОС для банки 0 загрузить драйвер 12 кб являющийся расширением ROM-BIOS? Ведь в этой же самой банке экран, ДОС в 12 кб и если сюда мы загружаем оконный драйвер в 12 кб, то за вычетом кода программы у нас остаётся под дисковый буфер (нортона или редактора) ОЗУ с "гулькин нос", а ведь надо ещё найти место для большого буфера сохранения окон (для комфорта надо примерно 20 кб).

Кроме того драйвер в той же банке, где сама ДОС невозможен вот почему. Понятно, что разместить в ОЗУ банки 0 драйвер в 32К, содержащий драйвера всех шрифтов, графические подпрограммы и функции ROM-BIOS для работы с винтом, флопоми SD-картой не получится. Значит, остаётся иметь отдельные драйвера для каждого шрифта, а графику и поддержку винта и флопа откинем (пусть программист мучается и пишет это сам).

Итак, имеются драйвера всех шрифтов с размером от 2 кб до 12 кб. Если ДОС грузить на 12 кб ниже экрана, то в зарезервированное место мы сможем загрузить любой драйвер. Но уровень TPA фатально упадёт на 12К. Причём при загрузке драйвера в 2К, 10 кб в резервированном месте будут пропадать впустую. Если же я смогу переместить все драйверы в ROM-BIOS, то получу максимально высокий уровень TPA. А в концепции ORDOS вообще драйвера в 12 кб не предусмотрены.

Так что Ваш довод несостоятелен. Для ДОС ОРИОНА в банке 0 необходим хороший ROM-BIOS, иначе кроме программ уровня VC$ ничего сделать нельзя.

Интересно, хоть в каком-то новоделе ОРИОНА догадались поставить побольше ПЗУ?

[Error404]

Интересно, хоть в каком-то новоделе ОРИОНА догадались поставить побольше ПЗУ?

Так в Орионе ПРО и есть. Там целых два ПЗУ, в двух окнах памяти, первое 8к, второе - до двух мегабайт (я использую одномегабайтную 27c080).

[OrionExt]

barsik, мое мнение. Для меня достаточно М1 для наладки, М2 для работы. Я бы и М3 не использовал, если бы к нему небыли привязаны некоторые программы. Объем ПЗУ слишком мал для серьезных и объемных подпрограмм и драйверов. Пусть такие, как есть и остаются.

А вот подумать над расширяемым БИОС-ом стоит. Вот, допустим, прикрутили новую железку. Написали одну программу для этой железки. И все. А был бы с этой железкой БИОС глядишь, кто ни будь еще эту железку использовал в своем софте. Хотя бы ради спортивного интереса.

Как то уныло переписывать драйвер ВГ93 сотый раз

- - - Добавлено - - -

Как я тут писал, монитор кроме как для бутлоадера по сегодняшним меркам и не на что не годится.

[Denn]

М2 достаточно для загрузки с ROM-диска, а более и не нужно, ибо в первую очередь мониторный 6-битный вывод неюзабелен, имхо. К тому же с М2 работает всё классическое РК86/ОРДОС-наследие.
Все программные расширения прекрасно вычитываются из ром-диска и как правило запихиваются во вторую страницу, и хранить их в виде БИОС-ПЗУ практического смысла нет.

Максимум чего полезного можно было бы сотворить с монитором - это сделать "унисекс" поддержку клавиатур, имхо.

[OrionExt]

Максимум чего полезного можно было бы сотворить с монитором - это сделать "унисекс" поддержку клавиатур, имхо.

Вот интересно как "унисексить" клавы с 2048 байтами

- - - Добавлено - - -

МС клава - очень редкая. Еще от Корвета в то время подключали. Я вот бы от MSX клаву подключил бы. Клава весом 1/3 от всего компа – вечная!

[barsik]

Интересно, хоть в каком-то новоделе ОРИОНА догадались поставить побольше ПЗУ?

Так в Орионе ПРО и есть. Там целых два ПЗУ, в двух окнах памяти

Заметим, что ОРИОН-ПРО это не заслуга никого из присутствующих и отнюдь не новодел. Точнее новодел 1993 года, хотя одновременно и долгострой до 1998. Значит во всех платах новоделов ОРИОН-128 так и оставили 2 кб. Это ошибка. Ну хотя-бы второе ПЗУ РФ2 могли бы предусмотреть.

Что фанаты ORDOS перевелись? А что DS-DOS тоже не имеет драйверов и обходится, как и VC$ подпрограммами из ПЗУ? Кажется только А.Вакуленко и ещё тульские аделаидчики поняли, что шрифт 8*8 лучще, чем 6*8 и использовали драйвер. Оттого у них и получились нормальные программы. А те, кто ориентировался на убогий драйвер из ПЗУ смогли сделать только неинтересные программы в интерфейсе РК86.

Мне казалось, что каждый программист заинтересован в хорошем ROM-BIOS. Но вероятнее, просто никто не хочет больше программировать для ОРИОНА, оттого всем и плевать. Печально.

А мне не плевать. Так что, сделаю себе ROM-BIOS в расширенном ПЗУ, включаемом в окне 0...7FFF. Железо у меня уже сделано, правда не ПЗУ, а ОЗУ 0...7FFF на 62256, включаемом битом D7 порта FC. Осталось чуть переделать схему и странслировать туда для начала просто драйвер D8, размером в 11 кб. Собственно роль такого ПЗУ может играть и ОЗУ банки 1. И если подумать о схеме, как это сделать, то получится что-то очень похожее на Z80CARD-I из 1991, где тоже в области 0...7FFF можно было включить другое ОЗУ. Эта концепция и предполагалась для решения проблемы драйверов. А Z80CARD-II решала иную проблему.

Но я попробую и другую идею, пришедшую в голову сегодня, что не требует аппаратных изменений. Это сделать тормозной драйвер работающий в банке 1. Если драйвер в банке 0 кидал в область F000...F3FF подпрограммы раскраски, то теперь придётся иметь на F000 подпрограммы вывода графики, хотя фонт остаётся в банке 1. Такой драйвер будет тормознее, но не более чем на 20%. Интересно только на сколько разбухнет Z80 код в 10-12 кб, если его перевести на КР580. По счастью я не увлекаюсь индексными регистрами, поэтому перевод на КР580 возможен, хотя как показал опыт это довольно утомительное дело.

Кстати, была ещё одна идея аппаратной доработки, хоть и менее победительная, чем "перекорёживатель". Это иметь бит, который меняет экранные плоскости местами (инверсия на ЛП5 выборки банки при попадании в экран), что позволяло бы работать с обоими плоскостями как из банки 0, так и из банки 1 без использования некоммутируемого ОЗУ F000.

МС-7007 клава - очень редкая

Не согласен. Их сделали тысячи, очевидно для наборов для сборки РК86 РК-03 (они также стояли и в других промышленных ЭВМ). И оказалось сделали много лишних. Они целый год в 1991 продавались в магазине "Юный техник" и довольно недорого. Я купил 3 штуки. И пользовался ими на ОРИОНЕ до 1996. Когда понял, что эргономика у них хреновая. Слишком маленький ход клавиш и нет фиксации при нажатии. Но всё же это было лучшее, что было в 1991, т.к альтернативой была РК-клавиатура на кнопках МП16.

Ещё клавиатуру КОРВЕТА подключали

Да. С.Корокин сделал такое ПЗУ М2 и пропагандировал это в 1993. Я тоже возможно так сделаю, т.к имею неиспользуемую герконовую клавиатуру от КОРВЕТА.

Я вот бы от MSX клаву подключил бы

И какая же в ней матрица? А вот я пытался подключить дохлую IBM PC клавиатуру к ОРИОНУ. Но как понял, токопроводящая резина слишком высокоомна для ВВ55.

Как то уныло переписывать драйвер ВГ93 в сотый раз

Вооюще-то это не проблема. Я транслировал CP/M явно больше тысячи раз и даже не вникал, как эти подпрограммы работают. У меня есть include-файл FLOP.INC (есть также файл RKFLOP.INC и VINT.INC). И я в него не заглядывал с 1991 года (а зачем, если работает). Так что какая трудность в "переписывании" кода ВГ93? Какой INCLUDE модуль вместе с ДОС транслируется, такое железо в ДОС и получается. Так что у меня есть аналоги всех ДОС ОРИОНА для винта и для РК-КНГМД.

Для подъёма уровня TPA, в ROM-BIOS полезно, как и в IBM PC иметь подпрограммы чтения и записи сектора и подпрограмму форматирования дорожки. Для РК-КНГМД я так и делал и эти две п/п-ммы умешались в моё второе ПЗУ РФ2. Правда это было мне невыгодно, т.к у меня было много форматов (разное число секторов на треке для 3-х типов дисков и дисководов и ещё CP/M и РК-ДОС) и ПЗУ для этого использовать стало невыгодно, так что сейчас я храню во втором РФ2 просто кусок фонта (весь фонт 8*10 имеет размер в A00 и в РФ2 не влезает), что увеличивает TPA на те же 2К.

Вот интересно как "унисексить" клавы с 2048 байтами

Если имеется ввиду уместить драйвер MS и драйвер РК в одно ПЗУ, то раньше это действительно было абсолютно невозможно, но недавно я освободил в ПЗУ М2 ~300 байтов и теперь всё-же возможны кое-какие варианты.

Драйвер РК-клавиатуры 318 байтов. Драйвер MS-7007 422 байта, а есть лишь менее 300. Однако, часть кода одного драйвера есть и в другом, так что реально надо смотреть и пробовать. Может быть что-то и получится. Но придётся выкинуть МГ-подпрограммы и вообще всё, что возможно.

Желательна процедура автоматической настройки на тип клавиатуры. Надо придумать какой-то признак, чтобы ПЗУ могло узнавать какой драйвер подключать.