Сообщения

1

Ромхакинг и программирование / Re: [NES и GB] Нужны ромхакеры чтобы убрать музыку из ромов

« : 31 Май 2014, 02:16:50 »

Когда-то по реквесту я отключил музыку в 9 известных играх на SMD и одной игре на SNES. Если кому-то нужно:
http://sonicresearch.org/forums/index.php?showtopic=3693&p=42078

2

Ромхакинг и программирование / Re: [SMD] хакинг игр серии Sonic the Hedgehog

« : 09 Май 2014, 04:23:01 »

Уговаривать не буду (у всех свои дела), просто будет жаль, если такой крутой хак не будет доделан в принципе (не в этом году, а вообще). На данный момент этот хак входит в 20 лучших хаков Соника за всю историю, ИМХО. Хотел сказать это лично.

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

К сожалению, судьба проекта сейчас туманна. Сейчас у меня в жизни появилось много других забот, которые захватили меня настолько, что хакингом я не занимался уже более полугода. Но я не могу утверждать, что проект будет навсегда брошен. Такое уже случалось -- хак замораживался более чем на год, казалось, безвозвратно, но потом воскресал. В тот период я, думалось, почти твердо решил, что никогда больше не возьмусь за него из-за сложившихся обстоятельств и неизбежного устаревания его и обрастания слоем пыли, но оставался еще лучик надежды, потому я решил, что не буду объявлять о кончине проекта.

В итоге новостей о SWA просто не было, и со временем многие люди стали сами спрашивать о нем, они хотели верить в то, что проект не загнулся. Во многим благодаря этому искреннему интересу со стороны многих людей SWA в конце концов воскрес и увидел свет, хотя мне это казалось неосуществимым. У меня тогда было трудный период, времени не было вообще -- и о том, чтобы заниматься крупными проектами я не мог думать уже более года. Но осознание того, что людям нужно то, что ты делаешь заставилось меня совершить чудо. Я собрал все силы в кулак, выкроил время, начал работать ударными темпами и смог закончить все начатое (;

Вот и сейчас, надежда остается. Хотелось бы мне развить SWA еще хотя бы чуть-чуть. К сожалению, возможности капитально сесть за работу над хаком не предоставится до июля этого года. Я понимаю, как это бывает обидно, когда очень перспективный проект, который еще не успел сам раскрыть свой потенциал гибнет в расцвете всего своего потенциала. Не хотелось бы такого допускать. Планы развития проекта у меня есть, причем обширные. Не могу дать полной гарантии, но я постараюсь сделать все, что в моих силах. Будем верить в лучшее!

3

Ромхакинг и программирование / Re: [SMD] хакинг игр серии Sonic the Hedgehog

« : 06 Май 2014, 02:43:05 »

Sonic Winter Adventure делали к конкурсу, но недоделали. А сейчас конкурс прошёл, все видели хаки, и доделывать никто ничего уже не хочет, как я понял...

Хак я делал не для конкурса, а в свое удовольствие. Этот проект -- долгострой, который тянулся с 2009 года и делался по наличию у меня времени и мотивации для работы над проектом. Первую демо-версию Sonic Winter Adventures я выпустил задолго до Хакинг Контеста, в апреле 2013 года.

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

А конкурс, как заметил Razor_ua, будет проводиться и в этом году. Правда шансы увидеть в этом году SWA ничтожно малы, увы.

4

Ромхакинг и программирование / Re: Gopher Mods - Моды игр для поддержки на Sega Gopher

« : 22 Август 2013, 15:58:10 »

У SWA есть поклонники? Не знал (=

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

Собственно, в этой версии переделана система передачи арта, которая раньше использовала DMA из ROM-секции, а теперь M68K переносит данные самостоятельно. Как я неоднократно убеждался, читая эту тему: DMA - самая нестабильная часть эмуляции Гофера. Самое интересное, систему передачи арта я переделал намного раньше для Sega CD версии игры. В эмуляции Кеги присутствует баг, из-за которого не работают DMA-переносы из ROM-секции в Mode 1, пришлось его обходить. Эта альтернативная система без DMA срабатывает, если игра запускается с Sega CD, в этой же версии для Гофера она работает по умолчанию. Медленнее, но надежнее!

Ах да, так и не разместил свое творение на этом форуме, но раз уж дошло до такого, могу исправить это недоразумение.

5

Ромхакинг и программирование / Re: Пишем музыку в стиле 8-ми и 16-битных консолей

« : 09 Июль 2013, 23:04:46 »

У меня такой вопрос:

Чип SN76489 (PSG) в играх MegaDrive/Genesis может использовать только 3-и канала из 4-х?

Я не помню всех деталей, но вроде как у третьего и четвертого каналов PSG общая частота. Насколько мне известно, многие звуковые движки для SMD (если не все) допускают только 3 PSG-канала с возможностью выбора назначения последнего (шумогенератор или тон).

Можно использовать все четыре канала, но на практике это бесполезно или как минимум сложно/не-стоит-того.

6

Ромхакинг и программирование / Re: [NES] Ассемблер перевести в понятный код

« : 29 Март 2013, 01:38:27 »

Код: [Выделить]

SEC
SBC #4
STA spr_buf(32,ycoo)
BCS ret06
SEC - Задать Carry флаг.

SBC отнимает из аккумулятора (А) значение 4 и инвертированное значение Carry-флага. Т.е., если Carry=1, ничего не отнимается, если Carry=0, дополнительно отнимается 1. В процессоре 6502 не предусмотрено отнимание без учета Carry-флага, поэтому флаг Carry специально задается инструкцией SEC, чтобы гарантировать, что SBC отнимает именно 4.

SBC очищает флаг Carry, если при выполнении вычитая случилось заимствование (borrow), т.е. результат пересек границу 00-FF. Например, если отнять из 01 число 04, получится FD, тогда флаг Carry будет очищен. Таким образом...

BCS - Branch if carry set - переходит, если заимствования не произошло (Carry=1).

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

7

Ромхакинг и программирование / Re: Sega MD Sound (Yamaha 2612/PSG) - Что оно такое и с чем его едят

« : 20 Ноябрь 2012, 00:19:53 »

Банк для Z80 - зеркало размером в 32 кб из памяти 68к из области 000000-FF8000. Номер банка может быть то 0 до 511. Для Z80 банк виден в адресах 8000-FFFF.

Небольшая поправка: банками можно обхватить всю область памяти 68K, т.е. $00000-$FFFFFF. Ведь если выбрать банк $1FF (511), стартовый адрес 68K будет как раз FF8000 ($1FF<<15), и это охватит диапозон $FF8000-$FFFFFF.
Но в общем-то, интерес представляет только чтение РОМа ($00000-$3FFFFF), насколько я знаю (по информации от ребят, которые проверяли это на железе), Z80 не может читать 68K RAM ($FF0000-$FFFFFF), но он может записывать в нее.

Я так понял, что в роме в каждом банке лежат сэмплы? А уж сам драйвер распоряжается, как их читать/воспроизводить?

По большому счету, сэмплы можно расположить в любом месте, но обычно, чтобы Z80 драйверу было удобнее с ними работать, их и другие данные выравнивают по границе в $8000 байт (т.е. преславутые 32 кб), чтобы, когда ты подключишь нужный банк, они располагались в самом начале (с адреса 8000h со стороны Z80).

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

8

Ромхакинг и программирование / Re: Sega MD Sound (Yamaha 2612/PSG) - Что оно такое и с чем его едят

« : 18 Ноябрь 2012, 02:43:42 »

Z80-чайник детектед

Серьезно, в чем смысл такого утверждения? Особенно в рамках ответа на мой предыдущий пост.
Я постарался во всех деталях описать все плюсы и минусы использования буферов, но вместо этого ты разглядел одно лишь предложение про LDIR и ответил в духе "ой-ты-ваще-чайник-рассмешил-меня, потому что вот в этом предложении описан не самый крутой способ, можно извращаться и получше".

Если тебя интересует мой опыт программирования на Z80, то в этой области я действительно не претендую на звание профи, и у меня нет в планах постоянно им заниматься. Оно мне понадобилось только для того, чтобы реализовать свою идею - написать годный DAC-драйвер.

К слову, Mega PCM - это вообще первое, что я написал на Z80. Когда приступал, был чайником, конечно, ведь опыта программирования конкретно на Z80 было ноль. В конце же работы над проектом я уже приобрел немало опыта. Моей задачей было написать серьезный и функциональный драйвер, с оптимальным кодом. И думаю, со своей задачей я справился, ведь то, что мой драйвер, с огромным количеством новых возможностей, работает быстрее оригинального драйвера Соник 1, в котором почти ничего нет, уже о чем-то говорит.

ощутимо быстрее будет в цикле подряд по несколько штук LDI

Ну, допустим, ты будешь использовать LDI, да. Ну быстрее, да. Ощутимо. К черту цикл, давай рассмотрим самый наилучший способ - 256 таких инструкций, идущих подряд. (Что кстати займет целых пол-кило памяти).
Ну получится в итоге, что исполнение занимает 7% от времени отображения NTSC-кадра. И все равно не выгодно.

а еще быстрее стеком типа

Ты уверен? Способ-то остроумный. Для переноса 6 байт прокатит (лучше не придумаешь), но нашем случае - сомневаюсь.

Скажем, как ты будешь оперировать оффсетами "куда" и "откуда"? Если оффсеты "куда" статичные и их можно каждый раз загружать как ld sp, xxxx, то в РОМе каждый раз приходится читать с разных мест. В таком случае, по когда ты получил 6 байт из буфера, лучшее, что ты можешь сделать - сохранить значение sp в память, потом записать буфер, заново загрузить sp из памяти. И так каждый раз. А это уже выливается в 40 циклов (20 на ld (xxxx),sp и 20 на ld sp, (xxxxx)). Ну в лучшем случае, это будет на 1-2% быстрее, но, думаю, очевидно, что пляски с сохранением и загрузкой значения стека сводят на нет всю гениальность этого метода + жирный размер кода.
Добавлено позже:

ты видел демку BadApple!!!9 в соседней теме ? так там Z80 вполне себе играет 4bit 13kHz ADPCM

Ты хотя бы видел сам алгоритм ADPCM? Аддаптивная Диференциальная Импульсно Кодовая модуляция.
Алгоритм подразумевает изменение шага квантования (шаг квантования "аддаптируется" под изменения волны), причем для предсказания следующего положения волны требуется умножать значение разности волн на величину шага.
Я знаю одного человека, великолепного программиста и разработчика алгоритмов, который написал свою, упрощенную реализацию ADPCM на 68K. Насколько помню, частота звука была 22 kHz. И это на 68K!

Мало того, что Z80 в два раза медленнее, так там еще нет операции умножения, а работа с 16-битными числами предоставляет некоторые трудности (в стандартной реализации 4-bit ADPCM все расчеты идут в 16-битных числах, разрядность выходного сигнала - тоже 16 бит). Это сложно, очень сложно. На гране возможного.

У меня есть мечта. Может когда-нибудь, я попробую реализовать ADPCM на Z80. Может быть, использование большего количества таблиц для промежуточных рассчетов поможет с этим. В любом случае, реализовать такой алгоритм на приемлимой частоте дискретизации, а я хочу более 8 kHz, очень сложно в поем представлении. Если кто-то написал реализацию ADPCM на Z80, то я снимаю перед ним шляпу - это действительно верх мастерства.

9

Ромхакинг и программирование / Re: Sega MD Sound (Yamaha 2612/PSG) - Что оно такое и с чем его едят

« : 18 Ноябрь 2012, 00:49:19 »

8бит 26кГц нежатый pcm это жирно слишком. да и где такой объем хранить ? карика не хватит же
в идеале нужно чтобы хватало 256б буфера, например пользовать 4бит ADPCM (или другое сжатие) и/или меньшую частоту.

В одном своем хаке я играл с Mega PCM целые песни, почти у всех частота была 22 kHz. Умудрился запихнуть пять штук (правда некоторые были коротки). Хотя песни занимали почти весь РОМ, качество на такой частоте было превосходное.

в идеале нужно чтобы хватало 256б буфера, например пользовать 4бит ADPCM (или другое сжатие) и/или меньшую частоту.

Буфер все равно же наполнять придется. Так что остановки в выводе звука неизбежны.

По времени выходит так: самый быстрый способ для загрузки буфера на Z80 - использовать LDIR, тогда на загрузку каждого байта уйдет 21 цикл + 16 циклов по окончанию переноса.
Получается 21*256+16 = 5392 цикла (не считая дополнительного кода на инициализацию регистров для LDIR, загрузку банка и т.д и т.п.)
По времени: 5392 / 3,58*10^6 = 0,0015 с, что составляет примерно 9% времени отображения одного NTSС-кадра (и это не считая времени задержки ответа 68k!). Дак тут все DMA в разы быстрее пройдут, чем наполнится буфер, а если вдруг наполнение буфера придется на работу DMA, время ожидания удвоится.

Чтобы воспроизводить PCM хотя бы на частоте ~15 kHz, неизбежно придется наполнять 256-байтный буфер каждый кадр. Учитывая вышесказанное, очень затратно получается.
Если использовать DPCM (не путать с ADPCM, этот алгоритм и 68K едва ли потянет), тут слегка получше: для той же частоты ~15 kHz придется наполнять буфер примерно раз в два кадра, но это тоже не очень-то выгодно выходит.

В общем, как ни крути - никакой выгоды в буферах в случае с воспроизведением DAC-сэмплов на Сеге нет.

vladikcomper, ты случайно не эмукодер?

Нет, но железо и некоторые нюансы знаю неплохо

10

Ромхакинг и программирование / Re: Sega MD Sound (Yamaha 2612/PSG) - Что оно такое и с чем его едят

« : 16 Ноябрь 2012, 17:56:47 »

а ты уверен в этом ? если мне не изменяет склероз, во время DMA Z80 вполне себе продолжает работать, разумеется в это время обращаться к области картриджа нельзя.

Да, во время DMA Z80 может спокойно работать, пока он не обратиться к РОМу.
Обращаться к РОМу можно, но как раз при этом Z80 останавливается вместе с 68K, пока DMA не будет завершен (только тогда 68K даст Z80 ответ).

В моем представлении, написать хороший DAC-драйвер, который бы не обращался постоянно к РОМу, нереально.
Когда-то я рассматривал идею использования буферов, но по моим прикидкам, это выходит нереально невыгодно.

Использование буферов требует намного больше ресурсов, как памяти Z80, так и времени на его наполнение. В случае с прямым чтением из РОМа надо просто прочитать, а в случае с буфером, нужно прочитать, сохранить, чтобы потом прочитать. Скажем, чтобы воспроизводить сэмпл на частоте дискретизации ~26 kHz, нужно за один кадр заносить в буфер примерно 433 байта. Такой объем памяти будет переноситься очень долго (к тому же речь идет о Z80 и его 8-битной шине), а это выливается в задержки в воспроизведении. Качество будет хуже некуда.

то есть если Z80 будет играть PCM из буфера в своей памяти (который периодически должен наполняться M68K) вывод звука будет постоянным и равномерным.

Наполнение со стороны 68K еще хуже. Замучаешься с синхронизацией. Z80 не может сгенерировать прерывание для 68K, чтобы пополнить буфер в нужный момент. Т.е. 68K понятия не имеет, когда наполнить буфер, и сколько z80 успеет проиграть за определенный интервал времени.

И Z80 все равно придется останавливать во время выполнения, а значит - от какой проблемы пытались уйти, к тому и придем.

и я кстати не уверен, что нормальные эмуляторы типа Regen или GenesisPlusGX не эмулируют это дело.

Да, эмуляторы остановку Z80 при DMA не эмулируют. В этом я сам убедился.
Я также сомневаюсь, что они эмулируют так называемый 'cycle stealing' между процессорами. Когда Z80 обращается к РОМу через шину 68K, он крадет у 68K по 4 цикла на каждый акт чтения или записи (да, Z80 может даже писать в 68K RAM, проверено на железе).

vladikcomper, твой драйвер что ли не только в Z80 работает? он ещё и жрёт постоянно такты M68k?

У меня лишь DAC-драйвер. Все, что он делает - проигрывает PCM-ки (но делает это он профессионально =Р).
В Соник 1 используется звуковой движок SMPS, и он работает на стороне 68K. Все такие движки состоят из двух частей: сам движок, обновляющий FM/PSG (со стороны 68k), и собственно DAC-драйвер (со стороны Z80). Mega PCM - это мой новый драйвер, который может заменить родной драйвер в Соник 1, чтобы расширить возможности и качество воспроизведения цифровых сэмплов в игре.

Да, когда звуковой движок работает на стороне 68k, это отнимает немного времени от работы движка самой игры. Но у них есть одно преимущество. Только с ними можно добиться максимально возможного качества воспроизведения DAC-сэмплов (что я и делаю =Р). Ведь Z80 может непрерывно выдавать звук, не отвлекаясь ни на что. А в движках полностью на Z80, Z80 должен отвлекаться на обновление FM/PSG.

11

Ромхакинг и программирование / Re: Sega MD Sound (Yamaha 2612/PSG) - Что оно такое и с чем его едят

« : 14 Ноябрь 2012, 19:35:06 »

Конечно были. Все выпущенные версии Mega PCM и дополнения к ним (в виде гидов для Соник 1) проверялись на реальном железе, и широкой общественности уже предоставлялся полностью работоспособный продукт, что было подтверждено экспериментально

К сожалению, у меня нет флэш катриджа, так что приходилось просить разных людей. В частности, я протестировал и это:
http://www.youtube.com/watch?v=LCDx7YUzFZ4

Человек, который для меня это протестировал, даже сделал запись звука с железа, так что я сам мог услышать, как оно в реале звучит. Оказалось довольно впечатляюще, но чуть хуже, чем в эмуляторах, потому что на реальном железе действуют многие факторы, которые удерживают работу Z80, а значит и вывод звука (например, Z80 останавливается, когда выполняется DMA, что не эмулируют эмуляторы. во всех деталях я это описал здесь: http://forum.sonic-world.ru/topic/20447-sonic-1-mega-pcm-driver/page__st__25#entry253074637)

Узреть, увы не получится. Запись ту я уже удалил, когда чистил файлы.
Добавлено позже:

Блин, с GEMS бы так (.

С GEMS такого точно не добиться, как и со всеми звуковыми движками, которые полностью работают на Z80. Они должны каждый кадр отвлекаться на обновление FM/PSG звука, так что непрерывно выводить DAC никак не получится. Задержки в выводе вызовут нехилое падения качества.

Например, звуковая волна была такой:

а из-за задержек вывода звука сильно искажается:

12

Ромхакинг и программирование / Re: Sega MD Sound (Yamaha 2612/PSG) - Что оно такое и с чем его едят

« : 10 Ноябрь 2012, 22:27:12 »

звук стерео не выдавить.

Можно. Разумеется, это не поддерживается на нативном уровне, а делается программным трюком (подобно тому, как можно растягивать слои по вертикали с помощью VDP-трюков).

Заключается трюк в следующем:
- Задаешь панорамирамирование на левое (B6 80)
- Посылаешь сэмпл в DAC, он, соотвественно, играет в левом динамике
- Задаешь панорамирование на правое (B6 40)
- Посылаешь сэмпл в DAC, и он заиграет в правом динамике

Способ довольно ресурсоемкий, и в плане обращений к YM, и в плане того, что стерео сэмплы весят в два раза больше.

Ато в сонике за него отвечает з80, а я в нём ничерта не сооброжу, как он звук выдаёт в йамаху.

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

В Соник 1 реализован наиболее простой Z80-драйвер. Если отбросить некоторые нюансы, драйвер управляется лишь одним байтом в памяти, и через него ему сообщают, какой сэмпл проиграть. В Sonic 1 очень немного DAC-сэмплов, причем они настолько малы, что целиком умешаются в памяти Z80 (в 8 килобайтах, включая размер кода самого драйвера).

В Соник 1 для сэмплов используется формат сжатия с потерями - 4 bit DPCM (Дифференциальная Импульсно-кодовая модуляция, где вместо абсолютных значений дается разность между предыдущим и новым положением волны, с использованием дельта-массива из 16 возможных значений разности). Такой же формат использовался во всех последующих Сониковских играх, включая 3Д Бласт.

Дизасембл драйвера можно скачать здесь: http://info.sonicretro.org/images/0/0a/S1_z80_dasm.7z

Еще, если тебя сильно интерисуют DAC-драйвера, советую посмотреть мою гордость: драйвер Mega PCM Он заточен под SMPS Соник 1, в замену его родного, не очень функционального драйвера, хотя драйвер может использоваться где угодно и для чего угодно.
Его особенности:

* Автоматическое переключение банков (благодаря чему драйвер может воспроизводить сэмплы любого размера, вплоть до 8 МБ, им даже можно играть песни)
* Поддержка двух звуковых форматов (8 bit PCM и 4 bit DPCM)
* Расширенное управление воспроизведением: Стоп, Пауза, Повтор, Приоритет
* Панорамирование звука (невероятно, но этого не было в родном драйвере Соник 1)
* (В SMPS Соник 1) До $5F слотов для сэмплов

Что самое невероятное, несмотря на перегруженность новыми функциями (ничего из вышеперечисленного не было в оригинальном драйвере), он умудуряется работать немного быстрее старого драйвера, потому что я оптимизировал все по максимуму. Более быстрая работа означает, что сэмплы можно играть на более высоких частотах (выше 27 кГц, старый драйвер играл примерно 23-24 кГц)

http://forum.sonic-world.ru/topic/20447-sonic-1-mega-pcm-driver/ - Драйвер с открытым исходным кодом.

13

Ромхакинг и программирование / Re: Gopher Mods - Моды игр для поддержки на Sega Gopher

« : 07 Июль 2012, 03:11:03 »

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

Делать это действительно необязательно.

Во время DMA процессор M68K останавливается и VDP захватывает его шину. Если в этот момент Z80 попытается получить доступ к шине 68K (прочитать что-нибудь из РОМа), он тоже остановится, ожидая шины. И так до конца DMA.

Вобщем, железо само справляется. А если останавливать Z80 принудительно, можно слегка потерять на производительности. Ведь не всегда же Z80 обращается к РОМу, так что он вполне может некоторое время успешно работать и когда M68K остановлен. Ну и если 68K будет заниматься остановкой/запуском Z80, он тоже потеряет пару циклов. Что интересно, эмуляторы не эмулируют остановку Z80 во время DMA. Так что на эмуляторах выгода колоссальная.

EDIT:
Кстати, если заменить DMA на обычный способ передачи данных (через VDP Data Port), Z80 вообще останавливаться не будет. Все это здорово улучшает качество цифровых сэмплов (DAC), если Z80 их воспроизводит (ведь если Z80 часто останавливается, звук становится "рваным", появляется шум), правда передача данных VDP будет идти в 2 раза медленнее.

14

Ромхакинг и программирование / Re: Ромхакинг. С чего начать ?

« : 06 Апрель 2012, 20:51:44 »

У меня есть вопрос: какой эмулятор имеет дебаггер? просто нужно разобраться, почему текст пропадает при его замене... из-за этого работа встала :'(

Какая консоль хотя бы?

15

Ромхакинг и программирование / Re: Sega MD VDP: Что оно такое и с чем его едят

« : 14 Февраль 2012, 20:00:17 »

Горизонтальные прерывания - вещь очень прихотливая, тут если не уследить за какой-то малейшей деталью или не учесть мелочь - все пойдет комом.

узнал только что если записать 8A20 то горизонтальное прерывание будет происходить всегда через каждые 32 строки ($20)

Все верно, регистр VDP $0A задает интервал в строках, через который нужно совершать горизонтальное прерывание.

В VDP есть внутренний счечик горизонтальных линий, который уменьшается на единицу с каждой отрисованной линией, и когда он достигает нуля, случается горизонтальное прерывание (если включено), а в счетчик загружается значение регистра $0A. Помимо этого, счетчик автоматически обновляется на линии 0 (начало кадра) и на линиях 225-261 (период VBlank'а). Последнее означает, что во время VBlank'а горизонтальные прерывания случатся не должны.

Важно отметить, что счетчик *не* обновляется как только в регистр $0A записывается новое значение. Он обновляется только при вышеописанных условиях. И это логично, иначе счетчик линий потерял бы привязку к началу рисования кадра.

Поскольку кадр состоит из 224 линий, если задать счетчику значение меньшее, чем 112, горизонтальное прерывание случится больше одного раза. Segaman, если у тебя оно случается по нескольку раз за кадр, это может объяснить мерцание, а может, это какой-нибудь баг в коде.

Если ты хочешь сделать прерывание только в одном месте, нужно позаботиться о том, чтобы после первого вызова, код прерывания в пределах одного кадра больше не выполнялся. Для этого можно сделать флаг в памяти и включать его в процедуре прерывания. И выходить из кода прерывания, если флаг включен. Потом, можно сбрасывать флаг в процедуре вертикального прерывания, чтобы к новому кадру он снова был чист. Также в коде горизонтального прерывания можно задавать регистру VDP $0A значение $DF, так, прерывание гарантированно случится не более двух раз (при следующем прерывании в счечик будет загружено значение $DF - 223 линии).

16

Ромхакинг и программирование / Re: Ваши хаки

« : 30 Январь 2012, 20:12:35 »

еще чек сумма вичисляется оригинальной консолью с биосом.
так что следите за чексуммой

Ты про TMSS?
Он ни коем образом не работает с чек суммой. Все, что он делает, проверяет записано ли слово 'SEGA' в адрес $A14000. Если при инициализации игра этого не сделала, она считается нелицензированной и TMSS отключает VDP.

17

Ромхакинг и программирование / Re: Ваши хаки

« : 30 Январь 2012, 16:19:42 »

Эмуляторам, в общем то, пофигу на контрольную сумму (на счёт родного железа - не уверен), но фиксить её - это что-то вроде хороших манер в ромхакинге

На самом деле контрольной суммы не касается ни железо, ни его эмуляторы.

Дело в том, что вся инициализация железа (подготовка памяти, VDP, Z80, PSG и стека) лежит на плечах самой игры. Поэтому в любом РОМе можно найти стандартный код инициализации, который абсолютно одинаков почти во всех играх.

Проверка контрольной суммы тоже выполняется самой игрой (железо не имеет к этому отношение). Эмуляторы только предлагают автоматически исправлять эту сумму, чтобы игра всегда считала, что она верная. Алгоритм вычисления чек сумм, опять же, одинаков во всех играх (в качестве исключения могу привести только порт Марио, в котором он отличается, и включение опции 'Auto-fix check sum' приводит к тому, что игра не работает).

На что влияет чек сумма? Зависит от игры, так как все в ее руках. Обычно, если чексума в заголовке не совпадает с настоящей, игры не запускаются или отображают красный экран (например, Соник 1 и 2). Я еще не видел, чтобы игра специально генерировала баги, если сумма неверна.

18

Ромхакинг и программирование / Re: Ваши хаки

« : 29 Январь 2012, 21:31:28 »

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

Для этого можно воспользоваться WinHex'ом например.
Открываешь в нем РОМ -> Ctrl + A -> Edit -> Modify Data -> 16-bit byte swap.
Разница между форматами SMD и GEN/BIN заключается лишь в том, что у них разных порядок байтов в слове.

Кстати, для SNES есть "корректный" эмулятор, который максимально приближен к работе натурального железа - BSNES, правда, он и самый тормознутый из эмуляторов

Для SMD таковым безусловно является Regen, и кстати, он далеко не тормознутый (проверено на старом ноуте).
Правда, 100%-ой точности никто не гарантирует, за долгое время работы с ним заметил я пару косяков, но это все мелочи. Вообще, все Сеговские эмуляторы на данный момент весьма поверхностно эмулируют доступ к SRAM и звуковые чипы. Эмуляция VDP кстати тоже отличается от железа, но тут учесть все детали просто невозможно.
Зато Реген один из немногих эмулирует Address Error и довольно точно эмулирует DMA.

19

Ромхакинг и программирование / Re: Sega MD VDP: Что оно такое и с чем его едят

« : 15 Декабрь 2011, 15:43:47 »

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

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

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

Без флага приоритета спрайт отображается поверх планов А и Б, и его могут перекрыть только тайлы планов А и Б с высоким приритетом. Вот как контроллер приоритетов VDP распределяет слои (приритеты даю по возврастанию):

1) Фоновый цвет
2) План Б с низким приоритетом
3) План А с низким приоритетом
4) Спрайты с низким приоритетом
5) План Б с высоким приоритетом
6) План А с высоким приоритетом
7) Спрайты с высоким приоритетом

Низкий приоритет - это когда у спрайта или тайла на плане бит приоритета равен 0, высокий - 1.

20

Ромхакинг и программирование / Re: Портирование игр с SegaMD/G на SegaCD/MegaCD

« : 08 Декабрь 2011, 22:28:20 »

такой вопрос. что делает команда stop?

Инструкция STOP приостанавливает процессор и ожидает прерывания. В качестве единственного операнда, насколько помню, принимает слово, которое запишется в статус регистр - SR. Это очень удобно, чтобы сразу задать маску перываний. Например stop $2300 приостоновит процессор, пока не случится прерывание выше третьего уровня (в этом случае доступны HInt - 4 уровень и VInt - 6 уровень).

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

К слову, про Sonic 1 with RA. Насколько помню, оборудование Sega CD инициализируется в режиме Mode 0 (хотя, могу ошибаться в цифре). В этом режиме код программы расположен на оффсетах $000000-$200000, занимая 2 Мб, т.е. внутри программы данные надо адресовать относительно нулевого оффсета, а не $200000, как это делают обычно. Не реальном железе программа запускается с картриджа и использует оборудование Mega CD, например диск, с которого играет музыка.

Не знаю, поможет ли это, просто сказал, что я по этому поводу знаю. Сам пока Сегой Сиди не занимался, хотя интерес есть. Думаю о том, как портировать свой Соник хак туда =Р Но не факт.

21

Ромхакинг и программирование / Re: Sega MD VDP: Что оно такое и с чем его едят

« : 30 Ноябрь 2011, 22:36:33 »

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

Спрайты в виде волн в Гидросити. И причем здесь мерцание пикселей? Мерцают спрайты.
Зато посмотри как интересно проходит линия воды в Angel Island Zone:

Я про этот уровень как раз и говорил. Здесь палитра меняется выборчно и в течении нескольких строк. Создается такой приятный эффект объемности. И только здесь, в AIZ2, в некоторых местах можно увидеть мерцающие пиксели, но они проходят через всю линию.

воще чтоб моск не парить не легче ли замутить DME переброс палитры?
так и быстрее. вдруг успеет?

Тоже задумывался, почему в Сониках перенос палитры во время прерывания не через DMA (насчет других игр не знаю). Думаю, дожна быть причина, Юджи Нака же крайне умный и умелый программист. Хотя, надо будет как-нибудь на досуге попробовать, заодно и проверить, как оно ведет себя на реальном железе.

22

Ромхакинг и программирование / Re: Sega MD VDP: Что оно такое и с чем его едят

« : 30 Ноябрь 2011, 14:40:18 »

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

HBlank, согласно внутренним счетчикам VDP, занимает столько времени, сколько нужно на отрисовку 2 пикслелей на экране. Согласно документации, это эквивалентно 36 циклам M68K. (Я это называю по памяти, так что могу немного наврать в цифрах).

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

В то же время, обработка самого прерывания тоже должна занять пару циклов процессора. Нужно сохранить в стеке значение PC (Program Counter - оффсет текущей инструкции), на котором произошло прерывание, а также значение SR (Status Register). Кстати, именно из-за того, что в стеке настраивается состояние SR, для возврата из прерывания нужна специальная инструкция RTE, а не обычный RTS.

Но вряд ли может случиться так, что все эти операции по времени займут больше, чем само прерывание. Вот тот эффект про который ты говоришь, ты заметил в Канслвании. Но видел ли ты его когда-нибудь в Сониках? Я не видел, если только мельком в Соник 3 (в AIZ 2).
Где-то на первой странице этого топика я высказывал мысль, что дело в медленном коде. Думаю, так и есть. Код прерывания не оптимален, понатыкан всякими бранчами, отнимающими время процессора, а может сам перенос цветов в CRAM сделан медленно (например, если перебрасывать по 2 байта, да еще и в цикле, потери времени будут огромны). Ну а если код еще написан на Си...
Вобщем, из-за всего этого палитра не успевает переброситься вовремя, и уже начинается отображение новой строки с еще старой палитрой.

23

Ромхакинг и программирование / Re: Портирование игр с SegaMD/G на SegaCD/MegaCD

« : 09 Ноябрь 2011, 22:50:27 »

http://forums.sonicretro.org/index.php?showtopic=26532 - неплохой шаблон и стартовая площадка.

MegamixCdSource непомню где взял, но собранный ром дальше текстовой заставки неидет. фиксить чота надо.

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

24

Ромхакинг и программирование / Re: как перегнать игру с картриджа на персональный компьютер?

« : 10 Октябрь 2011, 11:35:19 »

За тебя уже перегоняли. Помню, что видел похожий РОМ, попробуй поискать еще, может быть, лучше искать по запросу 9999, а не Супер Марио. Кстати, здесь не так давно в каком-то топике это обсуждалось.

Что до самого "перегона", тебе понадобится специальное оборудование, вряд ли все это просто достать. Впрочем, я сам никогда этим не занимался и имею об этом лишь поверхностное представление, так что сказать тут ничего не могу.

25

Дайджест / Re: Порт Sonic CD подтвержден

« : 30 Август 2011, 12:32:53 »

Удивительно вдвойне, я бы сказал - этот порт ещё два года назад мог выйти на айфоны, был трейлер на ютубе, который потом SEGA закрыла.

Это был порт самого The Taxman'а, с которого все началось. Почти забыл как все было.
Разумеется, СЕГА его дело прикрыла, так как игра оказалась весьма актуальной и выгодной, а Taxman мог бы получить деньги с их маскота.
Но хорошо, что все так великолепно закончилось - и Сега, и Taxman остались в выигрыше, причем двойном.

26

Дайджест / Re: Порт Sonic CD подтвержден

« : 27 Август 2011, 14:20:11 »

А я думал они банально собрались засунуть игру в эмулятор с фильтрацией.

Добавлено позже:
Посмотрел видео: и где же улучшения? Абсолютно то же самое, или переносят на новый движок только чтобы он отрисовывал картинку в разрешении повыше?

Улучшения? Игра теперь в широкоформатном разрешении, и это видно на видео.
Также обещают систему достижений, Спин Дэш в стиле Соник 2 (под вопросом) и повторяющуюся музыку (в оригинальной игре треки воспроизводились банально от начала до конца, а потом повторялись после задержки).

P.S А что значит Past/Future в Sonic CD, игру проходил много раз, но так и не понял их назначение 

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

27

Дайджест / Re: Порт Sonic CD подтвержден

« : 27 Август 2011, 12:44:50 »

Этот порт в отличие от других бесчисленных кривых и не очень портов Соник Тим крайне интересен и вообще уникален.

Дело в том, что Sonic Team делает этот порт на фанатском движке под названием "Retro Sonic". (http://www.sonicretro.org/2011/08/sonic-cd-can-do-anything-to-several-platforms-first-trailer/). Автор движка, The Taxman активно принимает участие в разработке вместе с самой Sonic Team, и даже раскрыл пару нововведений.

Фанатский движок оказался лучше и унверсальнее многих наработок Соник Тим. И это удивительный случай в истории, что компания выкупила работу фанатов. Я уверен, что Taxman сделает все как надо, и даже лучше.

28

Ромхакинг и программирование / Re: [SMD] Sonic 3 in 1

« : 26 Август 2011, 19:01:33 »

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

Я почти уверен, что все из-за настроек SRAM.
При тестировании Tiddles говорил о проблеммах со SRAM, потом я вроде бы убрал их, пофиксив заголовок РОМа, и Соник 3 вроде бы запускался (с флэшкартриджа).
Только что посмотрел на заголовок и с ужасом узнал, что настроил SRAM на адреса $200001-$2003FF. Именно такие адреса использовались в Sonic 3, но в моем случае эти же адреса используются самим РОМом, ведь он больше двух метров. Наверное, игра пытается записать что-то в SRAM, и процессор крашится. Забавно, что это работает во всех эмуляторах.

29

Ромхакинг и программирование / Re: Sega MD VDP: Что оно такое и с чем его едят

« : 27 Июль 2011, 23:00:32 »

а на гофере дма шрифт жует

Ты про Соник 3 в 1? Где именно шрифты жуются?

А как мне кажется  должно работать и move.l d7,(a0) , то есть условие что содержимое должно находится в ram или в регистре. 
(баг то по логике происходит, потому что если что-то типа move.l #$12345678,(a0) , а команда эта и число 12345678, это находится в ром, и из ром же должна передача пойти,только с другого адреса)

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

30

Ромхакинг и программирование / Re: [SMD] Sonic 3 in 1

« : 27 Июль 2011, 22:56:47 »

Что-то плохо тестили. Щас тока на суслике завис во 2м акте ангельского острова.
Лучшеб в обычный играл. Так разыгрался хорошо. Досихпор музыка играет

На Гофере Nemesis_с тестил в основном само меню и его части, ну и запускаемость игр, как я и просил. В играх абсолютно нет изменений, менющих логику кода или компоненты движка, а Соник 3 так вообще почти не изменился. Однако я слышал и о загадочных багах в Соник 2, которые были в каких-то старых левых эмуляторах, а теперь о проблемах с Соник 3. Перед выпуском следующей версии, я постраюсь отследить возможные баги, в том числе на Гофере. Не знаю точно, но это очень похоже на ошибки аппаратуры, а не критические ошибки в самой игре. Гофер ведь кривой, это факт.