похоже, спектрум нашёл и прочитал данные. вероятно, ошибка в загрузчике TRD-файлов, который сформировал неверные CRC для секторов (можно загрузить и сразу выгрузить в формате UDI, а потом сравнить с windows-версией). однако CRC для адресных меток сформированы верно (63,9B для 6-го сектора)
вернее, дело не в CRC (она, похоже, верная), а в том, что спектрум не нашёл код #10 в нужном месте системного сектора диска. либо TRD такой (c чистым 9-м сектором disc error - правильное поведение), либо данные не доходят до процессора из образа диска. всё равно проверь загрузчик TRD
оооо, точно, блин, вот же я идиот -- сплошные нули читаются ^____^
нелюбовь к глобальным переменным меня подвела -- распихивая их по классам, не обратил внимания на конструкцию
memset(this, 0, sizeof(FDD));
короче, победа, РАБОТАЕТ! надо еще проверить разные загрузчики, и тп, и тд, но в целом можно сказать, что альфа-версия порта модуля эмуляции ВГ93 из UnrealSpeccy под линукс готова!
это зачем "очень"?Сообщение от GriV
сейчас буду говорить много банальностей, умных прошу не читать ^_^
итак, саундблястер играет звук идёт не непрерывным потоком, а небольшими буферами, состоящими из семплов, для удобства (у меня) по времени равными 1 кадру (1/50 сек.)
имеем на входе переключение бита 4 в порту #FE в некоторые моменты в течение эмулируемого кадра, а на выходе хотим буфер со звуковыми сэмплами. если частота оцифровки 48khz, то размер буфера длиной в кадр равен 48000/50=960 семплов. теперь, задача, как заполнить этот буфер
предположим, что в начале кадра (пентагон, 71680 тактов в кадре) состояние #FE было 0. а через 5000 тактов туда выведена 1, потом через 5000 тактов - опять 0, и т.д. (тон в 700 герц). тогда, очевидно, нужно начало буфера заполнить 0 до семпла номер 66 (5000/71680*960 - пропорция такая), потом от семпла 67 до семпла 133 (второй вывод на такте 10000, соотв. номер семпла 10000/71680*960) некоторым ненулевым значением, зависящим от установленной громкости спикера
и так до конца буфера
когда буфер готов, он ставится в очередь звуковой карты на проигрывание (таким образом, в текущий момент практически во всех эмуляторах играют буферы от прошлого и даже, более вероятно, позапрошлого или поза- поза- прошлых кадров, но приходится с этим мириться в обмен на другие прелести эмуляторов)
в реальности мы видим, что из-за погрешностей округления при расчётах позиции семпла смены уровня, расстояния между фронтами в буфере не одинаковые, поэтому (и ещё по паре причин) возникают паразитные частоты (т.н. альясинг). что это такое и как с ними бороться, написано в любом более-менее уважающем себя учебнике по ЦОС, лучше мне и не сказать. рекомендую http://dsp-book.narod.ru
ну если уж такая лень открыть учебник, может, когда-нить и накатаю популярную лекцию типа этой
классно!короче, победа, РАБОТАЕТ! надо еще проверить разные загрузчики, и тп, и тд, но в целом можно сказать, что альфа-версия порта модуля эмуляции ВГ93 из UnrealSpeccy под линукс готова!поздравляем ! надеюсь сие чудо можно будет скомпилить под FreeBSD ? (в будущем
)
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
пасибклассно!
сам выдранный из US ВГ93-эмулятор под чем угодно соберется -- там только стандартные сишные библиотеки юзаются. ZX-эмуль, на котором экспериментирую сейчас -- искореженная глюкалка, если обычная глюкалка пашет под фрей, то и с этим хозяйством не должно быть проблем
кста, выше я обшибся, не 700hz, а 350 в примере
ладно я понял, меня как раз антиалиасинг интересует.
Тут ведь дело в чём - например тот же dizzy выводит на стартовой заставке (оригинальная версия имеется в ввиду) вполне приличный музон - если просто тыркать состояние бипки в звуковой ряд, то ничего путёвого не выйдет - прото потому что в указанный отрезок времени - даже для 48кгц получается около 73 тактов - он (бипка) изменяет своё состояние и даже порой не один раз и конечно оттуда и вопрос. На реальном спекке как - имеется триггер на выходе бипки и SPK и имеется его внутренняя ёмкость которая приводит к немоментальному срабатыванию триггера - например в течении нескольких мкс изменяет свой уровень на противоположный (сигнал не прямоугольной формы). Т.е. в любом случае имеется немоментальный переход в противоположное состояние, а потом я изучил диаграммы, получаемые US - и получается так же - что сигнал у бипки изменяется не моментально прямоугольно - а через некоторое количество отсчётов - порядка 1-2 отсчётов выходного звукового ряда (48 кгц всё те же). Вот и оттуда вопрос - откуда этот "наклон" кривой изменения состояния бипки? Это его именно антиалиасинг даёт?
да
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием