Доработки схемы Орион 128

Я это знаю. Окончательные прошивки выложены в открытый доступ. Я также нашел (уже не помню где) некоторые из промежуточных прошивок, в т.ч. одну из прошивок для 7128, выполненную в виде схемы. Она естественно работать не будет. Некоторые до сих пор повторяют эту ошибку.
Вероятно ты вот этот проект имел ввиду?

 
При утроении строк будет экран плющенный. При удвоении должны быть квадратные пикселы. У меня счетчик строк 10 разрядов. 0-й разряд счетчика используется только в XGA режиме. В TV режиме я его отключаю. Т.о. разряды 1-9 счетчика формируют строки для обоих режимов.
В XGA-выдохе при утроении строк расширенный режим 512x256 (SAR=2:1) будет иметь аспект изображения DAR=4:3 и аспект пикселя PAR=2:3 - РОДНЫЕ для Ориона. Во времена разработки и развития Ориона существовали мониторы/телевизоры ТОЛЬКО с DAR=4:3. Не было ещё тогда ни 5:4, ни 16:9...
В XGA-выдохе при удвоении строк расширенный режим 512x256 будет иметь аспект изображения DAR=2:1=4:2 и аспект пикселя PAR=1:1 - НЕРОДНЫЕ для Ориона, жутко сплюстнуто по вертикали. Стандартный режим 384x256 (SAR=3:2) будет иметь DAR=3:2.
 
Последний раз редактировалось:
Я в этом еще не разобрался. Понимаю, что это снимет многие проблемы, но не ясно, в каком направлении двигаться (пока).
Книжка Хоровица и Хилла "Искусство схемотехники". Недаром её называют Библией электронщика-схемотехника.


Вэб-версия. СУПЕР!!!
КАТЕГОРИЧЕСКИ рекомендую вдумчиво почитать часть 10 (особенно про асинхронные и синхронные счётчики), часть 12, и часть 11.
 
у меня такие есть, еще в 96 покупал
 
Вероятно ты вот этот проект имел ввиду?

Вроде эта. Там первые прошивки для 7128 были сделаны в схемном варианте в виде моделей серии 74xx. Т.е. счетчики были как в Орионе: 7493. В Квартусовских моделях эти асинхронные счетчики заменены синхронными, т.е. времянки по определению "поплывут". Хотя... нужно смотреть как эту схему Квартус оптимизирует. Для Протеуса при переходе на синхронные счетчики прошлось формирование цепей 96 и 111 подкорректировать.
 
Просто "засунуть" Орион в ПЛИС - не интересно...
ИМХО, реализация Ориона в ПЛИС должна давать как минимум два отличных профита:
1. Существенную турбу без вэйтов. Для Z80 это 2.5 и 20 МГц. Для 8085 это 2.5 и 10 МГц. Можно сделать сменные модули процессора.
2. XGA-выдох. Для этого видеоконтроллер надо отвязать от памяти и процессора. Процессор должен монопольно работать со статической ОЗУ на любой частоте турба/нетурба. А отдельный видеоконтроллер отслеживает запись процессором данных в ОЗУ по адресам текущего экрана. Как только поймал - фиксирует адрес и данные, а затем осуществляет отложенную запись в свою статическую видеопамять, с которой он работает исключительно монопольно.

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

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

Гы гы, что то мне это напоминает мою видеокарту для Спектрума. Там тоже видяха смотрит по каким адресам обращается комп и если это видео, то пишет информацию к себе. Комп не знает о видяхе и пишет и читает исключительно из своей внутренней памяти. А видяха работает только на запись в свою память. По сути происходит дублирование основного поля компьютера - это есть минус.
Но есть большой плюс - видеорежимы можно любые делать, в рамках железа конечно.
 
Просто "засунуть" Орион в ПЛИС - не интересно...
ИМХО, реализация Ориона в ПЛИС должна давать как минимум два отличных профита:
1. Существенную турбу без вэйтов. Для Z80 это 2.5 и 20 МГц. Для 8085 это 2.5 и 10 МГц. Можно сделать сменные модули процессора.
2. XGA-выдох. Для этого видеоконтроллер надо отвязать от памяти и процессора. Процессор должен монопольно работать со статической ОЗУ на любой частоте турба/нетурба. А отдельный видеоконтроллер отслеживает запись процессором данных в ОЗУ по адресам текущего экрана. Как только поймал - фиксирует адрес и данные, а затем осуществляет отложенную запись в свою статическую видеопамять, с которой он работает исключительно монопольно.

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

Сергей, может проникнишься этими идеями и воплотишь их с галками?
Ну, если я правильно понял, то отказ не принимается....
Идея понятна. Как защелкнуть нужные байты, вроде тоже ясно (3 защелки на 8 бит + логика управления), причем туда можно писать вообще все - это будет даже проще .... СРАМ-ку взять 64К*16 бит и тупо в нее записывать по адресу из защелки во время вывода байта на экран Защелки для байтов, которые будут перезаписываться в регистры сдвига вроде без надобности, мультиплексоры адресов, если хорошо подумать тоже нафиг убираем... Теоретически видеокарта будет проще синхрогенератора Ориона. К плюсам можно отнести тот факт, что эта архитектура отличная база для модульности.
 
причем туда можно писать вообще все - это будет даже проще ....
ИМХО, плохая идея...
А если процессор произвёл запись по адресу x3FFF в пятой странице памяти, это к видеопамяти не относится, и модулю отложенной записи это ни к чему. Отслеживать надо первые две страницы памяти, 128 КБ. Зафиксиривать адрес и данные, взвести триггер признака отложенной записи, и всё это по положительному фронту /MEMWR (задний фронт, конец импульса). Пересинхронизировать признак на дополнительном триггере по пиксельклоку. А потом уже писать в видеопамять.

СРАМ-ку взять 64К*16 бит
Можно взять 61C1024 с организацией 128Кх8. За время вывода 8 пикселов (8 таймслотов) обращаться к ней дважды, за атрибутами (пишется в буфер) и за битмапом (пишется в регистр сдвига, и одновременно атрибуты из буфера пишутся во вторую ИР13). А в перерывах между ними и писать отложенку.

Защелки для байтов, которые будут перезаписываться в регистры сдвига вроде без надобности,
Вот про это вообще не понял...

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

Теоретически видеокарта будет проще синхрогенератора Ориона.
Ха! Ещё какая сложная!

К плюсам можно отнести тот факт, что эта архитектура отличная база для модульности.
Это факт! ;)

Нужно использовать быстрые серии мелкосхем ABT, F, ACT, ACHT, ну и галки <=15нс.
 
Последний раз редактировалось:
Гы гы, что то мне это напоминает мою видеокарту для Спектрума. Там тоже видяха смотрит по каким адресам обращается комп и если это видео, то пишет информацию к себе. Комп не знает о видяхе и пишет и читает исключительно из своей внутренней памяти. А видяха работает только на запись в свою память. По сути происходит дублирование основного поля компьютера - это есть минус.
Но есть большой плюс - видеорежимы можно любые делать, в рамках железа конечно.
Выходит, что так. ;)
Расскажи, пожалуйста, о твоей архитектуре отложенки и её реализации.
 
Выходит, что так. ;)
Расскажи, пожалуйста, о твоей архитектуре отложенки и её реализации.

Сейчас уже точно не помню, но повозиться пришлось. Ссылка на проект - http://micklab.ru/ZXMVideoCard.htm
Изначально я ставил свой кварц на 28МГц, но возникли проблемы синхронизацией бордерных эффектов Спектрума, поэтому взял частоту 14МГц с основной платы.
Помоему идея была такова.
Защелкиваем в триггер сам цикл записи компа по стробу 14МГц
Это у нас как бы сигнал фиксации адреса и данных в буферных регистрах.
Также формируем сигнал WE памяти видеокарты, который также стробируется фиксатором записи.
Еще триггер на сброс сигнала WE, он стробируется сигналом RAS видеокарты.

Вот кусок кода на AHDL, а целиком исходники по ссылке

Код:
    ------------------------------------------------------------------------------------
    -- Сигнал стробирования сигналов от процессора
    ------------------------------------------------------------------------------------
    Data_fix.d = C_MREQ # C_WR # !Sel_A45 # Sel_ram;
    Data_fix.clk = !CLK_14MHZ;

    DData_reg[7..0].d       = CD[7..0];
    DData_reg[7..0].clk   = Data_fix.q;

    DAddr_reg[8..0].d = CA[8..0];
       DAddr_reg[9].d      = RA[2];
    DAddr_reg[14..10].d   = CA[13..9];
       DAddr_reg[15].d      = RA[0];
       DAddr_reg[16].d      = RA[1];
       DAddr_reg[17].d      = RA[3];

    DAddr_reg[17..0].clk  = Data_fix.q;

    Data_we.d    = GND;
    Data_we.clk  = Data_fix.q;
    Data_we.prn  = Ram_write.q;

    RAM_write.d    = Data_we.q;
    RAM_write.clk  = !RAS_sync.q;
    RAM_write.prn  = !Sync_count[1].q;
    ------------------------------------------------------------------------------------
    -- Запись в память
    ------------------------------------------------------------------------------------
    MWE = RAM_write.q;

    REG_wrdata[].in = DData_reg[].q;
    REG_wrdata[].oe = !RAM_write.q;

    DATA_VID[]      = REG_wrdata[].out;
    MD[]            = DATA_VID[].out;
 
ИМХО, плохая идея...
А если процессор произвёл запись по адресу x3FFF в пятой странице памяти, это к видеопамяти не относится, и модулю отложенной записи это ни к чему. Отслеживать надо первые две страницы памяти, 128 КБ. Зафиксиривать адрес и данные, взвести триггер признака отложенной записи, и всё это по положительному фронту /MEMWR (задний фронт, конец импульса). Пересинхронизировать признак на дополнительном триггере по пиксельклоку. А потом уже писать в видеопамять.
Имелось ввиду писать все с 0 и 1 страницы памяти. Когда печатал, не все продумал.
 
Можно взять 61C1024 с организацией 128Кх8. За время вывода 8 пикселов (8 таймслотов) обращаться к ней дважды, за атрибутами (пишется в буфер) и за битмапом (пишется в регистр сдвига, и одновременно атрибуты из буфера пишутся во вторую ИР13). А в перерывах между ними и писать отложенку.
Все так...
 
Один источник адресов - чтение видеоконтролером, другой - запись отложенки. Мультиплексоры нужны.
Я рассуждал так: регистры отложенной записи берем с тремя состояниями, счетчики видеопамяти делаем на ГАЛках тоже с тремя состояниями. Разрешаем выход для регистров или счетчиков по очереди. Мультиплексоры работают так-же.
 
регистры отложенной записи берем с тремя состояниями, счетчики видеопамяти делаем на ГАЛках тоже с тремя состояниями. Разрешаем выход для регистров или счетчиков по очереди.
КРАСИВЫЙ схемотехнический приём!
Минус 17 мультиплексоров 2-в-1, это аж 5 корпусов КП11.
Минус задержки в мультиках.
Но, у HiZ тоже есть задержки включения/выключения, и возможны сквозные токи.
 
Нашел у себя в архивах неплохую модельку цветного дисплея для Proteus. Называется VSMDigitalDisplay.dll. Подключил к Ориону - полет с натяжкой можно назвать нормальным.
Обитает модель по адресу: https://github.com/martinpiper/DigitalDisplay?ysclid=mveu694yg114505213
Но в репозитории модель допилили до совместимости с Proteus 9.0 и в 8-й версии он работает с ошибкой (по крайней мере у меня). Поэтому работаю со старой версией, скачанной год назад .

Достоинства модели:
* Настраиваемое разрешение отображаемой области экрана. Для телевизора нужно ввести 640*312 точек. Работать будет и в режиме VGA, SVGA.
* Входы RGB по 8 бит. Т.е. поддержка 24 битного цвета.
* Возможна работа с отладочной информацией.

Недостатки (очень существенные):
* информация выводится в окно модели, поэтому картинка сильно искажается при масштабировании (нет всплывающего экрана с масштабом 100% по пикселям)
* картинка обновляется по щелчку мыши по экрану модели.

Несмотря не недостатки, работать можно.
VSMDISPLAY.PNG
VSMDISPLAY1.PNG
 

Вложения

Назад
Вверх