Emu80 v.4

[zx_]

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

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

[Advertiser]

[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]

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

Попробовал, не работает. Ничего не происходит при запуске, видимо для иной Windows. Пробовал в разных каталогах в т.числе и в каталоге \Documents and Settings\, хотя у меня системный диск D:, а не C:. Кстати "лайт" и полная версия жрут, кажется, одинаковый ресурс.

Зато по Вашей картинке понял, где смотреть загрузку процессора. На русскоязычной Win XP этот столбец вместо CPU называется ЦП. Я не знал, что это загрузка процессора конкретным процессом и смотрел общую загрузку "Загрузка ЦП" в вкладке "Быстродействие". У меня при эмуляции СПЕЦИАЛИСТА загрузка 30...35%, а при эмуляции РК86 почти вдвое выше. А если загружены и другие ресурсо-жрущие программы, то и получается 100% загрузка и торможение. Кстати загрузка EMU от b2m тоже не 5%, а 9...12%, но зато она одинаковая при эмуляции СПЕЦИАЛИСТА и РК86.

Вообще-то, если не использовать одновременно другие программы и запустить EMU80 и никогда не выходить из него, то быстродействия более-менее хватает. Но если выходить и затем снова перезагружать EMU80, то быстродействие падает. Сейчас в этом разобрался. К тому же поднял быстродействие за счёт оверклока. Когда снимал радиатор с CPU, удалил теплопроводящую пасту, т.к она высохла. Из-за этого процессор перегревался и понижал себе частоту. Хотя радиатор не был горячим. Решил смазать вентилятор и одновременно нанёс новую теплопроводную пасту. Оказалось паста очень полезна. Температура процессора упала и процессор без перегрева работает даже на оверклоке.

[svofski]

barsik, шутки шутками, но похоже, что вы можете получить ощутимый прирост в общей производительности, проапгрейдив свой компьютер на Raspberry Pi 3.

Если у вас есть установленный Emu80 и вы умеете запускать в нем Emu80lite, положите мой туда же, где лежит Emu80lite.exe: вот и ответ на вопрос куда именно его класть. И наверное SDL2.dll тоже положите рядом. Я не разобрался сходу как в Code::Blocks прописать статическую линковку для SDL, поэтому dll должен лежать рядом.

Но если вообще получается, что загрузка 70%, то не должны пропускаться клавиши в эмуляции и хрюканья тоже быть не должно. От моего патча, может быть, получится сбросить еще процентов на 10,*но такое трудно прогнозировать.

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

P.S. уговорил Code::Blocks на статическую линковку, exe: http://sensi.org/~svo/b/emu80v4-svofski-static.exe

[barsik]

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

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

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

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

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

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

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

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

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

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

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

[Pyk]

svofski, сегодня, к сожалению, был занят, успел только потестировать готовые сборки с патчем.
На Intel, похоже, деление 64-разрядных чисел не дает мало-мальски заметного прироста производительности. Пробовал запускать в XP на Core2Duo 6420 2,13 ГГц 10-летней давности. Загрузка процессора на gigascreen demo колеблется в районе 35-41%10-16% как с патчем, так и без. Возможно, с патчем процента на 2 меньше - понять сложно. Завтра могу попробовать еще на Atom'е 1,6 ГГц.
barsik же от патча эффект тем более не почувствует, поскольку он работает в конфигурации "Специалиста", в которой не используется ВИ53.
А код я еще посмотрю в плане производительности. Меня пока несколько удивляет, почему именно эта процедура вызывается так часто, что затмевает все другие места, где встречается 64-битное деление. Возможно, просто специфика апогеевской программы, которая очень часто читает значения счетчиков (на какой программе проверялось, кстати?)


barsik, после прочтения последних ваших сообщений возникла одна идея. Не запущены ли у вас случайно параллельно с эмулятором какие-то DOS-программы (они запросто могут отбирать 100% процессорного времени)? Или про какие ресурсо-жрущие программы вы говорите? Просто загрузка порядка 30% на Специалисте - это довольно большой запас производительности...

[svofski]

Pyk, да мы никуда не опаздываем. Я проверял все на Апогее. Не знаю, почему, просто наугад. И первая попавшаяся там демка с гигаскрином меня заинтересовала тем, как она будет выглядеть на ЭЛТ.

Между вызовами updateState() по-моему 17500 циклов времени, а делитель 945. Это важный момент, потому что одно на другое не делится и, если неправильно считать количество тиков, выходит свист. В вычислении тиков до моего вмешательства уже прослеживаются какие-то следы борьбы ;) Вызывается я думаю он в обычных количествах, это же таймер. Еще подумал, что даже сохраняя 64-битное время, незачем там вычислять количество тиков в каждом счетчике. Достаточно сделать это в головном модуле один раз за троих.

Я сначала разбирал gperftools, но они не показывали причину вызовов __udivmoddi4(). Тогда я прибег к дедовскому способу: ctrl+c в отладчике, это всегда работает. Вообще я и сам удивлен, что на rpi3 это такая тяжкая операция, возможно я недожал какие-то архитектурно-специфические опции. Но, глядя правде в глаза, незачем там 64 бита иметь. При вот этих значениях, 17500/945, хватило бы на самом деле и 16.

[Pyk]

svofski, смутила меня все-таки относительно высокая загрузка процессора, попробовал сейчас еще раз на том же Core2Duo - неизменно получаются уже другие цифры: 13-16% без патча и 10-13% с патчем на том же гигаскрине. Откуда я взял лишние 30% при тестировании час назад, не понял

[svofski]

Откуда я взял лишние 30% при тестировании час назад, не понял

Не знаю На rpi3 Специалист съедает ~25%.

[barsik]

Вопрос к авторам эмуляторов с поддержкой КНГМД на ВГ93. Формат DD (Double Density), т.е 720 или 800 кб на диск поддерживается, а формат с одинарной плотностью, т.е SD (Single Density) 360 или 400 кб на диск поддерживается?

Предполагаю, что эмулятору, в котором эмуляция ВГ93 сделана не в реальном времени, а на отлове CPU-команд записывающих в регистры ВГ93, совершенно до лампочки низкоуровневый формат - частота импульсов записи и сам низкоуровневый формат (FM или MFM), т.к эмулятор просто отлавливает команду (например, читать сектор) и выдаёт соответствующие данные при чтении из регистра данных.

Если низкоуровневый формат до лампочки, то должна работать самая первая примитивная дискетная защита от копирования дискет ОРИОНА из начала 90-тых, которая была основана на том, что защищающие треки писались в формате SD (MFM), тогда как остальные треки были в обычном формате DD (FM). Программами копирования ОРИОНА эти дискеты не копировались, но к сожалению, специальными программами на IBM PC это копировалось. Потому пришлось усложнять защиту и все мои последующие дискеты нельзя было скопировать.

Проблема только как перенести такие дискеты в формат ODI. В формате ODI все сектора одного размера по 1 кб и идут впритык, без межсекторной информации. На дорожке отформатированной в DD 5 секторов по 1 кб, а на дорожке отформатированной в SD 5 секторов с размером всего по 512 байт.

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

Но это хотя бы позволит использовать дискеты ОРИОНА защищённые от копирования программой CERBERUS.COM от С.Коровкина из Ижевска. Там защита основана на том, что на дорожку пишется дополнительный 6-той ключевой сектор с размером всего в 256 байт. Такие дискеты тоже не могут копировать программы ОРИОНА для посекторного копирования дискет, но специальные программы IBM PC и это копируют.

Чтобы работали более грамотные защиты дискет ОРИОНА, что я применял начиная с 1993, надо хранить в образе диска полные копии дорожек со всей межсекторной информацией. Это увеличит объём образа диска от 800 кб до 1.5 мб.

Вопрос по эмуляции РК86. В реальном РК86, если повысить такт ВТ57 с 1.77 МГЦ до 2.66 МГЦ или даже до 3.2 МГЦ (16:5=3.2), то увеличивается быстродействие РК86 (короче становятся периоды захвата шины). В эмуляторе это так или влияние ПДП вообще не учитывается?

Как изменить такт в РК-КНГМД в эмуляторе?

Сейчас в эмуляторе в РК-КНГМД как бы применён такт 8 МГЦ (16 МГЦ на входе), что и даёт 5 секторов по 512 байт на трек. Но если поставить кварц 10.5 МГЦ, то на ту же DD-дискету на каждый трек влезает уже 7 секторов по 512 байт, что даёт емкость дискеты в 560 кб (574 кб при 82 треках). РК86 для такого формата д.быть немного турбированным. Т.е или иметь повышенный такт ВТ57 или же такт самого КР580 должен быть чуть повыше.

Для турбирования РК86 меняют кварц у ГФ24 на кварц 20...27 МГЦ. Это повышает такт у ВТ57 и у КР580. А чтобы видео-сигнал остался в норме, надо откуда-то брать такт 16 МГЦ для ВГ75. Для этого ставится отдельный генератор на 531ЛН1 с кварцем 16 МГЦ. При кварце 27 МГЦ для ГФ24 реальное быстродействие увеличивается вдвое против ~1.3 МГЦ эффективного такта базового РК86.

Можно ли в эмуляторе, чтобы не макетировать в реале, подставлять свои частоты для КР580 и для ВТ57 и замерять получившееся быстродействие РК86 ?