EmuZGL alpha preview

[Higgins]

А где написано про задержки IR?

http://www.shadowmagic.org.uk/cssfaq...kreference.htm

Поищите строки, содержащие "ir:" (без кавычек).

Если рассуждать так, то во всех инструкциях, точнее, в циклах выборки опкода (я так понял, для инструкций без префикса 1 раз, а с префиксами - 2, в соответствии с числом изменений R), надо тогда pc:4 заменять на pc:3,IR:1. Так?

Нет, четыре такта -- чтение плюс такт на обновление памяти -- выполняются в любом случае. И даже если значение I лежит в диапазоне [0x40; 0x80), на четвертом такте задержки нет. А вот если цикл выборки длиннее этих четырех тактов, то на каждом дополнительном такте, начиная с пятого и до конца цикла, ULA будет взводить ~CLK, т.е. останавливать процессор. (Может показаться странным это особенное поведение T4 цикла выборки, но на самом деле все логично: этот такт начинается при низком уровне ~MREQ, который в течение такта поднимается, и на следующем такте ULA уже смотрит на адресную шину.)

Почему же это не описано, вероятно, только потому, что в случае I=$40..$7F оригинальный Спектрум нормально вообще не функционирует, и смысла в таком сочетании нет вообще, наверное?

Тот же Vectron использует это как визуальный эффект. Без всяких последствий.

(И тогда зачем эту ситуации вообще эмулировать, понта ради, что ли). Мне вот, к примеру, не хочется навешивать много кода, выполняющегося на каждой инструкции. Я жутко рад, что в режиме max speed можно быстро пробегать несущественные участки демок или rzx-записей (да и лента быстрее грузится), и каждая такая добавка ударяет по ускорению.

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

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

Для меня здесь критерием правильности является демка, BBG, кстати. Она идёт именно так, как должна идти, причём конкретно обнаруживается инструкция PUSH BC: на такте 14425 она началась (задержка 4), и только при исправлении выше для push прошло ровно столько же тактов, сколько показал отладчик спектакулятора. В итоге вывод: выборка может и 5-тактная, но ULA ловит адрес тогда на втором такте второго цикла, а не на третьем. Результат-то: BBG идёт, а без исправления - нет.

Даже не знаю как прокомментировать...

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

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

Здесь-то явно никаких IR задержек нет, иначе просто был бы снег на экране, все прочие вмешательства вроде погоды на Марсе исключены: одна инструкция PUSH BC, с точно известного такта, точно известна последовательность задержек с этого такта (43210065432100...), точно известно, что в итоге инструкция должна отработать за 16 тактов. Официальное решение, не признанное Джоном, гласит 5+3+4(задержка)+3=15, остаётся только решение 4+3+5(задержка)+4=16.

Задержек на IR нет.

Я приложил трейсинг пары рабочих фреймов теста BBG. Там же снапшот состояния, с которого трейсинг стартовал. Формат такой: до двоеточия стоит адрес инструкции, после двоеточия следует полный оп-код инструкции, в скобках указан номер такта во фрейме до исполнения инструкции.

Не забудьте пропустить первые фреймы синхронизации.

3 - это не задержка. Уравнение простое: известно, что инструкция обычно выполняется за 11 тактов. Для неё написано pc:4,pc+1:4,io. Вопрос, чему (обычно) равно io? 11-4=3. Я так полагаю, что если есть задержка, то она добавляется где-то на этих 3х тактах.

Я имел в виду, что задержки вывода в порт считаются по паттернам. Все эти паттерны подразумевают, что цикл вывода длиной в 4 такта.

Для проверки 48 я ещё использую KAZ6 и MEGACLR (ну полное угрёбище, даже звука нет, но важен бордюрный эффект), ну и конечно shock, без него оно никак, конечно.

За KAZ6 спасибо.

С MEGACLR странная история. На Higgins и Fuse в режиме 48K после загрузки черный экран без признаков жизни. На Fuse в режиме 128K прокручивает снизу вверх текст из цветных квадратов, без всяких бордюрных эффектов. По описанию ("угребище") -- похоже, но тем не менее.

Если попадётся, сообщу.

Да, пожалуйста.

Надо полагать, этот тест вообще ни на что не годится, с такими-то глюками.

На всякий случай дам ссылку:

http://www.worldofspectrum.org/forum...ad.php?t=20345

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

Попробовал убрать влажок H из инструкции AND. Тест на флаги это обнаружил, на остальных инструкциях ошибок не дал. Тест на MEMPTR тоже ошибок не дал.

Попробовал изменить вычисление значения MEMPTR для LDIR/LDDR чтобы прибавлял 2 к значению PC. Тест на флаги прошел без ошибок. В тесте на MEMPTR LDIR (BC > 1) и LDDR (BC > 1) дали ошибки, все остальные инструкции прошли без ошибок.

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

Ну, вам в помощи здесь никто не отказывает. А игрушка... не хуже других. ;-)

Вот здесь об этом ясно сказано, стр. 98-99, в описании команд LD A,I и LA A,R.
Как видно, с некоторых пор данное явление задокументировано официально (т.е. описано не как баг, а как особенности работы).

Минуточку. В этом документе сказано, что если была прервана одна из этих инструкций, т.е. прерывание было принято перед ее исполнением, то флаг P/V получит уже сброшенное значение IFF2. Более того, сайте WOS подчеркнуто, что это обстоятельство является следствием того факта, что прерывания начинаются со сброса IFF1 и IFF2. То есть это не то что на баг не похоже, это даже не особый случай.

А Владимир пишет совсем по-другому:

Или этот тест не учитывает баг в Z80 с установкой в флаге P/V значения 1, пока на вход ~INT активен (кроме случая, когда предыдущая команда была EI), независимо от значения IFF2.

А можно с этого места поподробнее? Т.е. Вы хотите сказать, что из-за цикла регенерации более одного такта процессор также задерживается? Хотелось бы прояснить эти тонкости. По WOS видно, что при циклах доступа к памяти Z80 более 3-х тактов - ULA 48k его задерживает и далее, считая каждый лишний такт доступом к той же памяти, вплоть до следующего цикла доступа к памяти; при этом циклы M1 неприкосновенны - присутствует лишь задержка непосредственно перед выборкой инструкции. Получается, и для M1 у ULA 48k есть некий лимит?

Обновление памяти -- это всегда только один такт в цикле выборки. Больше оно не длится. Но само значение IR остается на адресной шине. И пока I лежит за пределами области задержек, это не заметно.

На сайте WOS задержки на IR просто не учтены, M1 не является чем-то особенным с точки зрения ULA, если не обращать внимания на уровень ~MREQ в начале T4.