Еще один Орион на ПЛИС

Кручу-верчу организацию памяти здесь и уже понятно, что надо делать псевдо-двухпортовую память для конкретно данного случая (и схожих с ним).
Проблема, собственно, заключается в асинхронности процессора и видео - в ПРОшке это всё тактировалось от 1 кварца.
Если в Орионе к частоте процессора ничего не привязано, то можно её и изменить, но это будет уже не Орион :) Исходить в таком случае надо от частоты 25МГц и получаем частоты 3.125/6.25/12.5МГц...
А для самой памяти придётся делать схему с удвоением частоты на 2-х инверторах и XOR'е для получения 50МГц - необходимо для организации "двухпортовости".
Сейчас ещё попробую текущий вариант покрутить, не меняя частоты, но корректной работы, без конфликтов процессора и видео, не получается - во время работы тесты видно пропуски при массовой записи в память.

От тактовой частоты в Орионе ничего не зависит такого за что стоило бы цепляться.

В соседнем разделе лет десять назад был проект hardwareman-а где Специалист на 8080 и Z80 (можно было ставить как тот так и другой) и РУ5 (тут не помню, может статика там была?) нативно выводил на VGA (тайминги были соответствующие). Может оттуда "списать" как надо? А то выходит какой-то монстр (по требуемым компонентам) с довольно скромными преимуществами (2-3 раза по скорости совершенно теряются если для этого надо память работающую на на 50Мгц)

Цитата:

---

Сообщение от Error404

От тактовой частоты в Орионе ничего не зависит такого за что стоило бы цепляться.

В соседнем разделе лет десять назад был проект hardwareman-а где Специалист на 8080 и Z80 (можно было ставить как тот так и другой) и РУ5 (тут не помню, может статика там была?) нативно выводил на VGA (тайминги были соответствующие). Может оттуда "списать" как надо? А то выходит какой-то монстр (по требуемым компонентам) с довольно скромными преимуществами (2-3 раза по скорости совершенно теряются если для этого надо память работающую на на 50Мгц)

---

Если убрать переключение видеорежимов (384/512, широкий экран), то схема видеотракта будет такого же уровня сложности.
В МХ2 используется видеорежим 800x600@60Hz с удвоением пикселей - пиксельклок 40МГц. Но это 4:3, а где сейчас найти такой монитор? Везде 16:9, так что надо реализовывать и такой видеорежим, а значит нужно подобрать оба с одинаковым пиксельклоком. Я таких нашел только 2:

• VGA 640x350@70 Hz (pixel clock 25.175 MHz)
• VGA 640x480@60 Hz Industry standard (pixel clock 25.175 MHz)

И да, расширенный экран Ориона с удвоением пикселей НЕ ВЛЕЗЕТ ни в один из упомянутых видеорежимов - напомню, что там получится картинка размером 512х256 пикселей (да даже 480х256 не влезет уже). Тут и стандартный экран (384х256) впритык на 800х600 поместится с удвоением-то.

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

Если я не прав, и есть 2 подходящих по пиксельклоку видеорежима - ткните в их времянки, я не находил такового...

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

А по памяти - я не говорил, что она будет работать на 50МГц ;) Эта частота нужна для управляющей логики, что бы максимизировать время доступа. По факту получается 2 такта на обращение к памяти, то есть 25МГц (40нс).

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

Я вот подумываю о применении GAL в видеотракте - сократит логику до минимума, если времянки позволят.

Вот апять не понятны шатания автора (надо делать реал). Дальше - это мое личное мнение.

Очень полезно для меня выходит и подтвердило (были попытки, месяца 2 мучался, и просто забил), что сделать Орион-128 с разбросом частоты 20..2,5мГц очень маловероятно на стандартной логике (или как будет угодно на FPGA с простым подходом).
И не важно, на какой видео-выхлоп (VGA лежит в рамках - LS, хоть и с натягом.) это делается, соль в другом=)

Кстати, вот та макетка с дешевым FPGA и прикрученным (МГТФ) 3.3В ОЗУ выдавала аж 50Мгц для простого CP/М компьютера.

Тут проблема не в помехах на линиях данных/адреса/прочих, а асинхронность частей.
Процессор у нас тактируется на 2.5/5/10Мгц, а видео - 25МГц. В итоге у нас нет 100% окна, как в ПРО - что бы в определённый такт открыть доступ процессора к памяти по необходимости и потом через пару тактов назад на видео переключиться. В текущем варианте обращение процессора к памяти может произойти абсолютно в любой момент относительно видеовывода.
Посмотрите на ПРО - триггеры D28.2/D115.2 как раз отвечают за арбитраж памяти и происходит это на строго фиксированных тактах (конкретно - по сигналу 42).

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

