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

[vfiuchcikicshuusrch]

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

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

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

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

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

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

[Advertiser]

[Ramiros]

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

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

[Tronix]

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

[vfiuchcikicshuusrch]

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

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

[Ramiros]

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

[vfiuchcikicshuusrch]

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

[Titus]

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

[Titus]

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

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

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

[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 такое наблюдается ? это же может быть изза рассинхронизации цпу и ппу ?