Повышаем качество эмуляции Львов ПК-01

[NEO SPECTRUMAN]

Я правильно понимаю, что при выводе на магнитофон встроенный динамик тоже пищит?

до притом пищит в противофозе
тоесть нельлзя просто взять и тупо сумировать оба сигнала в эммуляторе
тк будет громкость только падать (когда на реале она будет увеличиватся)

pb7	pc0		
0 	0	BEEP	TAPE	B=1 T=1			
0 	1	BEEP	....	B=1 T=0		
1	0	....	TAPE	B=0 T=1		
1	1	BEEP	....	B=1 T=0

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

хотя никто не мешает проинверттировать сигнал бипера

но это не поможет имитировать гипотетический режим полтора битного DAC

3 = pc0=0	pb7=0	TAPE+BEEP
2 = pc0=0	pb7=1	TAPE
1 = pc0=1	pb7=1	BEEP
	
1 = pc0=1	pb7=0	BEEP

[Pyk]

хотя никто не мешает проинвертировать сигнал бипера

А я инвертировал сигнал магнитофона. а не бипера. Хотя бы из того соображения, чтобы при старте на выходах не было постоянной составляющей.
В общем, сейчас на выходе эмулятора будет:

pc0  0  1  0  1
pb7  0  0  1  1
---------------
out  1  2  0  2

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

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

P. S. Как говорится, поспешишь - людей насмешишь. Табличка выше - это как я хотел сделать. А на самом деле у меня сейчас просто выводится звук спикера. Сделаю еще одну сборку чуть позже.

[NEO SPECTRUMAN]

кажется несколько надуманным

до посредственно оно суммируется
потом ищо поэкспериментирую...

[Pyk]

В общем, все-таки все правильно в последней сборке, поправил ошибку в таблице только. Правильная:

pc0  0  1  0  1
pb7  0  0  1  1
---------------
out  1  2  0  2

[ivagor]

Посмотрел тесты DDp (b0000x), хорошо, но мало, и на мой взгляд не очень удобно. Предлагаю более технологичный подход с использованием "магнитофона" (тест). Загружаем (BLOAD"",R), стартуем запись и жмем клавишу. В wav последовательно запишутся резльтаты тестирования команд, которые параллельно будут печататься на экране. Для удобства и скорости тестируется минимум команд, остальные можно свести к этим. Если что забыл - готов дополнить или можно дополнить самому, исходник прилагается. Длительность пересчитываем в такты. Точность не такая уж и плохая, для примера (выгрузил wav из emu, там без торможения) несколько команд (без округления):
NOP - 4.0735; MOV A,A - 5.0704; SHLD - 16.1053; XTHL - 18.1473
Если будет wav с реала, то готов перевести в такты.

[DDp]

Предлагаю более технологичный подход с использованием "магнитофона" (тест).

WAV с реала по той же ссылке (tstsp1_*)

[ivagor]

Спасибо, весьма познавательно, только пока не очень понятно. В такты перевел, но мне кажется что их нельзя использовать точно в таком виде в любых условиях, скорее всего конкретная растактовка будет зависеть и от последнего цикла предыдущей команды. Один вопрос можно считать проясненным - торможение "в целом" однородное, нет такого, что на бордюре так, а в активной области иначе, это было бы слышно и видно по wav (так было у искры-1080).

[ivagor]

По картинкам DDp:
b00000: mov r,r\ out - 22-23 такта
b00001: 3*nop\ mov r,r\ out - 42 такта
b00002: 2*xthl\ nop\ mov r,r\ out - (66-71)? такт
b00003: lhld\ mov r,r\ out - 49-52 такта
Результаты неплохо согласуются с TSTSP1, кроме b00002, с ним что-то сильно не то (или я неправильно измерил, но почему тогда другие совпали?). Может все же картинка b00002.png от другого теста, не от b00002.asm?

[Pyk]

ivagor, мы с DDp уже тестировали выполнение некоторых команд, я делал на скорую руку несколько тестов, тоже с выводом на магнитофон.
В принципе, результаты похожи:
NOP; XRA A - 6,42
MOV R,R - 7,13
XTHL - 32,08
IN; OUT - 16,04
MOV A,M (RAM) - 11,45
MOV M,A (RAM) - 12,47
MOV A,M; MOV M,A (ROM) - 8,91

Если DDp не против, можно выложить ссылку на тесты.

Результаты, в принципе, совпадают, я только брал меньше команд, зато дополнительно тестировал MOV A,M и M,A с операндом в ПЗУ.

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

Сейчас в эмуляторе алгоритм такой: на каждый цикл обращения к ОЗУ добавляется 2,5 такта, к портам - 1 такт.

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

И еще: я пытался теоретически обосновать задержки при обращении к ОЗУ, учитывая циклы обращения видеоконтроллера к ОЗУ в 400 нс через каждые 800 нс и предполагая, что цикл обращения процессора может начаться в произвольный момент времени, а также минимальную длительность цикла процессора в 9/8 от цикла видеоадаптера. У меня получилось в среднем 2,25. Для более точного соответствия реалу цифру пришлось увеличить до 2,5 - видимо, сказываются влияния циклов друг на друга, а может быть и просто напутал в своих прикидках либо опирался на неверные исходные данные...

[ivagor]

Сейчас в эмуляторе алгоритм такой: на каждый цикл обращения к ОЗУ добавляется 2,5 такта, к портам - 1 такт.

Близко к тому, но я бы немного дополнил. Каждая запись в озу примерно +.75 такта. И для полного счастья влияние циклов друг на друга тоже желательно учитывать, при наличии 5 тактных циклов дополнительное торможение уменьшается.
Думаю над результатом b00002, но не могу объяснить.

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

В tstsp1 есть одна ошибка - RET/Y неправильно тестируется. К счастью дополнительный тест не нужен, растактовка RET/Y совпадает с CALL/N, т.к. и там и там три совпадающих цикла чтения (исходно 5+3+3).