ZXMAK2 - Виртуальная машина ZX Spectrum

[ZXMAK]

наверное баян,но все же

к сожалению ничего по бластеру не нашел.
Разбирался в чем причина. Похоже весь вопрос в том что читается из порта #FE. Точно понять логику по фрагменту ADHL сложно, судя по AHDL за этот бит похоже отвечает CBL_IND, а на нем чтото очень хитрое накручено:

CBL_IND			= CBL_CNT7 xor CBL_WA7;

--	CBL_WR			= DFF((DCPP[] == B"10001000"),CLK42,,) & !/IOWR; -- 88

	CBL_WR	= (DFF((DCPP[] == B"10001000"),CLK42,,) & !/IOWR) or
		  (DFF((DECODE.PAGE[7..0] == B"11111101"),CLK42,(CBL_INT_ENA & ACC.ACC_DIR1),) &
	  		!DFF((DECODE.MC_WRITE or DECODE.CAS),CLK42,,/RESET));


	CBL_WAE			= CBL_MODE16 & DFF(!CBL_WAE,!CBL_WR,,CBL_INT);

	CBL_WA[].clk	= !CBL_WR;
	CBL_WA[].ena	= !CBL_WAE;

	CBL_WA[7].clrn	= CBL_MODE & CBL_INT_ENA & (CBL_INT or !CBL_CNT7);
	CBL_WA[7].prn	= (CBL_INT or CBL_CNT7);

	CBL_WA[6..0].clrn	= CBL_MODE & CBL_INT_ENA & CBL_INT;

	CBL_WA[].d		= CBL_WA[] + 1;

дебажил код плеера. Вся загвоздка в том, что он начинает писать в бластер следующие 128 байт, только если по прерыванию из статуса бластера в порте #FE прочиталась 1. Т.к. по документации на этот флаг, он отражает какая половинка буффера бластера сейчас проигрывается, плеер с такой логикой просто не может работать, но работает. AHDL только подтверждает, что логика этого бита не простая.

Может ктото знает почему плеер на каждую половину буффера ожидает в порте #FE единичку?

Пробовал разные догадки, но они не подтвердились. Максимум что удалось добиться - звук играет с формальным соответствием документации, но в прерывании костыль - подставлять в #FE состояние INT. Частота, скорость при этом нормальные, но слышно постоянное потрескивание от сбоя синхронизации...

Также, не получилось добиться нормальной работы прерываний от бластера, сразу после сборса. При этом в порт 4e пишется #FF, т.е. частота 109 кГц с прервываниями. Но спринтер от такого режима начинает себя неадекватно вести - курсор в навигаторе бешенно мерцает, задержек на детектирование винчестеров нет - система без задержек за секунду в навигатор грузится... Пока приходится блокировать прерывания в таком режиме...

[palsw]

ZXMAK, может на реале что то можно прояснить - тесты какие то по запускать?

[ZXMAK]

Смотрел реализацию акселей, их можно немного ускорить, доработкой эмуляции Z80. Для этого можно добавить регистрацию кастомных обработчиков для нужного опкода. Тогда не нужно будет в каждом цикле проверять опкод.

---------- Post added at 01:01 ---------- Previous post was at 00:52 ----------

ZXMAK, может на реале что то можно прояснить - тесты какие то по запускать?

да сразу так и не придумаешь судя по AHDL, для этого бита какой-то дополнительный счетчик заводится и много флагов учавствует, для чего это так хитро закручено даже не представляю.

Можно попробовать проверить несколько моментов - сохраняется ли этот флаг при повторном чтении из #FE? Есть предположение, что он из прерывания один раз читается, 1-ка если прерывание от бластера пришло. В этом случае при повторном чтении флаг будет меняться.
Второй вариант - проверить как долго этот флаг не меняется при чтении сразу после прерывания. Идея в том что он может некоторое время после прерывания от бластера быть в 1-ке, после чего переходить в обычный режим - отображать состояние старшего бита счетчика.
Третий - проверить есть ли разница при чтении из #FE в прерывании от бластера и сразу после завершения обработчика. Возможно плис отслеживает вход/выход в обработчик.

Думаю второй вариант наиболее вероятный, счетчик возможно предназначен чтобы дать задержку сигналу, чтобы его обработчик прерывания успел прочитать...

C 16-битными режимами тоже не все понятно, пытался по фрагменту AHDL понять как в 16-битном режиме читаются читаются сэмплы из буффера - как-то хитро все, есть предположение, что это старший байт адреса куда запись производится. Но чтото не верится в такой режим...
Предположение основано на вот этих строчках:

CBL.wraddress[] = ((!A[15..8]) & !CBL_INT_ENA) xor CBL_WA[];

CBL_WA завязан на бите включения 16 битного режима
А что значит !A[15..8] - толи это константа, толи значение адресных линий- хз, я в AHDL практически не понимаю.
Чисто интуитивно по описанию счетчики угадываю и из этого строю предположения как это работает
тут же вроде есть специалисты по AHDL, может помогут разобраться?

Нужно будет попробовать сгенерить wav файл с 1,2,3,4,5,... 0,0,0,0... 1,1,1,1,1... 2,2,2,2 по 128 байт и посмотреть что плеер на бластер выдает

[ZXMAK]

Получилось добиться стабильной синхронизации в плеере спринтера для обоих режимов - 8бит/моно и 8бит/стерео.
Для этого из порта #FE читается бит прерывания, который устанавливается при переходе между банками буффера бластера и сбрасывается на средине банки или если произведена запись в бластер.

Если плеер начал играть с нормальной синхронизацией, то держит ее стабильно.
Но при запуске плеера, синхронизация не всегда корректная. Т.е. плеер не всегда синхронизируется начиная писать в бластер.
Может и на живом спринтере так-же?

[palsw]

ZXMAK,

Может и на живом спринтере так-же?

8 бит всегда играет нормально от начала и до конца.
16 бит вначале играет нормально,потом буфер глючит - примерно через 1 мин и начинаются заикания.Если поставить ключ - h - тогда всегда играет нормально от начала и до конца

[ZXMAK]

ZXMAK,

8 бит всегда играет нормально от начала и до конца.
16 бит вначале играет нормально,потом буфер глючит - примерно через 1 мин и начинаются заикания.Если поставить ключ - h - тогда всегда играет нормально от начала и до конца

ну с 16 бит пока неизвестно в каком формате они в бластер пишутся.
Т.е. на 8 битах плеер всегда запускается без сбоев синхронизации?

И еще вопросик - вот эти Demo7 и Demo8, они на риале тоже так работают что звук затухает и появляется опять при нажатии кнопки? Или это какой-то баг?

[Advertiser]

[palsw]

ZXMAK,

Т.е. на 8 битах плеер всегда запускается без сбоев синхронизации?

да

[ZXMAK]

Сделал тестовый билд 2.9.3.3: https://drive.google.com/file/d/0B3U...ew?usp=sharing

Ковокс бластер работает с плеером, как 8 битный, так и 16 битный звук.
Не уверен что прерывания от бластера реализованы именно так как в риале, но плеер во всех режимах работает нормально.
Есть проблема со 109 кГц звуком, система часто включает этот режим, но из-за каких-то особенностей с прерываниями, прерывания бластера начинают мешать системе. Поэтому в этом режиме прерывания и звук отключены, хотя счетчик продолжает работать (нужно для синхронизации плеера).

Как выяснилось, бластер использует 512 байт буффер для 16-битного звука. Не совсем ясно как в этом режиме можно писать в старшую банку через порт #4F. Пока сделал чтобы при записи через порт, запись шла в неактивную банку...

[ZXMAK]

Ну для начала норм. Хотелось бы конечно статистику, и даже по возможности типа "сколько рисуется второй экран", но для этого нужны наверное скрипты для эмуля, чтобы можно было ставить условия на память и порты.
А эта Debug Info рисуется только поверх экрана? Сбоку можно?

хотел прикрутить, но тут загвоздка. Инфа про halt будет бесполезной и вот по какой причине - чтобы узнать когда хальт сработал, достаточно точку останова на хальте поставить. По такту кадра можно увидеть на каком такте он сработал, соответственно будет видно сколько осталось.
Но... хальт в эмуляторе в течении кадра может срабатывать несколько раз. Например если прийдет прерывание не от экрана. И эти прерывания обычно к экрану никак не привязаны.

Тут еще один момент. Если хальт еще не произошел, то показывать в отладчике нечего. А если уже произошел, то ничего не мешает поставить бряку на хальт и увидеть на каком такте он сработал.

Получается что постоянно показывать когда хальт произошел не имеет смысла. Можно в лог писать такт каждого хальта, чтобы без остановок прокрутить код и посмотреть по логу статистику. Но на постоянно такое делать нет смысла - лог будет забиваться. Такое можно прикрутить разве что как специальный режим отладчика.

Вообще, ZXMAK2 - единственный эмулятор отладчик которого позволяет в любой момент поменять текущий такт кадра и тайминги при этом не нарушаются. Все будет выполняться также, как будто код сам попал на заданный такт кадра.
Чтобы поменять такт кадра достаточно кликнуть в отладчике на строчке frmT=xxxx. В этой строчке отображается текущий такт кадра.

При отладке мультиколора для contended memory, я столкнулся с тем, что ни в одном эмуляторе невозможно нормально просимулировать выполнение кода на нужном такте. Во всех эмуляторах код работает корректно, только если дошел до прерывания своим ходом. Воздействие на счетчик тактов приводит к некорректной обработке прерываний. Что обидно, это происходит незаметно и обнаружить можно только увидев что прерывание не сработало в расчетный момент. Как пример Spectaculator, Spin и т.п. Поэтому в ZXMAK2 я постарался реализовать полноценную поддержку изменения счетчика тактов в отладчике на лету.

Экспериментируя с halt, обнаружил что в StartTact, отображаемый в DebugInfo, не всегда показывает ожидаемое значение. Задумывалось это значение как первый такт кадра, на котором процессор уже мог обработать прерывание. Из-за особенностей цикла эмуляции, получилось что значение в StartTact попадает часто уже после обработки сигнала прерывания. Что вобщемто тоже удобно.
Но... обнаружилось что иногда значение в StartTact меньше, чем в начале обработчика прерывания, после небольшого исследования выяснилось, что в StartTact может попасть значение такта на префиксном цикле Z80 (т.е. после обработки префикса, но до обработки самой префиксированной инструкции).
Т.е. следует учитывать, что StartTact отображает первый такт кадра не только в начале полного цикла, но и в начале цикла обработки префиксной инструкции.

[ZXMAK]

Как вам новый дизайн отладчика?


Все окошки можно сайзить, перетаскивать, докать, открывать, закрывать.
Может чтото перекрасить?

Нужны иконки 16x16 для кнопок и менюшек в отладчике , может ктото нарисует?