Что максимум можно выжать из КР580ВГ75 Intel 8275? Обсуждение

[bigral]

Всем привет, в свете того что уже много информации накопилось об этой микросхеме решил создать "собирательную" тему по ней. Сама микросхема очень старая и производилась (на западе) во времена засилия мини-ЭВМ (hp2100, pdp11, DATA General NOVA и т.д. т.е. примерно средина 70х). В то время появился i8080 и стало возможным строить на нем видеотерминалы которые были намного удобнее телетайпов с бумажной лентой.

Микруха спроектированна таким образом чтобы:
1. запрашивать во внутренний буфер символы во время того как из другого буфера ранее загруженные символы высвечиваются на экране;
2. работать с внешней схемой формирующей вид символов (т.е. внешняя схема ОБЯЗАННА отвечать за параметры типа: ширина точек символа, размер пробела между точками в символе и между символами, количество цветов на точку в символе, количество точек в символе в ширину и т.д.);
3. максимальное количество символов в строке: 80;
4. максимальный размер символа по вертикали в линиях: 16;
5...
6... (помогайте)


Основные вопросы:

1. В чем выиграш применения микросхемы (намного ли она поможет по сравнению скажем с вариантом построения видеоадаптера на 74xx + PAL)?
2. Во многих текстах говорится об крайней архаичности и бесполезности микросхемы, на сколько это правда (учитывая например то что на ней был сформирован аж ZX экран в АРГО, но софта манипулирующего именно "аппаратными символами" такого ZX экрана небыло)?
3. Можно ли сформировать на этой микросхеме спрайтовый движек с аппаратным наложением на другой экран (сюда же вопрос о том можно ли применить одновременно несколько микросхем для формирования общего экрана)?
4...
5... (помогайте)

[Ewgeny7]

Из нее можно выжать Апогей БК-01Ц (цветную РК86). Если жать дальше - полезут кишки :)
Плюсы - чуть меньше корпусов для работы. Остальное - минусы. Контроллер ПДП - обязателен. ПЗУ со знакогенератором. Прочая обвеска.
А для сравнения с 74хх достаточно сравнить Радио-86РК и Специалиста/Ориона. Выигрыш вторых - во всем. Чуть большее количество корпусов мелкологики дает несравнимые преимущества в графике и прочей работе. И по крайней мере, не теребонькает ни процессор, ни его шины во время работы.
Вывод - Радио-86РК оставить как исторический факт, но ничего нового на ВГ75 не изобретать!

[b2m]

3. Можно ли сформировать на этой микросхеме спрайтовый движек с аппаратным наложением на другой экран (сюда же вопрос о том можно ли применить одновременно несколько микросхем для формирования общего экрана)?
Идея интересная, но если вспомнить, что спрайты ещё и друг на друга накладываться должны, то опять возвращаемся с к тому, что знакогенератор для символа в случае наложения должен быть заново запрограммирован. Так и без аппаратного наложения делать можно (имеется ввиду, когда знакогенератор в ОЗУ и цветной).

По поводу нескольких микросхем одновременно - был МЦПГ для компьютера Партнёр. Там, правда, не наложение было, а замена знакоместа (вместо символа из ПЗУ отображался цветной символ из ОЗУ). К тому-же ВГ75 работали реально параллельно и получали одну и ту-же строку из ОЗУ. Впрочем, по другому и не возможно, если в качестве контроллера ПДП применять ВТ57 - у него только один канал с автозагрузкой.

[vinxru]

ИМХО максимум развития схемотехники ВГ75 в домашних/любительских компьютерах был в Арго ФВ 6511 и Электроника КР-04.

В этих компьютерах используются оба подхода Радио 86РК и Специалиста. Сначала символ вычитывается из ОЗУ с помощью захвата шины. В этом участвуют ВТ57 и ВГ75. А затем прочитанный символ используется как адрес для чтения из памяти. В этом участвуют мультиплексоры (и мелкая логика), прозрачно для процессора подключающая к памяти видеоадаптер.

И у нас получается текстовый видеорежим 64x25 с произвольным знакогенератором. Его можно рассматривать как графический режим 512×224 2 цвета с неудобной адресацией. (Так же, в компьютере КР-04 есть режим 240×224 4 цвета. Два соседних бита кодируют одну точку. Палитра 64 цвета.)

С одной стороны ВГ75 для графического режима не нужна. Она только тратит оперативную память, которая будет заполнена последовательностию символов от 0 до 127 (плюс символы для смены аттрибутов, которые используются для выбора одного из 16 знакогенераторов.)

С другой стороны мы получаем аппаратное ускорение при выводе спрайтов подобное MSX.

http://cs631121.vk.me/v631121349/68e/MEx2Xf6p2ks.jpg

И немного юмора:
- В КР-04 эмулируется текстовый режим 80x25 на основе текстового режима 64x25 со сменным знакогенератором. Вдумайтесь.
- Из 512 выводимых компьютером точек на экране видно лишь 480 точек, остальные выводятся за пределами экрана.

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


К тому-же ВГ75 работали реально параллельно и получали одну и ту-же строку из ОЗУ. Впрочем, по другому и не возможно, если в качестве контроллера ПДП применять ВТ57 - у него только один канал с автозагрузкой.

ВГ75 поддерживает только знакогенратор в 128 символов, 7 бит. Можно поставить пару ВГ75, подключив к ним разные биты для охвата всех возможных 256 символов.

[Destr]

сюда же вопрос о том можно ли применить одновременно несколько микросхем для формирования общего экрана
Конечно, очень нужно!
Да только опоздание, это нужно было делать ешё тогда, в 80-х....
А счаз - ну хочешь понастальжируй, что-ли...
(сорри, не попрекаю, просто поражаюсь порой как вы люди там заморачиваетесь, аж завидно временами, а потом вспоминаю что мне-то не светит...)

[freddy]

Интересно, а сможет ВГ75 выдать 80 символов в строке на VGA развертке? Кто-нибуть пробовал ее оверклокнуть на 3,146Мгц CCLK (25,175Мгц/8)?

[b2m]

Интересно, а сможет ВГ75 выдать 80 символов в строке на VGA развертке? Кто-нибуть пробовал ее оверклокнуть на 3,146Мгц CCLK (25,175Мгц/8)?
Только если схему гашения и формирования ССИ добавить.
Вот тут делали РК-шку с выводом на VGA: http://zx-pk.ru/threads/13148-radio-rk-86-kompyuter-s-protsessorom-1821vm85/page2.html

[Anubis_OD]

Интересно, а сможет ВГ75 выдать 80 символов в строке на VGA развертке? Кто-нибуть пробовал ее оверклокнуть на 3,146Мгц CCLK (25,175Мгц/8)?

Отлично работает на этой частоте. Проверил несколько отечественных чипов и импорт.

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


Только если схему гашения и формирования ССИ добавить.


Вот тут я описал как формировал близкие к стандарту параметры кадрового и строчного импульса.
http://zx-pk.ru/threads/26223-i-eshche-odna-rk-shka.html?p=868239

[freddy]

А может ведь старушка! Тоже не удержался, попробовал 640х480х60Гц и 640х400х70Гц. Легко заработала на стандартном пиксель клоке 25.175Мгц. Добавил еще 4 корпуса мелкой логики для формирования стандартных синхроимпульсов, теперь любой монитор хавает этот сигнал и даже автопостройка не врубается.
Выходит рано ее списывать. Она годится под текстовую видеокарту для самодельных компов на СР/М и MS-DOS. Для всяких видеотерминалов лучше не придумать.
Так что к ее плюсам можно прибавить:
+огромный разгонный потенциал
+простая и понятная схемотехника
+простое программирование
+легко купить, малая цена

[vinxru]

Только схема на рассыпухе получается не особо сложнее, но без ограничений:

- всего 128 символов
- неравномерное торможение процессора
- очень неудобная реализация цвета.

[freddy]

Намного сложнее на рассыпухе для реализации даже меньшего функионала. Торможения процессора... ну да, если мыслить в рамках Радио-86РК-подобных тазиков, то да, оно будет. А если грамотно построить, типа как в CGA, на псевдо двухпортовом видео ОЗУ, то все будет ОК. Цвет там не задумывался вообще, для текстовой видяхи не особо нужен, ее атрибутами лучше пользоваться по назначению. И еще останется возможность переключать 4 знакогенератора по 128 символов. К стати русский язык в терминале не очень нужен, хватит младшей половины стандартного VGA знакогенератора на все, там даже для рисования таблиц все есть. А еще у нее можно графику прикрутить, как у MC6845, доделав мультиплексор знакогенератора. А если взять две ВГ75... Но это уже две, а здесь обсуждаем одну :)
В общем на ней можно сделать толковую видеокарту, в 80-е тема по ней так и не была полностью раскрыта.

[vinxru]

Намного сложнее на рассыпухе для реализации даже меньшего функионала.

В Радио 86РК у нас ~25 микросхем среди которых большие дорогие и сложные ВТ57, ВГ75, еще одна ПЗУ для знакоенератора. В Специалисте у нас ~35 микросхем, среди которых только примитивная логика.

При этом, применение в Специалисте чуть более современных микросхем, типа АП6 вместо АП16, ИР10 вместо ИР1, ИЕ19 вместо ИЕ5... позволяет сократить схему до 18 микросхем.

А еще есть Кроха, простая, текстовая и без ВГ75:
http://zx-pk.ru/threads/26306-igrovaya-pristavka-quot-krokha-quot.html

Если мы возьмем более шустрый Z80, то сможем формировать экран программно как в компьютерах ZX80 и Галаксия. Это существенно снизит скорость Z80... до скорости Радио 86РК. Если написать свою программу формирования видео, то можно получить графику 256×208.

[freddy]

Мне больше всего понравилась фраза "ДОРОГИЕ И СЛОЖНЫЕ ВТ57 и ВГ75". Обе стоят порядка 10-20р/шт и перепаханы в букварях вдоль в поперек. А еще Специалист как и Кроха не может 80х25 на VGA монитор выводить. Ну и это... у меня вот ВГ75 без ВТ57 обходится и построена на ней вполне взрослая видеокарта, не хуже MDA от IBM. Она очень хорошо стыкуется с консолями UNIX-подобных и CP/M-образных. Вот на фото она, на плате еще COM и PS/2 есть :)
5707057071

[vinxru]

Специалист как и Кроха не может 80х25 на VGA монитор выводить.

Радио 86РК то же не может, выводит разогнанный Радио 86РК. Аналогично разогнанный Специалист под названием Специалист МХ2 выводит картинку на VGA монитор.

[freddy]

Причем же всетаки здесь Радио-86РК? Это же пример бездарного использования весьма неплохого для своего времени, профессионального видеоконтроллера. К стати удачи Вам с Специалистом МХ2. Посмотрим как он выдаст 80х25, может покажете ??? :) Можно конечно сделать ЗГ с шириной символа 4 пикселя и высотой 8 пикселей и еще и прорисовывать их програмно, наверно круто будет :) А без 80 символов в строке это даже на видеотерминал не потянет. А вот ВГ75 спокойно выводит красивые такие буковки аж 8x16 пикселей в высоту и все аппаратно, еще ее атрибуты как будто спецом заточены под управляющие ESC-последовательности терминала VT52. Поэтому видеокарта из нее как раз вписывается в терминал для работы под UNIX, CP/M, MS-DOS.

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

Еще можно как альтернативу IBM-овского адаптера MDA юзать. Я когда то в середине 90-х пытался его контроллер MC6845 разогнать под VGA- развертку. Ничего не вышло. 2Мгц символьной частоты это потолок. А тут так спокойно раз и VGA аж на 70гц кадровой развертки, что для ЭЛТ мониторов очень хорошо, глазам отдых.

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

Скорее всего и SVGA потянет, но у себя проверить не могу, нужно переделывать формировать синхроимпульсов, влом.

[vinxru]

> К стати удачи Вам с Специалистом МХ2. Посмотрим как он выдаст 80х25, может покажете ???

Специалист МХ2 - это просто пример того, что любой компьютер на рассыпухе можно разогнать до VGA-шных частот. Это рассыпуха, можно сделать всё что угодно. Я об этом говорил и вы это должны были понять.

Нужно 80 символов, делаем разрешение 512 или 640 точек в ширину. Схема примерно та же. Только сброс по другому развести.

Очень нужен аппаратный текстовый режим, просто добавляем одну ПЗУ со знакогенератором. Кроме ПЗУ ни одной микросхемы не потребуется. Ставим между ОЗУ и сдвиговым регистром (пикселей). Это сделано, например, в Крохе.

И нам не придется выключать видеоадаптер, что бы загрузить программу с магнитофона или дисковода. И скорость процессора не будет падать аж в два раза в режиме 80x64 символов.

> прорисовывать их програмно, наверно круто будет

Быстро прорисовывается. Даже при ширине символа в 6 пикселей (где надо сдвигать, AND, OR-ить) заполнение экрана происходит за десятую секунды, что для текстовых программ очень приемлимо. Я коммандер писал для Специалиста, знаю. А если мы возьмем режим 640 в ширину, то отрисовка будет просто моментальной (не надо AND, OR-ить)

Но зато мы не ограничены 128 символами. Да хоть 1024 символа, хоть разного размера. И не надо говорить - что русские буквы не нужны.

> еще ее атрибуты как будто спецом заточены под управляющие ESC-последовательности терминала VT52.

Вы сначала попробуйте что нибудь сделать с использованием атрибутов. Это худшее, что придумали за историю компьютеров.

И у меня очень сильное подозрение , что скрытые атрибуты работают лишь в разрешении 64 символа. У микросхемы буфер на 80 на байт. В режиме 80 символов места под атрибуты не остается.

[creator]

Уважаемые, а обьясните мне тупому, по-простому, на пальцах.

Сразу скажу, я не знаю внутренней логики ВГ75. Ну да, как-то видел её схему на рассыпухе в журнале Радио, ужаснулся, копаться глубже как-то даже мысли не возникло. ;)

Но мне так кажется, что у неё внутри эдакий внутренний буфер текстового экрана размерами 64 на неважно сколько. И сколько её не разгоняй, то от этого её внутренний буфер больше 64 символов по горизонтали не станет. А вы тут, с моей точки зрения, прямо про какие-то фантастические возможности рассказываете. Что, прямо на самом деле 8x16 пикселей знакогенератор, да 80 символов в строке?

P.S. Как-то всегда хотелось (даже не знаю зачем, но хотелось) собрать простую классическую CP/M машинку на Z80 с 64KB RAM, only text mode 80xXX, безо всяких графических режимов, ну чтобы ни у кого не возникало желания портировать туда всяких принцев и гоблинов. :) А если она ещё и на VGA будет выводить, то с нынешней дармовой ценой на 15" LCD мониторы, то это вообще песня.

[freddy]

И нам не придется выключать видеоадаптер, что бы загрузить программу с магнитофона или дисковода. И скорость процессора не будет падать аж в два раза в режиме 80x64 символов.
Так надо чтоб видеоадаптер работал с двухпортовым ОЗУ, у меня он вообще отдельно в своем адресном пространстве. Причем тут вобще магнитофон и дисковод??? у меня нет такого. Есть серверная под Unix, к серверам я цепляюсь с помощью своего терминала, у него видеокарта на ВГ75.


Но зато мы не ограничены 128 символами. Да хоть 1024 символа, хоть разного размера. И не надо говорить - что русские буквы не нужны.
Надо говорить что не нужны. Не встречал пока их во всяких консолях, все на английском там начиная от командной строки до мануалов.


Вы сначала попробуйте что нибудь сделать с использованием атрибутов. Это худшее, что придумали за историю компьютеров.
Круто! Не повезло мне, но я всетаки сделал то что на фото :))))) Наверно кактус съел пока делал.

[vinxru]

Надо говорить что не нужны. Не встречал пока их во всяких консолях, все на английском там начиная от командной строки до мануалов.

Ладно, цвет не нужен, 256 символов не нужны, изменяемый знакогенратор не нужен, русский язык не нужен, графика не нужна, но при этом нужна двухпортовая память.

Псевдографика вам то же не нужна? Рамочки ординарные и двойные?

[freddy]

Но мне так кажется, что у неё внутри эдакий внутренний буфер текстового экрана размерами 64 на неважно сколько. И сколько её не разгоняй, то от этого её внутренний буфер больше 64 символов по горизонтали не станет. А вы тут, с моей точки зрения, прямо про какие-то фантастические возможности рассказываете. Что, прямо на самом деле 8x16 пикселей знакогенератор, да 80 символов в строке?
Тут многие мануалы не читают, в основном копируя всякие бытовые компы 80-х 90х на современный манер. Однако Вы всеже посмотрите на нее даташит. Одноудовольствие как Intel сжато и понятно все излагает. В ВГ75 буфер не 64 символа и он там не один. И да! На самом деле выводит 80х25 символы 8х16, при этом видеорежим видимый 640х400@70Гц, физический 800х448.


P.S. Как-то всегда хотелось (даже не знаю зачем, но хотелось) собрать простую классическую CP/M машинку на Z80 с 64KB RAM, only text mode 80xXX, безо всяких графических режимов, ну чтобы ни у кого не возникало желания портировать туда всяких принцев и гоблинов. А если она ещё и на VGA будет выводить, то с нынешней дармовой ценой на 15" LCD мониторы, то это вообще песня.
Да, вы точно сказали. Никаких гоблинов и принцев. Только текст ее удел. Если на нее навесить графику, то простой схема уже не будет. Я очень люблю CP/M. И там ВГ75 как раз то что нужно. Ей можно доделать шину S100 или ISA8. Или как я на фото выкладывал вариант несколькими постами выше. Это законченный видеотерминал с поддержкой ESC-последовательностей ANSI/VT-52. Все что нужно - это сделать простенькую одноплатную машину с CP/M на z80 с COM-портом, подсоединить туда этот терминал и только в путь!

[vinxru]

Но мне так кажется, что у неё внутри эдакий внутренний буфер текстового экрана размерами 64 на неважно сколько.

Внутри микросхемы буфер на 80 символов.
Эта микросхема запрашивает у DMA-контроллера 80 байт (сколько настроишь), а потом повторяет эти 80 байт от 1 до 16 раз.

Всё, больше она ничего не делает. Она не формирует КСИ и ССИ. Она не занимается сдвигом пикселей.

Ну... еще делает паузы в конце строки и конце кадра. На 4-х своих ножках выводит атрибуты символа (застрелиться как они работают). И световое перо поддерживается!


И сколько её не разгоняй, то от этого её внутренний буфер больше 64 символов по горизонтали не станет. А вы тут, с моей точки зрения, прямо про какие-то фантастические возможности рассказываете. Что, прямо на самом деле 8x16 пикселей знакогенератор, да 80 символов в строке?

80 символов способна запомнить микросхема. И способна их 16 раз посторить. Ширина символа 8 обеспечивается внешними микросхемами, самой ВГ75 до этого нет дела. Хоть 6, хоть 16. ВГ75 просто байты копирует со входа на выход.

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


Если на нее навесить графику, то простой схема уже не будет

Поставить высоту символа в 1 пиксель.. но это невозможно. DMA контроллер не способен выводить данные на такой скорости.

[freddy]

Ладно, цвет не нужен, 256 символов не нужны, изменяемый знакогенратор не нужен, русский язык не нужен, графика не нужна, но при этом нужна двухпортовая память.

Псевдографика вам то же не нужна? Рамочки ординарные и двойные?

Это можно доделать. Прошить можно ПЗУ поболее... скажем 2764. Там влезет 2 занакогенератора по 256 символов размером 8х16. Работать будет так: при получении ASCII символа больше 127 арбитр обращения к видеобуферу добавит перед ним управляющий код для включение нужной линии GPIO на ВГ75, чтобы псле выборки этого кода ВГ75 перещелкнул ПЗУ на выбор старшей половинки ЗГ и в самом ASCII коде гасит старший разряд. Далее арбитр следит пока не получит какой-нибудь ASCII код из диапазона 0-127, продолжая принудительно гасить старший разряд во всех поступающий кодах. Он соответственно перед этим символом вставит управляющий код чтобы ВГ75 выбрала через GPIO младшую половинку ЗГ. DMA там всеравно програмно обрабатываются, так что это все вопрос пары-тройки строчек кода.
А вобще когда я его делал у меня были только 2шт КР573РФ5. Поэтому это моя не доработка, потом как нибудь сделаю полноценный ЗГ. Midnight Commander будет такой красивый-красивый. Сейчас его рамки рисуются заглавными буквами :)

[vinxru]

Кстати, в Радио 86РК на можно сделать шрифт 8x16. У ТВ ведь разрешение 768 x 576i

Правильно сделать формирование КСИ для черезстрочной развертки и завести номер полукадра на старшую линию адреса ПЗУ ЗГ. Четкость шрифта должна повысится.

[freddy]

А еще в Радио-86РК можно сделать, чтобы видеконтроллер не тормозил процессор и не выключался во время загрузки с мафана. Для этого ему надо свой видеобуфер, отдельно от ОЗУ РК-шки. Вариантов много. Можно все скрыть в недрах микроконтроллера (мой вариант). Можно на рассыпухе буферизацию записи со стороны компа сделать, как у CGA. Можно купить двухпортовое ОЗУ, их сейчас каких хош есть. РК должна быть на SRAM переделана, DMA больше не будет регенерацией ОЗУ заниматься.

[creator]

Кстати, в Радио 86РК на можно сделать шрифт 8x16. У ТВ ведь разрешение 768 x 576i
Правильно сделать формирование КСИ для черезстрочной развертки и завести номер полукадра на старшую линию адреса ПЗУ ЗГ. Четкость шрифта должна повысится.
Повыситься-то она повысится, но глаза тебе этого не простят. Будет ужасно (я на Амиге 8 лет работал, не по наслышке знаю что такое чрезстрочная развёртка в ТВ режимах 50Hz кадровой).
Хотя на нынешних LCD телеках оно вполне даже сносно выглядит.

[vinxru]

> скрыть в недрах микроконтроллера (мой вариант)

А может сразу с МК подавать выход на ПЗУ знакогенератора?

> Для этого ему надо свой видеобуфер, отдельно от ОЗУ РК-шки. Вариантов много. Можно все скрыть в недрах микроконтроллера (мой вариант). Можно на рассыпухе буферизацию записи со стороны компа сделать, как у CGA. Можно купить двухпортовое ОЗУ, их сейчас каких хош есть.

ВГ75 это и так буфер. У неё основная задача заранее набрать данных и равномерно выплюнуть их.

Тогда уж, поменять приоритеты доступа к памяти. В первую очередь работает процессор, а в свободные такты видео? Тормозить не процессор линий BUSREQ, а наоборот тормозить видео.

[freddy]

Тогда уж, поменять приоритеты доступа к памяти. В первую очередь работает процессор, а в свободные такты видео? Тормозить не процессор линий BUSREQ, а наоборот тормозить видео.
Тормозить не надо. Надо другой подход, пусть рабтают асинхронно. У видеоадаптера есть возможность делать паузы между запросами в Burst режиме. Их то я и использую. Ничего при этом не тормозит. Там, как такового, вообще сигнала "тормозить" нет.

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


Хотя на нынешних LCD телеках оно вполне даже сносно выглядит.
Плохо выглядит, скалер замыливает грани строк, выглядит как будто глаза сфокусироваться не могут. Начинают болеть. Черезстрочный растр это костыль.

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


А может сразу с МК подавать выход на ПЗУ знакогенератора?

Так тоже делал, и не только я. Есть у немцев подобный софтовый видеоадаптер. Там все еще проще. ЗГ в самом микроконтроллере. На сдвиговый регистр выводятся байты знакогенератора прямо из микроконтроллера. Тогда мы приходим к идее вообще отказаться от ВГ75, DMA и ее логики обвязки. Синхроимпульсы также вырбатываюся аппаратно на таймерах микроконтроллера. Схема упрощается до 2 микросхем: микроконтроллер+сдвиговый регистр. От РК остается только проц, SRAM, ROM, дешифратор адресов. Все можно сделать размером с ладошку. Но это совсем другая история.

[creator]

Плохо выглядит, скалер замыливает грани строк, выглядит как будто глаза сфокусироваться не могут. Начинают болеть. Черезстрочный растр это костыль.
Само собой. Только прогрессивную развёртку надо.

Поэтому это моя не доработка, потом как нибудь сделаю полноценный ЗГ.
Доделывай и опубликуй. Очень интересно. С VGA развёрткой! :)

[vinxru]

Само собой. Только прогрессивную развёртку надо.

LCD мониторы "прогрессивную" развертку, всё равно показывают как черезстрочную. Четные кадры занимают четные строки, нечетные нечетные.

Апогей, Гигаскрин, LCD

http://cs625316.vk.me/v625316349/3cc9c/kma5P6cz-R0.jpg

ZX Spectrum, Гигаскин, Проектор

http://cs624923.vk.me/u160193991/video/l_e573155e.jpg

Т.е. гигаскрин на LCD, это не эффект смешения цветов, это увеличение вертикального разрешения в два раза. Только из за неправильного формирвоания КСИ монитор не может правильно определить, какогда передаются черные или нечетные строки.

На LCD что бы поменять неправильно определенный порядок строк, надо включить-выключить монитор. Проектор же раз в секунду или чаще сам меняет строки. Не может определиться.

И где тут мыло? По сравнению с прогрессивной разверткой? (конечно, по сравнению с родным разрешением монитора не то, но не будете же вы делать вывод 1920x1080 с ВГ75)

[freddy]

Доделывай и опубликуй. Очень интересно. С VGA развёрткой!
Да, пожалуй оформлю в виде статьи и выложу.

И где тут мыло? По сравнению с прогрессивной разверткой? (конечно, по сравнению с родным разрешением монитора не то, но не будете же вы делать вывод 1920x1080 с ВГ75)
Мыло бъет по глазам когда в текст всматриваешся, а для такой графики мыло не страшно, а даже наоборот немного улучшает восприятие. 1920х1080 это перебор. Оставлю 640х400@70Гц и 640х480@60Гц. Скалеры их хорошо переваривают, это типа индустриальный стандарт. И формирование синхроимульсов схоже, только полярность отличается.
К слову о полярности. Я тут на работе попробовал штук 5 разных ЖК моников, им всеравно какая полярность. Видимо это важно только для стареньких аналоговых ЭЛТ моников.

[freddy]

57170
В архиве схема, печатная плата, прошивка контроллера и ЗГ. Для себя уяснил, что это не окончательный вариант. Буду переделывать, но не сильно :)
Что может текущая версия:
-прикидывается (вполне успешно) терминалом DEC VT52, не поддерживается альтернативная раскладка цифровой клавиатуры;
-работает пока только на 9600bps 8N1, в дуплексном режиме без управления потоком;
-атрибуты ВГ75 не задействованы никак, нет их у VT52;
-формат экрана 80х25 (640х400), шрифт очень крупный 8х16, выдран из редактора "Слово и дело";

Что хочу доделать:
-по эмуляции терминала доделать поддержку ANSI кодов управления атрибутами поля + некоторые команды DEC Private (VT100);
-переключить клавиатуру на второй COM порт;
-добавить поддержку инверсии и 8-ми цветов, задействовав(RVV, HGLT, GP0, GP1);
-сделать 4 знакогенератора, переключение через LA0, LA1 (на счет этого пока не уверен).

Пока что наступил на грабли. ВГ75 формирует опережающие сигналы на выводах атрибутов. Их перед использованием, надо защелкнуть в регистр, тем же импульсом, которым записывается код символа в сдвиговый регистр. Завтра допаяю. А пока курсор в виде инверсного видеоблока формируется немного не там :) При том что курсор в виде подчеркивания там :)

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

Для желающих повторить:
-Обратите особое внимание на U1, U5, U2. Нужны быстродействующие серии F, AC, ACT. У меня стоят U1-КР531ЛН1, U5-ОКР1533ИР10, U2-КР1533ИЕ5.
-Все остальные микросхемы могут быть серий К155, К555 без разницы.
-Все диоды любые импульсные кремниевые
-Все подтягивающие резисторы 2-10к всеравно какие.
-Mega128 с фьюзами на запуск от внешнего скоростного кварца

[Shaman]

Скан описания микросхемы КР580ВГ75 из справочника "Интегральные микросхемы".
Может кому, пригодится :)
http://ic.pics.livejournal.com/nushaman/13486084/4679/4679_original.jpg

[freddy]

Привет! Сделал поддержку команд терминала VT100. Теперь терминал подходит почти ко всему (DEC PDP, CP/M, Unix...) Немного переработал схему. Текущий вариант такой: 57271 На К555ТМ9 и КР531ЛП5 собрана защелка атрибутов и их распределение по каналам цветности.Теперь схема может 8 цветов и инверсию знакоместа. Курсор в виде подчеркивания убран из схемы совсем (это триггер U6 на старой схеме). Сигнал LTEN я попробую использовать в качестве дополнительного адреса для знакогенератора. С количеством ЗГ тоже определился, будет один со стандартной раскладкой ASCII, русифицированный. Курсор теперь только в виде мигающего инверсного блока, так смотрится красивее, в духе конца 70-х :)
Итак, по железу осталась переброска клавиатуры на UART1, ну и драйвер переписать.
По софту беда. Сейчас у меня не хватает ОЗУ микроконтроллера под видеобуфер из-за применения атрибутов. Но я что-нибудь придумаю, пока юзайте старую прошивку она на этой схеме работает.
Пишите сюда свои соображения, что еще можно добавить/убрать. Пока что то делать нет возможности, переезжаю на ПМЖ.

[b2m]

Сигнал LTEN я попробую использовать в качестве дополнительного адреса для знакогенератора.
Интересная идея. До сих пор вроде никто такого не делал.

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

По-моему, линия подчёркивания активна только на одной линии знакоместа. Или нет?

[freddy]

Да, только на одной линии. Это не удобно, нужно этот сигнал защелкивать, чтобы он действовал на всех 16 линиях знакоместа. Поэтому подчеркивание должно быть установлено в 0-й линии строки, за время 0-й линии произойдет запись LTEN в необходимые знакоместа. Запись по условию CCLK&(~LC0)&(~LC1)&(~LC2)&(~LC3). Для этого понадобится 80бит регистровой памяти, чтоб запомнить всю строку. Далее остальные 15 линий регистровая память будет гонять эти 80 бит по кругу Сбрасываться память будет сигналом HRTC&LC0&LC1&LC2&LC3, т.е. после последнего знакоместа 16-й линии символа. Собственно на чем сделать эту память я пока не думал. Идеально для этого подходят сдвиговые регистры. Взять 10 8ми битных :) Как ни крути, получается грамостко, и сейчас же " непризнанные гении" забросают гнилыми помидорами. Хотя реализовать можно. Можно счетчик адресов и какое-нибудь однобитное ОЗУ. Так получится около 3-х корпусов. Однако... нужен ли этот LTEN? Проще забить, например, на инверсию и использовать RVV в качестве старшего бита адреса знакогенератора.

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

Вот так я хотел использовать LTEN:
57288
К555ИЕ5 и КР565РУ5 взяты для примера, потому что у меня их много. А так вобще можно уложиться и в 2 корпуса.
LTEN в данном примере работает как старший адрес знакогенератора. Все оказалось проще, чем я думал. Однако до сих пор сомневаюсь в правильности такой идеи. Может ну его... лучше пусть подчеркивает потихоньку?

[Error404]

Тут многие мануалы не читают, в основном копируя всякие бытовые компы 80-х 90х на современный манер. Однако Вы всеже посмотрите на нее даташит. Одноудовольствие как Intel сжато и понятно все излагает. В ВГ75 буфер не 64 символа и он там не один. И да! На самом деле выводит 80х25 символы 8х16, при этом видеорежим видимый 640х400@70Гц, физический 800х448.


Да, вы точно сказали. Никаких гоблинов и принцев. Только текст ее удел. Если на нее навесить графику, то простой схема уже не будет. Я очень люблю CP/M. И там ВГ75 как раз то что нужно. Ей можно доделать шину S100 или ISA8. Или как я на фото выкладывал вариант несколькими постами выше. Это законченный видеотерминал с поддержкой ESC-последовательностей ANSI/VT-52. Все что нужно - это сделать простенькую одноплатную машину с CP/M на z80 с COM-портом, подсоединить туда этот терминал и только в путь!

Мануалов не читаю, но очень хочу текстовую видеокарту 80х25 символы 8х16, при этом видеорежим видимый 640х400@70Гц для моего Ориона на шину а-ля ISA8 (она почти орионовская). Видится как плата расширения с одельным набортным буфером видео-ОЗУ и знакогенератором в набортном же ОЗУ, оба массива доступные для ПК на запись/чтение через порты в некотором диапазоне (условно, регистр адреса видеоОЗУ{запись} и регистр данных {запись/чтение}). Примерно то же, что и в приведенном выше проекте с контроллером на Меге, но без контроллера. :)

[freddy]

Да, да. Я как раз думал о варианте чисто видеокарты на ВГ75. Из схемы можно выбросить UART и клавиатуру. Из прошивки выбросить терминал, оставить только сам движок, который выгребает видеобуфер. На шину вывести 12бит адреса для адресации внутреннего буфера и 8бит данных. RD и WR завести на прерывания меги, CS формировать аппаратно, например на 155ЛА2 и 155ЛН1 либо взять чтото по современнее, типа 74НС688. Но от микроконтроллера отказываться не стоит. Просто я придумал уже логику работы видеобуфера, особенно с атрибутами поля. Логика довольно сложна. Но... видеобуфер всегда остается линейным, сколько бы атрибутов в нем не вставляли. Т.е. сохраняется закрепление знакомест за физическими адресами, а не как у всяких РК-клонов. Если убрать мегу и делать арбитр шин на логике, то это увеличит еще количество корпусов примерно на 10-15. Это возможно, но... сейчас опять полетят гнилые помидоры :) Если же мегу всетаки оставить, то это позволит цеплятся вообще за любую шину, ISA, S100, пофиг. Ног у меги много, хватит чтобы работать с набором управляющих сигналов любой древней шины.

[Error404]

С одной стороны, алгоритмы можно попробовать реализовать не в видеокарте, а в драйвере компьютера, к которому подключена видеокарта - лишь бы интерфейс с картой был быстрый (сократив модуль RS-232). Другое дело если Мега позволяет радикально сократить количество корпусов, то тогда можно (и даже нужно) оставить ее. Единственно, есть ли возможности заюзать какой-нибудь контроллер, для которого существует корпус в ДИПе? Например, AtMega32? Памяти встроеннной в ней, конечно, меньше, но возможно стоит смотреть в сторону использования внешней SRAM (какой-нибудь типа 32Кх8 или 64Кх8)? Чтобы и в цветах/атрибутах знакоместа себя не ограничивать, и знакогенератор сделать загружаемым в это ОЗУ, и несколько переключаемых "экранных плоскостей" (т.е. выбирать адрес откуда в ОЗУ лежит начало экрана). И как-то более "лампово" получится, и сподручно для пайки людям с руками заточенными только под ДИП. :) Будет 2 сороконогих БИС на карте.

[freddy]

Хватит и ATMega16, нужна будет внешняя память 8кб это еще +1 корпус. Получится 2 экрана. Знакогенератор программно не доступен, но есть несколько обходных путей. Это еще +2 корпуса.

[Error404]

Хватит и ATMega16, нужна будет внешняя память 8кб это еще +1 корпус. Получится 2 экрана. Знакогенератор программно не доступен, но есть несколько обходных путей. Это еще +2 корпуса.

Пару корпусов за загружаемые знакогенераторы - это вполне разумная плата. Зато какое дополнительное преимущество: от собственно загрузки шрифтов на вкус любого пользователя, до чанковой графики (если вместо 128 - надеюсь получится и 256 - символов загрузить требуемое количество знакомест с разной степенью и разной конфигурации заполненности их точками).

Что до экранов (экранных плоскостей), то можно Мегу и ВГ75 даже не ставить в известность о их существовании, потратив их ножки вместо старших адресов ОЗУ (адреса экрана) на еще какой-нить полезный расширенный функционал, а старшие адреса ОЗУ выбирать просто аппаратным портом (одним из - в диапазоне портов видяхи), установив на плате всего-то еще один регистр типа ТМ9/ИР23 (или подобных). При этом решение получится прозрачным и на той же самой прошивке способным работать с любым ОЗУ >= 4к, количество экранов ограничивается только имеющимся в наличии у пользователя ОЗУ. Поставил 8к - у тебя 2 экрана, поставил 64к - у тебя их уже 16. :)

Хотя... Очень полезный режим когда один экран видимый (тот, который сканируется и выводится ВГ75 на монитор), а другие - действительные (временно не видимые, но куда Мега выводит символы в данный момент - в какой буфер кладет). А это как я понимаю, должно быть под управлением Меги (и соответственно ее адресных ножек к ОЗУ). Т.е. активный и видимый экраны могут в какой-то момент быть одним и тем же экраном, а в какой-то (управляемо ESC-кодом), выбирать активный экран не совпадающий с видимым. Это было бы архиполезно для UZIX, порт которого уже есть, и где такую видяху можно было бы поддержать (когда многозадачные приложения выводят каждый в свой экран, при этом один из экранов активный - видимый и имеющий фокус ввода, а в остальные пишем в фоне).

Еще у меня есть вопрос и "I have a dream".
Вопрос: реализуем ли (или м.б. уже есть?) "аппаратный" скроллинг действительного экрана? Например, средствами Меги - "задать окно X*Y, в окне текст на N строк вверх/вниз, на N столбцов влево/вправо"? Эта операция достаточно много тактов съедает у CPU хоста (небыстрого старичка), и раз уж у нас на видяхе есть проц, то почему бы не распараллеливать подобные нагрузки? Чтобы понимать что Мега в процессе скроллинга байтов видеоОЗУ, да и вообще какой-то из длительных операций {если они есть} можно для CPU=драйвераОС вывести ножку "МегаЗанята")

И "a dream". Некий режим, когда можно просмотреть "уехавшее скроллингом за экран" (например, когда компилятор вывалил ошибки на экран, их было много, и они "уехали" из-за скроллинга). Типа как буфер в современных програмных терминалах типа Putty,Hyperterm и подобных, который можно "прокрутить вверх". Конечно, можно извратиться и такой "уезжающий" вывод команд перенаправить средствами ОС в файл, но не все ОС так умеют (например, CP/M 2.2 нативно не умеет). В реализации это получится резервирование под экранный буфер, скажем, вдвое большего места в ОЗУ (уж ОЗУ то найдем, 32к-64к вполне распространены), и таки та самая нами ранее съэкономленная внешним регистром ножка. При этом если окно действия скроллинга/очистки/покраски (то самое X*Y) стоит на весь экран, то по условию скроллинга на строку вверх не пересылать массив на 80 символов вверх, а увеличивать на 80 адрес начала сканирования, пока "окно 80*25" не опустится на дно буфера (MAX_адрес - 2000). А вот когда окно уже "лежит на дне буфера", то таки при очередном переводе строки придется делать пересылку содержимого буфера, причем уже вдвое большего. Стоит ли так заморочиться, или нунафиг, переложить на ОС?

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

Вот для пояснения темы с окнами (ограниченными экранными областями X*Y) и экранами 80*25 видимыми/активными во вложении описание экранного драйвера от Ориона-128.

[freddy]

Что до экранов (экранных плоскостей), то можно Мегу и ВГ75 даже не ставить в известность о их существовании,
Мегу придется ставить в известность. Переключать экраны желательно в момент окончания отображения кадра, там у ВГ75 есть флаг даже специальный и прерывание. Выводить его на шину и контролировать средствами старичка -это гембель. Не хочется каких то спецсигналов на шине. Пускай мега сама решает когда можно экран сменить.

поставил 64к - у тебя их уже 16.
Ух... Зачем так много? У MDA было 4к, у CGA 16к. Нам же 8кб (в режиме double buffering) хватит чтобы играть нечто типа такого https://www.youtube.com/watch?v=rFEc3f8TDFg


А это как я понимаю, должно быть под управлением Меги (и соответственно ее адресных ножек к ОЗУ). Т.е. активный и видимый экраны могут в какой-то момент быть одним и тем же экраном, а в какой-то (управляемо ESC-кодом),
Так и есть. Только меге все время доступно все видео ОЗУ, переключается экран просто подменой стартового адреса в прерывании, обслуживающем DMA ВГ75. И в видеокарте никаких ESC кодов не будет. На меге будет сэмулировано некоторое количество управляющих регистров, там и будет все переключаться.

Еще у меня есть вопрос и "I have a dream".
Вопрос: реализуем ли (или м.б. уже есть?) "аппаратный" скроллинг действительного экрана? Например, средствами Меги - "задать окно X*Y, в окне текст на N строк вверх/вниз, на N столбцов влево/вправо"? Эта операция достаточно много тактов съедает у CPU хоста (небыстрого старичка), и раз уж у нас на видяхе есть проц, то почему бы не распараллеливать подобные нагрузки? Чтобы понимать что Мега в процессе скроллинга байтов видеоОЗУ, да и вообще какой-то из длительных операций {если они есть} можно для CPU=драйвераОС вывести ножку "МегаЗанята")
Псевдо аппаратно реализуется вертикальный скроллинг в оба направления. В первую строку(она всегда там где начальный адрес отображения видеобуфера) заносится новая информация, затем к стартовому адресу добавляется 80. И теперь первая строка стала последней (буфер то кольцевой). В результате на экране происходит сдвиг изображения вверх на одну строку и в нижней последней строке новая инфа :) И так можно по кругу пока не надоест. Вниз скролить вычитанием 80 из стартового адреса. Горизонтальный скролл только программно. Раньше когда у меня был поддержан только терминал VT52, скролл экрана был аппаратным. Теперь, когда поддержан VT100, все стало программно, так как VT100 умеет скролить окна :)
Сигнал "Busy" противоречит маленько всей идеологии. Мега всегда свободна как для хоста так и для ВГ75. Прерывания однако :)

И "a dream". Некий режим, когда можно просмотреть "уехавшее скроллингом за экран" (например, когда компилятор вывалил ошибки на экран, их было много, и они "уехали" из-за скроллинга). Типа как буфер в современных програмных терминалах типа Putty,Hyperterm и подобных, который можно "прокрутить вверх".
Тут немного нужно попридержать коней. Никакая видеокарта так не умеет делать. Видеокарта же не для этого. Это все на совести программистов прикладных программ. Но если говорить о терминале (железном), то там есть режим Scroll Lock, как раз чтобы не затирались непрочитаные строки. Используется управляющие коды XON/XOFF. Что CP/M, что Unix, понимают эти коды, так что все возможно, памяти при этом много не надо.

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

Вобще мне сейчас больше всего хочется 256 символов в знакогенераторе, я уже почти оборудовал себе рабочий стол на новом месте жительства. Скоро смогу поэкспериментировать с сигналом LTEN.

[Error404]

Согласен по всем пунктам.
256 символов в ЗГ также архиважны.

собственно, получается большая часть моих хотелок так или иначе уже была реализована (а в VT100 оно или в VT52 или через регистры Меги управляется - это уже решаемо: я на уровне драйвера ОС смогу до удобного мне API "подровнять").

ASCII-арт прикольный. :) Я как-то давно его не видел, еще с времен матричников, а тут вон мульты уже в полный рост. :)
А с загружаемым знакогенератором, да с ЗГ в 256 символов - так и вообще обычные картинки можно будет на экран выводить как если бы это была не текстовая карта. С цветами покраски этой картинки конечно сложнее, но всяко не сложнее чем в Спектруме, где аналогично общий цвет на знакоместо 8х8 точек. А вон какой арт присутствует (на Спеке), покраска знакоместом преодолевается народом.

Единственно что, все же экранов хочется хотя бы 4 (в перспективе для UZIX - чтобы не писать общий десктоп с окнами, маловато ресурсов для этого, а налепить побольше терминалов/экранов tty0,tty1,tty2,tty3 и итерактивные приложения при параллельном выполнении раскидывать каждое в свой tty, переключаясь между ними по сочетанию клавишь как на Линуксе между 4-мя десктопами).

[creator]

а тут вон мульты уже в полный рост
Порекомендую старенький Star Wars — telnet towel.blinkenlights.nl :)

[Error404]

Порекомендую старенький Star Wars — telnet towel.blinkenlights.nl :)

Этот я видел в версии от vinxru на его ютуб-канале не то на Апогее, не то для еще его какого-то коллекционного компутера. Но это не сравнимо с тем что поссылке от freddy, ибо это действительнго арт, а StarWars - нечто из-под детского пера. :)

[Error404]

Ладно, не будем скатываться в холивар, ASCII мультики, пускай и примитивные ибо в 80*25 и 64к ОЗУ, интересны уже своим фактом наличия, ну и ОК, пусть с ним.

[Error404]

Скоро смогу поэкспериментировать с сигналом LTEN.

Ну как? Получилось?

[Error404]

Куда-то freddy пропал...

[freddy]

Ой пропал. Были трудности не технического характера. Но все получилось. Все перечисленное где то выше в постах, реализовано. При этом не добавилось новых корпусов, не хотел усложнять. Но курсор остался мигающей полоской сверху символа. Итого карта умеет: 7 цветов, подчеркивание сверху, мигание символов. Все 256 знаков знакогенератора отображаются одновременно. Схему на днях перерисую. Пока вот картинка:58385

Теперь надо из прошивки выкинуть терминал и только в путь!

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

фотик розовый цвет не передает как надо, в реалии картинка изумительна.

[freddy]

Вот такая теперь схема:58392
В основном изменения коснулись формирования цветов. Теперь вместо ЛП5 работает ЛИ1. Так выглядит красивее. Однако и у такой схемы есть один недостаток (а может быть и фича :) При атрибутах цветов 000, символ становится не виден и курсор тоже :) Это из-за того что фон всегда черный. Ну и теперь ПЗУ вместо 2716 стоит 2764. Код терминала пока перепиливаю под новые возможности. Получился просто некий переросток VT52/VT100 и недоросток ANSI. Вот думаю как лучше новые фичи привязать к DECовским управляющим последовательностям.
Когда додумаю, выложу. А что касается видеосистемы, так драйвер уже меняться не будет. Все отлажено и проверено. Осталось только развести печатную плату, там уже будет видно как разведутся ноги ATMEGA128 и какие порты будут входными. Сам видеодрайвер можно будет подправить под эти ноги. Пока пришел к выводу что не стоит разводить видеоконтроллер под определенную шину. Разведу на обычный 2-х рядный IDC-коннектор, можно будет подключить шлейфом от HDD хоть к ISA, хоть на прямую к процессорному модулю.
Видеокарте надо будет 4кб адресного пространства. Завести на нее хочу 12 бит адреса A0-A11, 8 бит данных (D0-D7), ~CS, ~WR, ~RD, ~RST.
~CS на нее пусть формируется дешифраторами самого компа, куда ее поставят.
Видеобуфер линейный: байт атрибутов, байт символа и т.д. Т.е. все атрибуты четные, символы не четные.

[Андрианов Игорь]

Внеземной красоты вариант вместо МК поставить 8080 или 8085, как впрочем и бывало в жизни.
Тут и ВВ51 вместо MAX подтянется ...
И здоровые шрифты бы из 15ИЭ

[Error404]

Внеземной красоты вариант вместо МК поставить 8080 или 8085, как впрочем и бывало в жизни.
Тут и ВВ51 вместо MAX подтянется ...
И здоровые шрифты бы из 15ИЭ

Не получится по простому: там ОЗУ используется из Меги, ПЗУ тоже из Меги. А на 8080 или 8085 в итоге получится РК86. :)
Кстати, freddy как на счет внешнего ОЗУ в одной статической MCX (а то внутреннего же только на одну плоскость хватает если в цвете)? А как же активные и видимые экраны, фреймбуферы и прочие красивости?

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



Когда додумаю, выложу. А что касается видеосистемы, так драйвер уже меняться не будет. Все отлажено и проверено. Осталось только развести печатную плату, там уже будет видно как разведутся ноги ATMEGA128 и какие порты будут входными. Сам видеодрайвер можно будет подправить под эти ноги. Пока пришел к выводу что не стоит разводить видеоконтроллер под определенную шину. Разведу на обычный 2-х рядный IDC-коннектор, можно будет подключить шлейфом от HDD хоть к ISA, хоть на прямую к процессорному модулю.
Видеокарте надо будет 4кб адресного пространства. Завести на нее хочу 12 бит адреса A0-A11, 8 бит данных (D0-D7), ~CS, ~WR, ~RD, ~RST.
~CS на нее пусть формируется дешифраторами самого компа, куда ее поставят.
Видеобуфер линейный: байт атрибутов, байт символа и т.д. Т.е. все атрибуты четные, символы не четные.

Хороший старт. А там - время покажет что где допилить.

[Андрианов Игорь]

РК86 тут не причем, я пишу о терминале с монитором VGA и режимом 80 х 25
у которого (естественно) есть свое ОЗУ и ПЗУ и никаких МК.

[Error404]

МК одним корпусом заменяет CPU, ОЗУ, ПЗУ, ПДП и всякую мелочевку типа тактового генератора, адресного дешифратора и логику сопряжения.

Если к ВГ75 добавить CPU, ОЗУ, ПЗУ, ПДП, всякую мелочевку типа тактового генератора, адресный дешифратор и логику сопряжения, то получится РК86. В виде терминала, да.

[Андрианов Игорь]

Любая плата на 580м комплекте с ВГ75 и процем = РК86 :)

МК - это как бы из другой эпохи, вот и все что я хотел сказать, все остальное - вопросы терминологии ;)

[freddy]

МК - это как бы из другой эпохи
Когда схема приобрела атрибуты цветов и 256 символов знакогенератора и линейный видеобуфер, микроконтроллер здесь стал просто необходим. Ибо все эти вкусности реализованы за счет интеллектуального эмулятора ПДП. Ведь это не МС6845 и буфер атрибутов всего 16 байт на строку, вот МК и занимается анализом предыдущего атрибута и последующего, а потом принимает решение, гнать его в ВГ75 или не надо. Все это для процов типа 8080 или 8085 будет тяжеловато. Логика работы предполагает в момент записи символа внешним процом, остановку цикла ПДП для ВГ75, если он в этот момент осуществлялся.
Все это означает что видеосистема должна выбирать байты из видеопамяти быстрее чем их туда может положить внешний проц. Поэтому АТМега там. Это позволит юзать видяху с компами на 8080, 8085, 8086, 8088. В общем все что до 10Мгц должно работать. С мегой оно дает 208fps. Что более чем достаточно, развертка монитора всеравно 72fps :).
А вообще так немного скачусь во флейм. Мегу меня побудило поставить наличие удобных средств отладки.

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

Можно всеже и без МК и без проца. Схема будет размером с CGA адаптер :)

[Андрианов Игорь]

Ваш выбор полностью понятен и естественно оправдан.
Я же "о красоте и высоте штиля" ;)
Нашего аналога 8085 наверное (!) все-таки хватило бы по скорости. Вы уж простите, что не могу остановиться :v2_dizzy_vodka3:

[Error404]

как на счет внешнего ОЗУ в одной статической MCX (а то внутреннего же только на одну плоскость хватает если в цвете)? А как же активные и видимые экраны, фреймбуферы и прочие красивости?


Такое предложение чтобы обойтись без внешнего ОЗУ: первый режим (каждый символ своим атрибутом/цветом) оставить как есть, но добавить режим (переключать режимы ESC-кодом) когда один атрибут действует на целую строку (итого буфер экрана (80+1)*25=2025 байт) и разместить два буфера (выбираемые ESC-кодом): активный экран (куда пишутся данные) и видимый экран (который ВГ75 выводит). Ведь во многих случаях обычно весь экран требуется покрасить одним и тем же цветом (а многие операционные системы вообще монохромные), максимум - строку состояния выделить или строку подсказки.

Второе предложение: ввести программируемый регистр палитр в памяти Меги чтобы можно было esc-кодом задать более разнообразные сочетания (вариации) для 8 цветов.

А фон как-нибудь планируется обрабатывать, или он константно черный?

[barsik]

Из ВГ75 можно выжать до 64 строк, в каждой из которых - до 80 знакомест. Однако, если надо использовать так назваемые атрибутные команды, то число знакомест в строке приходится выбирать меньше. Кроме того, этот CRT контроллер поддерживает вывод 11 символов для рисования рамок. Авторы РК86 зря не ввели это в свой компьютер, т.к апаратно это обходится всего в несколько диодов и резистор.

Также используя псевдографический фонт можно иметь полноценный графический режим. Так как код символов 7-ми битовый, т.е всего 128 разных символов, то максимально знакоместо можно разбить на матрицу псевдографики 2x3 или 3x2 (причем 3x2 выгоднее, чтобы иметь больше точек по горизонтали). В обоих случаях фонт для вывода псевдографики будет занимать 64 символа. Иметь матрицу 3x3 мы уже не может, т.к тогда потребуется уже 512 пседографических символов (а у нас их лишь 128). Таким образом теоретически максимальная графика - это 80*3=240 точек по горизонтали и 64*2=128 точек по вертикали. Но в схемотехнике РК86, из-за особенности формирования кадрового и строчного бланков разрешение получится немного меньше.

Однако мы забыли одну вещь. Быстродействие компьютера, в котором работает ВГ75 напрямую зависит от числа строк. Рассмотрим РК86. Уже в стандартном режиме, т.е при 30 строках, более 25% времени КР580 остановлен захватом шины и ожидает конца работы ПДП. Реальная скорость РК86 при такте CPU в 1.77 МГЦ оказывается меньше чем 1.3 МГЦ. А при 60 строках процессор стоит уже 25*2=50% времени. При 64 строках КР580 работает лишь 47% времени, что даёт реальный такт около 800 КГЦ.

Кроме того псевдографика менее удобна в программировании графики. Для вывода текста в графическом режиме это не проблема (т.к есть драйвер вывода символов и он всё делает за Вас). Но при желании выводить по-пиксельную графику Вам придётся программировать самому, а для псевдографики это сложно и очень медленно.

Базовый РК86 использует матрицу псевдографики всего 2x2, что даёт формат графического экрана используя стандартный экран - 64*2 x 30*2, т.е 128 на 60. А при перенастройке ВГ75 на 64 строки 128x128, хотя при этом Вам придется одновременно перенастроить экранную область на адрес ниже 7600H (иначе экран уничтожит служебные ячейки ПЗУ и РК зависнет. Такая графика РК86 впервые была продемонстрирована на 34 всесоюзной радиовыставке в 1989 году.

Аппаратные затраты на введение графического режима за счёт второго фонта составляют всего 10 сантиметров провода (и при еобходимости тумблер). В ПЗУ знакогенератора (РФ2) допрошивается второй килобайт, содержащий 64 псевдографических символа. А проводом соединяют один бит порта C ППА D14 с адресом A10 ПЗУ знакогенератора. Тумблер необходим для отключения управления фонтом. Иначе ППА D14 будет неудобно использовать для внешних устройств. Например для программатора УФ-ПЗУ, т.к тогда при его работе фонт будет хаотично переключаться.

[Error404]

Переведу сообщение barsik:


Из ВГ75 можно выжать до 64 строк, в каждой из которых до 128 знакомест. Если надо использовать так называемые атрибутные команды, то число знакомест в строке приходится выбирать меньше. Кроме того, ВГ75 поддерживает вывод 11 символов для рисования рамок. Авторы РК зря не ввели это в свой компьютер, т.к апаратно это обходится в несколько диодов и резистор.

Используя псевдографический фонт на ВГ75 можно иметь графический режим. Т.к в фонте всего 128 символов, то максимально знакоместо можно разбить на матрицу псевдографики 2x3 или 3x2 (3x2 выгоднее, чтобы было больше точек по горизонтали). В обоих случаях фонт псевдографики будет занимать 64 символа. Иметь матрицу 3x3 мы уже не может, т.к тогда потребуется 512 пседографических символов (а есть лишь 128). Таким образом теоретически максимальная графика - это 128*3=384 на 64*2=128, т.е 384x128.

Но в РК86 режим 384*128 не получить, т.к нельзя изменить кварц. Иначе мы потеряем стандартный текстовый режим, т.е совместимость. Поэтому в РК ВГ75 всегда должен быть запрограммирован на 78 знакомест в строке. Таким образом максимальная графика для РК - 64*3=192 на 64*2=128, т.е 192x128. В этом режиме можно выводить 32 символа в 16 строках, или с некрасивым фонтом 5*8 - 38 символов в 16 строках. Важно, что такой режим обеспечивает вывод не только КОИ-8, но и вообще любых символов.

Псевдографика неудобна в программировании. Для вывода текста в графическом режиме это не проблема (т.к есть драйвер вывода символов, и он всё делает за Вас). Но при желании выводить по-пиксельную графику Вам придётся её самостоятельно программировать, а для псевдографики это сложно.

С базовым фонтом псевдографика РК86 имеет матрицу всего 2x2, что даёт формат графического экрана при 30 строках - 64*2 x 30*2 = 128x60. А при настройке ВГ75 на 64 строки - 128x128. Причём при 64 строках приходится переставлять экранную область на адрес ниже 7600H (иначе экран двойного размера уничтожит служебные ячейки ПЗУ и РК зависнет). Графика 192x128 впервые на РК86 была продемонстрирована на 34 всесоюзной радиовыставке в 1989 г (смотри в РАДИО статью о выставке).

Аппаратные затраты на режим 192x128 составляют всего 10 сантиметров провода (и, при необходимости, тумблер). В ПЗУ знакогенератора (РФ2) допрошивается второй килобайт, содержащий 64 псевдографических символа. А проводом соединяют один бит порта C ППА D14 с адресом A10 ПЗУ знакогенератора. После этого можно управлять выбором текущего фонта программно. Тумблер необходим для отключения управления фонтом. Иначе ППА D14 будет трудно использовать для внешних устройств. Например для программатора УФ-ПЗУ, т.к при его работе фонт будет хаотично переключаться, отчего экран будет мигать.

К сожалению быстродействие компьютера, в котором работает ВГ75, напрямую зависит от числа строк. Рассмотрим РК86. Уже в стандартном режиме, т.е при 30 строках, более 25% времени КР580 остановлен захватом шины и ожидает конца работы ПДП. Реальная скорость РК86 при такте CPU в 1.77 МГЦ оказывается меньше чем 1.3 МГЦ. А при 60 строках процессор стоит уже 25*2=50% времени. При 64 строках КР580 работает лишь 46% времени, что даёт Вам реальный такт 800 КГЦ.

Поднять быстродействие на пару процентов можно вставляя после последнего символа каждой строки, отличного от 0 или пробела, управляющий код "конец строки". Другим, более кардинальным методом увеличения быстродействия, является тактирование КР580 и ПДП повышенным тактом (как описано в РАДИО 01.1991). Такт на ВГ75 должен остаться 16 МГЦ. Ставится отдельный генератор на 531ЛН1 с кварцем 25...32 МГЦ. Если шина не перегружена (т.е если 2 банки РУ3 заменены на банку РУ5-тых и никаких В/У не подключено), то КР580 работает на такте 32:9= 3.55 МГЦ. Реальное быстродействие при этом в режиме 30 строк достигает 3 МГЦ, т.е РК86 оказывается быстрее ZX-Spectrum (где, из-за WAIT, реальный такт менее 3 МГЦ).

Можно поднять быстродействие РК86 ещё на 5-10%, если настроить ВГ75 на 25 строк (соответственно увеличив число линий растра отведенных на обратный ход по кадрам). РК86 непонятно зачем выводит 30 строк, хотя официально используются только 25. Причём все 30 строк даже не видно (видно 27-28). Это происходит из-за того, что слишком мало линий растра выделено на обратный ход по кадрам. А чтобы на РК86 были видны 30 строк, достаточно настроить ВГ75 на высоту знакоместа не 10 линий растра, а 9.

[Ewgeny7]

Из ВГ75 можно выжать до 64 строк, в каждой из которых до 128 знакомест. Если надо использовать так называемые атрибутные команды, то число знакомест в строке приходится выбирать меньше. . . . .
апраролкдддкщкщгкн? папроаллааьд :)

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


Из ВГ75 можно выжать до 64 строк, в каждой из которых до 128 знакомест. Если надо использовать так называемые атрибутные команды, то число знакомест в строке приходится выбирать меньше. . . . .
Кодировка ISO-8859-1.
barsic, поправь на правильную.

[freddy]

Такое предложение чтобы обойтись без внешнего ОЗУ:
зачем же без ОЗУ? у всех наверняка валяется кучка SRAM от кэшей старых 386 и 486. Надо же куда то приспособить :)
Если нужен монохром, подаете на A0 видяхи лог."1", оставшиеся 11 адресов заводите на A0-A10 компа. В результате комп пишет подряд только в нечетные адреса, там где символы. Видяха же инициализируется самостоятельно, т.е. настраивать там ничего не надо. По умолчанию выбран белый цвет. Все работает, все счастливы. Для РК-водов самое то вместо штатной видеосистемы. РК будет быстро работать, ПДП его не будет тормозить + проц можно подразогнать. Еще в придачу полный набор раскладки CP866 с русским и всякими там значками для таблиц.

(выбираемые ESC-кодом):
Это уже не модно. 4096-4000=96. У нас есть целых 96 байт в запасе. Там располагаем управляющие регистры курсора и переключалку страниц. Можно еще аппаратный сроллинг и флаг окончания развертки кадра :)

Второе предложение: ввести программируемый регистр палитр в памяти Меги
Отличная идея, только в схему прийдется вводить Video DAC. Как его по проще сделать, подумаю.


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

Из ВГ75 можно выжать до 64 строк, в каждой из которых до 128 знакомест
128 знакомест это жОстко. Как это вобще возможно?

[АлександрПП]

Исправленное сообщение участника форума barsik.
У него трудности с прямым участием в работе форума, поэтому пока сообщения идут через меня.:

barsik благодарит FREDDY за замеченные ошибки в оригинальном сообщении и приводит новый исправленный вариант.

Хочу отметить не скоростные характеристики ВГ75, а графические.

ВГ75 может выводить до 64 строк, в каждой строке до 80 знакомест. Аппаратно ВГ75 поддерживает вывод 11 символов для рисования рамок. Авторы РК зря не ввели это в свой компьютер, т.к апаратно это обходится в несколько диодов и резистор.

Используя псевдографический фонт на ВГ75 можно иметь графический режим. Вывод сплошной графики в стандартном режиме ВГ75 невозможен, т.к в нём между знакорядами есть две пустые линии растра. Поэтому при включении режима графики ВГ75 перенастраивают на высоту знакомест в 8 линий растра вместо 10, благодаря чему символы по вертиками примыкают друг к другу и в экран легко умещается 32 строки.

Т.к в фонте 128 символов, то максимально знакоместо можно разбить на матрицу псевдографики 2x3 или 3x2 (3x2 выгоднее, чтобы иметь больше точек по горизонтали). В обоих случаях фонт псевдографики будет занимать 64 символа. Иметь матрицу 3x3 мы уже не может, т.к тогда потребуется 512 символов (а есть лишь 128). Таким образом теоретически максимальная графика выводимая с помощью ВГ75 это 80*3 x 64*2, т.е 240x128.

В РК86 число видимых в строке знакомест равно 64 и максимальная графика получается 64*3 x 64*2, т.е 192x128. Такой графический режим позволяет вывести 32 символа в 16 строках. Важно, что при этом обеспечивается вывод не только КОИ-8, но и вообще любых символов. Скорость вывода символов превосходит скорость настоящей графической ЭВМ с таким же фонтом (символ 6*8 выводится записью в экран 8-ми байт, причем перепаковка байтов на 6 точек, сдвижка и маскирование знакомест не требуются).

Псевдографика неудобна в программировании. Для вывода текста в графическом режиме это не проблема (т.к есть драйвер вывода символов, и он всё делает за Вас). Но при желании выводить по-пиксельную графику Вам придётся её самостоятельно программировать, а для псевдографики это сложно.

Псевдографика прошитая в базовый фонт РК имеет матрицу всего 2x2, что даёт формат графического экрана при 32 строках - 64*2 x 32*2 = 128x64. А при 64 строках - 128x128. Причём при числе строк более 30 приходится переставлять экранную область на адрес ниже 7600H (иначе экран большего размера уничтожит служебные ячейки ПЗУ и РК зависнет). Графика 192x128 на ВГ75 впервые была продемонстрирована на 34-й всесоюзной радиовыставке в 1989 г (смотри в РАДИО статью о выставке).

Аппаратные затраты на режим 192x128 составляют всего 10 сантиметров провода (и, при необходимости, тумблер). В ПЗУ знакогенератора (РФ2) допрошивается второй килобайт, содержащий 64 псевдографических символа. А проводом соединяют один бит порта C ППА D14 с адресом A10 ПЗУ знакогенератора. После этого можно управлять выбором текущего фонта программно. Тумблер необходим для отключения управления фонтом. Иначе ППА D14 будет трудно использовать для внешних устройств. Например, для программатора УФ-ПЗУ, т.к при его работе фонт будет хаотично переключаться, отчего экран будет мигать.

К сожалению, быстродействие компьютера, в котором работает ВГ75, напрямую зависит от числа строк. Рассмотрим РК86. Уже в стандартном режиме, т.е при 30 строках, более 25% времени КР580 остановлен захватом шины и ожидает конца работы ПДП. Реальная скорость РК86 при такте CPU в 1.77 МГЦ оказывается меньше, чем 1.3 МГЦ. А при 60 строках процессор стоит уже 25*2=50% времени. При 64 строках КР580 работает лишь 46% времени, что даёт Вам реальный такт 800 КГЦ.

Существенно поднять быстродействие РК86 позволяет тактирование КР580 и ПДП повышенным тактом (как описано в РАДИО 01.1991). Такт на ВГ75 должен остаться 16 МГЦ. Ставится отдельный генератор на 531ЛН1 с кварцем 25...32 МГЦ. Если шина не перегружена (т.е если 2 банки РУ3 заменены на банку РУ5- тых и никаких В/У не подключено), то КР580 работает на такте 32:9= 3.55 МГЦ. Реальное быстродействие при этом в режиме 30 строк достигает 3 МГЦ, т.е РК86 оказывается быстрее ZX-Spectrum (где, из-за WAIT, реальный такт не превышает 3 МГЦ).

Можно поднять быстродействие РК86 ещё на 5-10%, если настроить ВГ75 на 25 строк (соответственно увеличив число линий растра отведенных на обратный ход по кадрам). РК86 непонятно зачем выводит 30 строк, хотя официально используются только 25. Причём все 30 строк даже не видно (видно 27-28). Это происходит из-за того, что слишком мало линий растра выделено на обратный ход по кадрам. Чтобы на РК86 увидеть 30 строк, достаточно настроить ВГ75 на высоту знакоместа в 9 линий растра, вместо 10.

[freddy]

Уважаемый barsik! Радио86рк очень странный компьютер. Я потратил много времени, пытался разобраться, что же двигало авторами. Часами всматривался в схему, пытаясь увидеть там скрытый смысл, все бесполезно. Свои выводы я подробно не стану описывать. В итоге моя схема и идеология ничего общего с РК не имеет. Просто у всех ВГ75 чего то с РКшкой ассоциируется.
И ещё КР580ВГ75 может выводить монохромную графику 640x400. Достаточно лишь обеспечить доступ центрального проца в адресное пространство знакогенератора и буферизацию записи. Либо без буферизации, но с тактированием проца от задающего генератора видеокарты... Тут тоже много вариантов и все рабочие. Заставить ВГ75 перебирать последовательно 32000 байт знакогенератора очень просто. И получите нормальную графику, которую очень удобно программировать. Псевдографика же... Это просто Жэ.

[freddy]

Ну вот, по терминалу все. В архиве новая печатная плата, прошивка и схема, шрифты. Работает изумительно. Схему привел в соответствие с печаткой. На этой печатке я еще не собирал.
Отличия от VT100: атрибуты жирный - > синий, инверсный -> зеленый. Одновременно жирный и инверсный -> аквамарин. Раскладка у VT100 своя, у меня CP866. VT100 допускает отображение без переключения ЗГ только 128 символов (7бит). ЗГ переключается принудительно. У меня можно отображать 256 символов, все переключается само. Помните о раскладке. У меня CP866, поэтому соответствующим образом настраиваете консоль сервера или еще чего то там. В любом случае вариант с транслитом всегда работает. Если же русский не надо, на раскладку можно забить, первые 128 символов везде одинаковые.
58501

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

На днях будет видеокарта, пока без внешнего ОЗУ.

[freddy]

Родил схему типа параллельный интерфейс. Для упрощения забил на режим чтения, в видеокарту можно только писать. Читать по-моему нет необходимости, На КР580ИР82 собрана защелка входных данных и адреса, куда эти данные положить. На К555ИД7 собран дешифратор верхней половины адресного пространства. Т.е. старшие 32Кб из 64Кб, разбиты на 8 страниц по 4Кб. С помощью джампера можно выбрать, где должен лежать видеобуфер. Если у кого то больше 64Кб, дешифруйте старшие ареса дополнительно сами. Для этого у ИД7 остался еще один свободный разрешающий вход.
58530

На этой схеме родил видео ЦАП. Он позволяет выбрать любые 8 цветов из 256. Запись цветов в регистры возможна в момент вертикального обратного хода, когда они не нужны видеогенератору. Для этого там есть мультиплексор К555КП11, переключающий доступ между ВГ75 и АВР. +10 корпусов однако... Думаю насчет целесообразности ввода палитры. Что скажете? Может можно сделать как то проще? Или вобще не делать. Зачем текстовой видюхе столько цветов?
58529

Сейчас проект на стадии разводки печатной платы. Софт уже готов.

[A_AVL]

Я полагаю, что для текста достаточно восьми цветов.

[Error404]

Родил схему типа параллельный интерфейс. Для упрощения забил на режим чтения, в видеокарту можно только писать. Читать по-моему нет необходимости, На КР580ИР82 собрана защелка входных данных и адреса, куда эти данные положить. На К555ИД7 собран дешифратор верхней половины адресного пространства. Т.е. старшие 32Кб из 64Кб, разбиты на 8 страниц по 4Кб. С помощью джампера можно выбрать, где должен лежать видеобуфер. Если у кого то больше 64Кб, дешифруйте старшие ареса дополнительно сами. Для этого у ИД7 остался еще один свободный разрешающий вход.


А как АТМега определяет, что в регистрах актуальные данные? Т.е. что хост туда не записал уже несколько раз. Ну или Хосту как перед записью понять что Атмега предыдущее уже обработала? Стоит ли на это заморачиваться? Какие там получатся временнЫе требования (запас по времени к следующей записи от хоста)?



На этой схеме родил видео ЦАП. Он позволяет выбрать любые 8 цветов из 256. Запись цветов в регистры возможна в момент вертикального обратного хода, когда они не нужны видеогенератору. Для этого там есть мультиплексор К555КП11, переключающий доступ между ВГ75 и АВР. +10 корпусов однако... Думаю насчет целесообразности ввода палитры. Что скажете? Может можно сделать как то проще? Или вобще не делать. Зачем текстовой видюхе столько цветов?
Сейчас проект на стадии разводки печатной платы. Софт уже готов.

ИМХО 8 из 256 более чем достаточно. Даже 8 из 64 (или даже 8 из 32) достаточно. Вот фон бы еще обработать, хотя бы в виде весь экран фоном одного цвета.
А сколько атрибутов (и какие) реализованы, если на цвет из 8 битов остается только 3 бита?

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

ВГ75 умеет от управляющего сигнала (или команды) переводить выводы LCx, CCx, RVV в Z-состояние? Если умеет, то добавлением одного буфера (между ШД и данными U7), заменой ПЗУ 2764 на ОЗУ и задействованием IA12 можно было бы вслед за 4к экранной области разместить в адресном пространстве хоста 4к знакогенератора. Т.е. сделать знакогенератор загружаемым, что значительно повысило бы функционал.

[freddy]

А как АТМега определяет, что в регистрах актуальные данные?
На схеме есть сигнал ~MWR, он вызывает прерывание, в обработчике забираются данные и адрес.


Ну или Хосту как перед записью понять что Атмега предыдущее уже обработала?
Изначально подразумевается что Хост медленнее видеокарты. Все расчитано на процы типа 8080, Z80, 8085, 8086 с тактовой частотой мегагерц 5. Работать на шине "серьезного" проца, АТ-Мега не осилит.


А сколько атрибутов (и какие) реализованы,
Задействованы все. RVV - переключалка ЗГ, GP0-синий,GP1-красный, HGLT-зеленый, LTEN-курсор. Больше у ВГ75 нет.

ВГ75 умеет от управляющего сигнала (или команды) переводить выводы LCx, CCx, RVV в Z-состояние?
Не умеет.
Для того чтобы получить загружаемый ЗГ, ну и как побочный эффект, графику 640х400, нужно еще 3 мультиплексора 8 в 4, три регистра для защелкивания данных и адресов от проц, ну и конвейер который, сам автоматом их туда положит в момент, когда ЗГ не нужен ВГ75. А нужен он там всего 1 такт из восьми.
Все не так просто, но и не сложно.

[Error404]

Изначально подразумевается что Хост медленнее видеокарты. Все расчитано на процы типа 8080, Z80, 8085, 8086 с тактовой частотой мегагерц 5. Работать на шине "серьезного" проца, АТ-Мега не осилит.


Ну, значит практика покажет. Думается мне что и 10 МГц потянет (ведь хост пишет в циклах обращения, наши процы выполняют по нескольку тактов между каждым обращением в память, в отличии от Меги работающей за 1 такт). 10Мгц - это магическое число (+-), до которого все и гонят Z80 (выше уже нереал для компов на россыпухе).



Задействованы все. RVV - переключалка ЗГ, GP0-синий,GP1-красный, HGLT-зеленый, LTEN-курсор. Больше у ВГ75 нет.


Т.е. в памяти из целого байта атрибутов заняты только 5 бит? И три свободно. А Мега читает с хоста и по запросу ДМА от ВГ75 выставляет на ШД "Мега<->ВГ75" все 8 битов.
Насколько сложно аппаратно определить что в данный момент читается ВГхой из Меги - символ или атрибуты? И если не сложно, то и защелкивать в момент чтения атрибутов "потерянные" ВГхой 3 бита с выводов Меги в доп.регистр. Вот и получим или дополнительные градации цвета (т.е. RGB уже по 2 бита на сигнал, т.е. 64 цвета) или цветность для фона (8 цветов букв + 8цветов фона), причем для каждой буквы. Красота! :)
Причем если поставить 1533ИР38 (два 4бит регистра в одном корпусе вместо одного 8бит) вместо U19 (старшие адреса), то и лишний корпус регистра можно съэкономить.



Для того чтобы получить загружаемый ЗГ, ну и как побочный эффект, графику 640х400, нужно еще 3 мультиплексора 8 в 4, три регистра для защелкивания данных и адресов от проц, ну и конвейер который, сам автоматом их туда положит в момент, когда ЗГ не нужен ВГ75. А нужен он там всего 1 такт из восьми.
Все не так просто, но и не сложно.

Идеологически понятно, но схемотехнически получается громоздко. Тогда предлагаю предусмотреть возможность "секционированной" ПЗУ знакогенератора - несколько блоков, которые выбираются регистром (например, замапленным на неиспользуемые ячейки из 4к видеобуфера) чтобы "хотелки к загружаемым данным" изначально прошить в ПЗУ. Один хрен ставить ПЗУ 2764 не имеет смысла - их даже на помойках сейчас уже не найти, а к примеру W27c512 пока продается, стоит копейки, она в таком же корпусе DIP28 и 64к вместо 8к. Т.е. все равно при сборке поставим более емкую ПЗУ с "занулеными" старшими адресами. А так, в первом блоке можно прошить собственно знакогенератор, во втором - примитивы для рисования, далее каждый по желанию: фонты, логотипы, что душа пожелает. Записал в этот регистр/ячейку 0 (или по Сбросу) - получи текстовый режим, записал 1 - чанковая графика, 2 - еще один "более другой фонт", и т.д. ...
Аппаратно это лучше сделать в Меге (ибо корпусов 1533 и так уже перебор): значения регистра она прочитает от Хоста аналогично прочим данным и соответствующе (увидев по значению адреса) выставит одну/две/три/... из своих свободных ножек в 0/1, эти ножки завести на старшие разряды ПЗУ.

[freddy]

Т.е. в памяти из целого байта атрибутов заняты только 5 бит? И три свободно. А Мега читает с хоста и по запросу ДМА от ВГ75 выставляет на ШД "Мега<->ВГ75" все 8 битов.
Насколько сложно аппаратно определить что в данный момент читается ВГхой из Меги - символ или атрибуты? И если не сложно, то и защелкивать в момент чтения атрибутов "потерянные" ВГхой 3 бита с выводов Меги в доп.регистр. Вот и получим или дополнительные градации цвета (т.е. RGB уже по 2 бита на сигнал, т.е. 64 цвета) или цветность для фона (8 цветов букв + 8цветов фона), причем для каждой буквы. Красота!
Причем если поставить 1533ИР38 (два 4бит регистра в одном корпусе вместо одного 8бит) вместо U19 (старшие адреса), то и лишний корпус регистра можно съэкономить.

Мега всегда знает, что вычитывает ВГ75. Мега никогда не знает, что в текущий момент выводит ВГ75. Ибо ВГ75 читает наперед, так чтоб с запасом, стремясь получить не менее одной строки символов в запасе. Да и формат байта атрибутов строго оговорен в документации на ВГ75, нет там ничего лишнего.

Идеологически понятно, но схемотехнически получается громоздко. Тогда предлагаю предусмотреть возможность "секционированной" ПЗУ знакогенератора - несколько блоков, которые выбираются регистром (например, замапленным на неиспользуемые ячейки из 4к видеобуфера) чтобы "хотелки к загружаемым данным" изначально прошить в ПЗУ. Один хрен ставить ПЗУ 2764 не имеет смысла - их даже на помойках сейчас уже не найти, а к примеру W27c512 пока продается, стоит копейки, она в таком же корпусе DIP28 и 64к вместо 8к. Т.е. все равно при сборке поставим более емкую ПЗУ с "занулеными" старшими адресами. А так, в первом блоке можно прошить собственно знакогенератор, во втором - примитивы для рисования, далее каждый по желанию: фонты, логотипы, что душа пожелает. Записал в этот регистр/ячейку 0 (или по Сбросу) - получи текстовый режим, записал 1 - чанковая графика, 2 - еще один "более другой фонт", и т.д. ...
Аппаратно это лучше сделать в Меге (ибо корпусов 1533 и так уже перебор): значения регистра она прочитает от Хоста аналогично прочим данным и соответствующе (увидев по значению адреса) выставит одну/две/три/... из своих свободных ножек в 0/1, эти ножки завести на старшие разряды ПЗУ.

Громоздкого там ничего нет. Меня остановило совсем другое. Рассчеты показывают, что 640х400 - тяжеловато для большинства 8-ми битных систем, именно поэтому я графику пока не трогаю. Регистры палитры тоже потом. Пускай конструкция будет простой. А вот переключалку страниц ЗГ - это можно хоть сейчас, можно кучку шрифтов зашить :)

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

Немного поразмыслив, пришел к выводу что буфер атрибутов можно построить в обход ВГ75. Синхронизировать работу можно по сигналам HRTC и CCLK.
Смысл в том что по аналогии с ВГ75 придется построить свои 2 буфера по 80 байт, символы выводить в ВГ75, а атрибуты в свой буфер. Счет начинать от конца HRTC, атрибуты из буфера выводить по CCLK. Переключалка буферов должна начинать считать от конца VRTC. Как только поднялась DRQ и выдалось 80 байт в ВГ75 и 80 байт в атрибуты, переключаем буфер. Под переключалкой я подразумеваю переключение счетчика адресов буфера. При записи от меги, счетчик адресов тактируется сигналом WR. А при чтении сигналом CCLK от видео генератора.

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

в итоге один буфер читается, один пишется, потом они меняются.
И снова я прихожу к мысли, что ВГ75 как бы становится лишней. Поэтому лучше пускай работает, на сколько хватает ее возможностей.

[barsik]

Радио-86РК очень странный компьютер

Конечно, РК86 удивляет. На первый взгляд он разработан по-идиотски. Точнее странно использует ВГ75. Например, координаты POSX, POSY сдвинуты на 8 и 3, отчего в драйвере ПЗУ приходится исхитряться для вывода в окно 64*25. Однако для этого есть причины.

Хотя то, что РК, заложенные в ВГ75 возможности, использует лишь наполовину, это неоспоримый факт. Самое обидное, что инверсия, вывод рамочек и второй фонт КОИ-8 обошлись бы всего в пару корпусов (ценой по 40 копеек). Если бы вместо ИЕ4 поставили ИЕ5, то РК имел бы красивый фонт 8*8, вместо убогого 6*8. Что сделало бы РК машиной для текстообработки. Добавка цвета сделала бы красивыми игры. А грамотный выбор адресации портов дал бы 60К ОЗУ и фактически превратил бы его в "Роботрон-1715". А главное, - тогда РК стал бы совместимым с сотнями ЭВМ в мире.

Это даже не случай, когда скупой платит дважды. Это случай, когда экономия фактически превратила саму идею РК в нонсенс.

При разработке РК не работал принцип 'Если взялся что-то делать, то делай хорошо'. Одно дело когда ты паяешь что-то на кухне для себя. А другое дело, когда ты лезешь в самый массовый журнал страны, что имеет следствием выпуск сотен тысяч плат РК и клонов, и миллионы впустую истраченных народных денег. Если бы за окном был 37-й год, то авторы РК точно были бы объявлены врагами народа.


Радио-86РК... Я потратил много времени, пытаясь разобраться, что же двигало его авторами. Часами всматривался в схему, пытаясь увидеть там скрытый смысл, - всё бесполезно

Ранее я не понимал схемных решений авторов РК86. Но когда я решил посчитать будут ли в нём регенерироваться SIMM с 10/12-ти битовым вектором регенерации, всё стало ясно.

Т.к экран в РК86 - 78*30, то даже не учитывая, что растр РК не влезает в экран, при попытке использовать 30 строк для текста произойдет срыв синхронизации по кадрам. И по строкам то же самое. Никакой телевизор или монитор ничего не выведет с таким видео-сигналом. Как можно объяснить всё это? Ведь установив размер строки в 64+4 байта (4 на атрибуты) и стандартные 25 строк, получаем экономию в 78*30-68*25 = 640 байт. Зачем их тратить впустую, когда ОЗУ и так не хватает. Но ведь не идиоты же авторы РК86? Остаётся думать, что для того, чтобы сделать такой режим ВГ75, у них были причины.

Вспомним, что в РК86 стоят ОЗУ 565РУ3 с временем регенерации 2 МСЕК. Вывод строки длится 640 МКСЕК. Для регенерации РУ3-х надо считать подряд 128 адресов. В строке перебирается 78 адресов. Итого, для регенерации требуется 2 строки и период 1.28 МСЕК вполне укладывается в допуск 2 МСЕК.

Кадровый период состоит из 312 строчных периодов. Видимый растр выводится за 250 строчных периодов. 62 строчных периода отводятся на гашение экрана по кадрам - т.е кадровый бланк. На 62 строчных периода приходится 6 строк по 10 линий растра.

Таким образом в идеале надо запрограммировать ВГ75 на вывод неотображаемых 6-ти строк на обратный ход кадровой развёртки. Но тогда на время вывода 6-ти строк не будет выполняться регенерация ОЗУ. С учётом того, что регенерация занимает 2 строки, период регенерации составит 8*64*10= 5.12 МСЕК, что явно больше необходимых 2-х МСЕК.

Это и объясняет почему схемотехника РК86 такая.

Авторы, применив динамические ОЗУ и отказавшись от специальных схем регенерации, просто вынуждены были растянуть экран по вертикали до 30 строк (включив тем самым бордюр в экран) и имитировать бордюр программно. Они действовали по РТМ, зная, что при большом числе строк на обратный ход луча по кадрам, будет перерыв регенерации и потеря данных в ОЗУ. Поэтому они и применили минимальное число строк на обратный ход луча и программное формирование "гашения по кадрам".

Таким образом авторы РК86 не были идиотами. Однако тот же программный способ они сдуру применили и для формирования ССИ и бордюра по строкам, затемнив по 7 знакомест слева и справа от строки, за счёт заполнения нулями. Тут это уже не объяснить ничем, кроме желания с'экономить 1 корпус 155-той серии.

Применение аппаратного ССИ и аппаратного бордюра по строкам, ускорило бы прогон, с'экономило бы 14*30=420 ячеек памяти, но главное - позволило бы произвольно программно менять режим дисплея, т.е число символов в строке. А сейчас мы жёстко связаны необходимостью иметь 78 символов в строке. Кстати ровно столько надо, чтобы частота строк была правильной. Строчный период: 78*(6:8) + 6*(6:8)= 64.5 МКСЕК.

Что, жёстко проехал по авторам РК? Согласен. Они были первыми, ещё когда мы слово микропроцессор считали матерным и плевались, получая ж.РАДИО со статьями о КР580. Не спорю, у авторов есть заслуги перед отечеством в сфере компьютеризации и большое спасибо им за это. Но это не отменяет их ошибок.

И полагаю, что все мы "выросли из коротких штанишек РК86". Эта странная, но часто встречающаяся у классиков фраза, должна означать, что реальное начало 'MP-hobby' в нашей стране дал именно РК86.

Для меня РК это мой первый компьютер и первый, что я решил доработать - спаял для него плату граф.адаптера 384*256 (по журналу RFE, 10.1987). Но я тогда не умел делать ПО, - в итоге, этот граф.адаптер стал моим первым эл.диском. А к мысли подключить к РК86 внешнюю графическую плату в ж.РАДИО додумались лишь в середине 90-х.

Насчёт того, что ВГ75 сможет выводить графику 640*400 за счёт доступа процессора к фонту. Не понял, как загрузка фонта поможет увеличить разрешение экрана.

Кстати, в 1988 я знал одного корифана с РК, который пытался его доработать, введя оперативную подгрузку фонта (чтобы игры РК стали красивыми). Фонт для ВГ75 хранится в ОЗУ с раздельными входом и выходом. Входы ОЗУ подключены к ШД. А адреса ОЗУ с помощью 3-х КП11 при обращениях КР580 переключаются от ВГ75 на ША. Благодаря чему и происходит загрузка фонта. Дальше набросков схемы дело не пошло. Но думаю конструкция могла бы работать.

Идея изменять фонт, чтобы сделать игры РК красивыми всё-же была использована. В 1990 я разговаривал с одним белорусским "малым предпринимателем". Он сказал, что поставил в игровой салон в качестве игровых автоматов ЭРКА-шки с играми в ПЗУ. Чтобы игры были красивыми использовался свой фонт для каждой игры. При этом визуально на экране не псевдографика с пикселями 3*4, а реальная поточечная графика. Никто даже не догадался, что это выводит РК.

РК86 с его 29 микросхемами (и дефицитной ВГ75) преподнесён в 1986 году как предел простоты и минимизации. Но 29 микросхем это далеко не предел. В журнале RFE 01.1985 был опубликован текстовый компьютер на двух десятках корпусов, использующий вывод символов процессором цепочкой команд NOP. Полагаю, что идея была заимствована у ZX81.


Ещё более победительная идея была реализована в графическом компьютере из журнала RFE 08.1987. Компьютер с разрешением лучше СИНКЛЕРА всего на 21-ой микросхеме! Причём, если заменить 8 шт. РУ5 на две 62256, а две ИР16 на ИР9, то корпусов будет на 7 меньше. Это высший пилотаж разработчика микропроцессорной техники! Автору надо было поставить памятник.

Кучу счётчиков, что в традиционных схемах, заменяют два канала таймера, и используется то, что Z80 во время RFSH-цикла выводит на младшую половину шины адреса регистр R (инкрементируя его каждый раз), а на старшие адреса выдаёт регистр I.

Перед началом кадра приходит INT и Z80 уходит на визуализацию. В которой для синхронизации он ждет импульс от таймера. Регистры R и I ставятся так, чтобы адресовать начало первой строки из экранной области и Z80 уходит в состояние HALT. Затем приходит NMI-импульс, отчего Z80 покидает HALT, но стопорится по WAIT. Пока не придёт ССИ. После чего у Z80 есть время, пока идёт бордюр слева, чтобы адресовать R на текущую строку. Всего 3-х команд Z80 достаточно для подготовки вывода строки. Последней командой выполняется HALT. После чего тактами RFSH начинается вывод на экран. Байт за байтом и без всякого участия процессора и каких-либо счётчиков. Байт считывается из ОЗУ и заносится в регистр сдвига. Затем побитово сдвигается на экран. В конце вывода строки снова приходит NMI и процесс повторяется для следующей строки.

Вся программа визуализации состоит из 3-х команд : LD A,nn : LD R,A : HALT : повторенных 200 раз (сколько строк растра). На период кадра приходится 320 строк, из которых 200 отображаются. Следовательно видео-вывод отнимает у процессора 200/320 - 62 процента времени. Т.е реальная скорость Z80 падает до 38% от такта. А в РК86 видео тормозит лишь до 75%. Но уже при такте Z80 в 4 МГЦ достигается скорость в 4*0.38= 1.52 МГЦ, что быстрее, чем 1.3 МГЦ РК. Тут синхронизация со счётчиками не нужна, можно выбрать любой такт Z80. А т.к Z80A тянет 6 МГЦ, Z80B работает при 8.5, - то считайте сами кто быстрее.

Недостаток в том, что полностью теряются все прерывания. Это не фатально, при нужде их легко заменить опросом флага в процедуре визуализации, которая происходит 50 раз в секунду. Цвет в такой схеме организуется только по принципу адаптера CGA, т.е ОЗУ для экранных атрибутов не может быть в другой банке (как в ОРИОНЕ). Цвет пикселя можно задать только в самом экранном байте.

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

Иными словами, схема это шедевр минимизации, а этот компьютер - "машина времён и народов".

[Error404]

Мега всегда знает, что вычитывает ВГ75. Мега никогда не знает, что в текущий момент выводит ВГ75. Ибо ВГ75 читает наперед, так чтоб с запасом, стремясь получить не менее одной строки символов в запасе. Да и формат байта атрибутов строго оговорен в документации на ВГ75, нет там ничего лишнего.


Ну и отлично. Тогда в видеопамяти можно завести один дополнительный байт на каждую строку, который будет записываться в регистр в начале каждой строки - и цвет фона всей строки (скажем, 5 бит) и дополнительные биты к RGB цвета (доп. 3 бита). Т.е. без дополнительного ОЗУ в 80 байт и его обвязки. В большинстве ПО как раз и используется окраска целых строк - будь то строки статуса/подсказки терминала или экранной программы, окраска панелей командера, рабочая область текстового редактора и т.п.

В похожих проектах (http://zx-pk.ru/threads/26871-8-bitnyj-displejnyj-modul.html) дисплейных модулей такое уже делалось кстати - общий атрибут на всю строку.
Просто хочется малой ценой выжать максимум. :)

[freddy]

Ну и отлично. Тогда в видеопамяти можно завести один дополнительный байт на каждую строку, который будет записываться в регистр в начале каждой строки - и цвет фона всей строки (скажем, 5 бит) и дополнительные биты к RGB цвета (доп. 3 бита). Т.е. без дополнительного ОЗУ в 80 байт и его обвязки. В большинстве ПО как раз и используется окраска целых строк - будь то строки статуса/подсказки терминала или экранной программы, окраска панелей командера, рабочая область текстового редактора и т.п.
В похожих проектах дисплейных модулей такое уже делалось кстати - общий атрибут на всю строку.
Просто хочется малой ценой выжать максимум.
Об этом я знал. Так я не сделал, потому что мне показалось и так малое количество возможных смен атрибутов на строку. Тратить еще одну смену атрибутов на покраску фона не стал из экономических соображений. А еще я видеопамять потрудился привести к стандарту с линейной адресацией. Нет там места всяким компромиссным байтам. Все должно быть линейно. Эти всякие кулибинские штучки не для меня. Благодаря этим потугам этот видеоадаптер можно воткнуть хоть куда. И он там будет показывать. А эти штучки с отдельно выделенными байтами... заставят многое перепахать в видеодрайверах и софте. Поэтому пусть будет стандарт аля "CGA by VG75" без атрибутов фона символов, оно спокойно схавает экран CGA, выводимый напрямую в видеобуфер. Только не будет управляться фон и шрифт будет значительно красивее, и ЖК монитор SVGA не будет выедать глаза :)
Что же касается ПО, так пусть как хочет так и красит фон символов. Адаптер же должен уметь красить фон каждого символа, либо не должен вообще фон красить. Это как раз наш случай, у ВГ75 не осталось больше свободных ног.
Посмотрел я эти "похожие" проекты. Улыбнуло :) Это намек что, ВГ75 лишняя или все же те проекты не похожи на мой?
Если серьезно, то они похожи только по выполняемой функции - показывать что то на экране. У меня полностью железный видеоадаптер с высоким быстродействием, аппаратным курсором и стандартнейшим VGA-сигналом. Как Вы могли заметить, я ради "стандартности" не пожалел целых пять корпусов, которыми формируются синхроимпульсы. В "похожих" проектах с софтварным выводом символов, из-за этого катастрофическим быстродействием, отсутствием стандартного видеосигнала, едва удается вытянуть телевизионную развертку с шрифтом, съедающим глаза. А также там никогда не будет полностью аппаратного курсора.

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


Насчёт того, что ВГ75 выводит 640*400 за счёт доступа процессора к фонту. Не понял, как смена фонта поможет увеличить разрешение экрана
Моя схема уже работает в режиме 640x400@72Hz. Только вместо графики выводит символы. Чтобы вывести полноценную графику, нужно увеличить размер фонта до 32000 байт, обеспечить к нему доступ центрального процессора. А ВГ75 нужно заставить последовательно перебирать все эти 32000байт, это я знаю как сделать программно. Таким образом будет развернута полноценная картинка 640х400.
Ваш "корефан" судя по всему тоже догадался как. Только там 3-мя КП11 не обойдется.

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


В журнале RFE 01.1985 был опубликован текстовый компьютер на двух десятках корпусов, использующий вывод символов процессором командой NOP. Предполагаю, что эта идея была заимствована у ZX81.
Че за журнал такой? Где достать/скачать?

[Error404]

"кулибинские штучки","потуги"... Что, неудачный день что ли ?
Решение сейчас (по количеству уже применного) - на границе целесообразности траты на него макетки. Много корпусов при функционале... Вот кстати, каком функционале? Когда оно было терминалом VT52 (и с меньшим количеством корпусов) - это одно. А сейчас с "линейной памятью" для которого еще система должна входящий VT-52 переварить и сама оттранслировать в оный массив, сделать все кроме финальной отрисовки - это что даст гигантское быстродействие что ли?
Я тоже не от безделья поболтать захожу, а примеряю реальное применение устройства в реальной ОС, как раз таки алфавитно-цифровой. Но если своими хотелками действую на нервы, что же, огородиться и творить для себя этот конечно выход, вперед.

[A_AVL]

Че за журнал такой? Где достать/скачать?
Это наверное Galaksija. Большая тема по ней там - http://www.nedopc.org/forum/viewtopic.php?f=71&t=9407

[barsik]

...что за журнал?
RFE это журнал выпускаемый в ГДР. Была такая страна в восточной Европе, очень хорошая. Её называли выставкой стран социализма, уровень жизни там был выше, чем в СССР. Но они купились на сказки о свободе и сдуру сломали одну бетонную стенку в Берлине. После сожалели, но было поздно.

RFE это "Radio Fernsehen Elektronik" (радио телевидение электроника). На мой взгляд, был наиболее полезным журналом, доступным к подписке в СССР. Там публиковались схемы промышленного железа: магнитофонов, усилителей и т.п. Статьи о новых радиодеталях и БИС. Т.е в чём чём-то он походил на наш "МПСС", но информативней и конкретней (там не было голых анонсов типа "вот у нас есть то-то, обращайтесь по адресу"). Там было довольно много статей о Z80 и его периферии.

Кроме RFE для подписки был доступен ГДР-овский журнал FUNKAMATEUR (радиолюбитель). Это немецкий аналог ж.РАДИО. Там с 1983 опубликовали несколько самодельных ЭВМ на Z80 и периферийных плат к ним, а также схемы промышленных бытовых ЭВМ. Эти два журнала были полезнее, чем все остальные радиолюбительские журналы из восточной Европы, Монголии и Китая.

Насчёт того, чтобы скачать. Тут возможны проблемы. Легко найти и скачать западногерманские радиолюбительские журналы 80-х, например FUNKSCHAU. Но с ГДР-овскими журналами сложнее. Дело в том, что после объединения Германий, они объявили, что в ГДР - всё было дерьмом. Поэтому все хорошее, что было в ГДР они сделали недоступным. Исчезла страна, исчезли и её журналы. Я как-то запустил поиск FUNKAMATEUR, но ничего не нашлось. Но возможно не там искал.

Журналы есть в библиотеках иностранной литературы. В интернете, тоже должно что-то где-то остаться. В крайнем случае можно оставить сообщение на немецких форумах по 8-ми разрядкам. Я и сам позднее собираюсь почитать немецкие форумы (с языком нет проблем, немецкий почти родной). У меня нет RFE за 1985, брал журнал в библиотеке. Думал, как эту идею реализовать на КР580, по прикидкам выходило менее 30 корпусов.

Поясняю слово корифан (компьютерный словарь начала 90-х). Происходит от двух греческих слов. Корифей, что означает знающий. И фанат, что означает увлечённый. Таким образом, корифан это увлечённый знаток. Корифан гораздо круче корифея. Корифей выучил "от сих до сих" по учебникам и считает себя знатоком. Он обладает академическими знаниями, но относится к теме без души, без энтузиазма. А вот корифан не только знает, но и умеет.


... знал одного фаната, который пытался доработать РК, введя загрузку фонта (чтобы игры РК стали красивыми). Фонт для ВГ75 хранится в ОЗУ с раздельными входом и выходом (565 РУ2). Входы ОЗУ подключены к ШД. А адреса ОЗУ с помощью трёх КП11 при обращениях КР580 переключаются от ВГ75 на ША. Благодаря чему и происходит загрузка фонта. ... Думаю конструкция могла бы работать

Не вижу, что в таком варианте помешает загрузить фонт (кроме нагрузочной способности шины РК). ОЗУ 1 кб имеет 10 адресных входов, три КП11 коммутируют 12 цепей. Входы ОЗУ на шине данных. Что ещё надо? Ну, для совершенства можно предусмотреть гашение, чтобы не было блёсток по экрану, в момент загрузки фонта.

Вообще-то FREDDY, ты не на то обратил внимание. Текстовой ЭВМ с выводом на идеях из ZX80, трудно кого-то удивить после 1980 года. Гораздо интереснее другая ЭВМ, о которой я упомянул в спойлере в конце поста.

[freddy]

Спасибо, что рассказали о журнале, постараюсь раздобыть. В нашей деревне с литературой плохо дело.
В моей конструкции тоже линейноетадресное пространство. Свой видеоадаптер я планирую использовать в самодельной ПиСе. Работать там будет Ms-Dos 3.30. При этом нужно поправить видеобиос int10h. Скорости у этого адаптера хоть отбавляй, буду на нем мультики в текстовом режиме смотреть. Стоит это 19 ти корпусов или нет, решайте сами. Мне и 50 корпусов для видеокарты нормально. Если говорить о целесообразности, то связываться с вг75 не стоит. Хлам этот только для фанатов.

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

К стати, barsik, я не любитель софтовых решений.

[barsik]

Был не прав. Попробовал поискать и нашёл в сети сайты по обоим немецким журналам.

Журнал FUNKAMATEUR оказывается существует до сих пор. И даже доступен на русском языке. Запусти в IExplorer поиск по FUNKAMATEUR и сразу попадёшь куда надо. Не знаю как насчёт того, есть ли там переводы древних номеров журнала, но д.быть ссылки на немецкие источники. И теперь уверен, что всё что надо можно будет найти.

Насчёт того сохранился ли журнал RFE, - пока не знаю. Думаю, что нет. Если искать его по имени, то на слово 'radio' выскакивают тысячи найденных ссылок. Поэтому надо набирать 'Radio Fernsehen Elektronik' точно, чтобы первые буквы были заглавными. Или вместо пробела между словами поставить тире.

Тогда находится вот этот адрес сайта RFE. И там тоже есть форум.

http://www.radiomuseum.org/lf/b/radio-fernsehen-elektronik-ddr/

Кстати, FREDDY зря вы не любите "софтовые" решения. Аппаратно программные решения всегда красивее и проще, чем чисто аппратные или чисто программные. Да и писать программы интереснее, чем возиться с железяками.

А зачем Вы используете ВГ75. Ведь есть же гораздо лучшая вещь - NEC 7220, чей отечественный аналог - это ГДК 1809ВГ4 (или международный аналог 82720 разных фирм). Он может всё то же самое, что и ВГ75, но кроме того выводит графический экран с разрешением до тысяч пикселей по вертикали и горизонтали. И плюс содержит в себе графический процессор. О нём писали в МПСС где-то за 1987-89 годы. Почитайте.

Я сам хотел в начале 90-х собрать крошечную платку графического процессора на NEC 7220 для РК86. ГДК это графический дисплейный контроллер. Он существенно упрощает плату графического адаптера для РК86, причем реализует множество эффектов: сдвиги во все стороны, панорамирование, ZOOM...

Но нам ценно то, что мало корпусов, что важно при ручном монтаже. Т.о малой кровью получаем графику. В 1993 я купил 15 штук NЕС 7220, но тогда до пайки дело не дошло. Есть и документация на ГДК 1809ВГ4.

Схемка простой платки на двух 6264, реализующая графику 640*200 - в журнале FUNKAMATEUR 07.1990. Там есть и готовый дамп драйвера для CP/M-BIOS. Смотри также журнал RFE 04.1989 (там статья о плате на 7220 с текстовым и цветным графическим режимом и есть и список литературы).

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

Я наконец догадался, как оперативная загрузка фонта в текстовой ЭВМ может расширить графические возможности.

ВГ75 программируем на режим с числом линий растра в знакоместе 8, числом знакомест в строке 64+3=67. И числом строк, например, в 50. Знакоместо фонта задаём 8*8. И задаём режим, когда атрибуты вообще не отображаются.

Затем во все строки экранного ОЗУ записываем нарастающий код 0,1,2,3...63, и три последних байта в каждой строке должны быть:

- атрибутная команда "включить" GPA1 (General Purpose Attribute)
- пробел
- атрибутная команда "выключить" GPA1

Таким образом при работе ВГ75 после вывода в каждой строке 64 знакомест, на выходе GPA1 будет появляться импульс. Который подается на вход '+1' счётчика 561 ИЕ10. Выходы счётчиков подаются на адреса ОЗУ с фонтом. Таким образом каждая новая строка выводится с другим фонтом.

Использовать GPA для инкремента счетчика удобнее, но можно использовать для тех же целей и ССИ, т.к он тоже формируется для каждой строки. Выход GPA2 можно использовать для сброса счётчиков ИЕ7 в начаче кадра.

При указанном режиме ВГ75 будет реализована графика:

80 * 8 = 640 по горизонтали 50 * 8 = 400 по вертикали

При программировании приходится работать не с экранным ОЗУ, с ОЗУ фонта. Размер ОЗУ фонта составит 64*50*8=3200*8=25600 ячеек.

Ну что, эта идея совпадает с тем, как ты "выжимаешь" из текстового контроллера CRT ВГ75 графику?

[freddy]

Ну что, эта идея совпадает с тем, как ты "выжимаешь" из текстового контроллера CRT ВГ75 графику?
Идея совпадает, реализация у меня немного другая. Посчитал fill-rate. Получается если класть с максимальной частотой байты в видеопамять, получится 25 Мегапикселей в секунду. CCLKx8bit. Конвеер данных на запись в память фонта может работать максимум со скоростью CCLK. Это примерно 97fps (25000000/256000), что более чем достаточно при развертке 72fps. Графический режим может пригодиться весьма могучему процу 20-40Мгц, так как там нет никакой программной обработки. Все делает логика.

А зачем Вы используете ВГ75. Ведь есть же гораздо лучшая вещь - NEC 7220
Я фанат ВГ75 и MC6845. ВГ75 просто ведрами как то выбрасывали, набрал их полную сумку. Вот пригодились.

Я сам хотел в начале 90-х собрать крошечную платку графического процессора на NEC 7220 для РК86.
Собирайте на ВГ75, для РК более чем достаточно.


ривожу также правильно оформленный тегом URL адрес сайта журнала RFE (интересный сайт).

http://www.radiomuseum.org/lf/b/radi...lektronik-ddr/

Спасибо, ссылка очень полезная. Буду потихоньку учить немецкий язык.

[barsik]

Это наверное Galaksija.

Спасибо A-AVL за ссылку.

Посмотрел схему "Галаксии". Похоже, что это гениальный компьютер. Братья славяне не подвели.

Нет, это не "Галаксия". Это чисто немецкое изобретение. "Галаксия" намного более грамотная машина на втрое меньшем числе корпусов. Здесь 25 корпусов, хотя при замене однобитовых микросхем ОЗУ 565РУ2 на одну 8-ми битовую (6216, 6264, 62256, w24257), будет всего 18 корпусов.

Самого журнала первоисточника RFE 01.1985 (стр 13...18) у меня нет, но некоторые статьи о нём в последующие годы есть. Эта железка называется "Basic-Heimcomputer BCS-3", что означает бейсиковый домашний компьютер. Для него действительно был опубликован крошечный целочисленный бейсик (TINY BASIC) и игра ПАКМЭН на нём. Также монитор с встроенным экранным редактором дампа и программатор УФ-ПЗУ. В журнале RFE 09.1986 опубликована статья "Расширения для бейсикового домашнего компьютера" и "Полноценная графика на BCS-3".

Вот список первоисточников:

RFE 01.1985 Полное описание
RFE 04.1985 Дополнения
RFE 09.1986 Расширение (BASIC 3.1)
RFE 09.1986 Полноценная графика (Werner Schmidt)
RFE 10.1987 Дальнейшие расширения

Вот список некоторых ссылок на упомянутый самодельный компьютер BCS-3:

http://hc-ddr.hucki.net/wiki/lib/exe/fetch.php/bcs3:bcs3.pdf
http://hc-ddr.hucki.net/wiki/doku.php/homecomputer:bcs3
http://www.robotrontechnik.de/index.htm?/html/computer/bausaetze.htm
http://www.google.ru/url?q=http://www.jens-mueller.org/jkcemu/bcs3.html&sa=U&ved=0ahUKEwinkaSOnarSAhWMWSwKHRkZBqwQFghXMA4&usg=AFQjCNElEUHLt8bCC3xLX-omkrv7312T5Q

А вообще по ключу "BCS-3 Z80 computer" можно найти и другие ссылки. К сожалению, имя BCS3 использовано для какого-то американского компьютера и других изделий, так что надо выискивать нужные ссылки в большом списке.

[freddy]

Усё пришлось переработать заново. Оказалось, что схеме таки не помешает чтение буфера и регистров. К этому меня подтолкнуло наличие светового пера. Это ж одна из изюминок ВГ75. В современных видеочипах такого нет. Вот я и подумал что не плохо было бы его читать :) Так я родил новый дешифратор сигналов управления шины, а сама читалка обошлась в еще один регистр КР580ИР82.
Поясню немного как оно работает, вдруг кто то захочет приколхозить в самодельный комп. Входные сигналы IA0-IA15, ID0-ID7, ~RD,~WR, ~RES. И так если на шине адреса диапазон адресов видеоадаптера (выбирается джампером), то дешифратор U14 разрешит прохождение сигналов ~RD, ~WR в схему (с помощью U17A, U17B), там они называются ~MWR и ~MRD. Они заведены на свои обработчики прерываний. Кроме того по ~MWR или ~MRD происходит автоматическое защелкивание адреса и данных в буфере U16, U18,U19. Таким образом у мозга видеокарты есть достаточно времени, чтоб оттуда их забрать, так как следующий цикл записи шины наступит еще не скоро (по меркам AVR). Дальше ничего интересного. Через 7 тактов AVR выпадет в прерывание и еще через 3 такта буфер данных и адреса будет считан. Всего в обработчике 11 тактов (с учетом выхода из прерывания), что обеспечит не хилый такой показатель в 1000000 сивмолов в секунду при тактовой 20Мгц. Это если постоянно не писать на каждый символ атрибуты. Если атрибуты вообще не нужны, то тогда можно подать единичку на IA0 видеокарты.
По сигналу ~RD происходит выдача данных из защелки U20. Она также облегчает AVR жизнь и способствует повышению пропускной способности - не нужно париться о длине сигнала ~RD. При чтении реакция немного другая. В буфере U16, U18,U19 все также защелкивается какая то ботва с шины. Только теперь пофиг что в U16, важен только адрес U18,19. Обработчик прерывания защелкнет нужные данные в регистр U20. И основной проц при следующем цикле сможет их оттуда взять. Т.е. самый первый цикл чтения ничего не даст. Зато в последующих циклах чтения будут всегда возвращаться данные предыдущего цикла. В итоге при чтении любого блока или рандомных ячеек, получаем всего один левый цикл.
Схема и печатка в файле. На печатке оставил место под плюшки. Буду признателен, если кто то проверит печатку на соответствие схеме, так как я ее пока еще не заказывал. 58600

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

Еще сорри за многословие. Чего то прорвало сегодня. Проанализировал свою схему и... понял, что она приспособлена под графический режим. Входная защелка на 16 адресных линий и данные уже есть. Дешифратор есть. Только немного по-другому развести, чтоб текстовый буфер занимал 4к гдето в первой половине, а графический буфер 32к второй половины. Итого 36к. Вполне можно пожертвовать и забить на текстовый экран и не дешифровать его в графическом режиме. но однако тут потеряется одна из очень вкусных плюшек - спрайтовый движек и возможность нелинейного разворачивания графического буфера.
Итого насчитал 5шт К555КП11, 1шт КР580ВА86, 1шт SRAM 32кб, 1шт К555ЛН1. Итого +8. Можно выполнить в виде Add On карты и цеплять сверху в сокет ПЗУ. При этом схема сможет программно переключаться, ничего не сломается, все достигнутые плюшки сохранятся. В графическом режиме можно подгрузить свой знакогенератор и тоже рисовать текст через текстовый буфер. В графическом режиме будет только монохром.

[Error404]

Проанализировал свою схему и... понял, что она приспособлена под графический режим. Входная защелка на 16 адресных линий и данные уже есть. Дешифратор есть. Только немного по-другому развести, чтоб текстовый буфер занимал 4к гдето в первой половине, а графический буфер 32к второй половины. Итого 36к.

А сложно ли будет реализовать несколько текстовых экранов? Чтобы с хоста переключать какой из них активный и какой видимый? Раз уж к Меге добавляется ОЗУ в которую она имеет доступ? Поставить SRAM более емкую (напр. 64к) и добить до 32к+4к+4к+4к+4к+4к+4к+4к+4к. Ну или сделать чтобы те 32к были бы либо одним графическим экраном, либо 8 шт. текстовых (переключаемый режим).
В текстовом режиме по записи хостом в "регистры обмена" по прерыванию Мега перепишет данные из регистров в SRAM в активный текстовый экран, а при отрисовке по запросу ДМА от ВГ75 на выводе строки выдаст данные не из своего внутреннего ОЗУ, а из внешней SRAM - со смещением по адресу видимого текстового экрана. Это было бы мегаудобно для многозадачных текстовых ОС (например UZIX/FUZIX).

[freddy]

А сложно ли будет реализовать несколько текстовых экранов? Чтобы с хоста переключать какой из них активный и какой видимый? Раз уж к Меге добавляется ОЗУ в которую она имеет доступ? Поставить SRAM более емкую (напр. 64к) и добить до 32к+4к+4к+4к+4к+4к+4к+4к+4к. Ну или сделать чтобы те 32к были бы либо одним графическим экраном, либо 8 шт. текстовых (переключаемый режим).
Это не к меге добавляется ОЗУ. Это для ВГ75 ОЗУ знакогенератора. Мега туда писать не сможет, только компьютер будет иметь доступ, и только аппаратно все будет.
У меги задача заставить ВГ75 разворачивать графический буфер в заданной последовательности. Можно играться например с нелинейным отображением кусочков графического буфера. Для меги то он состоит из 4000 спрайтов 16х8 точек. Можно читерить.


В текстовом режиме по записи хостом в "регистры обмена" по прерыванию Мега перепишет данные из регистров в SRAM в активный текстовый экран, а при отрисовке по запросу ДМА от ВГ75 на выводе строки выдаст данные не из своего внутреннего ОЗУ, а из внешней SRAM - со смещением по адресу видимого текстового экрана.
Где то выше я уже писал, что так можно, нужно приладить под текстовый режим меге еще одну SRAM. Пока так делать не буду, с внутренней памяти резвее работает. При переключении задач, можно экран перерисовывать из компа. 4000байт переписать - это очень быстро, а без атрибутов 2000байт еще быстрее. На глаз будет не заметно.

[freddy]

Кто еще использует в своих целях КР580ВГ75? Такое впечатление, что я один на ней строю видеокарты, какая то тишина в ветке. В соседних топиках народ занимается "онанизмом" типа микроконтроллера со сдвиговым регистром, которое едва тянет телевизионную развертку со скоростью COM-порта 9600. Видимо время железячных решений прошло.
Однако я на днях решил доделать в своем терминале все что казалось когда то не так уж важным. Клавиатура наконец то мигрировала на второй COM-порт, добавилась поддержка аппаратного управления потоком RTS/CTS (точнее RTR/CTS). Эх... и код оптимизировался, как то все произошло не заметно, само по себе. Решил в итоге посчитать такты... В общем мне гдето раньше уже писали о том, что вместо AVR не плохо бы взять старый проц типа 8085, чтобы элементная база была из эпохи 80-х. Ну так я был не прав. Для терминала 8085 хватит с головой. А еще учитывая что i8251 не гнались выше 19200bps, то и 8080 хватит. Ну и, в общем после очередного ностальгического приступа родилась схема на 8080. Сперва оно должно было заменить AVR, потом я посмотрел и понял, что это же полноценный комп! И тут я опять вспомнил про РК. Как здорово было бы, чтоб его афтары вместо у%%%%а, сделали тогда нормальный комп, совместимый с другими известными компами на таком же проце. Подумал я про CP/M! Это тонна полезного софта! Вот бы они собрали нормальное железо и портировали туды CP/M, так может быть и история советских ЭВМ пошла бы по совсем другому пути. Дык нет же... Сделали ЖЕ! Ну а дальше Вы все сами знаете. Это куча частично совместимых или не совместимых клонов на одной и то же элементной базе :) Почему то мне сразу стало очень грустно, я решил забить на портирование кода терминала на 8080. Захотел портировать на него CP/M, а терминал не трогать. Работает, да и ладно. На данный момент есть только схема и печатка. Хочу выложить куда нибуть в отдельную ветку ибо это уже не совсем про ВГ75, хотя она там будет участвовать :)
Вот здесь буду выкладывать http://zx-pk.ru/threads/27362-samodelnyj-komp-na-i8080.html

[bigral]

Кто еще использует в своих целях КР580ВГ75? Такое впечатление, что я один на ней строю видеокарты, какая то тишина в ветке.

Мне показалось что все затихло именно изза avr-a, если в схеме стоит avr то в принципе можно к нему навесить уже и V9958 или там CityGate D10 (чипы его эпохи) и весь интерес на этом заканчивается. В РК 86 же была связка вероятно взятая из документации intel где описывается пример применения intel микрух для построения дешевого терминала (как мне представляется на то время терминалы клепали на рассыпухе и были они понастоящему "тупые").

А вот КР580ВГ75 удивительно был как-то применен в АРГО, где он эмулировал ZX-SPECCY экран... никто так и не разжевал тут на форуме как это сделанно. И не ясно можно ли еще дальше развить эту идею. Про 2 синхронно работающих КР580ВГ75 тоже идеи проскакивали но ничем не закончились. На счет DMA тоже идея не раскрыта полностью помоему.

[b2m]

А вот КР580ВГ75 удивительно был как-то применен в АРГО, где он эмулировал ZX-SPECCY экран... никто так и не разжевал тут на форуме как это сделанно.
Я пытался рассказать. Вот тут и немного дальше: http://zx-pk.ru/threads/9650-kompyuter-quot-argo-fv-6511-quot.html?p=361991&viewfull=1#post361991

[A_AVL]

Мне показалось что все затихло именно изза avr-a [...]
IMHO, конечно не из-за АVR. Может, сложновата кажется. По сравнению с видеоконтроллером на одной АВР со сдвиговым регистром.
Конструкция freddy шикарна. Это устройство в формате видеокарты будет идеально для 86РК или того же ОРИОН-128 как чисто текстовый вывод. Полностью аппаратный видеовывод со стандартным 80х25 в формате VGA. Качественных мониторов полно (некачественных уже давно нет), глаза ломать на телевизоре не надо.
А по поводу V9958 & CityGateD10 и др. - это не VGA вывод, со всеми отсюда вытекающими последствиями.

[freddy]

А вот КР580ВГ75 удивительно был как-то применен в АРГО, где он эмулировал ZX-SPECCY экран... никто так и не разжевал тут на форуме как это сделанно.
Давным давно, все изобретено, в том числе и я приложился. Всего лишь ВГ75 надо запрограмировать на нужный видеорежим, так чтоб нужный экран влезал, и заэмулируйся на здоровье:) Незнаю, выкладывал или нет, вот на всякий случай выдран кусок моей схемы:59701
Это кусок видеокарты,отвечающий за графический режим. Остальная часть уже выкладывалась (это мой терминал и текстовое видло на базе него). Весь трюк в подмене ПЗУ знакогенератора на ОЗУ. Моя схема задумана немного под другие машины, поэтому работает в VGA 640х400@72Hz. Однако будет показывать и все что влезет в размеры такого разрешения. На U9,U10 собран синхронизатор записи центрального проца в видео память и чтения из видеопамяти ВГ75. У меня один символьный такт CCLK это 8 пикселных тактов. Последние 4 надо отдать VG75. В 0-м такте переключаются шины видео ОЗУ с ВГ75 на шины центрального процессора, в первом и втором тактах подается сигнал ~WRD, если до этого момента от центрального проца поступал сигнал ~WR, т.е. совмесно с входным буфером на ИР82-х получается типа отложенной записи. В 3-м такте происходить обратное переключение шин и обнуление признака поступления сигнала ~WR. Предполагается, что центральный процессор не может писать чаще чем CCLK, в моем случае это 3,1Мгц. PRD(Page read), PWR(Page Write) это сигналы выбора страницы записи и отображаемой текущей страницы. Здесь они могут быть как разными так и одинаковыми. Снежить не будет, перенял горький опыт конструкторов IBM CGA видяшки, у которой схема синхронизации чтения и записи видеобуфера занимает пол видеокарты :)
Тонкостей как графика реализована в Арго, не знаю. Но принцип тот же. По другому графику на ВГ75 не навесить. И чтобы адресовать видеопамять более 2Кб, нужно задействовать атрибуты ВГ75. Я юзаю все 4.

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


И не ясно можно ли еще дальше развить эту идею.
Ясно, что кое-кто этой идеей уже пользуется :)


Про 2 синхронно работающих КР580ВГ75 тоже идеи проскакивали но ничем не закончились.
Каков смысл? Хотите SVGA видеорежимы?


На счет DMA тоже идея не раскрыта полностью помоему.
Раскрыта, только код у меня пока закрыт. Так на словах могу рассказать, если что интересует.

[bigral]

IMHO, конечно не из-за АVR... Это устройство в формате видеокарты будет идеально для 86РК или того же ОРИОН-128 как чисто текстовый вывод.

А мое IMHO, avr смотрится как "бельмо на глазу" в схемах РК86 и ОРИОН-128, вообще сразу возникает вопрос а зачем там РК и ОРИОН? Неужели еще десяток копеечных avr нельзя было влепить за ту же цену? Или AVR spectrum по Вашему тоже спектрум?


Полностью аппаратный видеовывод со стандартным 80х25 в формате VGA.

Никой он не полностью аппаратный а программно реализованный на чипе с интергацией и скоростью превышающей на порядок и по скорости и по интеграции ОРИОН и РК ВМЕСТЕ ВЗЯТЫЕ!


А по поводу V9958 & CityGateD10 и др. - это не VGA вывод, со всеми отсюда вытекающими последствиями.

И что? Ну есть cl-gd5401 vga chip, trident9000i и т.д. все одногодки AVR-a, речь в ветке вообще не про vga а про видеоконтроллер на ВГ75.

[freddy]

IMHO, конечно не из-за АVR. Может, сложновата кажется. По сравнению с видеоконтроллером на одной АВР со сдвиговым регистром.
Конструкция freddy шикарна. Это устройство в формате видеокарты будет идеально для 86РК или того же ОРИОН-128 как чисто текстовый вывод. Полностью аппаратный видеовывод со стандартным 80х25 в формате VGA. Качественных мониторов полно (некачественных уже давно нет), глаза ломать на телевизоре не надо.
А по поводу V9958 & CityGateD10 и др. - это не VGA вывод, со всеми отсюда вытекающими последствиями.

Да, сам сколько видел этих конструкций: AVR+74HC165/166 и готово. Вот и вся видеокарта. НО... Производительность никакая, прокатит только для терминалов. И то при скорости больше 9600bps теряет символы. А 9600bps это около 1000 символов в секунду. Моей железке можно и Мегабит и два и три... Поэтому оно может использоваться непосредственно на шине не сильно быстрого проца.
Терминал, если не считать АВР, настоящее ретро на теплых ламповых детальках :)
Видеокарта в общем то опробована на АВР и через USB от компа. Схема и прошивка лежит где то выше. Все работало хоршо. Сейчас я собираю комп на 8080. Попробую на нем еще потестить.

[bigral]

Каков смысл? Хотите SVGA видеорежимы?

Смысл понять вообще это возможно? Что теоретически это может дать? Уменьшение частот на шинах с память? Большее количество цветов? Большее разрешение?

[freddy]

Никой он не полностью аппаратный а программно реализованный на чипе с интергацией и скоростью превышающей на порядок и по скорости и по интеграции ОРИОН и РК ВМЕСТЕ ВЗЯТЫЕ!
Он на ВГ75 :) Авр за место DMA :v2_lol:

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


Ну есть cl-gd5401 vga chip, trident9000i и т.д. все одногодки AVR-a, речь в ветке вообще не про vga а про видеоконтроллер на ВГ75.
Однако именно с нее можно получить качественный VGA видеовыход, приятно так когда старушка родом из 70-х VGA выдает.

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


Смысл понять вообще это возможно? Что теоретически это может дать? Уменьшение частот на шинах с память? Большее количество цветов? Большее разрешение?
Возможно. Это даст увеличение скоростей чтения/записи видеобуфера и увеличение разрешения. Т.е. это путь в SVGA.

[bigral]

Он на ВГ75 :) Авр за место DMA :v2_lol:

ага, всего-то... ну так нафик он надо раз его вклад такой "скромный", заменим его на родной i8057? хе хе хе ну или на логичный i8039 i8051... да?

з.ы. ненадо "жульничать", спорт так СПОРТ!

[freddy]

К стати вместо АВР в случае с видеокартой, вобще стоило применить что то из STM32 или FPGA,чтобы уверенно чувствовать себя на шине со всякими 286, 386 процами. Так вот STM32 во много раз мощнее всяких РК-шек, однако нужен он лишь для DMA и отлавливанья сигналов шины ;)

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


з.ы. ненадо "жульничать", спорт так СПОРТ!
Дальше сами. Удачи.

[A_AVL]

Смысл понять вообще это возможно? Что теоретически это может дать?

Две ВГ75 используются в терминале МС6102. Для возможности вывода 256 символов скорее всего. Нужно искать его схему и смотреть. Насколько я помню, они могут легко синхронизироваться друг с другом. Судя по всему, число сигналов атрибутов удвоится тоже.

[freddy]

ве ВГ75 используются в терминале МС6102. Для возможности вывода 256 символов скорее всего.
Есть стандартный текстовый режим с 132 символами в строке. 2хВГ75 легко осилят.

Судя по всему, число сигналов атрибутов удвоится тоже.
Нет. Каждая ВГ75 будет отвечать за свою часть символов.

[blackmirror]

И то при скорости больше 9600bps теряет символы.
Если при такой низкой скорости AVR теряет символы, значит вы не умеете их готовить! Xmega 32МГц вполне успевает принимать непрерывный поток данных по 5 последовательным портам(один на 921600 и 4 на 460800) и собрав их в кучу отдать W5100 чтобы он отправил их в Ethernet. AT90CAN 16МГц чисто программно(не было на тот момент нужного кварца) успевал принимать на скорости 921600 непрерывный поток байт, вытаскивать из него 32х разрядный счётчик (который занимал 5 байт, правда 7й бит каждого байта был признаком начала сообщения, поэтому его нужно было только проверять и не требовалось сохранять, за счёт чего часть регистров восстанавливалась еще до проверки его значения и после выхода их прерывания оставалось времени порядка 25 тактов) и отправлять его в CAN сеть, а так же пересылать принятые и отправленные CAN сообщения через W5100 в Ethernet.

[A_AVL]

А мое IMHO, avr смотрится как "бельмо на глазу" в схемах РК86 и ОРИОН-128, вообще сразу возникает вопрос а зачем там РК и ОРИОН? Неужели еще десяток копеечных avr нельзя было влепить за ту же цену? Или AVR spectrum по Вашему тоже спектрум?

Никой он не полностью аппаратный а программно реализованный на чипе с интергацией и скоростью превышающей на порядок и по скорости и по интеграции ОРИОН и РК ВМЕСТЕ ВЗЯТЫЕ!

И что? Ну есть cl-gd5401 vga chip, trident9000i и т.д. все одногодки AVR-a, речь в ветке вообще не про vga а про видеоконтроллер на ВГ75.
IMHO, мы отклоняемся от темы, но позволю высказать свое мнение:
1. AVR Spectrum - не спектрум. Это понятно любому. Это симулятор. Или эмулятор, в зависимости от того, как он написан.
2. С точки зрения РК или ориона, которые пишут данные по физическим адресам системной шины - обсуждаемый видеоконтроллер аппаратный. Как там внутри организовано всё- другой вопрос, и он абсолютно не волнует РК. Вас ведь не волнует, наверное, что любая современная видеокарта может уделать любой десктопный процессор как числодробилка, и внутри видеокарты сотни ядер CUDA или еще чего от ATI, которые умеют работать по программе и в сумме по GFLOPS-ам уделывают процессор компьютера как стоячего.
3. Есть то они есть :), много чего есть, например чипы от FUJITSU, но эти чипы на мой взгляд не подходят для видеокарты 8-ми битного компьютера. Сложность платы, сложность распайки, необходимость наличия VIDEО DACa, программирования под них, и это всё только из-за того, что не понравилась авр-ка, которую можно всунуть на обратную сторону ПП, и ее никто не увидит :).
Так же, вызывает диссонанс, что минимальный объем видеопамяти для их работы в четыре раза больше максимального объёма памяти восьмибиток :), загружаемый знакогенератор, и т.п. В итоге, с какой скоростью и как всё это будет работать?

[freddy]

О! Можно я тоже немного по оффтоплю. На TVGA9000i я делал когда то. Для 8-ми битного компа вполне пойдет. Чтоб не бегать по тырнету в поисках чипа и избежать его пайки в домашних условиях, нужно приколхозить к компу ISA 8bit. Б/У видеокарт на Трайдентах полно, на них уже есть режим 8 бит. Немного переработать процедуры инициализации в биосе под код 8080... И еще! Главное вынести адресное пространство видеобуфера в shadow ram, а то под основную прогу места не будет. А еще лучше взять более другой проц с 8-ми битной шиной. Да! Это же 8088!

Если при такой низкой скорости AVR теряет символы, значит вы не умеете их готовить! Xmega 32МГц вполне успевает принимать непрерывный поток данных по 5 последовательным портам(один на 921600 и 4 на 460800) и собрав их в кучу отдать W5100 чтобы он отправил их в Ethernet.
А при этом еще экран VGA програмно сможет перерисовывать 60 раз в секунду?
И не просто, а осмысленно из видеобуфера и памяти знакогенератора... И еще с клавы принимать символы...
И еще терминал эмулировать...
Соберите схемку сами, пощупайте ее, там три детальки всего... Потом нам расскажите Ваши впечатления от ее работы.

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


Так же, вызывает диссонанс, что минимальный объем видеопамяти для их работы в четыре раза больше максимального объёма памяти восьмибиток , загружаемый знакогенератор, и т.п. В итоге, с какой скоростью и как всё это будет работать?
Работать то оно будет, только проблем есть... Куда деть экранную область? Памяти всего 64К в основном. Можно конечно тот же трайдент запустить только в текстовом режиме 80х25. Но это всеравно, что из пушки по воробьям.

[Error404]

Кто еще использует в своих целях КР580ВГ75? Такое впечатление, что я один на ней строю видеокарты, какая то тишина в ветке.

Потому что ты продвинулся дальше других, штуковина получилась очень интересная, но в текущем виде проект мне, например, не подходит - ни вариант терминала, ни работающий из адресного пространства. Если будут выложены исходники проекта, возможно в адаптированном под мои хотелки виде он пропишется в Орионе, а до того вряд ли. А проделывать весь путь за тобой повторно неинтересно (да и долго), так лучше что-то новое запилить.

[freddy]

VT52 и VT100 у меня поддерживаются. Причём это vt100, а у него есть режим эмуляции vt52. Особое внимание уделено глюкам vt100. Например vttest проходит на ура. Что ещё не хватает? Vt220? Vt420?
Устройство в варианте видеокарты я выложу после тестирования на большом количестве реального железа. Будет один экранный буфер 4кб и управление курсором.

[Error404]

Ну вот, "опять за рыбу деньги". :) Чего не хватает я на пяти страницах треда описывал, ответы были "я вижу по-другому". Искейп коды мне тоже потребуется расширять, например оконными функциями, многие искейпы в Орионе исторически другие но аналогичные по функциям. Иначе опять все сведется что для того чтобы работать с аппаратной платой (в чем и плюс казалось бы), мне придется 2/3 всего обсчета делать на хосте, и буферизировать опять же на хосте, а от платы с процессором впятеро мощнее Ориона и размером в половину Ориона ничего кроме печати символа и взять будет нечего.

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

А я ведь целью текстового адаптера преследую не только красиво вывести на монитор, но и максимально разгрузить хост (Орион в моем случае) как от лишних тактов вычисления, так и от лишних байтов кода на эти вычисления, хранящихся в дефицитном адресном пространстве 8-битки.

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

Также, зрение уже не то что прежде, и надо хотя бы добавить программируемый регистр фона (в идеале построчно на каждую строку символов - 25 байт в Меге под это выделить). Долго в черный квадрат смотреть уже не могу - устаю быстро.

[freddy]

Чего не хватает я на пяти страницах треда описывал, ответы были "я вижу по-другому". Искейп коды мне тоже потребуется расширять, например оконными функциями, многие искейпы в Орионе исторически другие но аналогичные по функциям. Иначе опять все сведется что для того чтобы работать с аппаратной платой (в чем и плюс казалось бы), мне придется 2/3 всего обсчета делать на хосте, и буферизировать опять же на хосте, а от платы с процессором впятеро мощнее Ориона и размером в половину Ориона ничего кроме печати символа и взять будет нечего.
Где можно посмотреть спецификацию на все управляющие последовательности Ориона, ну вернее того что на нем будет запускаться?
На сколько они далеки от терминальных стандартов? Можно ли софт Ориона привести в соответствие какого нибудь стандарта терминалов?
У Вас Орион какой то особенный или стандартный Орион-128?
Неожиданно мне пришла очередная идея. Если управлять выводом текста с помощью управляющих последовательностей, тот тогда видеокарта в виде видеобуфера в адресном пространстве основного процессора, как зайцу стопсигнал. Это бесполезная затея с memory mapped style. Тут идеально подойдет I/O style. Т.е. имеем тот же терминал, который представляется обычным 8-ми битным портом в пространстве ввода/вывода основного компа. В него будут слать все тоже самое как и в COM-порт слали бы на терминал. Выгода в том, что физически COM порта нет и возможен высокоскоростной вывод на дисплей со скоростью до несколько Мбит. Удобно также, что экономится память, о 8-ми биток ее и так не много :)


А я ведь целью текстового адаптера преследую не только красиво вывести на монитор, но и максимально разгрузить хост (Орион в моем случае) как от лишних тактов вычисления, так и от лишних байтов кода на эти вычисления, хранящихся в дефицитном адресном пространстве 8-битки.
Сейчас сам строю машину на 8080 под CP/M. Работает неприлично быстро, как для 8080 :) Именно потому что не обрабатывает ESC-последовательности и не парится насчет вывода символов.

Также, зрение уже не то что прежде, и надо хотя бы добавить программируемый регистр фона (в идеале построчно на каждую строку символов - 25 байт в Меге под это выделить). Долго в черный квадрат смотреть уже не могу - устаю быстро.
Это вроди уже обсуждали. Мега не знает какая текущая строка у ВГ75. Мега -это DMA, шлет себе массив 4000 байт 72 раза в секунду и все остальное ей пофиг. К стати взять 25 байт в меге не от куда. Все использовано. По идее,чтобы навесить на ВГ75 дополнительные атрибуты поля, нужно городить внешний буфер строк и синхронизировать его выборку от VSYNC и HSYNC. Но я так не делал, Вы ж и так пышыте шо моя плата как пол-Ориона :) А со всеми этими наворотами она еще потолстеет :)
Правда есть и более изящный путь. Нужно взять 2 ВГ75 (две, Карл!) и запустить их синхронно. Одна будет работать как и работает сейчас. А второй ВГ75, Мега будет скармливать, скажем 2000 байтный буфер атрибутов фона знакоместа. Т.е. получили то что нужно. На выходах CC0-CC6 второй ВГ75 мы получим в нужный момент атрибут фона соответствующего символа, который рисует первая ВГ75. Итого имеем 256 символов, 8 цветов символов, мигание, подчеркивание (сверху :)) и 128 цветов фона каждого символа по отдельности :) И это как пример. Ресурсы второй ВГ75 можно распределить и по другому...
Но плата же и так как пол-Ориона! :v2_lol:

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

Убс... Затупил написать, что если во второй ВГ75 заюзать LC0-LC3, то можно получить супер, мега аффекты в виде градиетной заливки шрифта и или еще чего то в этом духе!

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

Неудачный пример привел. 127 цветов фона - много. Лучше 16 цветов символа и 16 цветов фона. Да здравствует полноценный режим CGA/VGA!

[blackmirror]

А при этом еще экран VGA програмно сможет перерисовывать 60 раз в секунду?
И не просто, а осмысленно из видеобуфера и памяти знакогенератора... И еще с клавы принимать символы...
Для Xmega минимальный код выдающий на 8 ног атрибуты и на другие 8 ног данные для сдвигового регистра(еще требуется буферный регистр для синхронизации изменения атрибутов и начала сдвига) требует 8 тактов на символ:
LD ATTR,[PTR++]
LD CHAR,[PTR++]
LD BITS,FONT_LINE_N[CHAR]
OUT VPORTA,ATTR
OUT VPORTC,BITS
при этом символы с атрибутами и шрифт должны сидеть в памяти. Если хочется использовать шрифт из flash, то потребуется тормозная команда LPM и вместо 8 тактов мы будем тратить 9. Чтобы вернуться к 8 тактам, можно вывод атрибутов поручить DMA, при этом сделать пересылку DMA сможет параллельно с LPM(если верить документации, но нужно проверять!) Огранизовав код следующим образом(таймер программируется так, чтобы пересылка через DMA шла параллельно с LPM):
LD CHAR,[PTR++]
LPM BITS,FONT_LINE_N[CHAR]
LD CHAR,[PTR++]
OUT VPORTC,BITS
LPM BITS,FONT_LINE_N[CHAR]
FREE 4 TICK
OUT VPORTC,BITS
мы получим на каждые 2 символа дыру в 4 такта, в которую вполне влезет код, принимающий данные по UART и складывющий в циклический буфер, при этом потерь не будет даже на скорости 4Mbps, хотя на обработку времени конечно не останется.
Что касается PS/2, то если частота меньше строчной(<31кГц к примеру), момент изменения CLK и DATA вполне можно захватить таймером, а в конце строки разбираться чего там произошло.


И еще терминал эмулировать...
Соберите схемку сами, пощупайте ее, там три детальки всего... Потом нам расскажите Ваши впечатления от ее работы.
Если вернуться к более реальным скоростям, то читая по одному байту из UART в конце каждой строки можно не напрягаясь принимать по 20-30КБайт/с и складывать в буфер. Если полная длина строки 800 точек при 640 видимых, то у нас вполне достаточно времени для обработки большей части команд "на лету", а сложности будут только с командами выполняющими очистку или заполнение больших областей, для них всё равно нужно иметь какой-то механизм чтобы сообщить о том, что терминал пока не готов принимать новых команд.

[Error404]

Но плата же и так как пол-Ориона! :v2_lol:


Я больше скажу, сейчас я тоже подумываю запилить микро-Орион (дополнив схему Гранта Сирла) - она получается порядка 10-12 микросхем вместе с RS-232. Т.е. в полтора-два меньше варианта видеокарты работающей по адресному пространству (которая здорово подросла в сравнении с терминалом). :) Так что и даже две ВГ75 кардинально не влияют на пропорцию.

Наиболее распространенный вариант ESС-кодов Ориона такой:
https://github.com/serge-404/AltairDOS/blob/master/Driver/about.txt

[freddy]

Мде... ВГ75 вобще микросхема не для слабаков. Чтобы любить ВГ75, нужно еще любить паять, сверлить, дружить с осциллографом. Время ее прошло, также как и мое. Материалы по видео на ВГ75 решился больше не выкладывать, чтоб не тратить свое и Ваше время. Возможности ВГ75 мною полностью изучены и используются, для меня тема "Что максимум можно выжать из КР580ВГ75..." больше не интересна. Она начинает походить на театр одного актера.
Стройте на XMega. А лучше на STM32. Так Орион будет ваще как спичечный коробок с VGA-видео и хранилищем на SD карте.

[A_AVL]

Мде... ВГ75 вобще микросхема не для слабаков. [...]

IMHO, не стоит так резко рвать проект. Реально очень большая работа проделана с творческим использованием возможностей ВГ75. Кому-то он реально интересен, например мне.


Я больше скажу, сейчас я тоже подумываю запилить микро-Орион
На мой взгляд, в таком случае проще на том же новодельном (да и на олдскульном) орионе сделать нормальную конвертацию на лету управляющих кодов Ориона/РК в коды стандартного VT-100 и отдавать уже их терминалу. Тем более, никаких трудностей и несовместимостей в том числе и программных в этом нет, т.к. драйвер дисплея в Орионе подгружаемый и может быть легко заменён с поддержкой именно VT-100.


Если управлять выводом текста с помощью управляющих последовательностей, тот тогда видеокарта в виде видеобуфера в адресном пространстве основного процессора, как зайцу стопсигнал. Это бесполезная затея с memory mapped style. Тут идеально подойдет I/O style.[...]
Поддержку I/O Style одновременно с UART можно ввести в тот же терминал. Не нужно обращение через I/O - регистры не ставятся, да и всё. Порты незанятые есть, входы прерывания тоже. Только нужно сделать так, что бы ввод с клавиатуры и световое перо тоже могли быть получены как по RS-232, так и по I/O.

[Error404]

Мде... ВГ75 вобще микросхема не для слабаков. Чтобы любить ВГ75, нужно еще любить паять, сверлить, дружить с осциллографом. Время ее прошло, также как и мое. Материалы по видео на ВГ75 решился больше не выкладывать, чтоб не тратить свое и Ваше время. Возможности ВГ75 мною полностью изучены и используются, для меня тема "Что максимум можно выжать из КР580ВГ75..." больше не интересна. Она начинает походить на театр одного актера.
Стройте на XMega. А лучше на STM32. Так Орион будет ваще как спичечный коробок с VGA-видео и хранилищем на SD карте.

Что на Орионе свет клином что ли сошелся, в каждом посте его всуе поминать? Эка важность, попросили доделать что-то, девицы тут что ли собираются, от такого в осадок выпадать?
А проект без исходников - таки и есть театр одного актера, затеянный заради сбора лайков. "Я смог, а вы нет - ну и слабаки", так надо понимать? Тогда уж да, я лучше контроллер возьму.

[freddy]

Я его рвать не собираюсь. Когда интересно, я всегда рад поделиться.

На мой взгляд, в таком случае проще на том же новодельном (да и на олдскульном) орионе сделать нормальную конвертацию на лету управляющих кодов Ориона/РК в коды стандартного VT-100 и отдавать уже их терминалу. Тем более, никаких трудностей и несовместимостей в том числе и программных в этом нет, т.к. драйвер дисплея в Орионе подгружаемый и может быть легко заменён с поддержкой именно VT-100.
Вы прямо мои мысли озвучили. Если хочется использовать какое то стандартное железо, то надо свое сперва привести к стандарту.
Думаю, Вы согласны, что железо должно удовлетворять некоторым мировым стандартам, особенно коммуникационное типа видеотерминала.

Поддержку I/O Style одновременно с UART можно ввести в тот же терминал.
Э... с Uart одновременно, как бы немного бессмысленно. Програмно оно конечно же может одновременно существовать в ядре в виде обработчиков прерывания от COM порта и от 8-ми битного параллельного порта. НО, одновременно будет работать только один источник. А самому терминалу всеравно откуда данные поступают. Он контролирует только вершину буфера входных данных. Драйвер приема символа эту вершину изменяет. Поэтому все просто. Какой драйвер будет срабатывать по прерыванию, те символы и будут обрабатываться, даже переключать ниче не надо.


Не нужно обращение через I/O - регистры не ставятся, да и всё.
Так точно! Для внутреннего использования, например, не нужен RS-232. Поэтому разъем DB9 и MAX232 можно не паять.
Все сведется к одной или двум версиям плат и единой прошивке.


Только нужно сделать так, что бы ввод с клавиатуры и световое перо тоже могли быть получены как по RS-232, так и по I/O.
Ну так оно уже давно сделано. Я даже прерывания компу могу генерировать, чтоб он забирал данные, передаваемые терминалом.
А с световым пером лажа. Оно не работает на LCD мониторах. Тока на ЭЛТ. У меня их есть! :) Не уверен что у других они тоже есть.

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


Что на Орионе свет клином что ли сошелся, в каждом посте его всуе поминать? Эка важность, попросили доделать что-то, девицы тут что ли собираются, от такого в осадок выпадать?
Я конкретно под одну заданную машину не могу делать. АВР он ведь не резиновый. Исходники причесывать пока нет времени. А то потрачу только зря чужое время и еще *****кодом обзовут и кучу багов найдут.

"Я смог, а вы нет - ну и слабаки", так надо понимать?
Не стоит.

Тогда уж да, я лучше контроллер возьму.
Возьмите эту машинку, даже паять не придется.
Вот: https://ru.aliexpress.com/store/product/New-Orange-Pi-Zero-H2-Quad-Core-Open-source-512MB-development-board-beyond-Raspberry-Pi/1553371_32761500374.html?spm=2114.12010208.0.0.hbz kr7
не реклама!

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


А проект без исходников - таки и есть театр одного актера, затеянный заради сбора лайков.
Точно! Я же за лайки и просмотры этой темы деньги получаю :)

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


Если вернуться к более реальным скоростям, то читая по одному байту из UART в конце каждой строки можно не напрягаясь принимать по 20-30КБайт/с и складывать в буфер. Если полная длина строки 800 точек при 640 видимых, то у нас вполне достаточно времени для обработки большей части команд "на лету", а сложности будут только с командами выполняющими очистку или заполнение больших областей, для них всё равно нужно иметь какой-то механизм чтобы сообщить о том, что терминал пока не готов принимать новых команд.
Вот это уже интереснее... У меня терминал готов всегда! Даже когда делает скроллинг содержимого экрана.
Но есть конечно и "какой-то" механизм... Называется XON/XOFF, еще есть RTS/CTS...
У меня реализовано только RTS/CTS для очень медленных машин.
Сделайте проект софтварного видеотерминала на микроконтроллере. Я могу помочь качественным эмулятором VT100/VT52.
Было бы интересно собрать что то простое, карманное. Только почему ATXMega ? Может лучше Cortex STM32F103 бакса за 1,5-2? Всяко 72Мгц лучше будет.
Есть 20кило SRAM, всякие плюшки типа DMA контроллера...

[freddy]

Всем привет!
Нарисовал схемку с учетом входных и выходных буферов для подключения типа "IO style". ~IOWR, ~IORD должны будут дешифроваться внешней логикой или браться с дешифратора адресов устройств ввода/вывода самого компа. DB0-DB7 это шина данных компа. U16 это буфер выходных данных. Данные защелкиваются сигналом OL(out latch). С этого же сигнала предусмотрена генерация сигнала прерывания INT, чтобы комп забирал данные сигналом ~IORD. Если аппаратного контроллера прерываний нет, INT можно не использовать. Следующий байт не будет записан в буфер, пока комп не заберет предыдущий, так как запись в буфер происходит в обработчике сигнала ~IORD.
U17 это входной буфер. По сгналу IOWR сгенерируется прерывание и микроконтроллер заберет оттуда байт, когда освободится.
увы и ах. Инверторы закончились, пришлось еще U18 добавить :)
Вот оно:
60536

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

Код буду дорабатывать в июне. Нужна программа setup. Очень!

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

Еще RTS/CTS можно убрать, практика показала, что оно не нужно.

[Shumadan]

а где можно глянуть исходники конструкции на ВГ75 с целью повторить. Ссылки выше уже недоступны

[freddy]

Я поудалял, чтоб не плодились старые платы и прошивки. Будет прошивка под схему, выше на два поста. Там где есть RS-232 и I/O порт. Сейчас мне не до этого, много работы.

[Shumadan]

на этом вы закрываете проект или будете развивать дальше?
ВГ75 стабильно работает? просто смотрю, стоит 8275

[freddy]

Ничего я не закрываю. ВГ75 оказалась более привлекательной и доступной, чем та же MC6845. Как бы по соотношению цена/возможности - лучший вариант. Где еще за 10-20р найти видеоконтроллер? Еще есть куда развивать. 2хВГ75 для меня тоже интересны, с разносом знакогенераторов, чтоб у каждой была своя половина знакогенератора в отдельной ПЗУ, потом шины данных ПЗУ объединить по ИЛИ и подать на сдвиговый регистр. Поимеем халяву в 256 символов без всяких ограничений по количеству переключения атрибутов на одну строку. Еще мне интересен вариант с графическим режимом 640х400. Он у меня тоже получился, только нужно до ума довести. Просто я сейчас в таких условиях, что мне не до хобби. ВГ75 отлично работает. В схеме стоят буржуйские названия, потому что это сделано в Proteus. Можете смело ставить наши любимые К155, К555, КР531.

[b2m]

потом шины данных ПЗУ объединить по ИЛИ и подать на сдвиговый регистр
А почему бы не использовать 7-битный код второй ВГ75 как номер знакогенератора? Получишь аж 16384 символа :)

[Shumadan]

А почему бы не использовать 7-битный код второй ВГ75 как номер знакогенератора? Получишь аж 16384 символа :)

ага, и все сочетания точек в знаке для псевдографики:v2_dizzy_coder:

[freddy]

А почему бы не использовать 7-битный код второй ВГ75 как номер знакогенератора? Получишь аж 16384 символа
Да, работать будет. Что потом делать с таким количеством символов? Тогда может лучше 1 бит на выбор знакогенератора, 3 на цвет символа и 3 на цвет фона.
Получим почти то же самое, что есть сейчас, но без ограничений на количество переключений атрибутов на одну строку. И курсор пусть будет в виде мигающего прямоугольника как в терминаторе-1 и древних терминалах :) Ведь бит инверсии теперь освободится.
.
ага, и все сочетания точек в знаке для псевдографики
Это не совсем так. Мы имеем символ высотой в 16 строк. Каждая строка - это 256 комбинаций точек. А 16 строк это просто колоссальное количество комбинаций. Поэтому рулит полноценный графический режим 640х400 с 32кб видеопамяти вместо знакогенератора.

[b2m]

Тогда может лучше 1 бит на выбор знакогенератора, 3 на цвет символа и 3 на цвет фона.
Тоже об этом подумал, но постеснялсь предложить. К тому же, всего два знакогенератора - маловато. :)

[freddy]

Не маловато. Нам надо чтоб отображалось 256 символов, сделано. Сам набор символов возможность переключать тоже есть. В последней схеме несколькими постами выше есть сигналы А12, А13. Они задуманы для переключения знакогенераторов (в текущей прошивке пока не задействованы). Т.е. можем иметь 4 набора по 256 символов. Я предполагал это использовать для смены кодовых страниц (можно вместе с формой шрифта), чтобы не замедлять работу процессора видеокарты таблицами перекодировки. Собственно KOI-8R и CP-866 достаточно для старых систем.

[Xrust]

А без использования современной элементной базы, в часности без контроллера, подобный функционал (кои8 + цвета+ vga) удасться получить?

[freddy]

А без использования современной элементной базы, в часности без контроллера, подобный функционал (кои8 + цвета+ vga) удасться получить?
VGA и KOI-8 тут к современной элементной базе никаким боком не относятся.
Сам же терминал, видеодрайвер и DMA вполне реализуем на не очень современном железе. Можете попробовать Z80, i8085 из соображений минимальности обвязки. По быстродействию точно хватит. Еще понадобится ОЗУ, ПЗУ, 2шт UART, контроллер прерываний и кучка логики, чтоб это все заработало :)

[Xrust]

VGA и KOI-8 тут к современной элементной базе никаким боком не относятся.
Я вот мечтаю все это реализовать максимально используя 580 чипсет.

[freddy]

Я вот мечтаю все это реализовать максимально используя 580 чипсет.
ну тогда нужно собрать волю в кулак. Сам проц i8080 довольно громоздко запускать. Кроме самого проца Вам понадобится два 8ми битных буфера на шину адреса (КР580ИР82), системный контроллер (КР580ВК28), генератор тактовых импульсов (КР580ГФ24), два UART КР580ВВ51 и КР580ВИ53 для их тактирования. Еще КР580ВН59 для обработки прерываний от UART и ВГ75. Плюс какое то ОЗУ и ПЗУ, еще кучка логики, чтобы все друг с другом подружилось.
Получится приличная лаптя, ее для скорости 9600 хватит :)
Я такую собрал. Вот можете оценить размеры на фото. Здесь нет BH59 :( И это... я здесь сильно экономил :)
6102061021
Все это легко заменила одна ATMEGA.

[TomaTLAB]

а где можно глянуть исходники конструкции на ВГ75 с целью повторить. Ссылки выше уже недоступны

Я поудалял, чтоб не плодились старые платы и прошивки.
Это зря. Я вот только наткнулся на эту тему и она мне очень интересна. И очень хотелось бы проследить именно развитие схемотехники этого контроллера.
Тем более, что с привязкой к постам и времени обсуждения это была весьма ценная информация и разные варианты схемы вряд ли запутают.
А вот как раз варианты плат и прошивки без исходников да, ценность имеют не высокую в данном контексте.

[Xrust]

Здесь нет BH59
ВТ57 и ВГ75 я здесь тоже не наблюдаю... Или это "материнка", а "видеокарта" отдельно? На ВН59 я точно не хочу экономить. А сам проц, ГФ24 и ВК28 у меня нашлись в заветной баночке из-под кофе :)

[freddy]

ВТ57 и ВГ75 я здесь тоже не наблюдаю...
Это я показал, что Вам нужно для замены ATMEGA. И зачем же Вам ВТ57? Она точно не нужна.

Или это "материнка", а "видеокарта" отдельно?
Это полноценный комп. Видеокарта ему не надо. У него RS-232 и терминал, как раз такой, как в этой ветке родился.
Комп, типа этого, понадобится для избавления от меги.
На макетке такое строить накладно однако. Если намерения серьезные, то рисуйте схему и разводите печатную плату.


Это зря. Я вот только наткнулся на эту тему и она мне очень интересна. И очень хотелось бы проследить именно развитие схемотехники этого контроллера.
Назад уже не вернуть. Да и место под файлы закончилось. Я новое не мог бы выкладывать. А теперь почистил и все ОК.

[Xrust]

И зачем же Вам ВТ57?
Так я вел речь про реализацию видеоадаптера с VGA выходом и т.д. на ВГ75 без применения ATMEGA. Насколько я понимаю, ВГ75 для работы необходима ВТ57. В вашем проекте ПДП осуществляет именно ATMEGA. Правильно?

[freddy]

Насколько я понимаю, ВГ75 для работы необходима ВТ57.
не нужна. нужен интеллект внутри цикла ПДП, естественно ВТ57 не подходит для этих целей.

В вашем проекте ПДП осуществляет именно ATMEGA. Правильно?
Да, она.

[TomaTLAB]

Так это вообще-то вообще не ПДП :) от которого только название сигнала и осталось, а чистой воды прерывание.
Обработчик которого и формирует то, что в буфер ВГшки скормить.
Потому как туда нужно вовсе не содержимое памяти чохом пихать, а с "обрамлением" так сказать.
Если я все правильно понимаю.

[Xrust]

Потому как туда нужно вовсе не содержимое памяти чохом пихать, а с "обрамлением" так сказать.
Ага, а "обрамлением" должен будет процессор в данном случае заниматься? А он справится? Если я все правильно понимаю.

[freddy]

Вот, посмотрите под спойлером. Это обработчик DMA запросов.
Для i8080 он вполне по силам. 8080 желательно подразогнать хотябы до 3МГц и еще останется время на выполнение кода терминала.
В общем пробуйте.


EXT_INT1: ; VG75 DMA Cycle Emulator
push r16
in r16,SREG
push r16
push ZH
push ZL
push r18
push r17
cbi PORTA,vg75_dac

lds ZH,dma_p ;Это указатель в видеобуфере
lds ZL,dma_p+1
dma_int4: sbis PIND,PD1 ;это проверяется сигнал DRQ
rjmp dma_int3
ld r16,Z+

sbrs r16,7 ;бит 7 это признак, что мы наткнулись на атрибут
rjmp dma_data
cp old_attr,r16 ;в old_attr сохраняется значение предыдущих атрибутов
breq dma_dat1
mov old_attr,r16


dma_data: out PORTC,r16
cbi PORTA,vg75_wr
dma_dat1: cpi ZL,low(screen+s_buf_size)
ldi r16,high(screen+s_buf_size)
cpc ZH,r16
sbi PORTA,vg75_wr


brne dma_int4
ldi ZL,0x80 ;сюда мы попадем когда видеобуфер закончится и начнем заново
mov old_attr,ZL
ldi ZL,low(screen) ;screen это начало видеобуфера
ldi ZH,high(screen)
rjmp dma_int4



dma_int3: sbi PORTA,vg75_dac
sts dma_p,ZH
sts dma_p+1,ZL
pop r17
pop r18
pop ZL
pop ZH
pop r16
out SREG,r16
pop r16
reti

Перепишите под 8080, посчитайте такты.

[bigral]

i8080 это универсальный cpu, в том смысле что у него 64kB адресуемого смешанного инструкции\данные пространства (т.е. изначально он рассчитан на то что его адресное пространство будет по желанию разделятся в любой пропорции между данными и кодом). Для спец. контроллеров типа звукового генератора, расширителя I/O или "интелектуального DMA" это не нужно и вредно, тут более подходит гарвардская архитектура mcs-48 семейства с ее 4kB. Ее как раз выпустили для тех мест где будет не сильно длинная программа помещенная в ROM (т.е. НЕ предпологается загрузка программы с внешнего источника в память программ, хотя и это вполне возможно при определенных наворотах в схеме, которые впрочем выходят за рамки разумного). Кроме того есть mcs-51 там где не хватит mcs-48.

[TomaTLAB]

Ну так это как бы очевидно. Если бы "классический" 51-й по скорости проходил, то получилось бы вполне логично и "в духе времени".
Ногами дрыгать он горазд, и внешняя память на него навешивается без проблем, что ПЗУ, что ОЗУ. (Из гарварда в фон неймана, кстати, он с внешним ОЗУ одним внешним лог. элементом переводится:))
Но по скорости, наверно, нужно что нибудь вроде 80с54 на 33МГц. Или опять же, из современных скорострельных с 4 тактами на цикл... Но это нужно будет подумать, растактовку посчитать.

[A_AVL]

А с чего 8051 по скорости не пройдёт?
https://drive.google.com/file/d/0B9rh9tVI0J5mODAyYzBiMWYtZTU1NS00MTRjLWI5NDAtNzQ0N TBjNWI2ZTIz/view
Вот готовое решение на 8051 и 8276 (почти 8275) от Интела. Терминал.
Там же рядом есть и идеологически похожий на решение freddy вариант 8085-8275 программным ПДП

[freddy]

Для терминала не надо супер производительности. Какие там 33Мгц... 3МГц хватит, так как ассемблер рулит.
ВелосЫпЭд изобретать не надо. Просто уберите АТМегу и поставьте любой раритетный 8-ми битный проц. Например Z80 прост в обвязке и его везде как грязи. До сих пор производят. Подумайте насчет него. Всего то понадобится. Z80SIO, Z80, 2764, 62256, пару-тройку логики. Можно попробовать обойтись без контроллера прерываний. По деталям получится меньше чем на 8080.
Фишка в том что на МГТФе столько не собереш или глючить будет. Нужно печатную плату разводить с ретро компом вместо атмеги.

[freddy]

К стати в оригинальном DEC VT100 был i8080 :)

[freddy]

Ура! Нашел! Не нужно ничего изобретать.
Когда то давно была такая вот железка... Называлась simpliway videoboard, тоже на ВГ75. Она могла быть как портом ввода/вывода, так и отображать видеобуфер в память. Работала на шине S100, но это не беда, можно из схемы жменю микрух выкинуть и оставить только Internal Bus. Отображала 80х24, весьма ущербно, с телевизионной разверткой. Видеогенератор там у них ваще допотопный, я рыдалЪ. Так вот, можно взять мой видеогенератор и приколхозить к их процессорной части. Исходники там есть. Можно подправить инициализацию ВГ75 и будет счастье! Видеотерминал на ретро комплектующих :)
Вот, ловите: http://www.classiccmp.org/dunfield/s100c/misc/simvdba.pdf

[Shumadan]

Ура! Нашел! Не нужно ничего изобретать.
Когда то давно была такая вот железка... Называлась simpliway videoboard, тоже на ВГ75. Она могла быть как портом ввода/вывода, так и отображать видеобуфер в память. Работала на шине S100, но это не беда, можно из схемы жменю микрух выкинуть и оставить только Internal Bus. Отображала 80х24, весьма ущербно, с телевизионной разверткой. Видеогенератор там у них ваще допотопный, я рыдалЪ. Так вот, можно взять мой видеогенератор и приколхозить к их процессорной части. Исходники там есть. Можно подправить инициализацию ВГ75 и будет счастье! Видеотерминал на ретро комплектующих :)
Вот, ловите: http://www.classiccmp.org/dunfield/s100c/misc/simvdba.pdf
еще бы разжевать)

[Xrust]

Я до сих пор не определился окончательно с выбором кодировки. Многие программы в CP/M портят старший бит. Из-за этого альтернативная кодировка будет выглядеть полностью не читаемой. Насколько вообще востребована альтернативная кодировка в CP/M? Я пока стал склоняться в пользу КОИ-7 с переключением наборов "на лету" атрибутами через GP0, GP1. От атрибутов цвета тогда придется отказаться. Но можно будет предусмотреть настройку цвета фона и символов целиком для экрана, как просил Error404.

[freddy]

еще бы разжевать)

Там же есть раздел "Theory of operation", все разжевано :) Ну и схема же принципиальная тоже есть :)

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

Обратите внимание на CLOCK. Проц работает на 2МГц и успевает ;)

[freddy]

Всетаки что же будет, если взять 2 ВГ75 (две, Карл)!? Оказалось, будет очень хорошо. Потому что ВГ75 лишних не бывает, ну или "кашу маслом не испортишь".
Набросал я тут новый видеогенератор. 61091
В общем то даже микросхем больше не стало, но возможности сильно выросли. Теперь у нас текстовый режим 03H :) И организация видеобуфера точно такая же как в режиме 03H у VGA-видеокарты. Байт атрибутов: BLINK|BR|BG|BB|HGLT|FR|FG|FB, за ним байт кода символа.
При этом B - значит background, F-forereground, HGLT- повышенная яркость forereground. BLINK- это счастье за счет атрибута RVV. И курсор будет в виде мерцающего прямоугольника. На LTEN можно забить, он не нужен теперь. Короче 16 цветов символа и 8 цветов фона это гуд.
Отсутствие ограничений на применение атрибутов это VERY GOOD! Скоро буду собирать такое чудо.
Немного по схеме... Атрибуты цвета и старший бит кода символа выгребает U18. Остальные 7 бит кода символа, бит яркости и бит мерцание выгребает U4. Далее все что касается атрибутов сохраняется в регистр U6, ну и когда начинает разворачиваться символ, все эти цвета и яркость колбасятся мультиплексором U15 в нужной последовательности прям на монитор. Мерцание реализовано на U19.
Отличная идея и красивое название. КР580ВГ75 Dual Head edition! :v2_lol:

[Xrust]

Атрибуты цвета и старший бит кода символа выгребает U18. Остальные 7 бит кода символа, бит яркости и бит мерцание выгребает U4.

А подменой этих битов занимается ATMEGA при записи строк в ВГ-шки?

[freddy]

А подменой этих битов занимается ATMEGA при записи строк в ВГ-шки?
Ну конечно ATMEGA.

В этом варианте возможно обойтись без АТМЕГИ. Забиваем на мерцание и повышенную яркость и тогда перестановки не надо.
Можно тупым ПДП типа ВТ57 обойтись. В первом байте будет младшие 7 бит кода символа, во втором байте: бит0-старший бит кода символа и еще 6 бит цветов. 7-й бит не нужен и не используется. Перестановкой старшего бита кода символа будет заниматься сам проц при записи данных в видеобуфер.

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


Я до сих пор не определился окончательно с выбором кодировки.

Рекомендую пока что пользовать просто младшие 128 символов. Раскладка у них везде одинакова.

[A_AVL]

Я конечно понимаю, что советы давать легко и просто :) но может быть сделать в EEPROM ATMEGA128 две таблицы - передодировки выводимых на экран символов и перекодировки вводимых с клавиатуры символов? Кому нужно, те смогут подправить этот hex и сделать какую угодно кодировку для себя?
Upd:
По крайней мере, каждый желающий не трогая саму прошивку сможет указать соответствие кодировки такое, какое ему необходимо, хоть КОИ, хоть ДКОИ, хоть и СР-866.

[TomaTLAB]

В первом байте будет младшие 7 бит кода символа, во втором байте: бит0-старший бит кода символа и еще 6 бит цветов. 7-й бит не нужен и не используется. Перестановкой старшего бита кода символа будет заниматься сам проц при записи данных в видеобуфер.
У меня вертится идея аппаратной перестановки старшего бита. В первую ВГшку загоняем 7 младших бит, старший сохраняем в защелке. Из следующего байта загоняем во вторую ВГшку 6 бит и 7-ой из защелки. :v2_dizzy_stupid: Э?

[freddy]

Я конечно понимаю, что советы давать легко и просто
Мне не просто. Надо ж еще подумать, а это мне с каждым днем все труднее.


но может быть сделать в EEPROM ATMEGA128 две таблицы - передодировки выводимых на экран символов и перекодировки вводимых с клавиатуры символов?
Не может быть. Выше писалось о перекодировке символов, вспоминаем назначение A12 и A13. Увидев их, один мультяшный герой сказал бы: "Это жжж не спроста." И тратить на это процессорное время не предполагается.
Вобще это VT100 и показывать одновременно 256 символов он не обязан. Это я просто у себя сделал такое лирическое отступление, чтобы показывались все 256 символов. По скольку устройство VT100 стандартизировано, то можно не париться насчет кодовых страниц.


По крайней мере, каждый желающий не трогая саму прошивку сможет указать соответствие кодировки такое, какое ему необходимо, хоть КОИ, хоть ДКОИ, хоть и СР-866.
Оно вобще не надо. Русский мало где применяется. Я сделал CP866 вобще ради того чтобы таблички в DOS navigator рисовались красиво. А KOI-8R это для линуксоидов. Я с этого терминала ходил даже в Интернет через Lynx. Русские сайты нормально отображались. Каких то других кодовых страниц не стоит лепить за не надобностью.

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


У меня вертится идея аппаратной перестановки старшего бита. В первую ВГшку загоняем 7 младших бит, старший сохраняем в защелке. Из следующего байта загоняем во вторую ВГшку 6 бит и 7-ой из защелки. Э?
Попробуйте смоделировать чем нибудь. Интересно сколько корпусов получится.
Возможно процессором все же проще. Пусть регистровая пара ZH:ZL указывает на нужный адрес буфера экрана, в r16 символ который нужно туда записать, какой то регистр будет называться atrib и содержать текущие атрибуты.
Тогда код записи символа:
rol r16
rol r17
lsr r16
add r17,atrib
st Z+,r16 ;младшие 7бит кода символа
st Z,r17 ;старши бит кода символа и 6 бит атрибутов

Радуемся, 8 тактов на анализ старшего бита и запись в буфер 2 байт.

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

От ПДП требуется всего лишь бережно положить один байт туда, другой сюда :)

[Xrust]

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

[freddy]

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

[TomaTLAB]

Но мы (по крайней мере я) тут все клинья подбиваем, чтобы только ВТ57 обойтись без неканоничной Атмеги И тут уже становится несколько плевать на количество "лишних" корпусов, лишь бы не совсем не скатиться к куче мелкой (и "жесткой") россыпи. Что-то можно, конечно, упаковать во вполне каноничные ПЛМ (РТ1/2) или мелкие ПЗУхи. Но тогда мы "Корвет" получим на выходе :D

[freddy]

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

[Xrust]

И при этом чтобы они не мешали друг другу.
Чтоб совсем не мешали? С ВТ57, мне кажется, так не получится. Или как-то делить системную шину.

Еще, если не трудно, хотя бы блок-схему.
У меня пока нет опыта применения ни ВТ57, ни ВГ75. Вот придет посылка, попробую потренироваться сначала на простом. А то от теории уже голова пухнет. Надо практикой закрепить. Советские даташиты и справочники писали не понятно для кого. Информация крайне скудная и подана очень плохо. С английским же у меня пока на "троечку", долго вникать приходится.

[freddy]

Нужно чтоб видео и проц работали асинхронно, не мешая друг другу никогда. Для упрощения задачи пусть процессор только пишет, DMA всегда читает. Какие идеи?

[OrionExt]

Мучают. Мучают ВГ75. Включите ее уже, как в мануале Intel написано и радуйтесь старушке (79г.)

Шутка юмора.

[A_AVL]

Развел плату для схемы в сообщении 110 (http://zx-pk.ru/threads/26455-chto-maksimum-mozhno-vyzhat-iz-kr580vg75-intel-8275-obsuzhdenie.html?p=907867&viewfull=1#post907867)
Нумерация компонентов другая, размер платы 100х100мм.
На плате разведены интерфейсы RS-232 и шина I/O. На плате распаивается один из интерфейсов.
Блокировочные конденсаторы есть на схеме, но на плате не установлены (кроме С17,С18) - напаиваются непосредственно на выводы ДИП ИМС.

UPD. 26/05
В схему внесены дополнения для возможности контролировать состояние буфера клавиатуры, если в системе нет прерываний. Для этого введен доп. адрес чтения и на базе имеющихся ИМС собран дешифратор. При чтении по четному адресу считываем байт из буфера, по нечетному - в бите D0 флаг заполнения буфера (0-ничего нет, 1 - что-то есть). Бит сбрасывается автоматически.
Для того, что бы не лепить еще одну микросхему формирователя на шину DB ради одного бита - используется одногейтовый буфер с третьим состоянием.

Я полагаю, что модификаций достаточно и если вопросов к схеме/плате нет, то плату можно заказывать.

Новая схема 61141
И плата. 61142

[freddy]

Нумерация компонентов другая, размер платы 100х100мм.
Свою схему тоже прикрепите, чтобы нумерация на печатке соответствовала схеме. Будем по Вашей собирать :)

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

Я вот немного поторопился и на заводе сделал такие платы без I/O порта. Размер 130х100, но зато легко собирать и сплошная земля :)
Все просторно, даже ЛУТом можно делать.
61134

[creator]

A_AVL и freddy, а можно ваши "разводки" в более детальном виде увидеть? ;)

[Xrust]

freddy, а вы не разбирались как в Электроника КР-04 графические режимы реализованы? Это ведь модификация Радио-86РК.

[freddy]

Вот моя разводка печатной платы в Sprint Layout 5.
61143
Она соответствует схеме выше, но нет регистров IO. Тогда я их еще не планировал :)

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


как в Электроника КР-04 графические режимы реализованы? Это ведь модификация Радио-86РК.
Да как то это не РК уже. Это КР01-03 были как РК.
И чего там разбираться, на этом форуме где то схема была. Так там кажись были за мултиплексированы шины ВГ75 и проца к памяти. Это дало возможность располагать там изображения. ВГ75 это адресовала как несколько ЗГ с последовательно повторяющимеся номерами символов 0-127.

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

61144
Вам наверное это больше поможет в осмыслении. Так у меня сделано, нарисовано понятнее и проверено.
Это дает два экрана VGA 640х400 mono. Возможен Double Buffering, выводятся сразу 8 точек за один mov m,a. Приятно для тормоза типа 8080 :)

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

Моя схема из моно легко превращаема в цвет. Например сделать 640х400х8 с раздельными плоскостями проще паренной репы. Можно писать хоть все три одновременно :)

[Xrust]

И чего там разбираться, на этом форуме где то схема была.
Там схема больно потертая и я до сих пор не все в ней понял.

[freddy]

Вот только что посмотрел схему КР-04. Принцип работы там понятен, качества схемы достаточно. Все, как я писал выше. Но зато реализовано как то странно... Зачем то кусочек видеогенератора, отвечающий за формирование цвета, упихали в ПЗУ :) Экономия!
И нельзя сказать что курили что то тяжелое, когда его проектировали, но сейчас так лучше не строить.

[barsik]

Вот только что посмотрел схему КР-04

А где Вы посмотрели схему КР-04 ? Не поделитесь ли ссылкой ?

Видел только фотографию печатной платы КР-04, а его схемы не нашёл. Схема интересует, чтобы узнать как ставить в РК86 системный контроллер ВК28.

[OrionExt]

Сегодня листал 74 серию и нашел там сист. контролер для I8080.

[Xrust]

А где Вы посмотрели схему КР-04 ?
Электроника КР-04 схема (http://zx-pk.ru/threads/23521-elektronika-kr-04.html?p=719869&viewfull=1#post719869)

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

freddy, а можно ВТ57 так подключить, чтобы при чтении из области видеопамяти совместно с процессором он получал "черный снег" для ВГ75 и захват шины получался бы фиктивный? Т.е. сделать как в CGA или если хотите в ЮТ-88. Или это проще без ВТ57 сделать? Собрать его урезанный эмулятор на рассыпухе. Атмегу пока не рассматриваем чисто из спортивных соображений :)

[TomaTLAB]

Схема интересует, чтобы узнать как ставить в РК86 системный контроллер ВК28. А его можно как то не по букварю поставить?

Или это проще без ВТ57 сделать? Собрать его урезанный эмулятор на рассыпухе. Атмегу пока не рассматриваем чисто из спортивных соображений
Не сыпьте соль на раны :) У мня есть несколько мыслей, но они пока еще не оформились. "Целый процессор" тратить не интересно, поэтому пока меня почему то потянуло в сторону микропрограммного автомата (читай - FSM) на пзушке и регистре.

[freddy]

Видел только фотографию печатной платы КР-04, а его схемы не нашёл. Схема интересует, чтобы узнать как ставить в РК86 системный контроллер ВК28.
Насчет этого не стоит беспокоиться. Его не возможно как то по-другому включить

а можно ВТ57 так подключить, чтобы при чтении из области видеопамяти совместно с процессором он получал "черный снег" для ВГ75 и захват шины получался бы фиктивный? Т.е. сделать как в CGA или если хотите в ЮТ-88. Или это проще без ВТ57 сделать? Собрать его урезанный эмулятор на рассыпухе. Атмегу пока не рассматриваем чисто из спортивных соображений
Вы смотрели схему графического режима, которую я выкладывал выше. Я ее и раньше сюда выкладывал, только никто не замечает, что Там же все реализовано. Используется отложенная запись со стороны процессора и штатная работа ВГ75. Половина CCLK отдана ВГ75 на выбор символа, а вот в течении другой половины шина памяти отдана вот тому цифровому автоматику, который выставляет адрес и пишет данные из буфера ( 3 регистра ИР82 (три, Карл), на схеме их нет, они были изображены в схеме видеокарты) в видеопамять.
В итоге никто не мешает друг дгугу. И черного снега не выпадает :) Так вот в случае ВТ57 я бы на Вашем месте подумал о ее торможении в момент записи со стороны процессора. Опять же чтобы не было черного снега :)

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

Тормозить ее можно, тормоз типо 8080 еще не скоро сможет очередной байт послать, ВТ57 наверстает упущенное :)

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

ну или... чтоб огород не городить, заведите видеобуфер на удвоенной частоте, половину отдайте ВТ57.

[barsik]

Насчет схемы включения ВК28 не стоит беспокоиться. Его невозможно как то по-другому включить

Да, как бы не так. Я в начале 90-х столкнулся с тем, что в РК86 КР580 плохо турбируется. А имея опыт, установки ВК28 в СПЕЦИАЛИСТ, где это помогло разогнать КР580 до 3.75 МГЦ, решил и в РК86 поставить ВК28.

Сделал акуратную платку переходник. На крошечной платке установил ВК28 и КР580, а снизу припаял штырьки отломанные от дохлых 27256, чтобы вся конструкция втыкалась в панельку КР580 вместо него. И бац... резко обломился.

РК86 не обычный компьютер, здесь обычные мерки не годятся. Сколько ни бился, так и не заработало, хотя когда втыкаешь эту же платку в СПЕЦИАЛИСТ, всё работает без проблем. Эту платку КР580+ВК28 имею до сих пор (могу сфотографировать), но как заставить её работать на РК86, не знаю. Некоторые люди уже установили ВК28 на РК86, но подло скрывают эту ценную информацию от народа.

[freddy]

Xrust, смотрите даташит Intel на i8257, особое внимание обратите на сигнал HLDA и у Вас появится улыбка :)
Все оказывается проще :)

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

Смысл такой: процессор произвел запись в буферные регистры. От его сигнала $WR$ тормозится ВТ57, заканчивая текущий цикл. Как затормозится, переключаем шины видеобуфера к буферным регистрам и в этом же такте производим запись. В следующем такте отдаем шину назад ВТ57 и в этом же такте ее растормаживаем. Усе! Радуемся!

[freddy]

Решил я попробовать разжевать написанное выше. Вот зарисовал.
61210
Это для тех кому количество корпусов не имеет значения. Схемка немного упрощена, на ней всего лишь показано формирование сигнала записи в видеобуфер. В чем же она упрощена будет потом. А сейчас опишу процесс. И так, проц решил записать. Не важно как, в материнке будет сформирован сигнал записи в видеокарту ~VB_WR (из каких-то адресов и самого WR). Адрес и данные защелкнулись в U22-U24. Триггер U16A сработает по заднему фронту. Таким образом, кроме запоминания сигнала записи, избавились от проблемы с его шириной. На входе D U16B появится 1. Однако, предположим что в этот момент ВТ57 во всю пересылает байты в BURST режиме ВГ75-м. Записи не произойдет так как триггер U16B будет удерживаться сигналом захвата шины ~BSEN Поэтому мы с выхода ~Q U16A начинаем тормозить ВТ57. Как только она тормознет, отпустит шину и запись 1 в триггер U16B произойдет. Сформируется сигнал записи в видеобуфер ~MW. При этом неактивный сигнал занятости внутренней шины, включит выходы U22-U24 и все получится. Синхронно с CCLK сигнал ~MW через U17A сбросит U16А, который отпустит ВТ57. Она сново захватит шину и продолжит...
Схемка упрощена. Тута показано только формирование записи в видеобуфер. А еще нужно писать в ВГ75 и ВТ57. Ну хотя бы писать. При этом они на внутренней шине и нужно для них дешифратор адресав внутренней шины для записи в регистры. Вот это сами дорисуйте. А то слишком легко все получается :)

[Error404]

Вот этот вариант наверное самый красивый с точки зрения олдфила: проц компа (на плате VGA никакого проца не ставим) только пишет в буфер на плате видеокарты (читать видео-буфер ему не надо т.к. запись дублируется и в собственном ОЗУ компа т.к. плата в адресном пространстве, при надобности можно оттуда прочитать), ВТ57 и две ВГ75 (256 символов + цвет) выводят этот буфер на VGA. Все остальное (переключаемые фонты, множественные экранные плоскости и т.п.) легко каждый сделает по вкусу, т.к. для такого варианта всё это дополнительное может быть сделано сугубо аппаратно.

[freddy]

Выкладываю инициализацию видеогенератора, чтобы могли переделать под любой проц. После выполнения этой последовательности, появится картинка и курсор, нужно срочно стартовать DMA.

vg75_ini: clr r16
rcall vg75_cmd
ldi r16,79
rcall vg75_dat
ldi r16,0b10011000
rcall vg75_dat
ldi r16,0x0F
rcall vg75_dat
ldi r16,0b00011001
rcall vg75_dat
cli
ldi r16,0b00101111
rcall vg75_cmd

cbi PORTA,vg75_cs ;Wait screen start
sbi PORTA,vg75_a0
out DDRC,zero
cbi PORTA,vg75_rd
nop
nop
nop
nop
sbi PORTA,vg75_rd
vg75_ini1: nop
nop
nop
cbi PORTA,vg75_rd
nop
nop
nop
nop
in r16,PINC
sbi PORTA,vg75_rd
sbrs r16,5
rjmp vg75_ini1
sbi PORTA,vg75_cs
cbi PORTA,vg75_a0
ldi r16,0xFF
out DDRC,r16
sei
ret

[freddy]

Там есть ожидание конца экрана, требующее операции чтения из ВГ75. Если DMA стартовать сразу же после команды инициализации ВГ75, то можно не ждать, так как ВГ-шка начинает всегда сначала. И обойтись только записью.

[TomaTLAB]

А почему нельзя запустить ПДП перед инитом ВГшки? Я где-то, что-то прощелкал и недопонимаю?
Надо все ж разгрести стол будет и собрать макет, живьем понюхать.

[freddy]

Соберите макет, и лучше на печатной плате.


А почему нельзя запустить ПДП перед инитом ВГшки?
Попробуйте. Нигде не говориться что нельзя :)

[Xrust]

freddy, я правильно понял, что представленная на предыдущей странице схема рассчитана на то, что запись в видеопамять из регистра должна успеть произойти между циклами записи процессора? Если же процессор будет слишком быстрый или запись будет производиться, например, контроллером ПДП материнки, то информация просто пропадет. По идее, такую ситуацию можно избежать, если предусмотреть торможение процессора или другого устройства, пока видеокарта не будет готова принять очередную порцию данных, верно?

[freddy]

freddy, я правильно понял, что представленная на предыдущей странице схема рассчитана на то, что запись в видеопамять из регистра должна успеть произойти между циклами записи процессора?
Правильно.

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

[freddy]

Xrust, Какой процессор будет? И сколько МГц?

[TomaTLAB]

Только если процессор тормозить Wait'ом придется схему отложенной записи переделать. ТМ-ка то сейчас по заднему фронту срабатывает, когда для процессора поезд уже ушел. Хотя затянется следующая операция, а она не может же быть записью в видео буфер. Или может? Но все равно как-то некрасиво.
Для чтения опять же нужно передний фронт уже ~VB_RD вылавливать. Вопрос, только, зачем текстовый экран может понадобиться читать? Но для красоты можно сделать. Подозреваю, что для этого дела АП10 (646) должна хорошо зайти в качестве буфера данных.

[Xrust]

freddy, предполагается, что процессор можно поставить практически любой, по вкусу, начиная от кр580вм80а@2.8МГц :)

[TomaTLAB]

Хмм... А чем черевато если на clk U16:A подать инвертированный сигнал записи(чтения), HLDA завести на WAIT проца, а вместо регистров U22...24 поставить буфера для изоляции шин?
И возможно мультиплексоры/буферные эл-ты для разгребстись с CS/RD/WR'ами...

[freddy]

Xrust, Под любой процессор нужно предусмотреть сигнал готовности READY с выхода триггера U16A. Если под тот с которого "начиная", тогда ничего не надо.

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

TomaTLAB Зачем вы так упорото пытаетесь тормозить процессор? Он и так пишет очень медленно по сравнению с CCLK.
Приведите пример пересылки одной области памяти в другую и посчитайте такты.
Может тогда я смогу помочь чем то.

[TomaTLAB]

Да, я пока не пытаюсь :) Просто рассматриваю разные варианты, пока чисто умозрительно. Можно конечно, для себя "на бумажке", но когда пишешь на форуме - глядишь кто мыслю умную подкинет, да и сам когда перечитываешь иногда видишь, что глупость сморозил :)
Вот у тов. Xrust'а, насколько я понимаю, проект в той же примерно стадии мозгового переваривания. Мне диапазон процессоров видится от ВМ80А до Z84C0020 как супер-мега-турбо вариант :)

[freddy]

Ясно. Вот пример вывода сообщения с адресом [HL] в экранный буфер с адреса [DE], конец сообщения обозначен как обычно 0.
rep: mov A,M
cpi 0
rz
stax D
inx H
inx D
jmp rep
Итого имеем 7+7+5(если не 0)+7+5+5+10=46тактов на один байт.
Отложенная запись сработает в самом худшем случае на 5-том такте CCLK после записи в видеокарту. К стати, кто знает почему не позже 5 такта, подскажите?
Итого, если процессор будет работать на CCLK (~3,2Мгц), то в худшем случае видеокарта работает быстрее в 10 раз, в лучшем в 20-30раз.
Z80@20Мгц выглядит тормозом.



глядишь кто мыслю умную подкинет
Подкидываю. Учите кунг-фу, т.е. ассемблер, потом в жизни легче станет.
И еще одна. Видеокарта - это не для новичков, хоть тема и находится в разделе для начинающих.

[TomaTLAB]

К стати, кто знает почему не позже 5 такта, На цикл ПДП 4 такта - отсюда ноги?
Ассемблер я знаю 51-й, AVR и 8080, Z80 поверхностно, правда лет 10 на асме не писал, кроме мелких процедур (прерывания обычно) для МК. Вот сейчас со скрипом вспоминаю :)
Если у ВГ-шки интервал между burst'ами установлен в 0 она так и будет DRQ держать активным пока все не выгребет?

[Vladimir_S]

freddy, Зачем лишний байт убивать?

[freddy]

На цикл ПДП 4 такта - отсюда ноги?
Верно. Если запись со стороны процессора придет в момент начала цикла, то на 5-м такте гарантировано произойдет отложенная запись. Это худший случай.
А еще будут случаи, когда ВТ57 вобще не активен, тогда на 1-м такте и будет запись :)

Vladimir_S, Это был пример для наглядности.

[Vladimir_S]

Это был пример для наглядности.
Я понял, но как то нервно отношусь к такому. Стараюсь минимизировать код.

[freddy]

Если у ВГ-шки интервал между burst'ами установлен в 0 она так и будет DRQ держать активным пока все не выгребет?
да

[Vadim]

Мне вот интересно, схема то видео карты когда будет? Мне бы хотелось такое подключить на Профик, ВГ 75 текствый экран крутой, здорово. 19 страниц обсуждения и всё схем нет.

[TomaTLAB]

Vadim, Вам на блюдечке? :) Базовых схем уже вагон и маленькая тележка. Выбирайте, компонуйте, обвязывайте под свою любимую платформу.
Мое мнение, конечно, но тема как раз развивается так как надо, т.е. без конкретных привязок к архитектуре даже самой видеокарты.
Объем и распределение памяти, диапазоны адресов в платформе, количество цветов и фломастеров - все можно выбрать на свой вкус :)

[Vadim]

Vadim, Вам на блюдечке?
Ну тут как-то всё в виде концепций. Схему сделать ведь не так просто, работающую.

[freddy]

Vadim, Я сейчас занят видеотерминалом на 2xВГ75. Пока только печатка готова. Как закончу, то видеокарту буду делать уже на базе нового видеогенератора. Так как, вариант без интеллекта на борту сможет с таким видеогенератором лучше работать. И, действительно, здесь не будет привязки к конкретной архитектуре.

Схему сделать ведь не так просто, работающую.
Да ладно? Все просто, времени вот мало. В этой ветке родился вполне качественный, рабочий видеотерминал. Это уже не плохо для ВГ75.
Новый будет еще и с скоростным портом... В общем тема движется понемногу.

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

К стати видеокарту можете сами построить какую надо. Видеогенератор здесь нарисован, кусок интерфейса тоже. Можете сами дорисовать остальное, я специально оставил поле для творчества

[TomaTLAB]

...я специально оставил поле для творчества И это правильно!:v2_thumb: А то как готовое, так критиков понабежит, успевай отмахиваться :)

У меня теперь вопрос по ВТ57 назрел. У нее же счетчики тупые? Если начальный адрес указать под самой верхушкой и размер блока для автозагрузки будет больше чем остаток до верхушки - начнет с нулевого адреса грести? То есть можно циклический аппаратный ролик по всем 64к сделать?

[Vadim]

Да ладно? Все просто, времени вот мало. В этой ветке родился вполне качественный, рабочий видеотерминал. Это уже не плохо для ВГ75.
Новый будет еще и с скоростным портом... В общем тема движется понемногу.
Я когда-то занимался схемотехникой, но сейчас времени нет. Даже готовую плату спаять и то время надо искать. Это раз. Потом отладка, нужно что бы всё было как говорится "на мази", что бы у нас была макетка, где мы быстро схему собрали, и отладили. Задержки распространения и прочее ведь вносят свою нехорошую лепту. Сколько есть клонов 8-и бит машин, чаще спектрум совместимых, которые работают плохо. Почему? Потому что плохо схема сделана. Без учета задержек, без компенсаций. При 3,5Мгц оно вроде как то ещё работает, а повышаем частоту до 7-8 или 10-12 Мгц и всё, вся схема разъехалась, глючит и тупит. Конечно к данной теме это мало относится, но всё же. Меня конкретно интересует схема на ВГ75 с отображением видеобуфера на ОЗУ. Так, как это сделано на ПЦ. Ставим карту в комп. У нас есть поты определенные, к которым подключены регистры. Когда нам надо, подключили ОЗУ карты в адресное пространство Z80. Сделали запись или перемещение, отключили. На такой карте можно будет организовать видеовывод в системе CP/M и писать под него демки. Выход на VGA при этом очень и очень замечателен. (конфликт с ОЗУ компа разрешается маппером, давно уж я продумал простую логическую схему на 4 окна, когда мы задаем для каждого окна в 16К его режим. Один байт хранит режимы для всех 4-х окон. По 2 бита на окно, 4 состояния 0 - маппинг как без схемы маппера, 1 - подключаем ОЗУ, 2 - подключаем ПЗУ, 3 - ничего не подлюкчаем вообще - как раз для ОЗУ/ПЗУ внешних устройств - красиво и просто.)

[Xrust]

У нее же счетчики тупые?
Они вроде еще и короткие, не более 16к, если я правильно вашу мысль понял.

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

Vadim, я примерно так для себя задачу и сформулировал. Спроектировать универсальную систему для CP/M с возможностью установки любого совместимого процессора. Для этого и разрабатываю сейчас универсальную видеокарту, которая сможет текстовые режимы 80x25 и простую графику низкого разрешения. При чем выводить все это она должна на VGA.

[freddy]

В CP/M вобще не предусмотрено наличие видеокарты. Ему нужен видеотерминал, так он уже есть.


То есть можно циклический аппаратный ролик по всем 64к сделать?
Можно. У нас будет режим работы с автозагрузкой канала 2. Поэтому перепрограммированием начального адреса в канале 3 можно получить аппаратный вертикальный скроллинг.



Меня конкретно интересует схема на ВГ75 с отображением видеобуфера на ОЗУ. Так, как это сделано на ПЦ.
Так прикрутите DMA к видеогенератору на 2хВГ75. Будет Вам и VGA и 8 цветов фона и 8 цветов символа и 80х25 и 256 буковок красивых 8х16.
DMA прикручивается в стандартном включении, как в букваре Intel. Подойдет как ВТ57, так и ВТ37.
Видеокарту я решил пока не разводить. У меня все консольное, что Debian, что Free BSD, что CP/M и, даже, мой модем US Robotics Courier, все хотят видеотерминал VT100. Вот и все, на memory mapped style было забито за ненадобностью. Зато будет высокоскоростной порт, на нем будет командный процессор и клавиатура, так же как и RS232, только без физического RS232. В качестве умной видеокарты в самый раз :)

[TomaTLAB]

Они вроде еще и короткие, не более 16к, если я правильно вашу мысль понял.
А для текста и этого много. Если я не ошибаюсь, там не счетчики короткие, а регистр (счетчик) размера блока 14 бит. (У 37-го 16?)
Адресный счетчик по идее должен быть 16 бит, и если его не остановить или не перезагрузить, то он так и будет по кругу гонять.
В даташите нихрена не видно, но на 16 больше похоже чем на 14 :) и вообще я только какой то куцый на 7 листочков смог найти.

[Xrust]

freddy, ну и что, что не предусмотрено? Драйвер можно написать. Есть же даже графическая библиотека для cp/m. Правда я сомневаюсь, что ей кто-то реально пользовался.
Я представляю себе примерно "прелести" cp/m, поэтому и хочу, чтобы возможностей было больше, чем дает голая система.

TomaTLAB, а какже тогда "по всем 64к"?

[freddy]

Я представляю себе примерно "прелести" cp/m, поэтому и хочу, чтобы возможностей было больше, чем дает голая система.
Так напишите свою операционную систему, которая дас больше чем CP/M.


freddy, ну и что, что не предусмотрено? Драйвер можно написать.
Ух ты! Что конкретно должен делать этот драйвер? Напишите пожалуйста откуда и что он будет брать, что с этим сделает и куда потом положит.

[Xrust]

freddy
1. Ага, только сперва поужинаю :)
2. Эмулировать работу терминала, что же еще?

[TomaTLAB]

а какже тогда "по всем 64к"? Я неудачно выразился, быть может. У нас текстовое окно для отображения всего 2000 байт (4000 с цветом).
А размер блока ПДП может быть 16к, оно столько за раз не надо - спейсаффекты будут :) И вот это самое окно мы можем гонять вперед-назад по всем 64к.
Если кратно 80 (160) - будет построчный скролл.

Только когда оно промеж страниц маппера приедет, будет процессору работы - этим самым маппером щелкать, если приспичит в рандомные области экрана писать.

[TomaTLAB]

Так, все... До меня наконец дошло. :) Как то я прощелкал на третьей странице темы сообщение про отложенное чтение.
Таки да, красиво и ничего тормозить не нужно. Чем то обмен по SPI напоминает. Ну разве что, не очень удобно для операций чтение-модификация-запись.

[Xrust]

Ну разве что, не очень удобно для операций чтение-модификация-запись.
Почему неудобно? Чтение ведь из системной оперативки будет, а не из видеопамяти. А запись в обе.

[TomaTLAB]

Это если видеопамять однозначно на системную отображать, то да.
Но если и той и другой будет изрядное количество и их раздербанить мапперами (как в MSX, а не простой переключалкой страниц) то чую будут нюансы :)
Впрочем, если добавить пару буферов отдельно для адреса чтения то будет проще.

[OrionExt]

Тема не раскрыта, есть некий контроллер АVR. И куча идей. Теперь конкретно. Будет схема в первом посте. Хотя бы – пишем в порт (AVR) видео-контролера на ВГ75.

И какие времянки допустимы (нужна диаграмма)

Сори. Терминал по RS не в счет.

[Xrust]

TomaTLAB, а кстати, как решался вопрос с маппингом памяти в CP/M 3.0?

[OrionExt]

Да никак=) с мапингом. Уважаемый Xrust. Делайте уже машинку в минимальной обвязке CP/M, а то так теорию еще можно 10 лет решать.

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

СР/М3 чего то там мепит. Z180 чего та там мепит, кому это уже было нужно? А жаль(

[Xrust]

OrionExt, да делаю. Но так как времени и опыта мало, делаю неспешно, растягивая удовольствие :)

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


СР/М3 чего то там мепит.(
Вот это и интересует. Хотелось бы в перспективе совместимость обеспечить.

[TomaTLAB]

а кстати, как решался вопрос с маппингом памяти в CP/M 3.0?
Это, наверно, скорее к barsik'у вопрос. И вообще это стоит обсудить в соседней ветке, я там как раз про маппер вопрос задавал, но его похоже не заметили :)

[barsik]

а кстати, как решался вопрос с маппингом памяти в CP/M 3.0?
Это, наверно, скорее к barsik'у вопрос

Увы, ничем не могу помочь. Я о CP/M 3.0 ничего не знаю (кроме того, что прочитал в книге Уэйт,Ангермейер "Операционная система CP/M").

Хотел её поиметь в начале 90-тых, но нЕгде было взять. Даже МИКРОДОС достать не смог, хотя она и была на "Векторе-06Ц". Саму CP/M 3.0 я увидел и смог скачать ДОК-и о ней только недавно. Да и то, не из практического интереса, а лишь из любопытства. Сейчас это уже никого не интересует. Уж лучше разобраться в ZCPR для CP/M 2.2 (собственно ZCPR исходно сделана для CP/M 3.0, но один чувак в середине 80-тых сделал её усечённую версию и для CP/M 2.2).

Я, как и многие на этом сайте, "возился" только с CP/M 2.2, т.е CP/M без дат файлов и многобанковости. Я даже не знаю на какой из отечественных ЭВМ использовали CP/M 3.0, но кажется это было на каком-то из клонов Spectrum-128 с большим ОЗУ. Так что абсолютно не знаю, коммутируется там память цельно-банково или в каком-либо окне и какие функции управления памятью там встроены в ДОС.

Кажется, error404 интересовался этим вопросом, и кажется его ДОС поддерживает многобанкоовость. В принципе, многобанковость особо и не нужна, т.к буквально единицы компиляторов могут генерить код для многобанковой архитектуры. А программ, использующих многобанковость наверное ещё меньше...

Так что CP/M 3.0 имеет смысл только потому, что там работает ZCPR и есть даты у файлов. В 1997 я для себя сделал CP/M с датами файлов, причём, в отличие от Digital Reserch совместимо. Они ввели даты прямо в каталог CP/M, отчего формат каталоговой записи изменился и совместимость пропала. А я ввёл дополнительный каталог для дат и расположил его на том же треке, где основной каталог, пользуясь тем, что дисковод двухсторонний, причём не в области файлов, а в области системных треков. Тогда для считывания каталога с датами не требуется делать шаг головки, что фактически не тормозит. Причём не пришлось менять даже код BDOS CP/M 2.2, изменение в оригинале лишь 2 байта ! Я ввёл в код BDOS две доп.функции для управления датой (номера взял как раз из CP/M 3.0) и ввёл перехват на входе в BDOS (кусок доп.кода BDOS разместил в BIOS). Достаточно было перехватывать лишь несколько функций BDOS. Для этого в начале кода BDOS, где стоит команда JP BDOS1 я ввёл заплатку, поставив JP CHKCAL на программу в теле BIOS, где проверялось какая функция BDOS вызвана.


CHKCAL:
LD (TMPA),A
LD A,C
CP 069H
JR Z,WRDATE
CP FMAKE
JR Z,XMAKE
CP FCLOSE
JR Z,XCLOSE
CP FRENAM
JR Z,XRENAM
CP 68H
JP Z,RDDATE
defb 3EH
TMPA: DS 1
JP BDOS1 ; переход на стандартный вход в BDOS


При создании файла создавалась не только каталоговая запись, но и каталоговая запись в каталоге дат файлов. Причём каталог дат был организован синхронно с основным каталогом. Тогда функция поиска файла выдает позицию каталоговой записи в основном каталоге и одновременно это же позиция и в каталоге дат (только на другой дорожке). Так что менять даты у файлов функциями BDOS было удобно. Текущая дата ставилась при CREATE, RENAME и CLOSE файла открытого на запись. Получилось предельно просто и эффективно. Потратил на введение дат всего пару дней труда. Доп.кода было (удивитесь) всего 180 строк кода в исходнике CP/M-BIOS. Плюс пришлось написать пару внешних утилит для управления датами и переделать CCP, чтобы каталог выдавался с датами.

Ещё более просто вводятся имена для юзеров. Для этого даже вообще не надо менять ДОС. Просто храним имена юзеров в BOOT-секторе, где это может читать и писать соответствующий нортон. Читал описание какого-то нортона для КОРВЕТА, где тоже были имена для юзеров, но хранимые в отдельном файле USERS.SYS, что не меняет сути.

Если всё что даёт CP/M 3.0 можно реализовать парой сотен строк ассемблера, то на кой хрен нужна CP/M 3.0, что тогда имеет смысл только для многобанковых систем и использования многобанковых компиляторов.

[Xrust]

barsik, поскольку cp/m однозадачна на 100%, то я думаю, переключение страниц памяти можно в нее так же легко добавить.

[barsik]

думаю, переключение страниц памяти можно в нее так же легко добавить
Конечно ввести в BDOS функцию переключения всего ОЗУ до уровня BDOS совсем просто. Но сначала надо понять для чего это надо.

Если наличие доп.банок в ДОС использовать только для данных (не для кода ПО), то это ничем не отличается от ОРИОНА с кучей банок ОЗУ, в котором доп.банки истрачены не на VDISK, а свободны для хранения оперативных данных программ. Например текстовый редактор загружает в ОЗУ излишних банок весь текстовый файл с размером превышающим TPA (минус код редактора), избавляясь тем самым от необходимости дискового свопинга, что существенно ускоряет и сокращает износ дисковода и дискет. Но кто будет сейчас писать такой редактор или иные программы с обработкой больших данных в иных банках? К тому же и без таких наворотов, для обычного TPA в 48 кб уже написан редактор SuperText, в оригинале называемый 'Final Word', и это действительно оказалось "последнее слово", т.к за прошедшие 35 лет никто лучше не сделал.

Если использовать доп.банки, управлямые ДОС, для кодов программ, то где брать такие программы? У программ на ассемблере объём небольшой, тут нет необходимости вводить XTPA в других банках. А чтобы получить гигантские программы написанные на ЯВУ, которые раскидывают свой исполняемый код по всем банкам, надо иметь соответствующий компилятор.

Гораздо умнее использовать одну доп.банку ОЗУ иначе, перегрузив в неё исполняемую часть кода DOS, а именно CCP и BDOS. Так и реализуют версии CP/M, у которых вершина TPA достигает FF00. И так сделано не только в эмуляторе Z80MU, написанном Joan Riff, но и на реальных машинах 80-х годов. Это позволяет прогонять программы размером в 63,7 кб. Укажите на того, кто написал программу большего размера.

Таким образом достаточно иметь архитектуру ОРИОНА с 3-мя банками ОЗУ. Первая банка - банка CP/M, где только ZERO-page в области 0...100 и вход в BDOS в самой-самой вершине ОЗУ. Вторая банка содержит исполнительную часть кодов самой ДОС, драйверов и TSR-программ на прерываниях. И третья банка - это просто ОЗУ для данных, размером в 64 кб. Что очень полезно для графического интерфейса с окнами, чтобы сохранять там содержимое открытых окон и не мучиться, как сейчас, тщетно надрываясь в попытке уместить код программы, дисковый буфер и буфер сохранения окон в крошечном TPA в 30 кб (имею ввиду ОРИОН в банке 0 в CP/M с графическим драйвером 10 кб).

Такая трёхбанковая ДОС может быть и многозадачной. Но не в общепринятом смысле, а быть ДОС с процессами на прерываниях. Т.е грамотно поддерживать работу мелких резидентных и загружаемых драйверов на прерываниях. При этом на входе INT Z80 такт 50 ГЦ и почти все периоды частоты 50 ГЦ прогоняется основная программа. Загруженные процессы получают управление каждый только на 1 период частоты 50 ГЦ, да и то, если процессу много не надо, не целиком. И тут возникает проблема придумать какие же резидентные программы (типа TSR) могут стать процессом. Понятно, что процессом может быть опрос клавиатуры (по получении кода, положить его в кольцевой буфер), печать на принтер в фоновом режиме, обслуживание апп.часов с выводом текущего времени на экран в любой программе и управление автодоилкой домашнего бегемотика.

Но всё это необязательно и серьёзного рассмотрения заслуживает только сам факт получения в CP/M максимально большого TPA. Это не сложно сделать и error404 уже сделал для ОРИОНА максимально большое TPA в своей ДОС, совместимой с CP/M.

Исходя из вышеизложенного в этих 2-х постах, разумно использовать CP/M 3.0 в небанковом варианте. Что без хлопот даёт даты у файлов, все навороты, что даёт ZCPR и возможность использовать ПО для CP/M 3.0, а его будет намного больше, чем для CP/M 2.2, т.к для CP/M 2.2 западные фирмы прекратили писать программы в 1982, а для CP/M 3.0 и MSX программы писали аж до конца 80-тых.

[Xrust]

barsik, полностью согласен с концепцией, вы просто словно мои смутные мысли упорядочили и грамотно озвучили.

[shattered]

Две ВГ75 используются в терминале МС6102. Для возможности вывода 256 символов скорее всего. Нужно искать его схему и смотреть. Насколько я помню, они могут легко синхронизироваться друг с другом. Судя по всему, число сигналов атрибутов удвоится тоже.

А вот и схемы -- https://goo.gl/photos/xJManS26QTxG1T7M7 (via http://zx-pk.ru/threads/9276-skhemy-i-dokumentatsiya-na-otechestvennye-kompyutery-i-komplektuyushchie.html?p=901928&)

Как именно они работают вместе, пока не вникал.

[freddy]

Ай, яй, яй! :v2_scare:Им не хватало атрибутов, ЗГ переключается на лету. Схему понять осложняет опечатки или намеренные ошибки. Например с вывода СГИ(7) второй ВГ75(DD56) выходит сигнал 84 в шину, куда дальше идет не понятно. А еще желательно посмотреть мануал, ибо нужно знать, что пользователь должен был запрограммировать в РТ5(DD69) , перед ее установкой.
Пока вижу что КГАМ, автору терминала привет. Что пил? Тоже самое можно было сделать куда проще и без переключения ЗГ. Я имею ввиду видеогенератор, там много лишних деталей :v2_lol: Зато сделали аппаратные линии в ВГ75, это конечно хорошо, таблицы можно рисовать атрибутами.
Такой терминал есть у Сергея Фролова. Дамп DD64 был бы очень интересен. Нравится мне история заблуждений и ошибок в советской технике.
Схема этого терминала представляет не малую историческую ценность, еще бы мануал...

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

К стати нет там 256 символов. И он не совместим с VT100 или ASCII. И аппаратные линии сделали по этой же причине :)
Вот взгляните на его знакогенератор и сами все поймете http://bunkerkom.lv/retrofonts
Короче терминал представляет исключительно историческую ценность.

[shattered]

Все прошивки (кроме DD69 -- ее могло и не быть) -- http://www.bunkerkom.lv/rom/MC6102.02_rom.rar (via http://www.phantom.sannata.ru/forum/index.php?t=24124)

Я потихоньку расковырял карту памяти по схеме, но эмулятор прошивки (в MAME) толком пока не заработал.

Карта памяти:

0000h..2FFFh - ROM
3800h..3BFFh - EEPROM (К1601РР1 aka ER2401)
C000h..FFFFh - RAM

Карта портов:

00-01 - 580ВВ51 aka i8251 (UART линии)
10-18 - 580ВТ57 aka i8257 (DMA)
20-23 - 580ВИ53 aka i8253 (таймер)
30-3F - 581ВА1А aka TR1602A aka AY-3-1013 (UART клавиатуры МС7002)
40-41 - 580ВГ75 aka i8275 (2шт включены параллельно)
50-5F - ???
60-6F - 589ИК14 aka i8214 (контроллер прерываний)
70-7F - защелка клавиатуры и пр.
80-BF - устройства на шине

[A_AVL]

Запустил тут VGA терминал от freddy.
Поддерживает аттрибуты мерцания, подчёркивания, и восемь цветов.
Пока запустил по RS-232, в планах - сделать доступ по I/O шине.
Плата - 100х100мм, шина/RS232 с одной ее стороны, клавиатура/питание/VGA - с другой.
Схема тут:http://zx-pk.ru/threads/26455-chto-maksimum-mozhno-vyzhat-iz-kr580vg75-intel-8275-obsuzhdenie.html?p=914280&viewfull=1#post914280
62444624456244662447

[freddy]

Посмотрел фото с монитора. Есть где то проблема с быстродействием компонентов.
Лагают строки. Посмотрите мою картинку, там возможно решение.
62448
Сейчас заглянул в справочник, так и есть, у РФ2-РФ5 время выборки адреса 450нс. Это всего 2,2Мгц для CCLK в пределе, что явно мало для нашего случая.
AT28C64B-15PU обещает в трое быстрее, что с запасом нас устраивает. Рекомендую флешки.

[Tronix]

Хм, круто. А чем мега занимается, кроме клавы и настройки вг? Если ее убрать, то можно эту схему в качестве видеоадаптера использовать с медленными старыми цпу?
Ps: платки лишней нет?

[TomaTLAB]

Мега занята мега важным делом "перетасовки" атрибутов для скармливания ВГшке.
Без меги можно на паре ВГшек и ВТшке сделать. Пару страниц назад обсуждалось.

[A_AVL]

Хм, круто. А чем мега занимается
Ps: платки лишней нет?
Вряд ли ее можно убрать без замены на что-то аналогичное. Мега обрабатывает запросы ПДП, динамически подсовывает атрибуты для ВГ75, обработка трибута мигания, похоже тоже ее рук дело.
Платы штуки 2-3 есть. Могу поделиться. Т.к. платы первой ревизии - есть пара некритичных косяков.
В принципе, устройство разрабатывалось и для использования с медленными старыми процессорами. Эмулирует VT100, Есть возможность обращения как по RS-232, так и по шине (пока не проверено, но на плате все разведено и в общем должно работать) (порт ввода, порт статуса и порт вывода с выходом прерывания)

[freddy]

Если ее убрать, то можно эту схему в качестве видеоадаптера использовать с медленными старыми цпу?
Ps: платки лишней нет?

Мегу конечно можно убрать, там нагрузка не большая. Экран 4000 байт, его нужно передавать 72 раза в секунду, анализируя байт атрибутов. Итого 288кб/сек + накладные расходы. Какой нибудь разогнаный z80 вполне справится.
Но с ATMega128 схема проще и габариты меньше и удобный отладчик...
Для тех кто хочет использовать этот видеогенератор как то по-своему, здесь приводились процедуры инициализации ВГ75 и обслуживания DMA.

[freddy]

Ps: платки лишней нет?
У меня появятся только через 2 недели. Заказал очередную партию, только у меня без параллельного порта, 130х100мм, из поста 158

[Tronix]

Блин, ну все-таки мега нужна получается, даже для паралельной... А тогда смысл теряется, к сожалению, ибо тогда проще взять голую мегу и на ней сделать все то же самое (вга терминал, ps/2, com). Палка о двух концах....

[ALS]

Может, и так, но... хоть какая-то утилизация целой пачки старых микросхем.
Как вариант, можно попробовать вместо Меги использовать что-то более винрарное, родом из 90-х

[TomaTLAB]

Господа, вы тему просматриваете, или только последнюю страницу?
Да, решения "на блюдечке" без меги тут нет, зато есть почти вся необходимая информация и наброски узлов для построения видео-подсистемы.
С прозрачной ("отложенной") записью в ОЗУ и почти таким же чтением. Да, нужна будет горсть-другая мелочи и регистров.
Подсистема чего это будет, компьютера, или терминала (хоть на 8008) особо не важно.
Осталось только немного напрячь извилины и можно сделать видеокарту со своими "шахматами и библиотекаршами" :)

[freddy]

Блин, ну все-таки мега нужна получается, даже для паралельной... А тогда смысл теряется, к сожалению, ибо тогда проще взять голую мегу и на ней сделать все то же самое (вга терминал, ps/2, com). Палка о двух концах....
Проще вобще ничего не делать. Есть уже готовый терминал на 8-ми ядерном чипе Paralax Propeller, он значительно проще и на Cи.
А лучше пользоваться софтовым, типа xterm.

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


Как вариант, можно попробовать вместо Меги использовать что-то более винрарное, родом из 90-х
Как запустить мой видеогенератор в посте 170 и что с ним делать в посте 131. Можно на любой процессор переписать.
Очень буду рад если кто то сделает не на ATMega128, а хоть на Z80.

[freddy]

Поделитесь шрифтом KOI8-R 8x16, только чтобы был красивый, bitmap-ный естественно.

[TomaTLAB]

http://savepic.net/10188143m.png (http://savepic.net/10188143.htm)
Уж не знаю, насколько красивый :)
По моему что-то стандартно-виндовое.
Еще пороюсь у себя, для TFT экранчиков как то искал.

Вообще нужно загружать в целевую железяку и смотреть как оно живьем будет выглядеть.
Очень уж по разному воспринимаются на разных экранах, сильно по разному...

[freddy]

Спасибо. Я уже переконвертировал собственный шрифт в KOI8-R, тот что сюда выкладывался, он всем хорош.
На фото у Вас кодовая страница не KOI8-R

[TomaTLAB]

А, ну да, точно виндовое. Ну, переконвертить не долго, больше проблема подобрать чтоб глаз радовало :)

[freddy]

Я написал по терминалу мурзилку, но выкладывать ее не захотел.
Потом почему то решил, что она может пригодится каким то другим "утилизаторам старых микросхем".
Также предполагаю, что некоторые даже не представляют, что он может.
Поэтому выложил, читайте, я по возможности перевел на русский.
Вот все в одном файле.
63166

Так выглядит фото финальной версии.
63164

Так выглядит setup.
63165

[freddy]

#ВГ75Может!
Здесь, несколькими страницами ранее, приводился пример нелепого применения двух ВГ75 в терминале МС6102. Меня такой ход инженерной мысли разочаровал и я раскритиковал его схему и авторов. Это все потому, что есть другой пример, в нем 2хВГ75 используются с умом. По просьбе одного уважаемого человека я его сейчас покажу.
64830
Этот двухголовый видеогенератор главным образом отличается от одноголового тем, что может дополнительно управлять 8 цветами фона и битом яркости символа. Т.е. доступны 16 цветов символа, 8 цветов фона, две кодовые страницы по 256 символов, которые можно применять в любых комбинациях без ограничений.
Это такой, своеобразный ответ VGA режиму 03H. CGA, MDA такой хорошей картинки не дают, я с ними не сравниваю.
Принципиальная схема на 2 микросхемы больше одноголового видеогенератора. Где то она уже выкладывалась. А вот и фото самого устройства.

64831

Сделано все на небольшой печатной платке, которая напаивается верхом на ВГ75. С основной платы демонтированы ТМ9 и ЛИ1.

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

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

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

То что я здесь показал, могли сделать еще в конце 70-х :)

[CodeMaster]

То что я здесь показал, могли сделать еще в конце 70-х

Сложно точно сказать по экономике этого проекта в 70-х, но это затормозило бы развитие ВТ, мы до сих пор сидели бы в суперцветастых текстовых терминалах ;-)

[freddy]

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

[TomaTLAB]

но это затормозило бы развитие ВТ, мы до сих пор сидели бы в суперцветастых текстовых терминалах
Это вряд ли. :) Их ведь было и цветных, и графических... ReGIS совместимые, какие там из VTшек? 240, 340? Все стухло к середине 90-х примерно.

[freddy]

ReGIS совместимые
Это что такое? Кто выпускал?


Все стухло к середине 90-х примерно.
Ага! А я то на работе думаю, откуда у меня такое deja vu, когда в консольке открываю 100500-й сеанс.
А это оказывается из-за того, что оно еще в 90-е стухло. Хорошо, что не вместе с админами и программистами :)

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

Есть ли надобность в варианте 2хВГ75? Есди да, то я готов развести печатную плату, подкорректировать схему и опубликовать с прошивкой.

[TomaTLAB]

Это что такое? Кто выпускал?
http://terminals-wiki.org/wiki/index.php/Category:ReGIS
Вон на "барахолке" типичный представитель выложен.
Обычно там в них всеми делами банальный 51-й заправлял. :)


Ага! А я то на работе думаю, откуда у меня такое deja vu, когда в консольке открываю 100500-й сеанс.
Вот-вот 100500 сеансов в консольке, а не на 100500 DEC-овских VT-шках :) Которые уже редкость музейная.

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


...реализовать даже их небольшую часть в рамках данной платформы уже не представляется возможным. Все ОЗУ микроконтроллера исчерпано.

Есть ли надобность в варианте 2хВГ75? Есди да, то я готов развести печатную плату, подкорректировать схему и опубликовать с прошивкой.
Напрашивается идея "перетасовать" ноги М128 под навеску внешней памяти.
Знакогенератор на SRAM и... ну, в принципе, VT-шка получится :) Только не со своей "трубой", а с VGA-выхлопом.

[freddy]

Вот-вот 100500 сеансов в консольке, а не на 100500 DEC-овских VT-шках Которые уже редкость музейная.
Был бы у меня оригинальный DEC, я бы на нем работал. А так работаю на 2-х самопальных и на PC-шном Zoc terminal.

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


Напрашивается идея "перетасовать" ноги М128 под навеску внешней памяти.
Знакогенератор на SRAM и... ну, в принципе, VT-шка получится Только не со своей "трубой", а с VGA-выхлопом.
Хм... что за VT-шка получится? Зачем терминалу знакогенератор на SRAM?

[TomaTLAB]

что за VT-шка получится?
Ну под какой парсер управляющих кодов написать тот и получится :v2_smile:

Зачем терминалу знакогенератор на SRAM? А как юзер-чарсет подгружать? VT-шки умели. :v2_wink2:
И кстати, плавный (попиксельный) ролик тоже. Правда не уверен, что он умел кроме как на кратно высоте символа проворачиваться.

[freddy]

Ну под какой парсер управляющих кодов написать тот и получится
Так написано уже под VT100, этого везде достаточно.

А как юзер-чарсет подгружать? VT-шки умели.
для чего перезагружать шрифт? VT100 не загружал. Мой шрифт достаточно красив. Если что не так, редактор шрифтов в помощь.

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


И кстати, плавный (попиксельный) ролик тоже.
Идея хорошая. Сделайте. ;)

[shattered]

#ВГ75Может!
Здесь, несколькими страницами ранее, приводился пример нелепого применения двух ВГ75 в терминале МС6102. Меня такой ход инженерной мысли разочаровал и я раскритиковал его схему и авторов. Это все потому, что есть другой пример, в нем 2хВГ75 используются с умом.

Подозреваю, что 6102 сделали настолько умно, насколько было надо, а в VT52, который он эмулирует, цветов не было. Зато есть NVRAM на 1024x4 бита (КР1601РР1, которая, к слову, не 100% клон своего аналога ER2401 - сигналы и распиновка отличаются, совпадает только разрядность и размер).

Если удастся расковырять протокол клавиатуры МС7002 (или появится ее схема с прошивкой) -- 6102 должен заработать в MAME, а пока он работает только на прием:

https://img-fotki.yandex.ru/get/1001581/264743.8/0_b7c41_cc81cf47_orig.png (https://fotki.yandex.ru/next/users/shattered/album/137130/view/752705)

[Titus]

В каких отечественных машинках применялось сразу два ВГ75?

[freddy]

Подозреваю, что 6102 сделали настолько умно, насколько было надо
Если буквально воспринимать, то да. Сделали, как могли, чтобы выполнить техническое задание.
Если же немного помыслить творчески, то можно было сделать все тоже самое, только хорошо, без утилизации ведра микросхем.
А так имеем избыточность логики и раздутую схему, такое впечатление, что делали, чтобы показать проделанную огромную работу :)
А еще пристроить определенные типы микросхем :) Может их заставили так сделать? Тогда я понимаю... В 90-е сам в такие тиски попадал. Номенклатуру радиокомпонентов спускали сверху из планового отдела. И приходилось городить огромные лапти на ЛА3 :)



В каких отечественных машинках применялось сразу два ВГ75?
В МС6102. В МЦПГ от "Партнера 01.01". Там одновременно работали ВГ75 в самом компьютере и в МЦПГ.

[Titus]

Как именно работали? Что такое МЦПГ?

[freddy]

Работали суммированием видеосигнала. Изображение МЦПГ (цветной псевдографический модуль) накладывалось на изображение видеоконтроллера самого компьютера.
Сам МЦПГ имел два набора по 128 символов 8х4 с форматом экрана 64х25 знакомест. Наборы были загружаемые, ОЗУ знакогенератора 4кб на двух РУ10. Можно было туда загрузить чего-нибуь и пользоваться как спрайтами, но с перемещением не по пикселям, а по знакоместам. Вот и все. Было топорно, уныло, но работало.
Смотрите демо https://www.youtube.com/watch?v=v3h3a-ZA_FI

[Xrust]

Было топорно, уныло, но работало.
И весьма быстро. На спеке кмк гораздо унылее.

[bigral]

И весьма быстро. На спеке кмк гораздо унылее.

На то они и "tiles", чтобы процессор при занесении в видеопамять сразу рисовал "квадратики" с кучей точек (а не как на спеке 8 пикселов). Но как показала практика (atari800,с64,msx2+,sms,smd,nes,snes) для полного счастья еще нужно: 1. сдвиг позиции высвечивания тайлов по X,Y; 2. спрайты; 3. прерывания в любой строке растра; в принципе плата с десятком ВГ75 может и такое дело наверно показать...

[TomaTLAB]

...в принципе плата с десятком ВГ75 может и такое дело наверно показать...

Может и поменьше нужно будет.
А вот ВТ57-х наверно точно больше одной нужно будет : )

Отправлено с моего Ixion XL145 Snatch через Tapatalk
Вот, блин, порнография... Так, вроде нашел как отключить.

[freddy]

Где можно посмотреть, как устроено спрайтовое железо?

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

Мне очень интересно как происходит рендеринг картинки, какие функциональные блоки используются?

[bigral]

Где можно посмотреть, как устроено спрайтовое железо?
Мне очень интересно как происходит рендеринг картинки, какие функциональные блоки используются?

ГЫ!!!

Вот он человек который мне поможет запилить "народный" спрайтовый движек!
Короче и я долго думал как бы его вникнуть в эти всякие tms9918 или antic\gtia внутренности.
На "наших" форумах задавал вопрос и сделал вывод что "те кто знают" молчат, а другим не интересно.

НО:

1. есть пално схем аркадных игровых автоматов на archive.org;
2. есть HDL модели для atari\c64\tsconf\retroleum\msx\magnavox2 ... и т.д.;
3. есть теория выведенная из reverse engeneering-а NES PPU;
4. есть схема ПК8002 ЭЛЬФ! с которой еще никто не разобрался...

... короче, насамделе много чего есть.

Судя по тому что я уже накопал, типичный sprite engine работает так:

1. Есть основной "экран", в который входят: 2 счетчика "точек". Ну это один горизонтальный (H),
другой вертикальный (V). Потом есть компараторы интервала типа "от..до", генерирующие на основе данных
из счетчиков сигналы типа: гашение (blank), бордюр (show_screen\show_border), синхронизация (h_sync, v_sync...), счетчики адреса в экранной памяти (это так называемый MAP RAM, где обычно хранятся номера тайлов которые сейчас высвечиваются, в ВГ75 это двойной буфер на 80 тайлов). MAP RAM генерирует старшую часть адреса для TILE RAM\ROM, в котором хранятся сами тайлы (ну типа как знакогенератор в РК86). Ну а младшую часть адреса генерирует счетчик так или иначе связанный с (V) счетчиком. Далее latch и сдвиговый регистр. С его выхода сигналы идут на мега-MUX, который смешивает изображение идущее от "бордюра", "экрана" и КАЖДОГО из "спрайтов" (этот MUX учитывает приоритет высвечивания, так что можно показать тайлы поверх спрайтов или спрайты поверх тайлов, и спрайты между собой тоже накладываются по приоритету).

2. На каждый спрайт есть схема схожая со схемой "основного экрана" за исключением дублирующихся частей (например H\V значения незачем генерить по новой и можно взять из "основного экрана"), т.е. есть регистр с X координатой откуда начинает высвечиваться спрайт (или мини-под-экранчик), есть компаратор который сравнивает текущий H счетчик и в момент совпадения запускает ОТДЕЛЬНЫЙ для каждого спрайта сдвиговый регистр, понятное дело что загрузка значения в сдвиговый регистр и значения в регистр Х координаты долно произойти ранее чем началась выводится соответсвующая строка, т.е. имеется отдельный микро-программируемый автомат, который загружает параметры X,Y всех спрайтов, а также ихние тайлы в нужные моменты времени. На выходе изображение из всех спрайтовых сдвиговых регистров подаются на мега-MUX.

3. Для плавного сдвига есть возможность начать вывод тайлов на 0..7 пикселей ранее... (а последний обычно находится "за шторкой" так как если бы он при сдвиге показывался полностью то был бы эфект движения кромки экрана). Сдвиговые регистры обычно могут свигать и влево и вправо (чтобы иметь возможность зеркально отображать тот же самый тайл). Есть программируемый генератор прерывания для CPU в конце
каждой строки (в идеале в момент высвечивания последней видимой точки последнего тайла в строке), это надо для того чтоб экран можно было перепрограммировать находу и скажем плавно двигать только 2/3 экрана а в 1/3 показать статичное табло с результатом, а также можно сделать sprite-multiplex и переиспользовать sprite-генераторы для других спрайтов чем те которые уже высветились на верхних
строках.

Сама схема выходит немалой, например в VIC-II аж 70% чипа занято спрайтами и их там 8 (для портирования 99% ретро игр хватит, но 16 был бы вообще жЫр). Есть проблема с количеством тайлов... 8bit как бы мало (особенно если есть зеркальное отображение, которое обычно только для спрайтов бывает) 16bit на index тайла это полный ЖЫР. Для MAP RAM и SPRITE\TILE RAM есть соблазн влепить мультипортовый SRAM, НО это
своего рода "читерство", которое приводит к потере "спортивного" смысла (как правило она бешенная по скорости да еще и многопортовая, это значит что возможна схема которая использует её как буфер для 1 строчки, и которая успеет в этот буфер вывести просто офигенное количество спрайтов и тайлы, наложить их правильно без всяких мега-MUX и сдвиговых регистров вместо которых будет использоваться схема по типу
bit-shifter-a из автомата space invaders http://searle.hostei.com/grant/spaceInvaders/index.html). Вместо latch+shifter можно влепить FIFO память типа Signetics N9403N или соорудить "линию" спрайта из чего-то типа 74ls396.