samstyle / xpeccy Goto Github PK

В дебагере метки вписываются вместо адреса, места там патологически мало. Локальные метки, которые склеиваются с основными, просто не вмещаются:

05:376E edit_key.l1
05:377B edit_key.l2
05:3791 edit_key.l3
05:379A edit_key.j1
05:37A9 edit_key.j2

Можно действовать как в том же дебагере из emuzwin, который выводит метки на отдельных строках, и не затирает ими адреса (что тоже хорошо):

В нём, кстати, метки совмещаются с фактическим адресом, и места для ассемблерной инструкции там даётся с лихвой. В XSpeccy много пустот справа от колонки с кодом и от самой инструкции пикселей 50 просто пустоты. Очень много пустот и в окне дампа, но это другая история.

Плюс, решение этого issue сделает более возможным использование меток со сдвигом через EQU $+n. А если бы при ховере мышки над словом/меткой/адресом - можно было перепрыгнуть по этому адресу (в окне дебага, или в окне дампа), по выбору из контекстного меню, или зажав Ctrl превращать адрес в прыгабельную ссылку (с возможностью возвращения) - это было бы вообще прекрасно.

На OS X окно дебаггера выглядит вот как-то так (сборка из master):

Весна, даже виджеты лезут друг на друга ;)
На дефолтных Ubuntu 14.04 и 16.04 примерно та же история с наползанием виджетов, но дамп там отображается.

Оченно нехватает

Пожалуйста в app под MacOS добавь все необходимые либы для запуска, для этого там есть утилита macdeployqt:

~/Qt/5.8/clang_64/bin/macdeployqt Xpeccy.app -dmg

Без либ сборка сегфолтит.. Запускаю из dmg отсюда - http://zx-pk.ru/threads/9479-xpeccy.html

После запуска и Sinclair research просто набиваешь на клавиатуре клавиши ",,,", затем ext (ss+cs), и снова ",,,", и в итоге то залипает то разлипает cs (то точки то запятые), выводится вот такое:

Вообще нажимая на клавишу ",<Б" получить символ "." в норме невозможно.

Собрал вчера под Qt и под SDL. Почему-то под SDL можно сменить букву виртуального драйва для пентевы, а под Qt пишет что нет виртуальных, но и не дает реальным воспользоваться. ЧЯДНТ? 8)
ps: Если что, я постоянно на conference.jabber.ru/8bit - присоединяйся, можем в реале обсуждать вопрос, пока форум йок.

При попытке выгрузки памяти "Save dump", невозможно сохранить все 64*1024: указываешь начало 0000 конец ffff - автоматом заполняется в длину 1000 (а должно быть 10000, но не вмещается), и сохраняется 4096 байт.

В каком-то из предыдущих коммитов что-то было сделано, и теперь звук рвётся. Любой. И Ау и бипер.

Пример: http://volutar.myds.me/xpec-beepbug.mp4

512 сэмплов прорываются из другого момента, расстояния между ними где то 0.6сек (если эта инфа поможет).

грусть печалька по этому поводу

Записывать лог выполнения в файл:
Addr: reg1: reg2:
и так далее

Хотелось бы чтобы в дебаггере, в том же табе, где экран, показывать цвет бордюра текущий (там виден только сам PAPER). Когда луч за кадром, или внутри папера - даже непонятно какой последний out 254 был сделан.

Также хотелось иметь возможность доступа к состоянию портов, тому же 254, на ввод и вывод (динамик/магнитофон, бордюр), всяким портам TR-DOS, кемпстону/мыши, с возможностью как-то влиять на те, которые завязаны на input.

По 254 порту, из которого считывается состояние клавиатуры, кстати, непонятно как поменять состояния нажатости кнопок. ZX Keyboard, похоже, не передаёт в дебаггер ничего (зафиксировать нажатые кнопки вроде можно по ПКМ, но их состояние считывается только когда дебаггер закрываешь), то есть нельзя сделать так, чтобы они во время действия сканера клавиатуры считывались такими, какие надо в ходе пошаговой отладки. Надо продебажить сканер клавиатуры, джойстик, а не получается.

Просьба сделать WUTcha вызываемым из дебаггера. А то приходится закрывать дебаггер (тем самым возобновлять выполнение), открывать WUTcha, набивать там кучу значений, и снова открывать дебаггер и искать нужное место, а то и изгаляться - перезапускать весь отлаживаемый процесс, если это допустим с самого запуска, и сработала автозагрузка.

Добавить можно в инструменты (туда же где Search / Fill / Sprite scanner / Keyboard)

В текущей версии окно вытягивается совсем некузяво.

То есть в первую очередь растягиваются регистры (которым растягиваться скорее всего нет смысла).
Растягивается самое правое поле с ASCII дампа (которому растягиваться точно нет смысла, и это поле, кстати и в "скукоженном" состоянии кучу пустоты слева имеет).
И в третью очередь, когда 1 и 2 уже растянулись достаточно, только тогда начинает растягиваться окно дизасма.

Просьба в первую очередь растягивать окно дизасма. С учётом длинных названий меток это в первую очередь необходимо.

Очень часто код - самомодифицируемый. То есть вида:

onetime1: ld a,1
and a
jr z,label2
xor a
ld (onetime+1),a
label2: ....

Хотелось бы, чтобы отсылки внутрь инструкций также работали. Либо через смещение в адресации (если метка указывает ровно на саму инструкцию), либо через добавление строки типа:

ld a,1
onetime: equ $-1
...
ld (onetime),a

либо

onetime: equ $+1
ld a,1
...
ld (onetime),a

если метка указывает внутрь инструкции.

а то не ясно - тормозит хрессу в данном конкретном окружении, или нет

если автостарт снапшота указан как 0х6000 и при запуске указать ключ "--bp 0х6000" то брякпоинт при запуске снапшота не срабатывает

Насколько видел из исходников, никакой передискретизации и КИХ фильтрации звуковых чипов нету. Нельзя ли добавить опциональный рендеринг звуков с КИХ фильтрами? На высоких тонах артефакты дифракционные очень заметны и не очень приятны. Есть вот такая тема с готовой либой: http://hypr.ru/blog/168.html
У Бульбы в zxemul с этим также все хорошо (помимо unreal и кучи других эмуляторов). А аюми вроде считается топом, кому это важно (типа меня) могли бы включать precise sound rendering.

Правда работать работает. Но вот не показывается. В связи с чем- а как их менять если подключено несколько?

Использую сборку 0.6.20190301, на предыдущих такое же поведение.

1. После нажатия и удерживания любой клавиши до срабатывания автоповтора, автоповтор не остановится до тех пор, пока не убрать фокус ввода с окна. Во время бесконтрольного автоповтора можно нажать любую другую (но не ту же самую!) кнопку и удерживать до уже её автоповтора, и тогда всё останавливается вообще, ни на что больше не реагирует. Продолжают работать только хоткеи самого эмулятора. Выход из ступора – переключение фокуса ввода из окна и обратно, можно даже через вызов и закрытие окна настроек по горячей клавише.

2. Нажатие любой клавиши в комбинации с command, даже быстрое, не дожидаясь автоповтора, приводит к тому же результату – начинается неконтролируемый автоповтор до перехватывания и возвращения обратно фокуса ввода.

UPD Через ZX Keyboard видно, что command (он же SS) отжимается, как и положено, а вот клавиша, нажатая в комбинации с ним, залипает.

Есть ли возможность когда окно хрессу активно, но маус не грабнутый - колёсиком мышки менять общую громкость эмулятора?

Хотелось бы иметь возможность при запуске указывать ресайз окна/фуллскрин. Возможно ноуфлик и пропорции
-x1, x2, x3,x4,full - это к размеру окна
также другими параметром ноуфлик и пропорции

Использую сборку 0.6.20190301, на предыдущих такое же поведение.

Включение KeyMap с использованием любого .map файла, даже с пустой секцией [Keymap file] приводит к стабильно одному и тому же результату. Клавиша с цифрой 1 перестаёт работать в любых комбинациях (shift, ctrl, command, alt), в том числе и на дополнительной клавиатуре. Только выбор в настройках KeyMap: none возвращает ожидаемое поведение.

