Emu80 v.4

svofski, похоже, что причина найдена - блок питания.
Обратил внимание, что при запущенном эмуляторе стал иногда появляться индикатор просадки напряжения, раньше никогда его не видел.
Сообразил, что в этот раз подключил монитор не напрямую, а через адаптер HDMI-VGA. Подключил напрямую через HDMI к другому монитору - индикатор пропал, текущая версия на минимальных настройках наконец пошла без тормозов, годичной давности по-прежнему притормаживает. Видимо, БП работает на пределе, от дополнительной нагрузки в виде адаптера ему совсем поплохело. И видимо даже без появляющейся "молнии" малинка все равно работает не на максимальной частоте. Надо будет попробовать отладочный вывод частоты процессора сделать, ну и буду искать более надежный БП...

P.S. Проверяю тоже на апогеевских демках.

Pyk, я подключал через композит с отключенным HDMI. Думаю, что это может быть существенно. Что же до блока питания, то он сам по себе скорее всего не так и плох, плохи обычно бывают провода. Из личного опыта проще добиться стабильной работы с коротким проводком 10-15см, чем пытаться найти взаправдашне годный длинный.

svofski, кабелей несколько штук перепробовал, в том числе и хорошо зарекомендовавших себя в других применениях под приличным током, - разницы не заметил. А БП у меня не родной - китайский какой-то на 2,5 A. Полноценно заменить пока не чем, кабелей короче 60 см тоже не нашел. Пробовал с другим БП на 2 A - эффекта нет...

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

Pyk, насколько я помню, сами рписты рекомендуют использовать свой блок питания, который дает 5.2В. (Вот почему они сами себе не могли порекомендовать сделать человеческий разъем питания я никак не могу понять. Бубубу бубубу бубубу!) В любом случае недопит у меня тоже мыргает иногда и с emu80, и в v06x - кстати, попробуй его, что получится? - ты теперь в Векторе тоже не чужой ;) - и ничего, если это не постоянная проблема, то все работает нормально.

ivagor, ты имеешь в виду сделать отдельную кнопку и отдельную горячую клавишу?
Сейчас для холодного рестарта можно нажать Alt-F9, Enter, то есть повторно выбрать текущую платформу.


svofski, взял трехамперный БП и короткий кабель - индикация просадок напряжения исчезла, но все равно тормозит, хотя и меньше... Через композит попробовать пока не удалось - почему-то отсутствует синхронизация, изменение режимов sdtv_mode не помогает...

Цитата:

---

Сообщение от Pyk

Сейчас для холодного рестарта можно нажать Alt-F9, Enter, то есть повторно выбрать текущую платформу.

---

Не сообразил, тогда конечно ничего добавлять не надо.

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

DemonId7, честно говоря, очень странно. Пришли, пожалуйста, полноразмерный скриншот (чтобы окно было целиком и можно было посчитать, на сколько пикселей обрезано; предыдущий скрин был нещадно пожат движком форума), а также напиши сведения об ОС (версия windows, service pack, установлены ли обновления). Можно в ЛС или на e-mail.

Кто-нибудь вообще с такой проблемой еще сталкивался?

У меня с окном отладчика нормально, а вот подсчет тактов все же не нравится. Было бы гораздо удобнее, если по F4 и бряку сначала выводилось накопленное значение тактов и только потом счетчик обнулялся.

Цитата:

---

Сообщение от ivagor

Было бы гораздо удобнее, если по F4 и бряку сначала выводилось накопленное значение тактов и только потом счетчик обнулялся

---

Хорошая идея, согласен. Не додумался сразу так сделать.

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

Версия 4.0.340 от 20.05.2019:

Portable Qt-версия, windows-сборка (рекомендуется):
http://emu80.org/v4beta/Emu80qt_40340.zip

Portable SWL/wx-версия, windows-сборка:
http://emu80.org/v4beta/Emu80_40340.zip

Исходники:
https://github.com/vpyk/emu80v4


Изменения в версии 4.0.340:

Легенда:
+ Нововведение
* Изменение / улучшение
- Исправлен баг
! Известная проблема

+ Возможность настройки символьной страницы для отображения текстовой информации в отладчике
+ Возможность задания в настройках произвольного целевого формата экрана наряду с 4:3 и 16:9
* При обнулении счетчика тактов в отладчике сейчас также отображается его текущее значение (обнуление происходит по точке останова либо F4 (Here))
* Оптимизировано расположение окон отладчика на экране после запуска (Qt)
* Скорректирована палитра цветов ПК8000, немного понижена яркость темных цветов
- Устранена проблема с размером окна отладчика в Windows XP (Qt)
- Исправлена несовместимость с Qt версии более 5.10 или 5.11 под Linux/GTK: отображалось пустое окно выбора файла
- Исправлена ошибка: ESC переставал работать после его использования для выхода из меню (Qt)
- Устранены проблемы в работе прерываний на Векторе. "Filer" сейчас работает.
- Исправлена работа клавиш ПК8000 "ВЗ" и "ИЗ" на клавишах "/" и "*" дополнительной цифровой клавиатуры (SDL)
- Исправлены другие небольшие ошибки

этот долбанный Qt5 добрался и сюда...

а Portable SWL/wx-версия, windows-сборка
функционально сильно отличается от Qt версии?
кроме все на горячих клавишах

- - - Добавлено - - -

Цитата:

---

Сообщение от Pyk

- Устранена проблема с размером окна отладчика в Windows XP (Qt)

---

о_О
тоесть оно должно работать?
ладно попробуем еще как то запустить

NEO SPECTRUMAN, практически не отличается. Некоторые не самые важные настройки правда отсутствуют в интерфейсе, их придется менять непосредственно в конфиге. И еще кажется так и не назначил горячую клавишу на сохранение RAM-диска (на загрузку есть). Также в этой версии чуть больше лаг звука. Я эту ветку не забрасываю и поддерживаю наравне с Qt.

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

Цитата:

---

Сообщение от Pyk

Qt может нравиться или нет

---

последние версии уже не работают в XP
как он можот нравится после этого?

- - - Добавлено - - -

qt5.4? точно работал

5.7 уже все

последние рабочие
Qt 5.5
Qt 5.6 (LTS) - так же подписана как последняя для висты

NEO SPECTRUMAN, Emu80 требует Qt не ниже 5.6. То есть на XP работать будет. Выкладываемые сборки собираю с Qt 5.7: хотя для него и не заявлена работа под XP, на самом деле Emu80 работает под XP без нареканий. Единственное ограничение - только в режиме OpenGL, то есть видеокарта должна быть как минимум не очень древняя и слабая (DirectX на XP не поддерживается из-за ограничений используемой в Qt сторонней библиотеки Angle от Google).

А что, какие-то версии Emu80/qt не работали под XP?

Цитата:

---

Сообщение от Pyk

А что, какие-то версии Emu80/qt не работали под XP?

---

ну дык как они могут работать если уже идут с 5.7 в комплекте

- - - Добавлено - - -

5.6 щас у себя ищу...
за одно похерил у себя другую прогу на qt
которая уже перешла на 5.11
...

Цитата:

---

Сообщение от NEO SPECTRUMAN

ну дык как они могут работать если уже идут с 5.7 в комплекте

---

А какую ошибку выдает?

Просто я проверял под XP разные версии и на разных системах - все работало (видимо, в той части, которая требуется Emu80, Qt 5.7 достаточно XP).
Но могу для теста и с 5.6 собрать (просто подменить dll от другой версии Qt не выйдет).

Нашел проблему на своей стороне
Венда не вышла из 16 бит на точку
при смене схемы питания

- - - Добавлено - - -

щас попробую подсунуть эти библиотеки другим софтварям

ок значет пока не заюзаны новые фичесы
5.7 тоже может работать

если подсунуть emu80 qt по новей
то уже традиционная ошибка
про отсутвстие cancelioex в кернел32 который добавили не то в висте не то в 7-ке

А нельзя в отладчик ввести новую команду, по которой программа могла бы проверять состояние флага разрешения прерываний? Уже пару недель не могу найти ошибку, из-за которой в программе, время от времени, самопроизвольно запрещаются прерывания. Весь проект встал.
Ну или возможность постановки бряка на этот флаг, но там нужно как то отсеивать изменения по rst 7, а то задолбает всплытиями.

DemonId7, придумаем что-нибудь. Проще всего прямо в код добавить проверку и сделать специальную сборку, могу попробовать вечером.

Для очистки совести спрошу только: проблема воспроизводится на реале? У меня в эмуляторе была ошибка, которая как раз проявлялась в том, что в редких случаях самопроизвольно запрещались прерывания. Вроде бы я ее исправлял уже, но мало ли...

- - - Добавлено - - -

Еще один вариант проверки, кстати: поменять процессор в конфиге на z80 и проверять командой ld a, i.

Проблема есть и на реале, "зависание" в любой момент времени, непредсказуемое и непонятное (точнее бесконечный опрос буфера клавиатуры, который без прерываний никогда не заполнится). Если в отладчике ручками добавить в буфер клавиатуры что-то, то программа без проблем работает дальше и даже могут опять появиться прерывания. То есть, это не порча кода, не джампинг в неизвестность, а "просто" исчезают прерывания, скорее всего где-то в недрах BIOS "Суры". Понятно, что это как-то связано с моим кодом, но вот как - пока даже представить не могу. Чертовщина какая-то :)

Цитата:

---

Сообщение от Pyk

Еще один вариант проверки, кстати: поменять процессор в конфиге на z80 и проверять командой ld a, i.

---

Просто заменить процессор не получится, там нужно BIOS патчить. Кажется товарищ ivagor этим когда-то занимался. Меня это не устраивает, поскольку проблемы скорее всего как раз во взаимодействии с биосом "Суры" - в моем коде нет ни одного байта с кодом 0xF3.

Извините, вклинюсь, раз речь зашла о совместимости пзу ПК8000 с z80. Раньше патчил основное пзу, но его вряд ли кто будет менять, а в этом году переделал под внешнее. Только такой вариант не совместим с другими внешними пзу, например досами, что весьма печально. Собирался подумать на эту тему, но так и не собрался, выкладываю как есть. Кроме совместимости с z80 здесь поправлена маленькая математическая неточность/особенность. В комплекте конфиг для emu, но думаю легко переделать и под emu80 по аналогии.

DemonId7, см. почту.

Слепил наспех отображение в отладчике адреса последней
выполненной команды DI и состояние стека при этом.
На случай, если еще кому-то вдруг понадобится:

http://emu80.org/v4beta/Emu80qt_40341_test.exe.zip

Цитата:

---

Сообщение от DemonId7

в моем коде нет ни одного байта с кодом 0xF3.

---

Чисто теоретически можно представить вариант запрета прерываний и без DI. Вход в обработчик по прерыванию и нештатный выход из него без EI.

Цитата:

---

Сообщение от Pyk

Слепил наспех отображение в отладчике адреса последней
выполненной команды DI и состояние стека при этом.

---

Указывает на подпрограмму чтения состояния жесткого диска из ПЗУ контроллера, в стеке тоже сплошь адреса из того же ПЗУ (видимо команды на чтение сектора). Бряк на этот адрес результата не дает, прерывания исчезают, а всплытия по бряку нет.
Остается вариант аварийного завершения RST 7. Интересно, чего же я такого слепил, что даже прошитый в ПЗУ обработчик прерывания вылетает :)

Цитата:

---

Сообщение от ivagor

Чисто теоретически можно представить вариант запрета прерываний и без DI. Вход в обработчик по прерыванию и нештатный выход из него без EI.

---

Да, только это и остается.

DemonId7, завтра попробую сотворить что-нибудь для отлавливания такого случая...

Например можно запоминать адрес, где произошел последний запрет прерывания и "тип" запрета - DI или вход в обработчик. Когда зависли - смотрим, кто запретил.

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

Нашёл ошибку. В модуле CP/M BIOS обработчик rst 7. Я его практически полностью срисовал с оригинального МДОС (что на дискетах). Там на входе проверяется последний байт, откуда был вызван обработчик, и если он равен 0xFF, то происходил выход из обработчика, без вызова обработчика в ПЗУ и без разрешения прерываний. Когда приходило прерывание на команде mvi L,0xFF, то и исчезали прерывания.
Никогда не знал для чего эта проверка. Теперь знаю - чтобы мозги пудрить :D
Походу будет очередной релиз CP/M.

Pyk, спасибо за помощь.

Цитата:

---

Сообщение от DemonId7

проверяется последний байт, откуда был вызван обработчик, и если он равен 0xFF, то происходил выход из обработчика, без вызова обработчика в ПЗУ и без разрешения прерываний

---

Похоже на "пропуск" команды rst 7, но на следующий вопрос - "а зачем?" нужно разбираться (в чем вряд ли есть смысл).

Скорее всего, кем-то задумывалась проверка на явный вызов обработчика по команде RST 7. Но зачем это было нужно и почему автор был уверен, что такая проверка будет всегда корректно работать - не понимаю...

- - - Добавлено - - -

Упс, ivagor меня опередил ;)

В оригинальном коде видны следы другого кода, в частности попытка останавливать мотор дисковода по таймеру. Рискну предположить, что и этот непонятный код из той же серии.
Еще раз спасибо, без этого отладчика я бы ни в жизь не нашел источник проблемы :) Теперь можно заканчивать софтину, осталась немного.

Возможно это традиция для разработчиков ПК8000. В основном пзу в обработчике прерывания тоже есть фрагмент-рудимент (c 2600h) который не используется (по крайней мере я не нашел, кто и как мог бы его вызвать).

Pyk, кстати на заметку -- недавно столкнулся с этим, вдруг пригодится для RPi. Запускал v06x на андроиде. И вот на одном телефоне все хорошо, а на другом, более древнем, при включенном аудио-фильтре хрюкает и тормозит. Фильтр мудреный, 100 отводов, с simd инструкциями завернутыми в страшный темплейтный код, кто его знает.. Убираю вычислительную часть фильтра, ничего не улучшается. И тут я заметил, что смещение входного буфера, в который семплы складываются по 1.5e6 штук в секунду, увеличивается выражением вроде i = (i + 1) % sizeof buffer.

На современных x86/amd64 этого вообще не заметишь. А на ARM %, в зависимости от тыщи параметров, может компилироваться в библиотечный вызов даже с -O3. И тогда один целочисленный % 1500000 раз в секунду легко перевешивает умножитель-сумматор с плавающей точкой с сотней отводов, но 48000 раз в секунду. Переделал на обычную проверку на переполнение и все стало быстро, а вычислительная часть фильтра выполняется практически незаметно.

svofski, спасибо за полезные наблюдения, буду иметь в виду. Я правильно понял, что там было даже не 64-битное деление?

А с телефонами на android/ARM тоже недавно немного поэкспериментировал - тормозит со звуком, скорее всего по аналогичной причине. Считаю, что нормальная работа на ARM важна, обязательно вернусь к этому вопросу, в том числе попробую выловить % в критичных участках. Но это все скорее уже ближе к осени, летом руки нечасто доходят до эмулятора... А вообще emu80 сам по себе более тормозной из-за того, что ради унифицированности зачастую приходилось жертвовать эффективностью...

Pyk, нет, обычный unsigned int. Транслируется в __aeabi_uidivmod, это фишка арма. Собственно можно скомпилировать с -save-temps и пошукать по .s файлам.

Цитата:

---

Сообщение от Pyk

Исходники (GPL v.3):
https://github.com/vpyk/emu80v4

---

Жаль, что нет сборки под MacOS :(

Цитата:

---

Сообщение от Manwe

Жаль, что нет сборки под MacOS

---

Действительно...
Кто поможет сделать сборку? :)

Ну, раз желающих помочь нет, пришлось самому ;)
Протестируйте, плиз, сборку под MacOS, у кого есть возможность:
http://emu80.org/v4beta/Emu80qt_40344_macos_test.zip

У меня в виртуальной машине иногда падает при запуске или переключении компьютеров, пока не разбирался, в чем дело. Неплохо бы проверить на реальном маке.
Буду рад также любым замечаниям по работе эмулятора и по построению сборки.