nedoPC.org

Спасибо - так бы не попробовал (доверился документации)!
Уткнулся в единственную известную ошибку https://github.com/gdevic/Z80Explorer/issues/1
(нужна гораздо более свежая версия qt, чем стоит, как буду обновлять систему, так попробую ещё).


Переписываемся; уже до авторов собственно эмулятора Z80 информация дошла.

С другой стороны, даже если с префиксом и без него !M1 действительно по-разному ведёт себя в 0xСВ - командах, это разница в пару логических элементов дешифратора.

Я из-за этого на днях Debian обновил до bullseye, после этого всё собралось.

Смотрю я на длинный ряд единичек в колонке m1 и думаю - ну не может же быть, чтоб тут ещё и прерывание могло сработать, это ж совсем бяка будет...


Вот не готов пока на такое действо - ни дома ни на работе... так-то оно запланировано на какие-нибудь небинарные выходные, но быстрее процессор на макетку припаяю с примерно таким http://www.nedopc.org/forum/viewtopic.php?p=83470#p83470 обвесом.

Не туда.

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

Касательно прерываний. Пару цитат.




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

Судя по документации-то так и есть (и там написано, что она неделимая не святым духом, а что после префиксов (и EI) на один такт блокируются прерывания); но опять же судя по документации, код команды со всеми префисами читается при активном !M1. И вот это место выглядит очень похоже на глюк - один внешний сигнал ведёт себя странно, близкие ему внутренние тоже могут вести себя странно (если довольно редкая команда читается без !M1, то и прерывания могут быть пропущены); в общем, попробую проверить на всякий случай при случае.

Тут как раз просто и понятно, а начало обработки прерывания легко можно отследить по запросу вектора (!M1 и !IOREQ).

Тут хуже - если нужно отследить, что вот прямо сейчас начало обрабатываться прерывание, то по сути надо ловить "the end of the current instruction".

Кто ПДП запросил, тот память и регенерирует; сложно представить, что процессор __всё равно__ будет лезть в память и регенерировать её не смотря на ПДП.

А как там сделано? Мои планы на ПДП начинаются и оканчиваются ВТ57 (на типа COVOX звук выдавать).

По прерываниям. Только так , и не как по другому. Иначе
По команде EI иметься ввиду следующие
Скорее не отследить, а подтвердить для периферии в фирменной схеме обработки прерываний от Zilog. И периферия может выставить на шину данных 8 битный вектор прерывания.
Самой схемы не существует. А подпрограмму переключения, пожалуйста.

Это уже от задачи зависит. Для маскируемых прерываний всё просто, а вот NMI сложнее.

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

Да что же там с NMI сложнее? Как его планируется использовать?

Вполне полное описание как оно работает.



По мне нормальное решение. Правда, запоздалое как минимум на лет 5-ть. А вот свой VDP они делали, не иначе как под забористой травой (личное суждение).

Да переключение полностью прозрачное для выполняемой программы, на лету. Один процессор стандартный Z80 (для совместимости), второй очень продвинутый R800 (на данный момент черный ящик).

Прочитал в соседней теме. Спрошу тут сразу. А чем стандартное решение не устраивает? Хоть от Intel (внешний контроллер прерываний), хоть от Zilog (встроенные контроллеры прерываний в комплект микросхем Zilog).

Снаружи чтобы отследить с точностью до такта первый ромбик следует наворотить кусок дешифратора команд - как минимум полный дешифратор префиксов. У маскируемого достаточно одного логического элемента. Цель одна - переключение страниц в MMU (потом распишу).



В соседней теме - внешний контроллер прерываний 580-й серии штука сложная, на 20 мГц не заведётся, а для "маргариткового венка" у меня нет комплекта микросхем Zilog. Конечно можно наворотить и на ПЛИС, и на AVR, но неспортивно.

Теперь стало понятнее. Отчего такой интерес.

Существует более простой вариант, если вам вдруг интересно:
http://www.nedopc.org/forum/viewtopic.php?f=81&t=10110&start=255#p124099

И там - еще есть далее по тексту:
http://www.nedopc.org/forum/viewtopic.php?f=81&t=10110&start=270#p124100

Довольно очевидное решение, но и с очевидной проблемой - при нескольких одновременно поступивших (по факту - накопившихся за время запрета прерываний) сигналов обработан будет только один (с максимальным приоритетом), остальные потеряются, а хочется-то чтоб отработали все с соблюдением очерёдности. Кроме того, для изменения приоритета прерываний придётся одновременно и перепаивать схему и переписывать программу (что может быть и не сильно страшно - зависит от задачи).

А моя идея подать сразу 7 сигналов (примерно так же, но без шифратора и в другом режиме прерываний) и уже только программой определять. Минус 1 сигнал, минус примерно с полкилобайта памяти, плюс обработка всех поступивших сигналов в порядке и плюс возможность управлять порядком без пайки.

Примерно к тому же пришли в той теме - viewtopic.php?p=158802#p158802

Про эмулятор http://www.visual6502.org/JSSim/expert-z80.html - если что, нашёл я причину ошибки:

файл http://www.visual6502.org/JSSim/chip-z80/support.js строка 630 (см. с отметкой +++++ ниже)

логично что никакого disassembly_ddfd тут быть не может, а должно быть

Поправил на лету (поставил breakpoint и присвоил disassembly_ddfd=disassembly_fdcb) - заработало; ну можно и локально на диск себе сохранить и поправить.

Напиши авторам

Написал сразу же, конечно. Но они __несколько__ небыстрые.