Полигон-2

Макс, а что там кстати с чипом pal от CSM?
Прогресс есть какой-то?

Fagear написал:

[q]

который он получил, считав родной PAL. Нашёл лишний GAL16V8, зашил. Пока не пробовал. Не верится, что они его оставили не залоченным, но кто знает.

[/q]

Я не спец по PAL/GAL, но выскажусь. По-моему нельзя вот так просто JED файл от PAL шить в GAL. Предварительно его нужно обработать вот этой софтиной https://www.latticesemi.com/en...se/7/1/710 Она в прикрепленном файле.

Fagear написал:

[q]

Есть ли какой-то способ по JED получить схему/визуализацию, чтобы заменить GAL на стандартную логику?

[/q]

Ну есть, как бы... Вот http://www.brouhaha.com/~eric/retrocomputing/mmi/palasm/ , там внизу страницы ссылка на Opal Jr. архив, в котором есть jed2eqn.exe . Есть еще такое: http://www.gen.eclipse.co.uk/GalDis/GalDis.html , но поддерживает только GAL22V10 и PAL16R4. Но есть сорцы и автор пишет, что " It could easily be modified to cover others, though."

А можно нам JED лицезреть тут?

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