Это точно тема для "Программирования" в разделе ZX Spectrum Software? Может, перенести ее туда, где больше почитателей 51-й серии найдется?
Это точно тема для "Программирования" в разделе ZX Spectrum Software? Может, перенести ее туда, где больше почитателей 51-й серии найдется?
ZX Evolution Rev C + ZXM-SoundCard Extreme + NeoGS.
Согласен. Я только не особо понял структуру форума(
Правильно ли я понял, что стоит задача организовать в ПЗУ файловую систему, т.е. определить формат служебной и полезной информации о хранящихся в этом ПЗУ файлах?
Если да, то нужно хоть немного почитать матчасть о построении файловых систем.
Самый простой пример файловой системы - TR-DOS. В TR-DOS достигнута предельная простота, но файлы не могут менять свой размер. Можно только стереть файл и записать на диск новый - пока не исчерпается свободное место. Место, которое занимали стертые файлы, просто так повторно использовать нельзя. Чтобы вернуть его "в оборот", необходимо двигать файлы по диску, чтобы их уплотнить. Эта операция может быть довольно долгой. Но не смертельной. Многие из присутствующих "жили" под TR-DOS с реальными дисководами.
Примеры чуть посложнее - Apple ][ DOS, CP/M. В этих файловых системах файл может быть фрагментирован - т.е. разбросан кусками по диску. Место, занимаемое стертыми файлами, может быть использовано для записи кусков новых файлов.
Еще более продвинутая ФС - Microsoft FAT12. Здесь тоже файлы могут быть фрагментированы. Но реализовать полноценную MS FAT12 довольно сложно из-за того, что в ней могут быть длинные файлы (которые не влезут в твое ОЗУ), а также поддерживаются вложенные подкаталоги. Можно на базе идей FAT сделать что-нибудь упрощенное, вроде файловой системы ADS от Andrew Strikes Code (используется в музыкальном редакторе ASM).
Определять же начало файла по "преамбуле" или конец файла по "скоплению нулей" - значит напрашиваться на неприятности. Что, если в каком-нибудь файле встретится такая же последовательность байт, как в преамбуле? Это приведет к ложному обнаружению файла, т.е. к сбою файловой системы. То же касается "скопления нулей" - если такое скопление они вдруг окажется частью какого-нибудь файла - то это приведет к ложному детектированию конца файла.
В некоторых древних файловых системах конец файла определяется по определенному байту (0x1A), но при этом гарантируется, что этот байт нигде в файле не встретится, а только в его конце. Такой подход накладывает ограничения на содержимое файлов.
Размер сектора 256 байт - это как-то многовато для накопителя объемом 32Кб. Как бы так не вышло, что накопитель будет неэффективно использоваться. У этой флеш-памяти есть минимальный размер страницы для стирания или записи? Какой он имеет размер? Лучше сделать размер сектора равным размеру минимального блока, который можно за раз стереть.
Последний раз редактировалось Barmaley_m; 11.12.2016 в 01:52.
Спасибо за развернутую подсказку. ФС TR-DOS даже не рассматривал, только сейчас почитал о ней. И вот какая мысль крутится у меня в голове уже довольно длительное время - а не отдать ли часть работы ЦП какому-нибудь быстрому МК, например STM8S207, который как раз имеется. Сделать его частью адресного пространства, а уже в МК реализовать поддержку ФС. Можно даже FAT32. 51-й (и, вроде, 8085) выдают старшую часть адреса с самого начала обращения к памяти, так что МК, работая на 24МГц, должен успеть защелкнуть адрес. Я понимаю, что использование в составе системы на старой элементарной базе современных МК сильно не приветствуется в Вашем сообществе, т.к. их скорости сильно выше тех же Z80, 8051 и прочих. Но несомненный плюс для меня заключается в том, что 51-й может исполнять загружаемый в ОЗУ код и объемы этого ОЗУ сильно больше даже некоторых ARM. С AVR такое не прокатит, с STM8 тоже. STM32 мне пока без боя сдаваться никак не хотят(
Вернусь к идее. Все в курсе как выглядит CF или HDD IDE со стороны проца? Несколько регистров и все. Аналогично хочу сделать с STM. У нее много ног, она нафарширована всякими АЦП и таймерами. Цепляю к ней клавиатуру от нетбука (уже в наличии и я вызвонил ее схему), RTC, SD карточку, дисплей. Одна нога МК пойдет на ногу прерывания 51-го. В обработчике 51-й спросит у МК номер прерывания (что именно вызвало) и обработает. Сейчас обдумываю таблицу регистров и их назначения. Единственное, что меня тревожит - успеет ли МК ответить, вписаться в стандартный цикл чтения/записи 51-го. Особенно, если я позже решу задрать ему частоту повыше 11.0592. Проблемы с RS232 не будет, т.к. это теперь тоже головные МК)
Можно, но зачем? Быстродействия 8051 хватит за глаза для реализации файловой системы (хоть FAT32) не то, что в флешке, а даже на реальном дисководе, где быстродействие программы критично. Лишь бы только мозгов программиста хватило на реализацию необходимых процедур. Я бы начал с реализации ФС на языке C, а потом либо компилятор нашел под нужную платформу, либо вручную перевел на ассемблер. Программу можно изначально писать на обычном компе. Отлаживать ее в свое удовольствие, а потом адаптировать отлаженный алгоритм к целевой платформе.Сообщение от alm604
За все сообщество не скажу, а мне в принципе все равно, на какой элементной базе реализовано решение, лишь бы оно работало.
Когда медленный МК управляет быстрым - это получается "хвост вертит собакой", выглядит некрасиво. Но иногда даже на PC встречается подобное. Например, видеокарта быстрее, чем процессор, решает некоторые задачи. Тем не менее она работает как периферия, а ведущее устройство в системе - процессор.
У некоторых МК для этих целей имеется периферия под названием "Parallel Slave Port". Это аппаратное устройство может выдержать очень жесткие рамки циклов чтения-записи, буферирует данные и ослабляет нагрузку на центральный процессор МК.
Я пробовал использовать fatfs от Чена как раз на STM8. Довольно шустрая либа. Вот только флеша она сожрала больше 20 КБ. В описании библиотеки я видел, что она может использоваться и на 51-ых, но не встречал в интернете реализации. Сам адаптировать не пробовал. Для такой подпрограммы потребуется подмена ПЗУ. В принципе это реализуемо даже без использования GAL или CPLD. Просто я не нашел это изящным решением, видимо. К тому же еще хочу и клавиатуру подключить, и часы... В общем тут прям просится периферийный контроллер. Но, в любом случае, спасибо за советы. Очень помогает взгляд на архитектуру со стороны.
Для 51-го - избыточно.
Для чего? Дрыгать двумя лапками на SD можно даже программно, а уж если есть внутренний SPI, то вопрос вообще можно не рассматривать. Поддержка FAT32 отнимет 4-5 Кб ПЗУ на ассемблере, и ещё 2-3 Кб ОЗУ под буферы, если не хочется лишних тормозов. На мой взгляд, было бы разумным в ПЗУ содержать только загрузчик основных программ с SD в ОЗУ, а уже развёрнутые процедуры, например, полноценной работы с FAT, запускать в ОЗУ, благо 51-й может код исполнять из него.
P.S. Любопытно взглянуть на схему имеющегося прототипа.
Написать поддержку FAT32 на асме для меня - что-то маловероятное. Тем более утолкать его в 4-5 КБ. Как я упоминал, уже написанная библиотека (правда почти с полными возможностями ФС - создание файлов, папок и прочим) заняла более 20 КБ. А у меня ПЗУ сейчас только 8 КБ отведено. Это чтоб увеличить объем ОЗУ из которого можно выполнять программу. И хотелось бы его еще уменьшить. Так что дело не в ногах.
Схемы я еще толком не рисовал. Так, наброски. А плату сделал. Ну бывает у меня так. Вот я фото выкладывал: http://zx-pk.ru/threads/26190-proshu...6v8/page2.html.
И вторая плата сверху ставится: https://yadi.sk/i/oxgQOZK033EWiM. На ней пара GPI и пара GPO, плюс дисплей. Схемы тоже нет) не рисую, если тут всего несколько микросхем.
Последний раз редактировалось alm604; 12.12.2016 в 17:54.
Его я выбрал из соображений возможности выполнения кода из ОЗУ и потому, что у меня их очень много. Еще есть Z80 пара штук, 8080, 8085 (по одному каждого), MB89, MB90, H8, XA-G3(очень интересный камешек), SH2, SH4, ВМ86, Am186, 80286, 80196. Это те, которые каким-либо образом могут выполнять код из ОЗУ. Но для большинства из них нет сред разработки и программаторов, сложные для меня архитектуры. Для 51-го есть готовый и мощный бейсик, хороший, документированный монитор, который я легко могу переписывать под свои нужды. Конкурентом ему вижу пока только Z80, для которого тоже уйма ПО есть, но так вышло, что для 51-го я уже плату макетную сделал. К тому же, видел много SBC на Z80, а на 51-м всего с десяток и те работают по терминалу или на LCD 2*16, что для меня как-то несерьезно. ПК, как таковых на 51-ых не собирали.
По-этому то я и говорю, что избыточно.
Ведь в случае прикошачивания STM придётся изобретать протокол обмена между оным и MCS51, что порой чревато ещё большими трудностями, которые могут быть изначально не на поверхности.
С другой стороны, это лишь моё личное видение решения задачи, сообразно моему личному опыту работы с 51-м семейством. Не обращайте внимания на брюзжание, не опускайте рук, делайте - это как минимум интересно
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием