А зачем SD прикручивать к винту? Я так думал это будет отдельный контроллер, как раз для замены винта.
Уже прикидывал. Но только недавно достал 74HC4050, для согласования уровней. Делать буду на PIC, под мегу нет программатора.
А зачем SD прикручивать к винту? Я так думал это будет отдельный контроллер, как раз для замены винта.
Уже прикидывал. Но только недавно достал 74HC4050, для согласования уровней. Делать буду на PIC, под мегу нет программатора.
под мегу программатор - пять проводов на лпт-порт.
просто готовый проект. эмуляция ПЗУ не нужна. и софт переделывать надо только на компе.
опять таки работа с FAT, а не со всякой экзотикой. я потому и интересовался - как запускать проги, загруженные в память не с магнитофона.
ПК8000 "Веста", "Сура". ПК8002 "Эльф". ПК8010,8020 "Корвет".
Как без ПЗУ грузиться то с SD? И с каких пор CP/M стала экзотикой?Смысл в FAT?
мега сначала эмулирует ПЗУ, этот код можно выбросить и грузиться из настоящего ПЗУ.
с FAT на ББ по-любому работать удобней.
на крайняк мона код меги переработать, ей то пофигу, что читать:FAT, раздел CP/M или еще что. например, мона работать с образами флоппи-дисков, будет сразу эмулятор и контроллера флопа и самого флопа
Последний раз редактировалось hantarex; 24.03.2015 в 20:27.
ПК8000 "Веста", "Сура". ПК8002 "Эльф". ПК8010,8020 "Корвет".
Посмотрите на наш проект extrom для корвета
Там реализована именно такая схема
Сначала имитация внешнего пзу
Потом уже в режиме api
Доступ к образам дисков с sd карты
для cpm там все очень красиво
Как? По схеме она контролирует лишь 8 адресных линий. Для эмуляции ПЗУ необходимо 16.Сообщение от hantarex
В нашем случае получаем:
16 линий - шина адреса
8 линий - шина данных
линия Чт/вв
линия Зп/вв
линия Reset
2 линии для программатора
2 линии под кварц
4 линии для SD-карт
2 линии питания
------
37 линий. 35 если без кварца. То есть ATMEGA328P по определению никак не катит. Если же отказаться от 8 линий адреса, то загрузка с SD будет в принципе невозможна.
Общепринятый у разработчиков подход - контроллер предоставляет доступ низкого уровня, а файловая система - это уровень ОС. Поэтому я представлял контроллер как простой конвертер [шина данных] <--> [SD], аппаратно независимый от типа файловой системы и тем более ОС. Так и требования к МК значительно понижаются, можно выбрать самую дешовую модель.
Вроде SD хотелось подключить из-за удобства портации файлов. В чем удобство работать с образами дискет?например, мона работать с образами флоппи-дисков, будет сразу эмулятор и контроллера флопа и самого флопа
Вообще же у ПК8000 есть предусмотренные разрабами средства для загрузки с внешних носителей, независимо от их типа. В чем смысл отказываться от этой фичи и строить велосипед?
---------- Post added at 04:44 ---------- Previous post was at 04:41 ----------
Что-то схему не увидел, можно ссылку? Или хоть на какой примерно странице?
Посмотрите на наш проект extrom для корвета
Там реализована именно такая схема
Сначала имитация внешнего пзу
Потом уже в режиме api
Доступ к образам дисков с sd карты
для cpm там все очень красиво
ПЗУ эмулируется всего на 256 байт, только загрузчик. в подробности особо не вникал.
нечто похожее я пытался замутить на Atmega16, на 20Mhz. 8 данных, 8 адресов, три прерывания - два на чт\зп. портов вв, одно - на чт. памяти.внешний дешифратор адреса(старшие 8 бит) и схема формирования CS. теоретически на 20Мгц цикл шины меги составит 50нс, цикл шины ВМ80 - что-то около 130-150нс, скорости должно хватить. только дальще прикидок и полуспаяной макетки дело не продвинулось
---------- Post added at 08:43 ---------- Previous post was at 08:41 ----------
образы срм, хранятся на фат
а ежели повыпедриваться и взять какой-нить ARM с USB-хостом - так ваще сказка будет
хотя есть коньроллеры на ядре MCS51, с USB-хостом, используются в атомобильных плеерах-трансмиттерах, там и USB и SD и внешняя память - все удовольствия
Последний раз редактировалось hantarex; 25.03.2015 в 08:53.
ПК8000 "Веста", "Сура". ПК8002 "Эльф". ПК8010,8020 "Корвет".
В ПК8000 загрузчик стартует только с адреса 0x4000, так что 8 или 4 битами не отделаться, придется заводить все 16 линий. Или часть линий заводить на отдельный дешифратор.
Вопрос спорный. Для переноса образов на SD сторонний софт конечно не понадобится, но вот для создания и изменения самих образов - полюбому. И в чем принципиальная разница - пользоваться софтом для переноса файлов, или пользоваться софтом для работы с образами?образы срм, хранятся на фат
я про это уже писал. CS устанавливается при обращении по адресу 4000Н, дальше мега сама дешифрует младшие адреса.
пустых образов море, а переносить в них файло мона из эмулятора уважаемого b2m.
для начинающего юзера нет риска затереть винт, например
ПК8000 "Веста", "Сура". ПК8002 "Эльф". ПК8010,8020 "Корвет".
вот весь проект.
https://bitbucket.org/esl/korvet-extrom-forth32
но там несколько другое, ПЗУ подключено к ВВ55.
моя идея оптимизации:
мы ТОЧНО знаем порядок чтения байт из пзу
и по этому с помощью детекта изменения A0 (чтение всегда увеличивает байт адреса на 1)
соответственно для детекта адреса нужно не 16 линия а достаточно 1й
+ нужен четкий детект начала последовательности чтения.
а дальше используя MODE2 ВВ55 уже идёт обмен в режиме API
итого мы обходимся всего 14 проводами (8дата, +1 A0, + 1 детект режима, +4 mode2 control)
это похоже применимо частично в случае РК8000, хотя
у вас там есть WAIT, можно тормозить процессор на и не гнаться за скоростью
и 16 бит адресса сравнивать не нужно, у вас же есть CS для нужного слота ?
т.е. идея - загрузить из "ПЗУ" минимальный объем кода нужный для второй фазы
а дальше например обмен с ячейками памяти в "ПЗУ"
в качестве детекта CSROM+An+IOPORT(R/W)+WAIT ?
по поводу CPM, для упрощения
т.к. ЦПМ обменивается ТОЛЬКО 128 байтными блоками то достаточно ей это обеспечить и всё.
т.е. это элементарно мапится на образ на SD карте.
на ПЦ уже работать с образами не напрягает.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием