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

Цитата:

---

Сообщение от Pyk

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

---

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

Код:

---

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

---

Цитата:

---

Сообщение от NEO SPECTRUMAN

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

---

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

Код:

---

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

---

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

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

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

Цитата:

---

Сообщение от Pyk

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

---

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

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

Код:

---

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

---

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

Цитата:

---

Сообщение от ivagor

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

---

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

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

По картинкам 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?

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

Цитата:

---

Сообщение от Pyk

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

---

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

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

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