а там разве вот прям код анализируется? а не (например) юла морозится до фронта
Вид для печати
скорее всего оцифровка делалась в автоРежиме.
если перегнать в wav и `правильно` оцифровать - заработает.
https://pic.maxiol.com/thumbs2/17333...48183.mtzx.png
посмотрел логику, дисплей проверяется по завершению перетаскивания окна, если дисплей на котором отображается окно изменился, то Direct3D девайс освобождается и создается заново для нового дисплея. HWND окна используется вроде тот-же, могу ошибаться но не увидел, чтобы окно пересоздавалось. На этапе отладки помню у меня были разные варианты, по результатам тестов остановился на таком. Он для всех случаев корректно работал, в том числе и с подключением новых дисплеев и перетаскиванием окна эмулятора на него.
- - - Добавлено - - -
не знаю, я ускорение загрузки edge load не делал, смысл его в том, что эмулятор видит где короткий импульс, где длинный - так libspectrum помечает флагом. Насколько понимаю эмуляторы анализируют эмулируемый код и пропускают эмуляцию сразу перескакивая на новый адрес в зависимости от того какой импульс на входе - длинный или короткий. Видимо, если код более сложный и может проверять больше чем две длительности импульсов, то указанные эмуляторы дают неправильную эмуляию, т.к. не могут корректно обработать такой код.
Грубо говоря это попытка не эмулировать кусок кода, а сразу подставить готовые результаты. Но проблема в том, что корректно проанализировать загрузчик на лету довольно проблематично, не потеряв в скорости и корректно обработав все возможные варианты загрузчиков.
Я даже не стал смотреть как это делается, т.к. тот-же fuse при загрузке с кассеты дико тормозит на медленных компьютерах, таких как raspberry pi. А я именно под raspberry pi и затачиваю zxmak2.
PS: посмотрел код fuse, да - там длинный свитч проверяющий текущую инструкцию и считающий что код загрузчика всегда одинаков и только такой как заложен в эмулятор, там в коде эмулятора захардкожено назначение регистров и битов в регистрах для загрузчика, поэтому такая акселерация загрузки не будет корректно работать для нестандартных загрузчиков.
нет, эмулятор сразу модифицирует регистры процессора:
причем, как видно назначение регистров и логика загрузчика захардкожена в эмуляторе, если загрузчик использует регистры по другому, то такая симуляция будет неправильной.Код:static void
do_acceleration( void )
{
if( length_known1 ) {
/* B is used to indicate the length of the pulses */
int set_b_high = length_long1;
set_b_high ^= ( acceleration_mode == ACCELERATION_MODE_DECREASING );
if( set_b_high ) {
z80.bc.b.h = 0xfe;
} else {
z80.bc.b.h = 0x00;
}
/* Bit 5 of C is used to indicate the current microphone level */
z80.bc.b.l = (z80.bc.b.l & ~0x20) | (tape_microphone ? 0x00 : 0x20);
z80.af.b.l |= 0x01;
/* Simulate the RET at the end of the edge-finding loop */
z80.pc.b.l = readbyte_internal( z80.sp.w ); z80.sp.w++;
z80.pc.b.h = readbyte_internal( z80.sp.w ); z80.sp.w++;
event_remove_type( tape_edge_event );
tape_next_edge( tstates, 1 );
successive_reads = 0;
}
length_known1 = length_known2;
length_long1 = length_long2;
}
Мне такой подход не нравится, поэтому я такой акселератор загрузки не стал добавлять, хотя флаги LENGTH_SHORT и LENGTH_LONG прикрутил, на случай если захочется поэкспериментировать.
в смысле "перегнать" - какой, неисправленный?
так он же воспроизведётся неправильно))
а исправленный уже нет смысла перегонять
в zxspin, наверно, что-то сложнее, потому что для него я затрудняюсь сходу назвать загрузчик, который НЕ сработает с edgeload
с виду-то похоже (турба и для ленты, и для проца) - полосы на бордере ужимаются
но для некорректного тызыкса не должно быть разницы в таком случае - а он грузится
если поставить цель обмануть захардкоженую в эмуляторе логику для загрузчиков, то я думаю не проблема сделать загрузчик, который не будет работать ни в zxspin, ни в каком другом эмуляторе использующем edge load акселерацию. Т.к. невозможно захардкодить в эмуляторе поддержку всех возможных загрузчиков, а код с таким анализом будет сильно тормозить.
- - - Добавлено - - -
потому что edge load - это не загрузка, это обман загрузчика эмулятором, с подсовыванием ему готовых данных напрямую вместо реальной эмуляции. Анализ длительности импульса при этом не производится, поэтому даже если импульсы некорректные и сигнал никогда не сможет быть загружен реальным спектрумом, загрузка в таком эмуляторе всегда будет "успешной". Эмуляции загрузки при этом по сути не происходит, просто данные из tzx напрямую записываются в память спектрума, счетчик в регистрах подкручивается чтобы загрузчик думал что загрузка произошла.
PS: Кстати, в этом очевидно и кроется ответ, как такой битый TZX появился. Ктото протестил в эмуляторе с edge load что программа "грузится" и выложил TZX, а на самом деле TZX битый, в нём потеряна реальная длительность импульсов, он не будет грузиться на реальном спектруме.
И восстановить длительность импульсов будет проблематично. В данном случае я просто взял TZX с другим релизом этой программы и посмотрел в ней длитетльность импульсов, но если бы смотреть было некуда, то пришлось бы анализировать код загрузчика и подбирать опытным путём чтобы сделать такой TZX загружаемым.
И наверняка таких битых TZX немало, благодаря этой edge load акселерации...
не поможет. В этом TZX указаны стандартные длительности импульсов. Вот фрагмент из asm файла сформированного дампером:
а должны быть укороченные:Код:#code BLOCK7_DATA, 0, *, flag=$ff, pause=0
.tzx-pilot-sym 0, 2168 ; symbol#0 for pilot pulses
.tzx-pilot-sym 0, 667,735 ; symbol#1 for sync pulses
.tzx-pilot 0,3220 , 1,1 ; 3220 pilot pulses (symbol#0), then one sync pulse symbol (symbol#1)
.tzx-data-sym 0, 855,855 ; symbol#0 for bit 0
.tzx-data-sym 0, 1710,1710 ; symbol#1 for bit 1
Сравните длительность импульсов 855 и 1710 тактов против 615 и 1230 тактов в оригинале.Код:#code BLOCK7_DATA, 0, *, flag=$ff, pause=0
.tzx-pilot-sym 0, 2165 ; symbol#0 for pilot pulses
.tzx-pilot-sym 0, 714,714 ; symbol#1 for sync pulses
.tzx-pilot 0,3261 , 1,1 ; 3261 pilot pulses (symbol#0), then one sync pulse symbol (symbol#1)
.tzx-data-sym 0, 615,615 ; symbol#0 for bit 0
.tzx-data-sym 0, 1230,1230 ; symbol#1 for bit 1
Синхроимпульс тоже неправильный - 667,735 вместо 714,714 в оригинале.
Очевидно ошибку не заметили из-за того, что для теста загрузили файл в эмуляторе с edge-load, который из-за ошибки загрузил его как корректный. На самом деле в нем отсутствует важная информация о длительности импульсов и восстановить ее было бы довольно сложно, если бы не было аналогичного рабочего релиза. Т.е. загрузить на реальном спектруме было бы невозможно, только в эмуляторе с загрузкой edge-load, которая игнорирует длительность импулсов и пишет данные сразу в регистры процессора подменяя счетчик.
ага, понял.
действительно (сразу не заметил) проверял с включённым EdgeLoad.
причём грузит только в модели48к
Хмм, я тоже думал что во fuse просто происходит детект фазы загрузки и включается макс.ускорение (отключена эмуляция всякого ненужного).
Еще один битый tzx из той-же серии - с неправильными длительностями импульсов, который грузится из-за ошибки с edge-load:
https://worldofspectrum.net/item/0001837/
https://worldofspectrum.net/pub/sinc...Planet.tzx.zip
там-же лежит и рабочий вариант с турбоблоком вместо обычного:
https://worldofspectrum.net/pub/sinc...anetV1.tzx.zip
в zxmak2 загружать с отключенным автостартом, т.к. лоадер капризен ко времени и приводит к ложному срабатыванию.
ZXMAK, а от зловредных тызыксов защитился? ну, таких, где переходы зациклились без появления в процессе звуковых блоков
ZXMAK, а что ты такого с MASK намутил, что даже исправленная (добавлением блоков 2B куда нужно) не работает?
и еще вопрос, частота сэмплов ленты у тебя потактовая или меньше?
а то есть, например, схема Digital Integration с порченными таймингами
которая честно вроде не должна бы загружаться, однако грузится
для загрузки Mask нужно отключать автоплей, т.к. он может останавливать магнитофон в паузах, что нарушает тайминги сигнала.
А куда там 2B нужно добавлять? У меня TZX только те что гуглом гуглятся - нерабочие. Нормально грузится только из WAV образа.
- - - Добавлено - - -
Загрузка привязана к тактам процессора. При загрузке TZX и других образов, во избежание конфликтов, тайминги не привязанные к тактам пересчитываются в такты исходя из фиксированной тактовой 3.5 МГц, независимо от фактической тактовой. Т.е. для загрузчика сигнал по тактам будет одинаковым, независимо от фактической частоты Z80.
а что за образ?
перед каждым турбоблоком #11 - высокий уровень
автоплей был выключен
нифига не понял, проще скажи - сколько тактов Z80 на сэмпл у тебя?
вот если спеку скормить оцифровку 44100 - будет 79 тактов на сэмпл
пробую сейчас процедурку с точностью один такт на сэмпл
но вот что-то грузит она не всё, вот например три файла
который блоками #19 с красивыми цифрами импульсов - грузится
такие цифры, похоже, восстановлены анализом кода загрузчика
(так как в тызыксе другой игры той же фирмы - ATF - такие же)
8191 x 1180
256 x 2168
1 x 1000
а который то же самое через #12-#13-#14 - пилот не видит
и времянки явно кривые, разные даже между собой
8190 x 1144 / 1144
256 x 2102 / 2098
1 x 805 / 725 (!)
импульсы данных тоже разные и некруглые, но это оказалось некритично
в архиве три версии (нужен переход в 48k):
general - всё норм
puretone - всё плохо
puretone - исправлены тайминги пилотона - после чего стало загружаться
еще пробовал плохие прописать в хороший #19 - перестал грузить
вот сижу и думаю - может, тайминги старых тызыксов замерялись/подбирались неточно
и проверялись в старых же эмулях, в которых память на сериализации экономили?
но неточность подбора маскируется неточностью представления
а тут всё вылезло
У меня загрузчик видит длины импульсов в тактах (не считая загрузки wav, там семплы).
я хз о чем ты, у меня в момент чтения порта проверяется, на какой импульс приходится чтение (если надо, выбирается новый импульс (или импульсы)), и его полярность читается с порта.
грузится и с тормозами, и без них.Цитата:
и да, для чистоты эксперимента тайминги Z80 поставь пентагоновские, без тормозов
тогда пока других идей нет, почему у меня не грузит по той же схеме
ведь я же проверяю логи, такого типа:
...и ничего там подозрительного не вижуКод:...
000000000000000000000000000000000
11111111111111111111111111111111
00000000000000000000000000000000000000000000000000000000000000000
111111111111111111111111111111111111111111111111111111111111111111
00000000000000000000000000000000
111111111111111111111111111111111
...
ну да, длительность для разных tzx отличается
но так и должно получаться
другие эмули твой badall тоже грузят. надеюсь, ты не забываешь загружать в 48к режиме.
у меня тоже все три нормально грузятся. Правда я код подчищал от старых рудиментов, может чтото поменялось. Код для блока PURE-DATA был очень старый, я особо не разбирался что там было, просто переписал начисто, возможно это сказалось.
Что касается MASK, у меня она с полярностью 1 не грузится, ей нужно 0. Вот допиленный TZX, который грузится в ZXMAK2.
Кстати, что у тебя за странный ZIP архиватор? Стандартный UNZIP твой файл не понимает, при этом размер у него на 5% больше, чем если перепаковать стандартным ZIP с обычным уровнем сжатия.
конечно, а иначе просто сбросится еще до
- - - Добавлено - - -
нет, судя по коду, ей нужно именно setlevel=1 (для чётного кол-ва пилотных импульсов)
он же замеряет общую длительность для пары импульсов именно 0000...00001111...11111
https://www.alessandrogrussu.it/load.../gremlin2.html
либо у тебя всё инверсное?
- - - Добавлено - - -
я ж говорил уже - 7-zip 24.08
выложил новый тестовый билд: https://github.com/zxmak/ZXMAK2/issu...ent-2535341864
исправления:
- исправлена частота шума AY
- добавлены оригинальные образы trdos 5.03 и 5.04T (проверял по md5, найти оказалось не просто), эмулятор теперь использует 5.04T по умолчанию
- добавлена ULA Орель БК-08 (не проврял, просто со слов подставил параметры ULA48 без задержек и подправленной дешифрацией порта бордюра)
- подчищен и переработан код загрузки TZX, исправлены мелкие ошибки, добавлено более детальное отображение ошибок, добавлена возможность грузить битые TZX до места ошибки.
У кого есть Орель, проверьте - совпадают ли мультиколорные и бордюрные эффекты в эмуляторе с реальной Орелью.
нет, число ипульсов должно совпадать, там только в одном турбо-блоке я заменил тайминги и число импульсов, т.к. оно сильно отличалось от остальных.
В ZXMAK2 этот MASK.TZX работает :D
Я думаю нужно узнать какие длительности 0 и 1 загрузчик ожидает и сколько импульсов пилот-тона и привести все к единообразию, а то сейчас в этом TZX в каждом блоке тайминги свои, хоть и не сильно отличаются.
Что касается твоего файла bobsleigh-test.zip, то в последней версии ZXMAK2 все три варианта грузятся без ошибок.
не совпадает; я в другом ошибся: ты не добавил, а фактически убрал импульс
флаг=2 это значит первый символ начинается с нуля, то есть совпадает с тишиной
но результат тот же - кол-во реальных импульсов в пилоте стало нечётным
тогда синхропара начинается с нуля и определяется правильно
ZXMAK, да, всё забываю сказать: ctrl+scroll для maximum speed крайне неудачный выбор
во-1, комба вместо одной кнопки; во-2, нынче не на всех клавах есть отдельная кнопка scroll
таким в лучшем случае нужна комба аж из трёх кнопок, в худшем не работает вовсе
Да, точно)
Если ставить у монитора развертку, например, 100Гц, то плавные скроллы в демках чуть дрожат примерно раз в несколько секунд. Но оно и на прежних релизах было, я думаю, от этого никуда не деться при подобном методе синхронизации.
Впрочем, у Спектакулятора дрожание гораздо заметнее и неприятнее, поэтому пока что ZXMAK2 в топчике)
а зачем 100 Гц ставить, я ставлю 50 Гц - скролы идеально плавно идут, как на оригинале :)
Если дисплей не позволяет, то оптимально 75 Гц поставить, но при мерцании цвет не совсем верный получается.
- - - Добавлено - - -
при 100 Гц не получится, чтобы 50 Гц не дрожало - либо прийдется картинку смазывать, либо будет дрожать. По другому никак. Дрожание обусловлено тем, что движение обновляется раз в два кадра, у спектрума нет промежуточных кадров, поэтому заполнить лишний кадр нечем.
Дрожание при таких методах синхронзиации происходит из-за расхождения тактовой частоты звуковухи (если она не интегрированна в материнку) и частоты материнки (процессора) /видюхи.
У меня есть несколько звуковух. Так вот на встроенных все нормально, на отдельной звуковухе, вставленной в слот, периодически дрожит.
- - - Добавлено - - -
Смазывание и дрожание - это разные вещи.
Смазывание происходит из-за того, что между двумя кадрами нет угасания люминофора.
Если каждый второй кадр при 100Гц вставить кадр с половинной яркостью, или хотя бы на 20-30 процентов уменьшенной, то смазывание значительно сократится.
Кстати, если у вас LCD-монитор, то там, что 50, что 100Гц, смазывание будет одинаковое, т.к. у LCD-моников нет между кадрами затухания люминофора (что логично).
- - - Добавлено - - -
Я у себя в эмуляторе пробовал экспериментировать с каждым вторым кадром пониженной яркости, действительно смазывание убирается, но так глаза напрягаются больше, т.к. идет стробоскопический эффект.