Вид для печати
глупость сморозили.Цитата:
Сообщение от aforeve
в обчном эмуляторе точно также приходится по сто раз лезть в меню чтоб добраться до конкректной опции, ведь все эти маленькии выдвигающиеся окошки после убирания с них курсора мыши, исчезали.
гуй эмулятора emuzgl очень даже неплох, хотя помоему всё несколько великовато.
глянь в конфиг, размер шрифта можно менятьЦитата:
Сообщение от ZEman
я не про шрифт, а про кнопки :)
Размер кнопок подбирается по размеру меню.Цитата:
Сообщение от ZEman
Выезжание я сделаю позже, когда руки дойдут. А вот автоматическое убирание - это плохо. Я ещё в ДОС когда-то понял, что с меню, которое заменяет конфиг, при автоматическом убирании работать просто невозможно. Выбираешь из кучи вложенных менюшек опцию, нажимаешь, и всё меню закрывается. Надо соседний пунктик щелкнуть или опять тот же - начинай всё сначала.
Добавлено через 8 минут
А вот как ра то что по умолчанию BigMenu=1, хорошо для работы и в окошке, когда оно маленькое, и в фулскрине, когда экран далеко стоит.Цитата:
Сообщение от ZEman
Vladimir Kladov,
Позвольте пару слов о не-GL версии. Я взял то, что сегодня доступно на
http://kolmck.net/apps/EmuZWin_Eng.htm
(в заголовке страницы написано EmuZWin v2.7 release 2.8). Запустил это на wine, Windows нет сейчас под рукой. Выбрал модель 48K. Попробовал пару тестов: BBG с цветными вертикальными полосами и эффект снега. Скриншот первого приложен. Понятно, что выглядит он не так, как должен. Может быть вы в курсе, это с проблемы с таймингами или это работа в wine так сказывается?
По поводу второго теста. Это простенькая программка на Бейсике, записывающая (с помощью POKE) и запускающая по адресу 40000 следующий код.
DI
LD A, 0x40
LD I, A
EI
RET
Попробовал запустить на EmuZWin, и он вывалился с ошибкой доступа к памяти. Запустил эмулятор еще раз и обнаружил, что галочка Snow Effect сброшена. Попытался ее установить, и тут же вывалился с той же ошибкой снова. Поэтому скриншота нет, прилагаю снапшот.
Cсылка на тест BBG:
http://ppest.org/zx/zxse.php
http://ppest.org/zx/et/BBG.ZIP
А можно ссылку на тест?
Я добавил ссылку в исходное сообщение.Цитата:
Сообщение от heroy
Извиняюсь, повылазилоЦитата:
Сообщение от Higgins
очень глючный. Смотрите на GL, он устойчивее (проще потому что). Снег реализован, тайминги тоже. Зависимость от винды тоже меньше. Есть вариант звука bass, наверняка это на Linux лучше будет.Цитата:
Сообщение от Higgins
Может подскажете, с чем может быть связано подрагивание изображения в полноэкранном режиме?
А то еще подрожит, потом успокоится, начнешь мышкой двигать и экран опять дергается.
На другой машине, что на работе, такого эффекта нет.
Демка Anamnesis, там в меню можно выбирать pentagon/scropion.Цитата:
Сообщение от Vladimir Kladov
Только вот скорпионы бывают разные, желтые, зеленые...
У желтого там какая то беда с нечетно тактовыми командами, они вроде как дополняются до четных и так-тов получается в худшем случае чуть ли не 65000.
В демке Binary Love тоже можно выбирать pentagon/scorpion, мультиколоров там достаточно
Vladimir Kladov,
Версия GL действительно смотрится гораздо лучше. К сожалению, в тестах на тайминги дает примерно то же. В Aquaplane правый край горизонта дрожит. В Dark Star значек на верхнем бордюре не по середине, сполз вправо. Floatspy показывает странные значения при чтении из нечетных портов в диапазоне 0x4000-0x7fff. Линии на тесте BBG тоже не на месте. В ShockMegademo справа видна дефектная полоса. В Vectron сверху вылезла синяя полоса и последняя красная линия на правом бордюре тоже дрожит.
С эффектом снего интересно получилось. Сам по себе тест прошел нормально, и снег я увидел. Но после загрузки (без сброса) очередного снапшота (.z80) снег продолжает идти как ни в чем не бывало. ;-) Это видно на одном из скриншотов.
На всякий случай. По моим расчетам получается следующее.
При ширине 64 пикселя на бордюр будет. На реальном экране не было столько пикселей. К примеру, эмулятор Spectaculator максимум показывает 48. Скорее всего, остальные он не показывает, чтобы не портить картинку, потому что в мультиколорных программах бордюр изменяется с небольшим запасом, на экране-то всё равно не было видно. Я 64 показываю, потому что рассчитываю на другие видеорежимы, в частности 384х304. И для отладки мультиколора тоже интересно глянуть, где бордюр переходит.Цитата:
Сообщение от Higgins
FloatSpy: читаться должны значения с шины. Т.е. пиксели и атрибуты. Вот я сейчас выбрал 128К, загрузил FloatSpy, нажал T, он мне спустя время выдал Floating bus OK for ULA 128K. Кстати, там у меня изначально показывает IN() BYTE: 0, и во время и после теста тоже. Кстати, для модели 48К картинка совершенно аналогичная, только он там 48К пишет.Цитата:
Сообщение от Higgins
BBG я не в курсе, что такое. DarkStar никогда не смотрел (и не знаю, что там мультиколорного, и в чём дефект). Может, был баг, а может модель не та.
Про это я уже сказал. А вот то, что посредине ступенька, это или действительно баг (я уже так далеко убежал от последней выложенной версии, что уже не помню). А может, просто неправильно выбрана модель. Хотя если грузить с ленты, то на модель (48, 128 или +3, остальные модели не знаю точно) шок настраивается сам. Тогда был баг. Сейчас этой ступеньки у себя я не вижу. Vectron у меня тоже работает нормально, раньше снег включался для любой модели и не только когда надо, это я у себя несколько дней как поправил, не помню точно уже, но примерно так выглядело, если загрузить в пентагоне.Цитата:
Сообщение от Higgins
Я вообще давно не обновлял, потому что очень глубоко забурился в видеовывод: захотел реализовать если не все видеорежимы сразу, то сделать так, чтобы по таблицам они легко могли настраиваться, и добавление нового видеорежима стоило копейки времени и усилий. Даже вроде получилось, осталось только довести до ума гигаскрин для тех режимов, где оно есть. Доделаю не спеша, так и выложу.
Добавлено через 11 часов 36 минут
Явных мультиколоров не обнаружил. Если выбрать не тот фикс, мало что меняется. В одном месте полоски кривые (рисунок из красных кирпичей), в другом полоска на экране дрожит, хотя в правильном фиксе нет её (это где морфинг и около).Цитата:
Сообщение от Alexander Makeev
Аналогичная ситуация. Полезноа оказалась только, чтобы обнаружить, что в варианте эмулятора флопа с nodelay=0 не грузит эту демку. Пришлось вместе с FastDisk включать NoDelay.Цитата:
Сообщение от newart
Кстати, если известно хоть что-то реально использующее хардверный гигаскрин по порту EFF7, тоже буду рад получить инфу о таких демах/играх/просмотрах. А то реализовать вроде реализовал (а может и не дореализовал), а проверять не на чем.
Ну вот, собственно, теперь выкладываю версию 206K. Добавлено: Scorpion (с мультиколором), видеорежим 256x192 байт атрибутов на байт пикселей (hardware multicolor), Gigascreen+ (и по порту EFF7 бит 4, и автоопределением програмного гигаскрина). Полупрозрачное меню, индикация текущей модели и объёма памяти в верхнем правом углу. Улучшена загрузка с ленты и с диска, поправлен кое-где мультиколор, исправлено отцепление от захваченной кемпстон-мыши при неактивном окне эмулятора, выделение регистров мышью в отладчике.
Это похоже на правду. Я попробовал у себя ширину бордюра в 64 пикселя, и наблюдал то же самое дрожание справа.Цитата:
Сообщение от Vladimir Kladov
Да, должны читаться значения с шины. Но: по нечетным портам в диапазоне [0x4000;0x8000) они читаются с задержками, и значения дают другие. Посмотрите на скриншот и не нажимайте T (в этом режиме всегда читается порт 0xff). Еще одно замечание: я говорю о модели 48K и выбираю эту модель на вашем эмуляторе на всех тестах.Цитата:
Сообщение от Vladimir Kladov
Смотрите чуть выше в этой же теме, я давал ссылки. Очень полезный тест.Цитата:
Сообщение от Vladimir Kladov
Скриншот был приложен в прошлом сообщении. На верхнем бордюре генерируется цветной значок.Цитата:
Сообщение от Vladimir Kladov
Но здесь есть тонкость: когда прерывания ловятся в течение 32-х тактов считая с последнего такта предыдущей инструкции (INT sampling), как это и должно быть, он у меня тоже сползает, если сравнивать с тем, что дает Fuse. Но Fuse сам не безгрешен (и тому у меня набралось уже достаточно примеров), и лучше всего было бы посмотреть на реальной машине, как это должно быть.
Здесь ситуация такая. Ступенька по середине экрана -- это проблема самого снапшота. На самом деле ее не видно, но по-другому снять скриншот не получается. А полоса справа -- это тоже из-за ширикого бордюра, и у меня на широком бордюре она тоже видна. Поэтому здесь проблемы нет никакой.Цитата:
Сообщение от Vladimir Kladov
Тут два пункта: синяя полоса наверху и дрожание бордюра справа внизу. Полоса, очевидно, -- это от размера бордюра (у себя не пробовал). А вот дрожание есть, и его видно на стандартном бордюре (эта линия действительно заканчивается в видимой области), и его быть не должно.Цитата:
Сообщение от Vladimir Kladov
Теперь дополнения.
1) Человечек в SideWize мерцает. Мерцать не должен.
2) Тест на тайминги (см. приложение) показывает, что IR contentions не реализованы вообще.
3) Тест на Z80 (тоже приложен) находит проблемы и на флагах, и на MEMPTR. Хотя на моей реализации, сделанной по вашему же описанию, проходит оба без ошибок.
Задержки по нечётным портам я не учитывал, решил, что для мультиколора это не очень существенно. Если найдётся демка, где существенна, тогда реализую.Цитата:
Сообщение от Higgins
Первый раз слышу-вижу. Какие могут быть контенции на IR, это же просто регистры?Цитата:
Сообщение от Higgins
Теперь увидел. Позднее добавили? У меня новые темы отражаются вверху, без особой надобности вниз не листаю, поэтому не увидел. А тест действительно полезный. После того, как я подправил задержку между бордюром и изображением, сначала вроде BBG пошла, но при этом съехала MDA demo (по фотографии с оригинального реала, пульсы стоят строго симметрично). Тогда я сравнил со спектакулятором, и обнаружил, что Джон утаил секретик, а именно, в описании контенций махонькая ошибка (а он, судя по всему, её нашёл, и у себя поправил). Потом, когда я её поправил, я нашёл ещё одну ошибку, уже на игре Black Lamp мультиколор съехал. Вот поправки (но это не по данным реала, а по данным спектакулятора, получается):Цитата:
Сообщение от Higgins
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К) пульсации больше не прыгают ходуном, как в спектакуляторе, а стоят ровненько. Видать, Джон что-то ещё не учёл.
Нет, все области дрожания - только из-за широкого бордюра. Достаточно поставить Large (48 пикселей), и все дрожи уходят за край. Кстати, у наших клонов, похоже, видимый бордюр был намного шире ихнего (иначе непонятно как влез режим 384х304, да и на наших мультиколорах демомейкеры область дрожания явно старались сдвигать дальше).Цитата:
Сообщение от Higgins
Вот с этим поподробнее. Я сначала поправил глупую ошибку в ADC16, а потом начал смотреть на LDA I/R, и обнаружил такую штуку. Или этот тест не учитывает баг в 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 не реализован, жаль, не помню, какая именно).Цитата:
Сообщение от Higgins
sidewiz я нашёл только в SCL, из чего вывод сделал, что он для Пентагона, мультиколор тут ни при чём тогда. А если это просто кто-то в SCL загнал, то надо оригинальный образ искать (на ВОСе не нашёл).
И вообще, граждане-господа спектрумисты! Надеюсь на вашу помощь (опять с памятью туго). Где-то мне уже разок давали тесты для 384х304 и если не ошибаюсь 512х192, но хоть убей не помню куда задевал. Куда-то сгинули. И ещё нужна какая-нибудь инфа по режиму 16с для пентагона (если такой есть). Есть куча описаний 384х304 атрибут на знакоместо, 512х192 и 256х192 атрибут на байт, и ничего такого 16с. Ну, кроме АТМовского 320х200х16с.
токо в пенте и есть пока :) , какая-нить инфа есть здесь: http://zx.clan.su/forum/7-28-1 , см. п.п. 4.2 16 color per pixel. К сожалению ничего более подробного нет..Цитата:
Сообщение от Vladimir Kladov
Хотя кажись уже нашёл описание 16 с или что-то на него похожее. Осталось найти софт для 384х304.
ACEdit, ANSI viewer.Цитата:
Сообщение от Vladimir Kladov
Владимир, а Map Maker будет?
Добавлено через 2 минуты
Сайдвайз вот: http://loz.the-pub.org/emu/speccy/s/sidewize.tap.zip
Вот. Теперь у меня есть что ответить, если спросят зачем понадобился еще один эмулятор Спектрума. ;-)Цитата:
Сообщение от Vladimir Kladov
К слову, а как вы узнаете когда что-нибудь не будет работать именно по этой причине?
Ну, PC, SP и DE -- это тоже просто регистры, вы же по ним задержки считаете. Или не считаете? Да и какое может быть дело ULA до того, из чего составлено значение на адресной шине?Цитата:
Сообщение от Vladimir Kladov
Попробую объяснить. В отличие от короткого цикла чтения в 3 такта, короткий цикл выборки инструкции (opcode fetch) занимает 4 такта. Чтение оп-кода происходит, тем не менее, на 3-м такте, как при обычном чтении. Четвертый такт нужен для обновления памяти: при выборке инструкции увеличивается R0:7 и пара IR кладется на адресную шину.
Теперь вспоминаем, что и циклы чтения, и циклы записи бывают и большего размера плюс есть циклы исполнения, которые не читают не пишут, тоже до пяти тактов длиной, на которых мы, тем не менее, считаем задержки на основании того, что осталось на адресной шине от предыдущего цикла. Так вот выборка -- не исключение, и на каждый дополнительный такт выборки мы получаем задержку со значением IR на адресной шине. PUSH, к слову, -- отличный пример на этот счет.
Да.Цитата:
Сообщение от Vladimir Kladov
Ничего себе... Давайте по порядку.Цитата:
Сообщение от Vladimir Kladov
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 смотрится очень красиво.)
Если у вас при ширине бордюра в 24 такта окончание этой линии уходит за правый край, то это тем более проблема. У меня при таком же бордюре этот кончик видно, на Fuse видно, и на реале видно. Причем видно не у края, а явно в пределах этих 24 тактов. И, разумеется, не дрожит.Цитата:
Сообщение от Vladimir Kladov
Это факт. На тех железных Спектрумах, которые побывали у меня у всех ширина бордюра была 32 такта. Поэтому поначалу стандартные размеры на эмуляторах выглядели для меня странно.Цитата:
Сообщение от Vladimir Kladov
Теперь для меня что-то новое открылось. Какие есть материалы по этому особенному значению P/V при активном ~INT? Я имею в виду, откуда ноги растут от этой информации и на чем можно проверить?Цитата:
Сообщение от Vladimir Kladov
У меня ~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.
Прекрасно работает на нашем 48K. Мультиколор, конечно, ни при чем, но речь все еще о таймингах. Эта игрушка известна как очень чувствительная к правильным таймингам. Если во время игры спрайты мелькают, значит есть проблема.Цитата:
Сообщение от Vladimir Kladov
А, всё, не надо. Нашёл софтинки. На работе в архиве завалялись. Пойду теперь сваи ашипки исправлять. (это я про софт для расширеных режимов)
Добавлено через 2 часа 48 минут
Когда выясняется, что что-то не работает, изучаются конкретные причины. До сих пор срабатывало. А вот с задержкой по нечётным портам, раз они не влияют на мультиколорные демки, и не используется эффект в играх, то и смысла особого нет, разве что для куражу. Я эмулятор делаю, чтобы можно было поиграть и поработать, потому что эмуляторов, в которых можно поделать и то, и это, и при этом удобно, пока что нет, при том что число эмуляторов спектрума уже наверняка приблизилось к тысяче. Хорошо тем, у кого есть реал (и умение+желание с ним возиться). Но и реальщик оказывается часто в дурацкой ситуации: моделей куча, доработок и периферии ещё большая куча, всё себе навешивать - жизни не хватит. В эмуляторе можно побаловаться с возможностями, которых нет возможности привозможнить к своему реалу. А вообще, я эмулятор EmuZWin начинал делать исключительно по той причине, что все эмуляторы, с которыми я имел дело до этого, не умели нормально клавиши PC перенаправлять на клавиши/джойстики Спектрума. Хотя дело-то плёвое, но неудобно же - в одной игруле ZXQA1, в другой QAOPN, в третьей совершенно неудобный синклер джойстик или InterfaceII.Цитата:
Сообщение от Higgins
Я не схемотехник и не радиолюбитель и мне вообще непонятно, почему выборка из памяти занимает 3 такта. А где написано про задержки IR? Я что-то такого нигде не встречал. Если рассуждать так, то во всех инструкциях, точнее, в циклах выборки опкода (я так понял, для инструкций без префикса 1 раз, а с префиксами - 2, в соответствии с числом изменений R), надо тогда pc:4 заменять на pc:3,IR:1. Так? Почему же это не описано, вероятно, только потому, что в случае I=$40..$7F оригинальный Спектрум нормально вообще не функционирует, и смысла в таком сочетании нет вообще, наверное? (И тогда зачем эту ситуации вообще эмулировать, понта ради, что ли). Мне вот, к примеру, не хочется навешивать много кода, выполняющегося на каждой инструкции. Я жутко рад, что в режиме max speed можно быстро пробегать несущественные участки демок или rzx-записей (да и лента быстрее грузится), и каждая такая добавка ударяет по ускорению. А ещё я могу добавить, что я не эмулирую экран с точностью до цикла. В идеальном случае, нужно было бы перед выполнением записи в память (не перед всей командой, а именно перед циклом записи байта в память) выполнять эмуляцию луча экрана, от последней точки, до новой. Я сознательно упрощаю ситуацию, и делаю такую эмуляцию перед всей инструкцией, правда, с упреждением 8 тактов (т.е. луч как бы на 8 тактов бежит вперёд времени). Этого хватает на все известные мне мультиколорные демки, и при этом достигается неплохая скорость эмуляции.Цитата:
Сообщение от Higgins
Для меня здесь критерием правильности является демка, BBG, кстати. Она идёт именно так, как должна идти, причём конкретно обнаруживается инструкция PUSH BC: на такте 14425 она началась (задержка 4), и только при исправлении выше для push прошло ровно столько же тактов, сколько показал отладчик спектакулятора. В итоге вывод: выборка может и 5-тактная, но ULA ловит адрес тогда на втором такте второго цикла, а не на третьем. Результат-то: BBG идёт, а без исправления - нет. Здесь-то явно никаких IR задержек нет, иначе просто был бы снег на экране, все прочие вмешательства вроде погоды на Марсе исключены: одна инструкция PUSH BC, с точно известного такта, точно известна последовательность задержек с этого такта (43210065432100...), точно известно, что в итоге инструкция должна отработать за 16 тактов. Официальное решение, не признанное Джоном, гласит 5+3+4(задержка)+3=15, остаётся только решение 4+3+5(задержка)+4=16.Цитата:
Сообщение от Higgins
3 - это не задержка. Уравнение простое: известно, что инструкция обычно выполняется за 11 тактов. Для неё написано pc:4,pc+1:4,io. Вопрос, чему (обычно) равно io? 11-4=3. Я так полагаю, что если есть задержка, то она добавляется где-то на этих 3х тактах. Предполагаю, что на первом из этих трёх. Вроде бы ничего сломалось, и кое-что (и даже многое) исправилось. Значит, ответ скорее верный, чем не верный. Вот такой у меня ход рассуждений. Скажете, глупо? Да, глупо, но документации-то нет. Где прочитать, чему равен этот Tw, и что такое T3, если это не вывод в порт?Цитата:
Сообщение от Higgins
Для проверки 48 я ещё использую KAZ6 и MEGACLR (ну полное угрёбище, даже звука нет, но важен бордюрный эффект), ну и конечно shock, без него оно никак, конечно.
Да если бы я уже помнил. В голове дыра, старый стал, всё забываю, именя, явки. Но где-то проскакивало. Да даже не источник важен, а то, что какая-то игруля или демка висла, пока я этот баг не реализовал. Если попадётся, сообщу.Цитата:
Сообщение от Higgins
Сначала определимся, о чём я говорил. Тесты 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 можно передать свойства проходимости или не проходимости теста, я просто не понимаю. В тесте явно где-то ошибка.Цитата:
Сообщение от Higgins
Далее, прогнал отдельно тесты 2, обнаружил баги на паре команд, всё проходит. Ну, думаю, раз bit n,... - это частично memptr и в старом эмуле эти тесты проходили, то уж memptr-то он пройдёт. Не тут-то было: ни один тест не пройден (во как!). А как же тогда тесты на bit nHL в тестах 1? Они как тогда пройдены? Надо полагать, этот тест вообще ни на что не годится, с такими-то глюками.
Я понял так, что автор тестов просто не пытался изолировать тесты от предыдущих, вполне возможно, что у него просто все последующие тесты напрямую могут зависеть от предыдущих. В корзину его, однозначно.Цитата:
Сообщение от Higgins
Проблема, и очень большая. На Спектакуляторе мигает, и значит, эта же проблема наблюдается и в нём. И в Spin-е тоже. Других доступных мне эмуляторов с отладчиком, в которых бы он не мигал, не существует. Хвалёный klive вообще сбрасывается (да в нём и отладчика-то нет, если бы и не сбрасывался). Соответственно, проблема останется неразрешимой в пределах моего приближённого решения. А делать приближение менее приближённым ради одной не очень интересной игрушки не очень интересно (особенно, когда нет интересной возможности сравнить с лучшим решением, и непонятно куда приближаться вперёд).Цитата:
Сообщение от Higgins
Я мож чего не понимаю и вообще далек от мысли... Это вот как? Или 11-4-4?Цитата:
11-4=3
Именно так. Окошечко махонькое, пока набираешь, оно всё куда-то уплывает, уже не видно, напечатал, не напечатал. Ну, здесь понятно, арифметика простая.Цитата:
Сообщение от Shadow Maker
Добавлено через 14 секунд
Выкладываю версию 208К. Главное: добавлено 4 видеорежима, в том числе 384х304 и 256х192х16.
Мм, ну там КартоСтроитель в планах есть? А то не было ответа на вопрос.
в Sidewize присутствует подвязка к чтению из порта #FFЦитата:
Сообщение от Vladimir Kladov
Higgins
Вот здесь об этом ясно сказано, стр. 98-99, в описании команд LD A,I и LA A,R.Цитата:
Сообщение от Higgins
Как видно, с некоторых пор данное явление задокументировано официально (т.е. описано не как баг, а как особенности работы).
Vladimir Kladov
Имхо, такое решение, вкупе с несуществующим 3х-тактовым циклом ввода/вывода, не совсем корректно. Это обыкновенный workaround. Тов. Джон, видимо, долго анализировал большой объем кода различных программ/демок и нашел где можно сделать изменения так, чтобы ничего не испортить, и даже улучшить.Цитата:
Сообщение от Vladimir Kladov
Тем не менее, workaround - он и в Африке... Но самое главное здесь то, что Higgins однозначно утверждает
что у него проблем в вышеуказанных демках и тестах нет, и при этом безо всяких решений-затычек. Почему-то Вы, то ли сознательно, то ли нет, вообще пропустили это замечание. Но кое-где Вы сами же сказали мудрую фразу:Цитата:
Сообщение от Higgins
Это Вам не в упрек. Это просьба не закрывать глаза на факты, тогда не придется переиначивать другие факты (например, 4х-тактовые циклы ввода/вывода и "лишний" такт в M1 у PUSH). EmuZGL уже гораздо лучше своего предшественника, многим нравится и мне в том числе. Так не идите же на поводу у любителей понаставить затычки "абы все известные проги работали правильно", а просто делайте красиво и хорошо. Увидев EmuZGL я понял, что Вы можете, когда хотите :).Цитата:
Всё получится, если всё сделать аккуратно
P.S. При желании попробуйте внести коррективы в как минимум одну команду (речь об EX (SP),HL и, возможно еще об OTIR/OTDR) в соответствии с этим и этим (правда я не понял, что там насчет задержек в M1?).
P.P.S.
Higgins
А можно с этого места поподробнее? Т.е. Вы хотите сказать, что из-за цикла регенерации более одного такта процессор также задерживается? Хотелось бы прояснить эти тонкости. По WOS видно, что при циклах доступа к памяти Z80 более 3-х тактов - ULA 48k его задерживает и далее, считая каждый лишний такт доступом к той же памяти, вплоть до следующего цикла доступа к памяти; при этом циклы M1 неприкосновенны - присутствует лишь задержка непосредственно перед выборкой инструкции. Получается, и для M1 у ULA 48k есть некий лимит?Цитата:
Сообщение от Higgins
http://www.shadowmagic.org.uk/cssfaq...kreference.htmЦитата:
Сообщение от Vladimir Kladov
Поищите строки, содержащие "ir:" (без кавычек).
Нет, четыре такта -- чтение плюс такт на обновление памяти -- выполняются в любом случае. И даже если значение I лежит в диапазоне [0x40; 0x80), на четвертом такте задержки нет. А вот если цикл выборки длиннее этих четырех тактов, то на каждом дополнительном такте, начиная с пятого и до конца цикла, ULA будет взводить ~CLK, т.е. останавливать процессор. (Может показаться странным это особенное поведение T4 цикла выборки, но на самом деле все логично: этот такт начинается при низком уровне ~MREQ, который в течение такта поднимается, и на следующем такте ULA уже смотрит на адресную шину.)Цитата:
Сообщение от Vladimir Kladov
Тот же Vectron использует это как визуальный эффект. Без всяких последствий.Цитата:
Сообщение от Vladimir Kladov
Да, интересно было бы сравнить предельные скорости эмуляции. Сейчас сравнивать родную линуксовую сборку с чем-то работающим под Wine было бы неправильно, но на перспективу идея годится.Цитата:
Сообщение от Vladimir Kladov
С другой стороны, в моем случае, насколько я могу умозрительно оценить реализацию, введение задержек на IR не могло ощутимо повлиять на производительность.
Даже не знаю как прокомментировать...Цитата:
Сообщение от Vladimir Kladov
В логике (уже который раз к ней обращаюсь) есть такие аксиомы: из истины следует истина, а из лжи может следовать что угодно. Применительно к теме это означает, что даже если реализация эмулятора не верна, то это еще не значит, что тест BBG на ней не будет правильно работать. И обратно: тот факт, что после некоторых правок тест BBG стал правильно работать, еще не значит, что сами эти правки верны.
Я вас отлично понимаю, когда вы говорите, что не стремитесь к абсолютной точности эмуляции, однако это не может делать из таких рассуждений аргумент в обсуждении правильной реализации.
Задержек на IR нет.Цитата:
Сообщение от Vladimir Kladov
Я приложил трейсинг пары рабочих фреймов теста BBG. Там же снапшот состояния, с которого трейсинг стартовал. Формат такой: до двоеточия стоит адрес инструкции, после двоеточия следует полный оп-код инструкции, в скобках указан номер такта во фрейме до исполнения инструкции.
Не забудьте пропустить первые фреймы синхронизации.
Я имел в виду, что задержки вывода в порт считаются по паттернам. Все эти паттерны подразумевают, что цикл вывода длиной в 4 такта.Цитата:
Сообщение от Vladimir Kladov
За KAZ6 спасибо.Цитата:
Сообщение от Vladimir Kladov
С MEGACLR странная история. На Higgins и Fuse в режиме 48K после загрузки черный экран без признаков жизни. На Fuse в режиме 128K прокручивает снизу вверх текст из цветных квадратов, без всяких бордюрных эффектов. По описанию ("угребище") -- похоже, но тем не менее.
Да, пожалуйста.Цитата:
Сообщение от Vladimir Kladov
На всякий случай дам ссылку:Цитата:
Сообщение от Vladimir Kladov
http://www.worldofspectrum.org/forum...ad.php?t=20345
Попробовал убрать влажок H из инструкции AND. Тест на флаги это обнаружил, на остальных инструкциях ошибок не дал. Тест на MEMPTR тоже ошибок не дал.Цитата:
Сообщение от Vladimir Kladov
Попробовал изменить вычисление значения MEMPTR для LDIR/LDDR чтобы прибавлял 2 к значению PC. Тест на флаги прошел без ошибок. В тесте на MEMPTR LDIR (BC > 1) и LDDR (BC > 1) дали ошибки, все остальные инструкции прошли без ошибок.
Ну, вам в помощи здесь никто не отказывает. А игрушка... не хуже других. ;-)Цитата:
Сообщение от Vladimir Kladov
Минуточку. В этом документе сказано, что если была прервана одна из этих инструкций, т.е. прерывание было принято перед ее исполнением, то флаг P/V получит уже сброшенное значение IFF2. Более того, сайте WOS подчеркнуто, что это обстоятельство является следствием того факта, что прерывания начинаются со сброса IFF1 и IFF2. То есть это не то что на баг не похоже, это даже не особый случай.Цитата:
Сообщение от ARTi
А Владимир пишет совсем по-другому:
Цитата:
Сообщение от Vladimir Kladov
Обновление памяти -- это всегда только один такт в цикле выборки. Больше оно не длится. Но само значение IR остается на адресной шине. И пока I лежит за пределами области задержек, это не заметно.Цитата:
Сообщение от ARTi
На сайте WOS задержки на IR просто не учтены, M1 не является чем-то особенным с точки зрения ULA, если не обращать внимания на уровень ~MREQ в начале T4.
Автоматический или полуручной интересует? Автомат почти никак нельзя сделать внешним, в виде отдельного экзешника. А полуручной - запросто.Цитата:
Сообщение от Shadow Maker
Обновить драйверы OpenGL, то бишь взять драйверы от производителя видеокарты, а не от микросовт. Или посмотреть, нет ли на переднем плане чужого окошка типа часиков, которое постоянно пытается себя показать поверх окна OpenGL.Цитата:
Сообщение от Rene Sens
Нет, там описано только официальное поведение: "During LD A, I and LD A, R instructions, the P/V Flag is set with the valueЦитата:
Сообщение от ARTi
of the interrupt enable flip-flop (IFF2) for storage or testing." И там ничего не говорится о ситуации, когда в P/V попадает 1 при активном INT. Так что это именно баг, противоречащий официальному описанию.
Ну как же не могло? Вот например 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 не надо.Цитата:
Сообщение от Higgins
Вот, я реализовал правильно IO контенции, и всё пошло (кроме sidewize) как и должно, и задержки IR не потребовались. Что касается сидвиз, то я конечно понимаю, что ничего не понимаю в том, какие байты именно и как долго читаются улой на шину, чтобы правильно сэмулировать in по несуществующему порту, но floatspy говорит, что шина в порядке. Значит, этот тест тоже надо выкинуть в корзину.
P.S. Насчёт интры megaclr я извиняюсь, это пентагоновская интра, и мультиколор там пентагоновский.
Вопросы к народу. Я нашёл, что в Скорпионе турбо выключается просто чтением из порта 1FFD. А включается как - так же?
Обнаружил, что неправильно понял раскладку битов по порту EFF7. Бит 0 оказался ответственным за режим 256х192х16с, а как же тогда включать атрибут на байт, тумблером только? Ещё бит 4 получается, отвечает за турбу в пентагоне, причём 0-вкл, 1-выкл. Верно? (хотя мне это не нравится совершенно. Получается, что порт надо инициализировать 1 в бите 4, или при ресете включать турбу). Я пока не меняю, оставил как в прошлый раз.
Я сейчас выкладываю версию 211К. В основном небольшие поправки, но добавлена гамма-коррекция, и автоматическое выезжание меню.
Вот оно как. Раскрыл глаза пошире и увидел на диаграммах то, что раньше не видел :) Очередное Вам спасибо.Цитата:
Сообщение от Higgins
Спасибо за правильную ссылку. Наконец-то и описание EX (SP),HL без ошибок, и учет IR:x. Я все не мог понять, почему (в смысле зачем) ULA 48k отличает M1 от обычного доступа к памяти. А оказывается, не отличает. Теперь многое встало на свои места.Цитата:
Сообщение от Higgins
Вы имеете в виду при активном ~INT, но запрещенных прерываниях?Цитата:
Сообщение от Vladimir Kladov
Если прерывания разрешены, то в P/V должна попадать 1, это документированное поведение. Если прервана сама команда получения IFF2, тогда 0. Я не зря указал нужные страницы, там написано
Но похоже мы не понимаем друг друга. Уточните, пожалуйста, подробности "бага", о котором Вы говорите.Код:If an interrpt occurs during execution of this instruction, the Parity flag contains a 0
Включается вроде чтением из #7FFD.Цитата:
Сообщение от Vladimir Kladov
Вообще-то при любых. Просто сигнал инта сам учитывается, только кроме случая, когда предыдущая команда была EI.Цитата:
Сообщение от ARTi
Точно? Или коза в огороде? Я же горы документации перерыл, практически ничего не нашёл. Особенно беполезно читать фирменные описания, там про это вообще ни слова.Цитата:
Сообщение от ARTi
Добавлено через 10 минут
Не нашёл ни одного ввода из нечётных портов. Если бы они были, наверняка долго искать не пришлось бы.Цитата:
Сообщение от goodboy
Turbo включается чтением из порта #7ffd,Цитата:
Сообщение от Vladimir Kladov
выключается чтением из порта #1ffd
и переключается при нажатии кнопки "Turbo/Normal".
Кнопка опрашивается 50 раз в секунду.
(Это всё видно из схемы ;) )
Взято отсюда (первоначально), а также отсюда и отсюда. Проверка информации в www.google.com очень эффективна, и никаких коз.Цитата:
Сообщение от Vladimir Kladov
в оригинале по адресу 40180Цитата:
Сообщение от Vladimir Kladov
BC,#40FF
E,#40
A,R
IN A,(C)
CP E
JR NZ ( на адрес где A,R)
А у меня фигня какая-тоЦитата:
Сообщение от goodboy
LD BC,40FF
E,40h
DEC E
LD A,E
JR NZ,9CF9
NOP
NOP
...
Попробую заменить.
Добавлено через 11 минут
ой, что=то совсем интересное... Где бы поподробнее почитать про чтение 7FFD через порты аюгрека... Я схемы не понимаю, они для меня молчат. И что? Кто-то понимает японские иероглифы? Все врубаются в нотую азбуку? Или все умеют программировать? Хотите нормальныъ эмуляторов - пишите нормальные доки. Авторам эмуляторов не надо рассказывать какие ноги у каких микросхем резать и припаивать. Нам надо по-простому: при выводе бита N в порт P впечатывается страница X. При выполнении инструкции по адресу A происходит такое-то явление. А ноги, хвосты, канифоль - мне это неинтересно.Цитата:
Сообщение от ARTi
Вот и напрасно "неинтересно". Правильно работающий эмулятор устройства можно разработать только хорошо представляя как эмулируемое устройство внутри работает.Цитата:
Сообщение от Vladimir Kladov
А по идеологии "вывод бита N в порт P" потом как раз и начинается всякая мистика.
PS: кстати, даже пресловутый memptr который с боями "открыли" не так давно спокон веку был нарисован на блок-схеме i8080. И он название даже официальное имеет, "M" :-) Вот это к вопросу как раз о канифоли. Загляни разработчик эмулятора поглубже в документацию - половину проблем бы отшибло.
можете удалить, я скачал на всякий случай. Впрочем, работает теперь как надо (но пришлось одну строчку подправить). И заодно нашёл, что этот tzx какой-то не такой, и у меня почему-то не грузится. Ага, непонятки в описании TZX. Пишут длина 10, не указывают что 16-ричное, т.е. 16, хотя сверху не написано явно, что формат длины десятичный. Оно вроде бы и не надо, длина обычно несколько байтов, но вот в этом случае оказывается надо.Цитата:
Сообщение от goodboy
Но для этого необязательно читать схемы. Вы машину водите? А двигатель разбирать умеете (а потом собирать, и чтобы гаек лишних не оставалось?) У меня математическое образование. Как думаете, сколько всякой ненужной ерунды удерживает моя голова? Вы, например, помните определение производной функции в точке? А я помню... Я ещё когда-то и преподавал это в вузе... Для того чтобы написать эмулятор, надо иметь толковое описание устройства. Схема не всегда поможет, там есть элементы интегральной логики, из схемы вам никто не расскажет, как работает AY или ULA. То, что там было нарисовано на схеме процессора Z80, можете выкинуть в корзину и забыть. Из этой принципиальной схемы логику memptr узнать невозможно. Только хитростью boo-boo, сумевшего подобрать тесты, расколовшие этот регистр. И, кстати, далеко не всегда поведение memptr укладывается в нормальную человеческую логику.Цитата:
Сообщение от ram_scan
Родной, в той статье со схемой в конце все, что надо, есть. Статья совсем маленькая, не потрудитесь дочитать до конца. Я ее привел не как основной источник, а как подтверждающий, тем более она настолько мала, что мне и в голову не пришло уточнять конкретное в ней место. Так что не надо придираться.Цитата:
Сообщение от Vladimir Kladov
Не понял, давайте-ка поподробнее. Это что, Вы тут делаете нам всем одолжение?Цитата:
Сообщение от Vladimir Kladov
Разговор был о том, что информация верна и что это легко проверить при помощи простых и доступных средств (если у Вас есть Интернет). А не о том, что мои высказывания каким-то образом Вас задевают, и Вам поэтому необходимо прямо тут на страницах форума как-то отреагировать, чтобы поддержать свою репутацию.
P.S. Все-таки такого я от Вас не ожидал. Вроде даже преподавали в вузе - а ведь считается, что именно там люди учатся находить информацию, также предполагается,что преподаватели умеют. Как же Вы тогда перерываете "горы документации", и что это за "горы" такие?
Если я Вас задел - простите. Для меня подобный процесс еще полезен (стимул к работе над собой), а для Вас, видимо, уже нет, я не подумал об этом. Простите, пожалуйста.
Все равно пришлось бы проверять, что в Z80 это осталось без изменений, хотя да - времени на проверку ушло бы гораздо меньше, чем на полноценное исследование "черного ящика". Можно, пожалуйста, ссылку?Цитата:
Сообщение от ram_scan
Цитата:
Сообщение от Vladimir Kladov
Господа программисты, не заводитесь. С доками на Спектруме действительно хреново. Наиболее качественные доки конечно на WoS'e, но и там многого нет, а про отечественную технику вообще молчу - в ней разбираться можно только со схемами, да и то в них до сих пор ошибки находят (например в той-же схеме Скорпа). Даже о документации АТМ, несмотря на то, что это один из лучших по документированности компьютеров, нельзя сказать что написана она толково, а об описаниях в отечественной электронной прессе я вообще молчу. В отечественной zxвики вы тож ничего конкретного не найдёте, окомя автобиографических опусов.. Вот и получается, что каждый раз приходится спрашивать одно и то-же, т.к. систематизированной достоверной документации (кроме отчасти схем) попросту нет.Цитата:
Сообщение от ARTi