Проигрыватель прохождения записей игр на реальной Dendy

[Tronix]

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

Пошло еще со времен, когда всяких ютюбов еще не было, а посмотреть прохождение той или иной игры было интересно. И вот я подумал сделать проигрыватель данных файлов в реальный NES, пускай чертова железяка работает :biggrin:

Немного загуглив, я узнал, что идея мне не первому в голову пришла. Например, есть некий PC NES transfer cable (http://nesdev.com/lptnes_v130.zip) v1.30 by sepi. Представляет из себя кабель LPT->джойстик с парой микросхем логики, позволяет вроде проигрывать файлы от Nestopia и играть просто с клавиатуры компа. Минусы: а) LPT б) софт под MS-DOS в) сорцов софта нет.

Поэтому гуглим дальше техническую сторону вопроса:
Во первых форматов много, но есть софтина, позволяющая конвертировать из одного формата в другой. Зовется nesmock (http://bisqwit.iki.fi/source/nesmock.html) . GPL, сорцы доступны. Пригодится в будущем.

Дальше самый имхо простой формат fm2 (http://www.fceux.com/web/FM2.html) от эмулятора FCEUX Представляет по сути текстовый файл (хотя может быть и бинарным), где по-фреймово записываются нажатые кнопки. Например,

|0|R.....B.|........||
|0|R.....BA|........||

Первый фрейм - нажаты Right и кнопка B. Второй фрейм - нажаты Right, B, A. и тд. Вроде просто все.

Аппаратно - маленький PIC с прикрученной SD-картой, торчащий в разъеме джойстика. Так мне видится...

[Eltaron]

Но как синхронизировать фреймы? Скажем, при записи START был нажат в 982й фрейм от рождества Христова от сброса. Как нажать его в тот же 982й при воспроизведении? Одним эмулятора джойстика не обойтись, как мне кажется.
А попасть нужно именно точно, иначе могут поплыть всякие привязанные ко времени вещи, самое неприятное - генераторы псевдослучайных чисел.

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

[Tronix]

Но как синхронизировать фреймы? Скажем, при записи START был нажат в 982й фрейм от рождества Христова от сброса. Как нажать его в тот же 982й при воспроизведении?

Ну во-первых, на разъеме джойстика есть питание +5V, таким образом включать девайсину можно одновременно с включением дендика. Дальше, запускается игра с катриджа, показывает заставку, где потом нужно, как правило, нажать СТАРТ. До этого никакие кнопки на гейпаде не нажимаются, и в файле-записи идут пустые фреймы. Пускай СТАРТ будет нажат немного позже, чем он был нажат игроком записывающем прохождение, ну допустим на 2-3 секунды. Но когда он (старт) будет нажат - от этого времени пойдет точный синхрон.

Тут другое меня волнует - чтение с SD-карты небольших блоков (128 или 256 байт, допустим) будет жрать приличное время на простом контроллере. Как бы в это время не получилось простоя в выдачи очередного байта в NES. Хорошо было бы считать весь файл сразу в память, но тогда нужна внешняя память...

[Titus]

И вот я подумал сделать проигрыватель данных файлов в реальный NES, пускай чертова железяка работает :biggrin:

Непросто это будет реализовать.

1) В эмуляторах новая информация от джойстиков приходит один раз за фрейм в строго определенное время, а на реальной Денди - в произвольное время.

2) В играх могут использоваться различные генераторы случайных чисел, зависящие в том числе от растактовки конкретного железа.

3) Если эмулятор не 100% точен по тактам процессора и всей остальной периферии, то записанное на нем видео так же разьедется на реальном железе.

[Ramiros]

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

[HardWareMan]

Все эти проблемы уже обсуждались много раз. Нет никакой информации о сбросе. Нет никакой информации фазе PPU. Напомню, что из-за разницы в тактовых частотах, алигнмент CPU к PPU имеет 4 фазы. Нет никакой информации о фрейме (не все игры сканируют джой по VBlank'у). Самый точный вариант - это в гнезде картриджа, но никак не в гнезде джойстика.

[Tronix]

Но ведь latch и clock выдает сама денди, по нему и отдавать данные. Можно например с помощью аппаратного SPI Slave, как мне видится. Интервалы подогнать опытным путем.... Я думаю все-же попробовать, чего я теряю...
Вот только с чтением с SD-карты не могу придумать, ведь будет тормозить в момент чтения блоков. Либо внешнюю память прикручивать, либо взять какой нить жирный NXP LCP1768 со встроенной SRAM дофига. Но это уже из пушки по воробьям.

[vfiuchcikicshuusrch]

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

[HardWareMan]

И latch и clock это программно генерируемые сигналы, являющиеся битами в портах $4016/$4017
http://savepic.org/6501366.png

[Ramiros]

В чем проблема? по Latch читаем новое значение из памяти/файла, по Clock выдаем дендику.

[vfiuchcikicshuusrch]

2HWM,
самое важное слово *программно*

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

по факту клок разный, в разные моменты игры.. всё зависит от софта. какой задается... такой и используется.

вообще.. если привязываться изначально к latch и clock при записи демок, то тогда всё ок было бы))..

---------- Post added at 12:16 ---------- Previous post was at 12:14 ----------

Ramiros, количество пропущенных latch указано в файле демок ?)
вообще он вроде 60/50 гц всегда должен быть для нтсц/пал версии соответственно, но это только по документам.

[Tronix]

Хм... Ну разный и разный, главное что он есть. Ждем latch, потом по фронту клока выдаем бит, ждем второй смены импульса клока - выдаем бит и тд. Не знаю, как смотрит на переменный клок аппаратный SPI (SPP) Slave у микроконтроллеров, но если плохо смотрит - можно и в ручную дергать ногами, благо скорости медленные.

[Ramiros]

[/COLOR]Ramiros, количество пропущенных latch указано в файле демок ?)
вообще он вроде 60/50 гц всегда должен быть для нтсц/пал версии соответственно, но это только по документам.

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

[vfiuchcikicshuusrch]

Ramiros, но latch на сколько я смог увидеть )) может возникнуть и раньше чем 50гц.
я о том что нет синхры как таковой. это просто сигнал защелки для джоя. сигнал о том чтобы взять с него бит данных.
поэтому не получается упростить *протокол* передачи данных до 3х проводков = земля, + , дата. потому как дендик не примет их когда джой будет передавать... %)
п.с. сорри что я немного о своём... )) но тут сложно взять просто так и сделать. мне тоже интересно и хочется понять:)

а почему не сделать через разъем карика ?. понимаю что будет неочень удобно. но главное ведь результат :)

[Ramiros]

чтоб все работало как надо, важно чтоб эмулятор NESа, с которого файл записывался тоже Latch использовал для отсчета моментов записи данных. если там будет другой принцип, то ессественно работать нифига не будет. Но я думаю что там как раз Latch и используется, иначе же и нелогично, ну покрайней мере если бы я эмуль NESа писал, я бы так делал :)

[vfiuchcikicshuusrch]

Ramiros, воооот ) и я о том же :)

[Ramiros]

vfiuchcikicshuusrch, Latch это сигнал записи состояния всех 8 кнопок в регистр джоя, а дальше идет пачка (обычно 8) Clock-ов чтобы перегнать все эти данные из джоя в дендик.
Понятно что раз эти сигналы формируются програмно, то они могут возникать в любой момент времени, но обычно чтение джоев всетаки вешают на прерывание.

РS: Еще пачка clock-ов идет обычно в рамках одного прерывания (читай - одной процедуры), так что там скорость весьма приличная, у меня в отремонтированом джое не каждая к555ир9 успевала, и в некоторых играх кнопки неверно опрашивались.

[vfiuchcikicshuusrch]

Ramiros, ну потому что по документации в сети.. пишут задержки импульсов и их длины одни, а по факту они раза в 2 быстрее могут быть..)

опять же , если делать устройство завязанное на кнопки и чтобы консоль понимала их правильно, нужно полюбому использовать LATCH и CLOCK. по сигналу latch идет синхронизация начала опроса. а клок нужен микрухе джоя (4021) для того чтобы биты данных (8штук = a,b,select,start и четыре направления) выходящих последовательно в сигнал DATA были ровно в clock. ну кароче это всё ясно в инете есть картинки, единственное что нужно учитывать, что к обоим сигналам нужно привязываться.

1. получили сигнал Latch.
2. начинаем получать сигнал CLOCK
3. синхронизируясь по clock (т.е. с такой же длинной импульсов и частотой) нужно выдать байт данных. те самые 8 кнопок..

сложность в том что оно блин не одинаковое нифига =\

п.с. может это только для клонов ?!... в оригинальной NES такое наблюдается ? это же может быть изза рассинхронизации цпу и ппу ?

[Ramiros]

Думаю что для NES все так же. на денди во многих играх я замечаю подтормаживание, когда основной цикл в игре неуспевает между прерываниями завершится и приходится ждать следующего кадра, но это возможно связано с тем, что у дендика кол-во операций CPU между прерываниями немного меньше чем у NES, соответственно те же игры на NES могут и не тормозить, или тормозить но меньше. Отсюда может быть и нестабильность Latch и Clock.
Еще на картриджах типа 100500 in 1 в меню я замечал хитрый опрос джоя, там в место 8 клоков было только 4 или 5, точно не помню :)

[vfiuchcikicshuusrch]

Ramiros, вот это и нужно учитывать ТС. ведь всё это дело на портах джоев.. именно программное.

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

кстати clock у второго джоя не такой как у первого. это я вчера и осциллографом посмотрел, и сейчас на схеме увидел, что сигнал там clk2

интересно ...
смотрел игру RC PRO AM2 .. игра подразумевает поддержку 4х джоев.
сигнал Latch потом clock потом снова (сразу же) latch и снова clock.
т.е. опрос джоя 2 раза друг за другом происходит в игре.
опять же , если читать инет и верить тому что там написано.. потом можно очень сильно обломаться. ибо тут уже latch не особо в 50/60 гц укладывается. (т.е. он то укладывается, но потом ещё раз укладывается)))))

[Titus]

Подумал я внимательнее и понял, что ваша идея полная утопия. Позже напишу почему.

[vfiuchcikicshuusrch]

Titus, и, более того, я с тобой соглашусь заранее.

сама задумка хороша. но для неё нужно писать софт для записи демок. имхо. тогда ещё возможно прокатит! :)

[Eltaron]

сама задумка хороша. но для неё нужно писать софт для записи демок. имхо. тогда ещё возможно прокатит! :)
Софт же даже есть. Просто тот текстовый формат из первого сообщения не подходит. Точнее, подходит - но для игр, которые не содержат ничего случайного и проходятся с закрытыми глазами. Типа Super Mario.

Но наверняка же есть форматы, устроенные как rzx - где сохраняются все результаты чтений из портов, независимо от того, было что-то нажато или нет. Ну, без доступа к адресной шине потребуется ещё указание номера порта, из которого было чтение. Тогда вполне можно сделать выталкиватель очередного байта по Latch/Pulse.

И в N-ное чтение порта (считая от ресета) мы получим именно N-ное значение состояния джойстика.

[vfiuchcikicshuusrch]

всё это понятно.

есть у кого-нибудь конкретные идеи и механизмы реализации данного чуда ? :)

[HardWareMan]

Если бы вы читали информацию, то поняли, что формат записашек - 1 состояние джоя на 1 кадр. Счет от сброса. Т.е. 10 чтений в пределах 1 кадра дают одно и то же значение. Однако, если это легко повторить на эмуляторе то практически невозможно повторить на железе. Самый главный сигнал - разделитель кадра, можно точно вычленить только из видеосигнала, ибо даже NMI управляется программно и может быть выключен игрой ради смеха. И тогда вся ваша затея накрывается медным тазом. Далее, каждая записашка конкретно подогнана под конкретный ROM и конкретный эмулятор. Касаемо Luck Control то тут в железе вообще ловить нечего, ибо невозможно предустановить значения аппаратуры перед игрой не промодифицировав ее, а это уже нарушение синхронизации.

[Tronix]

Понятно, но попробовать хочется...

В целом, о проигрывании файлов на реальном железе: http://tasvideos.org/ConsoleVerificationGuide.html Ссылки на файлы-записи, которые проверены на реальном железе (правда тут речь везде о оригинальном NES): http://tasvideos.org/ConsoleVerifiedMovies.html

Ссылки оттуда:
Проигрыватель на андурино с SD-карты: http://www.instructables.com/id/NESBot-Arduino-Powered-Robot-beating-Super-Mario-/

Готовый убер-девайс на PIC32: http://truecontrol.org/

[Titus]

Подумал я внимательнее и понял, что ваша идея полная утопия. Позже напишу почему.

Теперь подробнее)

Если дамп данных записан с эмулятора системы, имеющего расхождение хотя бы на такт, относительно вашего железа, потенциальные глюки обеспечены, и вот почему. Вышеприведенные доводы про то, что можно записать дамп данных джойстика хоть на 60Гц машине, а проигрывать на 50Гц, ввиду того, что обновление геймплея синхронно с кадровой разверткой - НЕ ВЕРНО. Помимо синхронного режима работы игры (когда обновление геймплея происходит синхронно с кадрами) есть и несинхронные участки (подготовка данных, инициализация и т.д.). Мало того, даже в синхронных участках далеко не во всех играх так гладко. Многие игры в некоторых ситуациях банально не успевают все просчитать и обновить за кадр, и переодически подтормаживают. Яркий пример - Contra Force.
Таким образом, чтобы быть гарантированно уверенными, что записанный сценарий проиграется как надо, эмулятор, на котором записано, должен В ТОЧНОСТИ эмулировать вашу хардварную систему. Причем все нюансы, такт в такт.
А наша отечественная Dendy - это вообще по растактовке смесь хорька, барсука и штопора. Процессор, грубо говоря, от NTSC версии, а видеочип от PAL.
Т.е. вам надо взять абсолютно точный по тактам эмулятор, настроить его на наш российский клон Dendy, поиграть в игры, получить дампы. И уже потом может быть удастся это воспроизвести на реальном железе.
Но какой смысл в этом, если реальное железо при таком раскладе должно в точности повторять эмулятор? Значит эмулятор ни чуть не хуже этого самого железа, если работают они один в один. А если не один в один, то смотри начало данной статьи)

[piroxilin]

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