Внимание! Это временный неофициальный архив старой версии форума Полигон Призраков, созданный сочувствующим форуму участником. Этот сайт просуществует лишь до тех пор, пока администрация Полигона не сдержит своё обещание и не откроет официальный архив по адресу old.sannata.org.

Полигон-2

Форум о старых компьютерах

Объявление форума

Если пользуетесь личными сообщениями и получили по электронной почте оповещение о новом письме, не отвечайте, пожалуйста, почтой. Зайдите на форум и ответьте отправителю через ЛС.

Полигон-2 »   IBM PC-совместимое. До 2000 года включительно »   Это не "дура", это FMonster
RSS

Это не "дура", это FMonster

Попытка создать ISA 8-bit плату со всеми синтезаторами

<<Назад  Вперед>> Страницы: 1 2 3 4 5 6 7 * 8 9
Печать
 
pahan
Advanced Member


Откуда: Химки, М.О.
Всего сообщений: 1070
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
13 мар. 2015
[q]
1) ПО выделяет в ОЗУ кусок под данные для PCM DAC (не более 64 КБ) и пихает туда сэмплы.
[/q]
Тут можно дополнить только, что буфер этот должен быть в пределах первого мегабайта, но при программировании под DOS это соблюдается почти автоматически :)
[q]
3) ПО настраивает DMA контроллер (указание канала
[/q]
Указывать канал на контроллере не нужно - просто у каждого из 4х каналов свои регистры адреса, размера, режима работы. Кроме этого, если выставить режим autoinitialize, по завершении передачи адрес и размер автоматически сбросятся на ранее заданные значения. Более того, если НЕ использовать autoinitialize, канал по завершении передачи автоматически будет замаскирован.
[q]
8) AY по таймеру выходом C дёргает DRQ.
[/q]
Не знаю подробностей работы с AY, но в принципе возможен и другой режим - записью в request register DMA контроллера вы можете начать передачу по нужному каналу в любой момент, не дожидаясь, пока устройство физически дёрнет DRQ.
[q]
На последнем пункте вопрос - DMA контроллер выставляет какой-то адрес для CSM или в этом нет необходимости? Ведь канал DMA жёстко указывает на эту плату.
[/q]
DMA контроллер выставляет адрес в памяти, с которого надо забрать данные и выставляет MEMR и IOW. DACK однозначно определяет какое устройство эти данные должно забрать с указанного адреса, отдельно выставлять адрес устройства (и вообще знать его) контроллеру не нужно. Собственно, возможная неправильная реакция какого-либо устройства в этот момент явно запрещена неактивным сигналом AEN.
Fagear
Advanced Member


Откуда: Москва, САО
Всего сообщений: 1228
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
22 янв. 2010
pahan написал:
[q]
Не знаю подробностей работы с AY
[/q]
Там очень замудрённый механизм запроса DRQ.


pahan написал:
[q]
DACK однозначно определяет какое устройство эти данные должно забрать с указанного адреса, отдельно выставлять адрес устройства (и вообще знать его) контроллеру не нужно.
[/q]
Тогда, получается, CSM должен уметь работать двумя способами.
1) Через DMA.
2) Прямой записью в порт.

