unreal speccy ряд вопросов по monitor

[Raider]

Я жму Esc, эмулятор постоянно останаваливается на адресе 0038.
мне хотелось бы чтобы он останаваливался на текущей в данный момент команде, как будто в realtime остановили настоящий спектрум.
Я понимаю как эмулятор работает и что он z80 выполняет батчем, а не размазанно по времени. Но все равно как-то можно примерно аппроксимировать диапазон адресов на котором должен находиться процессор и воткнуть туда брекпоинт...

Также хотелось бы запрещать из монитора прерывания. Это можно сейчас как-то сделать?
У меня на спектруме была кнопка отключающая прервания. Очень удобно, нажал ее, потом жмешь NMI и никаких эксцессов, и знаешь заодним, где halt стоит - а это в 99% случаев Main Demo/Game Loop..)

В мониторе рядом с im1,i:00
я так понял это флажки iff0, iff1
а зачем их может понадобиться редактировать?

Можно ли как-нибудь сделать так, что запустить код как trace в STS, и смотреть в мониторе где он выполняется в realtime? (состояние регистров, памяти, итд?) - это очень полезно. Я в своем эмуляторе N64 иногда прямо "глазами" видел где и как идет выполнение программы, какие регистры не используются и другое...
пока что жму Alt-S и потом держу F8...

[Advertiser]

[SMT]

Я жму Esc, эмулятор постоянно останаваливается на адресе 0038.
мне хотелось бы чтобы он останаваливался на текущей в данный момент команде, как будто в realtime остановили настоящий спектрум

F11 нажми после esc

Но все равно как-то можно примерно аппроксимировать диапазон адресов на котором должен находиться процессор и воткнуть туда брекпоинт

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

Также хотелось бы запрещать из монитора прерывания. Это можно сейчас как-то сделать? У меня на спектруме была кнопка отключающая прервания

ну это же была собственная довеска. вот и к эмулятору придётся её самому дописывать, благо делается в полпинка

я так понял это флажки iff0, iff1
а зачем их может понадобиться редактировать

а зачем регистры редактировать? никто редактировать не заставляет

пока что жму Alt-S и потом держу F8

тоже хорошо, но лучше F7

В мониторе нет команд copy memory и fill block with byte(s)?

copy специально нет, она должна выполнятся за 2 прохода (save to file, load from file). одновременно решается проблема копирования между банками. fill можно эмулировать через load (конечно, если человек копается в дампах, хекседитор просто обязан быть у него под рукой, чтобы сделать соотв. файл)

[Raider]

F11 Помогло.
спасибо.

А про trace как в STS ты забыл ответить. Особенно так трассировать здорово когда внутрь CALL'ов не заходишь. Помню как я натурально перся (как удав по стекловате), когда в таком режиме трассирования под STS запустил R-TYPE.
Это было нечто! Игра работает, и можно в любой момент прервать, или посмотреть как она там в Main game Loop крутится...

В анриле шибко такого нехватает..

Если б Stalker такое сделал в 1985-86 году, он бы наверное миллионером стал.... STS фирмы производители игрушек наверное с руками бы отрывали..

Кстати с чем связано, что когда в мониторе удерживаешь F8 нажатой, то из монитора через некоторое время вылетеает обратно в режм эмулятора?
F7 степать неудобно, потому что постоянно застреваешь в циклах..

[Raider]

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

Я делал так. У меня процессор выполнялся довольно "большими кусками" циклов. Я думаю ты понял о чем я.

for(u64 i=0; i<BIG_VALUE; i++) {
fetch_opcode();
}

и меж этими кусками я сканил клаву обычным GetAsyncKeyState()
все работало. для GetAsyncKeyState() не надо ничего, она работает всюду.
Но только я не останавливался где попало с точностью до команды, но "примерно" где попало. С гранулярностью так в несколько млн. команд :-)

[Dexus]

Да, кстати, то что в эмуле постоянно "рвется" звук (это можно исправить только постановкой приоритета high), и _всегда_ рвется когда перетаскиваешь окошка - не есть хорошо.
Вообще, монитор достаточно скуден.
Очень сильно помог бы trace log. т.е. последние 10 (или сколько там в опциях будет) команд записаны в лог. адрес, код, дизассемблировка, и регистры все (и флаги).

И еще очень нужная штучка - это "спец значок" у команды условных переходов, если она при текущих флагах сработает (когда тыкнешь f7/f8).

И еще - когда тыкаешь F8 на каком нибудь DJNZ, а внутри цикла стоит комманда, "выходящая" за рамки цикла (дальше) - то он просто выходить из монитора вовсе.... Т.е. там не учитывается "промежуток" цикла, а просто ставится как бы автоматом точка остановки ровненько за этим DJNZ. Это конечно очень легко с точки зрения реализации, но ИМХО - не совсем корректно.
А отмазка "было лениво делать" - как то смотрится не очень красиво.

[SMT]

про trace как в STS ты забыл ответить. Особенно так трассировать здорово когда внутрь CALL'ов не заходишь. Помню как я натурально перся (как удав по стекловате), когда в таком режиме трассирования под STS запустил R-TYPE. Это было нечто! Игра работает, и можно в любой момент прервать, или посмотреть как она там в Main game Loop крутится... В анриле шибко такого нехватает

все есть! пускаешь STS и наслаждаешься да и без него - прервать в любой момент можно? можно. а хочешь сильно замедлить? ну так поставь 20 int-ов в секунду вместо 50

Кстати с чем связано, что когда в мониторе удерживаешь F8 нажатой, то из монитора через некоторое время вылетеает обратно в режм эмулятора

или call не вернулся, но скорее всего условный jp наверх (например, игровой цикл), при этом считается что этот F8 - попытка пройти цикл и break ставится после jp

У меня процессор выполнялся довольно "большими кусками" циклов

не хочется переписывать главный цикл из-за сомнительной пользы этого эффекта

SMT, добавь меня в аську, поговорим насчет эмулятора

а нету

Очень сильно помог бы trace log. т.е. последние 10 (или сколько там в опциях будет) команд записаны в лог. адрес, код, дизассемблировка, и регистры все (и флаги).

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

И еще очень нужная штучка - это "спец значок" у команды условных переходов

согласен, полезная штучка

F8 на каком нибудь DJNZ

над этим надо подумать...

отмазка "было лениво делать" - как то смотрится не очень красиво

тогда придумай мне красивую

[Dexus]

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

Ну нет. этот "ЛОГ" можно вести только во время f7/f8 (хотя бы). Очень знаете ли полезно изучать "предыдущие" комманды. Весь цикл. Его и распечатать (в файл слить) - было бы очень полезно. потом трасировку на бумаге изучать, выясняя глюки... Можно и при обычной эмуляции (если какой нибудь флажок выставлять - для многих ресурсов для этого хватит)... А логировать в кольцевой буфер, память целая будет.

тогда придумай мне красивую

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

Надеюсь, что описанные мной "фички", которые были бы весьма полезны, все же найдут воплощение в следующих версиях!

З.Ы. Вот еще вспомнил интересное место в дизасме во время трассировки - при коммандах с косвенной работой (не регистрами а памятью) - показывать где нибудь в скобочках значение, которое прописано в данный момент там где произойдет "доступ к памяти". Если оттуда берется, или если это значение затирается (Может было бы полезно даже и для push/call/pop/ret). В любом случае это не было бы бесполезно. Смореть в правый верхний угол где куски памяти по регистрам расположены - не всегда удобно (взглядом бегать), да и с IX/IY очень часто смещение далеко за пределами отображаемого "окошка".

З.З.Ы. Вот еще вспомнил что бы мне казалось уместным в дебагере (по крайней мере я не нашел или не заметил чтобы это было в US, или в каком то другом эмуле - это как-то показывать место где сейчас находится "луч". Когда тыкаешь F9 (например).
Вообще, насколько я понял, когда идет трассировка, и какое то байтик записывается в видео область, то при F9 он немедленно там отображается, хотя технически это не совсем верно. Он появится там только после того как луч его отобразит.
Т.е. наблюдать "мультиколор" потактово не получится, как и не видно эффектов "пропадания" курсоров и вообще подобные эффекты. Можно конечно сделать два вида "показывания" экрана спектрума текущего - с учетом луча, и без учета. в текущий момент работает только схема "без учета" (правда мультиколор на момент остановки все-таки есть, хотя при дальнейшей пошаговой трассировке изменений этих "мульти" эффектов не видно). А можно сделать еще и с учетом этого луча. Т.е. не отображать тех участков "экрана", которые физически лучем не нарисованы еще, старые же участки можно как нибудь "пригасить"(те, что чуть ниже луча) а сам луч отобразить какой-нибудь мерцающей бледной точечкой. Хочешь увидеть что реально в видеопамять закинуто и что на бордюре (текущий цвет) - тыкаешь обычную F9 (или ShiftF9 для доп. экрана №7). А хочешь увидеть "расширенный вид" - тыкаешь AltF9. В нем будет показано что в данный момент выводится лучом. С учетом и мультиколора на бордюре, и аттрибутами, и "переключениями" между 0 и 7 экранами. ВОт эта фича точно был абы ОЧЕНЬ нужной для демомейкеров, и не только для них, а для всех кто хочет _точно_ и _качественно_ отслеживать и трассировать весь вывод с учетом луча.
На фоне этого (если это вдруг найдет воплощение), очень уместным было бы иметь "отладчик" в отдельном от "вывода" окне. Трассируется в одном окошке, и визуально отображается в другом. Строго говоря, это разделение окон (которое в некоторых эмулях имеется) без этой "фичи" отображения луча, имеет лишь "половину" смысла - это показывать сразу то, что в видеопамять запихивается. А то что луч выводит - не показывает. Это уже сам додумывай, какое место картинки он (луч) нарисует. В этом смысле бы ДВА окна + окошко отладчика были бы идеальным случаем (правда, это уже совсем маловероятно, что это найдет свое воплощение , хотя несомненно - уникальная и полезная фича ). Ведь после каждого f7/f8 тыкать на f9 не очень прикольно. часто хотелось бы видеть изменения сразу же. Кстати, сейас, когда входишь в отладчик - автоматом размер окошка ZX масштабируется под его (отладчика) размер, и потом уже не восстанавливается, поэтому независимое окошко - достаточно актуально.

[Raider]

или call не вернулся, но скорее всего условный jp наверх (например, игровой цикл), при этом считается что этот F8 - попытка пройти цикл и break ставится после jp

А как-нибудь сделать только для CALL'ов?

[Raider]

Да, кстати, то что в эмуле постоянно "рвется" звук (это можно исправить только постановкой приоритета high), и _всегда_ рвется когда перетаскиваешь окошка - не есть хорошо.
Вообще, монитор достаточно скуден.
Очень сильно помог бы trace log. т.е. последние 10 (или сколько там в опциях будет) команд записаны в лог. адрес, код, дизассемблировка, и регистры все (и флаги).

И еще очень нужная штучка - это "спец значок" у команды условных переходов, если она при текущих флагах сработает (когда тыкнешь f7/f8).

И еще - когда тыкаешь F8 на каком нибудь DJNZ, а внутри цикла стоит комманда, "выходящая" за рамки цикла (дальше) - то он просто выходить из монитора вовсе.... Т.е. там не учитывается "промежуток" цикла, а просто ставится как бы автоматом точка остановки ровненько за этим DJNZ. Это конечно очень легко с точки зрения реализации, но ИМХО - не совсем корректно.
А отмазка "было лениво делать" - как то смотрится не очень красиво.

2SMT:

Оконные сообщеня не обязательно выгребать слишком часто. Достаточно из процессорного цикла, если у тебя нет многопоточности делать изредка peekMessage() и если что выполнять getMessage() пока они не кончатся, а лучше делать cpu в отдельном потоке.

Спезначок удобно сделать стрелочкой сразу за командой перехода, я так делал у себя. Стрелочка показывает куда будет переход - вверх или вниз.

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

И есть еще пара прикольных херей, для хакинга игр/демок можно присобачить к эмулятору. У меня они были встроены в эмуль.

1. Это graph memory viewer, чтобы смотреть графические данные (отдельным окном - показывает просто память полоской в 1...N байт, водишь мышкой и в качестве хинта видишь адрес куда мышкой навелся).
и еще нужно клавиатурой смещать адрес на байтик вперед-назад, чтобы точно "встать" на граф. данные.

2. Память машины изображать в отдельном окне виде "ленты". периодически окно апдейтится (настраиваемо, в N прерываний или каждые несколько сотен тыс. тактов, или кнопкой).
В окне показывается память спектрума. Показывается тип памяти - выполнявшийся код. Записи. Чтения. Мертвая память (не было ни записей ни чтения, и проц сюда не заходил, не фетчил команды отсюда).

В наше время можно хоть на каждую ячейку памяти спектрума держать по 4 байта, на PC обычно такие объемы памяти не проблема
Я вообще-то такое делал для страниц памяти, но думаю для спека можно сделать для каждой ячейки.

Теперь дальше.
Мне еще требовалось "ручной сброс статистики по памяти", а не только автоматом.
И еще делал анализ hotspot-участков кода - в ячейках памяти выполняемых процессором я заводил счетчик с saturation, чтобы посмотреть как часто он сюда заходит - и это отображал на экране, на карте памяти в виде яркости (можно оранжево-синий градиент сделать а-ля FFT analysis в Cubic Player).
Чем чаще процессор исполнял эту команду, тем "ярче" отображался этот "hotspot". Таким образом мне удавалось увидеть где именно сосредоточена "работа" в игре.
Разумеется карту hotspot выполнения нужно время от времени >> 1.
Период подбирается экспериментальным путем, для достижения комфорта.

А если ты фанат скорости, так тоже делается просто.
Вводится #define и делается две сборки эмулятора - для простых людей чтобы порадовать их непритязытельностью к ресурсам. И для девелоперов, эмулятор собраный со всеми фичами.


p.s.
Я правильно понял, что на UnrealSpeccy breakpoint памяти возмжен только тупо на read/write access? Можно ли поставить breakpoint, но такой чтобы при write-access он срабатывал только если ячейка изменилась, т.е. туда записали значение не то что в ней было?

[SMT]

"ЛЕНЬ" - это как то черезчур небрежно и неуважительно

зато честно

Ну нет. этот "ЛОГ" можно вести только во время f7/f8 (хотя бы). Очень знаете ли полезно изучать "предыдущие" комманды. Весь цикл. Его и распечатать (в файл слить) - было бы очень полезно

10 команд никого не спасут, а вместо копания в 100 метровом логе полезнее подумать и установить правильные условные брейкпоинты

показывать где нибудь в скобочках значение, которое прописано в данный момент там где произойдет "доступ к памяти". Если оттуда берется, или если это значение затирается

это вместо ld (ix+12),e писать ld (a012),45?
а если ld e,(ix+12), что писать: ld e,45 или ld e,(a012)?
во втором случае всё равно смотреть в память

показывать место где сейчас находится "луч"

это было в старых версиях, когда было мало видеофильтров. используй их, а сейчас в каждом фильтре "я планирую воплотить, но сейчас руки не доходят"(с)

при F9 он немедленно там отображается, хотя технически это не совсем верно

немедленно не отображается, и многим это не нравится. хотят наоборот, а мультиколоры говорят им пофигу. отображается только после shift-f9, f9. тогда всё, что нарисовано лучом, стирается и берётся видеопамять. вообще насчёт затемнения можно подумать

А как-нибудь сделать только для CALL'ов

возьми старую версию. мне показалось удобным такое для jp cc, когда проходишь много расксорок подряд

Спезначок удобно сделать стрелочкой сразу за командой перехода, я так делал у себя. Стрелочка показывает куда будет переход - вверх или вниз

я так и хотел, как в soft-ice'e. если перехода нет, то и стрелку не рисовать

TraceLog хорошая вещь, не сказал бы что полезно иметь в стандартных возможностях, но эмуляторщикам без логгинга как-то сложно

например, зачем?

graph memory viewer

для этого есть EmuzWin

Память машины изображать в отдельном окне виде "ленты". периодически окно апдейтится

в принципе, реально сделать такой индикатор. например, показывать за последний int столбиком 128x8 какой из 512-байтных кусков читался, писался, выполнялся. или по банкам (4 столбика высотой 128 пискелей). хотя второе менее наглядно, но больше разрешение (1 полоска - 128 байт)

в ячейках памяти выполняемых процессором я заводил счетчик с saturation, чтобы посмотреть как часто он сюда заходит - и это отображал на экране, на карте памяти в виде яркости

это нельзя. в большинстве фильтров и в мониторе цвет 8-битный

Вводится #define и делается две сборки эмулятора - для простых людей чтобы порадовать их непритязытельностью к ресурсам. И для девелоперов, эмулятор собраный со всеми фичами

оно уже и сейчас так. для обычных моделей zx своё ядро z80, а для профПЗУ или если активны брейкпоинты, свой медленный вариант. разные бинарники - не знаю... хотя есть вариант для девелоперов компилить самим (сейчас уже можно скомпилить себе короткий exe без GS, monitor'a, GUI-настроек, просто закомментировав define'ы в mods.h)