То есть если я буду менять данные по $2001, то будет меняться яркость экрана?

старшие три бита

Ну а все-таки, СаН4е3, что думаешь по поводу моего предыдущего поста? В нестопии что-то неверно помимо таймингов?

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

На данный момент поступил следующим образом: скомпилировал два exe'шника на основе nestopia140src с разными таймингами.
Nestopia20 [VINT=20/VSLEEP=51] - Подходит для большинства игр, в т.ч. Battletoads/BtDD. Это наиболее "дендиподобный" режим.
Nestopia70 [VINT=70/VSLEEP=1] - Для ромов, испорченных на nestopia20 (James Bond Jr, Power Blade2, Aladdin 199x Unl и нек. др.)
Довольно удобно пользоваться ими из одной папки, не нужно перенастраивать конфигурацию под каждый билд.
При таком варианте и ромы работают хорошо, и высота звукового тона (включая DPCM-канал) аналогична "Денди".

исправление: громкость triangle-канала для денди режима по умолчанию равна стандартным "85" единицам.
Включается режим "денди" так:
1) options - preferences - favored system: [dendy].
2) Machine - Region: [PAL] или [Auto].
3) Закрыть и снова запустить эмулятор.

Обновление 05.10.2009: Скомпилировал в родной среде VS2005 SP1, со стандартными библиотеками DirectX SDK - summer 2004, как было у Мартина.

Скажите пожалуйста,а есть ли на сайте аналогичная тема,только посвященная mеga drive?

Нет. С клонами MD вроде бы нет таких проблем.

Ну не знаю,мне почему то не нравиться то ,что я слышу.Отчетливо это проявляется в Phantasy star 2.Может посоветуете какие-нибудь настройки для Gens или Fusion?

Единственное, что могу посоветовать - включить режим Super HQ в эмуляторах Fusion или Regen, т.к. они наиболее точные в плане эмуляции YM2612. Но и они, говорят, не идеальны. Мне не с чем сравнивать, я не слышал оригинального YM2612. А вообще это вопрос для другой ветки.

Regen, ИМХО, наиболее точен касаемо YM2612, а вот касаемо эмуляции - они оба примерно одинаковы.

Хорошо,может тогда подскажете где ветка находиться с обсуждением эмуляции Mega Drive? Для NES я уже хорошие настройки подобрал.

тут можно создать:
viewforum.php?f=12

Я долго думал, куда это поместить, решил пока сюда. И так, читайте, много буков, но думаю осилите. Код предоставлен на Delphi, кому надо на С - сами сообразите.

Многие хотят, чтобы вывод эмулятора соответствовал тому, что было в свое время на телевизоре. Используют для этого всякие сканлайнеры и блюры, но это все не совсем то. Все дело в том, что мы имели тогда. Обычно - это ЧБ телевизор. Или цветной советский ящик, в особо кошерном случае - с установленным декодером PAL. Так вот, речь дальше пойдет об имитации вывода композита PAL на некачественном телике. Это все применимо и к NTSC, но с некоторыми изменениями в логике согласно стандарту NTSC.

Немного теории. Дендик формирует чистый композит с цветовой кодировкой PAL. Для начала, я объясню, как это работает. Кодирование цвета в PAL использует цветовую модель YUV (как и NTSC, на основе которого он и сделан). Это означает, что изначальный RGB сигнал матрицируется в один яркостный Y и 2 цветоразностных U и V (в телевизорах обозначены как R-Y и B-Y). Такая схема дает обратную совместимость с ЧБ телевизором, т.к. яркость Y есть обычный яркостный черно-белый сигнал изображения. Поэтому, яркость передается так же, как и ЧБ сигнал. Другое дело - цвет. Для полного (если придираться - почти полного) восстановления цвета в картинке, требуется всего 2 цветоразностных сигнала. В системе PAL, эти сигналы модулируют по амплитуде цветовую поднесущую (4,43МГц). При этом, R-Y модулирует синус этой частоты, а B-Y - косинус (т.е. сдвинут на 90 градусов). Если представить упрощенно, то это выглядит так:

После модуляции этой частоты по амплитуде, оба результата складываются и получается один сигнал:

Видно, что частота не изменилась, а фаза будет зависеть от уровней модуляции R-Y и B-Y. В добавок к этому, каждую строку фаза частоты R-Y меняется на 180 градусов (инверсия). Получается, что каждую четную строку модулированный сигнал R-Y имеет фазу 0 градусов, а каждую нечетную - 180 градусов. Далее, результирующая частота складывается с сигналом яркости. И ее видно на ЧБ телевизоре (его яркостная четкость выше) в виде сетки на окрашенных частях экрана. Причем, из-за того, что при модуляции фаза сигнала меняется, то эта сетка имеет наклон, который изменяется в зависимости от цветового оттенка.

Теперь, что касается самого изображения, как мы его видели и помним. Дело в том, что пропорции дендика не 1х1. Экран телевизора имеет отношение 4:3 (4/3=1,33333~), а соотношение сторон у дендика: 256/240=1,06666~. 256 точек по горизонтали растягиваются на весь участок экрана. Частота строк у телевизора не меняется. При ее стандартной частоте 15625Гц отображаемое поле имеет 48 микросекунд времени. Для 256 точек дендика частота пикселей будет примерно 1/(48/256)=1/0,1875=5,333~МГц (более точно эту частоту мы уже выводили, исходя из тактовой 26,60МГц, где-то тут на форуме). Частота поднесущей PAL - 4,43МГц. Поэтому, на всем экране в 48мкс поместится примерно 48/(1/4,43)=48/0,225=212,64 периода (или чередований белой и черной точек). Если умножить число 212 на 4, то мы получаем рабочее разрешение 848х240 точек. Почему на 4? Чтобы сделать ровной маску сетки поднесущей. 4 пикселя подряд дают 4 фазы: 0, 90, 180 и 270. 0 и 180 будут содержать модуляцию R-Y, а 90 и 270 - B-Y. Это разрешение не кратно 256 точкам дендика, поэтому я решил сжульничать и заюзать меньшее рабочее разрешение: 256х3=768 точек в ширину. Это позволит применить целочисленную арифметику, что ускорит обработку.
Сначала создаем массивы масок поднесущей и заполняем их требуемой фазой:

Массивы содержат "вес" будущей яркости, значение 0,9 выбрано просто для надежности, чтобы не получить переполнение. Далее, берем исходный RGB кадр:

Из него, получаем YUV модель:

Все исходные числа целые (байты к тому же), поэтому можно один раз просчитать таблицу и делать просто табличный лукап. В итоге, к обычному ЧБ изображению с полутонами мы получаем 2 растра цветоразностных сигналов:


Теперь, у нас есть информация о цвете. Мы можем сформировать реальную маску поднесущей:

В результате, мы имеем в MC текущее значение удельного "веса" яркости в данной точке экрана, согласно модуляции PAL. Это будет выглядеть примерно так:

Видно, что присутствуют только окрашенные области. Промодулируем сигнал яркости Y и получим ЧБ ПТЦС.


На этом эмуляцию ЧБ телика можно закончить. Но мы идем дальше. Теперь, из модели YUV получаем обратно RGB и модулируем поднесущей (хотя, теоретически можно модулировать сразу исходный RGB на маску поднесущей, но тогда цвета станут несколько неестественными, однако это все дело вкуса. Просто, в системе преобразование RGB=>YUV=>RGB происходит все равно, к тому же, полоса сигналов R-Y и B-Y значительно уже, соответственно появляются дополнительные искажения):

И получаем следующую картинку (насыщенность цвета несколько снижена, играя с константой 0.4 в формуле можно ее регулировать):

Результирующую картинку разрешением 768х240 уже масштабируем до требуемой (с пропорцией 4:3, например 640х480) битблиттингом с прорисовкой полутонов, что даст нам конечный результат. Можно еще в довесок посканлайнить и добавить немного блюра.

Ну как вам?

PS Несколько замечаний.
Дело в том, что PPU дендика никогда не формирует RGB (именно дендика, PPU с RGB существует, но не в дендике). Поэтому, сам PAL формируется в нем аппаратно сразу. Так же известно, что в нем формируется 12 разных готовых фаз поднесущей, которые потом модулируются по яркости в 4 цвета одного оттенка. Поэтому, можно заготовить сразу все эти 12 патерна и куча вычислений сразу отпадает за ненадобностью. Тёрки про палитру велись на NESDev'е.
По идее, частота поднесущей не привязана к развертке и поэтому сетка должна всегда смещаться. Плагин blarrg'а имитирует смещение, однако конкретно в дендике частота цветовой поднесущей конкретно привязана к развертке и поэтому сетка не смещается (в NTSC версии по идее то же не должна, но смещение несколько повышает четкость картинки).

Однако, многа букав осилил, прям просто даж от обработанной картинки повеяло настальджи

HardWareMan, превосходная вещь. Ты молодец, спасибо!
Хотелось бы узнать - как и куда планируешь применить этот код видеофильтра?
Это часть проекта по "расшифровке" дендика? Если да, расскажи пожалуйста, как продвигаются дела на этом фронте.

Покажи эту работу на nesdev'e, однозначно.

Ломает. Покажи сам, если не лень, а я потом почитаю. Писать ничего не собираюсь - это удел эмуляторописателей.

Немного оффтопа, но к теме.
Я выяснил, что Мартин, оказывается в прошлом (1997-1999 г.) известный трекерщик и его работы высоко ценятся:

Last Sunset ("Бриллиантовая композиция" по рейтингу Modarchive)
Virtual Humanity
Jet Lag
Annie
Playing with Death
Porling Water (красивая печальная мелодия)

Он же известен под никами NightHawk и Reptile, участвовал в демосценерских группах Fairlight Music,
ProFound Sound, the Torrent Project, а также в проекте RetroFX в качестве музыканта.
Вот, кстати, интервью с нашим трекерщиком Eternal Engine. (работы NightHawk'a упоминаются)

Меня все время интересовало, зачем пин №30 у 6527 (смотрите вложение) заземлен? Где-то я слизал, что это BUSREQ. Захват шин. Но вполне мог быть и RDY/WAIT. Т.е. нужный нам сигнал синхронизации. Проводя эксперименты, я определил, что это все же захват шин, а не сигнал готовности. При этом, правда, я потерял комплект 6527/6538 изза бл**кой КРЕНки, у которой оторвалась земля в самый разгар экспериментов. Картридж, на счастье, выжил. Вот мои выводы:
1. Сигнал захвата шин. Если лог.0, то все пучком и проц пашет. Если лог.1 то проц бросает шину (F2=0).
2. Надолго захватывать шину нельзя. Иначе сбрасываются мапперы картов, которые используют F2 для распознавания сброса.
3. pAPU питается от F2! При захвате шин все звуки замолкают и продолжаются при восстановлении BUSREQ=0. Причем, если формировать BUSREQ так, чтобы растянуть цикл обращения (и изменить F2), то частота звуков pAPU меняется.

Discuss же.

В даташите от UMC он обозначен как RDY. И написано следующее:
This input signal allows the user to halt the 6502 microprocessor on all cycles except write cycles. A negative transition to the low state during or coincident with phase one (Ф1), will halt the microprocessor with the output address lines reflecting the current address being fetched. If ready is low during a write cycle, it is ignored until the following read operation.
(прошу прощения, если где есть опечатки)

Rumata, у тебя есть даташиты на UMC UA6527P/6538 в PDF ?
Любые раритетные документы по этим чипам могут пригодиться.
Если есть возможность сделать электронные копии - было бы очень хорошо.