Прикрутить YM2149F к IBM-PC?

[Tronix]

Как вариант - если применить внешнее тактирование (напр., от генератора типа тех, что стояли на старых материнках), то старые PIC-и работают и на гораздо более высоких частотах.
У меня , напр., PIC16F690 нормально переваривает 32MHz, потребление при этом - ок. 15мА, ессно, ничего не греется.

Да, я думал и об этом тоже. Большая проблема в том, что если повысить частоту, то слетают все временные интервалы в софтовом USB стеке. Там часть подогнана с помощью высчитанных заранее машинных тактов, кое-где goto $+D'1', кое-где таймер с константой и тд. Повышаем частоту - PIC перестает распознаваться. Если гнать, нужно полностью вкурить как работает USB на низком уровне, а я чего-то очкую.

[ALS]

А, да, что-то я не подумал...

[Tronix]

Вообщем, оптимизировал как мог код записи байта в PIC:

DIO_WriteByte:

    ;Put value in RB3-RB7
    movlw   B'00000111'
    andwf   PORTB,W
    movwf   TMP
    movlw   B'11111000'
    andwf   RXDATA_BUFFER+4,W       ;wIndex Lo
    iorwf   TMP,W
    movwf   PORTB

    ;Put the last bits values in RA0-RA2
    movlw   B'11111000'
    andwf   PORTA,W
    movwf   TMP
    movlw   B'00000111'
    andwf   RXDATA_BUFFER+4,W       ;wIndex Lo
    iorwf   TMP,W
    movwf   PORTA
    
    iorlw   B'00011000'             ;set bc1=1, bdir=1
    btfsc   ODDEVEN,0               ;skip next intruction if first byte
    andlw   B'11110111'             ;set bc1=0, bdir=1 if second byte
    movwf   PORTA

    andlw   B'11100111'             ; set bc1=0, bdir=0 (inactive)
    movwf   PORTA
    movlw   B'00000001'             ; toggle ODDEVEN flag
    xorwf   ODDEVEN,F

    return

Ну, играет вроде:
https://soundcloud.com/tronix286/hig0dzhmm-nik-0tl99

Но мне кажется, что медленно. Или это меня уже глючит, не знаю. Или реально медленно. Дальше еще можно попробовать буферизировать в самом ПИКе паттерн из 28 байт, одновременно принимая байты во второй буфер (двойная буферизация), но это как-то сложно, да и вряд-ли выгорит по времени выполнения. Если только еще сжимать предварительно LZW или что там быстрое. Но это уже больше костыли какие-то. Уперся уже совсем в предел, мне кажется.

Либо так, либо менять на ПИК с хардварным USB.

---------- Post added at 14:29 ---------- Previous post was at 14:16 ----------

Ну вот выкинул еще одну команду

    ;Put the last bits values in RA0-RA2
    movlw   B'11111000'
    andwf   PORTA,W
    movwf   TMP
    movlw   B'00000111'
    andwf   RXDATA_BUFFER+4,W       ;wIndex Lo
    iorwf   TMP,W
    ;movwf   PORTA
    
    iorlw   B'00011000'             ;set bc1=1, bdir=1

Так тоже работает. Но это все.

[daniel]

Но мне кажется, что медленно. Или это меня уже глючит, не знаю. Или реально медленно.

прпробуй две одинаковых мелодии на разных устройствах одновременно запустить и сравнишь.

[Tronix]

Короче прикрутил еще кольцевой буффер на 28 байт, теперь в декодере складываю туда байты, а иногда, в основном цикле, вывожу их на YM.. Это позволило в библиотеке USB-lib откатится назад на время ожидания в тиках 1000. Раньше стояло 5 и работало только на моей машине, на нетбуке - уже глючило. Щаз полет и там и там нормальный.

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

[Tronix]

На всякий случай выкладываю схему устройства, исходники прошивки, исходники DLL-заглушки для ZX Tune.

Плюс уже скомпилированная прошивка для записи в микроконтроллер PIC16F628A и длл-ки для x86 и x64. Драйвера брать здесь: http://16fusb.googlecode.com/files/1...32-1.2.6.0.zip

Прошивка базируется на оригинале библиотеки 16FUSB, но многое подогнано "под себя":
- выкинуто все, что связано с чтением сигналов из PIC в хост (компьютер) для увеличения быстродействия обработки реквестов USB;
- состояние направлений портов ввода-вывода жёстко задано при инициализации МК и не изменяется в процедурах выдачи байта на ноги.
- организован кольцевой буфер на 28 байт. При декодировании запроса от хоста байты складываются в буффер. Когда есть свободное время, данные из буфера выдаются на YM.
- дичайше оптимизирована скорость выдачи байта на ноги МК. Частично за счет жестко указанных направлений ввода-вывода, частично из-за известности предыдущего состояния управляющих бит.
- что-то еще по мелочи.

По схеме - для тактирования PIC применен кварцевый генератор, а не кварц, тем самым высвобождая одну ногу МК (RA6), необходимую для управления сигналом RESET. Нога RA5, торчащая в воздухе, в данном семействе работает только на вход и не может быть использована для управления выходным сигналом. Можно было бы попробовать ее (ногу RA5) использовать как входной сигнал U+ или U- USB, но в обработчике прерывания тогда бы увеличилась задержка из-за разбросанности на разных портах (порт A и порт B) сигналов, что скорее всего привело бы к неработоспособности USB стека. Хотя не отрицаю, что возможно бы и получилось перенести с ноги RB2 функционал на RA5, а RB2 использовать для управления RESET, а МК тактовать просто от кварца. Но, как получилось. С другой стороны, для тактирования YM2149F собран генератор на микросхеме 74HC02 и кварце 3.579545 MHz. Можно было бы попробовать использовать вторую свободную половину микросхемы для сборки аналогичного генератора и для PIC, но остановило два момента: 1) у меня нету кварца на 24МГц (а кварцевый генератор был, с какой-то древней мамки) 2) я не знаю, как поведет себя 74HC02, если с "разных боков" у нее будут разные частоты, причем одна из них довольно высокая (24МГц все таки большая частота).

Дальше, нога RA4, которая управляет сигналом BDIR, с открытым коллектором, поэтому ее обязательно нужно подтянуть к питанию - на схеме это 10K резистор R5.

[Advertiser]

[Vitamin]

Tronix, если ZXTune будет общаться с библиотекой в пакетном режиме (2 байта маски и 0..14/14 (по желанию) байт данных), тебе это поможет?

[TSL]

[04.01 00:35:42] <deathsoft> TSL, скинь в болото линк http://dlcorp.nedopc.com/viewtopic.php?f=21&t=732

[Tronix]

Tronix, если ZXTune будет общаться с библиотекой в пакетном режиме (2 байта маски и 0..14/14 (по желанию) байт данных), тебе это поможет?

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

Еще посетила безумная мысль - как только обработали принятый байт в ПИКе, все, выходим в начало суперцикла, не отвечая ничего хосту (компу). Ни NAK, ни ACK, просто ничего. По идее, функция usb_control_msg(..) должна тогда отвалится по таймауту. Таймаут можно минимальный поставить в 1 такт.

[Vitamin]

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

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