EmuZGL alpha preview

[Vladimir Kladov]

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

Добавлено через 2 часа 48 минут

как вы узнаете когда что-нибудь не будет работать именно по этой причине

Когда выясняется, что что-то не работает, изучаются конкретные причины. До сих пор срабатывало. А вот с задержкой по нечётным портам, раз они не влияют на мультиколорные демки, и не используется эффект в играх, то и смысла особого нет, разве что для куражу. Я эмулятор делаю, чтобы можно было поиграть и поработать, потому что эмуляторов, в которых можно поделать и то, и это, и при этом удобно, пока что нет, при том что число эмуляторов спектрума уже наверняка приблизилось к тысяче. Хорошо тем, у кого есть реал (и умение+желание с ним возиться). Но и реальщик оказывается часто в дурацкой ситуации: моделей куча, доработок и периферии ещё большая куча, всё себе навешивать - жизни не хватит. В эмуляторе можно побаловаться с возможностями, которых нет возможности привозможнить к своему реалу. А вообще, я эмулятор EmuZWin начинал делать исключительно по той причине, что все эмуляторы, с которыми я имел дело до этого, не умели нормально клавиши PC перенаправлять на клавиши/джойстики Спектрума. Хотя дело-то плёвое, но неудобно же - в одной игруле ZXQA1, в другой QAOPN, в третьей совершенно неудобный синклер джойстик или InterfaceII.

Попробую объяснить. В отличие от короткого цикла чтения в 3 такта, короткий цикл выборки инструкции (opcode fetch) занимает 4 такта. Чтение оп-кода происходит, тем не менее, на 3-м такте, как при обычном чтении. Четвертый такт нужен для обновления памяти: при выборке инструкции увеличивается R0:7 и пара IR кладется на адресную шину.

Я не схемотехник и не радиолюбитель и мне вообще непонятно, почему выборка из памяти занимает 3 такта. А где написано про задержки IR? Я что-то такого нигде не встречал. Если рассуждать так, то во всех инструкциях, точнее, в циклах выборки опкода (я так понял, для инструкций без префикса 1 раз, а с префиксами - 2, в соответствии с числом изменений R), надо тогда pc:4 заменять на pc:3,IR:1. Так? Почему же это не описано, вероятно, только потому, что в случае I=$40..$7F оригинальный Спектрум нормально вообще не функционирует, и смысла в таком сочетании нет вообще, наверное? (И тогда зачем эту ситуации вообще эмулировать, понта ради, что ли). Мне вот, к примеру, не хочется навешивать много кода, выполняющегося на каждой инструкции. Я жутко рад, что в режиме max speed можно быстро пробегать несущественные участки демок или rzx-записей (да и лента быстрее грузится), и каждая такая добавка ударяет по ускорению. А ещё я могу добавить, что я не эмулирую экран с точностью до цикла. В идеальном случае, нужно было бы перед выполнением записи в память (не перед всей командой, а именно перед циклом записи байта в память) выполнять эмуляцию луча экрана, от последней точки, до новой. Я сознательно упрощаю ситуацию, и делаю такую эмуляцию перед всей инструкцией, правда, с упреждением 8 тактов (т.е. луч как бы на 8 тактов бежит вперёд времени). Этого хватает на все известные мне мультиколорные демки, и при этом достигается неплохая скорость эмуляции.

Логика таймингов PUSH в том, что ему нужно уменьшить SP, и не когда-нибудь, а выложить его уменьшенное значение на адресную шину уже на первом такте следующего цикла (чтения). (Если вы посмотрите на тайминги 16-разрядных арифметических операций Z80 или i8080, вы увидите, что они никогда не проходят без потерь.) А вот четырехтактовое чтение PUSH действительно ни к чему.

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

как вы считаете задержки для такого цикла вывода

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

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

Я имею в виду, откуда ноги растут от этой информации и на чем можно проверить?

Да если бы я уже помнил. В голове дыра, старый стал, всё забываю, именя, явки. Но где-то проскакивало. Да даже не источник важен, а то, что какая-то игруля или демка висла, пока я этот баг не реализовал. Если попадётся, сообщу.

Теперь с MEMPTR. Я не знаю как получаются контрольные числа для тестов на флаги, но в тестах на MEMPTR эти числа -- это значения самого MEMPTR. Значение его получается с помощью BIT b, (HL) и CPD. (Кстати, а какое отношение имеют BIT b, (i+d) к предыдущим значениям MEMPTR?) Как вы понимаете, в тесте проверяются и те инструкции, которые дают в MEMPTR значения, не зависящие от его прежних значений. Как вам кажется, насколько вероятно, что автор не знал как инцилизировать этот регистр?

Сначала определимся, о чём я говорил. Тесты 2 на мемптр отдельно я вчера не гонял. Я имею в в иду, что тесты на bitNhl. должны учитывать memptr, т.е. это уже тесты на memptr. Я сегодня сгонял этот тестик ещё пару раз, и подивился дважды. Даже не знаю что и думать. Дохожу в другом эмуляторе (EmuzWin2.7) до теста ld a,r/ld a,i, сбрасываю z80, загружаю в GL - проходит все тесты дальше. Но самое интересное: если снова нажать 1 в GL и прогнать все тесты - опять проходит! И снова проходит (я правда, для чистоты эксперимента вырубил эмуляцию бага, и LD AR, LD AI проходят сами по себе). Загружаю образ с ленты - опять не проходят... Это мистика №1. Ладно, делаю наоборот. Раз баг Z80 отключён, у меня должно быть то же, что и в той версии. Прохожу в GL до этого же примерно места, сбрасываю в Z80, загружаю в старом - и бац! - в нём перестаёт проходить тест, failed на на том же месте в bit n,..., при том, что раньше проходил. И опять, повторный запуск тестов 1 - и они опять не проходят. Ну - мистика, одним словом. Как через снапшот z80 можно передать свойства проходимости или не проходимости теста, я просто не понимаю. В тесте явно где-то ошибка.

Далее, прогнал отдельно тесты 2, обнаружил баги на паре команд, всё проходит. Ну, думаю, раз bit n,... - это частично memptr и в старом эмуле эти тесты проходили, то уж memptr-то он пройдёт. Не тут-то было: ни один тест не пройден (во как!). А как же тогда тесты на bit nHL в тестах 1? Они как тогда пройдены? Надо полагать, этот тест вообще ни на что не годится, с такими-то глюками.

имеют BIT b, (i+d) к предыдущим значениям MEMPTR?

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

Эта игрушка известна как очень чувствительная к правильным таймингам. Если во время игры спрайты мелькают, значит есть проблема.

Проблема, и очень большая. На Спектакуляторе мигает, и значит, эта же проблема наблюдается и в нём. И в Spin-е тоже. Других доступных мне эмуляторов с отладчиком, в которых бы он не мигал, не существует. Хвалёный klive вообще сбрасывается (да в нём и отладчика-то нет, если бы и не сбрасывался). Соответственно, проблема останется неразрешимой в пределах моего приближённого решения. А делать приближение менее приближённым ради одной не очень интересной игрушки не очень интересно (особенно, когда нет интересной возможности сравнить с лучшим решением, и непонятно куда приближаться вперёд).

[Advertiser]