Вид для печати
Хотел я тут было "Иришу" купить, с продавцом договорился, он отправил, а компьютер ко мне не приехал. И что-то я сомневаюсь, что он приедет.
Но есть фотографии от продавца. Вроде тут таких не было. Хотя бы такие. Если вдруг кто-то из вас такой компьютер приобрел (на случай если продавец продал один компьютер нескольким людям), то не выбрасывайте коробочку с обратным адресом...
http://storage7.static.itmages.ru/i/...b289932bb0.jpg http://storage8.static.itmages.ru/i/...864d116870.jpg
Красивый комп
В тему. Если кто мои платы увидит, фото которых я выкладывал, то тоже прошу отметиться и написать.
Тема криминальных сводок, даже страшно допаивать Иришу.
Теперь понятно почему тишина в теме :(
Кому допаивать (если есть чего), а кому вернуть своё. Всего лишь. И это - не смешно. :-)
Все сообщения о программах для ИРИШИ перенесены в новую тему "Программы для ИРИШИ".
Далее обсуждения о программах для ИРИШИ, в том числе и о перспективных программах и доработках самой ИРИШИ прошу вести в новой теме "Программы для ИРИШИ".
Графический адаптер ИРИШИ в режиме 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-ми разрядок).
Это лишь непроверенная на практике идея. Пока не особо и актуальная. Но я не вижу препятствий для её использования. И саму идею можно доработать. Например, в монохромном режиме можно использовать доп.бит для организации мигания. Снижение яркости можно использовать для маркировке в цвете и для вывода теней от панелей.
Работая на Орионе только в тестовых режимах, я бы сказал что важнее разрешающая способность. Для текста Ирише нужны 640х200, пофиг со сколькими цветами (лишь бы не вырвиглазными).Цитата:
Сообщение от barsik
Думаю, целью автора Специалиста было прикрутить цвет малой кровью - малым внедрением в основную схему и малым количеством корпусов. Если речь идет про тот вариант на трех РУ3, который я в прошлом столетии мельком видел в Моделист-конструкторе.Цитата:
Сообщение от barsik
Я не программировал под Спец. Имеется ли произвольный доступ к видео ОЗУ на запись/чтение? Или доступ только из регистра при выводе в основное видео ОЗУ? Если произвольного доступа нет, то задачка скроллинга части экрана (в любую сторону), где в этой части присутствует окраска фрагментов в разные цвета, представляется задачкой из серии "убил бы автора той схемы" (либо разъедутся атрибуты и фон, либо надо перевыводить на экран заново весь блок по новым координатом, что намного медленнее, чем копирнуть в памяти массив байт). А если произвольный доступ и есть, скроллинг опять же будет не быстрее Орионовского.
- - - Добавлено - - -
А ведь скроллинг задача не гипотетическая, а как раз таки наипервейшая для тестообработки. Именно на медленном скроллинге особенно заметно что комп ворочает бОльшим количеством пикселей чем сосед.
ИРИША в цвете может выводить только на CGA, т.е 320x200 в 4-х цветах (из 2-х палитр). А 640x200 - монохром, без цвета, точнее общий цвет на весь экран. Речь только о цветном режиме 2 (color-40).
В волковской идее не принципиально сколько цветов (т.е сколько битов в регистре). Были схемы с 4-мя цветами и с 8-ю цветами (что ты видел в журнале МК), где цвет задаётся только для цвета символов (цвет фона, т.е цвет битов 0 в видео-байте - всегда черный). Были схемы где 8 цветов для фона и 8 цветов для символов. И то же самое для 16-ти цветов. Это не принципиально (сколько РУ5-тых напаял вторым этажом - столько битов для цвета и имеешь).
Принципиально только одно - автозапись в ОЗУ цвета из регистра цвета. Занёс туда цвет и далее все выводы графики в экран раскрашивают в этот цвет. Отдельно ОЗУ для графики с прямым доступом и отдельно - ОЗУ цвета, куда нет прямого доступа, ни по чтению, ни по записи. Поэтому если надо делать полноценный цветной ролик, то программа должна знать и помнить где были какие цвета и действовать соответственно.
Но это вообще не проблема. Ролик нужен только в одноцветных окнах. Там нет кусков в разных цветах. Например в текстовом редакторе, в окне прокрутки для выбора файла и т.п. Вокруг окна, что делает ролик могут быть другие цвета, но само окно где ролик одноцветное. И даже трудно представить программу для 8-ми разрядки, где нужен полноценный цветной ролик. Поэтому твой довод о преимуществах полноценного цветного ролика, считай, "разгромлен в пух и прах". На порядок важнее, чем цветной ролик - скорость вывода. Поэтому автор СПЕЦИАЛИСТА был абсолютно прав, выбрав цвет с автозаписью из регистра цвета.
Значит, надо придумать как покрасить этот режим 640x200. Никакая текстообработка с 40 символами в строке не имеет смысла, разве что для какой-нить демы или игры в которой текст - дело десятое. Мне всегда даже 60 было мало (символы 8бит шириной при разрешении 480 по горизонтали). А что поместится в 40? Никакой текст на такую ширину не форматируют. Писать на ЯВУ при 40 символах нереально - не видишь алгоритма на экране. Разве что ассемблер в два столбца (комменты уже не влезают)?Цитата:
Сообщение от barsik
Да это понятно, что если не экономить (как Волков), то РУ3 можно поставить не три а хоть восемь. Суть то не меняется: в драйвере цветного вывода символа на экран придется делать буферизирование и хранить цвет каждого символа (как и сами символы), чтобы при скроллинге их все переписывать заново из буфера. Я кстати делал похожее для VT52 чтобы имитировать тестовый экран (когда можно взять из буфера ранее выведенный в эту позицию символ) - чтобы открывать и закрывать "окна" (когда выводом текста из буфера восстанавливается только текст под закрываемым окном) в сугубо текстовом режиме в 100% CPM программе, причем прозрачно для самой программы, которай просто говорила "открыть/закрытm окно". Только и это не панацея: у нас же графический экран, а если перед скроллом на экран шел вывод несколькими шрифтами, да разной ширины? Хранить в буфере для каждого символа еще больше атрибутов? А если наложение? Обсчитывать из буфера и его? А если там еще графика на экране - как ее забуферизировать? Вводить векторное представление? На наших то смешных вычислительных ресурсах и мизере ОЗУ?Цитата:
Сообщение от barsik
А в вариантах на тему "плоскостей цветовых атрибутов привязанных по знакоместам" (Спек, Орион) при желании как скроллинг, так и вывод символов прекрасно делается только в плоскости точек графики, а плоскость (страница) цвета может быть единожды покрашена на довольно длительное время - до того момента как потребуется ролик вместе с цветовыми атрибутами, который не вызывает никаких проблем и делается простым LDIR-ом - в любую сторону. И цветовые атрибуты я в тексте вполне себе использовал - выводя под скроллинг в одном окне просмотрщика текст разными цветами (например подсвеченный гипертекст в хелп-системе). И скролл использовал сразу нескольких цветных окон. Все это всплывает если программировать начать. Конечно, можно выезжать на инверсии, но это слишком бедно выглядит, и тогда вообще зачем ОЗУ цвета? Поставить как в Орионе-ПРО один единственный регистр, который красит константой весь экран да и всё.