покопался в коде AY8910, обнаружился баг в миксере, который тянется еще с первых версий ZXMAK :)
Пофиксил, хотел сделать релиз, но codeplex сейчас падает при попытке создать новый релиз.
Вид для печати
покопался в коде AY8910, обнаружился баг в миксере, который тянется еще с первых версий ZXMAK :)
Пофиксил, хотел сделать релиз, но codeplex сейчас падает при попытке создать новый релиз.
Зарелизил тестовую версию 2.8.6.7 TESTSYNC.
В эту-же версию вошли такие изменения:
- исправлен миксер и шум для AY8910;
- много разных фиксов и оптимизаций для стабильности синхронизации;
- изменен цикл эмуляции;
- исправлена поддержка 100 Гц дисплеев (и не только);
- исправлены Sprinter ULA и Memory, чтобы не падали если нет контроллера дисковода и т.п.;
- изменен механизм загрузки плагинов, теперь плагины грузятся из сборок перечисленных в plugins.config;
- добавлен отладчик GDB-Z80 server;
- много кода отрефакторено;
Тут довольно сильно затронут механизм синхронизации, поэтому к стабильным релизам пока относить не буду. При синхронизации от видео, теперь вызывается Present для каждого кадра. Нужно потестить как новый механизм работает на разных машинах.
Значительно изменился граф debug info. Теперь тут есть сетка, по горизонтали 25 фреймов, по вертикали 1 мс (белая сетка) или 10 мс (красная сетка).
Расчет данных для графа довольно тяжеловат, поэтому при включении debug info эмулятор кушает дополнительное процессорное время.
Просьба потестить как работает на разных машинах и выложить скрины с включенным debug info при синхронизации от видео.
Заодно просьба написать отзывы по поводу нового звука AY. :) Т.к. серьезно потестить исправленный вариант времени не было.
http://savepic.su/4846048.png
Легенда по графу:
Зеленый график - время между отображением кадров (Present);
Красный график - время затраченное на эмуляцию фрейма (теперь не включает в себя время на рендеринг текстуры и запись буфера в звуковую карту);
Желтая граница - время периода частоты обновления дисплея;
Сиреневая граница - время периода 50 Гц;
Белая сетка - вертикальный масштаб 1 мс на клетку, горизонтальный 25 кадров;
Красная сетка - вертикальный масштаб 10 мс на клетку, горизонтальный 25 кадров;
MinT/AvgT/MaxT - минимальное/среднее/максимальное время между отображением кадров (Present);
AvgE - среднее время эмуляции кадра;
MinL/AvgL/MaxL - минимальная/средняя/максимальная латентность планировщика операционной системы, отражает разницу между запрошенным временем на Thread.Sleep и реальным временем, через которое система вернула управление. Больше 0 - плохо, т.к. будут пропуски кадров. Сильно меньше нуля тоже плохо, т.к. процессор больше времени работает в холостую. Оптимальное значение -0.001...-1.000 мс
Значения вычисляются за период графа - 150 кадров.
А на дисплеях с 60 Гц, сейчас, с любыми настройками, будет не очень?
http://i.imgur.com/0gWCAPu.gif
для 60 Гц дисплея нужно интерполяцию кадров делать, чтобы получить плавный ресэмплинг. Это второй шаг. Сейчас задача добиться хорошей синхронизации.
Сейчас обновление на каждом кадре производится какраз специально для того, чтобы в дальнейшем обновлять кадры с временными коэфициентами для интерполяции.
По гифке не очень понятно, насколько стабильно держится AvgT? Что это за выброс в конце гифки?
Судя по времени обновления на графе, частота кадров реально 59.952 Гц. Если это так, то ресэмплинг сбивается, т.к. ориентируется на частоту, которую говорит DirectX - 59,000 Гц. Первое наблюдение, когда частота кадров дисплея не соответствует заявленной системой.
В реальности действительно так дергается?
выкладываю все тесты на 2.8.6.7.
скриншот с эмуляции Спринтера:
http://savepic.su/4844482.jpg
Обновил до версии 2.9.0.38062
Исправлена и переработана эмуляция AY8910 и звука.
Теперь для ау используется передискретизация.
Исправлены миксеры - общий и АY.
Качество звука выросло в разы :)
Частоту ay можно задавать любую (в разумных пределах), правда пока только вручную через файл конфигурации машины zxmak2.vmz
Интересно услышать ваше мнение по поводу качества звука в новой версии по сравнению с unreal например :)
Звук не слушал, но заглянул в исходники. Очень странный микшер- сложение сразу двухканальных семплов. Само по себе оно нормальное, но вот ненормированные коэффициенты в m_mixerPreset могут дать переполнение при сложении, что чревато переползанием левого канала в правый и клиппингом в правом канале (или наоборот, не суть важно).
Раз у тебя есть отличное событие OnVolumeChanged, заюзай его по полной- считай таблицу в 32768 элементов примерно следующим способом:
и потом в коде:Код:for (int idx = 0; idx != 32768; ++idx) {
int volA = vol_table[idx & 31] * volume / 65535;
int volB = vol_table[(idx >> 5) & 31] * volume / 65535;
int volC = vol_table[(idx >> 10) & 31] * volume / 65535;
int levAL = m_mixerPreset[0];
int levAR = m_mixerPreset[1];
int levBL = m_mixerPreset[2];
int levBR = m_mixerPreset[3];
int levCL = m_mixerPreset[4];
int levCR = m_mixerPreset[5];
int volL = (volA * levAL + volB * levBL + volC * levCL) / 300;
int volR = (volA * levAR + volB * levBR + volC * levCR) / 300;
m_volTable[idx] = volL + (volR << 16);
}
Вообще, mixA/mixB/mixC тоже можно считать практически параллельно, но это уже несколько сложнее.Код:var sample = m_volTable[(mixC << 10) | (mixB << 5) | mixA];
UpdateDac(m_lastTime, (ushort)sample, (ushort)(sample >> 16));
Для спринтера это нормально, у него графика прилично процессор ест, нужно оптимизировать.
Кстати как работает ковокс на спринтере? Насколько помню, у спринтера ковокс с буффером. С новым звуком добавить его поддержку думаю будет несложно. У SoundDeviceBase появились методы UpdateDac, принимающие время относительно кадра (от 0 до 1) и метод получающий текущее время кадра (тоже от 0 до 1). Т.е привязки к текущему такту нет - можно сразу пачками апдейты делать, главное время вычислить и с убывающим временем не обновлять :)
UpdateDac теперь несколько вариантов для signed 16 бит и для unsigned 16 бит.
---------- Post added at 12:33 ---------- Previous post was at 12:20 ----------
\
спасибо, я тоже это заметил, но пока эту часть не трогал, нужно будет пофиксить.
при использовании Акселя в Альтере, проц, можно сказать, прохлаждается.Цитата:
Для спринтера это нормально, у него графика прилично процессор ест, нужно оптимизировать.
есть "документация" и некоторые исходники того же ваф плеера. если в кратце, ковокс буферизированный, с возможностью задавать битность (8 или 16, но тут могу ошибиться).Цитата:
Кстати как работает ковокс на спринтере?
Цитата:
Covox с буферным ОЗУ.
Подключение буферного ОЗУ осуществляется по следующей схеме:
http://zx-pk.ru/attachment.php?attac...1&d=1422373114
Счетчик работает на частоте 15 или 22 килогерца, в зависимости от состояния порта конфигурации
Covox-а. Адрес мультиплексируется на момент записи в порт из процессора, все остальное время данные
из ОЗУ записываются в регистр ЦАП-а.
Ввод байтов в буферное ОЗУ осуществляется командой OTIR (OUTI), что позволяет ускорить вывод
звука и создать достаточно большие паузы для работы других частей программы. Так как при использовании
команды OTIR регистр B (который попадает на A15..A8 процессора) уменьшается, для нормальной работы
CBL счетчик считает «назад».
Для контроля за работой Covox-Blaster-а используется бит 7 порта #FE, в который выводится старший
бит счетчика. Блок ОЗУ 256 байт условно разбит на две банки по 128 байт, и бит 7 порта #FE указывает
какая из банок ОЗУ выводится в ЦАП в конкретный момент времени. Это используется программой вывода
для определения, нужно ли подгружать следующие 128 байт в буфер.
В плате Sp2000 COVOX-Blaster включен в основную прошивку и включается через порт управления
CBL - #4E. Запись в этот порт значения #80 приводит к включению режима CBL, #00 - включение
обычного COVOX-а. Другие биты порта #4E имеют значение и их следует выставлять в 0 для получения
описанного выше режима CBL. В дальнейшем этот порт будет устанавливать режимы Stereo, 8/16-bit и
частоту.
используется ли этот Covox-Blaster на других моделях спектрума? или это девайс именно Cпринтера? Есть ли софт на котором его можно потестить?
Из описания не все ясно, например:
1) если начать писать по адресам банки которая сейчас выводится, что произойдет? или вывод по этим адресам блокируется? :)
2) какое назначение для ковокс-бластера имеют остальные биты порта #4E? Какими битами устанавливается режим 8/16, стерео/моно? И в каком формате данные из озу попадают на цап в этих режимах? Ведь если по одному байту устанавливать 16 битный цап, то будет треск...
3) как происходит переключение в режим обычного ковокса? задействуется ли в этом механизме озу или просто выход порта напрямую переключается на цап?
ZXMAK, данных по работе CBLа у меня мало. я не разбирался пока в работе звука. То, что Covox-Blaster фишка чисто Спринтера, это точно. на профи или там на атм или скорпе такого не было. Как оно работает точно не знаю, не изучал ещё вопрос, но вот есть несколько исходников и бинаров. Во1х, есть дока от Ивана:
Скрытый текст
Цитата:
;***********************************************************************
;
; Пример программы для Covox-Blaster-a.
;
;***********************************************************************
CLEAR_COVOX: ; программа для очистки буфера ОЗУ и
; отключения звука
LD A,80H ; значение, эквивалентное нулю на выходе Covox
LD BC,0FBH ; порт Covox-Blaster-à
CLEAR_CBL:
OUT (C),A
DJNZ CLEAR_CBL
XOR A
LD (SND_P),A ; установить в страницу звука 0 (нет звука)
RET
;***********************************************************************
SOUND_START: ; программа инициализации Covox-Blaster-à
;=======================================================================
; здесь должна располагаться программа, которая
; произведет расчет первой страницы данных для COVOX-áëàñòåðà è
; адреса данных. Страница и адрес соответственно в регистры A и HL
;=======================================================================
LD (SND_A),HL ; запомнить состояние адреса звука
LD (SND_P),A ; запомнить новую страницу WAV-данных
RET
SND_A: DB 0
SND_P: DW 0
;***********************************************************************
SOUND:
PUSH AF
LD A,(SND_P) ; проверка, что страница WAV-данных не равна 0
AND A
JR Z,RET_ALL ;иначе выход -- нет звука
PUSH HL
SND_MORE:
IN A,(0FEH) ; бит 7 порта #FE указывает состояние 7-го бита
; счетчика выводимого байта (банк 0/1)
XOR 0 ; запомненное состояние Covox адреса
COV_ADR EQU $-1
AND 80H ; проверить, переключение банки 128 байт
JP NZ,NO_LD_SND ; если изменения не было, вернуться.
LD A,(SND_P)
AND A
JR Z,RET_ALL
PUSH DE
PUSH BC
LD A,(COV_ADR) ; взять адрес Covox-а.
CPL ; инвертировать
LD B,A ; запомнить в B
LD HL,(SND_A) ; взять адрес WAV-данных
LD C,0FBH ; порт Covox-Blaster-а
IN A,(PAGE3) ; запомнить состояние PAGE3
LD E,A
LD A,(SND_P) ; взять номер страницы WAV-данных
OUT (PAGE3),A ; переключить PAGE3
LD D,16 ; повторять 16 раз
L_DDX:
OUTI ; выводить в Covox-Blaster
OUTI ; (OUTI работает несколько быстрее, чем OTIR)
OUTI
OUTI
OUTI
OUTI
OUTI
OUTI
DEC D
JR NZ,L_DDX
LD (SND_A),HL ; запомнить состояние адреса звука
LD A,H ; проверить, что адрес не дошел до конца страницы
AND A
JP NZ,NO_SNDP ; если не дошел, идти на выход
LD A,E ; вспомнить страницу PAGE3
OUT (PAGE3),A
;=======================================================================
; здесь должна располагаться программа, которая
; произведет рассчет новой страницы данных для COVOX-бластера и
; адреса данных. Страница и адрес соответственно в регистры A и HL
;=======================================================================
LD (SND_A),HL ; запомнить состояние адреса звука
LD (SND_P),A ; запомнить новую страницу WAV-данных
JR NO_SNDP1
NO_SNDP:
LD A,E ; вспомнить страницу PAGE3
OUT (PAGE3),A
NO_SNDP1:
POP BC
POP DE
NO_LD_SND:
POP HL
RET_ALL:
POP AF
RET
[свернуть]
Во2х, есть ваф плеер собранный и в виде исходников. Переключение режима 8бит и 16 бит, сюдя по плееру, осуществляется так:
Скрытый текст
Цитата:
...
LD B,80h+10h ; CBL-mode8 & INT ENABLE
JR Z,NEXT_1
CP 16
LD B,80h+20h+10h; CBL-mode16 & INT ENABLE
...
NEXT_1:
LD A,(0C016h)
CP 1
JR Z,NEXT_2
CP 2
SET 6,B ; set stereo-mode
JR NZ,ERROR2
NEXT_2:
LD A,B
LD (CBL_MODE),A
LD BC,(0C018h) ; частота
LD HL,7000
LD DE,9000
CALL Test_DIAP
EX AF,AF'
LD A,8 ; 8khz
EX AF,AF'
JR Z,NEXT_3
LD HL,10000
LD DE,12000
CALL Test_DIAP
EX AF,AF'
LD A,9 ; 11khz
EX AF,AF'
JR Z,NEXT_3
LD HL,15000
LD DE,17000
CALL Test_DIAP
EX AF,AF'
LD A,10 ; 16khz
EX AF,AF'
JR Z,NEXT_3
LD HL,21000
LD DE,23000
CALL Test_DIAP
EX AF,AF'
LD A,11 ; 22khz
EX AF,AF'
JR Z,NEXT_3
LD HL,30000
LD DE,34000
CALL Test_DIAP
EX AF,AF'
LD A,12 ; 32khz
EX AF,AF'
JR Z,NEXT_3
LD HL,42000
LD DE,46000
CALL Test_DIAP
EX AF,AF'
LD A,13 ; 44khz
; LD A,15 ; 109khz
EX AF,AF'
JR Z,NEXT_3
LD HL,50000
LD DE,60000
CALL Test_DIAP
EX AF,AF'
LD A,14 ; 54khz
EX AF,AF'
JR Z,NEXT_3
JP ERROR3
NEXT_3:
EX AF,AF'
LD C,A
EX AF,AF'
LD A,(CBL_MODE)
ADD A,C
LD (CBL_MODE),A
JP PLAY_FILE
...
LD A,0
LD BC,78
OUT (C),A
LD BC,79
LD A,80h
FILL_L0:
OUT (C),A ; забить во все 80h
DJNZ FILL_L0
LD HL,0A000h ; CLEAR PAGE_IM2
LD DE,0A001h
LD BC,100h
LD (HL),0
LDIR
DI
LD DE,PLAY
LD (0A0FFh),DE ; IM2_ADRESS
LD A,0A0h
LD I,A
IM 2
LD A,(CBL_MODE)
LD BC,78
OUT (C),A
и т.д.
[свернуть]
прямо сейчас большего сказать не смогу. сам плеер есть. так же он есть в доступе в теме спринтера в первом посте, там ссылка на рабочий архив с настройками эмуля и образ винта, на котором есть плеер (но нет ваф вайлов).
по указанной тобой процедуре идёт проверка, попадает ли взятое значение из заголовка ваф файла под выбранную частоту. если посмотреть, то:
как то так. т.е. все настройки Ковокса через порт 4Eh.Цитата:
LD BC,(0C018h) ; частота
LD HL,7000
LD DE,9000
CALL Test_DIAP ; если в диапазоне, тогда
LD A,8 ; 8khz
JR Z,NEXT_3
...
NEXT_3:
LD C,A
LD A,(CBL_MODE)
ADD A,C
LD (CBL_MODE),A
; а там дальше ты уже видел:
...
LD A,(CBL_MODE)
LD BC,4eh
OUT (C),A
собственно, во вложении отдельно сам плеер.
а тут полный архив с настройками и образами. Скопируй в образ для примера какой-нить ваф вайл, примонтируй образ в эмуль, запусти эмуль как Спринтер и там уже все проверки...
https://www.dropbox.com/s/7lxe0jrmdj..._work.rar?dl=0
так что, ктото оценивал качество нового AY в ZXMAK2?
Есть ли разница с риалом или один в один как риал играет? :)
Реала уже давно нет, но на слух очень хорошо. :-)
попробовал запустить эмулятор с выводом звука на звуковуху с частотой дискретизации 176,4 кГц, впринципе звучит также, но не совсем :smile:
В некоторых мелодиях можно заметить небольшие ньюансы на высокочастотных звуках и шуме, кое-где даже провляются эффекты не заметные на 44,1 кГц, плюс на 176 кГц появляется едва заметная субъективная разница, которую в словах можно описать как "более чистый звук" :smile:
А на 192 кГц звук еще чище :biggrin: Кстати нагрузка на процессор заметно при этом практически не меняется :)
Кому интересно, сейчас частота задается в двух местах - при создании DirectSound, там же указывается размер буфера и его тоже нужно корректировать (вместо 882 нужно указать частоту/50). А второе место в SoundDeviceBase при вызове метода ApplyTimings.
Впринципе можно прикрутить установку частоты дискретизации звуковухи в настройки, но думаю пока это немного опасно будет, т.к. хорошо поддерживаются только частоты кратные 50 Гц.
Кстати выяснился еще один интересный эффект. Для тестов звука понадобилась запись Stereo Output, но как выяснилось дефолтный драйвер Win 7 не поддерживает этого, почитал что пишут - оказалось нужно устанавливать родной драйвер. У меня звуковуха встроенная на материнку (какой-то риалтек), установил и был немного удивлен результатом...
Кроме того что появилась возможность включить запись того что сейчас играет в системе, в эмуляторе при синхронизации от звуковухи синхра стала держаться на 50 Гц без провалов... :)
Для теста адекватности эмуляции AY рекомендую музон из второй части демы Binary Love (Authors/Joe/Binary Love 2.ftc в коллекции Бульбы). Там весьма зубодробительное сочетание ВЧ тона и огибающей- хорошо слышно разницу между разными режимами эмуляции и фильтрации.
Можешь сверяться с http://sovietov.com/app/ayumi/ayumi.html как с эталоном звучания.
ZXMAK,прикрути п/ж сохранение в SCL
сохранение в SCL и hobeta специально и преднамеренно вырезано, т.к. это очень проблемный формат, сохранение в нем портит образы, т.к. в SCL не предусмотрено сохранение секторов которые могут содержать важные данные. Ну и кроме того поддержка сохранения проблематичная, т.к. код эмулятора не должен разбираться какие сектора к какому файлу относятся, тем более что записанная на диске информация часто не соответствует действительности.
SCL - это мертвый формат, сохранение в нем часто приводит к порче софта, причем определить испортился образ при сохранении или нет невозможно. А смысла в нем нету, TRD в ZIP архиве меньше места занимает и с ним меньше проблем.
---------- Post added at 23:47 ---------- Previous post was at 23:23 ----------
спасибо, при детальном исследовании BIN LOVE part 2, сразу обнаружилось что есть проблема с миксером AY. Вначале мелодии ничего не слышно, хотя в это время идут переливы. Сразу определить в чем проблема не удалось, чтото странное. Вот так у меня микшируются генераторы, шум и огибающая:
тут три бита m_stateGen содержат состояние выходов делителей A, B, C генератора.
А три бита m_stateNoise содержат состояние генератора шума (одинаковое).
Делаем ИЛИ с управляющими битами регистра миксера и получаем единицы для отключеных каналов.
Тут делаем И между выходами генератора и генератором шума (отключенные каналы в 1 и не влияют на результат)Код:var outGen = m_stateGen | (m_controlChannels & 7);
var outNoise = m_stateNoise | ((m_controlChannels & 0x38) >> 3);
Тут мы берем вначале амплитуду 0, потом проверяем состояние outMix - если 1, то берем амплитуду из регистра амплитуды.Код:var outMix = outGen & outNoise;
Далее проверяем если в амплитуде включен старший бит, то берем амплитуду из из генератора огибающей.
mixA + 1 - это рудимент, предназначался чтобы использовалась большая амплитуда из 32 (на баг не влияет)
чтото тут неправильно :smile:Код:var mixA = 0;
if ((outMix & 0x01) != 0)
{
mixA = (m_volumeA & 0x1F) << 1;
mixA = (mixA & 0x20) == 0 ? mixA + 1 : m_bendVolumeIndex;
}
Если инициализировать mixA=0x0F, то переливы в BIN LOVE появляются, но дальше по мелодии вместо нормальных эффектов возникает какие-то шумовые эффекты :smile:
Может ктото разбирается генераторах AY, подскажет в чем ошибка?
почему-же, вовсе не так, для обычных записей (без приколов с хитрой записью секторов, маркеров и т.п.) TRD - отличный формат, ну и заодно позволяет сразу записать на диск чтото, без танцев с бубном :smile:
---------- Post added at 00:13 ---------- Previous post was at 00:08 ----------
посмотрел свежим взглядом на код миксера, вот это я намудрил с битами :)
Поправил, чтобы соответствовало задуманному:
но всеравно переливов не слышно, судя по экспериментам, BIN LOVE на этом фрагменте как-то хитро генерирует звук переключением бита огибающей в регистре амплитуды. Причем так что после переключения громкость меняется на противоположную, а у меня почему-то остается той-же :v2_conf2:Код:var mixA = 0;
if ((outMix & 0x01) == 0)
{
mixA = (m_volumeA & 0x1F) << 1;
mixA = (mixA & 0x20) == 0 ? mixA & 0x1F : m_bendVolumeIndex;
}
Для обычных файлов и SCL - отличный формат. 97% игр/софта не используют удалённые файлы или "якобы свободные" сектора, которые потом в SCL не сохранятся.
На рабочих TRD приходится иногда MOVE делать (не надо мне рассказывать, что нечасто, я на реале долго кодил), а в SCL сохранил - уже спрессовал место.
---
А ещё и с TRD бывают извращения - больше 160 дорожек, обрезанные по дорожке/сектору, всякие чешскопольские умельцы извращаться умеют...
Из за таких 97% мне не раз пришлось повозиться, чтобы понять почему программа глючит - с виду образ рабочий, все запускается, но глючит. Обычно этим буты страдают
Когдато по размеру трд определялось сколько сторон у диска, но в zxmak это пришлось отключить из за появления вот таких инвалидных трдшек :)
Всякие "скрытые" буты, которые сидят на 0 дорожке, конечно, не подходят для SCL, но почти все остальные годятся! Для образов без boot-ов надо сделать, как в Unreal - догружать туда пользовательский boot.$B
Да и не обязательно софт будет что-то на диск писать - куча игр, демки вполне могут храниться в SCL и не источать неприятных запахов.
тогда прикрути выбор из зипа с хобо файлами какие из них на диск пихать ... когда их в зипе штук сорок .. а то достало каждый раз кидать зип
---------- Post added at 01:57 ---------- Previous post was at 01:55 ----------
ну типо галочку поставить что монтировать.
хм, действительно дельное предложение :smile:
как разберусь с AY и синхронизацией (я ее опять хочу переделать, т.к. текущий вариант не позволяет железобетонную синхру сделать), займусь дискетами, нужно еще прикрутить поддержку образов с аппаратно считанными raw дорожками в mfm.
Еще думаю встроенный snippet compiller прикрутить, c подсветкой и т.п., чтобы компилить небольшие куски кода и отлаживаться по исходному коду. Компилятор думаю использовать сторонний, сделать настройку конфигураций для разных языков и дергать внешний компилятор через командную строку... :)
---------- Post added at 01:04 ---------- Previous post was at 01:01 ----------
так чтение SCL и хобет и так работает :)
Убрана только запись, т.к. с ней много проблем было, плюс опасность потерять сектора при записи.
спс и прикрути поддеожку записи с мафона.
---------- Post added at 02:08 ---------- Previous post was at 02:06 ----------
в старых версиях вроде было не помню .. ща нема..
---------- Post added at 02:10 ---------- Previous post was at 02:08 ----------
в спекуляторе есть чтение с кассеты у тя нема. надо..
---------- Post added at 02:17 ---------- Previous post was at 02:10 ----------
раньше была такая шляпа как плавное затухание лампы на дисковде.. не в одном эмуле не видал.. а на реале есть)))
---------- Post added at 02:46 ---------- Previous post was at 02:17 ----------
ну чтоб визуально видно было.. помню ета хрень в ревю публиковалась
в каком смысле чтение с магнитофона? чтение и так есть...
В новой версии можно будет настраивать порт, маску порта и номер бита для бипера и магнитофона. Можно будет добавить в машину два бипера, один будет бипером, второй будет воспроизводить то что на запись в магнитофон идет :)
Вместо разных биперов для каждой машины, будет один с разными настройками порта.
Вобщемто это уже реализовано и закомичено вместе с фиксом для исправления частоты AY (в последней версии она в 2 раза больше в конфигурации задавалась), но пока релизить не буду - нужно баги с AY и синхронизацией пофиксить.
Кстати с портами беда - когда стал настройки портов для машин прописывать, оказалось что для многих машин они просто общие используются. Покопался в интернете, оказалось что найти информацию о том как декодируются порты для разных машин практически невозможно. В unreal с этим вообще беда, там порты вручную подогнаны с разными костылями, чтобы как-то работало с разным софтом.
Даже информацию про декодирование портов AY в пентагоне найти невозможно. Пришлось сидеть разбираться по схеме, которую кстати тоже проблематично найти (оригинал схемы В.М.Г. так и не нашел). И как выяснилось, в большинстве эмуляторов выборка портов AY для пентагона реализована неправильно.
Если у когото есть точная информация о том как происходит выборка портов (любых) на разных машинах, напишите пожалуйста сюда. Эта информация очень нужна - нужно разгрести бардак с портами.
чтение в реале я типо майфун подклю
чил
---------- Post added at 03:31 ---------- Previous post was at 03:24 ----------
раньше была такая шляпа как плавное затухание лампы на дисковде.. не в одном эмуле не видал.. а на реале есть)))
---------- Post added at 03:33 ---------- Previous post was at 03:31 ----------
забубень
прикрутил эмулятор AY от unreal :biggrin:
Вся логика, счетчики и миксер из unreal 038, не переносил только ресэмплинг - используется старый SoundDeviceBase, хотя он тоже на базе кода unreal основан.
Эмулятор AY от unreal прожорливый оказался, жрет чуть больше времени чем эмуляция всего остального железа занимает. На звуковухе со 176 кГц звуком неплохо работает :smile:
Судя по коду unreal, огибающую тоже нужно миксить как и генератор с шумом. Попробую зафиксить родной zxmak эмулятор AY, он поменьше процессор кушает :smile:
Вобщем в следующей версии можно будет через unity.config переключать какой эмулятор AY использовать - zxmak или unreal. Заодно прикручу, чтобы можно было частоту звуковухи задавать - тоже будет через unity.config задаваться
Ну так честно предупреждай пользователя, что делается на ваш страх и риск, мол возможна порча иму... содержимого. пусть юзер имеет возможность сохранять в SCL, но делает это сознательно.
---------- Post added at 07:46 ---------- Previous post was at 07:43 ----------
Скажем так, эта фишка, даже назовем ее багофичей, работала не везде и не всегда, помнится даже был список моделей дисководов, которые умели это, а 3,5" дисководы так, имхо, вообще этого не умели, только головками трещали. Поправьте, если не прав.
Да в Spectaculator и вроде в zx Spin есть чтение с
реального магнитофона вернее с линейного входа звуковухи или микрофона, смотря как микшер настроить. Иногда полезно например включаешь ютуб где со звуком грузится что–то в спектрум автора и Spectaculator начинает синхронно грузить:)
---------- Post added at 11:43 ---------- Previous post was at 11:41 ----------
Эх запамятовал я примеры - была какая-то игрушка и еще в zx-ревю пример кода печатали.
ZXMAK, еще раз напомею свою хотелку про автоапдейт. Ну не вызывает у меня радости перекачивать архив с билдом при каждом обновлении. У тебя ж не поумертвый unreal от трупософта, которых хорошо, если раз в год апдейтится. Живое развитие, но ты теряешь тестеров эмуля из-за необходимости руками апдейтить сборку на машине. Если не хочешь делать, хотя бы напиши почему нет.
---------- Post added at 18:45 ---------- Previous post was at 18:44 ----------
Кстати, уркто было бы вообще сделать инсталлер. Жмешь на ссылку в теме - оно выкаичвается и ставится.
да чтение с реального кассетника было бы очень хорошо.
несколько эмуляторов обладают такой функцией - Spectaculator, ZX Spin, Klive, spectrum ZigaRamsak.
сам когда-то с помощью zx spin оцифровал немало игрушек и прог с кассет.
Так у меня тоже оверсэмплинг, UpdateDac использует оверсэмплинг :)
Вобщем порефакторил звук, добавил микширование огибающей, поправил косяки и вышло тоже самое что в unreal. Но в unreal операции оптимизированы чтобы не делать if, поэтому не стал мудрить - заюзал микcер unreal, порефакторил код и вынес эмуляцию в hardware.circuits. Уже закомитил, кому интересно могут уже сбилдить и потестить. Звук ау заметно преобразился, особенно там где эффекты на огибающей :)
как выяснилось, процессор ел ресэмплер, т.к. я тестил его на частоте дискретизации 176 кГц. Так впринципе примерно одинаково, но нагрузка на проц с новой реализацией чуток подросла, проявляется когда в музыке активно огибающая используется