Просмотр полной версии : Вектор-06Ц, 580хх на ПЛИС
Погуглил "PCI-compliant" на одном банке IO у МАХа ... честно говоря, что-то не вдохновило :(
Две ПЛИСины лепить, скорее всего, проблем будет выше крыши.
Значит остается Циклон с обвязкой из преобразователей уровня.
Благо, кроме шины данных, все остальные однозначно, либо вход, либо выход. 74LVX добавит только 3-6ns задержки.
С шиной данных пока не знаю. Для той-же 74LVX понадобится специально выводить управляющие сигналы, так как аналогов штатных выходов ВМ80 для корректного переключения, скорее всего, будет не достаточно.
Что меня смущает, так это эпопея с КвазиДиском, который оказался очень капризным, и чувствительным к сигналам управления и состоянию шины адреса.
Improver
10.06.2022, 11:14
Что меня смущает, так это эпопея с КвазиДиском, который оказался очень капризным, и чувствительным к сигналам управления и состоянию шины адреса.Он оказался чувствительным к ШАП/RAS/CAS (после мультиплексоров), причём не из-за процессора, а по причине специфичной работы схемы 02-го Вектора, так что тут беспокоится особо не о чем, если ПЛИС будет попадать в диаграммы и тайминги в пределах значений по документации на ВМ80 (и ВМ1). Разброс характеристик у процессоров тоже ведь был.
Значит остается Циклон с обвязкой из преобразователей уровня.Ок, только в обвязке ещё надо учесть 12В уровни на F1, чтобы не трогать остальную схему Вектора.
KTSerg, спасибо за создание отдельной темы.
Немного про 74LVX (https://www.eevblog.com/forum/projects/74lvx245-what-the-heck!/) (и не только).
Для той-же 74LVX понадобится специально выводить управляющие сигналы, так как аналогов штатных выходов ВМ80 для корректного переключения, скорее всего, будет не достаточно.
Скорее всего DBIN хватит.
- - - Добавлено - - -
только в обвязке ещё надо учесть 12В уровни на F1, чтобы не трогать остальную схему Вектора.
Полная совместимость с ВМ80 - это здорово, но чуть модифицировать вектор для получения F1 5В (как для ВМ1) заметно проще. F2 вряд ли понадобится.
С шиной данных пока не знаю.
На вход та-же 74LVX, а вот на выход нужен другой буфер, с тремя состояниями, выдающий +5В, и которому хватит +3.3В для входных сигналов (74HCT?).
- - - Добавлено - - -
Есть ещё вот такая бяка TXS0108E (https://www.ti.com/lit/ds/symlink/txs0108e.pdf), 8-канальная, с тремя состояниями, двунаправленная. По-моему идеально для шины данных.
KTSerg, спасибо за создание отдельной темы.
Немного про 74LVX (https://www.eevblog.com/forum/projects/74lvx245-what-the-heck!/) (и не только).
Скорее всего DBIN хватит.
- - - Добавлено - - -
Полная совместимость с ВМ80 - это здорово, но чуть модифицировать вектор для получения F1 5В (как для ВМ1) заметно проще. F2 вряд ли понадобится.
У меня сейчас между разъёмом "ВУ" Вектора и Альтерой 74LVX уже стоят.
Я не хотел бы менять подтяжку F1 на самом Векторе, вдруг приспичит ВМ80 воткнуть, а склероз - дело такое, можно и забыть, что что-то обратно перепаивать нужно.
- - - Добавлено - - -
На вход та-же 74LVX, а вот на выход нужен другой буфер, с тремя состояниями, выдающий +5В, и которому хватит +3.3В для входных сигналов (74HCT?).
- - - Добавлено - - -
Есть ещё вот такая бяка TXS0108E (https://www.ti.com/lit/ds/symlink/txs0108e.pdf), 8-канальная, с тремя состояниями, двунаправленная. По-моему идеально для шины данных.
А почему 74LVX на выход не подоёдёт? Он ведь с двумя питаниями и на выходе нормальный уровень будет для TTL.
У неё ведь и переключение направления есть и в третье состояние можно переключить.
Я смотрел вчера TXS0108, там что-то про ограничения в применении говорится. Написано, что она двунаправленная, вроде интересно, но на плате Вектора, шина данных подтянута к питанию, и не понятно как на это отреагирует TXS, вдруг будет считать, что снаружи логическую "1" нужно на проц передавать.
Понятнее 74LVX переключать когда это нужно, собственно только на время чтения шины. Над переводом в третье состояние тоже надо подумать.
В Шадках по-моему похожая проблема решена успешно. У меня там стоят 74lvc8t245 для 8 линий и lvc1t45 для единичного гейта. У них два питания между которыми осуществляется трансляция уровней и никаких ремарок по поводу того, что мол лол тут у нас 5В на 3.3В просачивается я не нашел. Может быть плохо искал, но с другой стороны плисина в Шадках жива, так что наверное они работают.
Я не читал всю ветку на eevblog, но по-моему там речь немного о другой микросхеме. Это шинный буфер, который имеет одно питание и вроде бы действительно, если он запитан от 3В и на его выход вдруг начинают вдавливать 5В, он таки прогнется. Но это другая микросхема, не надо ее использовать для трансляции уровней. Там прямо специально написано, что вот именно этого делать не надо.
Чисто технически разместить такое вместе со всеми причиндалами на платке размером с DIP40 наверное будет непросто. Это уж точно будет плата не двухслойная и монтаж с двух сторон. Можно еще на ребрах навесить светодиодов и конденсаторов. Типа один пин на верхнем слое, второй на нижнем =)
В Шадках по-моему похожая проблема решена успешно. У меня там стоят 74lvc8t245 для 8 линий и lvc1t45 для единичного гейта. У них два питания между которыми осуществляется трансляция уровней и никаких ремарок по поводу того, что мол лол тут у нас 5В на 3.3В просачивается я не нашел. Может быть плохо искал, но с другой стороны плисина в Шадках жива, так что наверное они работают.
Я не читал всю ветку на eevblog, но по-моему там речь немного о другой микросхеме. Это шинный буфер, который имеет одно питание и вроде бы действительно, если он запитан от 3В и на его выход вдруг начинают вдавливать 5В, он таки прогнется. Но это другая микросхема, не надо ее использовать для трансляции уровней. Там прямо специально написано, что вот именно этого делать не надо.
...
Я когда первоначально искал микросхему согласования уровней, тоже на али собирался заказать 74lvc8t245 и lvc1t45, но когда заказ уже был сделан и оплачен, увидел, что я глюканул, и заказал 74LVX4245 и lvc1t45.
74LVX4245 это ущербная версия 74lvc8t245.
Если для 74lvc8t245 по даташитам, нет разницы с какой стороны какое питание, то по даташиту 74LVX4245, настоятельно рекомендуется (или однозначно указано), с какой стороны какой вольтаж подаётся.
А, понятно. Мне вообще с микросхемами на Али везло до сих пор, но все время рассказывают всякое. Перед тем, как жечь ими дорогую ПЛИС, я бы наверное проверил, что это вообще 4542, да и вообще что это 74LVX :)
Вообще 74lvx4542 чего-то не гуглится. Тут детали все решают. Может не спешить и сделать другой заказ.
И вот BTW, почему бы не поучиться у тех, кто уже успешно прошел этот путь ? В той же схеме 65f02 используются вот такие буферы: 74LVC245ABQ. Кроме всего прочего, у них приятный для упаковывания в ничтожный размер форм-фактор.
Я уже исправил 4245, а не 4542.
Improver
10.06.2022, 15:21
Чисто технически разместить такое вместе со всеми причиндалами на платке размером с DIP40 наверное будет непросто.Я так думаю, сделать платку один в один размером с ВМ80 можно, но тогда её нужно будет делать и распространять партиями не меньше сотни штук. Лучше путь будет больше процессора по размерам (но легко размещаемая в Векторе), но собираемая "в домашних условиях", без профессионального оборудования, иначе сложность её повторения резко ограничит круг заинтересованных лиц.
...
такие буферы: 74LVC245ABQ. Кроме всего прочего, у них приятный для упаковывания в ничтожный размер форм-фактор.
Я смотрел, вроде это всего лишь "толерант к 5V". Из даташита не понятно, есть ли у него на выходе ОК, что-бы прокачать 5V-шину данных компа.
Если ограничиться (по крайней мере пока) обсуждением вектора, то с детства/юности помню, что емкостная клавиатура полностью закрывала проц, а вот из-под герконовой его было видно и с ней теоретически можно было сделать не такую уж и маленькую платку замены проца без перекрытия с клавиатурой. А железячники прошлого не парились и на кишиневском адаптере z80, как я понимаю (см. еще вектор-user 20), фактически полулежала клавиатура, ужасное конструктивное решение.
Да, хотелось-бы собрать самому.
А значит формфактор буферных чипов скорее всего не меньше soic (10*15мм) так вроде они обзываются.
И плата скорее всего, разъём DIP-40 будет находиться сбоку от ПЛИСа. Тогда и под емкостной клавой поместится.
Других съедобных вариантов пока в голову не приходит.
Я смотрел, вроде это всего лишь "толерант к 5V". Из даташита не понятно, есть ли у него на выходе ОК, что-бы прокачать 5V-шину данных компа.
The 74LVC245A; 74LVCH245A is an 8-bit transceiver with 3-state outputs. The device features an output enable (OE) and send/receive (DIR) for direction control. A HIGH on OE causes the outputs to assume a high-impedance OFF-state. Inputs can be driven from either 3.3 V or 5 V devices. This feature allows the use of these devices as translators in mixed 3.3 V and 5 V environments.
Schmitt-trigger action at all inputs makes the circuit tolerant of slower input rise and fall times.
This device is fully specified for partial power down applications using IOFF. The IOFF circuitry disables the output, preventing the potentially damaging backflow current through the device when it is powered down.
Разве это не идеальный вариант? Откуда взялось требование к ОК? Разве у 8080 есть какие-то ноги ОК? Насколько я помню у него ноги nMOS, все дохленькие и в схеме практически всегда дополнительно буферизованы, потому что как раз иначе никак. Что до пайки, на фабричную плату с маской такие чипы легко припаиваются обычным паяльником. Флюса не жалеть, прогреть хорошо, припой сам найдет куда ему затечь.
Improver
10.06.2022, 16:25
Других съедобных вариантов пока в голову не приходит.А что если сделать выносную плату на гибком плоском шлейфе? Даже можно типа FFC.
А сверху над процом зазор есть? Или прям упирается в плату клавиатуры?
Я к тому, что можно было бы разместить бутерброд из двух платок при наличии места.
Как будет выглядеть в итоге, вариантов накидали. Конкретный разговор можно будет начинать когда Вектор заработает с подключенной девбордой Циклона вместо процессора.
Тогда будет понятно, что должно быть в обвязке Циклона.
У меня осталось 4245-ых и lvc1t45 как раз, чтобы переходник сделать.
Как-бы ещё F1 и F2 ничего не спалили.
Интересно встречного диода с резистором будет достаточно...
Как-бы ещё F1 и F2 ничего не спалили.
Зачем F2? Насколько помню две фазы требовал только вариант Vslava и он вполне переваривал F2=not F1. Если понадобиться задержать фазу/фазы, то это можно сделать внутри плис
TomaTLAB
10.06.2022, 19:11
TXS0108, там что-то про ограничения в применении говорится. Написано, что она двунаправленная, вроде интересно, но на плате Вектора, шина данных подтянута к питанию, и не понятно как на это отреагирует TXS, вдруг будет считать, что снаружи логическую "1" нужно на проц передавать. Будет передавать, но не единицу, а свою внутреннюю подтяжку. Только при изменении уровня она "стреляет" ключами one shot для быстрой перезарядки емкости линии, остальное время обычный транслятор на полевике и подтяжками на разные питания по сторонам, по сути, со стороны шины выглядит как открытый сток с подтяжкой.
А почему 74LVX на выход не подоёдёт?
Ну не знаю. К примеру 74LVX245, хоть у неё максимум Vcc +7B, но рекомендованный максимум +3.6В. Так что решать вам.
Ну не знаю. К примеру 74LVX245, хоть у неё максимум Vcc +7B, но рекомендованный максимум +3.6В. Так что решать вам.
Я ни чего не знаю про 74LVX245.
Уже пользуюсь 74LVX4245, для согласования шины разъёма "ВУ" и девборды Альтеры. В том числе шины данных. Пока проблем не заметил.
- - - Добавлено - - -
... по сути, со стороны шины выглядит как открытый сток с подтяжкой.
Возможно TXS0108 и подходящий вариант для шины данных, меньше головной боли с переключением направления.
Только в наличии такого чуда природы нет. А в местный сельмаг могут завезти по цене 240 руб/шт.
- - - Добавлено - - -
Что-то я туплю с подключением F1 - проще не бывает... простейший делитель напряжения на двух резисторах...
F1---.
II 15К
i-------- > 5V
II 10K
i
-- gnd
Я когда-то через подобный делитель напряжения подключал к девайсам дисплеи от телефонов.
Тем более, с делителя ведь будет не сразу на Альтеру идти, а через преобразователь 5>3.3.
Что-то я туплю с подключением F1 - проще не бывает... простейший делитель напряжения на двух резисторах...
Так обычно не делают с клоком, потому что получается ФНЧ неплохой из этих резисторов и емкости пина. Допустим у Cyclone IV пин имеет емкость 8пФ, тут выйдет Fc=1.3МГц. Ну так, может и проканает.. Но лучше известные грабли сразу обойти, чтобы сэкономить силы на прохождение граблей пока еще неизведанных.
Так обычно не делают с клоком, потому что получается ФНЧ неплохой из этих резисторов и емкости пина. Допустим у Cyclone IV пин имеет емкость 8пФ, тут выйдет Fc=1.3МГц. Ну так, может и проканает.. Но лучше известные грабли сразу обойти, чтобы сэкономить силы на прохождение граблей пока еще неизведанных.
Ну, я ведь говорил, что собираюсь F1 подключать не прямиком к Циклону, а через буфер.
Если с делителем на резисторах получается ФНЧ, то какие ещё варианты, делать преобразователь на Мосфете типа схем с BSS138 ?
Фактически нужно преобразовать 12В сигнал в 5В, который через 74lvc1t45 пойдёт в дело.
какие ещё варианты
например
чуть модифицировать вектор для получения F1 5В (как для ВМ1)
какие ещё варианты
Я совсем не эксперт, но вариантов предлагают много разных -- надо подбирать самый подходящий
https://next-hack.com/index.php/2017/09/15/how-to-interface-a-5v-output-to-a-3-3v-input/
Собственно делитель из резисторов тут один из них. Опять же, если взять сопротивления поменьше, то может быть эффект фильтра можно скомпенсировать нагрузочной способностью источника. Мне нравится схема из мосфета с ОЗ, но это скорее эмоционально. На практике я использовал только 74lvc1t45 и только один раз.
TomaTLAB
11.06.2022, 23:04
Только в наличии такого чуда природы нет. А в местный сельмаг могут завезти по цене 240 руб/шт.
https://aliexpress.ru/item/32988164907.html?spm=a2g2w.productlist.0.0.5aee62e 39V3UHT&sku_id=66850826621
Как овна за баней.
У меня вообще появилась идея взять циклопа в мелком BGA и TXS-ок 5шт. в QFN на все 38 пинов сороканожки и сделать эмулятор "почти чего угодно" строго в габаритах DIP-40.
https://aliexpress.ru/item/32988164907.html?spm=a2g2w.productlist.0.0.5aee62e 39V3UHT&sku_id=66850826621
Как овна за баней.
У меня вообще появилась идея взять циклопа в мелком BGA и TXS-ок 5шт. в QFN на все 38 пинов сороканожки и сделать эмулятор "почти чего угодно" строго в габаритах DIP-40.
Если есть возможность заказать изготовление из таких комплектующих, или самостоятельно спаять такое изящное изделие, то конечно, нет смысла городить "монстра".
TomaTLAB
12.06.2022, 16:13
В принципе, ничего там сверхъестественного, но если страшно, можно отнести в ремонтную мастерскую. Ребята будут рады припаять свежий чип на новенькую плату и отдохнуть от утопленных в толчках телефонов и зассанных котами ноутбуков :D
В принципе, ничего там сверхъестественного, но если страшно, можно отнести в ремонтную мастерскую. Ребята будут рады припаять свежий чип на новенькую плату и отдохнуть от утопленных в толчках телефонов и зассанных котами ноутбуков :D
Я не имею опыта общения с BGA корпусами, но мне кажется, что если плату для него разводить, то скорее всего, двумя слоями не обойтись.
Если делать платку "универсальной платформы", то место для разъёма программирования, джамперы, для отключения некоторых "критичных" пинов типа нестандартного питания ВМ80, и обход на альтернативный вход с F1, F2.
Improver
16.06.2022, 13:15
его сделали не совместимым по распиновке, и его нельзя использовать вместо 8080, без доработок.
Судя по инфе, в 8085 додумались сократить 5ти тактовые команды до 4х тактов. На Векторе это дало-бы значительный прирост быстродействия.Кстати, ещё одна идея для реализации в ПЛИС -- сделать 8085 с распиновкой ВМ80. :)
Кстати, ещё одна идея для реализации в ПЛИС -- сделать 8085 с распиновкой ВМ80. :)
Разве только чтобы посмотреть: "что будет если"...
Полетят все тайминги, скорее всего на экране вылезут артефакты в игрушках и наступит полный каллапс в демках.
В сложных (с точки зрения программирования) играх, и серьёзных демах, скорее всего многое было привязано к таймингам.
Меня другое больше интересует...
За последнее время просмотрел форумы на предмет недокументированных команд в ВМхх.
У ВМ80, как кто-то подметил, это скорее не дополнительные "недокументированные", а банально не доделанный дешифратор (или как его там правильно назвать) команд. Так как в при выполнении "неопределённого" кода выполняется вполне определённая команда, и их коды имеют значительное сходство.
А вот ВМ1 реально имеет дополнительные, недокументированные команды.
Понимаю, что для многих тут это "прописные истины", но мой склероз преподносит много сюрпризов... ;)
Надо ещё раз найти тему про программную методику определения типа процессора. Там код был, я его не внимательно посмотрел.
Нужно глянуть, по каким командам процессоры различают...
Разве только чтобы посмотреть: "что будет если"...
"Что будет если" можно посмотреть в Emu или VV, там 8085 реализован со всеми таймингами и недокументированными особенностями.
Полетят все тайминги, скорее всего на экране вылезут артефакты в игрушках и наступит полный каллапс в демках.
С демками проблемы, а с подавляющим большинством игрушек все нормально. Еще проблема с обменом с магнитофоном, векторовские программы надо тюнинговать. Также страдает биперная музыка, при необходимости можно доработать.
Но если вспомнить название темы, то все проблемы с таймингами 8085 и z80 можно решить. По умолчанию тайминги 8080, а когда надо быстрее - включаем быстрые тайминги. Примерно так было сделано в кишиневском адаптере z80, но там возможности были ограниченные и корректировались только mov/inr/dcr, а с плисом можно корректировать все.
А вот ВМ1 реально имеет дополнительные, недокументированные команды.
Очень интересно, можно ли где-нибудь прочитать про недокументированные команды 580ВМ1?
...
Очень интересно, можно ли где-нибудь прочитать про недокументированные команды 580ВМ1?
Скачал себе описание этих инструкций, но сейчас не могу найти куда кинул.
Кстати интересная выдержка с форума "недопс":
...
В "Вектоp" ВМ1 вставляется элементаpно, pаботает очень надежно, совместимость с ВМ80 после этого- абсолютная. Из адаптиpованного ПО есть веpсия ДОС Т-34 для этого пpоцессоpа. Ускоpение основных функций заметно даже на глаз." /Сергей Терентьев/
http://www.nedopc.org/forum/viewtopic.php?t=8283
Кстати интересная выдержка с форума "недопс":
В некотором смысле замкнулся круг, насколько помню это цитата с сайта Tim0xи.
Скачал себе описание этих инструкций, но сейчас не могу найти куда кинул.
У меня закрадывается подозрение, что тут речь о документированных командах 580ВМ1, описание которых расползлось по интернету и есть например здесь (https://sensi.org/scalar/ware/582/). Для меня недокументированные команды 580ВМ1 это те, которых нет в KP580BM1.DOC. Например там перечислены не все возможные варианты команд с префиксами. Возможно они являются дублями документированных (как у ВМ80), а возможно не для всех это так.
В некотором смысле замкнулся круг, насколько помню это цитата с сайта Tim0xи.
Да, просто я раньше не обращал внимание на инфу, что есть ДОС Т-34 адаптированная менно для ВМ1.
У меня закрадывается подозрение, что тут речь о документированных командах 580ВМ1, описание которых расползлось по интернету ...
Таблицу с документированными я уже изучал.
Сначала увидел эту таблицу с нарушенным форматом, и там вообще не смог понять о чём речь. Но потом наткнулся на версию с нормальной таблицей команд, и сразу стало понятно, где совместимые команды, где новые, и что они делают.
...
Очень интересно, можно ли где-нибудь прочитать про недокументированные команды 580ВМ1?
Нашел у себя документ с описанием недокументированных команд.
Но не могу сообразить, почему я при сохранении назвал его "ВМ1", так как в нём оказалось описание 10ти новых команд 8085.
Видимо не понял контекст сообщения в котором приводилась ссылка на описание, а так как само описание на буржуйском, вчитываться не стал, а просто сохранил, перепутав название процессора.
Ввёл в заблуждение, прошу прощения.
Вот только не понятно, если в 8085 известно 12 новых команд, то почему в таблицах TASM-ов для 8085, к командам 8080, добавлены только две официальные команды...
Для себя дополнял таблицу для TASMа. Консенсуса по поводу названий недокументированных команд 8085 нет, я выбрал вариант для совместимости с идой. В качестве альтернативы можно посмотреть z80asm из z88dk, там другой синтаксис.
Для себя дополнял таблицу для TASMа. Консенсуса по поводу названий недокументированных команд 8085 нет, я выбрал вариант для совместимости с идой. В качестве альтернативы можно посмотреть z80asm из z88dk, там другой синтаксис.
А в иде есть недоументированные ?
Глянул таблицу для ТАСМа, мнемоника команд такая-же как доках на буржуйском.
А в иде есть недоументированные ?
да
Глянул таблицу для ТАСМа, мнемоника команд такая-же как доках на буржуйском.
В разных доках можно увидеть разные мнемоники.
Наибольшее разнообразие для jx5/jnx5. Альтернативные варианты jk/jnk, jui/jnui. Мне больше нравится jk/jnk, но на что не пойдешь для совместимости с идой.
Другие альтернативы менее популярны:
ARHL - RRHL
RDEL - RLDE
LDHI - ADI HL
LDSI - ADI SP
Вот с DSUB, LHLX, SHLX и RSTV вроде все согласны.
Пока собираю переходник DIP40-Девборда Альтеры, стало интересно, на сколько в Векторе, формирование F1 и F2 соответствует даташиту на 8080.
Не знаю, на сколько можно верить Протеусу, в плане симуляции работы схемы...
Собрал в Претеусе узел формирования F1 и F2... чёт даже близко не по даташиту... F1 в два раза короче минимума, про интервалы между фронтами F1 и F2 вообще молчу.
Во вложении скрин Лог.Анализатора Протеуса. 25нс на деление. 3 и 6МГц с выходов счётчика, из которых и формируются F1 и F2.
Смотрю 06c_36.png с логического анализатора (не KTSerg ли снимал эти логи?) и вижу вполне вменяемые F1 и F2. F1 - четверть такта, потом F2 - две четверти такта, потом четверть такта пусто. Картина на осциллографе наверняка немного отличается, но не настолько же.
Смотрю 06c_36.png с логического анализатора (не KTSerg ли снимал эти логи?) и вижу вполне вменяемые F1 и F2. F1 - четверть такта, потом F2 - две четверти такта, потом четверть такта пусто. Картина на осциллографе наверняка немного отличается, но не настолько же.
Что-бы увидеть оба сигнала на осциллографе, нужен двухлучевой.
Реальный "Логический анализатор" имеет ограничение по частоте семплирования, значит точные времянки не посмотреть, особенно на высоких частотах.
Хотел точно симулировать схему, и посмотреть реальное положение F1 и F2.
Похоже придётся пропустить инверсные F1 и F2 через 2ИНЕ, и смотреть на простом осциллографе.
Можно разделить задачу на две
1. Временные параметры F1 и F2. Смотрим по отдельности и снимаем вопросы типа
F1 в два раза короче минимума
(очень сомневаюсь, что так будет)
2. Положение F1 относительно F2. Раз речь о логическом элементе, значит F1 и F2 уже преобразованы к 5В?
Насчет И-НЕ признаюсь не очень понял. Если нужно посмотреть "пустые" места между импульсами, то лучше подойдет ИЛИ-НЕ.
Можно разделить задачу на две
1. Временные параметры F1 и F2. Смотрим по отдельности и снимаем вопросы типа
...
К сожалению, осциллограф оказался слишком слабым... :(
Даже на частоте 3МГц сильные завалы фронтов.
Реальные десятки "нс" мне не посмотреть.
2. Положение F1 относительно F2. Раз речь о логическом элементе, значит F1 и F2 уже преобразованы к 5В?
Нет, не преобразованы, просто взять со входов ЛН3. Потому и писал "инверсные F1 и F2".
Если судить логически, то в Векторе действительно тайминги будут меньше минимума по даташиту... Так как по даташиту частота F1 и F2 вроде 2.7МГц (если считать тайминги), а на проце Вектора они 3МГц, значит значения будут меньше указанных.
Потому и писал "инверсные F1 и F2".
Пардон, был невнимателен, тогда понятно почему И-НЕ.
Если судить логически, то в Векторе действительно тайминги будут меньше минимума по даташиту
С этим вряд ли кто-то будет спорить, в СССР не выпускались ВМ80 с официальными частотами >2.5 МГц, но на практике работали на более высоких частотах. Десятки тысяч векторов тому в подтверждение, а у Micka в экспериментах даже худшие экземпляры заводились на 3.4 МГц. Но я бы не зацикливался на даташитах ВМ80/8080, если речь о новодельном проце и принял в качестве рабочего приближения, что F1 - четверть такта, F2 - следующие две четверти такта, потом четверть пустая. Для плисовых процов на частоте 3 МГц это должно быть совершенно не критично.
...
F1 - четверть такта, F2 - следующие две четверти такта, потом четверть пустая. Для плисовых процов на частоте 3 МГц это должно быть совершенно не критично.
Я пока не знаю, на сколько это не критично, если пытаться плисовый проц воткнуть в реальный комп.
Согласен, что если плисовый проц в плисовом компе, то можно что-то, где-то подправить задержками...
А вот как будет взаимодействовать плисовый проц в реальном компе...
Пока сам не увижу, что работает, буду сомневаться. ;)
Много раз в 90-ых, мелькало, что растактовка Вектора якобы показывала, что он работает (балансирует) "на грани".
Не знаю на сколько это заявление было справедливым, ведь он работает довольно стабильно, даже не смотря на одновременное применение в нём микросхем разных серий, с разными внутренними задержками.
Сам эту инфу не проверял, но это мнение было устойчивым.
Много раз в 90-ых, мелькало, что растактовка Вектора якобы показывала, что он работает (балансирует) "на грани".
Для меня этот вопрос в значительной степени закрыла тема с zx8080 Micka. Там можно проследить, что процы нормально работали на 3.5, некоторые на 4 МГц и неожиданно не работали на 3 МГц, причем как раз более быстрые. Это решилось коррекцией (задержкой) тактового сигнала, причем достаточно оказалось задержать F2. В векторовской теме можно встретить аналогичный случай, когда после замены в векторе на другой ВМ80 он нормально не работал. Если проц рабочий, то это явно можно было вылечить коррекцией тактовых сигналов. Mick выкладывал логи с анализатора для разных процов и там видно, что более новые (по крайней мере это касается некоторых заводов) стали быстрее, там меньше задержки некоторых сигналов.
Многобукаф, если коротко
1. 3 МГц для ВМ80 не проблема при подходящих тактовых сигналах (и 3 МГц не предел).
2. Все же не считаю особенности тактирования ВМ80 значимыми для плисового новодела. Если там и будут особенности, то свои.
...
неожиданно не работали на 3 МГц, причем как раз более быстрые. Это решилось коррекцией (задержкой) тактового сигнала, причем достаточно оказалось задержать F2.
...
2. Все же не считаю особенности тактирования ВМ80 значимыми для плисового новодела. Если там и будут особенности, то свои.
Мне кажется я об этом и говорю.
Что схема Вектора может быть чувствительна к поведению процессора. А его поведение зависит от F1 и F2.
В указанном случае, понадобилось задержать F2, что-бы привести выходные сигналы процессора в соответствие с потребностями схемы компьютера.
Попробую перепаять сканер шины "ВУ", завести на него инверсные F1, F2. Период семплирования конечно целых 10нс, но может что-то прояснится.
Мне кажется я об этом и говорю.
Что схема Вектора может быть чувствительна к поведению процессора. А его поведение зависит от F1 и F2.
В указанном случае, понадобилось задержать F2, что-бы привести выходные сигналы процессора в соответствие с потребностями схемы компьютера.
Применительно к плисовой реализации я уже писал, что если надо задержать, то делаем задержку в плис. Возможно потребуется подвести к плисине 12 МГц.
Заменил в "сканере ВУ" сигналы "сброс" и "ввод" на F1 и F2, которые взяты на входах микросхемы D81 схемы Вектора-06Ц (инвертировал при сканировании для наглядности).
Семплирование 100МГц для таких сигналов маловато, но будет от чего отталкиваться.
Результат разительно отличается от симуляции Протеуса.
Длительность F1 ~100нс, F2 ~170-180нс.
- - - Добавлено - - -
Простой делитель напряжения на резисторах не годится для получения F1 c амплитудой 5В. :(
Проверил c сопротивлениями 10К и 15К. Меньше не рискнул, т.к. при формировании F1 используется резистор 1.5К-1.6К. Если уменьшать сопротивления в делителе, то нужно будет учитывать ещё и взаимное влияние.
Во вложении кусок скрина со сканера.
Верхний F1 - на входе D81.
Нижний F1 - с делителя на резисторах, из реального F1. Правда проц не вынимал, возможно вход процессора мог добавить искажений.
Нужно ещё попробовать преобразователь на MOSFETе, успокоиться и сделать доработку самого Вектора, запитав F1 от 5В, а не от 12В.
оффтоп:
Разве очень сложно посмотреть два сигнала (а в некоторых случаях и шину данных/адреса всю) и их взаимное расположение (при условии что они "постоянны") на одно лучевом осциле ? Это даже можно на "Осциллограф С1-112".
1) смотрим первый сигнал, запоминаем параметры.
2) подключаем его на вход синхры. синхронизируемся
3) смотрим второй сигнал от синхры первого.
или я о чём-то "вдрызг очевидном говорю" ? и совсем не в тему ?
Improver
18.06.2022, 17:02
Разве очень сложно посмотреть два сигнала (а в некоторых случаях и шину данных/адреса всю) и их взаимное расположение (при условии что они "постоянны") на одно лучевом осциле ?Не сложно. Если надо, могу вечером тыкнуть осликом в Вектор, подобные диаграммы уже снимал как-то для ГФ24 тут (https://zx-pk.ru/threads/33133-vektor-06ts-novodel-(ne-altera).html?p=1111238&viewfull=1#post1111238).
оффтоп:
...
Это даже можно на "Осциллограф С1-112".
...
По характеристикам полоса до 10МГц.
Посмотрел характеристики своего С1-107 ... - до 5МГц... бесполезно синхронизироваться, ничего не увидеть.
Хоть 3МГц и должен показывать, но фронты жутко заваливает.
Improver
18.06.2022, 22:47
Обещанные осцилограммы тактовых частот Вектора, для начала F1 и F2 на процессоре (снимал на резисторах R9 и R10, они удобнее для подключения):
77471
Канал 1 -- R9, сигнал F2
Канал 2 -- R10, сигнал F1
А это на входах 1 и 3 микросхемы D81, до преобразования уровней в 12В:
77472
Канал 1 -- вывод 1 D81, инверсный F2
Канал 2 -- вывод 3 D81, инверсный F1
Снимал всё это на осцилограф FNIRSI-1013D, не профессиональный ригол, но всё же 1GSa/s на два канала и с полосой 100МГц...
Удивляет амплитуда канала 2 (F1, если я правильно понял).
Посмотрел характеристики своего С1-107 ... - до 5МГц... бесполезно синхронизироваться, ничего не увидеть.
Хоть 3МГц и должен показывать, но фронты жутко заваливает.
Синусоиду 3 МГц должен показывать, а прямоугольные прямоугольники разве что до 0.5-1 МГц
Improver
19.06.2022, 09:53
Удивляет амплитуда канала 2 (F1, если я правильно понял).Да, это F1 (дополнил сообщение). Меня тоже удивило, но так оно и есть.
А пробы с каким делителем были? Земля где подключалась?
Improver
19.06.2022, 11:31
А пробы с каким делителем были?1:1
Земля где подключалась?В обязательном порядке, на обоих щупах.
Возможно, первый щуп надо было немного подрегулировать -- там всплески в нижней границе графика больше, чем на втором, но это не так критично для определения границ фронтов, думаю.
Удивляет амплитуда канала 2 (F1, если я правильно понял).
...
Видимо нагрузка у процессора по F1 и F2 разная.
У простого Вектора в схеме аж два инвертора объединены по входам/выходам, чтобы F2 прокачать.
Да и сопротивления подтяжки у F1 и F2 отличаются в 2-3 раза у 02-го и почти в 5 раз у простого Вектора.
Извините за оффтоп, но вот такие крутые F1 (https://imgbb.com/WgP7phs) и F2 (https://imgbb.com/0GkCcBt) Mick формировал в zx8080 с использованием 170АП3. Вряд ли кто-то будет перепахивать формирование тактовых в векторе, но я к тому, что "красивые" F1 и F2 вполне достижимы (и без ГФ24). Тема на nedopc (http://www.nedopc.org/forum/viewtopic.php?f=90&t=11201) про тактовые для 8080.
TomaTLAB
19.06.2022, 18:38
1:1 Епрст... И что мы надеемся таким макаром нащупать?
Improver
19.06.2022, 19:20
Епрст... И что мы надеемся таким макаром нащупать?Эмм... Надо было 1:10? Не шутите, это 1:10 для напряжений больше 50В, в таком режиме только хуже будет.
Нет, почему же больше 50В, откуда такие идеи? Для таких вещей годится только 1:10.
Improver
19.06.2022, 22:02
Нет, почему же больше 50В, откуда такие идеи? Для таких вещей годится только 1:10.
Исхожу из характеристик ослика:
Установка коэффициента затухания датчика -- 1Х, 10Х
Максимальное входное напряжение -- 40 В (1X), 400 В (10Х)
И да, ошибся, больше не 50В, а 40В. В общем, для любых измерений на Векторе оптимально будет "1х" (оно же 1:1).
Максимальное входное напряжение это хорошо. Если оно максимальное 400В, это не значит, что нельзя такой пробой померить 0.5В. Оно же не минимальное. Делитель используется для того, чтобы увеличить импеданс пробы, а значит уменьшить влияние на измеряемую схему. Это особенно важно когда сигнал быстрый и дохленький. Осциллографу при этом надо сказать, что используется проба 10х и он внутри все усилит и пересчитает как надо.
Improver
19.06.2022, 22:22
Осциллографу при этом надо сказать, что используется проба 10х и он внутри все усилит и пересчитает как надо.Пробовал и в таком режиме снимать, уж поверьте, картинка становится только хуже -- вместе с усилением сигнала усиливаются и шумы. Но, если надо, могу сделать и такой вариант.
По идее если сигнал периодический, то сделав 1000 замеров все шумы усереднятся и сойдут на 0, что обычно на практике и происходит. Единичный замер бывает и шумноват.
Но конечно кто знает, что это за FNIRSI такой (хотя вообще вроде бренд осторожно хвалят)
... Осциллографу при этом надо сказать, что используется проба 10х и он внутри все усилит и пересчитает как надо.
По логике, когда ослику говорят, что будет использован 1:10, это означает, что к нему подключат на вход сигнал, который он, без делителя, не в состоянии переварить. Сомневаюсь, что ослик станет что-то усиливать... скорее "вздрогнет"...
Единственное оправдание (с моей точки зрения) для применения делителя в данном конкретном случае, это отличие входных параметров ослика и делителя, к примеру у делителя меньше входная емкость. О общем случае, внесение искажений в изучаемую схему (щупом) будет иное. Я не говорю о искажении изучаемого сигнала, а именно о внесении в схему иной паразитной ёмкости.
Наличие на самом ослике режима 10х, ни как на прямую не связано с применением внешнего делителя.
Если вообще речь шла о применении такого.
Я не хочу спускать тему во флейм (и вообще я сварщик не настоящий!) но если осциллограф сигнал с амплитудой ~5-12В не может показать более-менее убедительно с пробой 1:10, тут что-то не так.
Improver
20.06.2022, 13:46
В общем, да, подрегулировал щупы и с делителем 1:10 картинка на резисторах (сигналы уровня 12В) стала более красивой, особенно F2:
77482
Канал 1 -- R9, сигнал F2
Канал 2 -- R10, сигнал F1
А входе микросхемы D81 (сигналы уровня 5В) отличий практически нет:
77483
Канал 1 -- вывод 1 D81, инверсный F2
Канал 2 -- вывод 3 D81, инверсный F1
HardWareMan
20.06.2022, 15:51
KTSerg прав. Режимы, отличные от 1х, нужны чисто для согласования единиц измерения. Т.е., чтобы у цифрового осцилла все числа сразу автоматически показывали правильное значение. Для аналогового это становится тренировкой для ума: ты берёшь числа на ослике и умножаешь на множитель в уме. Никаких усилений или подавлений внутри осцилла при этом не происходит, оно происходит во внешнем щупе.
Алсо, заявленные мегагерцы у щупов обычно именно на делителе, а на 1х у всех щупов параметры сильно хуже.
... Возможно потребуется подвести к плисине 12 МГц.
По отсутствию опыта в таких делах, я пока не могу понять, зачем дополнительно подводить 12МГц...
Строгой синхронизации процессов в Векторе практически нет, все сигналы формируются через прорву логики рассыпухи, причём разношерстной, с разными задержками.
Я вот подумал, если есть хотя-бы F1, даже отстающий от реального, то этого вполне достаточно.
Делаем 300МГц из 50МГц, и на их основе рисуем свои F1 и F2, там где нужно, синхронизируя начало цикла с полученным на входе худосочным F1. Благо при этом двигать фронты генерируемых F1 и F2 можно будет как угодно без особых проблем.
Я понимаю, что кварцы не все одинаковые, и 12МГц не всегда одинаковые.
Но и коррекцию в ПЛИСине сделать не проблема. Считай сколько тактов частоты 300МГц проходит между фронтами соседних входных F1, и вноси поправки в счетчики.
Из-за отсутствия реального опыта, проблем в этом пока не вижу. ;)
Я понимаю, что кварцы не все одинаковые, и 12МГц не всегда одинаковые.
Но и коррекцию в ПЛИСине сделать не проблема. Считай сколько тактов частоты 300МГц проходит между фронтами соседних входных F1, и вноси поправки в счетчики.
Завидую оптимизму. К сожалению затрудняюсь быстро найти тему про "внешнюю плисовую видеокарту" Syntala, где вопрос об одинаковости внешних/внутренних 12 МГц уже возникал.
Строгой синхронизации процессов в Векторе практически нет
Есть строгая синхронизация проца с видео.
Делаем 300МГц из 50МГц, и на их основе рисуем свои F1 и F2
В высокие частоты без крайней необходимости не стоит уходить, это потенциальный источник проблем. Не то чтобы нельзя сделать нормально, но степень новизны в проекте лучше сократить.
- - - Добавлено - - -
С другой стороны есть пример шадков, где svofski или иначе смог приноровиться с внешними 96 МГц (если не ошибаюсь) к вектору. Но там не все так просто, возможно он напишет свое мнение, использовать ли внешний независимый клок для проца.
HardWareMan
22.06.2022, 09:15
Делаем 300МГц из 50МГц, и на их основе рисуем свои F1 и F2
В высокие частоты без крайней необходимости не стоит уходить, это потенциальный источник проблем. Не то чтобы нельзя сделать нормально, но степень новизны в проекте лучше сократить.
Тем более, что такое возможно только в PLL, а это значит постоянный джиттер.
Завидую оптимизму. К сожалению затрудняюсь быстро найти тему про "внешнюю плисовую видеокарту" Syntala, где вопрос об одинаковости внешних/внутренних 12 МГц уже возникал.
Есть строгая синхронизация проца с видео.
Тут скорее синхронизация от 6МГц, как внучатые племянники... От 6МГц работает видео, и из этих-же 6Мгц формируется F1/F2 - задающая для процессора.
В высокие частоты без крайней необходимости не стоит уходить, это потенциальный источник проблем. Не то чтобы нельзя сделать нормально, но степень новизны в проекте лучше сократить.
...
Не, я не предлагал переделать ядро проца на 300МГц. ПЛИСовые 8080 вроде на 50МГц сделаны, если я правильно понял.
Я предлагал сформировать свои F1 и F2 на основе счетчика от 300МГц, это позволит двигать фронты F1 и F2 с точностью 3.33нс.
При этом ядро ПЛИС проца вообще трогать не нужно, просто на его вход будут подаваться F1 и F2 не с пинов (через буферы) а сгенерированные, выставленные в нужное место, для синхронизации с видео.
300МГц взял, так как мне показалось, на вскидку, что 300МГц это последняя (наибольшая) из доступных частот кратная и 50МГц и 12МГц.
Improver
22.06.2022, 10:31
Тут скорее синхронизация от 6МГц, как внучатые племянники... От 6МГц работает видео, и из этих-же 6Мгц формируется F1/F2 - задающая для процессора.Хочу напомнить про сигнал МХ2, который формируется в видео и тормозит процессор, так что тут родственных связей чуть больше... :)
Не, я не предлагал переделать ядро проца на 300МГц. ПЛИСовые 8080 вроде на 50МГц сделаны, если я правильно понял.
Я предлагал сформировать свои F1 и F2 на основе счетчика от 300МГц, это позволит двигать фронты F1 и F2 с точностью 3.33нс.
Примерно так я и понял и по возможности желательно без этого обойтись. Если чуть в сторону, то "личные рекорды" тактирования T80 у меня в районе 120-144 МГц в рамках v06cc (девборды на 4 и 5 циклонах).
Тут скорее синхронизация от 6МГц, как внучатые племянники
У вектора тесно связаны вместе видеоконтроллер, тактирование проца и циклы озу. Если тактовая проца будет (пусть даже очень медленно, это без разницы) дрейфовать относительно озу, то нехороший эффект у этого будет. Опять же, это преодолимая проблема, но все имеет свою цену. Навскидку переделка взаимодействия проца с озу на асинхронное приведет к необходимости дополнительных тактов ожидания, а это альтернативные тайминги команд на ровном месте и дополнительное вмешательство в схему компа.
Чтобы повысить конструктивность дискуссии пара вопросов:
1. Какое ядро 8080 планируешь использовать?
2. С каким интерфейсом (через какой интерфейс)?
Хочу напомнить про сигнал МХ2, который формируется в видео и тормозит процессор, так что тут родственных связей чуть больше... :)
Я думал, что МХ2 формируется в D36, а на неё ничего кроме задающего генератора не влияет. Если не брать в расчёт регистр состояния.
Значит МХ2 не может "формироваться в видео".
Или я ошибаюсь?
- - - Добавлено - - -
...
1. Какое ядро 8080 планируешь использовать?
2. С каким интерфейсом (через какой интерфейс)?
Вы тут усердно стращали предпринятыми усилиями по "допиливанию" Т80, и ещё какой-то версии...
Я эти проекты вроде пока даже не смотрел.
Смотрел проекты на "vm80a", мне показалось, что код доступен для понимания. Пока, предварительно, возможно, начну эксперименты с него.
На счет интерфейса не понял.
С другой стороны есть пример шадков, где svofski или иначе смог приноровиться с внешними 96 МГц (если не ошибаюсь) к вектору. Но там не все так просто, возможно он напишет свое мнение, использовать ли внешний независимый клок для проца.
Опыта замены процов в реальных схемах аналогами на ПЛИС у меня нет совсем. Представить себе асинхронный проц на ПЛИС с двухфазным клоком я, честно говоря, не могу. Чтобы сохранить рассудок, сам бы я наверное начал с проца на больших мегагерцах (но не 300МГц, это ой), а внешние клоки семплировал бы в разрешающие сигналы. Подогнать +- какие-то фазовые смещения сигналов в такой конструкции вполне можно, если того будет требовать система. Можно сделать подгоночные параметры настраиваемыми, чтобы не упираться в задачу решения всех проблем сразу.
300МГц взял, так как мне показалось, на вскидку, что 300МГц это последняя (наибольшая) из доступных частот кратная и 50МГц и 12МГц.
А зачем нужна кратность 50МГц?
...
А зачем нужна кратность 50МГц?
Собираюсь начать эксперименты с подключения готовой девборды. А на ней кварц 50МГц, от него и плясать.
Возможно лучшим решением было-бы завести внешнюю частоту с Вектора на Альтеру, подать её на PLL и жить в гармонии...
Но наиболее близкая к меандру, и доступная на пинах частота с которой наверное можно было-бы синхронизироваться, это F2.
Подать её на PLL получить нечто пригодное для ядра...
А на ней кварц 50МГц, от него и плясать.
Это просто кварц, от него с помощью PLL можно получить более удобные для себя частоты. Необязательно тактировать свою систему от кварца напрямую.
На счет интерфейса не понял.
В данном случае с использованием проца Vslava это скорее всего будет
module vm80a
(
input pin_clk, // global module clock (no in original 8080)
input pin_f1, // clock phase 1 (used as clock enable)
input pin_f2, // clock phase 2 (used as clock enable)
input pin_reset, // module reset
output[15:0] pin_a, // address bus outputs
inout [7:0] pin_d, //
input pin_hold, //
output pin_hlda, //
input pin_ready, //
output pin_wait, //
input pin_int, //
output pin_inte, //
output pin_sync, //
output pin_dbin, //
output pin_wr_n
);
Хотя не исключено, что придется сделать свой вариант согласования с vm80a_core.
Но наиболее близкая к меандру, и доступная на пинах частота с которой наверное можно было-бы синхронизироваться, это F2.
Подать её на PLL получить нечто пригодное для ядра...
И все же как тогда с этим
Но я бы еще обратил внимание на другую строку fIN Input clock frequency и минимальная там 5 MHz.
Не буду притворяться, что знаю, какие конкретно проблемы будут в данном случае. Возможно будет работать, но с некими особенностями. Лучше бы все же на это не нацеливаться, если знающие люди не скажут - "не обращайте внимания на даташит, можно подать на вход pll 3 МГц и будет нормально работать".
В сухом остатке (достаточно капитанский) вопрос - как сформировать с минимальными усилиями pin_clk, pin_f1, pin_f2 и желательно без pll.
Improver
22.06.2022, 16:49
Я думал, что МХ2 формируется в D36, а на неё ничего кроме задающего генератора не влияет. Если не брать в расчёт регистр состояния.
Значит МХ2 не может "формироваться в видео".
Или я ошибаюсь?Точно, это я ошибся -- в моей схеме МХ2 формировался в видеокарте, а на первом Векторе был в D36 (во втором в D79.2), но это тоже можно отнести к части схемы сигналов управления памятью, которые влияют на процессор.
Спаял переходник DIP40 - девборда. Для начала, на ШД поставил TXB0108, на все остальные LVX4245.
Собрал интерфейс для vm80a.
По входному F1 сгенерировал новые F1 и F2, выставил их относительно импульсов 6МГц...
Не взлетело :(
После нажатия/отпускания БЛК+ВВОД осциллограф показывает, что появляются пачки импульсов на ШД, ША, управлении... вроде как оживает, но сразу замолкает. На всех выводах всё пропадает.
Вектор рандомно изменяет тональность писка после каждого ресета.
Логическим анализатором выловил, что после ресета появляются "строб сост.", но вместо ЧТЗУ идут импульсы ЧТВВ.
Корректность шины данных пока не могу проверить, сканер ВУ снова завыёживался.
Не могу понять, почему ПЛИС-проц вообще останавливается...
Тактовые F1 и F2 - вижу, из входных с Вектора кроме F1 есть ещё INT (если правильно помню).
Единственное объяснение, которое приходи в голову, в шуме ШД ловит команду "HLT".
Если действительно ловит HLT, то удивляет, с каким упорством и постоянством. Разброс по времени "работы" минимальный.
KTSerg, что подал на pin_clk?
KTSerg, что подал на pin_clk?
Для начала 100МГц. :)
Счётчиков в ядре не заметил, к частоте вроде не должно быть привязано. От частоты ядра, на сколько я понял, будет зависеть только быстрота (и стабильность) реакции ядра на изменения состояний некоторых регистров и сигналов.
С другой стороны, основные процессы начинаются по фронтам F1 и F2, а они от pin_clk не зависят, они сами по себе.
По тому, что успел отловить сканером и анализатором, "ЧТВВ" и "строб сост." выглядят адекватно.
- - - Добавлено - - -
Вообще, для отладки, было-бы замечательно организовать остановку "процессора" на каждом цикле, чтобы смотреть, что происходит.
С другой стороны, если сканер-ВУ заработает, то 40-ка сканируемых сигналов с семплированием 5нс надеюсь будет достаточно... :)
Для начала 100МГц.
pin_clk с отдельного генератора, а pin_f1 и pin_f2 из векторовских сигналов (из 6 МГц и F1, если я правильно понял)?
Единственное объяснение, которое приходи в голову, в шуме ШД ловит команду "HLT"
По слову состояния можно увидеть, какой цикл выполняет процессор, правда без логического анализатора тут вряд ли получится.
Можно сделать обертку для проца внутри плиса и пускать наружу только ограниченный набор сигналов. Например можно все чтение делать из внутренней памяти (в которую записать какой-нибудь минималистичный тестик), а наружу только записывать.
pin_clk с отдельного генератора, а pin_f1 и pin_f2 из векторовских сигналов (из 6 МГц и F1, если я правильно понял)?
...
pin_clk, pin_f1, pin_f2 - от генератора ПЛИС.
От входного F1 по переднему фронту перезапускается счетчик. По конкретным значениям счетчика формируются фронты/спады импульсов для pin_f1 и pin_f2.
Результат смотрел сканером с семплированием 5нс, от оригинальных F1 и F2 (снятых до преобразования их в 12В) не отличить.
- - - Добавлено - - -
...
Можно сделать обертку для проца внутри плиса и пускать наружу только ограниченный набор сигналов. Например можно все чтение делать из внутренней памяти (в которую записать какой-нибудь минималистичный тестик), а наружу только записывать.
В проектах для vm80a.v похоже идут такие тестовые обертки, но для меня пока это слишком сложно. :(
Тогда минималистичный тест стоит записать в векторовское пзу. Если без анализатора, то можно и тест посложнее, например этот (https://zx-pk.ru/threads/30914-testovoe-pzu.html?p=1156693&viewfull=1#post1156693). На мой взгляд на первом этапе стоит воздержаться от чтения озу в любых видах (кроме как для тестирования) и добиться хотя бы работы с пзу.
TomaTLAB
30.06.2022, 10:58
Для начала, на ШД поставил TXB0108 Вот это, кмк, зря. Вот оно, в отличие от TXS, могет на шине с подтяжками раскорячиться.
Вот это, кмк, зря. Вот оно, в отличие от TXS, могет на шине с подтяжками раскорячиться.
Судя по схеме Вектора, на шине данных нет подтягивающих резисторов.
Судя по схеме Вектора, на шине данных нет подтягивающих резисторов.
А разве R8, R6, R4, R78, R7, R75, R77, R3 в правом верхнем квадранте рядом с D9 -- это не они?
А разве R8, R6, R4, R78, R7, R75, R77, R3 в правом верхнем квадранте рядом с D9 -- это не они?
Они на шине "ВУ", между ними и процессором стоит ВА86.
Они на шине "ВУ", между ними и процессором стоит ВА86.
Да, правда.
Improver
30.06.2022, 18:06
Они на шине "ВУ"Они не только для шины ВУ, микросхемы памяти ещё нуждаются в подтяжке, насколько я помню.
А я думал, что основная задача этих резисторов - дать FF на шину данных при генерации прерывания.
- - - Добавлено - - -
микросхемы памяти ещё нуждаются в подтяжке
Как понимаю речь о РТ5, у которых ОК, это да. Но могу поизворачиваться, что когда меняют пзу на микросхемы с третьим состоянием, то резисторы оставляют, а если их убрать то не будет FF при входе в прерывание.
Improver
30.06.2022, 19:40
ivagor, да, я про рт5, в стандартной схеме Вектора... И для FF на прерывании и запросам к отсутствующим внешним устройствам, безусловно.
TomaTLAB
30.06.2022, 22:16
Судя по схеме Вектора, на шине данных нет подтягивающих резисторов. Да, пардон, у Вектора там в этом месте только с HiZ концы сходятся. TXB пойдет, заодно будет BusKeeper'ом и не даст шине в чистом HiZ болтаться. Хотя, исходя из принятого положения, что на неактивной шине должно быть FF, логичнее все же TXS.
- - - Добавлено - - -
А я думал, что основная задача этих резисторов - дать FF на шину данных при генерации прерывания. Ну не только. Болтающаяся в HiZ шина потенциальный источник неприятностей. Дубовые TTL входы ее, конечно, к единице когда нибудь притащат, а ну как таковых на ней не окажется :)
Да, пардон, у Вектора там в этом месте только с HiZ концы сходятся. TXB пойдет, заодно будет BusKeeper'ом и не даст шине в чистом HiZ болтаться. ...
Не понимаю о чём речь.
Когда проц настроен на вывод по ШД, он командует уровнями, когда он переходит в режим чтения, то сигналом "DBIN" меняет направление передачи у ВА86, и тот подаёт инфу на ШД процессора с "внешних" источников.
Ни какого "чистого HiZ", нет ни в какой момент времени (кроме переходных процессов) на ШД подключенной к процессору. С обратной стороны ВА86, да, но там и резюки-подтяжки есть, для описанных ситуаций, типа вектора прерывания и отсутствия устройства с которого запрашивают данные.
- - - Добавлено - - -
А если использовать TXS, то нужно предусмотреть для неё обвязку из резисторов подтяжки (ведь выяснили, что в схеме их нет) ?
Со стороны ПЛИС понятно, там свои включить можно, а со стороны платы, скорее всего, не стоит надеяться только на входы TTL?
TomaTLAB
01.07.2022, 14:28
А если использовать TXS, то нужно предусмотреть для неё обвязку из резисторов подтяжки А внутре нее неонка подтяжки :)
- - - Добавлено - - -
(кроме переходных процессов) про них, родимых, и речь... Баскиперы и активные терминаторы не зря придумывали.
580-ой серии может и фиолетово (а может и не совсем), а вот шустрой плисине "висящий в воздухе" вход может очень не понравится (ну у нее-то, правда, и баскипер и подтяжку можно включить).
Вспомнил я про signal tap. Логический анализатор - это очень хорошо, но в данном случае для начала и сигнал тапа хватило бы, чтобы увидеть что там творится с обменом с памятью и портами. Предвижу возражение "это сложно" с которым не могу согласиться. По крайней мере мне объяснение svofski в свое время позволило начать пользоваться, глаза боятся, а руки делают.
Похоже TXB не катит.
Вывел на сканер, для сравнения, одновременно шину данных с ПЛИС и с разъёма ВУ.
Шина данных ПЛИС - сплошной шум.
Отключил разъём шины данных, от DIP-40 - шина данных ПЛИС сразу успокоилась.
Вот зараза...
Для экспериментов (с ПЛИС) использую .02-ой (у него с завода проц в панельке), и совсем из головы вылетело, что у него, во время активности ПЗУ загрузчика, от процессора отключается шина данных разъёма ВУ. :( Сканер не видит, что у процессора на ШД происходит. Снова нужно мозги включать...
Не помогла простая замена TXB на TXS.
Шума на ШД конечно стало немного меньше, и даже появились проблески попыток читать программу из ПЗУ. Но процесс быстро крашится.
Надо экспериментировать с резисторами подтяжки.
Резисторы подтяжки 10К на стороне 5В шины - почти не повлияли. Если и стало лучше, то не значительно.
Попробовал подключить pull-up резисторы на ПЛИС, по инструкции в статье "марсоход"... не знаю, что получилось, но стало совсем плохо... т.е. вообще.
Как или где в квартусе можно увидеть, что pull-up резисторы подключены к пинам?
Я имею в виду RTL-вьювер или ещё где?
Если не разберусь с ПЛИСовскими pull_up, буду перепаивать переходник на микросхему с переключением направления шины.
Не стал я разбираться с pull-upами...
Припаял на ШД LVX4245, управление направлением завёл с DBIN.
Поиграл немного в "LODE RUNNER" который для КД.
Думаю если такая игрушка работает, то скорее всего можно считать, что ПЛИС-vm80a на Векторе завёлся.
Присоединяюсь к поздравлениям!
LODE RUNNER активно использует кваз (причем улучшенный), но только в режиме адресности. Желательно и стеком погонять, или тесты или например ROBBO-AT (https://zx-pk.ru/threads/8394-kartoteka-po-dlya-vektora-06ts.html?p=1155475&viewfull=1#post1155475)
LODE RUNNER активно использует кваз (причем улучшенный), но только в режиме адресности. Желательно и стеком погонять, или тесты или например ROBBO-AT (https://zx-pk.ru/threads/8394-kartoteka-po-dlya-vektora-06ts.html?p=1155475&viewfull=1#post1155475)
Гонял несколько тестов КД.
Только "Дождь" давал хаотичные, каждый раз разные ошибки на КД с доработкой Баркаря (так совпало).
КД без доработки на всех тестах (в том числе "Дождь") проходит без нареканий.
Сейчас повторно запустил "Дождь" на КД с доработкой Баркаря, выставил напряжение питания Вектора 4.95 (попугаев по цифровому вольтметру) - тест "Дождь" крутится довольно долго, ошибок нет.
Но я в "Дожде" не виду сколько циклов теста прошло. Не наглядный тест, кроме времени с начала запуска, ни чего не меняется.
- - - Добавлено - - -
После 40-ка минут тестирования "Дождём", появились ошибки. :(
Дождь тестирует сугубо стеком. Можно попробовать старый прием - немного задержать внутренние тактовые плисового проца относительно F1 (конкретную длительность задержки надо подобрать). И чтобы не ждать 40 минут немного уменьшить напряжение.
Дождь тестирует сугубо стеком. Можно попробовать старый прием - немного задержать внутренние тактовые плисового проца относительно F1 (конкретную длительность задержки надо подобрать). И чтобы не ждать 40 минут немного уменьшить напряжение.
Как ни странно, в тех тестах, при понижении питания до 4.95, КД продержался 40 минут, а при 5.05V "Дождь" сыпал ошибки практически сразу.
Попробую двигать F1, F2.
Дождь тестирует сугубо стеком. ...
А разве можно протестировать КД целиком, не пользуясь стеком? Ведь ОЗУшный доступ возможен только к части адресного пространства, любой тест КД будет тестировать стеком, разве нет?
Может разница в выборе режима доступа к КД?
А разве можно протестировать КД целиком, не пользуясь стеком?
Нельзя, но на мой взгляд тест кваза должен сочетать проверки стеком и адресностью.
Нельзя, но на мой взгляд тест кваза должен сочетать проверки стеком и адресностью.
Чем-то алгоритм "Дождя" отличается от алгоритмов других тестов КД, так как другие проходят без ошибок, а "Дождь" чёто находит... и это скорее всего не связано с отсутствием ОЗУшного тестирования КД в "Дожде".
Любопытно, что на КД, который тестируется без ошибок всеми тестами (в том числе с ПЛИС-процессором), есть "565РУ" и с двумя, и с тремя "точками".
А на КД, который глючит, все микросхемы 565РУ только с двумя "точками".
Чем-то алгоритм "Дождя" отличается от алгоритмов других тестов КД
От каких именно других тестов? Надо посмотреть, сравнить.
Дождь работает примерно так:
1. Формирует в основном озу паттерны
2. Переписывает их в кваз
3. Читает из кваза и сверяет с паттернами в основном озу
4. По ходу тестирования паттерны меняются
Это еще немного и тест основного озу.
Задержка внутренних клоков плисового проца совсем не помогает (может становится хуже)? В каких пределах пробовал задерживать, 10-20-40-80-... нс?
От каких именно других тестов? Надо посмотреть, сравнить.
Дождь работает примерно так:
1. Формирует в основном озу паттерны
2. Переписывает их в кваз
3. Читает из кваза и сверяет с паттернами в основном озу
4. По ходу тестирования паттерны меняются
Это еще немного и тест основного озу.
Задержка внутренних клоков плисового проца совсем не помогает (может становится хуже)? В каких пределах пробовал задерживать, 10-20-40-80-... нс?
Не вижу проблемы, обращение к стеку - "оно и в Африке" обращение к стеку... Но именно Дождь, ошибки вылавливает.
Предполагаю только одно возможное отличие, это режим КД.
Что-то там было, что если КД включен как ОЗУ, то и стековые операции идут в КД.
Судя по схеме, если КД настроен как ОЗУ, то БЛК должен вырабатываться уже при появлении нужного адреса.
А вот если КД настроен только как "стек", то БЛК вырабатывается синхронно с сигналом "Стек".
Может в этом загвоздка...
Других объяснений не могу найти.
Двигать F1 и F2 пока не успел. Делал дебаг конструкцию, для управления фронтами по СОМ-порту, и свет вырубили на весь вечер...
Буду двигать F1 и F2, сразу и на положение сигнала стек гляну, сравню при реальном проце и с ПЛИСом.
Improver
05.07.2022, 17:01
А вот если КД настроен только как "стек", то БЛК вырабатывается синхронно с сигналом "Стек".
Может в этом загвоздка...Большая часть КД доступна только как стек, так что если бы в этом была проблема, то ошибки вылезали бы и на других тестах. Более вероятен такой вариант: из-за того, что "Дождь", из описания выше (https://zx-pk.ru/threads/34449-vektor-06ts-580khkh-na-plis.html?p=1157518&viewfull=1#post1157518), на КД пишет сразу блоками, а потом также читает, возможно сбой вызывает именно частое последовательное повторение PUSH (или POP).
Я припоминаю, что для отладки шадков писал свои маленькие тестики кваза -- потому что выуживал разные частные случаи. Но по-моему у меня никаких записей этого не сохранилось.
Improver
05.07.2022, 18:16
Я припоминаю, что для отладки шадков писал свои маленькие тестики квазаАналогично писал тесты для нового старого квазидиска, все можно найти в соответствующей теме, вот тут и немного ранее (https://zx-pk.ru/threads/29342-novyj-staryj-kvazidisk.html?p=988970&viewfull=1#post988970).
Тесты КД, которые запускаются из под МикроДоса?
Improver
05.07.2022, 21:01
Тесты КД, которые запускаются из под МикроДоса?Из под монитора-отладчика, из под микродоса не получится протестировать, т.к. в процессе данные с КД удаляются.
Из под монитора-отладчика, из под микродоса не получится протестировать, т.к. в процессе данные с КД удаляются.
Ясно, поэтому у файла теста такое расширение ".m01".
Пробовал "двигать" спад F2.
Укоротил F2 на ~20нс - ошибки появились через 5 минут "Дождя".
Увеличил длительность F2 на ~26нс (от нормы) - 35 минут тестировался без ошибок.
Смещение фронтов сканером пока не фиксировал.
Сканером ВУ много раз сканировал (со стандартными F1 и F2) процесс тестирования КД "Дождём" и с реальным процессором и с ПЛИСовым, визуально графики ни чем принципиально не отличаются. Конечно я не могу быть уверенным, что ловил момент сбоя. Даже скорее всего не ловил. Но так как сбои КД не постоянные, не представляю, как сканером выловить подобный момент, так как не известны признаки.
Не могут быть отличия во фронтах из-за различий в нагрузочной способности? Переходные процессы занимают разное время, вот и сместились на десяток нс тут, десяток там. К замерам, даже очень аккуратным, это тоже относится.
А я бы поставил на величину запаздывания управляющих сигналов относительно клоков. У быстрых 8080 это запаздывание меньше, чем у медленных и это может приводить к отличиям в работе в составе компа. На а у плисового vm80a с pin_clk=100 МГц наверняка эти запаздывания меньше чем у самых быстрых 8080.
Не могу найти в ядре vm80a процессы, которые могли-бы реагировать на спад F2.
Т.е. от длительности F2 ни чего не должно зависеть.
Вот фронт F2 вроде должен формироваться уже после прихода внешнего "READY".
Т.е. положение фронта F2 - критично, а спада вроде как нет...
Я говорю о внутреннем F2, который я эмулирую для ядра.
Там много мест, где важно текущее значение f2, а значит и положение и длительность f2.
Там много мест, где важно текущее значение f2, а значит и положение и длительность f2.
Это понятно, но при clk = 100МГц, думаю эти always-ы успевают за один f2 выполниться несколько раз.
Пока не разобрался, важно-ли только первое срабатывание, или за один f2, каждый "posedge clk" в одном always происходит что-то новенькое...
при clk = 100МГц, думаю эти always-ы успевают за один f2 выполниться несколько раз.
И поэтому важно текущее значение f2
за один f2, каждый "posedge clk" в одном always происходит что-то новенькое
конечно так
...
конечно так
Тогда нужно точно знать, сколько должно быть "posedge clk" за время пока f2 находится в "1".
Проблема в том, что за один f2, который является enable, проскакивает несколько posedge clk? Наверное это можно решить добавив еще один сигнал, который по posedge clk и f2 сделает disable. Но его тоже надо как-то сбрасывать. В общем это та еще возня ;)
Пытаюсь разобраться в эмуляции на плисе "580vm80a" и что-бы хоть что-то в ней найти, ещё и пытаюсь экспериментировать с modelsim...
Написал программку в несколько строк, скомпилировал для проекта "580vm80j", всё остальное в архиве уже есть для симуляции в modelsim.
Сам проект "vm80" без изменений, заменил только код программы выполняемой процессором при симуляции.
Запускаю, разглядываю графики, и ни как не могу понять, почему после команды 05h - "dcr b", на шину адреса попадает состояние регистровой пары "BC"...
Скриншот в прицепе.
С моей точки зрения, при выполнении команды "dcr b", значение пары "ВС" не должно попадать на шину адреса... или я что-то не понимаю?
А после команды 23h - "dcx h", на шину адреса вылазит значение пары "DE" (предположительно).
https://disk.yandex.ru/i/el8u23GE4oYNmg
А по какому признаку определяется валидность адреса на шине? Я позабыл. По идее все время, пока этого признака нет нет, там может быть любой мусор. А в этих процах все кишками наружу торчит.
Проверить, не попадает ли на ША содержимое регистровых пар сравнительно просто, например так
loop:
lxi d,0123h
lxi h,4567h
lxi b,89ABh
lxi sp,CDEFh
dcx b
lxi d,1230h
lxi h,5674h
lxi b,9AB8h
lxi sp,DEFCh
dcx b
jmp loop
Если мне не изменяет память, для декремента/инкремента регистровых пар используется то же исполнительное устройство, что и для PC, возможно это сказывается.
Особого криминала на временной диаграмме не видно, когда на ША "странные" адреса сигналы чтения и записи не активны.
В модуле процессора нашел вот такие стоки:
module vm80a(
...
assign mxwadr = t3363 | (t4f1 & ~id_dad & ~id_hlt);
...
always @ (posedge clk)
if (f2)
begin
if (mxwadr) a <= mxo;
...
mxo - содержит значение регистровой пары с которой, в данный момент, идет работа.
Приведённый кусок фактически говорит, что на каждом 4-ом такте, на шину адреса выкидывается содержимое текущей регистровой пары.
А 4-ый такт в моей тестовой проскакивает часто, включая команды: inx h\ inx d\ dcr b.
Посмотрел свои старые сканы ВУ, сделанные с настоящим процессором и с ПЛИС-вариантом.
ШАВВ идентична, а так как она часть шины адреса процессора, то можно считать, что и у настоящего процессора на ША выкидываются "потроха"...
Но когда совместил графики сканов ПЛИСа и реального процессора в одной анимации, то обнаружил интересную фишечку...
У ПЛИС-процессора изменения ШД, ШАВВ, ЧТЗУ - происходят по фронту CLK (6МГц), а у реального процессора - по спаду.
анимация сканов - https://disk.yandex.ru/i/QvpWt2JQWRtFsw
Пока все же остаюсь при старом мнении, что
величину запаздывания управляющих сигналов относительно клоков. У быстрых 8080 это запаздывание меньше, чем у медленных
На а у плисового vm80a с pin_clk=100 МГц наверняка эти запаздывания меньше чем у самых быстрых 8080
Что-то я не совсем понимаю, вернее совсем не понимаю, как такое происходит...
Есть always, в котором регистру "acc" передаётся значение регистра "d".
always @(posedge clk)
begin
if (f2)
begin
if (alu_xwr) xr <= id_rst ? (i & 8'b00111000) : d;
if (alu_awr) acc <= d;
...
Судя по всему acc должен получить новое значение при "posedge clk" и "f2==1" и "alu_awr==1".
Но судя по графику ModelSim, "acc" меняет своё значение при "f2==0".
Инверсии "f2" в коде я не заметил.
Что я упускаю?
Запутался ещё больше.
Все процессы происходят при "инверсных" значениях сигналов "f1" и "f2", если верить графикам ModelSim.
Нужно сначала искать, где они инвертируются, в коде или при выводе в график.
Если в коде нет ветки else, то можно считать else acc <= acc;. Почему ModelSim решил показывать значение acc именно с этого posedge clk, знают только его разработчики. В принципе, если acc нигде больше не инициализируется, там должен быть мусор уже после первого posedge clk.
Если в коде нет ветки else, то можно считать else acc <= acc;. ...
В принципе, если acc нигде больше не инициализируется, там должен быть мусор уже после первого posedge clk.
Можно считать, что acc больше ни где не инициализируется. В соседней строке кода есть ещё один IF, в коде так:
...
if (alu_awr) acc <= d;
if (alu_ald) acc <= s;
...
Но второй IF в моём случае срабатывает значительно позднее.
А мусор в асс и есть до указанного момента, т.к. до него не было операций с аккумулятором.
Но второй IF в моём случае срабатывает значительно позднее.
Нельзя сказать "срабатывает". Регистр, в котором хранится acc, будет обновляться при каждом posedge clk (в таком варианте кода). Значение на входах регистра, если присутствует if, формируется при помощи мультиплексоров, а входы мультиплексоров в любом случае куда-то подключены. Если нет ветки else, то соответственно к выходу регистра acc.
- - - Добавлено - - -
Данный код:
...
if (alu_awr) acc <= d;
if (alu_ald) acc <= s;
...
не содержит синтаксических ошибок, но тут не определён приоритет alu_awr alu_ald. Можно, конечно, надеяться, что приоритет последнего if выше, и код будет соответствовать следующему:
if (alu_ald) acc <= s; else if (alu_awr) acc <= d; else acc <= acc;
Нельзя сказать "срабатывает". Регистр, в котором хранится acc, будет обновляться при каждом posedge clk (в таком варианте кода). ...
Да, я понимаю.
Я имел в виду, что значение "alu_ald" на изучаемом участке графика всегда равно "0", и код второй строки не выполняется в изучаемом интервале времени.
Подозреваю, что сигналы alu_awr и alu_ald ни когда не пересекаются. Так как отвечают за обозначение активности разных групп команд, первая активна при выполнении операций с памятью (при чтении/записи), вторая в момент выполнения арифметических операций:
assign alu_ald = t2222 & ( id_adc | id_add | id_daa | id_xra | id_sbb | id_sub | id_ana | id_ora | id_sha | id_cma);
По крайней мере, у меня создалось именно такое впечатление.
Но это уход в сторону от вопроса, почему в "асс" значение меняется не в ту фазу "f2".
До меня только недавно дошло, что частота clk = 50MHz, а частота "f1" и "f2" = 25MHz.
Если получится, попробую сначала в симуляторе снизить частоту f1 и f2, что-бы иметь графики, более приближенные к реальности.
почему в "асс" значение меняется не в ту фазу "f2"
На графике как раз видно, что асс меняется на 0 чуть раньше, чем ты поставил вертикальную линию, как раз по posedge clk (tb/clk), а в предыдущем клоке alu_awr установилось в 1.
На графике как раз видно, что асс меняется на 0 чуть раньше, чем ты поставил вертикальную линию, как раз по posedge clk (tb/clk), а в предыдущем клоке alu_awr установилось в 1.
Вертикальную линию поставил не я, а ModelSim, который формировал график.
Мне нравится, что acc меняется по posedge clk, к этому я претензий не имею.
Но на графике видно, что когда происходит "posedge clk", и асс меняется, f2==0 - что не соответствует коду.
Так как ветка в которой: "acc <= d", находится в ветке: "if (f2)" - и не должна работать, т.к. f2==0.
Вот это меня и смущает.
Ладно.
Сначала попробую уменьшить частоту сигналов f1 и f2, а потом снова буду смотреть графики... вполне возможно, что там будет ещё больше "чудес"...
Ну вот...
Модифицировал эмуляцию.
Влепил clk=100MHz (как в проекте, залитом в ПЛИСину), выставил длительности f1 и f2, приближенные к реальным (с интервалами между ними).
И сразу стало видно, какие сигналы меняются по переднему фронту f1, какие по переднему фронту f2.
И асс стал меняться как ему положено, при f2==1 (типа по переднему фронту).
Уже съедобные графики получились, можно дальше "ехать"...
Тестирую "хотелки" пока только на ModelSim-е...
Удалось упаковать 4 команды:
ldax d
mov m,a
inx d
inx h
в одну: "ldmi" - копия байта из (de) в (m) с инкрементом указателей.
При этом аккумулятор пока не используется и его значение не "портится".
Команда выполняется в ModelSim за 10 (4,3,3) тактов, предполагаю, что на Векторе будет выполняться за 12 тактов.
Не очень удобно, что в проекте "580vm80j" обозначение регистровых пар HL и DE - перепутаны :( сбивает с толку маненько...
Как посмотреть, xchg же их меняет (перекоммутирует)
Как посмотреть, xchg же их меняет (перекоммутирует)
Не, тут другое.
Например, выполняется команда: lxi d,0x0024 (11 24 00)
При этом 0x0024 записывается в регистр с именем "hl".
Соответственно, когда выполняется команда: lxi h,0x0024 (21 36 00)
значение 0x0036 записывается в регистр с именем "de".
Немного покумекал... сейчас одна команда выполняет функцию:
ldax d (без сохранения в аккумуляторе, читаем в "di")
mov m,di
inx d
inx h
dcr a
Регистр "di" штатно используется в процессоре, например в командах "mvi m,D8".
Тут ничего нагромождать не пришлось.
Для зацикливания достаточно:
adr: ldmi
jnz adr
Осталось разобраться, как "рс" вернуть назад на один адрес.
Например, выполняется команда: lxi d,0x0024 (11 24 00)
При этом 0x0024 записывается в регистр с именем "hl".
Соответственно, когда выполняется команда: lxi h,0x0024 (21 36 00)
значение 0x0036 записывается в регистр с именем "de".
Дальше добавляем xchg и еще раз lxi d, и lxi h,
Дальше добавляем xchg и еще раз lxi d, и lxi h,
А для чего это делать?
Вроде симулируется так как хотел.
Одна команда "ldmi" (за 10/12 тактов на байт/цикл) выполняет функцию:
adr: ldax d (без сохранения в аккумуляторе, читаем в "di")
mov m,di
inx d
inx h
dcr a
jnz adr
Нужно загонять в ПЛИС и тестить на разных старых программах для проверки совместимости.
А потом тестировать новый алгоритм вывода спрайта на экран.
Тест на реале показал, что моя доработка пока не совместима с командой "xchg".
Нужно разбираться.
Но если xchg не применяется, то в остальном пока тесты проходят.
В старый тест вывода спрайта (24х24 пикселя 3 плана) разными методами, добавил алгоритм с новыми командами.
https://disk.yandex.ru/i/o7WYXww9DNrz6A
Результаты "ЕВВ4" - это заглушки, так как в подпрограммах использовались xchg.
Получилось $27cd - 10189 выводов спрайта 24х24х3 за 10 секунд, это примерно 20 спрайтов за интервал между прерываниями.
Стек при выводе спрайта не используется, прерывания разрешены.
Для вывода спрайта используется аккумулятор и пары HL с DE.
Графики ModelSim показывают, что проблему с "xchg" удалось обойти.
Дело за тестами с ПЛИС на реальном Векторе.
На Альтеровской девборде с модифицированным vm80a, запустил тест скорости вывода спрайтов.
Алгоритм с моими командами копирования показал 27F8h = 10232 спрайта за 10 секунд, 20 спрайтов за одно прерывание.
https://disk.yandex.ru/i/K-VdzcM1NgSVmA
- - - Добавлено - - -
Подозреваю, что вставить в ПЛИС-процессор математику, ещё проще.
Нужно только разобраться как организовать чтение кода команды состоящего из двух байт (как у Z80), а не из одного как обычно.
Что-то я большего ускорения ожидал :(
Перелопатил тест скорости вывода ч/б текста в режиме 512*256, 80 символов в строку.
Получилось вот это, на фото.
https://disk.yandex.ru/i/Y-qN2o1AyyMDpQ
"Y" - успел вывести только в одну плоскость.
Фонты 8 байт на символ, горизонтально, одинаковые как для режима 256х256, так и для 512х256.
Предсдвиговых таблиц нет, проц сам сдвигает и маску накладывает.
Малость разочарован.
Если говорить о задаче вывода спрайтов (и тайлов) на экран, то стоит оценить предельный возможный вариант.
...
2. Частичный разгон ядра 8080. Можно реализовать вывод спрайтов программно, но нужно некоторое количество быстрого озу внутри проца (или кеш). С этим озу проц пусть работает на 48 или 96 МГц, а снаружи опять видны только пересылки байтов.
...
Есть какие-то стандарты по работе со спрайтам?
Типа как/какие характеристики спрайта указывать, в каком формате загружать?
Хочу попробовать загрузить спрайт 8х8х4 в М9К ПЛИСа.
Нужно ещё разобраться, как это всё отреагирует на запрос прерывания, во время выполнения такого безобразия...
По стандартам сложный вопрос. Можно сказать, что их нет, но более конструктивным будет ответ, что их определяют разработчики игр. Вспомним, кто делал последние игры - metamorpho и сейчас parallelno. В Binorum были спрайты без маски, можно сказать просто тайлы, в GameNoName - с маской.
Сам я игрушки с нуля делал только в юности, потом понял, что я не игродел и только участвовал в портировании, в первую очередь с msx. У msx есть свой стандарт представления спрайтов (даже два, если не ограничиваться первым msxом). Т.е. по оптимизации вывода специальновекторовских спрайтов - к игроделам, а я могу сравнительно квалифицированно сказать, что нужно для упрощения и улучшения конверсий с msx, но тут мы возвращаемся к тому, что я уже писал. Задача комплексная, если не ограничиваться какой-нибудь одной демонстрационной программой, то нужна не только реализация в плисе, но и поддержка эмуляторов и средств разработки. При таком подходе мне (повторюсь) кажется более-менее реалистичным вариантом только z80, при всех его недостатках. А если ограничиваться одной демкой, то надо делать так, как самому нравится и удобно. Это не совсем умозрительные рассуждения, у меня были попытки наворотов (к v06cc), например 256 цветов, но все закончилось на одном тесте, в эмуляторы не пытался добавить, кучу программ под это не написал.
...
При таком подходе мне (повторюсь) кажется более-менее реалистичным вариантом только z80, при всех его недостатках.
...
Т.е. речь о реализации в ПЛИС "векторовского контроллера z80" с самим z80. Типа проц z80 с распиновкой i8080 ?
Типа проц z80 с распиновкой i8080 ?
Да, именно так. Вопрос в том, заработает ли в реальном векторе ядро T80 (для начала в режиме 8080). В рамках v06cc я включал z80 просто изменением одной настройки (Mode), шина оставалась 8080 и все работало. Для реала, как мне представляется, придется доработать только один момент - адресацию портов, продублировав в верхней половине ША нижнюю половину.
Прикинул, если упаковать в одну команду вывод одного спрайта на экран, то даже для вывода одного спрайта 8х8х4, потребуется порядка 260 тактов...
А если верить даташиту i8080, то проверка запроса прерывания происходит в последнем цикле каждой команды.
Значит, скорее всего при выполнении такой "модифицированной" команды (вывода спрайта одной командой), запрос на прерывание скорее всего будет потерян. Что не есть зер гуд... :(
если верить даташиту i8080, то проверка запроса прерывания происходит в последнем цикле каждой команды.
Так там и нет команд вывода спрайтов. А при реализации в плис никто не может помешать проверять запрос прерывания например после каждой записи байта в память.
- - - Добавлено - - -
Насчет потери прерываний. Насколько я понимаю схему вектора, там ничего не потеряется, даже если будет команда на 20000 тактов. Другое дело, что к тому времени пройдет интервал пригодный для всяких темных делишек типа опроса клавиатуры и программирования палитры, скорее вот это ограничивающий фактор.
... при реализации в плис никто не может помешать проверять запрос прерывания например после каждой записи байта в память.
...
Я об этом думал. Но не уверен, что после возврата из прерывания удастся вернуть состояние всех потрошков в тот вид, который был у них в момент прерывания процесса. Для модификации команд ведь приходится, что-то "корявить". В Векторе вроде нет специальной команды, которая завершает прерывание. А если в программе используется для этих целей не просто "ret", а "pchl" к примеру... тогда понять, что нужно вернуться к продолжению прерванной операции, будет ещё сложнее, если вообще возможно.
не уверен, что после возврата из прерывания удастся вернуть состояние всех потрошков
Это не техническая сложность, не принципиальная проблема, это вопрос аккуратной разработки. Адрес откуда читаем (или два адреса, если графика и маска отдельно), адрес куда пишем, счетчик. Приход прерывания во время такой долгой команды должен приводить к помещению в стек ее (этой команды) адреса, состояние регистров - как обычно, если обработчик прерывания корректный, то он сохраняет то, что сам меняет. И возврат приведет к корректному продолжению.
Это не техническая сложность, не принципиальная проблема, это вопрос аккуратной разработки. Адрес откуда читаем (или два адреса, если графика и маска отдельно), адрес куда пишем, счетчик. Приход прерывания во время такой долгой команды должен приводить к помещению в стек ее (этой команды) адреса, состояние регистров - как обычно, если обработчик прерывания корректный, то он сохраняет то, что сам меняет. И возврат приведет к корректному продолжению.
Не совсем так.
Возврат из прерывания это команда, когда она закончится, процессор должен будет прочитать новую команду, а как ему объяснить, что команду вот именно сейчас читать не нужно, что она уже выполнялась, и что её нужно просто продолжать выполнять, причём с определённого места.
В крайнем случае. Можно подумать о дополнительном флаге (для модифицированной команды) выполнения команды. Если модифицированная команда читается, но флаг был не сброшен (предыдущим штатным окончанием выполнения этой команды), значит её выполнение было прервано, и нужно продолжить выполнять с текущего состояния счётчиков. А "РС" держать с самого начала на повтор этой команды, и только после успешного окончания переводить его на следующую команду.
Нужно перевариваь...
Возврат из прерывания это команда, когда она закончится, процессор должен будет прочитать новую команду, а как ему объяснить, что команду вот именно сейчас читать не нужно
Я описал вариант, при котором ничего ему не надо специально объяснять. Он после прерывания читает команду "как в первый раз", но в регистрах уже текущие значения, поэтому продолжит выполнять дальше. Т.е. выполнение команды разобьется на две части - до прерывания и после.
Я описал вариант, при котором ничего ему не надо специально объяснять. Он после прерывания читает команду "как в первый раз", но в регистрах уже текущие значения, поэтому продолжит выполнять дальше. Т.е. выполнение команды разобьется на две части - до прерывания и после.
Я прикидывал, что именно в первом цикле команды, когда считывается код команды, происходит инициализация (дополнительных счетчиков, флагов, признаков), и чтение характеристик спрайта.
Если выполнение команды, разрывалось прерыванием, и после возврата из прерывания, снова выполнится чтение кода команды, то без дополнительного указателя, снова произойдёт инициализация вывода спрайта, только уже в новых адресах, в текущих указателях hl, de, bc.
Когда речь пошла о команде, то я воспринял это примерно как навороченный LDIR с соответствующими выводами.
Если речь скорее о "DMA-сопроцессоре", у которого есть свои регистры, то это другое дело и тут возможны варианты:
1. Шина делится между ядром 8080 и "копперо-блиттером" в каком-то соотношении. Например пополам, или 1:2 и т.д. В этом случае 8080 и сопроцессор работают параллельно и никаких специальных изобретений не нужно. Процессор выполняет свою программу и штатно обрабатывает прерывания. А сопроцессор пересылает свои байты.
2. Необходимость в каких-то уникальных придумках возникает, если выделять сопроцессору всю шину на время его работы и вдобавок еще требовать обработки прерываний ядром 8080. Вот тут да, нужно вводить некую специальную команду (или специальный порт), чтобы дать знать сопроцессору, что обработчик прерывания закончился и сопроцессор может продолжать.
Когда речь пошла о команде, то я воспринял это примерно как навороченный LDIR с соответствующими выводами.
Ну, подобие LDIR я первым делом реализовал. Выше скриншот теста скорости вывода спрайта 24х24х3 это именно с этой командой.
Если речь скорее о "DMA-сопроцессоре", у которого есть свои регистры, то это другое дело и тут возможны варианты:
1. Шина делится между ядром 8080 и "копперо-блиттером" в каком-то соотношении. Например пополам, или 1:2 и т.д. В этом случае 8080 и сопроцессор работают параллельно и никаких специальных изобретений не нужно. Процессор выполняет свою программу и штатно обрабатывает прерывания. А сопроцессор пересылает свои байты.
2. Необходимость в каких-то уникальных придумках возникает, если выделять сопроцессору всю шину на время его работы и вдобавок еще требовать обработки прерываний ядром 8080. Вот тут да, нужно вводить некую специальную команду (или специальный порт), чтобы дать знать сопроцессору, что обработчик прерывания закончился и сопроцессор может продолжать.
Варианты с DMA я пока морально не готов рассматривать.
Предполагался некий вариант LDIR, который не ограничивается одним байтом за раз, а выполняется пока не обработает весь спрайт с учетом строения экрана Вектора. Это ускоряет процесс как минимум на 25-30%% , так как не требуется чтения кода команды, для обработки следующего адреса.
Но при этом возникают "заморочки" с прерываниями.
Пока отложу эту версию, до переваривания.
Решил сравнить в рамках вектора, что даст быстрое умножение шринклеру (на примере распаковки теста устройств). Для этого добавил в z80 (emu80) команду MULUW HL,BC из R800. Оригинальный распаковщик для z80 - 1 минута 11 секунд. Распаковщик для R800 (https://github.com/ivagorRetrocomp/DeShrinkler/tree/main/R800) - 25 секунд. Т.е. ускорение распаковки в 2.84 раза, при том что умножение быстрее более чем на два десятичных порядка (MULUW не стал тормозить до 36 тактов как в R800, сделал 8 тактов).
Как-то так получилось:
https://disk.yandex.ru/i/QVrF9rpCvF-VnA
96 символов, если не сбился.
Без использования стека.
Надо подумать над оптимизацией расчёта экранного адреса курсорной позиции символа.
Сейчас эти расчёты занимают больше времени, чем сам символ выводится на экран.
Как-то так получилось:
https://disk.yandex.ru/i/QVrF9rpCvF-VnA
96 символов, если не сбился.
Без использования стека.
По одной фотке не совсем понятно -- на что именно мы смотрим? Это работает ПЛИС-ный 8080 с какими-то дополнительными инструкциями?
Хороший результат, стоит посчитать и достижимый максимум. Пусть в символе 8 строк и шрифт хранится внутри ПЛИС, 2 Кб не так уж много. На одну строку 2 чтения и 2 записи VRAM. Плюс на каждый символ одно чтение кода символа. ((2+2)*8+1)*4=132 такта/символ, за прерывание 453 двухцветных символа в режиме высокого разрешения.
По одной фотке не совсем понятно -- на что именно мы смотрим? Это работает ПЛИС-ный 8080 с какими-то дополнительными инструкциями?
Да, инструкции читают, накладывают маску, складывают с данными спрайта, записывают обратно, сдвигают указатели.
Для упрощения, две инструкции. Одна со смещением указателей вверх, вторая - вниз.
- - - Добавлено - - -
Хороший результат, стоит посчитать и достижимый максимум. Пусть в символе 8 строк и шрифт хранится внутри ПЛИС, 2 Кб не так уж много. На одну строку 2 чтения и 2 записи VRAM. Плюс на каждый символ одно чтение кода символа. ((2+2)*8+1)*4=132 такта/символ, за прерывание 453 двухцветных символа в режиме высокого разрешения.
Намекаешь на эксперимент с разворачиванием всех циклов в линейный код?
Чтение кода символа в 1 цикл - это жесткач :) если учитывать, что даже "inr r" - это 8 тактов.
Единственный выход это типа "add a,r" - держать один регистр для "1".
Плюс смещение позиции на экране.
В одно знакоместо может и получится 453, но идентифицировать результат не получится.
Пардон, я привел расчет только для удобного случая. Для неудобных будет ((4+4)*8+1)*4=260 тактов. "Удобных" 6/8, неудобных - 2/8 (это если 80 символов в строке), поэтому 132*6/8+260*2/8=164 такта/символ в среднем. Уточненный максимум - 365 символов за прерывание.
- - - Добавлено - - -
Намекаешь на эксперимент с разворачиванием всех циклов в линейный код?
Это теоретический максимум исходя из пропускной способности шины. Способы достижения могут быть разные, например "высокоинтеллектуальный DMA-сопроцессор".
- - - Добавлено - - -
Если в плисине есть еще 16 Кб под копию VRAM, то убираем с внешней шины процессора чтение VRAM и получаем 713 символов/прерывание, это абсолютный максимум, быстрее не получится.
Хотелось развёрнутых циклов...
Распишитесь в получении:
https://disk.yandex.ru/i/_o63DMADDFux1A
Что тут... 225 символов получилось.
Это без модификации текущего ПЛИС.
Просто в тестовой программе, только вывод символов, без подпрограмм, ветвлений, проверок.
Минимальная обвязка только смещение координат на экране, увеличение кода символа.
Да, ещё, не стал в одну команду пикать вывод всего спрайта. Соответственно, выбрал самый затратный, но простой для реализации вариант - одна команда на один байт. Соответственно, только на чтение/запись одного символа тратится не 32 (или 64) цикла, а с командой 48 (или 96) циклов (если в подсчётах не ошибся).
Вот это уже серьезно, почти в 3 раза быстрее возможностей стандартного 06Ц.
- - - Добавлено - - -
Хотя так некорректно сравнивать, для измененного теста нет референсной скорости 06Ц. Скорее всего выигрыш будет заметно меньше.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot