Кодерский уголок

AxXxB, оно так работать не будет.

 

это называется плеер. И останавливать цпу низя, если предполагается использование плеера в других программах. Например в играх.

И вообще, логичнее взять мануал по портам платы и программированию самой микрухи. А так же подробную документацию по формату SID. И сделать всё чисто и по уму. Копипаста с подменами непойми чего на непойми что до добра не доведёт в любом случае.

 

Geryon, Кончай уже этот секс по переписке. Тут работы на полдня скорее всего и ты либо уж прошаривайся и делай сам, либо расшарь код с теми, кто сделает.
Без обид

 

Я вообще не понимаю, в чём проблема. Наверняка точная частота нужна для одной цели — кидать с этой частотой байты в порт устройства. Ну вот и ставим этот OUT в наш обработчик прерывания, предварительно перепрограммировав таймер. Сотни игрушек так делали со спикером и/или саундбластером, сам такой код писал (на самом деле со спикером посложнее) — это элементарно же.

 

Читать показания таймера?

Если custom_counter - счётчик прерываний, тогда ОК. А если счётчик в аппаратном таймере, тогда не пойдёт - c hlt'а проц снимается только прерыванием, привет точности. :-(

Скорее

Код:

custom_counter = 0; end_counter = delay;

и всех троих беззнаковыми.

 

Рыжий Тигра, Ставим таймер на период, скажем, в 16 тиков вместо 65536. Заводим наш глобальный счетчик, который инкрементим каждый раз, и через каждые 4096 вызовов вызываем стандартный обработчик, чтобы шли досовские часы итд.
Перед каждый OUT делаем задержку до ожидаемого времени, ожидая нужного значения счетчика в цикле с тем же __asm hlt внутри. Нужно разве что еще учесть, что на медленной машине при большом количестве "единомоментных" OUT-ов, таймер уже может немного убежать вперед, и поэтому ждать нужно в пределах некоторого "окна". Но это лишние 1-2 строчки кода.
Cуммарное время, которое мы тут потратили, объясняя, намного больше, чем время, требуемое на реализацию
А и да, Тигра, не надо обнулять счетчик, в который пишет обработчик прерывания, вариант от AxXxB чуть надежнее. просто прибавляем к нему время ожидания (с переполнением, если надо) и ждем до него.

 

Нет, тут дело в другом. То, что ты описываешь - это вывод PCM-звука, он через SID тоже возможен, но это другой случай.

Как я понимаю происходящее, библиотека читает файл *.SID (или другой понимаемый формат), эмулирует его обработку Коммодором, но без привязки ко времени. При этом постоянно учитывается количество циклов процессора C64, которое уходит на обработку. Всякий раз, когда Коммодор писал или читал бы из регистров SID, вызываются соответствующие функции модуля, отвечающего за SID. В моем случае этот модуль просто пишет требуемое в порты SSI-2001 (или читает). Но, так как таймер никак не используется, на выходе получается звук с той скоростью, с какой CPU успевает эмулировать Коммодор. А нужно сделать задержку, используя имеющееся количество циклов Коммодора, которое отдает библиотека при вызовах модуля для работы с SID.

 

Geryon, модули SID содержат две части, насколько я мельком глянул:
1. оригинальный проигрыватель мелодии в кодах C64.
2. Саму мелодию в формате этого самого плеера (то есть вообще неведомо как).

Что бы всё это послушать, нам надо эмулировать процессор C64, который будет выполнять код плеера и который и будет жрать мелодию и плевать в виртуальные порты, которые мы будем перехватывать и уже сами плевать в железную карту.

По сути эмулируем фактически весь коммодор. Без экрана.

Однако, что то подсказывает что HardSID умела это сама.

Так вот, задача, как я понимаю сводится к тактированию виртуального C64.

Частота у него была 1Mhz, смотрим на фотку и видим кварц в 1Mhz...

 

Geryon, Если я напишу тебе функцию synchronize(unsigned long current_cpu_ticks), тебе хватит?

Кстати, интересный факт. частота_процессора_NTSC / частота_таймера_PC == 6/7 РОВНО
Для PAL не работает, там кварцы разные

 

Мне хватит, если будет аналог функции usleep(), то есть задержка в каких-то понятных единицах (в случае usleep это микросекунды), которые можно было бы пересчитать в циклы C64, в зависимости от требуемой конкретным SID-файлом модели (NTSC или PAL).

Я наконец закоммитил исходники в github: https://github.com/bristlehog/libsidplayfp-innov. Да только не знаю, как их тестировать кто-то кроме меня будет. Тут Dosbox не поможет, потому что libsidplayfp слишком прожорлива до ресурсов. А обрабатывать надо ситуацию, когда процессор слишком быстрый, а не слишком медленный.

---------- Сообщение добавлено в 18:36 ---------- Предыдущее сообщение размещено в 18:30 ----------

Нет, HardSID эмулировать Commodore наверняка не умела. Там тоже интерфейс к портам SID, только не такой прямой, как у SSI-2001, а через всего два порта, 300-301h. И, видимо, функция задержки. Больше я ничего не нашел, документации тоже не нашел.

---------- Сообщение добавлено в 18:41 ---------- Предыдущее сообщение размещено в 18:36 ----------

Не знаю, что такое тактирование, но в остальном в libsidplayfp так и есть: эмулируются необходимые части Commodore. Эти части обращаются к виртуальному SID через методы sid::read() и sid::write(), а там уже то, что нужно: либо эмулятор SID, либо класс для работы с HardSID через порты или DLL, либо вот кидаются данные тупо в порты SSI-2001.

 

ТЬФУ 6/7

 

Geryon, а когда будет версия под Windows 98 - 10 ?

каждая команда процессора исполняется определённое время, что должно эмулироваться для правильной работы. Это самое время определяется в тактах. Один такт в данном случае равен 1Mhz. Одна команда может использовать более 1 такта.

 

Это, кстати, идея. Что если собрать под Windows 98 с использованием QueryPerformanceCounter() хотя бы для проверки? Windows 98 ведь допускает прямую работу с портами?

 

Да, допускает без проблем. Более того, есть драйвера для включения прямого доступа к портам в NT-виндах. Типа http://retired.beyondlogic.org/porttalk/porttalk.htm

 

Ребята. вот вам исходники целого эмулятора, что бы не долбаться по мелочам:
http://www.emu-land.net/computers/c64/emuls/linux?act=showonly&id=844

 

У меня есть исходники VICE 2.4 для DOS, но там черт ногу сломит. Хотя VICE, скорее всего, существенно менее прожорливый.

 

Geryon, тебе надо взять токо модуль эмуляции процессора и разобраться как сделано тактирование.

 

У меня есть свой эмулятор 6502 на ассемблере(не релизился, но старый тест-билд могу закинуть), только он эмулирует Atari 2600, а не C64. Наверное подключать туда поддержку именно C64 (менять карту памяти как минимум, прерывания добавлять) - многовато возни..

 

nop, скорее всего основная возня с форматом SID будет. С другой стороны получится более чисто и менее глючно, да и кроссплатформу можно сразу заложить. Всё же это лучше, чем в чужих сорцах ковыряться.

 

в проекте Vice, кстати, есть свой SID-плеер.