CGA и CF IDE адаптер на Altera MAX10

[Tronix]

Драйверы сетевых адаптеров

Скачать свои дрова и дизасемблернуть, не?

[newold86]

Просто офигеваю, какой я умный
Как-то сходу DMA заработал, как железная, так и софтовая часть... Правда, честно признаюсь - идею украл у XT-CFv3...

Пока только читает через DMA загрузочный сектор. Чтобы полностью все сделать, нужно допилить переход буфера в памяти через 64К, а мне так лень этим заниматься (ненавижу кропотливую работу над деталями, когда задача принципиально решена)...

[newold86]

Блин, просто офигеваю, какой я бестолковый
Все работает на первый взгляд классно, только вот в логике есть одна принципиальная проблема, которую даже не знаю, как решать... У меня чтение из порта модуля SD карты инициирует процесс чтения этого байта по SPI из самой карты. На время чтения все притормаживается сигналом IOREADY. В случае с процессором это работает без проблем, а вот с DMA я совершенно забыл, что память живет своей жизнью. В начале каждой операции DMA по чтению байта из порта и записи его в память контроллер DMA тоже нормально притормаживается на период чтения этого байта из карты, но вот память не ждет, и спокойно записывает в себя то, что находится на шине данных в этот момент. А находится там байт от предыдущего чтения с карты, т.е. первый байт в памяти оказывается мусором, ну а далее все остальные байты сдвинуты на один.
Кроме как принципиально усложнять модуль работы с SD картой (чтобы он сам готовил байты и запрашивал DMA по готовности), даже не знаю, что еще можно сделать...

[Vic3Dexe]

но вот память не ждет, и спокойно записывает в себя то, что находится на шине данных в этот момент

В смысле? Память пишет по заднему фронту (подъему) /WR, он же /MWR, не?
Если вы тормозите DMA по IORDY, то он затягивает длительность /MWR, и отпускает его только когда ваше уст-во "готово", т.е. на шине корректные данные.

[newold86]

но вот память не ждет, и спокойно записывает в себя то, что находится на шине данных в этот момент

В смысле? Память пишет по заднему фронту (подъему) /WR, он же /MWR, не?
Если вы тормозите DMA по IORDY, то он затягивает длительность /MWR, и отпускает его только когда ваше уст-во "готово", т.е. на шине корректные данные.

Вот я тоже так думал - насчет заднего фронта. Мало того - сначала я даже думал, что слишком быстро отпускаю iordy после появления правильных данных на шине, поэтому искусственно его продлял, но это не помогло. Начал смотреть схемы и datasheet на память ~ такое впечатление, что запись идет по заднему фронту CAS, который вроде не продляется...
Еще меня смущает, что я нигде пока не смог найти требования по времянкам для DMA - в какие временные параметры должно укладываться устройство, использующее DMA...

[Vic3Dexe]

Гм... так а какая нафиг разница, кто генерит цикл записи - DMA или CPU. CAS/RAS должны вести себя абсолютно одинаково.
Если затягивание цикла работает при CPU-обмене, то должно работать и при DMA-обмене.
Описание времянок в даташите на 8237 должно быть (навскидку).

[newold86]

Если затягивание цикла работает при CPU-обмене, то должно работать и при DMA-обмене.

Две совершенно разные вещи. При чтении из порта процессором сам процессор приостанавливается и ждет готовности байта из SPI. Затем процессор глотает этот байт и потом уже сам пишет его в память, при этом цикл запись в память идет без ожидания (ну, или там память сама может снять iordy на нужное для нее время, если сразу не готова)
При DMA сама память ждет готовности байта, и это, похоже, ей не нравится...

Описание времянок в даташите на 8237 должно быть (навскидку).

Это времянки самого 8237, меня же интересуют требования памяти. Например, через сколько времени после выставления контроллером DMA сигнала MEMWn необходимо выставить данные на шину данных для записи, и сколько их там нужно держать. В конце-концов, хотя бы однозначный ответ, в какой момент происходит запись в память ???

[Vic3Dexe]

Две совершенно разные вещи

Точно. Спал на ходу уже

требования памяти

Даташит на память?
Для 41256 (РУ7) указано, что данные пишутся по фронту (т.е. по переходу 1 -> 0) сигналов /CAS или /WE, смотря кто из них наступит позже.
При этом, данные уже должны быть на DI и держаться там от этого момента не менее 40 нс.

[Mixa64]

Ага, посмотрел про РУ3, там та же фигня, данные защелкиваются по спаду CAS при активном WE или по спаду WE при активном CAS. Одинаково они все работают, различаются только объемом.
В XT контроллера памяти как такового нету, времянка RAS/CAS/WE формируется задержками из стробов чтения-записи. Я уж не помню, как там в деталях и подробностях устроено, но самое простое (имхо) - WE на память формировать из WRMEM при условии активного READY. Пришел WRMEM, запустили как обычно RAS/CAS, WE придерживаем до момента как появится READY. Подразумевается, что к появлению READY данные для записи уже есть. (название WRMEM - условное, единый строб для памяти, формируемый из требования процессора или DMA, смотря кто из них активен.)

[newold86]

WE придерживаем до момента как появится READY. Подразумевается, что к появлению READY данные для записи уже есть. (название WRMEM - условное, единый строб для памяти, формируемый из требования процессора или DMA, смотря кто из них активен.)

Такое впечатление, что памяти глубоко наплевать на READY (если под этим подразумевается CHRDY) - как я уже писал, у меня не получается придержать момент записи в память байта с шины данных...

[Vic3Dexe]

но самое простое (имхо) - WE на память формировать из WRMEM

Это все хорошо, но тут готовая мать, на которой DMA, который не может тормозить память...

А сколько времени занимает чтение по SPI?
Если очень много, то, может нет смысла вообще городить DMA?
Или же можно вычитать весь сектор превентивно, все равно обмен с диском секторами идет.

Посмотрел, почему у меня все работало. Мое DMA сначала читало флоп, потом писАло в память, т.е. двумя циклами, хоть и очень плотно расположенными, плюс буфер данных в самом DMA.

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

Так вот, обучите платку реагировать на команду seek, в процессе "выполнения" которой читайте в буфер альтеры "трек", ну т.е. сколько там секторов на дорогу, согласно геометрии CHS.
Далее, по запросу DMA отдавайте.

[newold86]

Это все хорошо, но тут готовая мать, на которой DMA, который не может тормозить память...

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

А сколько времени занимает чтение по SPI? Если очень много, то, может нет смысла вообще городить DMA?

Вообще смысл есть, особенно для медленных компьютеров. Тупое чтение из порта и выгрузка в память через in - stosb на стандартной XT дает около 180К/с при отсутствии дополнительного ожидания на прием байта из SD карты. С DMA, по результатам моих экспериментов, получилось бы более 300К/с уже с чтением из карты. Однако для 286 с более высокой тактовой частотой и дополнительными командами, интерес был бы только академический.

По крайней мере, в ХТ это же как-то работало?

Насколько знаю, там чтение из гибкого диска вообще идет побайтно - контроллер приготовил байт, потом выдает запрос на DMA

Так вот, обучите платку...

Да есть у меня куча вариантов, как можно обойти проблему. Только сейчас все выглядит красиво и просто, а так придется городить сложную конструкцию. Самое главное - понадобится буфер под FIFO, и сразу же станет вопрос о возможности реализации данного устройства на простом CPLD...

[Vic3Dexe]

Вообще смысл есть, особенно для медленных компьютеров.

Я про то, что если скорости SPI не хватает для обмена с RAM на ее скорости, то накладные расходы на DMA только замедлят обмен по сравнению с CPU, даже на 8088@4.77

там чтение из гибкого диска вообще идет побайтно - контроллер приготовил байт, потом выдает запрос на DMA

Может быть, сам уже не помню точно чего там и как.
Кто мешает этот самый on-demand в вашем случае? Биос ваш, контроллер ваш.

так придется городить сложную конструкцию

Ой... как все просто выглядело у меня в голове, когда я свое городить начинал

[newold86]

Я про то, что если скорости SPI не хватает для обмена с RAM на ее скорости, то накладные расходы на DMA только замедлят обмен по сравнению с CPU, даже на 8088@4.77

Долго объяснять сейчас не могу, поэтому поверьте на слово - при выбранном мною подходе DMA помогает (цифры приводил чуть выше). Если кратко, то поток от SPI медленнее памяти, но намного быстрее цепочки - SPI - CPU - память. И даже с памятью проблема не столько в медленном потоке, а в его сдвинутости по фазе относительно времянок памяти

Кто мешает этот самый on-demand в вашем случае?

Побайтно - нет проблем, но тогда расходы на DMA как раз на корню всю идею перечеркнут. Через FIFO - уже раньше объяснял.

[Vic3Dexe]

поэтому поверьте на слово

Да без проблем, мне-то что

В общем ладно, я все, что знал - рассказал.