Вид для печати
Интересует, как будет работать следующий кусок кода на реале и разных эмулях:
Смысл, думаю понятен. Как будет работать выполнение ОЧЕНЬ длинной команды (в смысле взаимодействия с системой прерываний и т.д.Код: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 проканала %)
Тут кто то спрашивал как эмули можно обнаружить? ;-)
Вот я о том же. У него идет непрерывная выборка префиксов до получения КОП (если мне не изменяет склероз).Цитата:
Сообщение от GriV
Vitamin, Итак ... сли сделать "0DDH,0FDH" 100 раз, а потом "3", то получается 1602 такта. Проверял на "Zilog Z84H", бак же я делал в своём эмуляторе, там такая же картина. Смысл таков: если встречается "0DDH,0FDH", то на это тратится 4*2 такта и PC устанавливается на "0FDH". Прерывания исполняются безотказно безо всяких ошибок. Дома есть "Thomphson Z80A", завтра возьму на работу и попробую что на нём. Но мне кажется, что картна будет та же.
Т.е. есть отдельный контроль на чередование префиксов? А если префиксы будут дублироватсья? Например, в моем исходнике сделать префиксы одинаковыеЦитата:
Сообщение от Robus
Добавлено через 1 минуту
Какая же я деструктивная личность :))))) Просто стало интересно, как будут себя вести эмули и _как должны_ себя вести по идее.Цитата:
Сообщение от GriV
и ZX SPIN 0.622 и Klive 1.1 открывают этот снапшот и никаких ошибок не выдают.
Тут скорее не "обнаружить" а "обрушить" :)Цитата:
Сообщение от GriV
Стоп. Из всех эмулей протестированных только EmuZWin глючило остальные отрабатывали. НО они видели эти #FD #DD как одну команду а не как несколько команд (как это делает реал и R80). Надо в отладчике посмотреть что он видит начиная с адреса #C000. Весьма вероятно что будет 1) проблема с тем, чтобы залезть в отладчик 2) проблем в отладчике что он будет видеть это как одну большую команду.Цитата:
Сообщение от ZEman
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 ставится на следующий байт сразу после префикса?
Кстати, очень здравое и разумное решение, если это реально так. Логика действенна для 2 из 4 префиксов (#ED не может дублироваться, если мне не изменяет склероз). Вопрос о "стоимости" в тактах по прежнему открыт :)Цитата:
Сообщение от ARTi
Если мне не изменяет память, в результате своих давнишних экспериментов на реале я выяснил, что:
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) не производится.
Надо будет напридумать простеньких прожек для проверки, навроде таких, и хорошо попросить товарища 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
Как всегда, просьба замерить время между спадающими фронтами WR (короче, период). А также: в первом варианте бордюр должен быть постоянно одного цвета (вроде белого). Как ведет себя бордюр во втором варианте?Код: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
Неприятный побочный эффект: через динамик будет слышен звук определенной частоты (~2 кГц) ;), т.к. содержимое регистра R полностью транслируется в порт #FE без изменений. Кстати, как частота тона будет отличаться во втором случае?
Заранее спасибо за содействие!
Ага, при том, что у меня нет осцилла... :biggrin:Цитата:
Сообщение от ARTi
Только потому, что мне это тоже интересно:
var1 - 60 тактов,
var2 - 56 тактов.
Z0840004PSC (9011)
US0.36.7 ведёт себя также:Цитата:
Сообщение от ARTi
var1 - бордюр белый (R+8),
var2 - цвет "уменьшается на еденицу" (R+7).
~14-15 kHzЦитата:
Сообщение от ARTi
Опа...
Я похоже совсем в тот день пересидел на работе, что-то не совсем то написал, что хотел ;)
Однако все равно определенную часть картины это подтверждает. В случае с #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
В обоих ли случаях бордюр белый? Время между WR-ами одно и то же или разное?Код: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
А как Вы это тогда делаете?Цитата:
Ага, при том, что у меня нет осцилла...
var1: 48 тактов, бордюр белый.
var2: 44 такта, цвет_бордюра-1.
cpu: тот же.
А у нас так глаз пристрелявши. :v2_wink2:Цитата:
Сообщение от ARTi
Прочитал тред. Не смешно. Длинная команда выполняется как серия коротких это известно давным давно. Соответственно, если "длинная" команда после очередного выполнения затирает себя (например), то на следующей итерации выполняется уже модифицированная команда. И прерывания обрабатываются как после обычной короткой команды LDI.
Короче: LDIR = LDI;PC=PC-2. И точка. Осциллографом тыкать сразу - нет чтобы доки почитать...
Это уж давно известно. Вопрос стоял про выполнение НЕ ИТЕРАТИВНЫХ команд, а именно цепочки префиксов.Цитата:
Сообщение от Vladimir Kladov
Vladimir Kladov
Мне бы эту гениальную мысль, да лет 10 назад... а что теперь прошлое ворошить...Цитата:
Короче: LDIR = LDI;PC=PC-2. И точка.
Честно-честно?Цитата:
Прочитал тред
Ну-ну, зачем же так злобно... Лучше на работе долго не задерживаться, да спать побольше, а еще на людей, которые раздражают и злят, не обращать особого внимания, тогда и настроение гораздо лучше будет, и быть может производительность повысится до версии 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
Если все предполагалось верно, тогда в обоих случаях бордюр должен быть постоянно белым и кол-во тактов между WR должно быть 81. Чуть позже наваяю поверку прерываний.Код: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
Никаких "PC-=1"!
В обоих вариантах период 60 тактов.
Цвет брдюра -= 5 (R+=11).
(в US0367 аналогично)
The Undocumented Z80 Documented (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:
Изначально меня интересовало, как ведет себя процессор при выполнении особо длинной цепочки префиксов, в частности, поведение при приходе прерывания (см. первый пост).Цитата:
Сообщение от DDp
ARTi для проверки идеи насчет уменьшения РС накидал примеры, косвенно проверяющие на основе изменения регистра R. Вот и все :)
(Угу, пропустил начало)Цитата:
Сообщение от Vitamin
(по-экспериментировал на реале) Во время длинной последовательности префиксов прерывания не срабатывают.
US 0.36.7 внешне ведёт себя как реал (вот только вешается при SoundDrv=ds)
В отладчик дает зайти? (см. сообщения GriV'а о поведении эмуляторов)Цитата:
Сообщение от DDp
опа! интересно!Цитата:
(по-экспериментировал на реале) Во время длинной последовательности префиксов прерывания не срабатывают.
надо будет расконсервировать kay и убедиться воочию ;)
В отладчик входит (PC=FB01).Цитата:
Сообщение от Vitamin
Пошагово последовательность префиксов выполняется как одна комманда.
Отображается как попало (короткий буфер???).
И ещё...
На реальном проце поведение сигналов M1 и RFSH на последовательности префиксов такое же, как на последовательности NOP-ов.
Мда... Жаль, что у меня пока нет такой возможности - убедиться воочию. А то теперь у меня возник серьезный вопрос к самому себе: каким местом я экспериментировал/анализировал результаты, когда у меня был реал??? Хотя небольшое оправдание мне все же есть:
Неужели зависит от производителя/модели процессора? =-OЦитата:
Сообщение от Robus
Бл*ха-муха, надо срочно вспоминать тонкости работы с прерываниями и написать автоматизированный тест, да восстановить валяющийся где-то реал (128K, нет шнура для соединения с видео)... Простите за мой французский...
Вообще зашибись... Теперь в эмуляторах можно будет выбирать тип кристалла :-D
В чем там еще различия выявлялись? В обработке секретного внутреннего регистра MEMPTR?
Ага, именно, но там проще - пара команд типа LD A,(nn)/(nn),A и еще какой-то, да и с типами кристаллов полегче T34 и неT34 :-D
Добавлено через 2 минуты
И вообще вроде T34 даже как-то по-особенному выставляют какой-то флаг при выполнении команды DAA, так что у этих резон быть отличными от других есть...
я думаю следует отличать что видно в дебагере и как это обрабатывает эмулятор. В ZXMAK.NET дебагер отображает это как одну инструкцию. И при выполнении Step Into будет выполнена вся эта последовательность за раз. Но движок на самом деле выполняет это за множество шагов. Просто при выполнении Step Into в отладчике стоит цикл вызывающий ExecCycle до тех пор пока взведены флаги префиксов.Цитата:
Сообщение от GriV
Сделано для удобства отладки, т.к. смотреть промежуточные состояния процессора в отладчике было бы несколько экстравагантно :)