Загрузка с магнитофона на БК-0011(М)

[Manwe]

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

Код, к сожалению, не очень-то подгоняется. Сложность ещё в том, что кроме кода надо подгонять частоту дискретизации WAV. Я делал так: считывал 1000 периодов настроечного тона и выводил на экран сколько за это время насчитал счётчик. Цель была получить ровно 6000 (то есть ровно 6 проходов цикла на каждый период). В зависимости от того, насколько число отличалось от 6000, исправлял частоту дискретизации WAVа. С первого раза никогда не совпадало - то недолёт, то перелёт. Приходилось последовательным приближением находить оптимальную частоту. И она никак не делится на целое число тактов процессора.

Казалось бы, что здесь могло пойти не так? Справа от всех инструкций написана их длительность в тактах. Но на практике сумма не сходится. Сильно. SOB закомментирован и не используется, так как длительность 20 тактов никуда не подходит. Вместо него DEC и BNE. Кусок длительностью 44 такта можно заменить на 56 - всё равно ничего не сходится. Непредсказуемо.

		; count 1000 periods

4:		INC R2		; 12 | 56
		BIT R5,(R4)	; 28 |
		BNE 4		; 16 |

5:		BIT R5,(R4)	; 28 | 44
		BEQ 5		; 16 |

		INC R2		; 12 | 56
		BR 6		; 16 |
6:		DEC R0		; 12 |
		BNE 4		; 16 |

;		SOB R0,3	; 20

[blackmirror]

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

	MOV 0,Rcode
	MOV 0,Rnext
WAIT0:	BIT BNE WAIT0	; ждём низкий уровень
WAIT1:	BIT / BEQ WAIT1	; ждём его изменение на высокий
	ASL Rcnt		; тестируемый код
	MOV Tune,Rcnt
	ADC Rdata
	MOV Rdata,(Rbuf)
	MOV 1,Rdata	
	DEC Rlen	
	BNE WAIT2
WAIT2:	INC Rcode	;считаем сколько длится высокий уровень за вычетом кода
	BIT
	BNE WAIT2
WAIT3:	INC Rnext	;считаем сколько длится низкий уровень
	BIT
	BEQ WAIT3

В качестве порога потом использовать Rcode+Rnext/2. На всякий случай можно будет сделать такую же проверку и для другой полярности. Если Rcode или Rnext будут сильно расходиться, значит либо сильно смещён уровень и длительность полуволн неодинаковая, либо в сигнале есть какие-то выбросы. В теории сигнал должен будет приниматься если max(Rcode+, Rcode-) < Rcode+Rnext/2 < min(Rnext+, Rnext-). Вообще хорошо бы вывести в каждую строку экрана, что мы принимаем после того как дождёмся перепад заданной полярности. В идеале должны получиться вертикальные полосы с дрожанием +/-1 пиксель на границах. А особая подгонка дискретизации WAV не должна требоваться если она хотя бы 3-4 раза выше частоты сигнала.

[Manwe]

особая подгонка дискретизации WAV не должна требоваться если она хотя бы 3-4 раза выше частоты сигнала.

Сейчас у меня в алгоритме со скважностью частота дискретизации 36394 Гц. В 3 раза - это длина волны 3 отсчёта, получается тон 12 КГц. Слишком много для бытовых источников звука. Ну а если снижать частоту дискретизации, всё замедлится.

Попробовал алгоритм без счётчика (с кучей проверок подряд), замеры выводят на частоту дискретизации 36235 Гц. Кодирую единицу сигналом 1,1,0,0 и ноль сигналом 1,0,0. Средняя скорость 10400 бод. Пока распознавание плохое. Слишком много быстрых перепадов, высокая частота звука. Но я ещё поэкспериментирую.

[blackmirror]

Ну а почему сразу не перейти на кодирование половиной волны если магнитофоны не справляются? 0 или 1 считать за 0, а 00 или 11 считать за 1, частота сразу в два раза снижается. Можно настраиваться на циклически передаваемое слово 09AF, которое при передаче выглядит как 0101 001011 001001 00110011, здесь есть и длинные и короткие импульсы во всех комбинациях и полярностях, и мы можем напрямую измерять сколько какой из них длится. Кроме этого 09AF прекрасно тем, что если его циклически сдвигать и брать младшие 4 бита, мы получаем 16 различных значений. То есть после настройки на длину импульсов мы начинаем приём, принимаем какую-то фигню, и взяв младшие 4 бита(впрочем подойдут и любые другие), по таблице определяем сколько бит нужно выбросить, чтобы синхронизироваться и правильно принимать 09AF. Ну а дальше(продолжая принимать 09AF) ждём стартовую сигнатуру, длину блока и прочие данные.

[Manwe]

Ну а почему сразу не перейти на кодирование половиной волны если магнитофоны не справляются? 0 или 1 считать за 0, а 00 или 11 считать за 1

у меня так и есть: ноль кодируется полуволной «1», а единица полуволной «1,1». И после этого «0,0» чтобы успеть обработать считанное. Но как я говорил, «1,0,0» – это частота 12 КГц, даже больше. Это перебор.
До четырёхбитных пакетов пока далеко – нам бы хоть что-нибудь считать на таких скоростях.
Реальная ситуация такова: я измерю 1000 периодов пилотона вида «1,1,1,0,0,0» (считаю только полуволну высокого уровня) и получаю значения от 5996 до 6004 в серии экспериментов. Это значит, что иногда волна считывается не 6 раз, как должна, а 5 или 7. Этой точностью мы и ограничены. Поэтому нельзя делать короткие перепады типа «1,0,1,0»

[blackmirror]

Весь вопрос сводится к тому, что за время короткой полуволны мы должны успеть хотя бы 1 раз её прочитать и обработать, иными словами от одной метки WAIT дойти до другой. Допустим волны длительность 50мкс, частота процессора 4МГц, а цикл ожидания требует 50 тактов, или 5 мкс и прочитать короткую полуволну мы успеваем 10 раз. Длинную полуволну мы успеем прочитать 20 раз, и счётчик нужно загружать средним значением, то есть цифрой 15, тогда за время короткой волны сменить знак он не успеет, а за время длинной успеет. Но нам еще нужно выполнить обработку, и если она к примеру занимает по времени 7 или 8 итераций чтения, мы просто уменьшаем на эту величину счётчик и всё.
В длинной ветке последнего кода с предыдущей страницы получилось 10 команд вместе с циклом чтения, если в среднем выделить на каждую по 20 тактов, получится, что короткая полуволна должна быть не менее 200 тактов, что для частоты 4МГц будет 50мкс, и даст сигнал 10кГц для коротких полуволн и 5кГц для длинных.
Можно попробовать завернуть код из 22 сообщения в цикл, подать ему 010011 и складывать накопленные Rcode и Rnext в буфер, чтобы потом на экране нарисовать столбики соответствующей длины и посмотреть при какой скорости сигнала код перестанет успевать.

[Manwe]

частота процессора 4МГц

Я делаю для БК0010 3 МГц.

Допустим волны длительность 50мкс

Слишком оптимистично. 50 мкс - это 20 КГц (почти ультразвук). 20000 колебаний в секунду. При частоте дискретизации 40000 КГц это 1,0,1,0,1,0... Такой сигнал просто не считается. А скорее всего, потеряется ещё на этапе передачи.

прочитать короткую полуволну мы успеваем 10 раз

Больше похоже на низкую частоту дискритизации, в районе 18 КГц. Подобной скорости мы уже достигли для стандартной подпрограммы чтения из ПЗУ.

Максимум чего мне удалось добиться при частоте дискритизации 36235 Гц:
ноль кодируем последовательностью 1,0,0
единицу кодируем последовательностью 1,1,1,0,0
Получаем в среднем 4 отсчёта на бит. Итого 9059 бод.

Можно сократить кодирующие последовательности (уменьшить число отсчётов), но для этого придётся снижать частоту дискретизации. Причём, снижать кратно определённым значениям.
На частоте 36235 Гц один отсчёт в WAVе соответствует двум циклам чтения в нашей программе (и не забываем, что иногда случаются ошибки +/- один цикл чтения). Если мы хотим замедлить WAV до трёх циклов чтения, частоту придётся опустить примерно до 24156 Гц.
Допустим, за счёт снижения частоты нам удалось сократить последовательности до 1,0 и 1,1,0 - это в среднем 2,5 отсчёта на бит. Тогда для частоты 24156 Гц получаем 9662 бод (сейчас мы уже умеем 9059 бод с более длинной, а значит более надёжной последовательностью).
Рискнуть с частотой 24156 можно, но это долгий эксперимент - заново ловить и подгадывать. Может быть завтра попробую. Затея кажется рискованной.

Update: Простое изменение частоты с 36235 Гц на 40000 Гц дало ровно 10000 бод, успешно читается той же программой (правда, контрольную сумму не сверял). Думаю, на этом цель достигнута, эксперименты можно прекращать и переходить к производству.
Подпрограмма чтения такая (можно оптимизировать размер, но пока не факт, что лишний BR не отразится на надёжности чтения):

	MOV #177716,R4
	MOV #40,R5
	MOV #10,R3
SIZE:	MOV #24000,R0		; size
DATA:	MOV R3,R2		; read 8 bits
2:		BIT R5,(R4)	; wait for high level
		BEQ 2
				; high level detected
3:		BIT R5,(R4)
		BEQ 5
		BIT R5,(R4)
		BEQ 5
		BIT R5,(R4)
		BEQ 5

4:		BIT R5,(R4)	; wait for high level end
		BNE 4
		SEC		; 1
		RORB (R1)	; load bit C
	SOB R2,2
	INC R1			; next byte

	SOB R0,DATA
	BR CHECK
5:		CLC		; 0
		RORB (R1)	; load bit C
	SOB R2,2
	INC R1			; next byte

	SOB R0,DATA

CHECK:

[blackmirror]

Меня очень смущает что не используется вторая полуволна, если сигнал за время передачи 00 успевает обработать бит, значит можно использовать кодирование 00/11 для 0 и 0000/1111(или даже 000/111) для 1 при той же частоте дискретизации.

[Manwe]

Меня очень смущает что не используется вторая полуволна

Она используется для другого: это время тратится на запись прочитанного бита в память. Я пробовал вместо "0,0" делать просто "0" - всё съезжает, не успеваем записывать прочитанное.
Мне нравится идея с измерением обоих полуволн, но считать/измерить вторую полуволну мы успеем только если она длится "0,0,0" и больше. К уже имеющимся "0,0" нам придётся приписать "0" для кодирования нуля и "0,0" для кодирования единицы. И потом ещё "0,0" - время на запись результата. Было в среднем 8 отсчётов на два бита, станет 7,5 отсчётов. Выигрыш не такой большой (и так уже в 5 раз превзошли максимальную скорость ПЗУшной читалки), а программа усложнится. Я хотел уместить её в область адресов 400-700.

[blackmirror]

Если развернуть цикл, то для чтения 1 бита минимум нужны: SEC / RORB / BIT и BEQ (или BNE), то есть короче импульсы быть не могут.
Поскольку импульс получается чуть длиннее, то если предыдущая пара BIT / BEQ точно отловит его начало, следующая сработать уже не успеет.
Значит минимальный цикл получается SEC / RORB / BIT / BEQ / BIT / BEQ, и длина короткого импульса должна быть меньше времени его выполнения.
Если начало импульса мы поймаем с максимальным опозданием, то вторая пара BIT / BEQ будет выполнять чтение в момент TIME(SEC / RORB) + 3*TIME(BIT / BEQ).
Это определяет минимальную длительность длинного импульса, но хорошо еще взять запас в 1/2*TIME(BIT / BEQ).
То есть для короткого импульса идеально TIME(SEC / RORB) + 3/2*TIME(BIT / BEQ), а для длинного не менее TIME(SEC / RORB) + 7/2*TIME(BIT / BEQ).
Сколько тактов выполняется SEC / RORB? Есть подозрение можно выбрать длительности импульсов 100 и 200 тактов (или 120 / 240 если вернуть обратно SOB) и уложиться в описанные ограничения.