EmuZGL alpha preview

[Shadow Maker]

Владимир, а Map Maker будет?

Добавлено через 2 минуты
Сайдвайз вот: http://loz.the-pub.org/emu/speccy/s/sidewize.tap.zip

[Higgins]

Задержки по нечётным портам я не учитывал, решил, что для мультиколора это не очень существенно. Если найдётся демка, где существенна, тогда реализую.

Вот. Теперь у меня есть что ответить, если спросят зачем понадобился еще один эмулятор Спектрума. ;-)

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

Первый раз слышу-вижу. Какие могут быть контенции на IR, это же просто регистры?

Ну, PC, SP и DE -- это тоже просто регистры, вы же по ним задержки считаете. Или не считаете? Да и какое может быть дело ULA до того, из чего составлено значение на адресной шине?

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

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

Позднее добавили?

Да.

После того, как я подправил задержку между бордюром и изображением, сначала вроде BBG пошла, но при этом съехала MDA demo (по фотографии с оригинального реала, пульсы стоят строго симметрично). Тогда я сравнил со спектакулятором, и обнаружил, что Джон утаил секретик, а именно, в описании контенций махонькая ошибка (а он, судя по всему, её нашёл, и у себя поправил). Потом, когда я её поправил, я нашёл ещё одну ошибку, уже на игре Black Lamp мультиколор съехал. Вот поправки (но это не по данным реала, а по данным спектакулятора, получается):

PUSH dd pc:4,sp-1:4,sp-2:3 //BlackLamp old-incorrect:/pc:5,sp-1:3,sp-2:3

OUT (n),A pc:4,pc+1:4,IO:3 //corrected! (BBG)// old-incorrect: pc:4,pc+1:3,IO:4 (like IN A,(n))

И, кстати, после этих поправок на демке EEL (48К) пульсации больше не прыгают ходуном, как в спектакуляторе, а стоят ровненько. Видать, Джон что-то ещё не учёл.

Ничего себе... Давайте по порядку.

MDA demo в нашу память не помещается, мы эмулируем 48K. Поэтому, к сожалению, не могу попробовать.

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

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

У POP судьба счастливее -- он может выложить SP на адресную шину сразу как есть, поэтому такт не теряет.

OUT. У Z80 нет трехтактового вывода в порт. Цикл вывода выглядит следующим образом: T1 T2 Tw T3, где Tw добавляет сам процессор, и никакой ULA укоротить этот цикл не может.

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

У меня выборка PUSH в пять тактов и трехтактовых циклов вывода в порт нет. При этом Black Lamp, EEL demo и BBG работают как положено. (Спасибо за ссылки на первые две, я их раньше не пробовал. Black Lamp смотрится очень красиво.)

Нет, все области дрожания - только из-за широкого бордюра. Достаточно поставить Large (48 пикселей), и все дрожи уходят за край.

Если у вас при ширине бордюра в 24 такта окончание этой линии уходит за правый край, то это тем более проблема. У меня при таком же бордюре этот кончик видно, на Fuse видно, и на реале видно. Причем видно не у края, а явно в пределах этих 24 тактов. И, разумеется, не дрожит.

Кстати, у наших клонов, похоже, видимый бордюр был намного шире ихнего

Это факт. На тех железных Спектрумах, которые побывали у меня у всех ширина бордюра была 32 такта. Поэтому поначалу стандартные размеры на эмуляторах выглядели для меня странно.

Или этот тест не учитывает баг в Z80 с установкой в флаге P/V значения 1, пока на вход ~INT активен (кроме случая, когда предыдущая команда была EI), независимо от значения IFF2. Либо тест делался на машине с коротким интом (у меня 23, а там могло быть даже 22, и то уже существенно: разница нашлась как раз когда выполнялась загрузка LD A,R, и T было 22). Но это даже не важно. А важно то, что тест несколько некорректен по отношению к командам BIT n,(HL/IX+k/IY+k) - результат зависит от предыдущих тестов. Наверняка автор не знал, как стереть memptr и привести его в начальное состояние перед выполнением тестов. Так вот, если пройти тест LD A,R/I на другом эмуляторе (я использовал EmuZWin 2.7/build 2.8), остановиться и сбросить Z80-снапшот и загрузить в EmuZGL, то дальше все тесты на memptr проходят на ура. LD A R/I я исправлять не буду, т.к. полагаю, что сделал эту команду правильно (есть даже прога какая-то, которая виснет, если баг Z80 не реализован, жаль, не помню, какая именно).

Теперь для меня что-то новое открылось. Какие есть материалы по этому особенному значению P/V при активном ~INT? Я имею в виду, откуда ноги растут от этой информации и на чем можно проверить?

У меня ~INT держится 32 такта. При этом в тесте на флагах LD A, I выполняется минимум на 127-м такте, LD A,R -- на 15-м. На 22-м не исполняется никогда. Во Fuse ровно то же (вообще, мы с ним по тактам совпадаем точно, расхождений еще никогда не видел). Обе команды возвращают в P/V IFF2 и тест проходят. Не знаю, что думать... Может быть действительно этот кристалл от NEC особенный в этой части. Но чтобы аргументировать против такого теста нужны факты или контрпримеры, а их пока нет.

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

О BIT b, (HL) в тестах на флаги я могу сказать точно: MEMPTR инциализируется. Инструкция 0xCB46 по адресу 0x8858. Значение MEMPTR во время выполнения всегда 0x8855. Объяснить это значение очень просто. Если вы посмотрите на код с адреса 0x884c, то увидите, что исполняется специальный код, который записывает адрес начала процедуры тестирования инструкции (0x8855) в операнд инструкции CALL (по адресу 0x8928), которая эту процедуру вызывает. Я думаю, вам известно, что эта инструкция присваивает MEMPTR адрес перехода. Таким образом к BIT b, (HL) управление приходит всегда с одним и тем же значением MEMPTR.

Ну и кроме того, есть все та же логика. Если бы MEMPTR не инициализировался и получал бы непредсказуемые значения, тогда прохождение теста менялось от запуска к запуску, зависело бы от порядка прохождения тестов (скажем, сначала на MEMPTR, а потом на флаги), причем даже на реальном кристалле.

В общем, вспоминайте, пожалуйста, что за программка висла на LD A, I/R.

sidewiz я нашёл только в SCL, из чего вывод сделал, что он для Пентагона, мультиколор тут ни при чём тогда.

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

[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 вообще сбрасывается (да в нём и отладчика-то нет, если бы и не сбрасывался). Соответственно, проблема останется неразрешимой в пределах моего приближённого решения. А делать приближение менее приближённым ради одной не очень интересной игрушки не очень интересно (особенно, когда нет интересной возможности сравнить с лучшим решением, и непонятно куда приближаться вперёд).

[Shadow Maker]

11-4=3

Я мож чего не понимаю и вообще далек от мысли... Это вот как? Или 11-4-4?

[Vladimir Kladov]

11-4-4

Именно так. Окошечко махонькое, пока набираешь, оно всё куда-то уплывает, уже не видно, напечатал, не напечатал. Ну, здесь понятно, арифметика простая.

Добавлено через 14 секунд
Выкладываю версию 208К. Главное: добавлено 4 видеорежима, в том числе 384х304 и 256х192х16.

[Shadow Maker]

Мм, ну там КартоСтроитель в планах есть? А то не было ответа на вопрос.

[Advertiser]

[goodboy]

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

в Sidewize присутствует подвязка к чтению из порта #FF

[ARTi]

Higgins

Теперь для меня что-то новое открылось. Какие есть материалы по этому особенному значению P/V при активном ~INT? Я имею в виду, откуда ноги растут от этой информации и на чем можно проверить?

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

Vladimir Kladov

Для меня здесь критерием правильности является демка, 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х-тактовым циклом ввода/вывода, не совсем корректно. Это обыкновенный workaround. Тов. Джон, видимо, долго анализировал большой объем кода различных программ/демок и нашел где можно сделать изменения так, чтобы ничего не испортить, и даже улучшить.
Тем не менее, workaround - он и в Африке... Но самое главное здесь то, что Higgins однозначно утверждает

У меня выборка PUSH в пять тактов и трехтактовых циклов вывода в порт нет. При этом Black Lamp, EEL demo и BBG работают как положено. (Спасибо за ссылки на первые две, я их раньше не пробовал. Black Lamp смотрится очень красиво.)

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

Всё получится, если всё сделать аккуратно

Это Вам не в упрек. Это просьба не закрывать глаза на факты, тогда не придется переиначивать другие факты (например, 4х-тактовые циклы ввода/вывода и "лишний" такт в M1 у PUSH). EmuZGL уже гораздо лучше своего предшественника, многим нравится и мне в том числе. Так не идите же на поводу у любителей понаставить затычки "абы все известные проги работали правильно", а просто делайте красиво и хорошо. Увидев EmuZGL я понял, что Вы можете, когда хотите .

P.S. При желании попробуйте внести коррективы в как минимум одну команду (речь об EX (SP),HL и, возможно еще об OTIR/OTDR) в соответствии с этим и этим (правда я не понял, что там насчет задержек в M1?).

P.P.S.
Higgins

Так вот выборка -- не исключение, и на каждый дополнительный такт выборки мы получаем задержку со значением IR на адресной шине. PUSH, к слову, -- отличный пример на этот счет.

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

[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.

[Vladimir Kladov]

Мм, ну там КартоСтроитель в планах есть?

Автоматический или полуручной интересует? Автомат почти никак нельзя сделать внешним, в виде отдельного экзешника. А полуручной - запросто.

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

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

Вот здесь об этом ясно сказано, стр. 98-99, в описании команд LD A,I и LA A,R.

Нет, там описано только официальное поведение: "During LD A, I and LD A, R instructions, the P/V Flag is set with the value
of the interrupt enable flip-flop (IFF2) for storage or testing." И там ничего не говорится о ситуации, когда в P/V попадает 1 при активном INT. Так что это именно баг, противоречащий официальному описанию.

введение задержек на IR не могло ощутимо повлиять на производительность.

Ну как же не могло? Вот например PUSH dd - pc:4,ir:1,sp-1:3,sp-2:3, в случае отсутствия задержек по IR (т.е. когда I <$40 или > $7F), совершенно эквивалентно pc:5,sp-1:3,sp-2:3. А в случае, когла задержка такая нужно, на экране всё равно снег. Да ещё и регенерация нарушена. Т.е. ситуация для Спектрума совершенно недопустимая. Если предположить, что включили ненадолго, чтобы просто получить снег, то никакого мультиколора всё равно не увидим в этот момент, опять же только снег. Нет, для целей эмуляции Спектрума эмулировать задержки по IR не надо.

Вот, я реализовал правильно IO контенции, и всё пошло (кроме sidewize) как и должно, и задержки IR не потребовались. Что касается сидвиз, то я конечно понимаю, что ничего не понимаю в том, какие байты именно и как долго читаются улой на шину, чтобы правильно сэмулировать in по несуществующему порту, но floatspy говорит, что шина в порядке. Значит, этот тест тоже надо выкинуть в корзину.

P.S. Насчёт интры megaclr я извиняюсь, это пентагоновская интра, и мультиколор там пентагоновский.

Вопросы к народу. Я нашёл, что в Скорпионе турбо выключается просто чтением из порта 1FFD. А включается как - так же?

Обнаружил, что неправильно понял раскладку битов по порту EFF7. Бит 0 оказался ответственным за режим 256х192х16с, а как же тогда включать атрибут на байт, тумблером только? Ещё бит 4 получается, отвечает за турбу в пентагоне, причём 0-вкл, 1-выкл. Верно? (хотя мне это не нравится совершенно. Получается, что порт надо инициализировать 1 в бите 4, или при ресете включать турбу). Я пока не меняю, оставил как в прошлый раз.

Я сейчас выкладываю версию 211К. В основном небольшие поправки, но добавлена гамма-коррекция, и автоматическое выезжание меню.