Объявление форума |
Если пользуетесь личными сообщениями и получили по электронной почте оповещение о новом письме, не отвечайте, пожалуйста, почтой. Зайдите на форум и ответьте отправителю через ЛС. |
Полигон-2 » IBM PC-совместимое. До 2000 года включительно » Это не "дура", это FMonster |
<<Назад Вперед>> | Страницы: 1 2 3 4 5 6 7 * 8 9 | Печать |
pahan
Advanced Member
Откуда: Химки, М.О. Всего сообщений: 1070 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 13 мар. 2015 |
Профиль | Сообщить модератору
NEW! Сообщение отправлено: 4 декабря 2018 0:07 Сообщение отредактировано: 4 декабря 2018 0:08 Тут можно дополнить только, что буфер этот должен быть в пределах первого мегабайта, но при программировании под DOS это соблюдается почти автоматически 1) ПО выделяет в ОЗУ кусок под данные для PCM DAC (не более 64 КБ) и пихает туда сэмплы. Указывать канал на контроллере не нужно - просто у каждого из 4х каналов свои регистры адреса, размера, режима работы. Кроме этого, если выставить режим autoinitialize, по завершении передачи адрес и размер автоматически сбросятся на ранее заданные значения. Более того, если НЕ использовать autoinitialize, канал по завершении передачи автоматически будет замаскирован. 3) ПО настраивает DMA контроллер (указание канала Не знаю подробностей работы с AY, но в принципе возможен и другой режим - записью в request register DMA контроллера вы можете начать передачу по нужному каналу в любой момент, не дожидаясь, пока устройство физически дёрнет DRQ. 8) AY по таймеру выходом C дёргает DRQ. DMA контроллер выставляет адрес в памяти, с которого надо забрать данные и выставляет MEMR и IOW. DACK однозначно определяет какое устройство эти данные должно забрать с указанного адреса, отдельно выставлять адрес устройства (и вообще знать его) контроллеру не нужно. Собственно, возможная неправильная реакция какого-либо устройства в этот момент явно запрещена неактивным сигналом AEN. На последнем пункте вопрос - DMA контроллер выставляет какой-то адрес для CSM или в этом нет необходимости? Ведь канал DMA жёстко указывает на эту плату. |
Fagear
Advanced Member
Откуда: Москва, САО Всего сообщений: 1228 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 22 янв. 2010 |
pahan написал: Там очень замудрённый механизм запроса DRQ. Не знаю подробностей работы с AY pahan написал: Тогда, получается, CSM должен уметь работать двумя способами. DACK однозначно определяет какое устройство эти данные должно забрать с указанного адреса, отдельно выставлять адрес устройства (и вообще знать его) контроллеру не нужно. 1) Через DMA. 2) Прямой записью в порт. Потому что при работе через DMA от софта обращений по адресам CSM не будет (судя по кривому GAL - оно сработает просто при наличии DACK, IOW и разрешении, исходящего от AY). Однако некоторые игрушки явно пишут PCM данные просто в порт BASE+0x02: Что явно идёт в разрез с работой по DMA. [CSM] Write on port 222h, len 1, val 88h Надо пытаться запустить CSM на железе и смотреть на реальных железяках чего там куда обращается. |
pahan
Advanced Member
Откуда: Химки, М.О. Всего сообщений: 1070 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 13 мар. 2015 |
Конечно. И ещё в идеале выдавать прерывание. Повторюсь - для ПО (CPU) способа узнать, что передача по DMA данных конкретному устройству закончена, нет. Обычно делают так - устройство,увидев импульс TC, генерит IRQ. Тогда, получается, CSM должен уметь работать двумя способами. Да, этого абсолютно достаточно, чтобы принять данные. Потому что при работе через DMA от софта обращений по адресам CSM не будет (судя по кривому GAL - оно сработает просто при наличии DACK, IOW и разрешении, исходящего от AY). Думаю принципиальна здесь пересылка по одному байту за раз. Да, это можно реализовать через DMA, есть даже специальный режим у DMA-контроллера - single transfer, когда из всего буфера будет пересылаться 1 байт за раз, а в промежутках CPU будет позволено тоже что-то полезное сделать. Но всё это из серии - "но зачем???". DMA имеет смысл именно для довольно больших блоков (те самые килобайты). Однако некоторые игрушки явно пишут PCM данные просто в порт BASE+0x02:Что явно идёт в разрез с работой по DMA. [CSM] Write on port 222h, len 1, val 7eh Вообще утверждение, что DMA - самый быстрый режим передачи, заслуживает серьёзного расследования и разрушения мифа. Во времена всяких XT это действительно было так - частоты проца и DMA-контроллера (а у него не больше 4,77 МГц) близки, процы даже на элементарные команды тратили кучу тактов. Думаю, с 486х (а может даже 386х, считать надо) любая возня с DMA будет реально неоправдана - на простейшие команды не больше нескольких тактов, да ещё на в разы более высокой частоте... |
scg |
Для процессоров, которые работают на частотах выше частоты шины, обращение напрямую к шине (опереции ввода-вывода не кешируются) будет его сильно тормозить. С появление PCI DMA вообще стало основным способом общения перефирии с остальной системой. Думаю, с 486х (а может даже 386х, считать надо) любая возня с DMA будет реально неоправдана - на простейшие команды не больше нескольких тактов, да ещё на в разы более высокой частоте... |
pahan
Advanced Member
Откуда: Химки, М.О. Всего сообщений: 1070 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 13 мар. 2015 |
Именно так. Только к классическому ISA DMA, который мы в данном случае обсуждаем, всё это не имеет никакого отношения. В PCI и более поздних фактически этот режим называется bus mastering и позволяет любому устройству без всяких посредников (а именно DMA-контроллера) обращаться напрямую к любому другому устройству, в том числе памяти. С появление PCI DMA вообще стало основным способом общения перефирии с остальной системой. Однако частота шины в данным случае всё равно остаётся в разы выше частоты ISA DMA-контроллера. Для процессоров, которые работают на частотах выше частоты шины, обращение напрямую к шине (опереции ввода-вывода не кешируются) будет его сильно тормозить. |
scg |
Имеет - не имеет, но исторически DMA победил. Значит что-то в нем полезное есть. Только к классическому ISA DMA, который мы в данном случае обсуждаем, всё это не имеет никакого отношения. Разве частота ISA шины не постоянна? Однако частота шины в данным случае всё равно остаётся в разы выше частоты ISA DMA-контроллера. На мой взгляд, DMA гораздо удобнее для звуковых карт. Передавая побайтово семплы вы запаритесь выдерживать нужный период, тратя процессорное время не только на ожидание шины но и на отслеживание времени, а DMA позволяет самой звуковухе вытаскивать байты из памяти с нужной частотой. |
pahan
Advanced Member
Откуда: Химки, М.О. Всего сообщений: 1070 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 13 мар. 2015 |
А я и не отрицал его полезность как принципа. Я имел в виду лишь устарелость конкретной реализации этого принципа (а вся эта возня с отдельным контроллером и кучей каналов однозначно указывает на конкретную реализацию) с развитием PC-железа. Которую и производители прекрасно понимали в то время - уже в EISA (1988 год) были введены более быстрые и несовместимые режимы. Имеет - не имеет, но исторически DMA победил. Значит что-то в нем полезное есть. Ага. Более того, она даже нигде формально не стандартизирована Например, на 486х её можно заставить гулять от 1,6 до 25 МГц. Хотя найти платы, которые выдержат >11-12, надо ещё постараться Разве частота ISA шины не постоянна? Начнём с того, что кроме звуковых карт и дисководов, он ни для чего (массово) и не применялся. Ну и потом ещё прикрутили к LPT-портам и то скорее из-за потребности тащить обратную совместимость со старыми - он есть только в ECP-режиме, который появился в 1994, когда ISA уже стремительно устаревала. На мой взгляд, DMA гораздо удобнее для звуковых карт. Вы правда думаете, что у DMA-контроллера не будет ожидания шины? Но это не главное - главное действительно отслеживание времени. Тем более, что на разных поколениях процессоров на это действительно будет тратиться сильно разное число тактов, а достаточно надёжные способы программно измерять время и определять, что вообще за процессор используется, появились только в первых пентиумах. И кстати, зачем передавать побайтово, если можно забить буфер блоком данных и пусть устройство его обрабатывает со своей скоростью? А вот выбор способа как быстрее этот буфер забить - и есть суть спора. И он вполне может оказаться зависим от размера этого буфера. Передавая побайтово семплы вы запаритесь выдерживать нужный период, тратя процессорное время не только на ожидание шины но и на отслеживание времени С той частотой, на которой она способна их обработать. Кстати, в памяти они тоже должны откуда-то появиться, а кто их туда положит? Процессор. А тогда в чём разница, слать напрямую в устройство или сначала в память? а DMA позволяет самой звуковухе вытаскивать байты из памяти с нужной частотой. |
scg |
Пару раз видел такую реализацию в современных встраиваемых контроллерах. Система проста в реализации и вполне сносно работает, если вам нужно предать блок данных из памяти одного контроллера в другой. а вся эта возня с отдельным контроллером и кучей каналов однозначно указывает на конкретную реализацию Так больше ничего и не осталось. DMA контроллер, который мы обсуждаем как раз более всего подходит для задач, где нужно передавать большой и стабильный поток данных. Звуковые карты идеально для этого подходят. Я еще раз подчеркну: для звука нужно передавать данные не сколько быстро, сколько стабильно. И очень желательно не отвлекать на это процессор, который занимается более полезным делом - отрисовкой спрайтов. Начнём с того, что кроме звуковых карт и дисководов, он ни для чего (массово) и не применялся. Точно такая же, как и без DMA Вы правда думаете, что у DMA-контроллера не будет ожидания шины? Да, это тоже один из методов, и довольно не плохой. Но во времена ISA звуковых карт память была штукой дорогой. Помните длину FIFO буфера на последовательном порту? Если не ошибаюсь - 16 байт? Звуковухе памяти нужно гораздо больше. Автомат DMA штука простая, занимает меньше места на кристалле и неплохо выполняет свою задачу. можно забить буфер блоком данных и пусть устройство его обрабатывает со своей скоростью? А вот выбор способа как быстрее этот буфер забить - и есть суть спора. И он вполне может оказаться зависим от размера этого буфера. Лично я сойду с ума, если мне придется рендерить звук непосредственно в порты ввода вывода и следить чтобы не было джиттера. Вполне нормальная практика разделить рендеринг и вывод на две разные задачи даже если выводить звук непосредственно в 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 |
1 посетитель просмотрел эту тему за последние 15 минут |
В том числе: 1 гость, 0 скрытых пользователей |
Последние | |
[Москва] LIQUID-Акция. Сливаются разъемы CF МС7004 и 7004А на AT и XT Пайка термотрубок Проммать s478 PEAK 715VL2-HT ( Full-Size SBC) Подскажите по 386 материке по джамперам. |
Самые активные 5 тем | |