Реальный 8086/88 + FPGA

[newold86]

Наверное, еще попробую погонять на максимальной тактовой частоте.

А сейчас сколько? Мой 8086-1 (номинал 10 МГц) уверенно глючил уже на 8.

У меня все строго по стандарту - 4.77

[newold86]

Вы схему оригинального CGA смотрели, анализировали?

Безусловно. ...

А я вот смотрю на схему CGA адаптера и не верю своим глазам - такое впечатление, что при попытке чтения из регистров 3D8 или 3D9 в них запишется то, что в тот момент есть на шине (скорее всего, FF). Интересно, это действительно так, или у меня что с головой ?

P.S. Так удивлен, потому что нигде об этом даже упоминания не видел...

[Lavr]

Вы схему оригинального CGA смотрели, анализировали?

Безусловно. ...

А я вот смотрю на схему CGA адаптера и не верю своим глазам...

Я схему оригинального CGA смотрел от "Искры-1030" - адаптер у нее был полностью аппаратно
совместим и все программы работали нормально.

Но меня тогда интересовал её дополнительный режим, которого нет у оригинального CGA -
"Искра-1030" умела делать 640x400 BW чересстрочный, тогда как оригинальный CGA мог
только 640x200 BW прогрессивный, а я делал расчеты с выводом графики, и после "Специалиста"
с его очень удобным 384х256 это 200 у CGA мне всю малину портило...
Но 640x400 BW чересстрочный не был поддержан в BIOS, a я тогда сам с реализацией
такой графики на ассемблере совладать не сумел...

К сожалению, по регистрам 3D8 и 3D9 я сейчас ничего прояснить не смогу...

[Vic3Dexe]

А я вот смотрю на схему CGA адаптера и не верю своим глазам - такое впечатление, что при попытке чтения из регистров 3D8 или 3D9 в них запишется то, что в тот момент есть на шине (скорее всего, FF). Интересно, это действительно так, или у меня что с головой ?

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

[newold86]

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

Мне очень интересно, что курили инженеры IBM, создавая этот шедевр. Думаю, что даже с моими очень скромными навыками в схемотехнике я бы смог сделать аналогичное по функционалу, но с меньшим количеством корпусов и вообще без 6845...

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

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

Что-то у меня пока идеи закончились, как с этим разбираться...

[Lavr]

Попробовал тут повторить схему CGA адаптера на VHDL.
...
работоспособность меняется даже при перекомпиляции, когда сама схема вообще не меняется,
а просто что-то появляется/исчезает сбоку...
Что-то у меня пока идеи закончились, как с этим разбираться...

Так напишите аналог "в рамках своего понимания" - до сих пор Вы не промахивались!

[newold86]

Меня интересует не функциональный, а потактовый аналог...

[Vic3Dexe]

Меня интересует не функциональный, а потактовый аналог...

Потактовый это как? Гейт в гейт в смысле? Так это моветон, вы же сами уже напоролись на это:

асинхронная схема, в которой исходили из определенных задержек, работает весьма "интересно".

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

Только дело не в быстродействии циклона, а именно в задержках между гейтами, которы вы не повторите при всем желании.
Короче, нельзя повторять в FPGA асинхронную схему 1:1. Нежизнеспособно.

"Ломается" при сигналтапе потому, что где-то времянки не выдержаны. При наличии сигналтапа меняется маппинг гейтов в ячейки, соотв. меняются тайминги - и все опять работает/не работает. Таймквест вам в помощь (хотя я этот барьер пока не взял), для него нужно описание клоков в .sdc-файле.

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

Если сугубо для CGA - то да. Но 6845 использовалась и в MDA, и вообще ее преимущество "на тогда" было в программируемости растра. Т.е. WxH задавались регистрами, а не прибивались гвоздями.
А если повторять функционал 6845 на мелкой логике... Куча счетчиков и регистров их начальной установки (плюс логика записи в них), логика формирования адреса, логика курсора... Да на свою схему посмотрите и посчитайте регистры

[newold86]

Меня интересует не функциональный, а потактовый аналог...

Потактовый это как? Гейт в гейт в смысле?

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

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

Вообще задержки между гейтами всегда приблизительно одинаковы, и зависят только, грубо говоря, от скорости электрического тока в данной среде Вообще, конечно, и я говорил как раз о задержках гейтов - они у Циклона намного меньше. А в схемотехнике CGA на прогнозируемых задержках много чего базируется. И разные по быстродействию серии активно используются, и узлы некоторые напрямую на задержки завязаны. Например, как вам вот такое решение:

delay.jpg

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

Насколько я понимаю (TimeQuest пока освоил совсем чуть-чуть, на уровне готовых примеров), TimeQuest предназначен только для синхронных схем - асинхронные задержки, наверное, можно посчитать, но совсем через одно место, и никакого автоматического анализа не получить (думаю, что ему даже не объяснить, что нужно на выходе)...
Единственное, что пока поддерживает во мне хоть немного оптимизма - вроде бы у меня есть только две плавающих проблемы, причем они все время проявляются (если проявляются) идентично. Если корни этих проблем тоже все время одни и те же, то есть шанс понять, где находится критическое место, и привести его в порядок. Работу сильно осложняет то, что нужно просто наугад добавлять сигналы в SignalTap и перекомпилировать по многу раз после каждого изменения схемы, чтобы перейти в нужное мне состояние (наличие/отсутствие соответствующей проблемы). Это тупо отнимает кучу времени, которого у меня всегда не хватает

[Lavr]

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

Сурово, откровенно говоря! А я, наивный, почему-то всегда думал, что задержки определяются скоростью переключения гейтов...
А между гейтами там и задерживать нечему.

[newold86]

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

Сурово, откровенно говоря! А я, наивный, почему-то всегда думал, что задержки определяются скоростью переключения гейтов...
А между гейтами там и задерживать нечему.

Это, между прочим, НЕ МОИ слова насчет задержек между гейтами, именно поэтому я и прикалывался

А вообще у меня сейчас стадия "это в принципе работать не может !". Возможно, нашел еще одну ошибку в схеме, хотя (скорее всего), возможно, просто не понимаю до конца один из кусков...

[Lavr]

Это, между прочим, НЕ МОИ слова насчет задержек между гейтами, именно поэтому я и прикалывался

Ну, человек всё ж, наверное, выражался фигурально...

[Vic3Dexe]

Давайте расставим точки над ё.
Задержка между гейтами есть сумма всего, что входит в путь от гейта А до гейта Б. Включая другие гейты и пути между ними.
И если пути между ними для мелочевки не суть важны (хотя важны на самом деле, несмотря на скорость света), то для циклона с его быстродействием - очень важны даже в габаритах кристалла.

Вообще, конечно, и я говорил как раз о задержках гейтов - они у Циклона намного меньше.

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

А в схемотехнике CGA на прогнозируемых задержках много чего базируется. И разные по быстродействию серии активно используются, и узлы некоторые напрямую на задержки завязаны.

Как и в любой асинхронной схеме, нет? Ну и как это повторить в циклоне? А главное - зачем??

Сделать такое, моделируя просто функциональность, практически невозможно - всегда найдется какой-то еще один режим

Основанный на задержках? Не найдется, если до нас с вами не нашли, то и вы, я думаю, не найдете

Например, как вам вот такое решение

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

[newold86]

Давайте расставим точки над ё.
Задержка между гейтами есть сумма всего, что входит в путь от гейта А до гейта Б. Включая другие гейты и пути между ними.
И если пути между ними для мелочевки не суть важны (хотя важны на самом деле, несмотря на скорость света), то для циклона с его быстродействием - очень важны даже в габаритах кристалла.

Вообще, конечно, и я говорил как раз о задержках гейтов - они у Циклона намного меньше.

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

Что-то одно и то же по третьему кругу пошло, я с самого начала все это и имел ввиду, просто другими словами

Сделать такое, моделируя просто функциональность, практически невозможно - всегда найдется какой-то еще один режим

Основанный на задержках? Не найдется, если до нас с вами не нашли, то и вы, я думаю, не найдете

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

Прозрачный латч? Что я должен искать в этой схеме или что комментировать?

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

А так хоть сейчас узнаю, как CGA действительно работает

[newold86]

Что-то я совсем близок к тому, чтобы признать поражение

SignalTap почти бесполезен в прямом нахождении гличей, поэтому приходится заниматься логическими размышлениями, глядя на диаграммы, на которых, на самом деле, в критических местах вполне могут быть невидимые импульсы. К сожалению, в случае с CGA глубины стека моего мозга не хватает... Очень обидно - ведь схема почти работает...