Потому что при работе через DMA от софта обращений по адресам CSM не будет (судя по кривому GAL - оно сработает просто при наличии DACK, IOW и разрешении, исходящего от AY).
Однако некоторые игрушки явно пишут PCM данные просто в порт BASE+0x02:
[q]
[CSM] Write on port 222h, len 1, val 88h
[CSM] Write on port 222h, len 1, val 88h
[CSM] Write on port 222h, len 1, val 8ah
[CSM] Write on port 222h, len 1, val 86h
[CSM] Write on port 222h, len 1, val 8ch
[CSM] Write on port 222h, len 1, val 90h
[CSM] Write on port 222h, len 1, val 84h
[CSM] Write on port 222h, len 1, val 7eh
[CSM] Write on port 222h, len 1, val 80h
[CSM] Write on port 222h, len 1, val 82h
[CSM] Write on port 222h, len 1, val 82h
[CSM] Write on port 222h, len 1, val 7ah
[CSM] Write on port 222h, len 1, val 7eh
[CSM] Write on port 222h, len 1, val 78h
[CSM] Write on port 222h, len 1, val 76h
[CSM] Write on port 222h, len 1, val 70h
[CSM] Write on port 222h, len 1, val 86h
[CSM] Write on port 222h, len 1, val 74h
[CSM] Write on port 222h, len 1, val 80h
[CSM] Write on port 222h, len 1, val 78h
[CSM] Write on port 222h, len 1, val 74h
[CSM] Write on port 222h, len 1, val 90h
[CSM] Write on port 222h, len 1, val 8eh
[CSM] Write on port 222h, len 1, val 7ah
[CSM] Write on port 222h, len 1, val 8ah
[CSM] Write on port 222h, len 1, val 6eh
[CSM] Write on port 222h, len 1, val 88h
[CSM] Write on port 222h, len 1, val 94h
[CSM] Write on port 222h, len 1, val 80h
[CSM] Write on port 222h, len 1, val 7eh
[CSM] Write on port 222h, len 1, val 7ch
[CSM] Write on port 222h, len 1, val 7ch
[CSM] Write on port 222h, len 1, val 70h
[CSM] Write on port 222h, len 1, val 70h
[CSM] Write on port 222h, len 1, val 8ah
[CSM] Write on port 222h, len 1, val 8ah
[CSM] Write on port 222h, len 1, val 6eh
[CSM] Write on port 222h, len 1, val 84h
[CSM] Write on port 222h, len 1, val 8ch
[CSM] Write on port 222h, len 1, val 90h
[CSM] Write on port 222h, len 1, val 9ah
[CSM] Write on port 222h, len 1, val 74h
[CSM] Write on port 222h, len 1, val 6ah
[CSM] Write on port 222h, len 1, val 7ch
[CSM] Write on port 222h, len 1, val 88h
[CSM] Write on port 222h, len 1, val 92h
[CSM] Write on port 222h, len 1, val 92h
[CSM] Write on port 222h, len 1, val 82h
[CSM] Write on port 222h, len 1, val 70h
[CSM] Write on port 222h, len 1, val 66h
[CSM] Write on port 222h, len 1, val 7ah
[CSM] Write on port 222h, len 1, val 8ch
[CSM] Write on port 222h, len 1, val 94h
[CSM] Write on port 222h, len 1, val 82h
[CSM] Write on port 222h, len 1, val 7eh
[CSM] Write on port 222h, len 1, val 7ah
[CSM] Write on port 222h, len 1, val 7ah
[CSM] Write on port 222h, len 1, val 7ah
[CSM] Write on port 222h, len 1, val 7ch
[CSM] Write on port 222h, len 1, val 76h
[CSM] Write on port 222h, len 1, val 74h
[CSM] Write on port 222h, len 1, val 7ch
[CSM] Write on port 222h, len 1, val 88h
[CSM] Write on port 222h, len 1, val 8eh
[CSM] Write on port 222h, len 1, val 86h
[CSM] Write on port 222h, len 1, val 80h
[CSM] Write on port 222h, len 1, val 80h
[CSM] Write on port 222h, len 1, val 80h
[CSM] Write on port 222h, len 1, val 7ah
[CSM] Write on port 222h, len 1, val 70h
[CSM] Write on port 222h, len 1, val 72h
[CSM] Write on port 222h, len 1, val 7eh
[/q]
Что явно идёт в разрез с работой по DMA.

Надо пытаться запустить CSM на железе и смотреть на реальных железяках чего там куда обращается.
pahan
Advanced Member


Откуда: Химки, М.О.
Всего сообщений: 1070
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
13 мар. 2015
[q]
Тогда, получается, CSM должен уметь работать двумя способами.
1) Через DMA.
2) Прямой записью в порт.
[/q]
Конечно. И ещё в идеале выдавать прерывание. Повторюсь - для ПО (CPU) способа узнать, что передача по DMA данных конкретному устройству закончена, нет. Обычно делают так - устройство,увидев импульс TC, генерит IRQ.
[q]
Потому что при работе через DMA от софта обращений по адресам CSM не будет (судя по кривому GAL - оно сработает просто при наличии DACK, IOW и разрешении, исходящего от AY).
[/q]
Да, этого абсолютно достаточно, чтобы принять данные.
[q]
Однако некоторые игрушки явно пишут PCM данные просто в порт BASE+0x02:
[q]
[CSM] Write on port 222h, len 1, val 7eh
[/q]
Что явно идёт в разрез с работой по DMA.
[/q]
Думаю принципиальна здесь пересылка по одному байту за раз. Да, это можно реализовать через DMA, есть даже специальный режим у DMA-контроллера - single transfer, когда из всего буфера будет пересылаться 1 байт за раз, а в промежутках CPU будет позволено тоже что-то полезное сделать. Но всё это из серии - "но зачем???". DMA имеет смысл именно для довольно больших блоков (те самые килобайты).
Вообще утверждение, что DMA - самый быстрый режим передачи, заслуживает серьёзного расследования и разрушения мифа. Во времена всяких XT это действительно было так - частоты проца и DMA-контроллера (а у него не больше 4,77 МГц) близки, процы даже на элементарные команды тратили кучу тактов. Думаю, с 486х (а может даже 386х, считать надо) любая возня с DMA будет реально неоправдана - на простейшие команды не больше нескольких тактов, да ещё на в разы более высокой частоте...
scg
Newbie


Всего сообщений: 108
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
28 фев. 2017
[q]
Думаю, с 486х (а может даже 386х, считать надо) любая возня с DMA будет реально неоправдана - на простейшие команды не больше нескольких тактов, да ещё на в разы более высокой частоте...
[/q]
Для процессоров, которые работают на частотах выше частоты шины, обращение напрямую к шине (опереции ввода-вывода не кешируются) будет его сильно тормозить. С появление PCI DMA вообще стало основным способом общения перефирии с остальной системой.
pahan
Advanced Member


Откуда: Химки, М.О.
Всего сообщений: 1070
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
13 мар. 2015
[q]
С появление PCI DMA вообще стало основным способом общения перефирии с остальной системой.
[/q]
Именно так. Только к классическому ISA DMA, который мы в данном случае обсуждаем, всё это не имеет никакого отношения. В PCI и более поздних фактически этот режим называется bus mastering и позволяет любому устройству без всяких посредников (а именно DMA-контроллера) обращаться напрямую к любому другому устройству, в том числе памяти.
[q]
Для процессоров, которые работают на частотах выше частоты шины, обращение напрямую к шине (опереции ввода-вывода не кешируются) будет его сильно тормозить.
[/q]
Однако частота шины в данным случае всё равно остаётся в разы выше частоты ISA DMA-контроллера.
scg
Newbie


Всего сообщений: 108
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
28 фев. 2017
[q]
Только к классическому ISA DMA, который мы в данном случае обсуждаем, всё это не имеет никакого отношения.
[/q]
Имеет - не имеет, но исторически DMA победил. Значит что-то в нем полезное есть.
[q]
Однако частота шины в данным случае всё равно остаётся в разы выше частоты ISA DMA-контроллера.
[/q]
Разве частота ISA шины не постоянна?
На мой взгляд, DMA гораздо удобнее для звуковых карт. Передавая побайтово семплы вы запаритесь выдерживать нужный период, тратя процессорное время не только на ожидание шины но и на отслеживание времени, а DMA позволяет самой звуковухе вытаскивать байты из памяти с нужной частотой.
pahan
Advanced Member


Откуда: Химки, М.О.
Всего сообщений: 1070
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
13 мар. 2015
[q]
Имеет - не имеет, но исторически DMA победил. Значит что-то в нем полезное есть.
[/q]
А я и не отрицал его полезность как принципа. Я имел в виду лишь устарелость конкретной реализации этого принципа (а вся эта возня с отдельным контроллером и кучей каналов однозначно указывает на конкретную реализацию) с развитием PC-железа. Которую и производители прекрасно понимали в то время - уже в EISA (1988 год) были введены более быстрые и несовместимые режимы.
[q]
Разве частота ISA шины не постоянна?
[/q]
Ага. Более того, она даже нигде формально не стандартизирована :) Например, на 486х её можно заставить гулять от 1,6 до 25 МГц. Хотя найти платы, которые выдержат >11-12, надо ещё постараться :)
[q]
На мой взгляд, DMA гораздо удобнее для звуковых карт.
[/q]
Начнём с того, что кроме звуковых карт и дисководов, он ни для чего (массово) и не применялся. Ну и потом ещё прикрутили к LPT-портам и то скорее из-за потребности тащить обратную совместимость со старыми - он есть только в ECP-режиме, который появился в 1994, когда ISA уже стремительно устаревала.
[q]
Передавая побайтово семплы вы запаритесь выдерживать нужный период, тратя процессорное время не только на ожидание шины но и на отслеживание времени
[/q]
Вы правда думаете, что у DMA-контроллера не будет ожидания шины? Но это не главное - главное действительно отслеживание времени. Тем более, что на разных поколениях процессоров на это действительно будет тратиться сильно разное число тактов, а достаточно надёжные способы программно измерять время и определять, что вообще за процессор используется, появились только в первых пентиумах. И кстати, зачем передавать побайтово, если можно забить буфер блоком данных и пусть устройство его обрабатывает со своей скоростью? А вот выбор способа как быстрее этот буфер забить - и есть суть спора. И он вполне может оказаться зависим от размера этого буфера.
[q]
а DMA позволяет самой звуковухе вытаскивать байты из памяти с нужной частотой.
[/q]
С той частотой, на которой она способна их обработать. Кстати, в памяти они тоже должны откуда-то появиться, а кто их туда положит? Процессор. А тогда в чём разница, слать напрямую в устройство или сначала в память?
scg
Newbie