А по реалу - у меня проц и память и так реальные, только внутренняя логика на данный момент в ПЛИС, что бы её обкатать.

Цитата:

---

Сообщение от andreil

Тут проблема не в помехах на линиях данных/адреса/прочих, а асинхронность частей.
Процессор у нас тактируется на 2.5/5/10Мгц, а видео - 25МГц. В итоге у нас нет 100% окна, как в ПРО - что бы в определённый такт открыть доступ процессора к памяти по необходимости и потом через пару тактов назад на видео переключиться. В текущем варианте обращение процессора к памяти может произойти абсолютно в любой момент относительно видеовывода.

---

Очень запросто для тактирования ЦПУ с кратностью к пиксельклоку можно использовать такие частоты:
25/8=3.125
25/4=6.25
25/2=12.5

Повторюсь, на Орионе не было критичности к частоте ЦПУ, и 3.125 будет вполне достаточно чтобы ордосовские игры не сильно были быстрее оригинала (+ поправить константу автоповтора клавиатурной п/п Монитора), и для игр ZX хватало (которые не синхронизируются по кадровому гасящему СИ). А вот которые синхронизируются по КГСИ, то тут ХЗ (у нас ведь будет 60Гц а не 50Гц), но навскидку особенных проблем (кроме чуть более быстрого проигрывания AY и убегания аппаратных часов, я не вижу). А если получится каждый шестой ГКСИ не доводить до INT процессора, то и проблемы никакой не будет.

Либо взять гену на 50МГц и получить с него нужную сетку, хоть 50/25/12,5/6,25/3,125 хоть 50/10/5/2,5. Городить огород с удвоением не вижу никакого смысла.

Цитата:

---

Сообщение от Error404

Очень запросто для тактирования ЦПУ с кратностью к пиксельклоку можно использовать такие частоты:
25/8=3.125
25/4=6.25
25/2=12.5

Повторюсь, на Орионе не было критичности к частоте ЦПУ, и 3.125 будет вполне достаточно чтобы ордосовские игры не сильно были быстрее оригинала (+ поправить константу автоповтора клавиатурной п/п Монитора), и для игр ZX хватало (которые не синхронизируются по кадровому гасящему СИ). А вот которые синхронизируются по КГСИ, то тут ХЗ (у нас ведь будет 60Гц а не 50Гц), но навскидку особенных проблем (кроме чуть более быстрого проигрывания AY и убегания аппаратных часов, я не вижу). А если получится каждый шестой ГКСИ не доводить до INT процессора, то и проблемы никакой не будет.

---

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

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

Кстати, ещё вопрос по железу, на перспективу - что на счёт использования GAL вместо кучи мелкой логики? При их использовании, в идеале, синхрогенератор для видео "схлопнется" в 6 счётчиков и 2 GAL'ки.

Да, сделал части синхронными - и проблем с памятью почти нет. Осталось только фронт обращения к памяти укоротить до 80нс. А так - вроде бы даже работает.
Проблемы мелкие есть, но только из-за того, что циклы не подогнал ещё к таймингам реальным.

Цитата:

---

Сообщение от Error404

Повторюсь, на Орионе не было критичности к частоте ЦПУ

---

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

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

Цитата:

---

Сообщение от andreil

В МХ2 используется видеорежим 800x600@60Hz с удвоением пикселей - пиксельклок 40МГц. Но это 4:3, а где сейчас найти такой монитор? Везде 16:9, так что надо реализовывать и такой видеорежим, а значит нужно подобрать оба с одинаковым пиксельклоком. Я таких нашел только 2:

• VGA 640x350@70 Hz (pixel clock 25.175 MHz)
• VGA 640x480@60 Hz Industry standard (pixel clock 25.175 MHz)

И да, расширенный экран Ориона с удвоением пикселей НЕ ВЛЕЗЕТ ни в один из упомянутых видеорежимов - напомню, что там получится картинка размером 512х256 пикселей (да даже 480х256 не влезет уже).

---

При удвоенной точке по обеим координатам неродное разрешение смотрится вполне нормально на любом мониторе. С режимом 512х256 имхо можно не заморачиваться..