Аппаратная эмуляция GS/TFM/AY

[Black_Cat]

... скориона, хдд со смуком, джойстика, перенаправления клавишей, режимов 16с, 512х, гигаскрина, принтера, дизасма в файл, точек останова по портам, ....Владимир, а можно будет сразу подумать о выделении блоков эмулирующие AY, TS, TSFM, GS, так чтоб возможно было реализовать дополнительную функцию вашего эмуля - эмуляцию этих устройств для реалов, не имеющих их в своём составе?

Суть идеи следующая:

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

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

[Vladimir Kladov]

о выделении блоков эмулирующие AY, TS, TSFM, GS
Я и так пишу на модульном языке, и выдрать нужные модули наверное будет несложно, хотя воспользоваться ими будет несколько сложно из С/С++ (азве что через DLL). Но то, что вы предлагаете мне не кажется необходимым встраивать в эмулятор. Проще реализовать как отдельный специализрованный эмулятор конкретного девайса.

Добавлено через 3 минуты
Режим Gfx256 почти-почти, часть игр уже идёт. Надеюсь до праздников всё-таки добить его...

[ZEK]

интерфейс COM порта она будет связываться с РС
Латентность будет смертельно большая (в смысле для качественой работы), к тому же эмули работают не в реалтайме (на широком круге ОС недостижимо) а порциями по 20мс, то есть пока не набьеш буфер в 20мс длиной для звука его на звуковуку не посылают

[Black_Cat]

Латентность будет смертельно большаяда, винда эт не RTOS и в разные моменты времени время отклика может быть разным, и пожалуй для AY/TSFM это будет достаточно критично, но на GS и MP3 это практически не скажется, т.к. латентность будет сказываться только на моменте запуска проигрываемых блоков (т.е. на моменте управления), но не на самих блоках, а это не критично и особо не играет роли т.к. даже при коротком блоке длиной в 1 сек. задержка на 20 мсек будет неощутима. Что касательно эмуляци AY/TSFM, то тут конечно нужно пробовать на сколько это критично, т.к. латентность здесь по идее будет сказываться на равномерности темпа мелодии. Возможно с помощью задания максимального приоритета эт и можно будет довести до приемлемого незаметного уровня неравномерности.

[ZEK]

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

вот теперт и представь что произойдет с софтиной которая к примеру постоянно опрашивает состояние ГС, или котороя юзает его возможность эмуляции Квовкса

в общем забудь за химеру это бред

[Black_Cat]

что произойдет с софтиной которая к примеру постоянно опрашивает состояние ГС
она же статусный регистр опрашивает, а он стоит в мультяхе и устанавливается по данным от эмуля, сами же опросы этого регистра никуда дальше него не идут. Задержки будут, но они не особо критичны.
или котороя юзает его возможность эмуляции Квовксаэмулировать ковокс на такой системе нет смысла, только если все данные уже находятся внутри памяти GS, а в этом случае не вижу никаких проблем

[ZEK]

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

[Black_Cat]

Ага на целый кадр это мелочивремя распространения нервного импульса от пальцев руки например - 0,1 с, а задержка в 20 мс - эт в 5 раз меньше.. думаю разницы никто не заметит

[Vitamin]

время распространения нервного импульса от пальцев руки например - 0,1 с, а задержка в 20 мс - эт в 5 раз меньше.. думаю разницы никто не заметит
А еще уши дальше глаз расположены, посему вспышку молнии видим раньше, чем слышим гром.

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

[Black_Cat]

т.к. не кодер, то представляю с трудом :) пож поподробнее на каких этапах будут проблемы и в чём они будут выражаться?

[Vitamin]

в чём они будут выражаться
В заторможенной реакции компьютера на воздействия человека (равно как и обратное).

[Black_Cat]

В заторможенной реакции компьютера на воздействия человека (равно как и обратное).человек-то тут при чём? вопрос стоит об взаимодействии Спека с эмулем отсутствующих у него звуковых устройств, эмулируемых на РС (например). В чём ты видишь проблему?

[Vitamin]

А звуки из колонок в конце концов тоже спек с эмулем на пару слушают?

[Black_Cat]

блин, Vitamin!! харе мозги пудрить и воду лить! объяснись пож что за проблемы ты считаешь будут и в чём потвоему они будут выражаться!

[Vitamin]

харе мозги пудрить и воду лить
Не боись, я тебе не конкурент! %)


