ПЭВМ "ИРИША"

[perestoronin]

Все сообщения о программах для ИРИШИ перенесены в новую тему "Программы для ИРИШИ".
Далее обсуждения о программах для ИРИШИ, в том числе и о перспективных программах и доработках самой ИРИШИ прошу вести в новой теме "Программы для ИРИШИ".

[Advertiser]

[barsik]

Графический адаптер ИРИШИ в режиме 2 (color-40) реализует "один в один" цветной режим CGA, полноценную поточечную графику 320 на 200 с 4-мя цветами. Почти все остальные отечественные бытовые 8-ми разрядки имеют цвет или сразу на всё знакоместо или байтовую организацию, когда цвет задаётся на все 8 соседних пикселей. Таким образом по графике ИРИША изначально лучше большинства бытовых 8-ми разрядок.

Для текстовых программ поточечная графика не нужна, а нужно большее число цветов. Можно было бы установить вторую банку РУ5-тых и кардинально изменив схему видеовыхода, получить 16 цветов на каждый пиксель. Но это не реализуемо, это не сделать вручную за час труда.

Есть простой способ увеличить число цветов с 4 до 8. Для этого на одну из РУ5-тых напаивается вторая РУ5-тая. Все ноги в параллель, кроме входа и выхода. Тогда эта РУ5-тая будет читаться и писаться синхронно с основным ОЗУ, обеспечивая на своём выходе дополнительный бит управления цветом.

Теоретически можно включить эту РУ5-тую в доп.банку ОЗУ. Переключается сразу вся банка 64К. Но увы, в однобитовом ОЗУ программы работают очень плохо, т.к КР580 не одноразрядный, а 8-ми разрядный.

Поэтому используется идея СПЕЦИАЛИСТА. Когда в ОЗУ цвета информация заносится автоматически и синхронно с записью в ОЗУ графики, переписываясь из внешнего регистра цвета. Это имеет преимуществом скорость. Скорость вывода в цвете такая же как скорость вывода без цвета. А например, в ОРИОНЕ скорость вывода в цвете фатально падает. Цвет СПЕЦИАЛИСТА наиболее разумный для бытовых 8-ми разрядок. Автор СПЕЦИАЛИСТА и в этом оказался умнее других авторов БК.

В качестве однобитового регистра используем ТМ2 (хотя можно просто "кинуть проволоку" от одного из ненужных битов ППА). Запись в ТМ2 будем выполнять используя имеющуюся на плате граф.адаптера выборку порта 0DBH. А второй триггер из ТМ2 используем как защелку выходных данных, куда запись происходит одновременно с записью в регистр видеовыхода.

Грамотно было бы использовать этот бит для переключения палитр, тогда можно было бы выбирать любые цвета. В ИРИШЕ в цветном режиме есть две палитры. Можно переключать их этим битом. Но пока я не могу разобраться в схеме граф.адаптера и понять как выбор палитры управляется.

Но для простоты можно управлять яркостью цветов. Единица считанная из РУ5-той будет снижать уровень сигналов R,G,B на видеовыходе (как в схеме видео выхода в зоновской плате СИНКЛЕРА).

Это не полноценные 8 цветов, т.к меняется цвет сразу всех 4 цветных точек, определяемых экранным байтом. Но это уже лучше, чем всего 4 цвета. И важно, что это нам обойдется всего в минимальный расход деталей и затрату времени в час труда. Дискретность в 4 точки, но этого достаточно для текстовых программ (и намного лучше, чем дискретность в 8 точек остальных 8-ми разрядок).

Это лишь непроверенная на практике идея. Пока не особо и актуальная. Но я не вижу препятствий для её использования. И саму идею можно доработать. Например, в монохромном режиме можно использовать доп.бит для организации мигания. Снижение яркости можно использовать для маркировке в цвете и для вывода теней от панелей.

[Error404]

Для текстовых программ поточечная графика не нужна, а нужно большее число цветов.

Работая на Орионе только в тестовых режимах, я бы сказал что важнее разрешающая способность. Для текста Ирише нужны 640х200, пофиг со сколькими цветами (лишь бы не вырвиглазными).

Поэтому используется идея СПЕЦИАЛИСТА. Когда в ОЗУ цвета информация заносится автоматически и синхронно с записью в ОЗУ графики, переписываясь из внешнего регистра цвета. Это имеет преимуществом скорость. Скорость вывода в цвете такая же как скорость вывода без цвета. А например, в ОРИОНЕ скорость вывода в цвете фатально падает. Цвет СПЕЦИАЛИСТА наиболее разумный для бытовых 8-ми разрядок. Автор СПЕЦИАЛИСТА и в этом оказался умнее других авторов БК.

Думаю, целью автора Специалиста было прикрутить цвет малой кровью - малым внедрением в основную схему и малым количеством корпусов. Если речь идет про тот вариант на трех РУ3, который я в прошлом столетии мельком видел в Моделист-конструкторе.
Я не программировал под Спец. Имеется ли произвольный доступ к видео ОЗУ на запись/чтение? Или доступ только из регистра при выводе в основное видео ОЗУ? Если произвольного доступа нет, то задачка скроллинга части экрана (в любую сторону), где в этой части присутствует окраска фрагментов в разные цвета, представляется задачкой из серии "убил бы автора той схемы" (либо разъедутся атрибуты и фон, либо надо перевыводить на экран заново весь блок по новым координатом, что намного медленнее, чем копирнуть в памяти массив байт). А если произвольный доступ и есть, скроллинг опять же будет не быстрее Орионовского.

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

А ведь скроллинг задача не гипотетическая, а как раз таки наипервейшая для тестообработки. Именно на медленном скроллинге особенно заметно что комп ворочает бОльшим количеством пикселей чем сосед.

[barsik]

ИРИША в цвете может выводить только на CGA, т.е 320x200 в 4-х цветах (из 2-х палитр). А 640x200 - монохром, без цвета, точнее общий цвет на весь экран. Речь только о цветном режиме 2 (color-40).

В волковской идее не принципиально сколько цветов (т.е сколько битов в регистре). Были схемы с 4-мя цветами и с 8-ю цветами (что ты видел в журнале МК), где цвет задаётся только для цвета символов (цвет фона, т.е цвет битов 0 в видео-байте - всегда черный). Были схемы где 8 цветов для фона и 8 цветов для символов. И то же самое для 16-ти цветов. Это не принципиально (сколько РУ5-тых напаял вторым этажом - столько битов для цвета и имеешь).

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

Но это вообще не проблема. Ролик нужен только в одноцветных окнах. Там нет кусков в разных цветах. Например в текстовом редакторе, в окне прокрутки для выбора файла и т.п. Вокруг окна, что делает ролик могут быть другие цвета, но само окно где ролик одноцветное. И даже трудно представить программу для 8-ми разрядки, где нужен полноценный цветной ролик. Поэтому твой довод о преимуществах полноценного цветного ролика, считай, "разгромлен в пух и прах". На порядок важнее, чем цветной ролик - скорость вывода. Поэтому автор СПЕЦИАЛИСТА был абсолютно прав, выбрав цвет с автозаписью из регистра цвета.

[Error404]

ИРИША в цвете может выводить только на CGA, т.е 320x200 в 4-х цветах (из 2-х палитр). А 640x200 - монохром, без цвета, точнее общий цвет на весь экран. Речь только о цветном режиме 2 (color-40).

Значит, надо придумать как покрасить этот режим 640x200. Никакая текстообработка с 40 символами в строке не имеет смысла, разве что для какой-нить демы или игры в которой текст - дело десятое. Мне всегда даже 60 было мало (символы 8бит шириной при разрешении 480 по горизонтали). А что поместится в 40? Никакой текст на такую ширину не форматируют. Писать на ЯВУ при 40 символах нереально - не видишь алгоритма на экране. Разве что ассемблер в два столбца (комменты уже не влезают)?

В волковской идее не принципиально сколько цветов (т.е сколько битов в регистре). Были схемы с 4-мя цветами и с 8-ю цветами (что ты видел в журнале МК), где цвет задаётся только для цвета символов (цвет фона, т.е цвет битов 0 в видео-байте - всегда черный). Были схемы где 8 цветов для фона и 8 цветов для символов. И то же самое для 16-ти цветов. Это не принципиально (сколько РУ5-тых напаял вторым этажом - столько битов для цвета и имеешь).

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

Но это вообще не проблема. Ролик нужен только в одноцветных окнах. Там нет кусков в разных цветах. Например в текстовом редакторе, в окне прокрутки для выбора файла и т.п. Вокруг окна, что делает ролик могут быть другие цвета, но само окно где ролик одноцветное. И даже трудно представить программу для 8-ми разрядки, где нужен полноценный цветной ролик. Поэтому твой довод о преимуществах полноценного цветного ролика, считай, "разгромлен в пух и прах". На порядок важнее, чем цветной ролик - скорость вывода. Поэтому автор СПЕЦИАЛИСТА был абсолютно прав, выбрав цвет с автозаписью из регистра цвета.

Да это понятно, что если не экономить (как Волков), то РУ3 можно поставить не три а хоть восемь. Суть то не меняется: в драйвере цветного вывода символа на экран придется делать буферизирование и хранить цвет каждого символа (как и сами символы), чтобы при скроллинге их все переписывать заново из буфера. Я кстати делал похожее для VT52 чтобы имитировать тестовый экран (когда можно взять из буфера ранее выведенный в эту позицию символ) - чтобы открывать и закрывать "окна" (когда выводом текста из буфера восстанавливается только текст под закрываемым окном) в сугубо текстовом режиме в 100% CPM программе, причем прозрачно для самой программы, которай просто говорила "открыть/закрытm окно". Только и это не панацея: у нас же графический экран, а если перед скроллом на экран шел вывод несколькими шрифтами, да разной ширины? Хранить в буфере для каждого символа еще больше атрибутов? А если наложение? Обсчитывать из буфера и его? А если там еще графика на экране - как ее забуферизировать? Вводить векторное представление? На наших то смешных вычислительных ресурсах и мизере ОЗУ?

А в вариантах на тему "плоскостей цветовых атрибутов привязанных по знакоместам" (Спек, Орион) при желании как скроллинг, так и вывод символов прекрасно делается только в плоскости точек графики, а плоскость (страница) цвета может быть единожды покрашена на довольно длительное время - до того момента как потребуется ролик вместе с цветовыми атрибутами, который не вызывает никаких проблем и делается простым LDIR-ом - в любую сторону. И цветовые атрибуты я в тексте вполне себе использовал - выводя под скроллинг в одном окне просмотрщика текст разными цветами (например подсвеченный гипертекст в хелп-системе). И скролл использовал сразу нескольких цветных окон. Все это всплывает если программировать начать. Конечно, можно выезжать на инверсии, но это слишком бедно выглядит, и тогда вообще зачем ОЗУ цвета? Поставить как в Орионе-ПРО один единственный регистр, который красит константой весь экран да и всё.

[barsik]

У меня вопрос к автору эмулятора B2M. Т.к для эмулятора B2M нет отдельной темы. А зря, т.к эмулятор B2M очень хороший и используется по всему миру, причём для всех бытовых компьютеров, а документации к нему нет. Поэтому единственный способ что-то узнать про эмулятор, - это спросить у автора. А так как вопрос касается ИРИШИ, то это будет интересно для пользователей ИРИШИ, т.к даже имея реальную рабочую ИРИШУ, программы удобнее писать в эмуляторе. Например, мне хотелось бы расширить в эмуляторе ОЗУ на плате графического адаптера. А как это сделать? - Только спросить у автора эмулятора B2M.

После того, как я кое-что узнал о составлении конфиг-файлов для эмулятора в теме 'РК86 на Z80', я решил заглянуть в конфиг-файл ИРИШИ. И ничего не понял. Причём я смотрел конфиг-файл для базовой ИРИШИ, т.е без НГМД.

Я понял, что в конфиг базовой ИРИШИ добавили НГМД, кучу несуществующих портов и море ОЗУ. Посмотрев конфиг-файл ДИАЛОГА я понял, что именно надо удалять. Но не понял, что надо добавлять, чтобы получить базовую реальную ИРИШУ, без фантазий. В частности, в ИРИШЕ в карте 1 в сегменте 0 не читается продолжение ROM-BIOS, как в ДИАЛОГЕ, а читается базовое ОЗУ из платы граф.адаптера.

Хотя трудно судить, не имея информации об устройстве конфига, у меня возникло предположение, что карты памяти ИРИШИ обслуживаются неверно. Точнее реализована только карта 2, в которой работают резидентные программы. А карты 1 и 3 проигнорированы. Точнее, проигнорирована их работа, как в базовой ИРИШЕ. И вместо этого сделано что-то иное. Вообще, прошивка карты памяти может меняться, т.е она должна как-то присутствовать в конфиг-файле, а её здесь нет.

Похоже, что 64К дополнительного ОЗУ, читаемого в окнах 4000...7FFF и C000...FFFF в картах памяти 1 и 3, в эмуляторе ДИАЛОГА нет, а в ИРИШЕ здесь что-то другое.

Там в секции 'mm' подставлены какие-то 'win1', 'win2', 'win3', 'win4', что указывает на ОЗУ, из каких-то неизвестных науке периферийных плат, управляемых портами 24...27H, которых в базовой ИРИШЕ нет. Предположительно это ОЗУ на плате НГМД, т.к про другие периферийные платы содержащие доп.ОЗУ мне не известно.

На моей базовой ИРИШЕ стоит стандартное дополнительное ОЗУ, которое не нуждается в платах КНГМД и управлении несуществующими портами. Не могли бы Вы сделать мне конфиг-файл для стандартной ИРИШИ, т.е именно того, что у меня и у всех пользователей ИРИШИ есть в реальности, без всяких мифических устройств. Мне нужен эмулятор полностью соответствующий реальности, чтобы использовать эмулятор B2M для первичной проверки программ. Т.е нужна базовая ИРИША с ОЗУ в 128К, т.е только то, что поддерживается стандартным диспетчером памяти в картах 0...3.

Я так понимаю, что надо удалить порты 24...39 и непонятно откуда взявшийся мегабайт памяти 'mem2'. И ввести 2 блока памяти по 32К с 2-мя frame в окнах 4000...7FFF и C000...FFFF, включаемых в картах памяти соответственно 1 и 3.

К сожалению, автор эмулятора B2M, не прислушался к пожеланиям пользователей и не исправил регистры небуквенных клавиш (как я просил в теме ДИАЛОГА). Чтобы точка и запятая выводились, как на всех клавиатурах в мире, т.е по нажатию одной клавиши. А не по нажатию клавиши вместе с SHIFT-ом, что дико неудобно. Это дико непривычно и вызывает сильные отрицательные эмоции при пользовании, потому что всякий раз вводишь по привычке и возникает ошибка !!!

По счастью, при появлении новой версии эмулятора B2M от 28 декабря, я не поленился заглянуть в конфиг-файл и обнаружил, что исправление кодов курсорных клавиш сделано путём замены в конфиге, а не в самом коде эмулятора. А регистры небуквенных клавиш, так и не были исправлены.

В конфиге нового дистрибутива в секции 'kbd' обнаружилась следующаяся строка

vk.xlat[0][25-28]="1A1C191D"

Непонятно как работает эта строка, т.к на клавиши, вырабатывающие эти коды она не влияет.
Тогда я попробовал вставить следующие строки:

vk.xlat[0][3C]="2C"
vk.xlat[0][2C]="3C"
vk.xlat[0][3E]="2E"
vk.xlat[0][2E]="3E"
vk.xlat[0][3F]="2F"
vk.xlat[0][2F]="3F"

И, О чудо ! Символы точка, запятая и слэш вернулись в нормальный регистр. Увы, теперь для этих клавиш перестала работать клавиша <SHIFT>. Однако удалось обнаружить, что получить символы верхнего регистра этих клавиш можно нажимая клавишу <Control>, вместо <SHIFT>. Это уже спасение эмулятора ИРИШИ (иначе им просто невозможно пользоваться, свои нервы дороже).

Однако, учтите, что команда конфига VK.XLAT есть только в последней версии эмулятора B2M (от 28 декабря). С предыдущей версией эмулятора B2M (от 5 апреля) данные строки замены кодов вообще не работают. Надеюсь, что в следующей версии автор эмулятора B2M, наконец, исправит регистры небуквенных клавиш, т.к пользоваться клавишей <Control> вместо <SHIFT> - не смешно.

Однако ещё большая проблема возникает с вводом текстов русскими буквами. В ОРИОНЕ, есть жёстко фиксированная системная переменная RUSLAT (F3E5). Эмулятор ОРИОНА может "посмотреть" в эту ячейку и в соответствии с ней возвращать код (или латинских букв по раскладке QWERTY или русских букв по раскладке ЙЦУКЕН). А вот на ИРИШЕ такой стандартной ячейки нет. В каждой программе эта ячейка своя. Поэтому эмулятор не может знать какой код возвращать по нажатию на буквенную клавишу. Из-за этого в эмуляторе B2M русские буквы находятся на тех же клавишах, что и созвучные латинские, т.е так, как это в клавиатуре РК86 (хотя там раскладка ЙЦУКЕН).

В программах, рассчитанных специально для эмулятора, я могу программно вернуть русские клавиши в соответствии с подписями (я это делал в своём эмуляторе). Это делается простейшим перекодированием типа команды XLAT 8086-го. Но для этого надо иметь команду идентификации эмулятора. Выполнив её, программа узнаёт прогоняется она в эмуляторе на IBM PC, или на реальной ИРИШЕ. К сожалению, похоже, что в эмуляторе B2M нет команд эмулятора. Поэтому все программы придётся делать в двух версиях - для эмулятора и для реала.

[b2m]

Непонятно как работает эта строка

vk.xlat[0] для обычных клавиш
vk.xlat[1] для клавиш с Shift
vk.xlat[2] для клавиш с Ctrl
Второй индекс - это виртуальный код клавиши: virtualkeycodes.html
Можно задавать подряд несколько клавиш в одной строке для стоящих рядом виртуальных кодов.

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

Я понял, что в конфиг базовой ИРИШИ добавили НГМД

В "базовый" конфиг, т.е. тот, который просто Ириша, я добавил обе версии контроллера дисковода. Не хотелось плодить ещё конфигов.
Чтобы получить минимальную Иришу, проще всего покоцать конфиг Ириши с ГМД-70, он меньше всего по размеру. Достаточно убрать секцию dsk и связанные с ней порты 50-51.