Всего сообщений: 108
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
28 фев. 2017
[q]
а вся эта возня с отдельным контроллером и кучей каналов однозначно указывает на конкретную реализацию
[/q]
Пару раз видел такую реализацию в современных встраиваемых контроллерах. Система проста в реализации и вполне сносно работает, если вам нужно предать блок данных из памяти одного контроллера в другой.
[q]
Начнём с того, что кроме звуковых карт и дисководов, он ни для чего (массово) и не применялся.
[/q]
Так больше ничего и не осталось. DMA контроллер, который мы обсуждаем как раз более всего подходит для задач, где нужно передавать большой и стабильный поток данных. Звуковые карты идеально для этого подходят. Я еще раз подчеркну: для звука нужно передавать данные не сколько быстро, сколько стабильно. И очень желательно не отвлекать на это процессор, который занимается более полезным делом - отрисовкой спрайтов.
[q]
Вы правда думаете, что у DMA-контроллера не будет ожидания шины?
[/q]
Точно такая же, как и без DMA
[q]
можно забить буфер блоком данных и пусть устройство его обрабатывает со своей скоростью? А вот выбор способа как быстрее этот буфер забить - и есть суть спора. И он вполне может оказаться зависим от размера этого буфера.
[/q]
Да, это тоже один из методов, и довольно не плохой. Но во времена ISA звуковых карт память была штукой дорогой. Помните длину FIFO буфера на последовательном порту? Если не ошибаюсь - 16 байт? Звуковухе памяти нужно гораздо больше. Автомат DMA штука простая, занимает меньше места на кристалле и неплохо выполняет свою задачу.
[q]
Процессор. А тогда в чём разница, слать напрямую в устройство или сначала в память?
[/q]
Лично я сойду с ума, если мне придется рендерить звук непосредственно в порты ввода вывода и следить чтобы не было джиттера. Вполне нормальная практика разделить рендеринг и вывод на две разные задачи даже если выводить звук непосредственно в IO порты.
Fagear
Advanced Member


Откуда: Москва, САО
Всего сообщений: 1228
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
22 янв. 2010
В общем, теоретически скорректировав кривое содержимое JED'а я сочинил некоторый GAL'озаменитель для CSM.

Прикрепленный файл (2018-12-14 21.20.00.png, 0 байт, скачан: 46 раз)
Fagear
Advanced Member


Откуда: Москва, САО
Всего сообщений: 1228
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
22 янв. 2010
Заказал прототипы реплики.

Прикрепленный файл (Скриншот 2018-12, 0 байт, скачан: 80 раз)
<<Назад  Вперед>> Страницы: 1 2 3 4 5 6 7 * 8 9
Печать
Полигон-2 »   IBM PC-совместимое. До 2000 года включительно »   Это не "дура", это FMonster
RSS

1 посетитель просмотрел эту тему за последние 15 минут
В том числе: 1 гость, 0 скрытых пользователей

Последние RSS
[Москва] LIQUID-Акция. Сливаются разъемы CF
МС7004 и 7004А на AT и XT
Пайка термотрубок
Проммать s478 PEAK 715VL2-HT ( Full-Size SBC)
Подскажите по 386 материке по джамперам.

Самые активные 5 тем RSS