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

[andreil]

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

В соседнем разделе лет десять назад был проект 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 в видеотракте - сократит логику до минимума, если времянки позволят.

[Advertiser]

[OrionExt]

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

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

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

[andreil]

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

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

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

[Error404]

Тут проблема не в помехах на линиях данных/адреса/прочих, а асинхронность частей.
Процессор у нас тактируется на 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 процессора, то и проблемы никакой не будет.

[andreil]

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

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

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

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

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

[Denn]

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

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

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

В МХ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 имхо можно не заморачиваться..

[Error404]

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

С ВГ93 должно нормально прокатить увеличение частоты, там критично наоборот - если вдруг будет не хватать (2,5М это минимум на котором возможно прочитать сектора 5х1024), с любой схемой Турбо ВГ нормально сочеталась на известном мне софте.

А с клавиатурой надо будет или поправить константу автоповтора в Мониторе, или просто привыкнуть. Даже на старых схемах 3,9М (Турбо 5М с Wait) было терпимо без исправления константы автоповтора, а этот режим в сравнении с штатными 2,5М был заметно быстрее нового получающегося 3,125М (25/8). Что до более скоростных режимов турбирования новой платы (25/4=6.25, 25/2=12.5), то их можно использовать софтом, который опрос клавы делает в привязке к INT50Гц (так например делают многие игры портированные на Орион от ZX, или консольный драйвер CPM) и там уже это не будет критично (или в более скромном варианте - софт может ставить другие константы автоповтора).

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

[Denn]

С ВГ93 должно нормально прокатить увеличение частоты, там критично наоборот - если вдруг будет не хватать (2,5М это минимум на котором возможно прочитать сектора 5х1024)

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

[andreil]

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

Точно можно выкинуть расширенный экран? Тут многие наоборот, просят именно его

[Denn]

andreil, "широкоэкранные" мониторы хороши разве что для просмотра киношек, и то там 16:9 (=1,7), а тут диспропорция аж в 2 раза и ни разу не кино. Какой смысл в такой картинке?
Потом, стандартное расположение экранной области (включается по-умолчанию при сбросе) с C000h, т.о. "киношный" экран своими 16 Кб сжирает всё непереключаемое ОЗУ ПРК и залезает на ПЗУ Монитора. Неудобный он, что аппаратно, что программно.
Имхо, неразумная плата за лишние 16 символов в в строке. Используется только в PRODOS на Орионе-ПРО. Если упираться в спортивный интерес, то поддержать можно, а практически смысла не вижу.