объяснись пож что за проблемы ты считаешь будут и в чём потвоему они будут выражаться!
В большой латентности. Тебе heroy уже расписал все в деталях.
Наглядный пример- эмулируем АУ. Запускаем трекер и удивляемся, почему у нас звук запаздывает чуть ли не на ноту (при высокоскоростном треке), а спектроанализаторы вообще хрень показывают (либо получая данные из плеера, как в SoundTracker'e, либо считывая их обратно из чипа, что есть двойное запаздывание).

[Black_Cat]

Запускаем трекер и удивляемся, почему у нас звук запаздывает чуть ли не на ноту (при высокоскоростном треке)тебе-то какая разница если ты ни на слух, ни визуально это не можешь отследить? или ты хочешь сказать что знаешь в какой момент относительно видеоряда должен начинаться каждый звук?
а спектроанализаторы вообще хрень показывают (либо получая данные из плеера, как в SoundTracker'e, либо считывая их обратно из чипа, что есть двойное запаздывание).даже если они вообще ничего показывать не будут - НА ЗВУКЕ ЭТО НИКАК НЕ ОТРАЗИТСЯ!
Мне приходилось наблюдать в мр4 фильмах рассогласование видеоряда со звуком, дык на ~0,5 сек это начинает замечаться, притом только по артикуляции актёров! А ты здесь по артикуляции чего это заметишь? Дык даже по спектроанализаторам ты рассинхронизацию в два кадра не заметишь, т.к. у тебя инерционность зрения не позволит!

[Vitamin]

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

Я когда эмуль отлаживал, 2-3 фрейма уже замечал опаздывание звука (в основном, звук нажатия клавиш), 1- с трудом, но заметно.

[Black_Cat]

Я когда эмуль отлаживал, 2-3 фрейма уже замечал опаздывание звука (в основном, звук нажатия клавиш)дык нажатия клавиш через бипер идут - его эмулировать никто и не собирался, он в каждом Спеке и так есть. Эмулироваться должны только малораспространённые девайсы типа GS и AY/TSFM

[Vitamin]

дык нажатия клавиш через бипер идут
Не везде


Эмулироваться должны только малораспространённые девайсы типа GS и AY/TSFM
Ну АУ я б не отнес к малораспространенным девайсам... По крайней мере, он распространен на порядки больше, чем мультикарта.

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

[Black_Cat]

К тому же, оценка запаздывания в несколько фреймов- оценочная. На деле результат может быть и лучше и хуже.ну ты тоже учитывай что ессно никто не обещает 100% качества, оно должно быть приемлемым для среднего непродвинутого юзверя, не имеющего возможности прикрутить к своему старенькому компу AY + шину NemoBus да ещё и найти где-то за 1500р GS, который вообще не производится..

[ZEK]

думаю разницы никто не заметит
wait в 20мс кто угодно заметит

[Black_Cat]

wait в 20мс кто угодно заметит
это не вайт, а рассинхронизация видео и аудио. Сам же звуковой поток в эмуле будет идти слитно без разрывов
А такую задержку человек не в состоянии отследить, иначе бы это давно и повсеместно заметили на всяких видеопреобразователях, где запоминается кадр! ..а в реале этого никто не замечает!!

[ZEK]

Black_Cat
Ну ты издеваешся??
К примеру мы находмисмся в 1/3 части кадра, и спрашиваем у ГС какой щас трек(и как они там называются) воспроизводится, что бы ГС могла на это ответить ей нада проэмулить 1/3 кадра, а она не будет этого делать пока не наберется фрейм

Добавлено через 1 минуту
Vitamin, я че думаю, последняя нить рассуждений не совсем в тему??

[Black_Cat]

что бы ГС могла на это ответить ей нада проэмулить 1/3 кадра, а она не будет этого делать пока не наберется фреймвот здесь не понял на счёт проэмулить 1/3 кадра и ждать до полного фрейма - эт зачем?

[ZXMAK]

Латентность будет смертельно большая (в смысле для качественой работы), к тому же эмули работают не в реалтайме (на широком круге ОС недостижимо) а порциями по 20мс, то есть пока не набьеш буфер в 20мс длиной для звука его на звуковуку не посылают

на pc звук с реакцией 20 мс это практически недостижимо, для этого нужно dsp или чтонить аппаратное использовать. Обычно в win хорошая реакция звука 50-100 мс, задержку больше 100-150 уже можно заметить, если очень внимательно следить. 200-500 мс уже можно заметить на контрастных фрагментах (например щелчек с одновременной вспышкой на видео).
Да и DirectX сам по себе, незаметно для софта делает задержки для звука и видео, он старается держать один-два кадра про запас... Но программно это не заметишь... :v2_cool:

в Win XP минимальный time slice у менеджера потоков в нормальном режиме равен 130 ms (!), не путать с quantum (10 ms). Поэтому реально можно расчитывать на работоспособность кода раз в 130 мс... В наиболее благоприятном случае (в системе все остальные потоки простаивают) можно расчитывать на 10 мс, что в реальности бывает не так уж и часто и уж точно не стабильно... quantum конечно можно уменьшить до 1 мс (timeBeginPeriod), немного увеличив время реакции когда (только для благоприятных условий) но это плохо отразится на производительности многопоточных программ...

[Black_Cat]

но это плохо отразится на производительности многопоточных программ...
полагаю что при таком использовании РС никакой другой софт исполняться не будет, но лаги в 100-150 мс эт конечно смертельно.. Тоды остаётся только ДОС, хоть это конечно и весьма неудобно, но в конце концов думаю такой плеер можно загрузить и с дискеты..
Александр, на счёт ДОСа по задержкам можете что сказать?

[Vladimir Kladov]

Вообще-то под виндой есть приоритет real time. Если программа не занимается клавиатурой или мышью, ей можно дать этот самый приоритет. Разумеется, программа должна хорошо работать и не циклить и не виснуть в ожиданиях, иначе восстановить работоспособность системы удастся только ресетом писюка. В случае двухъядерника будучи запущенной в реальном приоритете задаче сожрёт только один процессор, и в принципе, на ПЦ ещё что-то можно будет поделать. С учётом тенденции полного перехода на многоядерники такой режим вполне возможен. И в этом случае разговоры о латентности не нужны, реакция получается достаточно быстрая (в пределах 1 мс). На ГС хватит, и на флопарь какой-нибудь тоже. Что касается АY и других звуковых устройств, не требующих обратной связи, ситуация ещё проще, там хватит и одноядерника и работы в повышенном (но не рилтайм) приоритете.

[ZXMAK]

Вообще-то под виндой есть приоритет real time. Если программа не занимается клавиатурой или мышью, ей можно дать этот самый приоритет.

приоритет ничего не даст, т.к. временные характеристики не меняет. Для каждого приоритета просто отдельные очереди. И пока очередь потоков с высоким приоритетом не пуста, потоки с более низким приоритетом процессорное время не получат. На время переключения потоков это никак не влияет :v2_wink2:

Добавлено через 4 минуты

реакция получается достаточно быстрая (в пределах 1 мс).

реакция 1 мс на Windows в нормальном режиме невозможна, т.к. quantum = 10 мс, да еще и поток в системе явно не один крутится :v2_wink2:

Если уменьшить quantum до 1 мс (timeBeginPeriod, DX вроде сам это делает при эксклюзивном захвате видеоадаптера), то рекация в 1 мс будет очень и очень нестабильной, плюс проблемы с многопоточностью :v2_wink2:

Добавлено через 10 минут

на счёт ДОСа по задержкам можете что сказать?

дык дос онже однопоточный :v2_wink2:
Да, чтобы получить 20 мс, сама звуковая карта должна иметь задержку не превышающую это значение (X-Fi вроде этому условию удовлетворяют)

[Black_Cat]

дык дос онже однопоточныйДОС, эт конечно вариант запасной, но если чисто теоретически, то зачем нам для эмуля звуковых устройств больше?

Добавлено через 7 минут

X-Fi вроде этому условию удовлетворяютчто за зверь? под ДОСом боюсь что ни на что другое кроме SBPro ориентироваться не получится

[Vladimir Kladov]

приоритет ничего не даст, т.к. временные характеристики не меняет.Да неужели? :) Мы говорим о разных вещах? Какие такие характеристики не мяет рилтайм? А вы пробовали ЧТО-НИБУДЬ КОГДА-НИБУДЬ запустить в РИЛ-ТАЙМ приоритете? А вы попробуйте, на какой-нибудь безобидной игрушке. Если у вас система намертво не зависнет после этого, то вы получите представление о том, что такое рил-тайм и однопользовательский режим в винде. Понятие время реакции исчезает. Правда, ничего больше и не работает, даже не пытается.

[ZXMAK]

Да неужели? :) Мы говорим о разных вещах? Какие такие характеристики не мяет рилтайм? А вы пробовали ЧТО-НИБУДЬ КОГДА-НИБУДЬ запустить в РИЛ-ТАЙМ приоритете?

пробовать то пробовал, но толку от него ноль. И вообще если нет четкого понимания к чему приводит изменение приоритета, то его лучше вообще не менять. Приоритет в Win XP изменяет очередность выполнения потоков, но не меняет время переключения. :v2_wink2:

устанавливать повышенный приоритет для потока который жрет много процессорного времени вообще глупость редкая.

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

На самом деле, скажу по секрету, низкоприоритетные очереди всетаки будут выполнятся, даже если очередь с более высоким приоритетом не пустует. Происходить это начнет через 5-10 секунд отсутствия процессорного времени у низкоприоритетных потоков. времени они будут получать совсем мало - крохи, но чтото достанется :)

[Vladimir Kladov]

если нет четкого понимания
У меня есть чёткое понимание. Если нет понимания, есть MSDN.

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

низкоприоритетные очереди всетаки будут выполнятся, даже если очередь с более высоким приоритетом не пустует.
Ну-ну. И нажатие на клавишу альт-таб где-то минут за 20 будет обработано. (После чего обнаружится, что то окно, в которое мы таким макаром попали, ещё минут 10 перерисовывается). Видал я и такое :) Если нет понимания, то кнопка ресет только и поможет.

[ZXMAK]

У меня есть чёткое понимание. Если нет понимания, есть MSDN.


