Emu80 v.4

[svofski]

С музыкой на первый вслух все отлично.
Гигаскрин ожидаемо: фуллскрин очень хорошо, если нет эпилепсии и учитывая обстоятельства, смыргивает изредка, но в целом отлично. В окне ой. Наверное есть параметр не использовать vsync, когда в окне?

Когда камера настроена на 25 fps, выглядит вообще как будто много цветов:

Но на самом деле все мерцает. И когда в видео видно смыргивание, на экране смыргивает совсем сильно. В общем я думаю это точно так же, как и на 100% лцд мониторов на 60Гц на любой системе.

Пойду-ка соберу на расбери-пи, она у меня к ЭЛТ 50 Гц подключена, правда чб.

[Advertiser]

[Pyk]

смыргивает изредка, но в целом отлично

Ну да, это из-за небольшого несовпадения 60 Гц в Апогее и 60 Гц на мониторе.

В окне ой. Наверное есть параметр не использовать vsync, когда в окне?

Есть параметр emulation.frameRate в emu80.conf, там можно выставить принудительно частоту обновления экрана вместо привязки к vsync. Но параметр общий, будет работать как в оконном, так и в полноэкранном режимах. Под Windows и под Linux проблем в окне нет, vsync работает точно так же - видимо, есть какие-то нюансы с SDL под macos? Либо это специфика самой macos?

Когда камера настроена на 25 fps, выглядит вообще как будто много цветов

Для того же эффекта можно еще window.fieldsMixing = mix в apogey.conf раскомментировать. Будет так же, как в эмуляторе uart.

Пойду-ка соберу на расбери-пи

Подозреваю, что быстродействия может не хватить Но попробовать можно

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

на расбери-пи, она у меня к ЭЛТ 50 Гц подключена

На 50 Гц хуже будет - в этих режимах Апогей на частоту 60 Гц программируется...

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

А видео в предыдущем сообщении сделано в 30 fps...

[svofski]

видимо, есть какие-то нюансы с SDL под macos? Либо это специфика самой macos?

Видимо это специфика макоса или SDL под нее. По крайней мере у меня получается все то же самое.

Подозреваю, что быстродействия может не хватить

Для Raspberry Pi 3:

CFLAGS += -mcpu=cortex-a53  -mfpu=neon-fp-armv8 -mfloat-abi=hard

Где-то на грани. Мельтешение то частое, то быстрое, звук то еще как-то, то совсем хрипит. Видно, что ему _очень_ тяжело. При этом загрузка всего 100% одного ядра и температура 58 градусов.

Понятно, что под рпи3 надо оптимизировать. Есть Neon, есть 4 ядра.

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

А видео в предыдущем сообщении сделано в 30 fps...

25, но ютуба знает лучше, как нам надо.

[svofski]

УФ!

Pyk, вот! https://github.com/vpyk/emu80v4/pull/1

Для распи главное, чтобы 64-битных делений было поменьше. Одно вот это изменение и теперь все влезает в 50% одного ядра.

Пойду попробую запущу ЭЛТ на 60 Гц, раз так.

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

Да, на 60 Гц Гигаскрин хорошо, хотя не могу сказать, что это как-то принципиально лучше, чем на LCD. И все равно он смыргивает где-то раз в секунду.

[barsik]

Одно вот это изменение и теперь загрузка CPU одного ядра сократилась до 50%

Хорошо бы это изменение по ускорению EMU80 внести и в базовую версию EMU80 для IBM PC.

Потому, что, уж извините за правду, эмулятор EMU80 тормозит на одноядерном PC с тактом 2.4 ГГЦ (загрузка CPU 100%). Тормозит не по экрану, с этим всё нормально. А имеет неприятный дефект, - пропускает нажатия на клавиши. Если при эмуляции ОРИОНА и СПЕЦИАЛИСТА это ещё терпимо (хотя при быстром вводе символы пропускаются, чего никогда не бывает на реале), то при эмуляции РК86 вводить с клавиатуры просто неудобно, надо нажать и удерживать клавишу нажатой примерно пол секунды. Пользоваться таким эмулятором РК86 неудобно, хотя и приходится, если надо прогнать ПО для дисковода. В играх отсутствие реакции на короткие нажатия клавиш, тоже вероятно ухудшит качество игры.

Нельзя ли сделать упрощённую версию именно для РК86, где не будут эмулироваться всякие ненужные для большинства программ свойства ВГ75. Скорее всего, что именно эмуляция этих свойств тормозит, ведь в РК86 текстовый экран, т.е заведомо более быстрый, чем экран у СПЕЦИАЛИСТА и ОРИОНА. Вообще бы не было проблем, если бы из Windows, как и в MSDOS можно было бы установить текстовый режим VGA (загрузив фонт как в РК86), что ускорило бы визуализацию в 50 раз.

Заметим, что все даже самые современные иностранные эмуляторы прекрасно работают даже на самых первых ПЕНТИУМ-ах, что имеют в 50 раз меньшее быстродействие. Для сравнения эмулятор EMU от b2m загружает процессор всего на ~10% и ввод с клавиатуры там беp потерь.

Недавно пока делал CP/M для СПЕЦИАЛИСТА, чтобы сберечь нервы, приходилось использовать EMU, эмулируя дисковод в RAM-диске, и только для проверки работы дисковода требовался именно EMU80, т.к в EMU нужный контроллер дисковода не эмулируется.

Очередная версия 4.0.277 от 30.12.2017: http://emu80.org/v4beta/Emu80_40277.zip

Вылет в отладчик по встрече Z80 команды при эмуляции КР580 - полезная вещь. Это позволило за 15 минут очистить от Z80-команд программу, в то время как при трассировке вручную эта работа заняла бы несколько недель.

Сброс по АЛЬТ+F11 должен работать и в окне отладчика. Иначе трассируя программу и останавливаясь в точках контроля, где для останова поставлена команда HALT, никак не выйти из отладчика, чтобы сделать сброс в основном окне программы. Закрываешь окно отладчика, и снова вылетаешь в отладчик по очередному HALT в программе, т.е никак не вернуться в окно программы, чтобы нажать там АЛЬТ-F11.

[Pyk]

nzeemin, предупреждения clang отработаю. К счастью, среди них не оказалось ничего критического, даже ошибка с битовой операцией, вероятно, не проявляется ни в одной реальной программе.

svofski, спасибо, pull request посмотрю вечером. Насчет гигаскрин-режима: можно посмотреть режим, на который программируется там ВГ-75. Если получится подстроить его на частоту, более близкую к 60 Гц, то "смыргивать" будет реже (кстати, гигаскрин-режим есть еще в заставке к игре lines).

barsik, не факт, что этот патч поможет на процессорах x86. Эмулятор, конечно, не самый быстрый, простор для оптимизации есть, но все-таки он обычно нормально работает и на процессорах с меньшей тактовой частотой, чем 2,4 ГГц. В очередной раз прошу информацию о вашем ПК, чтобы попробовать понять причину тормозов.

А для сброса пока можно переключиться из отладчика в основное окно, нажать Alt-F11 и опять вернуться в окно отладчика. Информация в окне отладчика обновится при следующем шаге.

[svofski]

при эмуляции РК86 вводить с клавиатуры просто неудобно, надо нажать и удерживать клавишу нажатой примерно пол секунды

Это симптом загрузки 100%.
Я построил было Emu80lite для винды со своим патчем. Но в последний момент вспомнил, что у вас XP. Просите Pyk-a сделать тестовый 32-битный билд.

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

Pyk, профайлер еще намекает на то, что еще есть 64-битные деления и что Crt8275Renderer:rimaryRenderFrame() можно было бы улучшить. Типа там можно const Symbol & вместо копирования Symbol, инкременты умножить заранее итд. Но на фоне ВИ53 я не смог даже разглядеть непосредственных эффектов от этих изменений, и не факт, что локальная копия объекта не работает быстрее из-за кеша итд, поэтому я не стал копать в ту сторону.

[zx_]

Потому недавно пока делал CP/M для СПЕЦИАЛИСТА

сделали? под какой контроллер?

[svofski]

barsik, я нашел у себя XP.

Попробуйте вот эту сборку:
http://sensi.org/~svo/b/emu80v4-patched.zip

Это версия lite без интерфейса. Надо распаковать себе в userhome, то есть например c:\Documents and Settings\barsik\emu80
Там из командной строки запустить em80v4-svofski -a (Апогей) или -r (РК)

У меня в затюканной виртуализованной в VirtualBox-е XP на лаптопе 8 летней давности эмулятор съедает около 20% своего виртуального проца:
https://www.dropbox.com/s/5uvsrq9q3b...18.54.png?dl=0

Версия из официальной сборки редко переваливает 30%.

[barsik]

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

Есть три алгоритма эмуляции. Полноценная покомандная эмуляция и покадровая визуализация. Во-времена медленных ЭВМ использовалась покомандная эмуляция. Но она сложна и поэтому сейчас, когда скорости ЭВМ стали это позволять, используется визуализация, т.к это на порядок проще.

Для экранной визуализации также имеется два алгоритма. В грамотных эмуляторах это делается добавление паузы после КАЖДОЙ (!) команды. Это даёт возможность не только подогнать длительность исполнения каждой команды к числу её маш.тактов в реале. Важнее то, что эмулируемая программа прогоняется с той же равномерностью как в реале.

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

А в данном эмуляторе используется покадровая визуализация и применён следующий алгоритм выравнивания скорости. Весь прогон разбивается на фрагменты дискретизации. В 20...50 мсек. Известно сколько маш.тактов выполнит реальный процессор за это время. Эмуляция команд эмулируемого CPU производится на максимальной скорости PC. При этом эмулируемая программа прогоняется на эмулируемом такте 200 МГЦ, и нужное число машинных тактов прогонит всего за 1 МСЕК. Чтобы уровнять скорость прогона, надо остановить эмуляцию на оставшиеся 49 МСЕК. И как раз в это время и делается визулизация - копирование экрана 8-ми разрядки в реальный экран SVGA. Если быстродействия не хватает, чтобы процедурой написанной на ЯВУ вывести весь кадр за 49 МСЕК, то FPS падает (хотя это визуально не вредит), а время вывода кадра подпрограммой написанной на ЯВУ может увеличиться до долей секунды.

Ясно, что в такой концепции прогон происходит рывками, т.е прогнали фрагмент, остановились, затем после паузы - следующий фрагмент. И вот как раз в эту паузу программа не чувствует клавиатуру. Если коротко нажать как раз в момент такой паузы (длиной в доли секунды), то нажатие пропадает.

Исправить такой алгоритм можно 2-мя способами. Во-первых, не допускать потери нажатий клавиш. Т.е фиксировать нажатия. А не только проверять клавиатуру тогда, когда к ней обращается программа. Надо искусственно удлинять нажатия на период больший чем время паузы, чтобы программа 8-ми разрядки могла это обнаружить.

Когда нажатие случается и заканчивается во время, когда происходит визуализация, то оно пропадает для прогоняемой программы. Если эмулятор отнял у программы 8-ми разрядки время, то он должен брать на себя функции обслуживания клавиатуры. Т.е по окончании визуализации, он должен проверить было ли или нет нажатие на клавиши во время визуализации и если оно было, то надо сэмулировать нажатие той же или лучше большей длительности на время когда прогоняется программа 8-ми разрядки. Вот тогда никаких пропаданий нажатий не будет.

Второй способ избавиться от потери нажатий - это сократить период дискретизации. Похоже сейчас пауза равна времени копирования всего экрана 8-ми разрядки в экран SVGA, написанной на ЯВУ. А чтобы сократить период дискретизации лучше в каждой паузе выводить не весь экран, а лишь его часть, например четверть экрана, что в 4 раза сократит время пауз в прогоне и требования к скорости PC.

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

Вывод простой. Надо писать критичные процедуры на ассемблере, а не на ЯВУ. Так было для 8-ми разрядки и так это осталось и для PC со скоростями в тысячи раз выше.