Полигон-2

Fagear написал:

[q]

Виртуалку собирать лень.

[/q]

Ну, в нашем деле без Dos никуда.... Я на винде DosBox юзаю постоянно. Хоть и не очень удобно, но хотя бы так.

Вообщем попробовал скормить файл JED2EQN. Сначала ругался на неожиданный конец файла, я тогда просто звездочку '*' добавил последним символом в .JED и вот что из этого вышло:


; JED2EQN — JEDEC file to Boolean Equations disassembler (Version V063)
; Copyright © National Semiconductor Corporation 1990-1993
; Disassembled from cms.jed. Date: 11-25-118
;$GALMODE MEDIUM

chip cms GAL16V8

i1=1 i2=2 i3=3 i4=4 i5=5 i6=6 i7=7 i8=8 i9=9 GND=10 /i11=11 o12=12
o13=13 f14=14 o15=15 o16=16 o17=17 o18=18 o19=19 VCC=20

@ues 0000000000000000
@ptd unused

equations

o19 = /i2 * /i1 * /i6
    + /i2 * /i1 * /i4 * /i6 * /i7 * /f14 * /i8 * i9 * i11
o19.oe = vcc
o18 = /i3 * /i4 * /i7 * /f14 * i8 * /i9 * /i11
o18.oe = gnd
o17 = /i3 * /i4 * /i7 * /f14 * i8 * /i9 * i11
o17.oe = gnd
o16 = /i2 * /i4 * /i7 * /f14 * /i8 * /i9 * i11
    + /i2 * /i3 * /i4 * /i7 * /f14 * /i8 * /i9 * /i11 * i11
o16.oe = gnd
o15 = /i2 * /i4 * /i7 * /f14 * /i8 * /i9 * i11
    + /i2 * /i4 * /i7 * /f14 * /i8 * /i9 * /i11 * i11
o15.oe = gnd
f14 = gnd
f14.oe = gnd
o13 = /i2 * /i1 * i5 * /i6
o13.oe = vcc
o12 = /i2 * /i4 * /i7 * /f14 * /i8 * i9 * /i11
o12.oe = gnd

rus написал:

[q]

Послушайте те же AWE32 с их огромными размерами и кучей компонентов, с аналоговой передачей сигнала чуть ли не через всю PCB. Это же ужас, а не звук. А тут ещё больше источников. Как это всё будет решаться, когда до этого дойдёт очередь?

[/q]

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

• Корректная трассировка цифровых цепей, чтобы уменьшить наводки с их стороны.
• Корректная трассировка аналоговых цепей, чтобы они не ловили всё подряд из эфира.
• Физическое разнесение цифровых и аналоговых цепей с минимальным пересечением: шина ISA - внизу платы, логика посередине, аналог - наверху, вдали как от цифры на плате FMonster, так и от материнской платы.
• Отдельное и фильтрованное питание аналоговых частей платы.
• Согласование импедансов узлов и исключение "висящих" высокоимпедансных входов.
  

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


Tronix написал:

[q]

Вообщем попробовал скормить файл JED2EQN.

[/q]

Спасибо большое, помогли!
Я уже на работе сегодня изучал спецификацию JED-файла и пытался декодировать его "ручками". Выглядит похоже на то, что приведено выше.
Я проанализировал полученное и вот что получилось:

[q]

Pin 12: /IOW x /BASE_ADDR x /A4 x /A3 x /A2 x A1 x /A0 = 0
Pin 13: /IOW x /ACK x TC x /IOB5 = 1
Pin 14: feedback
Pin 15: /IOW x /BASE_ADDR x /A4 x /A3 x /A2 x /A1 x A0 + /IOW x /BASE_ADDR x /A4 x /A3 x /A2 x /A1 x /A0 x A0 = 0
Pin 16: /IOW x /BASE_ADDR x /A4 x /A3 x /A2 x /A1 x A0 + /IOW x /IOR x /BASE_ADDR x /A4 x /A3 x /A2 x /A1 x /A0 x A0 = 0
Pin 17: /IOR x /BASE_ADDR x /A4 x /A3 x A2 x /A1 x A0 = 0
Pin 18: /IOR x /BASE_ADDR x /A4 x /A3 x A2 x /A1 x /A0 = 0
Pin 19: /IOW x /DACK x /IOB5 + /IOW x /DACK x /BASE_ADDR x /IOB5 x /A4 x /A3 x /A2 x A1 x A0 = 1

[/q]

Конфигурация пинов совпадает с тем, что я ранее анализировал на Vogons. Входы/выходы сконфигурированы так же, как я и предполагал. А вот дешифрованное не очень сочетается с тем, что получено путём наблюдения за эмуляцией платы. Да и в целом есть вопросы к логике полученных выражений. Причём, декодированы они вроде верно (у меня "ручками" то же получается), т.е. проблема либо в исходном чипе, либо в его считывании. Но это и не мусор, вполне похоже на то, что должно быть.

Несколько примеров.

[q]

Pin 19: /IOW x /DACK x /IOB5 + /IOW x /DACK x /BASE_ADDR x /IOB5 x /A4 x /A3 x /A2 x A1 x A0 = 1

[/q]

Получается, вторая часть выражения не имеет смысла, поскольку её "перекрывает" первая часть. Одновременно с этим выходит, что запись по определённому адресу для обновления показаний PCM DAC не имеет смысла - оно будет срабатывать по любому адресу в случае получения DACK.

[q]

Pin 16: /IOW x /BASE_ADDR x /A4 x /A3 x /A2 x /A1 x A0 + /IOW x /IOR x /BASE_ADDR x /A4 x /A3 x /A2 x /A1 x /A0 x A0 = 0

[/q]

Тут сразу два ляпа.
Во-первых, одновременное появление /IOW и /IOR на шине ISA в исправной работе невозможно. Во-вторых, "/A0 x A0" всегда ложь. Т.е. вторая часть (после "+") никогда не сработает.
А левая часть вообще равна левой части формулы для пина 15 (а вторая часть там тоже не сработает из-за такого же "/A0 x A0").

Пин 15 управляет BDIR, а пин 16 - BC1 на чипе AY. По результатам наблюдения за работой ПО в эмуляторе, получены данные, что:

• база+0x00 только запись, запись адреса в AY (BDIR/BC1 = 1/1)
• база+0x01 чтение - чтение данных из регистра AY (BDIR/BC1 = 0/1)
• база+0x01 запись - запись данных в регистр AY (BDIR/BC1 = 1/0)
  

По дешифрованному же получается, что:

• база+0x01 запись выставляет BDIR/BC1 = 0/0
  

Т.е. это режим "неактивности" AY. По 0x00 ничего не декодируется, чтение также невозможно.

Также есть сомнения по поводу порта для PCM DAC, поскольку наблюдение за софтом показывает, что запись именно данных для PCM DAC производится в порт база+0x02. Судя по декодированному выше, обновление показаний в PCM DAC проводится записью в база+0x03, а запись в +0x02 вызывает срабатывания прерывания от CSM...

Я, вообще, пока так и не дошёл до того, как работает DMA на ISA с т.з. приложения и с т.з. платы. Может кто-нибудь быстро введёт "чайника" в курс дела?
Вот я из приложения пишу в некий порт. Чтобы записать это через DMA я должен что-то особенное сделать, что-то подготовить или вызвать? Или это исключительно прерогатива платы - запросит ли она DMA по факту записи?
И, допустим, плата дала запрос на DMA. В какой последовательности и когда прибудут данные по шине? На том же цикле? Отдельно потом, когда появится DACK?

Fagear написал:

[q]

Может кто-нибудь быстро введёт "чайника" в курс дела?

[/q]

Неплохое объяснение с примером - https://wiki.osdev.org/ISA_DMA

pahan, justontime спасибо большое за ликбез!
Значит, в случае CSM всё примерно так:
1) ПО выделяет в ОЗУ кусок под данные для PCM DAC (не более 64 КБ) и пихает туда сэмплы.
2) ПО маскирует нужный DRQ (1 или 3).
3) ПО настраивает DMA контроллер (указание канала, адреса на буфер, размера и прочее).
4) ПО демаскирует DRQ.
5) ПО пишет в AY чип по адресу BASE+0x00 номер регистра "0xFF" (управление портом I/O B).
6) ПО пишет в AY чип по адресу BASE+0x01 данные для регистра 0xFF, чтобы дёрнуть пин 7, отключив аналоговый выход C от микшера и разрешив выдачу DRQ.
7) ПО пишет ряд байт в AY чип по адресу BASE+0x00 и BASE+0x01, чтобы заставить канал C чипа AY генерировать запрос DMA.
8) AY по таймеру выходом C дёргает DRQ.
9) DMA контроллер выдаёт DACK и начинает передачу данных для CSM.

На последнем пункте вопрос - DMA контроллер выставляет какой-то адрес для CSM или в этом нет необходимости? Ведь канал DMA жёстко указывает на эту плату.


rus написал:

[q]

Насколько я понимаю, все источники будут отдавать сигнал в формате I2S, так?

[/q]

Вообще нет, даже не близко.
Ни один из чипов не отдаёт I2S. В цифре вообще отдают только два - OPL2 и OPL3, и у тех свой проприетарный Ямаховский интерфейс к своим же ЦАПам. Остальные чипы отдают сразу аналог.

rus написал:

[q]

Тогда остаётся только защищать линии насколько это возможно. Любая ошибка, и вся работа с чистотой звучания насмарку будет.

[/q]

Для этого и идёт многостадийная отладка. Сначала несколько вариантов отдельных мини-плат, затем будет полноразмерный образец.