Невероятно, но - факт! Провел подряд несколько тестов и все ОК!
Дема называется Blava demo. При переходе к части 3 практически всегда сбрасывалась. 1-го такта не хватало!
Вид для печати
Невероятно, но - факт! Провел подряд несколько тестов и все ОК!
Дема называется Blava demo. При переходе к части 3 практически всегда сбрасывалась. 1-го такта не хватало!
может, его еще из-за чего-то не хватало? очень странно -- в официальном мануале говорится, что при запросе вектора прерывания добавляется 2 wait-a (что отражено на диаграмме), в z80undocumented прямо сказано, что IM0 с RST -- 13 тактов... при этом согласно доке с расписанными циклами, для CALL -- 2 wait'a, а для RST, выходит, 1? CPU ж не знает, что к нему придет, откуда такая дискриминация? ИМХО больше похоже на опечатку в документе с расписанными циклами, иначе вообще непонятно, что к чему O__oЦитата:
Сообщение от Vladimir Kladov
кстати, у меня в z80ex -- 13 тактов на im0-rst, и blava работает стабильно (в zemu)...
насчет temporary index register -- занятно.. похоже, кто-то что-то знает, но молчит :rolleyes:
кстати, вот еще любопытная дока: http://www.funet.fi/pub/msx/mirrors/...s/z80prg02.htm
там упоминаются некие внутренние регистры w и z, используемые для работы с 16-битными значениями (тк шина данных 8-и битная)
надеюсь выглядеть будет разборчиво, вставляю:Цитата:
Сообщение от boo_boo
INTERRUPTS
----------
NMI _ OCF(5)* SWH(3) SWL(3) *Op Code Ignored
SP-1 ---> SP-1 --->
MODE 0 - INTA(6) ODL(3) ODH(4) SWH(3) SWL(3)
(CALL INSERTED) SP-1 ---> SP-1 --->
- INTA(6) SWH(3) SWL(3)
(RST INSERTED)
SP-1 ---> SP-1 --->
MODE 1 INTA(7) SWH(3) SWL(3)
(RST 38H
INTERNAL)
SP-1 ---> SP-1 --->
MODE 2 - INTA(7) SWH(3) SWL(3) MRL(3) MRH(3)
(VECTOR
SUPPLIED)
SP-1 ---> SP-1 --->
В Пентагоне - нет проблем. Там ведь нет тормозов в памяти, тактов в кадре хватает с большим избытком. Но она сделана для фирменного 128-го, а там есть contented memory. Вот такой вопрос: с чего начинается работа этой демы после "якобы загрузки"? Т.е. надпись Press Any Key просто мигает на черном фоне и все? А должно мигать - на фоне мультиколорного располосования всего экрана, типа как в overscan.Цитата:
кстати, у меня в z80ex -- 13 тактов на im0-rst, и blava работает стабильно (в zemu)...
Может и они. Sharp - вот кто знает, но молчит.Цитата:
насчет temporary index register -- занятно.. похоже, кто-то что-то знает, но молчит :rolleyes:
кстати, вот еще любопытная дока: http://www.funet.fi/pub/msx/mirrors/...s/z80prg02.htm
там упоминаются некие внутренние регистры w и z, используемые для работы с 16-битными значениями (тк шина данных 8-и битная)
С чего вы взяли? Я, например, уверен, что они производили по готовому шаблону, не вдаваясь в детали, и, тем более не разводя схему заново.Цитата:
Сообщение от Vladimir Kladov
а в RS эта дема идёт? там по тактам im0 и im1 не различаются, кроме возможных тормозов за счёт contented портов
Мне тут попалась страничка: Sharp сделал z80 на стеклянной пластине. Вроде как скорость движения электронов в такой пластине в 600 раз больше чем в обычном полупроводнике. Инфа за 2002 год. Может и утка. Думаю, чтобы сделать такое, простопо шаблону вряд ли достаточно работать.
В RS не помню, а в Spectaculator'е точно сбрасывалась. И в Spin'е. Щас RS гляну. Так, в RS вообще не пашет, уже после первого скрина на второй с замком не выходит. (Считая скрин Press Any Key нулевым). То ли не может ленту догрузить, то ли еще. А кто сказал, что RS - самый точный? 8-]
честно говоря, фирменному руководству + куче других руководств доверия больше, чем перепечатке из какой-то книги... однако, и весь мир может ошибаться..
MODE 0 - INTA(6) ODL(3) ODH(4) SWH(3) SWL(3)
(CALL INSERTED) SP-1 ---> SP-1 --->
- INTA(6) SWH(3) SWL(3)
(RST INSERTED)
это намек на то, что M1-цикл при IM0 сжирает 6 тактов для любой инструкции? то есть 4 не считая wait'ов? странно...
ИМХО стоит на реале проверить...
Почему для любой. В Спектруме возможна только инструкция RST38. Эта область за экраном всегда, на шине всегда FF. Т.е. для нас - для любой инструкции RST38.
я имею в виду -- в этой доке при IM0 цикл M1 одинаковой длины для RST и для CALL, почему? крайне это подозрительно и похоже на опечатку. то есть, всякое бывает, но ИМХО то, что какая-то демка заработала, еще ничего не доказывает, проверять надо на реале.Цитата:
Сообщение от Vladimir Kladov
Vladimir Kladov, похоже, мы раздули из мухи слона :)
поглядел я на результаты моего последнего теста от Wlodek'a...
сдается мне, с CP* все просто, как апельсин! а именно:
CPD: memptr=memptr-1
CPI: memptr=memptr+1
CPIR: memptr=адрес_инструкции+2 или как CPI если BC=1 или A=(HL)
или, возможно, нечто типа memptr=(адрес_инструкции+1)+(кол ичество_изменений_PC)
CPDR: memptr=адрес_инструкции или как CPD если BC=1 или A=(HL)
очень похоже!!!! только CPIR надо проверить (при адресах типа F7FD, F7FC, F7F1 и разных BC)
а такие странные результаты для пар были оттого, что 1) первая команда пары тоже меняет BC 2) в предыдущих тестах при "сброшенном" memptr он был на самом деле 0x0001 :rolleyes:
если я прав, то у нас есть: неизвестное число, у которого мы можем узнать 10й и 12й биты, и операции инкремента и декремента этого числа. вопрос: как с помощью всего этого узнать о числе побольше?
Вообще-то есть немного больше: мы же знаем, откуда оно устанавливается. Вот только хранить теперь придется не 1 только старший байт, а уже оба.
Логика становится более понятной, регистр действительно 1 как и указано на схемах (принципиальных). Все просто замечательно!
итак, зная два бита (из BIT n,(HL)) и отслеживая заем при вычитании (командой CPD), можно запросто найти 4 возможных значения memptr, одно из которых - верное. пример на C:
иначе говоря, нам известны 14 бит.Код:unsigned short mask=0x2800; /*известные нам биты*/
digit=значение_memptr_которое_мы_угадываем;
for(m=0; 1 ;m++)
{
if(!(digit & mask))
{
digit--;
if((digit & mask) == mask)
{
printf("одно из возможных значений memptr=%04X\n", (int)m);
}
}
else digit--;
if(m==0xFFFF) break;
}
А ТЕПЕРЬ
задачка для вундеркиндов: есть ли способ отсеять лишние варианты (найти оставшиеся биты)? :rolleyes:
Я чего не понял?
1+1=10
11+1=100
111+1=1000
1....11+1=11...11
Положить число (FFFFh & not 800h) и прибавить 1 или число (FFFFh & not 2000h) и прибавить 1? Или в чем вопрос?
с помощью битовых "окошек" (BIT (HL)) и декремента (CPD) можно однозначно узнать 14 младших бит memptr в общем случае. это уже здорово. вопрос -- можно ли выяснить, что в двух старших битах? там никаких "окошек" нет, поэтому определить из какого бита был заем, и, таким образом, включен он или выключен, так просто не выходит...Цитата:
Сообщение от Vladimir Kladov
подозреваю, невозможно это узнать -- тк мы этих старших бит не видим, их все равно, что нет.
опять непонятно: если они ни на что не влияют, то зачем про них что-то узнавать?
по большому счету незачем. хотя утверждать на 100%, что не влияют, нельзя.... ладно, 2 бита мелочь, и так будет видно, что к чему. если вся эта затея прокатит (под эмулятором уже работает, а вот что будет на реале?), не удивлюсь, если окажется, что после тех команд, которые "обнуляют" мемптр, в младшем байте остается какая-то муть :rolleyes:Цитата:
Сообщение от Vladimir Kladov
это дегко проверяется CPDR (кажется). 0-1=11111...11111. Если после обнудения memptr=memptr-1 дает оба бита установленные, то младший обнуляется.
ничего-ничего, если только CPD действительно декремент memptr, нормально все проверим, по 14и битам :)Цитата:
Сообщение от Vladimir Kladov
итак, поэма о memptr -- читаем!
на этой бодрой ноте дело о BIT n,(HL) предлагаю считать закрытым :rolleyes:
спасибо огромное всем участникам исследований :)
ЗЫ. надо бы еще на английский перевести -- поделиться с буржуями ;) может, возьмется кто-нибудь? могу и я, но позориться неохота -- выйдет в стилистике "ай хаве зе вери гуд фемили"...
Ну я перевел в общем, как смог. И исходный текст перевел в win из unix'а :) Иначе в notepad'е не откроешь.Цитата:
Сообщение от boo_boo
исправляю опечатку в OUTI про before. Остальные сверять сейчас не могу. Ждем выкладывания окончательного варианта, после чего стираю окончательно.
П.С. Все, убираю. Напоминаю: русский оригинал тоже не мешало бы отформатировать с концами строк как в винде, #10#13, иначе в обычном блокноте ничего не видно, хотя и кодировка win1251.
о, здорово! исправил пару опечаток (before вместо after для одного из outi, еще какая-то мелочь), отослал. :)Цитата:
Сообщение от Vladimir Kladov
заодно написал ему о баге с XF и YF в описании bit n,reg
выложи и здесь, я свой с опечатками уберу тогда.
вотЦитата:
Сообщение от Vladimir Kladov
Я еще подумал: пока он там новую версию книги "издаст"... Может и на WoS сообщить в раздел emuls? Там по крайней мере тусуются авторы Spectaculator'а, Spin'а и Fuse. Надо отдать им должное: про тайминги они всю доку выложили, потратив на это и свое время и усилия, и "ломали" их с неменьшим старанием.
ага, сообщи :) ...а что за дока про тайминги?Цитата:
Сообщение от Vladimir Kladov
я имею в виду подробно расписанную картину того как происходят задержки на contended памяти для фирменных моделей. Это информация тоже была недокументирована и получалась путем экспериментов. Что-то знали и использовали демо-мейкеры для получения своих мультиколорных эффектов, но чаще - просто замеряли время для каждой конкретной демы. Совсем другое дело - предоставить подробное описание того, что происходит на каждом машинном цикле каждой команлы процессора, в зависимости от того, происходит в этом цикле обращение к contended памяти или портам или нет. Только так можно троить эмулятор, который будет корректно воспроизводить вс мультиколоры фирменных моделей, с настоящим ULA.
Я сообщу. Не знаю только как пришпилить им текст. Никогда не видел, чтобы там что-то пришпиливали. Попробую на этот тред ссылку дать в наш форум.
Круто! Помнится ещё давным давно книгу "Написать игру на ассемблере" читал "...а флаги обозначенный номерами .. потому они обычно не используются..." (-; во так они не используются - по этим флагам определили наличие неведомого memptr (-:
Кстати, сразу вопрос - тут была ссылка на глобальные тесты Z80 - ZEXALL - получается что тест "не знает" про эти особенности - и на нормальных эмуляторах и нормальном железе даёт неверный результат?
не то, чтобы неверный, но memptr-овские штучки в себя не включающий. собственно, там перед каждой тестируемой инструкцией имеет место быть LD SP,(адрес), причем 11 и 13 биты в этом адресе 0-ые, так что эмуляторы, в которых 3 и 5 флаги просто не устанавливаются, проходят тест на ура :rolleyes:Цитата:
Сообщение от GriV
письмо пришло от Мартина Корта, автора nocash-евской доки и эмуляторов, кроме спасибов и прочего, с указаниями на пару неточностей/неясностей в тексте. посему -- пофикшенная версия.
Boo-boo, ответь плиз в WoS'е:Филип Кендал спрашивает разрешения на публикацию в ФАКах этой информации.
(У них как раз дизайн поменялся форума, стал на этот похож).
ок, зарегестрюсь там заодно, давно собирался ;)Цитата:
Сообщение от Vladimir Kladov
мне не хватает уже ни русского ни английского языка, чтобы выразить свое возмущение. Оказывается некто Фрейзер уже 2 года назад это ВСЕ ЗНАЛ и поместил инфу (или якобы пометил) внутрь архива со своим кросс-асмом - см. сюда: http://www.worldofspectrum.org/forum...6&postcount=17Цитата:
Сообщение от boo_boo
Я просто фигею - какое умное место он для этого придумал. Нет чтобы просто добавить инфу туда где бы ее нашли другие люди. Кстати, не мешает проверить что там есть. Что-то я не нашел этот кросс-ассемблер. А, нашел: ftp://ftp.worldofspectrum.org/pub/si...heE-Z80Way.zip
Почитаем. Где тут самый злой диззи. :mad:
+Пока что ничего интересного. То же самое можно было найти и в других доках. Хотя вполне может быть, что найденная мною на WoS версия устарела ибо лежит там уже 4 года без движения. Что ж, подождем когда автор укажет точное местоположение обновленного архива. А то я что-то в гугле искал - нашел только линк на WoS.
Неужели-таки всё? И про русские процессоры?Цитата:
Сообщение от Vladimir Kladov
Наверно, мы здесь всё же проделали бОльшую работу.
Так что тебе спасибо - заслуженное, я думаю.
В comp.sys.sinclair его некто Dunny уже обломал :) Г-н Fraser Ross исследовал поведение команд из группы 16-ти битных арифметических операций. Возмутился он по поводу того, что его не указали в кредитах текста, написаным boo_boo, делая уклон на то, что вы с boo_boo содрали часть инфы из им указаного документа. На что и попал под раздачу от Dunny. Так что всё нормально.Цитата:
Сообщение от Vladimir Kladov
Лично я этого документа пока он об этом не написал, и в глаза не видел. Boo-boo его тоже не упоминал. Кроме того, толку от его документа: то, что он наисал, и так было известно для 16-разрядного сложения-вычитания, по крайней мере из Шона Янга, задолго до его скрытого в дебрях его асма документа.
Boo-boo, напомни: ведь INC rp / DEC rp не воздействуют на MEMPTR? А то Фрейзер опять возникает. Или сам туда ответь, а то уже спать пора, полночь наступила (все-таки +6 по гринвичу).
Ребята! Не обращайте внимания! Всегда найдётся какой нибудь.... человек.. который скажет "у меня содрали" и будет бумажками при этом размахивать доказывающими его причастность. Вы проделали отличную работу - и это все кто хоть чуть чуть следил за этим тредом, могут подтвердить. Может быть кто-то там и сделал что-то похожее, только он 1) не поделился 2) теперь хочет примазаться к чужому успеху (ненужное из 1 и 2 зачеркнуть), так что знайте вы - молодцы. :v2_tong2:
ну да, только для *ВМ1 отличия по memptr. хотя если есть еще какие-нибудь русские процессоры, можно их тоже протестить ;)Цитата:
Сообщение от Wlodek
не, не воздействуют. в цикле декремента MEMPTR у меня делается INC/DEC BC, и все прекрасно :) пойду загляну на WoS.Цитата:
Сообщение от Vladimir Kladov