могу вас огорчить, в MSDN эта тема не раскрывается. :v2_laugh:




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


и тут ошибочка, даже такому жадному потоку win xp даст проработать непрерывно не более 130 мс. :v2_wink2:



Максимум для чего система прервёт рил-таймовую программу - если оживёт драйвер важного устройства типа хдд или таймера,


нет, win xp прервет любой поток, с любым приоритетом. Прервет и отдаст другому потоку из очереди с такимже приоритетом.

Ключевое заблуждение в этом вопросе, в том, что якобы "реалтайм" приоритет делает поток realtime. Это не так Windows не является системой реального времени и потому не гарантирует время реакции на событие, вне зависимости от приоритета потока.

Повышением приоритета до реалтайм в виндовс вы только ухудшите время реакции.

Еще раз подчеркну - приоритет потока в Windows не влияет на время реакции, т.е. на скорость переключения потоков. Т.е. не выполняется главное требование для realtime системы. Повышение приоритета влияет только на очередность получения потоками процессорного времени. Сами интервалы работы планировщика не меняются. На quantum приоритет не влияет.



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


глупости, повышением приоритета скорость реакции увеличить не получится, зато тормознутость системы в целом увеличится очень значительно.



Ну-ну. И нажатие на клавишу альт-таб где-то минут за 20 будет обработано. (После чего обнаружится, что то окно, в которое мы таким макаром попали, ещё минут 10 перерисовывается). Видал я и такое :) Если нет понимания, то кнопка ресет только и поможет.
[/QUOTE]

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

[Vladimir Kladov]

могу вас огорчить, в MSDN эта тема не раскрывается.Я жутко огорчён. Набираю Sleep, и нахожу всё, что нужно. В том числе ссылочку на стью Scheduling Priorities. Да, они договаривают. Но есть ведь и ещё и опыт.


даже такому жадному потоку win xp даст проработать непрерывно не более 130 мс.
Я фигею. И больше не запустит? Не говоря уже о timeBeginPeriod, действующем глобально на все программы.
Почему же тогда если дать тако приоритет какой-нибудь левой программе, то всё вешается навсегда?

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

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

Добавлено через 24 секунды

[ZXMAK]

Я жутко огорчён. Набираю Sleep, и нахожу всё, что нужно. В том числе ссылочку на стью Scheduling Priorities. Да, они договаривают. Но есть ведь и ещё и опыт.


вот после msdnа многие люди и пребывают в заблуждении, что Sleep(1) отдаст процессорное время на 1 мс... :v2_wink2:



Я фигею. И больше не запустит? Не говоря уже о timeBeginPeriod, действующем глобально на все программы.
Почему же тогда если дать тако приоритет какой-нибудь левой программе, то всё вешается навсегда?


У меня задачи писать проги которые не вешаются, проги которые вешают комп я пользовать не стану. Поэтому и приоритет REALTIME я использовать не стану, как бы вы меня не уговаривали :v2_laugh:

Если вам нужно реализовать реакцию в 20 мс, то приоритет REALTIME вам никак не поможет. Это можно сделать только модифицировав ядро Windows... Сделав из Windows realtime систему. Realtime приоритет не делает из Windows realtime систему. Время реакции у потока с realtime приоритетом кстати увеличится :v2_biggr: Это просто неудачное название для приоритета