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

[Manwe]

Сколько тактов выполняется SEC / RORB?

Неизвестно. В теории одно, на практике другое. Я выше приводил код где в комментариях расписана длительность в тактах. Причём, это не чисто теоретические значения, а проверенные в стерильных тестах. Но в итоге в реальной программе всё равно другая длительность. Поэтому я уже не полагаюсь на такты. Помогает только измерение 1000 периодов тестового тона.

Если развернуть цикл

Убрать SOB? Но всё равно после каждых восьми бит останется INC R1 и второй SOB.

[Advertiser]

[Hunta]

удалено

[blackmirror]

Убрать SOB? Но всё равно после каждых восьми бит останется INC R1 и второй SOB.

Из-за этого при приёме первого бита нужно будет выбросить одну пару BIT / BEQ, поскольку срабатывать она никогда не будет, но вполне возможно что разворачивать цикл и не нужно. Если взять частоту чтения бит равной 3М / TIME(BIT / BEQ), для простоты рассуждений пусть это будет 60 кБит, то различить длинные и короткие импульсы мы сможем если их длина отличается минимум на два цикла. Даже если после добавления всяких SEC / RORB / SOB нам придётся кодировать длительность импульсов как 3 / 5 бит, мы получим 15 кбод только за счёт использования дискретизации совпадающей(вернее чуть ниже) со скоростью чтения.

[Manwe]

Из-за инструкций типа SOB синхронизация будет съезжать и выкидывание одной BIT / BEQ этого не скомпенсирует, фронты сигнала поползут и непонятно что получится. Выше я приводил кусок кода, в котором заменил SOB на DEC / BEQ, наивно полагая, что эта пара инструкций будет длиться столько же, сколько INC и BEQ. Но не сходится. Я уже оставил попытки рассчитать всё в тактах. Может быть обращение к порту каждый раз длится разное время. Непонятно.

[Hunta]

А то, что ОЗУ читает ещё и видеоадаптер - учитывается?

[Manwe]

А то, что ОЗУ читает ещё и видеоадаптер - учитывается?

На БК0010 это не критично. Вот на 11-ой да, там каждый третий раз напарываемся на занятую шину.
Делаю для 10-ки потому, что у неё есть автозапуск. Сначала загрузится и запустится читалка, а следом за ней данные. На БК0011 так не выйдет, поэтому пока забил на неё.

[Hunta]

На БК0010 это не критично

(пожал плечами) Ну, я по БК не специалист, не знаю, но проверил бы. Если есть возможность остановить обращение к ОЗУ со стороны видеоадаптера. Прости исходя из того, что неоднократно налетал на то, что утверждения, даже со стороны авторитетов, надо проверять.

[konst_st]

Если есть возможность остановить обращение к ОЗУ со стороны видеоадаптера.

Естественно обращение к ОЗУ со стороны видеоконтроллера влияет на быстродействие процессора, но влияние это на БК0010 вроде как стабильно. Т.е. одни и те же инструкции всегда выполняются за одно и то же количество тактов.

[Hunta]

вроде как стабильно

Ну да, ну да, как обычно - ключевое слово - вроде.

[blackmirror]

Manwe, можно попробовать прямой метод определения правильно ли выбраны длительности импульсов или нет:

	MOV 0, R0
WAIT1: BIT / BEQ WAIT0
WAIT0: BIT / BNE WAIT1
	SEC / RORB / SOB и другие команды обработки
	BIT / BNE RET1
	BIT / BNE RET2
	BIT / BNE RET3
	BIT / BNE RET4
	BIT / BNE RET5
	...
RET5:	INC R0
RET4:	INC R0
RET3:	INC R0
RET2:	INC R0
RET1:	INC R0
	RTS

В идеале для короткого импульса примерно в равных пропорциях должны срабатывать RET1 или RET2, в этом случае его длительность находится где-то посередине между двумя инструкциями BIT, если считать что его начало точно попадает на WAIT0. А если его удлинить до второй инструкции BIT, мы будем часто получать RET2, но когда влезет видеоадаптер может получить RET1 или RET3. Само по себе это не страшно, но нам еще нужно чтобы для длинного импульса не срабатывал ни один переход который срабатывал для короткого. Проверять всё это нужно и для другой полярности сигнала, и для случаев когда все импульсы одного уровня короткие, а другого длинные или наоборот.