Подумал я внимательнее и понял, что ваша идея полная утопия. Позже напишу почему.
Вид для печати
Подумал я внимательнее и понял, что ваша идея полная утопия. Позже напишу почему.
Titus, и, более того, я с тобой соглашусь заранее.
сама задумка хороша. но для неё нужно писать софт для записи демок. имхо. тогда ещё возможно прокатит! :)
Софт же даже есть. Просто тот текстовый формат из первого сообщения не подходит. Точнее, подходит - но для игр, которые не содержат ничего случайного и проходятся с закрытыми глазами. Типа Super Mario.
Но наверняка же есть форматы, устроенные как rzx - где сохраняются все результаты чтений из портов, независимо от того, было что-то нажато или нет. Ну, без доступа к адресной шине потребуется ещё указание номера порта, из которого было чтение. Тогда вполне можно сделать выталкиватель очередного байта по Latch/Pulse.
И в N-ное чтение порта (считая от ресета) мы получим именно N-ное значение состояния джойстика.
всё это понятно.
есть у кого-нибудь конкретные идеи и механизмы реализации данного чуда ? :)
Если бы вы читали информацию, то поняли, что формат записашек - 1 состояние джоя на 1 кадр. Счет от сброса. Т.е. 10 чтений в пределах 1 кадра дают одно и то же значение. Однако, если это легко повторить на эмуляторе то практически невозможно повторить на железе. Самый главный сигнал - разделитель кадра, можно точно вычленить только из видеосигнала, ибо даже NMI управляется программно и может быть выключен игрой ради смеха. И тогда вся ваша затея накрывается медным тазом. Далее, каждая записашка конкретно подогнана под конкретный ROM и конкретный эмулятор. Касаемо Luck Control то тут в железе вообще ловить нечего, ибо невозможно предустановить значения аппаратуры перед игрой не промодифицировав ее, а это уже нарушение синхронизации.
Понятно, но попробовать хочется...
В целом, о проигрывании файлов на реальном железе: http://tasvideos.org/ConsoleVerificationGuide.html Ссылки на файлы-записи, которые проверены на реальном железе (правда тут речь везде о оригинальном NES): http://tasvideos.org/ConsoleVerifiedMovies.html
Ссылки оттуда:
Проигрыватель на андурино с SD-карты: http://www.instructables.com/id/NESB...-Super-Mario-/
Готовый убер-девайс на PIC32: http://truecontrol.org/
Теперь подробнее)
Если дамп данных записан с эмулятора системы, имеющего расхождение хотя бы на такт, относительно вашего железа, потенциальные глюки обеспечены, и вот почему. Вышеприведенные доводы про то, что можно записать дамп данных джойстика хоть на 60Гц машине, а проигрывать на 50Гц, ввиду того, что обновление геймплея синхронно с кадровой разверткой - НЕ ВЕРНО. Помимо синхронного режима работы игры (когда обновление геймплея происходит синхронно с кадрами) есть и несинхронные участки (подготовка данных, инициализация и т.д.). Мало того, даже в синхронных участках далеко не во всех играх так гладко. Многие игры в некоторых ситуациях банально не успевают все просчитать и обновить за кадр, и переодически подтормаживают. Яркий пример - Contra Force.
Таким образом, чтобы быть гарантированно уверенными, что записанный сценарий проиграется как надо, эмулятор, на котором записано, должен В ТОЧНОСТИ эмулировать вашу хардварную систему. Причем все нюансы, такт в такт.
А наша отечественная Dendy - это вообще по растактовке смесь хорька, барсука и штопора. Процессор, грубо говоря, от NTSC версии, а видеочип от PAL.
Т.е. вам надо взять абсолютно точный по тактам эмулятор, настроить его на наш российский клон Dendy, поиграть в игры, получить дампы. И уже потом может быть удастся это воспроизвести на реальном железе.
Но какой смысл в этом, если реальное железо при таком раскладе должно в точности повторять эмулятор? Значит эмулятор ни чуть не хуже этого самого железа, если работают они один в один. А если не один в один, то смотри начало данной статьи)
Ну вот по ссылкам с ТАС-видео у них что-то да работает (отдел проверенные на железе прохождения).
Сбивается градиус (на вулкане) , но многое работает (маревы, даблдрагоны) как задумано.
Девайс не панацея, но имеет право на жизнь , кмк... :)