Важная информация

User Tag List

Страница 3 из 10 ПерваяПервая 1234567 ... ПоследняяПоследняя
Показано с 21 по 30 из 97

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

  1. #21
    Master Аватар для Manwe
    Регистрация
    06.12.2017
    Адрес
    г. Москва
    Сообщений
    622
    Спасибо Благодарностей отдано 
    12
    Спасибо Благодарностей получено 
    36
    Поблагодарили
    19 сообщений
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от blackmirror Посмотреть сообщение
    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
    Последний раз редактировалось Manwe; 13.04.2019 в 18:05.
    Manwe/SandS

  2. #22
    Member
    Регистрация
    25.11.2015
    Адрес
    г. Москва
    Сообщений
    154
    Спасибо Благодарностей отдано 
    1
    Спасибо Благодарностей получено 
    6
    Поблагодарили
    6 сообщений
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Там нужно измерить всего две константы для самой длинной ветки, а потом подогнать и для других:
    Код:
    	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 раза выше частоты сигнала.

  3. #23
    Master Аватар для Manwe
    Регистрация
    06.12.2017
    Адрес
    г. Москва
    Сообщений
    622
    Спасибо Благодарностей отдано 
    12
    Спасибо Благодарностей получено 
    36
    Поблагодарили
    19 сообщений
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

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

  4. #24
    Member
    Регистрация
    25.11.2015
    Адрес
    г. Москва
    Сообщений
    154
    Спасибо Благодарностей отдано 
    1
    Спасибо Благодарностей получено 
    6
    Поблагодарили
    6 сообщений
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

  5. #25
    Master Аватар для Manwe
    Регистрация
    06.12.2017
    Адрес
    г. Москва
    Сообщений
    622
    Спасибо Благодарностей отдано 
    12
    Спасибо Благодарностей получено 
    36
    Поблагодарили
    19 сообщений
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от blackmirror Посмотреть сообщение
    Ну а почему сразу не перейти на кодирование половиной волны если магнитофоны не справляются? 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»
    Последний раз редактировалось Manwe; 13.04.2019 в 22:09.
    Manwe/SandS

  6. #26
    Member
    Регистрация
    25.11.2015
    Адрес
    г. Москва
    Сообщений
    154
    Спасибо Благодарностей отдано 
    1
    Спасибо Благодарностей получено 
    6
    Поблагодарили
    6 сообщений
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

  7. #27
    Master Аватар для Manwe
    Регистрация
    06.12.2017
    Адрес
    г. Москва
    Сообщений
    622
    Спасибо Благодарностей отдано 
    12
    Спасибо Благодарностей получено 
    36
    Поблагодарили
    19 сообщений
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от blackmirror Посмотреть сообщение
    частота процессора 4МГц
    Я делаю для БК0010 3 МГц.

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

    Цитата Сообщение от blackmirror Посмотреть сообщение
    прочитать короткую полуволну мы успеваем 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:
    Последний раз редактировалось Manwe; 14.04.2019 в 00:07.
    Manwe/SandS

  8. #28
    Member
    Регистрация
    25.11.2015
    Адрес
    г. Москва
    Сообщений
    154
    Спасибо Благодарностей отдано 
    1
    Спасибо Благодарностей получено 
    6
    Поблагодарили
    6 сообщений
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

  9. #29
    Master Аватар для Manwe
    Регистрация
    06.12.2017
    Адрес
    г. Москва
    Сообщений
    622
    Спасибо Благодарностей отдано 
    12
    Спасибо Благодарностей получено 
    36
    Поблагодарили
    19 сообщений
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

  10. #30
    Member
    Регистрация
    25.11.2015
    Адрес
    г. Москва
    Сообщений
    154
    Спасибо Благодарностей отдано 
    1
    Спасибо Благодарностей получено 
    6
    Поблагодарили
    6 сообщений
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Если развернуть цикл, то для чтения 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) и уложиться в описанные ограничения.

Страница 3 из 10 ПерваяПервая 1234567 ... ПоследняяПоследняя

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Похожие темы

  1. Ремонт БК-0011
    от RTeh в разделе БК-0010/0011
    Ответов: 4
    Последнее: 25.10.2013, 13:24
  2. Документация БК-0011
    от pilgrim в разделе БК-0010/0011
    Ответов: 5
    Последнее: 28.04.2012, 20:09
  3. ленин - 1 загрузка с магнитофона
    от sevol в разделе Unsorted
    Ответов: 15
    Последнее: 10.07.2010, 22:49
  4. Загрузка с магнитофона Spectrum +2A
    от Andrey_Ak в разделе Разное
    Ответов: 9
    Последнее: 13.11.2009, 16:14

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •