Как распознать, что опрос #FE игнорит магнитофон? [Архив] - Speccy

Lethargeek

26.12.2024, 17:34

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

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

то есть, например, основная часть игрушки с мультилоадом загрузилась, напечатала для юзера "stop the tape" и кнопки ждёт
но тем временем tape продолжает тянуться (ну вот tzx такой хреновый, без пометки "АСТАНАВИТЕСЬ", или вообще примитивный tap)

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

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

поделитесь опытом и идеями :v2_dizzy_botan:

ZXMAK

26.12.2024, 20:22

Способ старый - детектим анализом кода/регистров наличие чтения в течении одного фрейма, если есть - обновляем таймаут. В конце фрейма уменьшаем переменную таймаута, если дошли до нуля - то стоп магнитофона.Таймаут в ZXMAK2 используется 50 фреймов (1 секунда).

Lethargeek

26.12.2024, 20:59

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

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

- - - Добавлено - - -

вот, к примеру, press any key в tap-версии Forgotten Worlds

l_ad84: ld hl, $ad8c ; ad84
ld (hl), $fe ; ad87
ld b, $08 ; ad89
l_ad8b: ld a, $ef ; ad8b
in a, ($fe) ; ad8d
and $1f ; ad8f
cp $1f ; ad91
ret nz ; ad93
rlc (hl) ; ad94
djnz l_ad8b ; ad96
jr l_ad84 ; ad98

промежутки меньше, чем длины импульсов

krt17

26.12.2024, 21:58

Стандартный лоадер из которого делают 99.99% кастомных в ожидании смены фронта крутит цикл в 59 тактов, если между последними 5 опросами fe промежутки не 59 тактов у 4 из 5 то стоп.
Если ложное срабатывание то пользователь пусть сам запустит пленку

Lethargeek

26.12.2024, 22:57

Стандартный лоадер из которого делают 99.99% кастомных в ожидании смены фронта крутит цикл в 59 тактов,
во-первых, у 99% кастомных там не 59

если между последними 5 опросами fe промежутки не 59 тактов у 4 из 5 то стоп.
во-вторых, даже в стандартном паттерн примерно ...59,59,59,500+,59,59...

а вот, например, Basil the Mouse Detective
загрузка ...29,29,29,47,29,29,29,,,29,123,29,29...
опрос клавы ...50,50,50,50,150,50,50,50...

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

Если ложное срабатывание то пользователь пусть сам запустит пленку
а загрузка-то уже сбойнула, если ложно остановили
ладно, это вместо автостопа решить можно паузой эмуля
но всё равно, юзера поменьше дёргать желательно

ZXMAK

27.12.2024, 03:02

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

я-же написал - детектим анализом кода/регистров наличие чтения в течении одного фрейма, это не значит что детектить нужно один раз за фрейм. Детектить нужно при каждом обращении к порту. Если детект положительный (в ZXMAK2 проверяется детект на 8 раз подряд в серии без пропуска), то сбрасываем таймаут и запускаем магнитофон, если не запущен.

В конце фрейма уменьшаем таймаут. Если детектов не было, то по прошествии таймаута (в ZXMAK2 50 фреймов) стопаем магнитофон.

вот, к примеру, press any key в tap-версии Forgotten Worlds
промежутки меньше, чем длины импульсов

проверил в ZXMAK2, автостарт магнитофона эта последовательность не вызывает

Lethargeek

27.12.2024, 11:05

я-же написал - детектим анализом кода/регистров наличие чтения в течении одного фрейма,
именно, что "чтениЯ", а не "чтениЙ", и дальше невнятное - "если есть" (что именно?)

Детектить нужно при каждом обращении к порту. Если детект положительный (в ZXMAK2 проверяется детект на 8 раз подряд в серии без пропуска)
"без пропуска" ЧЕГО? фрейма? импульса? пары импульсов? только данных или пилота тоже?

проверил в ZXMAK2, автостарт магнитофона эта последовательность не вызывает
да, и почему же? опрос постоянный, твои "8 раз подряд" набирает за 554 такта
либо что-то недоговариваешь, либо твой детект работает не так, как сам ожидаешь

ZXMAK

27.12.2024, 15:31

"без пропуска" ЧЕГО? фрейма? импульса? пары импульсов? только данных или пилота тоже?

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

да, и почему же? опрос постоянный, твои "8 раз подряд" набирает за 554 такта
либо что-то недоговариваешь, либо твой детект работает не так, как сам ожидаешь

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

Lethargeek

27.12.2024, 20:36

при каждом обращении к порту делаем проверку на чтение магнитофона,
"сепульки - см. сепулькарии; сепулькарии - см. сепуление; сепуление - см. сепульки"
ну блин горелый жеж... ЧТО КОНКРЕТНО значит "делаем проверку на чтение магнитофона"??
вопрос был именно о том, КАК отличить чтение (=проверку) магнитофона от чтения (=проверки) ТОЛЬКО клавиатуры!

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

ZXMAK

27.12.2024, 21:13

вопрос был именно о том, КАК отличить чтение (=проверку) магнитофона от чтения (=проверки) ТОЛЬКО клавиатуры!

однозначного и красивого ответа на этот вопрос нет. В каждом эмуляторе это делается по своему.

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

В ZXMAK2 для этого проверяется что опрос порта происходит с интервалом не превышающим уставку, далее сравнивается состояние всех основных регистров с предыдущим обращением к порту, если изменился 1 регистр в + или в -, то увеличиваем счетчик вероятности опроса магнитофона. Как только счетчик больше уставки (в ZXMAK2 это 8), то считаем что детект положительный, т.е. идет чтение с магнитофона.

Lethargeek

27.12.2024, 21:24

В ZXMAK2 для этого проверяется что опрос порта происходит с интервалом не превышающим уставку,
как определяется уставка? притом паттерны загрузчиков разных блоков одной проги могут быть разными

далее сравнивается состояние всех основных регистров с предыдущим обращением к порту, если изменился 1 регистр в + или в -,
...то он мог вполне считать и длительность нажатия кнопки, или же кол-во нажатых кнопок, а не обязательно длину импульса

ZXMAK

27.12.2024, 21:29

как определяется уставка?

экспериментально :)

то он мог вполне считать и длительность нажатия кнопки, или же кол-во нажатых кнопок, а не обязательно длину импульса

ну универсального способа помоему нет, программа ведь может только для вида читать порт и анализировать бит магнитофона так, как-будто на самом деле читает магнитофон, а на самом деле просто ожидает нажатие кнопки :)

Lethargeek

27.12.2024, 21:35

экспериментально :)
в смысле, как-то так?
https://imgs.xkcd.com/comics/random_number.png
или всё же динамически вычисляется?

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

ZXMAK

27.12.2024, 21:52

в смысле, как-то так?

:biggrin: да, както-так. В ZXMAK2 используется проверка на 96 тактов. На включение работает вроде неплохо. Правда со стопом запаздывает. Возможно после запуска магнитофона имеет смысл менять уставку.

Dexus

28.12.2024, 06:44

Может кто-то смотрел статистику по лоадерам - сколько раз во фрейм читается #fe? Чтобы даже не смотреть какие биты потом обрабатываются. Мне думается, что для лоадеров будет другое число в момент ловли пилот-тона, чем от сканирования клавиш, или даже экзотического анализатора частот.

ZXMAK

28.12.2024, 09:34

Lethargeek

28.12.2024, 11:21

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

а пока держи еще одного клиента, странный он и с автостопом, и без
во-первых, почему вообще у тебя лента не останавливается после окончания-перемотки?
во-вторых, без остановки он в конце зачем-то имитирует загрузку ненужного ему блока (даже с полосками))
(а может, даже вправду загружает и тем что-то портит себе внутре, не смотрел еще)
(и это еще кроме аццкого паттерна промежутков)

ZXMAK

28.12.2024, 17:57

а пока держи еще одного клиента

поменяй архиватор на нормальный zip, чтобы unzip не падал с ошибкой. Или хотя-бы расширение 7z ставь.
Везде zip-ы нормально unzip-ом открываются, а твои unzip не открывает, только 7z. Приходится перепаковывать zip-ом.

странный он и с автостопом, и без

а что с ним не так? Что магнитофон не останавливается?

во-первых, почему вообще у тебя лента не останавливается после окончания-перемотки?

после завершения файла и перехода к началу? нужно будет проверить.

Lethargeek

29.12.2024, 12:59

поменяй архиватор на нормальный zip, чтобы unzip не падал с ошибкой.
что, вот прям падает вместо сообщения о неизвестном формате сжатия?
архиватор на данных неизвестного формата падать не должен, замени его на нормальный

Или хотя-бы расширение 7z ставь.
с чего вдруг, если файл - нормальный контейнер zip? определение контейнера знаешь?
если твой архиватор падает на корректно размещённом внутри объекте, это не проблема контейнера

Везде zip-ы нормально unzip-ом открываются, а твои unzip не открывает, только 7z. Приходится перепаковывать zip-ом.
у меня в тоталкомандере открывает и как с обычной папкой работает

а что с ним не так? Что магнитофон не останавливается?
причём с имитацией загрузки не останавливается
да и внутри творится какой-то ад - то нормальный короткие промежутки, то всего один на импульс (без пропусков!)

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

Dexus

29.12.2024, 16:08

вроде тут нащупал рабочую схемку без анализа регистров и кода, а только промежутков и уровней, сейчас тестирую ;)
Что имеется в виду под уровнями?
Промежутки, как я вижу, на 3.5Мгц (а это как бы и норма при которой лоадеры работают), должны быть плюс-минус одинаковые, находиться в определённых "окнах" (в зависимости от того какой вид защиты и скорости используется". Но в целом, можно было бы определить паттерны. Под паттерном я имею в виду статистическую картину именно в момент ловли "пилота", у него все равно плюс-минус узкое окошко.

ZXMAK

29.12.2024, 17:11

с чего вдруг, если файл - нормальный контейнер zip? определение контейнера знаешь?
если твой архиватор падает на корректно размещённом внутри объекте, это не проблема контейнера

если бы он мой был. Но проблема в том, что стандартный архиватор unzip в линукс падает:

$ unzip bba.zip
Archive: bba.zip
skipping: bba-bba.tzx need PK compat. v6.3 (can do v4.6)
skipping: bba.tzx need PK compat. v6.3 (can do v4.6)
$ unzip
UnZip 6.00 of 20 April 2009, by Debian. Original by Info-ZIP.

Та-же беда в Windows и со всеми библиотеками, которые не понимают новый 7z.
7z понимает, но это явно не zip.

Во всех стандартных zip архивах такой проблемы нет. А ведь zip это особый формат для обмена, он не допускает новых версий не совместимых со старым. Без такой совместимости нет никакого смысла создавать zip архивы, т.к. сжатие в них хуже, чем в других типах архиваторов. Если выкладываешь несовместимый с zip архив, тогда почему не rar или 7z?

у меня в тоталкомандере открывает и как с обычной папкой работает

в тотал коммандер можно прикрутить хоть rar, чтобы он создавал файлы с расширением zip. Но zip это особый вид архива, который предполагает совместимость со старыми версиями софта, в котором нет поддержки новомодных архиваторов, т.к. это не стандартный zip и смысла в нем мало. Именно поэтому все zip файлы из архивов tzx и прочих архивов и источников всегда открываются unzip, чтобы их везде можно было распаковать без проблем, не думая о том где скачать новомодный архиватор для платформы на котором его нет.

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

Lethargeek

29.12.2024, 17:28

Что имеется в виду под уровнями?
уровень на входе EAR (#FE бит D6)
фронт - изменение значения по сравнению с прочитанным в прошлый раз

Промежутки, как я вижу, на 3.5Мгц (а это как бы и норма при которой лоадеры работают), должны быть плюс-минус одинаковые, находиться в определённых "окнах" (в зависимости от того какой вид защиты и скорости используется".
промежутки между in(#FE) в тактах z80
они неодинаковые (иногда непредсказуемо, пример выше)

Но в целом, можно было бы определить паттерны.
пока неплох более простой способ, надо помнить только три последних in(#FE)

Под паттерном я имею в виду статистическую картину именно в момент ловли "пилота",
на пилот ориентироваться нельзя, на пилоте загрузчик может в произвольные моменты творить что хочет, если не пропустит начало данных

- - - Добавлено - - -

если бы он мой был. Но проблема в том, что стандартный архиватор unzip в линукс падает:
а, так ты снова термины не к месту употребляешь, "падает" - это аварийное завершение, а здесь отчёт с намёком обновить софт

need PK compat. v6.3 (can do v4.6)
ну так и обновись до этого v6.3

Во всех стандартных zip архивах такой проблемы нет. А ведь zip это особый формат для обмена, он не допускает новых версий не совместимых со старым.
:v2_dizzy_facepalm: еще раз - zip это формат КОНТЕЙНЕРА (гугли термин), а не самих объектов в этом контейнере
нет проблем с контейнером в данном случае; проблема в том, что твой унзип 15-летней давности

Dexus

29.12.2024, 18:20

уровень на входе EAR (#FE бит D6)
фронт - изменение значения по сравнению с прочитанным в прошлый раз

Занечения там меняются только когда лента уже имитируется. Тут же вопрос о том - надо ли её включать или это не лоадер а что-то иное.

промежутки между in(#FE) в тактах z80
они неодинаковые (иногда непредсказуемо, пример выше)
И тем не менее, тайминги между чтениями в рамках фрейма можно складывать в массив, считая статистику, и видеть определённые пики, сигнализирующие о том, что происходит вылавливание во входящем сигнале «пилота».

пока неплох более простой способ, надо помнить только три последних in(#FE)
Что-то мне кажется что в такой истории будет масса ложных срабатываний. Слишком реактивное реагирование. Для того чтобы автовключение считать успешным, можно и на пару фреймов устраивать тестирование чтобы убедиться в отсутствии ложных признаков - это вообще не будет проблемой.

на пилот ориентироваться нельзя, на пилоте загрузчик может в произвольные моменты творить что хочет, если не пропустит начало данных
Ему нужно считать задержки. Что хочет он творить не может. Может быть и загрязнение чтением из FE(в чем я сомневаюсь), но регулярность чтения должна быть всемерной.
Правда, тут подумалось, что в целом было бы правильно устраивать ложное изменение значений с 0 на 1 и назад каждый цикл чтения из FE, тогда ловца пилота точно можно будет поймать. Со статичным значением этого бита загрузчик может по фрейму устраивать паузу ждя хотя бы одного изменения, и такое уже не поможет поймать загрузку.

Lethargeek

29.12.2024, 18:42

в тотал коммандер можно прикрутить хоть rar, чтобы он создавал файлы с расширением zip.
у меня в настройках внутренний упаковщик от info-zip (тоже старый, но всё-таки чуть поновее, чем у тебя)

Но zip это особый вид архива, который предполагает совместимость со старыми версиями софта, в котором нет поддержки новомодных архиваторов, т.к. это не стандартный zip и смысла в нем мало. Именно поэтому все zip файлы из архивов tzx и прочих архивов и источников всегда открываются unzip, чтобы их везде можно было распаковать без проблем, не думая о том где скачать новомодный архиватор для платформы на котором его нет.
твои отмазки - это особый вид болтовни)) а "совместимость со старой версией софта" в данном случае выразилась в том, что твой старый софт вовсе не упал, как ты первоначально дезинформировал, а корректно открыл корректный контейнер, корректно определил неподдержанный метод сжатия, и мягко посоветовал тебе обновиться

Поэтому если стандартный unzip падает на ахивах созаваемых вашим тотал командером,
поэтому, если стандартный ДРЕВНИЙ unzip падает намекает, что его надо обновить - обнови

- - - Добавлено - - -

Занечения там меняются только когда лента уже имитируется. Тут же вопрос о том - надо ли её включать или это не лоадер а что-то иное.
не включив ленту, не определить надёжно, что работает - опрос только клавы или мафона
так что включить придётся, чтобы оценить реакцию на сигнал; если нет реакции - сразу выключить
судя по звуку, эмули так и работают

И тем не менее, тайминги между чтениями в рамках фрейма можно складывать в массив, считая статистику, и видеть определённые пики, сигнализирующие о том, что происходит вылавливание во входящем сигнале «пилота».
слишком громоздко

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

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

ZXMAK

29.12.2024, 18:53

еще раз - zip это формат КОНТЕЙНЕРА (гугли термин), а не самих объектов в этом контейнере
нет проблем с контейнером в данном случае; проблема в том, что твой унзип 15-летней давности

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

Проблема с контейнером в данном случае в том, что при наличии всех последних обновлений системы, такие файлы невозможно распаковать стандартным unzip. На платформах, где свежие 7z недоступны и есть только стандартный unzip без закрытых алгоритмов, которые недоступны в открытом коде, такие файлы вообще невозможно распаковать.

Lethargeek

29.12.2024, 19:13

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

Проблема с контейнером в данном случае в том, что при наличии всех последних обновлений системы, такие файлы невозможно распаковать стандартным unzip. На платформах, где свежие 7z недоступны и есть только стандартный unzip такие файлы вообще невозможно распаковать.
с чего ты решил, что именно твой унзип именно твоей версии - универсально "стандартный" на всех платформах?

Dexus

29.12.2024, 19:24

слишком громоздко
Почему?
Первые 4000 тактов с точностью до такта (то есть массив из 4 тысяч вордов). Что больше - вообще игнорировать, так как паузы больше 4000(может даже меньше) тактов вообще не могут быть в стадии ловли пилота. Ничего громоздкого. Потом просмотреть пики. Проанализировать все доступные загрузчики (учитывая всякие экзотические сверхтурбированные tzx, которые только в цифровом виде работают и загружают 40 килобайт за 40 секунд).

Lethargeek

29.12.2024, 19:44

Почему?
потому что можно намного проще

Первые 4000 тактов с точностью до такта (то есть массив из 4 тысяч вордов) ...
вот нафига? что он даст при выключенном мафоне?

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

ZXMAK

29.12.2024, 19:44

он 2009 года - жалуйся мейнтейнерам на него, если сам не хочешь решать вопрос

Скачал самый свежий код unzip, скомпилил, он оказался тоже 2009 год, результат еще хуже:

$ ./unzip/build/unzip bba.zip
Archive: bba.zip
skipping: bba-bba.tzx need PK compat. v6.3 (can do v2.1)
skipping: bba.tzx need PK compat. v6.3 (can do v2.1)
$ unzip
UnZip 6.00 of 20 April 2009, by Debian. Original by Info-ZIP.

Информация с сайта:

Latest Release

New features in UnZip 6.0, released 20 April 2009

У меня просто вопрос - почему-бы не использовать стандартный zip, который даже контроллером утюга поддерживается? Это обязательно использовать непонятный формат, который невозможно стандартным unzip свежей версии распаковать?

Lethargeek

29.12.2024, 19:58

Скачал свежий код unzip, скомпилил, он оказался тоже 2009 год, результат еще хуже:
значит, жалуйся по правильному адресу, а не в спортлото мне

У меня просто вопрос - почему-бы не использовать стандартный zip, который даже контроллером утюга поддерживается? Это обязательно использовать непонятный формат,
еще раз: я использую СТАНДАРТНЫЙ КОНТЕЙНЕР ZIP, почему бы тебе не перестать открывать его древним утюгом?
вот если тебе напишет счастливый обладатель еще более древней "свежей" (на его системе) версии архиватора - ты свою откатишь ради него?

и хватит здесь уже офтопа на тему зипов

Chwe

29.12.2024, 20:38

Тише, тише, горячие парни :) Я, как любитель уточнить детали, встряну с оффтопом:

Как со всякой проприетарщиной, ни о каких единых стандартах тут речи нет. Вернее, есть спецификация PKZIP от PKWARE. Кто этим пользуется, я лично не знаю, наверное, какие-то клиенты у них есть. Педивикия говорит, что есть какой-то ISO стандарт, что ему соответствует тоже не интересовался. И есть то, чем большинство пользуется и за «настоящий ZIP» считает -- Info-ZIP. Так вот, PKZIP дошёл где-то до версии 6.3, а Info-ZIP со времён 4.x (4.5?) не трогали за ненадобностью, это был уже XXIй век, там было и чем получше сжать/упаковать.

Поэтому практический совет: если у вас не Info-ZIP, предупредите получателя, это я старый больной |Пью, а кто помоложе или подальше от этой teh drama последние двадцать лет провёл, может в этих хитросплетениях и не разбираться :)

Dexus

29.12.2024, 21:24

потому что можно намного проще
Работает для всех возможных загрузчиках? Есть имплементация, чтобы потестировать?

вот нафига? что он даст при выключенном мафоне?
Каждое прерывание будет заполняться буфер со статистикой. Который должен будет в фоне мониториться (если стоит крыж "автозапуск ленты").
Длина 4000 - это условно. По факту после тестирования на всех возможных загрузчиках (и в других режимах работы программ) будет видно, сколько уже хватит. В идеале, конечно коротенький. Но его "мониторинг" много ресурсов не отнимет. Во-первых, его заполнение практически не удлинит логику эмуляции (что происходит в том же Fuse, когда постоянно анализируется исполняемый код). Во-вторых мониторить его можно не часто, и вообще в другом потоке - реактивность тут вообще не нужна.

мне уже и после некоторых понятно, что без наличия фронтов на входе опрос мафона от иных опросов клавы - не отличить
Да, это я уже тоже понял. Но фронт на входе в идеале должен быть фейковым, с периодом в 1 (менять состояние каждое новое чтение, без привязки к cpu-t). Это позволит в загрузчиках максимально "уплотнить" и стабилизировать период чтения из порта в подпрограмме вылавливания пилота. Вовсе не обязательно пускать первые секунды tap, tzx, или wav, в котором может быть вообще что угодно, просто начальный хруст, или даже пауза.

- - - Добавлено - - -

Даже не так.
Считать статистику в четном прерывании, с генерируемым каждый in(#fe) тоном максимальной частоты (каждое новое чтение = измененное значение), и в нечётном - полная тишина (значение 0). Может быть не по 1 прерыванию а типа 2 с писком и 1 с тишиной, в общем чтобы было как-то идентифицируемо то что "там" происходит обработка магнитофонного бита.
Статистика в буферах будет сильно различаться, если присутствует подпрограмма чтения.
Вопрос в том как такой буфер устроить наиболее простым способом, чтобы и меньше памяти тратить на это, и меньше логики для обработки.
Но смысл в том, чтобы чередовать писк с тишиной, и мониторить тайминги между чтениями из #fe.

- - - Добавлено - - -

Далее когда всё воспроизводится, уже в ходе чтения смотреть статистику, зафиксировать её паттерн (фингерпринт воспроизведения). И если он поменяется, ленту останавливать.

Lethargeek

29.12.2024, 22:25

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

но могу принцип и сейчас описать, благо коротко:
помним три последних уровня (просто вдвигаю биты в переменную) и знаем промежуток в тактах между получением двух последних уровней
смотрим на ПРЕДпоследние два уровня (бита) - если они одинаковые, запомним промежуток как "короткий" (он реально может быть и длинный, не важно)
если они разные, то прошлое чтение пришлось на фронт, на который реальный загрузчик реагирует увеличением промежутка из-за обработки фронта
тогда сравниваем последний с "коротким" - при реакции должен быть длиннее... на сколько-то (хотя на практике работает и просто "длиннее")
для надёжности увеличиваем счётчик отсутствия реакций до некоторого порога, прежде чем сигнализировать автостоп
я сделал так: два подряд фронта без реакций +2, два фронта подряд с реакциями -1 (до нуля)

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

Каждое прерывание будет заполняться буфер со статистикой. Который должен будет в фоне мониториться (если стоит крыж "автозапуск ленты").
Длина 4000 - это условно. По факту после тестирования на всех возможных загрузчиках (и в других режимах работы программ) будет видно, сколько уже хватит. В идеале, конечно коротенький. Но его "мониторинг" много ресурсов не отнимет. Во-первых, его заполнение практически не удлинит логику эмуляции (что происходит в том же Fuse, когда постоянно анализируется исполняемый код). Во-вторых мониторить его можно не часто, и вообще в другом потоке - реактивность тут вообще не нужна.
зачем, просто автозапуск и проверка реакций, и при их отсутствии - остановка с перемоткой в начало блока
главное - после остановки не повторять автозапуска, пока длится тот же самый опрос))

Да, это я уже тоже понял. Но фронт на входе в идеале должен быть фейковым, с периодом в 1 (менять состояние каждое новое чтение, без привязки к cpu-t). Это позволит в загрузчиках максимально "уплотнить" и стабилизировать период чтения из порта в подпрограмме вылавливания пилота. Вовсе не обязательно пускать первые секунды tap, tzx, или wav, в котором может быть вообще что угодно, просто начальный хруст, или даже пауза.
зачем фейковый (на который прога может вдруг и неадекватно отреагировать), когда можно настоящий подать?

- - - Добавлено - - -

практический совет: если у вас не Info-ZIP, предупредите получателя,
в моём тотале вроде инфозип как раз и встроен, такой же старый, но PPMd понимает

Dexus

29.12.2024, 22:34

зачем фейковый (на который прога может вдруг и неадекватно отреагировать), когда можно настоящий подать?
Потому что в tzx и тем более в wav'ках на выходе может быть нерелевантный хруст, хоть пол секунды, хоть секунду, хоть дольше. Я понимаю, с tap'ом вариантов нет - все стандартно, но нас же интересуют нестандартные образы (tzx/wav), которые никто не обязан вылизывать. В wav вообще модет быть несколько секунд тишины, и может голос объявлять номер уровня. Потому фейковый - более надежный.

помним три последних уровня (просто вдвигаю биты в переменную) и знаем промежуток в тактах между получением двух последних уровней

Ты смотрел tzx'ы, которые генерируются конвертером https://zx-pk.ru/threads/21336-novyj-bolee-effektivnyj-kassetnyj-format.html ?
Еще есть конвертер снапов в tzx, что-то не могу пока найти (там пачка алгоритмов и режимы с разной скоростью) - нашел. Называется k7zx.
Схема загрузчика может быть с автоподстройкой под скорость, и 3х может не хватить.

Lethargeek

29.12.2024, 23:29

Потому что в tzx и тем более в wav'ках на выходе может быть нерелевантный хруст, хоть пол секунды, хоть секунду, хоть дольше. Я понимаю, с tap'ом вариантов нет - все стандартно, но нас же интересуют нестандартные образы (tzx/wav), которые никто не обязан вылизывать. В wav вообще модет быть несколько секунд тишины, и может голос объявлять номер уровня. Потому фейковый - более надежный.
наоборот, нет гарантии, что твой фейк нерелевантнее не окажется - в отличие от уже проверенной загрузкой записи с любым треском
потом, нужно ведь определить только факт наличия стабильной реакции на фронты

алсо, на wav (а также direct и csw) автостоп лучше вообще отрубать, ведь неясно, где там данные, где пилот, где полезный шум, а где мусор
да и в принципе автостоп опасная штука; я вообще себе автостарт не делал, а вместо автостопа у меня пауза - юзер сам решает, как продолжать

Ты смотрел tzx'ы, которые генерируются конвертером https://zx-pk.ru/threads/21336-novyj...yj-format.html ?
Схема загрузчика может быть с автоподстройкой под скорость, и 3х может не хватить.
да какая разница, фронты везде одинаковые))
не хватить с любым форматом в принципе может, даже с пзушным стандартным
ЕСЛИ нестандартный загрузчик на фронты будет с отставанием реагировать
но мне пока такие не попадались - вероятно, потому что бессмысленно
просто код получается сложнее - ради чего?

- - - Добавлено - - -

глянул логи 8b10b - разница после фронта совсем небольшая, но различимая, и без отставания появляется

Dexus

29.12.2024, 23:45

наоборот, нет гарантии, что твой фейк нерелевантнее не окажется - в отличие от уже проверенной загрузкой записи с любым треском
потом, нужно ведь определить только факт наличия стабильной реакции на фронты
Потому уповать на релевантность информации с tzx/wav - наивно, гарантия есть только когда пробная запись синтетическая.

алсо, на wav (а также direct и csw) автостоп лучше вообще отрубать, ведь неясно, где там данные, где пилот, где полезный шум, а где мусор
да и в принципе автостоп опасная штука; я вообще себе автостарт не делал, а вместо автостопа у меня пауза - юзер сам решает, как продолжать
Сам выше же писал, что отвлекать юзера плохо (то есть в идеале - автоматизировать и запуск, и остановку всего, включая wav), и сам же от этого фактически отказываешься, tap автоматизируется - и ладно (tzx не каждый сработает)... И по итогу тему можно закрывать на словах "Пусть пользователь решает".

На этом я откланиваюсь (для себя я уже все моменты уяснил, вижу дальше только бодания на пустом месте). Удачи с охватом всех tzxов.

- - - Добавлено - - -

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

Lethargeek

29.12.2024, 23:53

Потому уповать на релевантность информации с tzx/wav - наивно, гарантия есть только когда пробная запись синтетичнская.
еще раз - tzx/wav УЖЕ проверен успешной загрузкой без автостопа
(ну, или безуспешной, но тогда он не загрузится в любом случае)
"пробная синтетическая запись" - не проверена

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

И по итогу тему можно закрывать на словах "Пусть пользователь решает".

На этом я удаляюсь (для себя я уже все уяснил).
"как-ничего-не-понять,но-не-подать-виду-и-гoрдo-удалиться.жпг" :D

- - - Добавлено - - -

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

Titus

30.12.2024, 00:03

будет в следующей версии юлакс-эмуля

Кстати, почему эмуляторописатели в основном остались на устаревшем движке Direct3D 9-й версии?

Никто не пишет под современные Direct2D?

Lethargeek

30.12.2024, 00:14

Кстати, почему эмуляторописатели в основном остались на устаревшем движке Direct3D 9-й версии?

Никто не пишет под современные Direct2D?
это мне вопрос? я вообще пишу под SDL2 не интересуясь, что под капотом
да и зачем лёгкий софт лишать возможности работать на старом (уже) железе

ZXMAK

30.12.2024, 01:05

стати, почему эмуляторописатели в основном остались на устаревшем движке Direct3D 9-й версии?

Никто не пишет под современные Direct2D?

Direct3D 9 это по сути последняя версия поддерживаемая на WinXP. Direct2D на WinXP нет, также как и на других платформах. Та-же беда с DXGI расширениями. Библиотека интересная и неплохо рисует, но код под нее оказывается жестко привязан к Windows, даже портировать его под OpenGL будет проблематично. В этом вобщемто и суть. Наиболее портабельный вариант - это OpenGL, который почти не уступает Direct2D по качеству, но проще и работает практически на всех платформах. Из кроссплатформенных либ SDL2 хорош легкостью портирования, правда имеет баги. GLFW получше, правда имеет свои грабли.

- - - Добавлено - - -

Обновил zip на ново-модный, теперь понимает файлы от Lethargeek :)

Кстати вот наткнулся на любопытный загрузчик, в ZXMAK2 при чтении с автостопом приводит к ложному срабатыванию остановки магнитофона, т.е. метод распознавания чтения магнитофона методом анализа регистров дал сбой. Заодно тест для TZX блока #15, что не часто встретишь:

Titus

30.12.2024, 05:39

Direct3D 9 это по сути последняя версия поддерживаемая на WinXP. Direct2D на WinXP нет, также как и на других платформах. Та-же беда с DXGI расширениями. Библиотека интересная и неплохо рисует, но код под нее оказывается жестко привязан к Windows, даже портировать его под OpenGL будет проблематично. В этом вобщемто и суть. Наиболее портабельный вариант - это OpenGL, который почти не уступает Direct2D по качеству, но проще и работает практически на всех платформах. Из кроссплатформенных либ SDL2 хорош легкостью портирования, правда имеет баги. GLFW получше, правда имеет свои грабли.

Продолжу немного оффтоп:
Если взвесить на весах либо поддержку XP, котороая ну совсем устарела, либо поддержку современных API, то лучше выбрать современные.
Конечно, если ты пишешь кроссплатформенно, то тут вариантов немного.
Но лично я решил переходить на Direct2D, когда увидел, сколько там полезного для улучшения и качества видео (та же минимальная задержка между отрисовкой и выводом на экран, которую никак не получить в обход Direct2D, или возможность использования кубической фильтрации при масштабировании изображения), и звука.
Плюс, часть функций отрисовки экрана я переложил на шейдеры. Понравилось. Разгружает процессор, и позволяет сделать многое интересное.