Меня вполне устраивает чановский API, в принципе, запустить бы пример от Чана. Просто его сэмплы недописанные - начинаешь смотреть, а там то и дело "// здесь надо преобразовать то-то в то-то".Сообщение от Hunta
Под кубиками я подразумеваю STM32CubeMX с его кривыми, как бумеранг, драйверами HAL. Сильно не хочется воевать с ошибками этого HAL'а вместо собственных...
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
Великое дело сделали. Причешете... Всё хорошо будет
Patron, а где указать эмулятору, чтобы он использовал HD V4 или V5 ?
И еще. Я правильно понимаю, что если я добавлю в драйвер HD V4 и V5 в циклы чтения и записи ожидание бита готовности (0200) перед каждым принимаемым/передаваемым словом, то оно должно работать в эмуляторе? Это я к тому, что слона надо есть по кусочкам - сначала V4 в простейшем PIO-mode, а когда заработает, буду двигаться дальше. Оно, конечно, неэффективно (лишние две команды в цикле передачи данных, который мог бы быть на эти две команды короче, но это требуется вмешательство в эмулятор), но для начала сойдет. Поскольку отлаживать одновременно и железо (точнее, софт в МК), и драйвер, это сложнее не вдвое, а больше.
- - - Добавлено - - -
Нет, конечно, я понимаю, что в рамках V4/V5 тоже можно организовать поблочную работу - аккуратно отсчитывать заполнение блоков и делать ожидание только в момент окончания очередного блока, в том числе, для V5 ждать прерывания, но это солидное усложнение драйвера, а я основательно подзабыл приёмы драйверописательства для RT-11, и сейчас заниматься еще и этим как-то не с руки.
А отлаживать драйвер одновременно с железом на ДВК, как новое устройство - так у меня на ДВК-шнике, кроме моей железки, ничего нет, не через HX же гонять MACRO с LINK'ом? То есть, конечно, можно все сгенерить в эмуляторе, засунуть драйвер в HX.DSK, или как там его, загрузить ДВК с HX и пробовать. В крайнем случае так и сделаю...
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
При эмуляции тип эмулируемого контролера HD задаётся "секретным" параметром: HD_InterfaceType в разделе HD.ini. Значение по умолчанию HD_InterfaceType = 2 соответствует обычному контроллеру HD.
Нет, цитирую описание:Имитировать "безблочную" работу так не получится - надо делать в эмуляторе новое устройство.После подачи команды записи - контроллер снимает флаг READY ( 0200 ) и в регистр данных нужно (без каких-либо других обращений) записать количество слов, равное текущему значению "СЧЁТЧИК СЛОВ", после чего контроллер снимает флаг NO.DMA и выполняет запись. Завершение записи приводит к установке в CSR флагов READY и NO.DMA.
На мой взгляд - сначала надо детально продумать работу "блочного" контроллера (всем миром), потом добавить такой контроллер в эмулятор и написать для него драйвер (это я сделаю).
Например - в любой из фаз работы контроллера операционка может вылететь и запустить начальный загрузчик. Как начальный загрузчик выполнит сброс контроллера на любой из фаз его работы, сколько времени это займёт, нужно ли начальному загрузчику ждать готовности контролера после сброса или при неготовности контроллера после сброса - завершить работу с выдачей сообщения, чтобы пользователь сам дождался завершения сброса контроллера и перезапустил начальный загрузчик.
Недоглядел. Жаль, я бы уже начал.
В смысле, блочную...
ОК. Думаем. Мне больше импонирует, так сказать, "раздельное заряжание". То есть, при записи подаем отдельную команду "принять с МПИ в буфер", передаем без ожиданий любое количесво слов от 1 до 256 включительно, затем даем команду "писать на СД", и контроллер запишет это дело по заданному адресу, с отключением и переходом в состояние "Думаю, прошу не мешать". Ну, и при чтении - даем команду "читать с СД в буфер", контроллер, опять же, отключится, прочитает блок с СД-шки, подключится снова, выдаст прерывание, и, получив команду "передать содержимое буфера на МПИ" быстренько передаст прочитанное.
Я, конечно, не настаиваю, но, ИМХО, так будет лучше.
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
Это алгоритм работы контроллеров DX ( если без ДМА ) и DY ( если с ДМА ).
Можно сделать упрощённый аналог контроллера DX ( например FX ), которому вместо номеров дорожки и сектора надо передавать только номер блока, а остальную логику работы оставить без изменений. Правда, такое устройство не сможет работать с образами больше 32М, но для первого варианта реализации в эмуляторе и железе это и не особо надо.
При таком подходе полезно то, что на DX есть полная спецификация, которую можно реализовать без долгих раздумий.
На эту тему два возражения. Одно непринципиальное - мне сложно сменить адрес, он в "заглушке", за 5 минут я его не сменю, так, что лучше бы оставить 177720. Второе - принципиальное. А что делать с нормальным DX-ом? 1201.01 или .02 плюс ГМД-7012 - вполне работоспособная конфигурация, мою железяку, получается, в неё не воткнуть?
Нет, я не настаиваю на своем варианте, может быть, есть что-то лучше?
- - - Добавлено - - -
Кроме того, мне нравится способ передачи параметров у HD.
- - - Добавлено - - -
Нет, на этом я тоже не настаиваю. Вообще, ИМХО, приспосабливать HD, устройство, изначально запланированное на DMA - неважно, реальный, или мгновенный, к работе в PIO-mode было ошибкой. В PIO-mode должно работать другое устройство, пусть и с похожим способом передачи параметров, но другое. Так, что, вероятно, имеет смысл изменить адрес. Если наш проект когда-нибудь дорастёт до DMA, тогда можно будет вернуться к идее реализации HD в железе, а пока надо делать что-то другое. ИМХО.
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
PDP - это устройство с ограниченным ресурсом - памятью. Да и быстродействие тоже ограниченный ресурс.
Значит, надо делать так, что бы драйвер был максимально простым и не затратным. Блок параметров в памяти, а не регистры устройства, PIO, а не DMA - это напрасный расход ресурсов и затраты.
Уже две ошибки, а не одна.
Угу. Только вот готовый макет, пригодный для работы в PIO-mode у меня есть, стоит рабочий, включай, загружай в МК софтину, переключайся в окно VT52 и пробуй, как работает. А вариант с DMA я не потянул, хоть и собирался сначала - я с трудом справился с имеющимся десятком микросхем, зрение не позволяет, а для DMA надо два десятка!
Ты сделай такой макет с DMA, я с удовольствием подключусь к твоему проекту. А так...
Да и не так страшен черт, как его малюют. Да, тот самый "мгновенный" HD занимает всего 88 слов. Тот же, допустим, MY - 145. А творение Патрона в "безблочном" PIO-mode - порядка 130. Ну, пусть для разбиения на блоки понадобится еще 2-3 десятка команд, грубо - 50 слов. Итого 180. Тот же DW занимает около 500 слов, а MX вообще 2 тыс. с гаком! Сильно тебя напрягут потерянные 100 слов на драйвере SD-шки в PIO-mode? Да не морочь голову!
Единственное, чего следует опасаться, это то, что заработает этот проект и народ решит, что хватит, обойдемся без DMA. И красивая идея останется нереализованной. Но я надеюсь, что мы все-таки не остановимся - в частности, на этом базисе (с DMA) можно реализовать и кое-что другое. Допустим, тот же МТ - Патрон в процессе написания эмулятора детально разобрал структуру записи информации на магнитные ленты, хоть прямо сейчас садись и пиши контроллер. Есть и еще кое-какие мысли, в общем, не остановимся.
Последний раз редактировалось AFZ; 17.11.2018 в 07:00.
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
Как только получится купить осциллограф (один раз загадывал, больше загадывать не буду) - займусь.
Он будет на FPGA
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием