nedoPC.org

Отстал я с этой задумкой лет на 30.

Решил, что следующей моей розработкой после вот этого
http://www.nedopc.org/forum/viewtopic.php?t=9066
станет устройство для вывода изображения на экран, которое легко можно будет применить в любой микропроцесорной системе.

Мои познания о видеосигнале базируются на этом
http://mediatory.ru/article22_article_14_1.phtml
и
http://www.rickard.gunee.com/projects/video/pic/howto.php

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

И вот уже на этапе продумывания характеристик "видеокарты"
стали возникать вопросы:

1) Устройство формирует изображение из тремя оттенками серого
(Экономия памяти, 4 пикселя хранятся в 1 байте, ну и повышение производительности)

2)Разрешение 256x256 или более (желательно чтобы управлялось программно)

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

Внутренне карта состоит:

1) Процессор (Z80A, 4Mhz max) просто потому, что их у меня 8 шт.

2) Видеопамять.

3) Устройство для вывода содержимого видеопамяти на экран.

4) "Внешняя" память для обмена данными с системой в которой устанеовлена карта. (Тут же могут быть регистры защелки и буферы с 3-мя состояниями)

5) Собственные RAM и ROM.

6) Туча логики.

7) Регистр засчелка с мультиплексором или сдвигновым регистром и счетчиком или еще чемто, что выдает байт на выход по 2 бита (от части входит в состав "Устройства для вывода содержимого видеопамяти на экран"

"Устройство для вывода содержимого видеопамяти на экран" (назавем его УВС -- устройство вывода сигнала)
генерирует прерывания, заставляя процессор выдавать вертикальные синхроимпульсы, создает строчные синхроимпульсы, меняя адрес выводит в порт вывода содержимое видеопамяти байт за байтом.

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

Главные проблемы:
-Конфликт УВС и процессора при доступе к видеопамяти.
Никак не придумаю ничего дельного, нужно очень много дополнительных микросхем, процессору часто приходится ждать и падает его производительность.

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


Вот... Скажите пожалуйста, что думаете по этому поводу?

Идея хорошая, если никто и не соберёт это устройство больше, то для себя получишь опыт.
По поводу цветности: можно сделать "цифровой" rgb выход и получать 8 различных цветов, а если добавить яркость (оттенки серого, который ты сам хочешь сделать), то цветов ещё прибавится.
По поводу подключения к компьютерам: мне больше нравится вариант, когда видеоконтроллер имеет свою память и виден как порты ввода, как это сделано в денди. Хотя можно память видеоконтроллера включить в какое-нибудь окно основного контроллера, для увеличения скорости заполнения экрана.
Ну и последнее: экран будет текстовым, или графическим, или иметь несколько режимов?

Мне кажется для подобной системы лучше начать с текстового режима. Графический пока и не понадобится.

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

Режим именно графический.
Каждый байт видеопамяти хранит информацию яркости 4 пикселей экрана. Апаратные средства карты сами без участия процессора карты выводят содержимое видеопамяти на экран.
Если нужно вывести символ 8x8, то его прийдется нарисовать (изменив значение 16 ячеек видеопамяти), зато поверх него тут же можно нарисовать окружность, прямую или спрайт.
Содержимое видеопамяти меняет только процессор карты.

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

По поводу "Простейшей микроЭВМ".
Я эту книгу прочитал.
Там описано использование видимо "простейшего телевизора", которому сигналы синхронизации по отдельным проводам идут.
Так было бы очень просто. Но у современных телевизоров есть только разъем "тюльпан", куда нужно подавать хотябы в PAL кодировке сигнал. А там кадровая синхронизация это пачка импульсов (синхронизирующие, уравнивающие) так что не все так просто

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

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

А зачем на такой машине графика? Имхо ненадо и проще сделать текст. Один байт - один символ. ПЗУ знакогенератора и всё. Процессор дополнительный даже не понадобится.



Да, действительно там не то...



Это надо сделать в первую очередь...

А что будет в качестве клавиатуры?

Смешать кадровую и строчную развёртку просто. А если делать цвета в формате RGB, то смешать в PAL можно кодером группы NedoPC.
В книге как раз то, что надо: там по полочкам расписано как сделать видеоконтроллер и получить видеосигнал. Ещё можно почитать Радиоежегодник 85 там тоже схема формирование видеосигнала есть. Так же в "Радио телевизия электроника"¹3"85 и ¹8"85(журналы болгарские, написано кирилицей, вполне читаемо).
Процессор действительно может быть лишним, потому что контроллер сам может последовательно выводить на экран все точки(символы, если он текстовый).
Видеопамять можно сделать 2-страничной: из 1-ой контроллер выводит картинку на экран, во 2-ую процессор записывает данные для вывода, потом они меняются местами и процесс повторяется. Так, конечно, получается 2-ой расход памяти, но организуется прозрачный доступ к памяти.

Вот кое-что из моего видео-наследия:

NedoVideo:
http://www.nedopc.org/forum/viewtopic.php?t=7533

NedoText:
http://www.nedopc.org/forum/viewtopic.php?t=8388
http://www.nedopc.org/forum/viewtopic.php?t=8553

В Радио"87 ¹5и ¹6писали про замену дефицитной 580ВГ75. Замена не полная. Повторять полностью может и не стоит, но почитать можно.

Розбиение видеопамяти на 2 страницы, расположенные в разных чипах это хорошо, но нужно 12 корпусов для мультиплексирования шин адресса и данных (не считая 2 мс. памяти)
Ну и работа с памятью наооборот непрозрачная.

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

С другой стороны внезапно обноружилось, что при использовании медленного процессора (4Мгц, Т=250нс) и быстрой памяти (время циклов чтения и записи < T/3, хорошо бы 50 нс) можно вообще ничего не придпренимать и пользоваться одновремменно одним чипом памяти.

Очередная плохонарисованная картинка
http://files.mail.ru/4932SY

1) Чип памяти выбирается процессором или видеосистемой.
2) Процессор подает сигнал _WR. Сигнал _RD видеосистемы неактивен. При этом буфферы с 3-мя состояниями на выходе соеденяющие шину адреса и шину данных процессора и соответствующие выводы чипа находятся в проводящем состоянии, а буфферы соеденяюшие выводы адресса с ША видеосистемы в высокоомном. Процессор может писать в память.
3) Если сигнал _RD видеосистемы активен, то на в³вод _WR памяти подается 1 независимо от состояния WR процессора. На вывод чтение соответственно подается сигнал чтения. Буферы соеденяющие с процессором отключаются, а соеденяющие с видеоустройством открываются. На память подается адрес ячейки для чтения, осуществляется чтение из памяти видеосистемой, и все возврашается обратно.

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

Если чтение прервало запись после того как сигнал записи был активен дольше времени записи, то на момент начала чтения данные уже записаны, но после завершения чтения сигнал запись может быть активен меньше времени записи (расстояние между синими полосами), что происходит с данными в памяти если производится запись, но продолжается она меньше необходимого времени?

Если данные "портятся" то нужно блоктровать сигнал запись, а это не так просто...

Вот мои мысли. За исходное берем именно быструю статику и Z80.
1. Почему DRAM удобнее? Касаемо Z80, дело то не в объеме. Дело в том, что ты получаешь хорошую подсистему с нормированными таймингами. Поэтому согласование идет проще.
2. Касаемо обращения. Смотри, Z80 при обращениях к памяти делает это при фронте такта / всегда, за исключением цикла М1, который это делает по спаду \.
3. Из-за того, что М1 только читает, в спектруме подгоняют проц так, чтобы по фронту он работал с ОЗУ синхронно, просто подав на его такты сигнал RAS. А М1 выделяют отдельно при дешифрации обращения и записывают его в регистр, чтобы задержать на полтакта.
4. Наипростейшей логикой распределения ОЗУ я бы выбрал следующее: на фронте / организовывать доступ процессора, на спаде \ синхрогенератора. Если такты получить делением - это не сложно (примерно как формирование RAS/CAS). Исключение - М1, который реализовать все тем же регистром, только он будет висеть как ячейка памяти (входы запитаны на выходы) и активироваться он должен после переноса ОЗУ=>регистр на фронте / и активация выходов последнего по спаду \.
Не вижу сложности, получаем синхронный девайс и все происходит прозрачно, без бессмысленного торможения Z80.
PS Если работу синхрогенератора надо ускорить (т.е. повысить например разрешение и т.д.), то мы просто ускоряем эту частоту, а время, выделенное на фронтах для Z80, будет использоваться не полностью (через 1, 2, 3 ... обращения).

Плохой я, видимо, собеседник: редко отвечаю, и не веду диалог
Так что прошу прощенья.



Нет. Процессор по моим задумкам нужен. Контроллер выводит на экран, а кто собственно заполняет видеопамять? Контроллеру подается команда "нарисуй прямоугольник такого-то цвета от точки (x,y) до т. (x1,y1)" и собственно уже сам процессор контроллера заносит в нужные ячейки видеопамяти информацию о чвете/яркости, освобождая ЦП системы где контроллер установлен от этой рутины.

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



Да пожалуй так будет лучше, тем более если выводить все через SCART то и кодер не понадобиться. 4 бита на пиксель = 8 цветов * 2 варианта яркости. Дорева!
Вот только подкинте пожалуйста временную диаграмму RGB видеосигнала. Особенно интересует вход синхронизации -- как выглядят синхроимпульсы? 1.5 часа гуглил не нашел Только в одном проекте издевка что "all this is symple and well documented"

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

Буду дальше думать, и может опять уже через год вы увидете результат


P. S. Если я не найду временные параметры сигнала то не увидите)

Даю ссылочку на тайминги SVGA. Я ими пользовался, когда КР580ВГ75 в режим VGA программировал:

http://www.epanorama.net/documents/pc/vga_timing.html

Вот тут еще посмотрите, может тоже пригодится. Это видеокнтроллер под управлением микропроцессора. http://www.jcwolfram.de/projekte/vhdl/main.php
Или на английском http://opencores.org/projects.cgi/web/fbas_encoder/overview

Невижу "видеоконтроллер". Вижу "кодер PAL". Причем входа цифровые.