Также не мапится ctrl, ни левый, ни правый. Такое ощущение, что эта клавиша вообще не обрабатывается.

UPD научили посмотреть, что там на самом деле происходит через ZX Keyboard. Выяснилось много интересного. Например, нажатие 1 при включенном кеймапе выглядит как одновременное нажатие 2 и 3:

Также обнаружено, что ctrl действительно вообще не участвует в процессе, а LC совершенно замечательно мапится, только вместо ctrl на command. А RC просто в никуда.

Наблюдается неприятные моменты:

1. Не отрабатывает одновременное нажатие на левую и правую мод.клавишу, т.е. left ctrl одновременно с right ctrl не видится. То же самое и с shift.
2. Зажав LS затем RS, и отпускаем LS, при этом залипшим остается RS. И в обратной последовательности так же. Если после залипания одной нажать на одну клавишу с другой стороны (например при залипшем LS нажать RS), то она также залипает. При выходе в дебаг залипы уходят.
3. Даже если не перемапливать LS/RS/LC/RC, то залипы всё равно случаются с нажатиями на LS+LC. Причём, при зажатом LC, потыкивание на LS не даёт залипы, а при зажатом LS потыкивание на LC даёт залип, но не первый раз - со второго потыкивания с вероятностью где-то в 50%. Выход в дебагер этот "счётчик" сбрасывает. т.е. после выхода в дебагер одиночный LC+LS никогда не залипает. Сброс в дебагере работает ТОЛЬКО если ZX Keyboard не включен, а если он включен то залипания остаются после входа в дебаггер. И более того - все залипы прекрасно отображаются на ней.

Постоянно при шаге через CALL (а также DJNZ) происходит сброс положения отладчика - следующая команда оказывается наверху, а не остаётся на месте. Желательно во время пошаговой отладки не сбрасывать положение скроллера, если точка возвращения находится в области видимости.

При запуске можно просто обдавиться на джойстики и кнопки геймпада. Работать они будут только после того как зайти в настройки и выйти из них обратно. При последующем запуске хрессу опять болт до захода/выхода из настроек.

Просьба сделать возможность добавлять просмотр не только по фактическому шестнадцатеричному адресу и регистру, но и МЕТКЕ (если таблица меток загружена). Сейчас приходится каждый раз лезть в файл с метками и адреса оттуда брать и вбивать адреса.

Сделать можно также как и в строке дизасма - вбил метку, на неё и адресовался, вбил шестнадцаричную строку - перешёл по этому адресу. Метка теоретически может называться c000, но я даже не знаю как дебаггер отреагирует, и перейдёт ли он по адресу c000, или возмёт адрес метки. По логике приоритет за адресом, и нефиг так называть метки :)

Причём, если это значение по метке, то желательно выводить и название метки и её значение (в колонках слева). А колонки слева лучше склеить в такое же как и дебаггере, а не пилить их на отдельные type/page/addr.

Очень преочень

Чтобы вот так вот можно было:

я плакаю.

Бывает брекпоинт ставишь в функции которая вызывается из разных мест. Чтобы понять из какой - надо из стека адрес вбивать чтобы узнать. Когда это один раз или два это норм. Но бывает что надо интенсивно выявлять места откуда вызов шёл. Нельзя ли сделать чтобы по двойным щелчкам в адрес стековый, происходил прыжок Окном дебаггера к ней (только не так что адрес сверху, а лучше в центре, чтобы видеть предшествующие операции).

А также при вбивании нового адреса в дебаггере происходит прыжок в это место. А обратно - никак. Только так же вручную. Нельзя ли сделать что-то типа истории (как в ida, как в браузерах), чтобы можно было возвращаться к предыдущим точкам, и снова вперёд. Логика фиксирования таких позиций:

1. Прямой прыжок по адресу (напрямую набором адреса, или щелчком по стеку).
2. Во время трассировки, jr/jp/djnz(дальше какого-то значения, за пределы экрана), call/rst, ret, nmi/interrupt.
3. Во время активного скроллинга, фиксировать точки только при остановках дольше 5 секунд, и если они достаточно далеко от предыдущей позиции.

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

При установке палитры методом, описанным в посте http://forum.tslabs.info/viewtopic.php?p=1001#p1001 происходит запись не только в отображённую на #0000 память альтеры, но и в страницу памяти в окне 0. Билд Xpeccy 0.6.20160730.

Когда переключаешься с CPU на RAM/ROM в дизасме - все время отображается RAM:00, вне зависимости от того, какая страница выбрана (RAM/ROM отображается, но номер страницы всегда 00). В дампе вообще никогда RAM:00 даже нет, всегда только 4х-циферный адрес.

Когда трассируется код, и строка вида ld a,(#8054) справа содержит подсказку - содержимое байта. Беда в том, что команда ld hl,(#8054) также будет показывать только один байт (младший разряд), а не целиком слово. По-доброму должно быть полное слово - содержимое памяти.

Также битовая команда сверки (bit) по-доброму должна иметь подсказку не только в виде полного байта, но и запрашиваемого бита, а то не сразу очевидно - он 1 или 0.

Было бы неплохо, если бы по крайней мере содержимое по адресам IX,IY,HL,DE,BC (с текущего набора) было бы отображено, чтобы каждый раз не искать то, что там в соседних адресах. Содержимое в активной памяти, которую видит CPU. Возможно, в виде отдельной вкладки, там где DUMP (CPU/RAM/ROM), отображая пару байт слева и несколько байт справа от памяти, куда указывает регистр. Может где-то в другом месте. В US это очень удобное окошко, но у него там есть один недостаток - он показывает текущий и только следующие байты, но те же индексные часто берутся с отрицательным смещением. Поэтому было бы прекрасным наличие возможности выбирать смещение для отображения, относительно самого адреса регистров (выделяя как-то цветом байт со смещением 0).

В идеале - просто секция watches, в которой можно указывать конкретные адреса, а можно регистры, которые интересны.

Редактор шестнадцатеричных значений в WUTcha какой-то странный, если поле пустое, начинаешь вбивать 4 цифры FFFF, в итоге он примет только крайнюю (000F), и каждый раз приходится бежать в начало и вбивать всё заново. То есть дефолтовое пустое значение интерпретируется как не пустое, а заполненное, и курсор установлен в 4й позиции.

В дампе памяти выделяешь поле, пытаешься целиком его вбить, и он заменяет последнее значение, а курсор ставить на ВТОРОЕ.

Редактор шестнадцатеричных значений ощущается кривым именно из-за валидации. Зачем вообще с ним мудрить и почему не брать поле как обычную строку, и использовать значение для калькуляций, не трогая исходной? А если там ошибочное значение - просто не вычислять значения, на него отсылающиеся, и писать там какой-нибудь "error".

Во время отладки показывать место куда будет переход - пока отображается просто красная стрелка вверх или вниз, но не видно куда именно - надо вручную ориентироваться по адресу. Желательно показывать также эту же красную стрелку, направленную влево, в той же правой части где стрелка вверх/вниз.

А например и +3

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

предлагаю при загрузке большогор файла - делить его на несколько

если при записи мнапшота по F2 не указать расширение - то файло не записывается и никаких сообщений не выдаётся.

P.S. Возможно это касается и других типоов файлов - не проверял.

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

Замечено, когда жмёшь например влево, а потом резко переходишь на клавишу вправо, на какое-то время shift исчезает (если смотреть на Zx keyboard), и начинают идти цифры 8.

Дело в том, что в этот небольшой промежуток перехода между нажатыми клавишами, когда они обе нажаты, капс считается зажатым один раз, и при отпускании одной из клавиш - пропадает. Хотя должен оставаться, т.к. вторая клавиша тоже с капсом. В реальности капс восстанавливается, но поздно, цифры уже во всю набираются. Более того, если не отпуская давить капс на клавиатуре и тыкать влево-вправо - капс будет всё равно пропадать!!!
То же самое с Symbol Shift (скобки тоже превращаются в цифры).

Может быть имеет смысл под каждую конфигурацию уже в дистрибутиве сделать дефолтный romset как это сделано в Fuse? А то что-то тыкаюсь-тыкаюсь, кроме 48к ничего толком не удается подключить... Не обязательно включать сами ROM, только настройки для них

ключ --рс выводится в какойто ОПЕ