А зачем SD прикручивать к винту? Я так думал это будет отдельный контроллер, как раз для замены винта.
Уже прикидывал. Но только недавно достал 74HC4050, для согласования уровней. Делать буду на PIC, под мегу нет программатора.
Вид для печати
А зачем SD прикручивать к винту? Я так думал это будет отдельный контроллер, как раз для замены винта.
Уже прикидывал. Но только недавно достал 74HC4050, для согласования уровней. Делать буду на PIC, под мегу нет программатора.
под мегу программатор - пять проводов на лпт-порт.
просто готовый проект. эмуляция ПЗУ не нужна. и софт переделывать надо только на компе.
опять таки работа с FAT, а не со всякой экзотикой. я потому и интересовался - как запускать проги, загруженные в память не с магнитофона.
Как без ПЗУ грузиться то с SD? И с каких пор CP/M стала экзотикой? :) Смысл в FAT?
мега сначала эмулирует ПЗУ, этот код можно выбросить и грузиться из настоящего ПЗУ.
с FAT на ББ по-любому работать удобней.
на крайняк мона код меги переработать, ей то пофигу, что читать:FAT, раздел CP/M или еще что. например, мона работать с образами флоппи-дисков, будет сразу эмулятор и контроллера флопа и самого флопа:)
:)
Посмотрите на наш проект extrom для корвета
Там реализована именно такая схема
Сначала имитация внешнего пзу
Потом уже в режиме api
Доступ к образам дисков с sd карты
для cpm там все очень красиво
Как? По схеме она контролирует лишь 8 адресных линий. Для эмуляции ПЗУ необходимо 16.Цитата:
Сообщение от hantarex
В нашем случае получаем:
16 линий - шина адреса
8 линий - шина данных
линия Чт/вв
линия Зп/вв
линия Reset
2 линии для программатора
2 линии под кварц
4 линии для SD-карт
2 линии питания
------
37 линий. 35 если без кварца. То есть ATMEGA328P по определению никак не катит. Если же отказаться от 8 линий адреса, то загрузка с SD будет в принципе невозможна.
Общепринятый у разработчиков подход - контроллер предоставляет доступ низкого уровня, а файловая система - это уровень ОС. Поэтому я представлял контроллер как простой конвертер [шина данных] <--> [SD], аппаратно независимый от типа файловой системы и тем более ОС. Так и требования к МК значительно понижаются, можно выбрать самую дешовую модель.Цитата:
Сообщение от hantarex
Вроде SD хотелось подключить из-за удобства портации файлов. В чем удобство работать с образами дискет?Цитата:
Сообщение от hantarex
Вообще же у ПК8000 есть предусмотренные разрабами средства для загрузки с внешних носителей, независимо от их типа. В чем смысл отказываться от этой фичи и строить велосипед?
---------- Post added at 04:44 ---------- Previous post was at 04:41 ----------
Что-то схему не увидел, можно ссылку? Или хоть на какой примерно странице?Цитата:
Сообщение от esl
ПЗУ эмулируется всего на 256 байт, только загрузчик. в подробности особо не вникал.
нечто похожее я пытался замутить на Atmega16, на 20Mhz. 8 данных, 8 адресов, три прерывания - два на чт\зп. портов вв, одно - на чт. памяти.внешний дешифратор адреса(старшие 8 бит) и схема формирования CS. теоретически на 20Мгц цикл шины меги составит 50нс, цикл шины ВМ80 - что-то около 130-150нс, скорости должно хватить. только дальще прикидок и полуспаяной макетки дело не продвинулось:) надо реанимировать свой проект. а ежели Мегой дешифровать только мпадшие 4 бита адреса и использовать внешнее ПЗУ - все будет еще проще:)
---------- Post added at 08:43 ---------- Previous post was at 08:41 ----------
образы срм, хранятся на фат:) мона даже образы винтов на фат держать:) не нужен будет софт для переноса образов на SD:)Цитата:
Сообщение от DemonId7
а ежели повыпедриваться и взять какой-нить ARM с USB-хостом - так ваще сказка будет:)
хотя есть коньроллеры на ядре MCS51, с USB-хостом, используются в атомобильных плеерах-трансмиттерах, там и USB и SD и внешняя память - все удовольствия:)
В ПК8000 загрузчик стартует только с адреса 0x4000, так что 8 или 4 битами не отделаться, придется заводить все 16 линий. Или часть линий заводить на отдельный дешифратор.Цитата:
Сообщение от hantarex
Вопрос спорный. Для переноса образов на SD сторонний софт конечно не понадобится, но вот для создания и изменения самих образов - полюбому. И в чем принципиальная разница - пользоваться софтом для переноса файлов, или пользоваться софтом для работы с образами?Цитата:
Сообщение от hantarex
я про это уже писал. CS устанавливается при обращении по адресу 4000Н, дальше мега сама дешифрует младшие адреса.Цитата:
Сообщение от hantarex
пустых образов море, а переносить в них файло мона из эмулятора уважаемого b2m.Цитата:
Сообщение от DemonId7
для начинающего юзера нет риска затереть винт, например:)
вот весь проект.
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 карте.
на ПЦ уже работать с образами не напрягает.