ROM-формат: автозапуск, защита, секреты

[svofski]

ivagor, есть смысл добавить в мегатест, если BYTEMAN его еще не запустил? Я вечером смогу обновить.

Не знаю, что в OTLA, но подозреваю, что там какой-то компромисс. Что-нибудь типа того, что в последовательном порту. Стоп бит, старт бит, дальше просто сколько-то бит PCM и так далее.

[ivagor]

ivagor, есть смысл добавить в мегатест, если BYTEMAN его еще не запустил? Я вечером смогу обновить.

Не стоит, в fm3 (не slow) и fm4 все на грани, шаг влево-шаг вправо и не будет грузится.
Судя по wav, в OTLA нечто похожее на ЧМ, но уверен не на 100%.
Все же у вектора и частота поменьше и торможение и 8080 вместо z80 - все это не позволит догнать спек, но ускорить еще можно. Понятно, что каждую оптимизацию загрузчика можно использовать либо для увеличения скорости либо для повышения помехоустойчивости, т.ч. потенциальный fm4slow мог бы быть чуть быстрее fm3slow.

[BYTEMAN]

ivagor, есть смысл добавить в мегатест, если BYTEMAN его еще не запустил? Я вечером смогу обновить.

К тестам результаты будут в субботу либо воскресенье с утра.

[svofski]

ivagor, вот что можно попробовать https://en.wikipedia.org/wiki/Group_code_recording

[ivagor]

Признаюсь, в магнитной записи я совершенно темный. Не знаю, почему много единиц подряд можно, а много нулей - нет. И разве произвольный бытовой магнитофон гарантирует, что он запишет именно "прямо", а не инверсно? А для передачи по шнурку от pc сразу в вектор (v06cc или 06ц) думаю это вобще не поможет.

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

Кроме того, перекос в сторону единиц дает постоянную составляющую. Наверно я что-то недопонимаю.

[svofski]

Если они говорят, что 0 это отсуствие инверсии потока, то видимо 1 — это ее присуствие. То есть это не буквальные нули и единицы. В таком случае понятно, почему много нулей подряд плохо (получается перевес в одну из сторон, теряем зацепку клока), а перевес в сторону единиц дает больше инверсий.

[svofski]

-

[ivagor]

Пардон, читал по диагонали и пропустил "...zero bits (which are represented by lack of a flux reversal)..."

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

Избыточность gcr 20% (без учета помехоустойчивого кодирования). Избыточность fm4 - 33% (без учета синхробитов, которые понадобятся и при программной реализации gcr). Т.е. gcr эффективноее, но. Так получилось, что в fm3/fm4 используется универсальная (неоптимальная) процедура getbit, которая фактически может быть использована для gcr (различение 1, 10 и 100). И я планирую разделить ее на две процедуры, оптимизировать и попробовать уменьшить длительность бита, что для gcr не получится, т.к. там еще нужно время на преобразование 5->4 (как бы не пришлось наоборот увеличивать длительность бита).

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

Rom2fm5. Оптимизация сказалась даже лучше, чем я предполагал - минимальная скорость выросла до 9300 бит/сек, что примерно соответствует OTLA с поправкой на разницу в быстродействии спека и вектора. PUTUP грузит за 13,745 сек (почти 10300 бит/сек!). Два недостатка:
1. Пришлось вернуться к высокой частоте дискретизации 44100 Гц
2. Emu не переваривает такую скорость. Главное целевое устройство "v06cс на de1" и VV грузят без проблем.

[svofski]

ivagor, это бешено круто. Как я понимаю, проблема взаимодействия с реальной пленкой в таких запределах упирается скорее в недостаточное быстродействие Вектора, чем в физические особенности канала. Жаль, что ты не показываешь код, а заморачиваться с дизассемблером мне чего-то невмоготу. Может быть можно оптимизировать ввод бита. Например, в стандартном загрузчике написано так:

MASK:   .EQU     00010000B       ;бит ввода с мг.
IZMSIG: IN      01      ;
        ANI     MASK    ;
        CMP     E       ;
        JZ      IZMSIG  ;
        RLC             ;
        RLC             ;
        RLC             ;
        RLC             ; итд

И все это еще в цикле. Что если цикл развернуть, а с тестом на бит схитрить так, чтобы избавиться от сравнений. Например, такой грубый псевдокод:

...
lxi h, adj_middle
mvi e, MAGIC ; то, что при сложении со значением в порте 01, будет давать или нет флаг переноса
...
adj_longest:
in 01
add e
rlc ; или jc xxx...
adj_long:
in 01
add e
rlc
adj_middle:
... 
adj_shorter:
...
adj_shortest:
; тут магия, декодирование, группировка и проч
; по результатам, когда определено изменение входа, вносим временную поправку в длину цикла - меняем HL на один из adj_...
pchl

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

P.S. Кстати, github теперь поддерживает закачку файлов простым дрег-н-дропом в браузере

[ivagor]

Источник loadfm5 выкладываю, вряд ли там ты или кто-нибудь найдет нечто хитрое. Но я для разнообразия в этот раз нигде не списывал.
Насчет чтения бита (группы бит) я так понимаю ты думаешь про gcr. Ради спортивного интереса можно подумать, но вряд ли получится быстрее, чем fm5.
drag&drop в github - это круто