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

С управлением размером буфера подсказали и разобрался.

Код:

HRESULT subhook_c::DecideBufferSize( IMemAllocator *pAlloc, ALLOCATOR_PROPERTIES *pProperties ) {
  HRESULT hr;
  int new_bufsize = g_max_subtitle_size;
  ALLOCATOR_PROPERTIES previous;
// сначала отрабатываем штатный:
  if ( FAILED( hr = CTransInPlaceFilter::DecideBufferSize( pAlloc, pProperties ) ) )
    return ( hr );
#ifndef NDEBUG // [
  new_bufsize = 16384; // только чтобы проверить идею
#endif // ]
  if ( pProperties->cbBuffer < new_bufsize ) { // мало - увеличиваем:
    pProperties->cbBuffer = new_bufsize;
// пробуем:
    if ( FAILED( hr = pAlloc->SetProperties( pProperties, &previous ) ) )
      return ( hr );
// проверяем:
    if ( previous.cbBuffer < pProperties->cbBuffer )
      return ( E_FAIL );
  }
  return ( hr );
}

Вроде работает, никто никуда не падает.

 

И снова вопрос про таймер! Можно ли вместо перехвата обработчика просто перепрограммировать другой канал (не нулевой) на нужную мне частоту, а затем просто считывать оттуда значения?

 

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

 

Эээ... Какими действиями?

 

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

Не то что бы это совсем уж невозможно, особенно для доса, но не спектрум всё же.

 

А чем тогда может помочь обработчик прерывания?

 

Geryon, ты чем прочитал предыдущий пост ? Написано же чем. Прям в первой фразе. А в конце написано почему без него получится фигня скорее всего.

Если я правильно понимаю задачу - твоему драйверу охота делать что то через определённое время. Притом время очень небольшое и с высокой точностью таймера. Иначе зачем огород с таймером городить ? Ведь можно и часы читать. А коли нужна высокая точность - значит обрботчик дожен получать пинка точно в нужный момент и тратить на обработку не больше чем запланировано.

 

Задача следующая: библиотека libsidplayfp что-то там внутри себя эмулирует и вызывает метод драйвера ::clock, в коем методе известно, сколько прошло циклов C64 с момента прошлого вызова метода.

Я переделывал драйвер SSI-2001 из драйвера HardSID. Так вот, в этом HardSID есть внутренний таймер, который используется для корректного независимого от скорости CPU воспроизведения:

Код:

void HardSID::clock()
{
    if (!m_handle)
        return;

    event_clock_t cycles = m_context->getTime(m_accessClk, EVENT_CLOCK_PHI1);
    m_accessClk += cycles;

    while (cycles > 0xffff)
    {
        ioctl(m_handle, HSID_IOCTL_DELAY, 0xffff);
        cycles -= 0xffff;
    }
    if (cycles)
        ioctl(m_handle, HSID_IOCTL_DELAY, cycles);
}

Можно предположить, что HardSID поддерживает только 16-битные значения задержки, отсюда выверты с 0xffff.

А у SSI-2001 никаких внутренних таймеров нет, поэтому надо как-то решать за счет таймера самого компа.

Автор библиотеки рекомендовал поступить так:

Но в том и беда, что для Unix есть usleep(), для Windows - QueryPerformanceCounter(), а для доса придется как-то выкручиваться.

 

а схема и мануал по программированию у неё есть ?
И вообще, зачем делать железку эмулирующую другую железку, что бы этой эмуляцией занималась таки внешняя библиотека, которая чудно умеет эмулировать обе железки сразу на любой другой железке ?

 

Схема - это не разводка платы, а принципиальная схема? Где-то такая была, я могу поискать. Мануал тоже есть, но читать там особо нечего: плата просто позволяет работать с регистрами SID через I/O 280h-29Ch. Это по дефолту, возможны другие значения I/O - например, я использую 2A0h-2BCh, потому что дефолтные настройки конфликтуют с ресурсами материнки. Кроме работы с регистрами SID, плата ничего не умеет (ну, еще там порт джойстика есть).

Мы (мы пахали...) делали копию/клон железки, а не эмулятор. Эмуляторов и без нас дофига. Копия полностью совместима с оригиналом, и лишена некоторых его недостатков. Например, она не глючит на быстрых машинах, поддерживает кроме 6581 еще и 8580, может переключаться между режимами PAL и NTSC, и еще кое-что по мелочам.

Вот фото оригинала Innovation SSI-2001 и HardSID:



Раньше я как-то не обращал внимания на имеющийся на HardSID кварц...

 

Geryon, это я из ролика уже знаю (про бла-бла-бла и поддерживает). В принципе штука не сложнее AY8910.

Я просто не понимаю, что мешает тебе использовать прерывание ?

 

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

 

Если бывает такое, что количество циклов между вызовами больше 0xFFFF, то считывание из таймера не годится - там всего 0xFFFF циклов и помещается. Можно, правда, запустить два канала, чтобы один считал на максимальной частоте, а другой на в 2^n меньшей, тогда общая разрядность будет 16+n бит. Но проще обработчик прерывания повесить с инкрементом сколько-угодно-разрядного значения.

---------- Сообщение добавлено в 14:35 ---------- Предыдущее сообщение размещено в 14:32 ----------

Это проще, чем ты думаешь, всего пару операций надо сделать. С самим таймером даже посложнее работать.

 

Наверное, бывает, раз авторы решили обработать такую ситуацию.

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

Как это выглядит? Неужели так:

Код:

end_counter = custom_counter + delay;

while(custom_counter < end_counter)
{
   // ждем, пока обработчик сам меняет custom_counter ?
}

 

Geryon, выглядит это так:


1. Ты вешаешь свой обработчик поверх IRQ8. Тут своя кухня с запретом прерывания, сохранением адреса старого обработчика, танцами с подготовкой и разрешением прерывания после.
2. В обработчике происходит только проверка на нужный отрезок времени и кидание нужных данных куда оно тебе надо и отдача управления на предыдущий обработчик по цепочке. Обычно туда весь плеерный блок и засовывается, что бы не мешался под ногами.
3. В основной программе происходит проверка на окончание работы и в случае такового - удаление своего обработчика и возвращение старого на место.

Конкретно по таймеру в ненаучно-популярном виде.

При написании дров под досю рекомендую забыть псю как страшный сон. Даже если надо работать с DPMI.

 

Geryon, тут просто малость непонятно, что именно этот самый ::clock делает. Вроде как он отправляет команду на задержку железки на полученное через m_context->getTime количество циклов, но сам код при этом не задерживается. Так? Если так, то куда деваются значения, передаваемые через ioctl во время задержки, неужели в железке есть их очередь? Если не так, то, выходит, железка задерживает сам проц? Фигня какая-то, в общем. К тому же, непонятно, откуда эти самые циклы берутся в getTime.

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

 

AxXxB, а тут ещё фокус то в том, что он софтовый эмулятор пытается на хард переориентировать. Без изменения концепции основной библиотеки. Ну это примерно как винамп целиком (вместе с гуями и прочим) повесить на таймерное прерывание в качестве обработчика.

 

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

 

Не совсем так. HardSID-то поддерживается, значит, и SSI-2001 в конце концов заработает.

Насчет драйвера - я использовал неудачное слово. Это не драйвер, а модуль, который отвечает за работу с SID в библиотеке. Есть модули-эмуляторы, которые выдают на выход PCM-данные, есть модуль для HardSID, а я делаю модуль для SSI-2001. Поэтому останавливать CPU для ожидания можно.

 

Geryon, а, ну тогда действительно будет примерно так, как ты и писал:

Код:

end_counter = custom_counter + delay;

while(custom_counter < end_counter)
{
   __asm hlt; //просто чтобы не есть лишнюю энергию
}