Просмотр полной версии : Crash-test
Интересует, как будет работать следующий кусок кода на реале и разных эмулях:
org 24576
ld hl,freestart
fill:ld (hl),#dd
inc hl
ld (hl),#fd
inc hl
ld a,h
and a
jr nz,fill
ld hl,testcode
ld de,testcode-freestart
ld bc,freestart-testcode
ldir
jr freestart
testcode:
ld hl,0
ld a,2
out (254),a
xor a
ld b,a
djnz $
djnz $
out (254),a
jp freestart
freestart:
Смысл, думаю понятен. Как будет работать выполнение ОЧЕНЬ длинной команды (в смысле взаимодействия с системой прерываний и т.д.
Должны пропускаться как NOP'ы. В своё время даже это использовалось в защите коммерческих программ - тупые отладчики вешались на такой последовательности (DoS атака отладчиков :-D). R80 определяет их как NOPI (в отличие от стандартных NOP), каждый NOPI 4 такта. Unreal (0.2.1) определяет их как одну команду. Проверять на прерывания ломает... хотя ладно счас...
гыгы Unreal вообще глючит на таких командах, даже в отладчик выйти не может (DoS проканала :-D). Прикрепляю SNAP, тестируйте где хотите :-)
Гыгы, ещё одна DoS проканала :-D EmuZWin вешается на приходе прерывания (когда полоска внизу экрана), причём выдается ошибку ("программа будет закрыта").
RealSpec (у меня достаточно древняя версия) тоже глючит, он принимает эту команду как одну, со всеми вытекающими - даже в меню надо попасть умудриться в промежуток когда он отрисует бордюр, во время выполнения длинной команды он ничего не позволяет нажать %). Ещё одна DoS проканала %)
Тут кто то спрашивал как эмули можно обнаружить? ;-)
Unreal вообще глючит на таких командах
Вот я о том же. У него идет непрерывная выборка префиксов до получения КОП (если мне не изменяет склероз).
Vitamin, Итак ... сли сделать "0DDH,0FDH" 100 раз, а потом "3", то получается 1602 такта. Проверял на "Zilog Z84H", бак же я делал в своём эмуляторе, там такая же картина. Смысл таков: если встречается "0DDH,0FDH", то на это тратится 4*2 такта и PC устанавливается на "0FDH". Прерывания исполняются безотказно безо всяких ошибок. Дома есть "Thomphson Z80A", завтра возьму на работу и попробую что на нём. Но мне кажется, что картна будет та же.
Смысл таков: если встречается "0DDH,0FDH", то на это тратится 4*2 такта и PC устанавливается на "0FDH"
Т.е. есть отдельный контроль на чередование префиксов? А если префиксы будут дублироватсья? Например, в моем исходнике сделать префиксы одинаковые
Добавлено через 1 минуту
Тут кто то спрашивал как эмули можно обнаружить? ;-)
Какая же я деструктивная личность :))))) Просто стало интересно, как будут себя вести эмули и _как должны_ себя вести по идее.
и ZX SPIN 0.622 и Klive 1.1 открывают этот снапшот и никаких ошибок не выдают.
Тут кто то спрашивал как эмули можно обнаружить?
Тут скорее не "обнаружить" а "обрушить" :)
и ZX SPIN 0.622 и Klive 1.1 открывают этот снапшот и никаких ошибок не выдают.
Стоп. Из всех эмулей протестированных только EmuZWin глючило остальные отрабатывали. НО они видели эти #FD #DD как одну команду а не как несколько команд (как это делает реал и R80). Надо в отладчике посмотреть что он видит начиная с адреса #C000. Весьма вероятно что будет 1) проблема с тем, чтобы залезть в отладчик 2) проблем в отладчике что он будет видеть это как одну большую команду.
zemu - всё работает (следует сказать спасибо boo_boo за отличную либу z80ex)
в дебаге видно как куча NOP* , при пошаговом исполнении проскакивает через несколько комманд.
Меня интересует вопрос прихода прерывания во время выполнения этой длинной команды. Сыгнорируется ли оно, если сигнал закончится до окончания. Если выполнится, то куда будет указывать адрес возврата, есть ли некий флаг, указывающий с каким из регистров (IX/IY) будет идти работа.
Меня интересует вопрос прихода прерывания во время выполнения этой длинной команды.
кстати интерестно как отреагирует на это реал.
жалко что мой кай сейчас без моника...
хым,
я вот так думаю.
Команда LD IX,#ABCD не может быть прервана, так что прерывание не может на неё прийти. Однако что будет если перед #DD будет стоять ещё и #FD не знаю.
Я тут всё пытаюсь отладить программу которая на реале бы проверила действие этого мегафрукта - набора префиксов команд. Как наберу скажу что и как.
Судя по поведению некоторых эмуляторов, выполнение операций с префиксами не является атомарным (по меньшей мере, с точки зрения инфраструктуры эмулятора- иначе бы все затыкались). Вопрос о точке зрения процессора остается открытым.
GriV,
Проверь, плз на одинаковых префиксах и чередующихся- может быть разное поведение.
Насколько я понял, приход префикса в префиксе уменьшает PC на 1 и все, при этом тратится 8 тактов. Соответственно, прерывания никто не запрещает, два префикса выполняются как команда уменьшения PC на 1.
P.S. Кстати вдруг стало интересно. Засекали ли время выполнения команд, префиксирование которых ничего не дает? Например, команда EX DE,HL не превращается в EX DE,IX/IY, значит ли это, что, встретив "неверный" КОП для определенного префикса (в т.ч. и другой префикс кроме 0xCB), Z80 просто уменьшает PC на 1, отчего PC ставится на следующий байт сразу после префикса?
встретив "неверный" КОП для определенного префикса (в т.ч. и другой префикс кроме 0xCB), Z80 просто уменьшает PC на 1, отчего PC ставится на следующий байт сразу после префикса?
Кстати, очень здравое и разумное решение, если это реально так. Логика действенна для 2 из 4 префиксов (#ED не может дублироваться, если мне не изменяет склероз). Вопрос о "стоимости" в тактах по прежнему открыт :)
Если мне не изменяет память, в результате своих давнишних экспериментов на реале я выяснил, что:
1. Последовательности вроде
PC+0: #DD/#FD
PC+1: #недопустимый КОП (в т.ч. #ED, #DD, #FD) поправка - к #ED не относится, см ниже
PC+2: #xx
в результате ставят PC на PC+1, tacts = tacts+8. Но на сколько увеличивается R - на 1 или 2 - я тогда, тупица, не посмотрел... предположительно на 2 все-таки. При этом сбоев функционирования прерываний при моих экспериментах я не заметил. Хороший, однако, Фаджин придумал "workaround" ;)
2. Последовательность
PC+0: #ED
PC+1: #ED/#DD/#FD
PC+2: #xx
работает как 8-тактный NOP, т.е. PC ставится на PC+2, tacts = tacts+8. Регистр R предположительно должен увеличиваться на 2, т.к. в данном случае никаких специальных действий (типа отката как в случае с #DD/#FD) не производится.
Надо будет напридумать простеньких прожек для проверки, навроде таких (http://zx.pk.ru/showpost.php?p=113069&postcount=26), и хорошо попросить товарища DDp проверить (и сделать замеры) на реале :).
Добавлено через 15 часов 2 минуты
Итак, начнем.
Господин DDp или кто-нибудь еще! Если есть возможность, запустите, пожалуйста, на реале вот такие 2 программулины:
ORG #8000
LD HL, 0
XOR A, A
LD R, A
DI
DB #00 ; R += 1
DB #00 ; R += 1
LD BC, (#8000) ; R += 2
LD A, R ; R += 2
OUT (#FE), A ; R += 1
JR $-10 ; R += 1
и
ORG #8000
LD HL, 0
XOR A, A
LD R, A
DI
DB #DD ; R += 2 ???
LD BC, (#8000) ; R += 2
LD A, R ; R += 2
OUT (#FE), A ; R += 1
JR $-9 ; R += 1
Как всегда, просьба замерить время между спадающими фронтами WR (короче, период). А также: в первом варианте бордюр должен быть постоянно одного цвета (вроде белого). Как ведет себя бордюр во втором варианте?
Неприятный побочный эффект: через динамик будет слышен звук определенной частоты (~2 кГц) ;), т.к. содержимое регистра R полностью транслируется в порт #FE без изменений. Кстати, как частота тона будет отличаться во втором случае?
Заранее спасибо за содействие!
Господин DDp или кто-нибудь еще! Если есть возможность, запустите, пожалуйста, на реале вот такие 2 программулины:
...
Как всегда, просьба замерить время между спадающими фронтами WR (короче, период).
Ага, при том, что у меня нет осцилла... :biggrin:
Только потому, что мне это тоже интересно:
var1 - 60 тактов,
var2 - 56 тактов.
Z0840004PSC (9011)
А также: в первом варианте бордюр должен быть постоянно одного цвета (вроде белого). Как ведет себя бордюр во втором варианте?
US0.36.7 ведёт себя также:
var1 - бордюр белый (R+8),
var2 - цвет "уменьшается на еденицу" (R+7).
Неприятный побочный эффект: через динамик будет слышен звук определенной частоты (~2 кГц)
~14-15 kHz
Опа...
Я похоже совсем в тот день пересидел на работе, что-то не совсем то написал, что хотел ;)
Однако все равно определенную часть картины это подтверждает. В случае с #DD/#FD + #ED никакого отката не происходит, все как и надо. А я что написал? Сейчас подправлю, приношу извинения за дезинформацию... R увеличивается как и надо, такты - тоже. Только я чего-то не въехал, почему частота-то такая большая?..
Только потому, что мне это тоже интересно
Если у Вас еще не пропал интерес, то теперь будет самое интересное :). Просьба - та же:
ORG #8000
LD HL, 0
XOR A, A
LD R, A
DI
DB #00 ; R += 1
DB #00 ; R += 1
DB #00 ; R += 1
EX DE, HL ; R += 1
LD A, R ; R += 2
OUT (#FE), A ; R += 1
JR $-8 ; R += 1
и
ORG #8000
LD HL, 0
XOR A, A
LD R, A
DI
DB #00 ; R += 1
DB #DD ; R += 2 ???
EX DE, HL ; R += 1
LD A, R ; R += 2
OUT (#FE), A ; R += 1
JR $-7 ; R += 1
В обоих ли случаях бордюр белый? Время между WR-ами одно и то же или разное?
Ага, при том, что у меня нет осцилла...
А как Вы это тогда делаете?
var1: 48 тактов, бордюр белый.
var2: 44 такта, цвет_бордюра-1.
cpu: тот же.
А как Вы это тогда делаете?
А у нас так глаз пристрелявши. :v2_wink2:
Vladimir Kladov
06.02.2008, 21:46
Прочитал тред. Не смешно. Длинная команда выполняется как серия коротких это известно давным давно. Соответственно, если "длинная" команда после очередного выполнения затирает себя (например), то на следующей итерации выполняется уже модифицированная команда. И прерывания обрабатываются как после обычной короткой команды LDI.
Короче: LDIR = LDI;PC=PC-2. И точка. Осциллографом тыкать сразу - нет чтобы доки почитать...
Короче: LDIR = LDI;PC=PC-2
Это уж давно известно. Вопрос стоял про выполнение НЕ ИТЕРАТИВНЫХ команд, а именно цепочки префиксов.
Vladimir Kladov
Короче: LDIR = LDI;PC=PC-2. И точка.Мне бы эту гениальную мысль, да лет 10 назад... а что теперь прошлое ворошить...
Прочитал тредЧестно-честно?
Осциллографом тыкать сразу - нет чтобы доки почитать...Ну-ну, зачем же так злобно... Лучше на работе долго не задерживаться, да спать побольше, а еще на людей, которые раздражают и злят, не обращать особого внимания, тогда и настроение гораздо лучше будет, и быть может производительность повысится до версии 2.8 (а то и 3.0) :).
А то будете как я 4-мя постами выше :biggrin:
DDp
Вы как всегда на высоте, примите мои благодарности (кстати, что я могу для Вас сделать?). Этот тест был на то, правильно ли мы думаем(ли) о командах, на которые префиксы #DD/#FD не влияют. Итого осталось уточнить, как реагируют префиксы #DD/#FD на длинную цепочку из самих себя. С тактами вроде ясно и с регистром R почти понятно, но на всякий случай лучше проверить. Это несложно. А вот с прерываниями будет небольшая рутина...
А у нас так глаз пристрелявши.Круто! Я даже прочувствовал то самое давно забытое ощущение возбуждения от созерцания подобных полосок :)))
Итак, продолжаем. (Может удобнее будет, если я сразу коды забабах*ю? ;) ). Следующая пара прожек:
ORG #8000
XOR A, A
LD R, A
DI
DB #FD ; R += 1
DB #DD ; R += 1, PC -=1, R += 1 ???
DB #FD ; R += 1, PC -=1, R += 1 ???
DB #DD ; R += 1, PC -=1, R += 1 ???
DB #FD ; R += 1, PC -=1, R += 1 ???
DB #DD ; R += 1, PC -=1, R += 1 ???
DB #00 ; R += 1
LD A, R ; R += 2
OUT (#FE), A ; R += 1
JR $-11 ; R += 1
и
ORG #8000
XOR A, A
LD R, A
DI
DB #DD ; R += 1
DB #DD ; R += 1, PC -=1, R += 1 ???
DB #DD ; R += 1, PC -=1, R += 1 ???
DB #FD ; R += 1, PC -=1, R += 1 ???
DB #FD ; R += 1, PC -=1, R += 1 ???
DB #FD ; R += 1, PC -=1, R += 1 ???
DB #00 ; R += 1
LD A, R ; R += 2
OUT (#FE), A ; R += 1
JR $-11 ; R += 1
Если все предполагалось верно, тогда в обоих случаях бордюр должен быть постоянно белым и кол-во тактов между WR должно быть 81. Чуть позже наваяю поверку прерываний.
Никаких "PC-=1"!
В обоих вариантах период 60 тактов.
Цвет брдюра -= 5 (R+=11).
(в US0367 аналогично)
The Undocumented Z80 Documented (http://www.myquest.nl/z80undocumented/z80-documented-v0.91.pdf) (by Sean Young) так же подтверждает это:
3.7. ... FD or DD should be seen as prefix setting a flag which says “use IX or IY in
stead of HL”, and not an instruction. In a large sequence of DD and FD bytes,
it is the last one that counts. Also any other byte (or instruction) resets this flag.
DDp,
Значит дело в некорректной эмуляции данной цепочки эмуляторами.
Имхо, z80_ex (c) boo_boo делает это наиболее точным образом- прерывания перекрываются внутренним флагом процессора, а не физическим DoS :)
Vitamin,
вы о чём?
Проверил на реале 2 последних фрагмента из поста #22.
Какие прерывания?
:v2_wacko: пошёл курить тему с начала. :v2_wink2:
вы о чём?
Изначально меня интересовало, как ведет себя процессор при выполнении особо длинной цепочки префиксов, в частности, поведение при приходе прерывания (см. первый пост).
ARTi для проверки идеи насчет уменьшения РС накидал примеры, косвенно проверяющие на основе изменения регистра R. Вот и все :)
Изначально меня интересовало, как ведет себя процессор при выполнении особо длинной цепочки префиксов, в частности, поведение при приходе прерывания
(Угу, пропустил начало)
(по-экспериментировал на реале) Во время длинной последовательности префиксов прерывания не срабатывают.
US 0.36.7 внешне ведёт себя как реал (вот только вешается при SoundDrv=ds)
US 0.36.7 внешне ведёт себя как реал
В отладчик дает зайти? (см. сообщения GriV'а о поведении эмуляторов)
(по-экспериментировал на реале) Во время длинной последовательности префиксов прерывания не срабатывают.
опа! интересно!
надо будет расконсервировать kay и убедиться воочию ;)
В отладчик дает зайти?
В отладчик входит (PC=FB01).
Пошагово последовательность префиксов выполняется как одна комманда.
Отображается как попало (короткий буфер???).
И ещё...
На реальном проце поведение сигналов M1 и RFSH на последовательности префиксов такое же, как на последовательности NOP-ов.
Мда... Жаль, что у меня пока нет такой возможности - убедиться воочию. А то теперь у меня возник серьезный вопрос к самому себе: каким местом я экспериментировал/анализировал результаты, когда у меня был реал??? Хотя небольшое оправдание мне все же есть (http://zx.pk.ru/showpost.php?p=117032&postcount=4):
Vitamin, Итак ... сли сделать "0DDH,0FDH" 100 раз, а потом "3", то получается 1602 такта. Проверял на "Zilog Z84H", бак же я делал в своём эмуляторе, там такая же картина. Смысл таков: если встречается "0DDH,0FDH", то на это тратится 4*2 такта и PC устанавливается на "0FDH". Прерывания исполняются безотказно безо всяких ошибок. Дома есть "Thomphson Z80A", завтра возьму на работу и попробую что на нём. Но мне кажется, что картна будет та же.
Неужели зависит от производителя/модели процессора? =-O
Бл*ха-муха, надо срочно вспоминать тонкости работы с прерываниями и написать автоматизированный тест, да восстановить валяющийся где-то реал (128K, нет шнура для соединения с видео)... Простите за мой французский...
Вообще зашибись... Теперь в эмуляторах можно будет выбирать тип кристалла :-D
В чем там еще различия выявлялись? В обработке секретного внутреннего регистра MEMPTR?
Ага, именно, но там проще - пара команд типа LD A,(nn)/(nn),A и еще какой-то, да и с типами кристаллов полегче T34 и неT34 :-D
Добавлено через 2 минуты
И вообще вроде T34 даже как-то по-особенному выставляют какой-то флаг при выполнении команды DAA, так что у этих резон быть отличными от других есть...
Стоп. Из всех эмулей протестированных только EmuZWin глючило остальные отрабатывали. НО они видели эти #FD #DD как одну команду а не как несколько команд (как это делает реал и R80). Надо в отладчике посмотреть что он видит начиная с адреса #C000. Весьма вероятно что будет 1) проблема с тем, чтобы залезть в отладчик 2) проблем в отладчике что он будет видеть это как одну большую команду.
я думаю следует отличать что видно в дебагере и как это обрабатывает эмулятор. В ZXMAK.NET дебагер отображает это как одну инструкцию. И при выполнении Step Into будет выполнена вся эта последовательность за раз. Но движок на самом деле выполняет это за множество шагов. Просто при выполнении Step Into в отладчике стоит цикл вызывающий ExecCycle до тех пор пока взведены флаги префиксов.
Сделано для удобства отладки, т.к. смотреть промежуточные состояния процессора в отладчике было бы несколько экстравагантно :)
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot