Корвет: ExtROM Open Source extender

[esl]

Эта тема отерзана в отдельную
тут идет обсуждение и разработка адаптера к внешнему порту Корвета
который позволит загружать систему с внешней SD карты
работать должно и на машинах без дисковода.

отрезано из темы http://zx-pk.ru/showthread.php?t=23458

lets go ....
------------------------------------------------------------------------------------------------------------------------------

Сама CP/M может работать с носителями, если не ошибаюсь, до 32М. Только для этого придется сильно править биос.

не всё так плохо, во первых есть исходники
во вторых надо только размер буфера ALV кажись увеличить, место там есть
но смысла не особо

2. Еще лучше - задействовать боковой разъем. Скажем, подключить его к LPT-порту PC в двунаправленном режиме. Тут можно получить несравнимо большую скорость, ограниченную только скоростью процессора. Как вариант - загрузку ОС также делать через этот разъем, благо ОПТС это умеет. Все это схемотехнически не особо сложно, но надо писать свой биос, а вот это уже муторно. Но, с другой стороны, это хорошее упражнение для мозгов, почему бы и не заняться...

ага, по этому поводу есть давно ждущие планы,

однокристалку на боковой разъем
имеем загрузку из "внешнего пзу", и делаем что-хотим
уже есть мысли как грузить CP/M c монтрированием образов.

или сразу грузить свой cp/m или микродос, или что интереснее
сделать патчер, который при загрузке образа патчит существующие (их кол-во ограничено, и везде есть место, в CP/M точно)

правда с боковым - есть потенциальные проблеммы
во первых есть 2 типа разъемов, разных (был изначально РП15-50Г (мама), потом стали ставить DC-37(папа) )
во вторых, если разъемы были ПАПА (отдельный бред такое ставить) причем оригинально стояли нормальные,
то есть шанс поиметь сгоревший порт
т.к. там есть +5 на разъеме, а школьники закорочивали контакты типа ключами ...

но сделать можно, и будем пробовать.

---------- Post added at 23:12 ---------- Previous post was at 23:00 ----------

про скорость не подумал. у вас нет документации по порту расширения?

есть даже отдельная тема
http://zx-pk.ru/showthread.php?t=15297

[Advertiser]

[forth32]

ага, по этому поводу есть давно ждущие планы,
однокристалку на боковой разъем
имеем загрузку из "внешнего пзу", и делаем что-хотим

К сожалению, не все так просто. Дело в том, что ОПТС при чтении внешнего ПЗУ не использует линии стробирования CE и OE. Они, похоже, тупо сидят на земле. ОПТС просто перебирает (через каналы B и С) адреса ПЗУ от 0 до максимального адреса, взятого из той же ПЗУ, и сразу читает данные через канал А. Тебе с твоим микроконтроллером придется отcлеживать изменение всех (вплоть до 16) линий адреса и мнгновенно выдавать данные, соответствующие этому адресу. Боюсь, тут даже скорости STM32 не хватит на такое. Видимо, все же придется ставить полноценную параллельную Flash-память.

Я нарвался на эту проблему, когда подключал PS/2 клавиатуру к корвету - родной клавиатуры у меня нет, пришлось извращаться. Так вот скорости Atmega32-16 не хватило на обработку адреса и вывод данных - пришлось вставлять таткты ожидания процессора через вход RDY.

правда с боковым - есть потенциальные проблеммы
во первых есть 2 типа разъемов, разных (был изначально РП15-50Г

там есть +5 на разъеме, а школьники закорочивали контакты типа ключами ...

Проще выпаять нафиг этот РП15 и поставить нормальный DB-37.
Ну и, кроме 5, там еще и 12В есть на разъеме, что потенциально гораздо опаснее.

---------- Post added at 07:18 ---------- Previous post was at 06:42 ----------

если доступ к накопителю блочный ("сервер, дай мне третий сектор пятого цилиндра"), то ограничения биоса могут проявляться каким-то образом. но при файловом доступе ("сервер, пришли мне klad2.com") биос вроде не затрагивается.

В CP/N сетевые запросы имитируют вызовы BDOS - open, close, fcreate, readseq итд. Оно работает так. Сервер NDR по сети передает маркер - двухбайтовый пакет FF8x, x - номер опрешиваемого РМУ. Если РМУ хочет пообщаться с сервером, то на маркер отвечает пакетом запроса, содержащим номер функции BDOS и подготовленный блок FCB. Сервер обрабатывает запрос и выдает в сеть сектор считываемых данных, ну или принимает сектор данных для записи на диск. Все это эмулировать никаких проблем не составляет.
Но, к сожалению, и блочный доступ тут также используется - для него выделен специальный код функции 0. Правда, только на чтение. Это используется для доступа к каталогу диска. В случае с образом KDI тут тоже никаких проблем, но вот если делать сетевой диск из директрии РС - придется поизвращаться.

по поводу образов на сд-карте - почему бы и нет. если переключение будет возможным через консоль корвета, то образы станут вожделенной альтернативой папок.

Да, конечно, штука получится достаточно удбная. Однако, когда даже убогий PIP будет грузиться секунд 10 - ты быстро озвереешь от такой работы. Хотя, может быть, все не так страшно.

Ну и стоит учесть, что не все здесь электронщики. Многие просто не смогут собрать конструкцию на МК и плюнут на эту красивую идею. Так что это только для себя получится.

Я пока пошел по другму пути - буду делать серверную программу на РС, эмулирующую NDR. Тут тоже трудностей хватает - придется, в принципе, написать с нуля всю дисковую часть BDOS. Зато потом такую программу можно запустить, например, на каком-нибудь андроид-планшете, поключить его к корвету, и получить то же самое, что и МК+SD, только более простым путем. Спаять переходник на компорт из трех сопротивлений и диода граздо проще...

[forth32]

я собирался сделать пару упрошений

1) грузим ТОЛЬКО 1 (один) блок (256 байт) - boot loader
2) уже в нем грузим остальное по своему внутреннему протоколу

Да, логично, согласен. 8 линий адреса - это уже терпимо. Потом в режиме 2 неторопясь докачать остальное - при этом к МК можно подцепить 4Мбитную SPI флешку, коих как грязи на сдохших матерях. И записать туда целую ОС, даже с утилитами.

Хорошая идея. Завтра поеду в город - попробую подцепить мегу к боковому разъему и сделать пробную загрузку таким способом. У меня вроде бы должен был сохраниться монитор-отладчик для корвета, который я делал, когда его воскрешал из мертвых. На нем можно потренироваться.

3) в теории можно отслеживать только 1 линю A0 (ну еще всё проверку наличия ПЗУ как флаг начала загрузки)

А вот тут я не уверен. ДЕло в том, что ОПТС читает ПЗУ нелинейно - вначале читает только отдельные байты заголовка, а потом уже делает 2 полных прохода - для подсчета КС и загрузки. И тут надо смотреть, не попадутся ли подряд 2 байта с одинаковым младшим битом адреса.

по поводу CP/M - есть просто РОМ в котором сразц CP/M вместо бейсика

Но это немного неспортивно Ну и у меня ROM0 намертво впаян в плату, и, учитывая низкое качество самой платы (даже маски нет), выпаивать ее и ставить колодку что-то пока не хочется. Мне бы ГЗУ перепаять на РУ5 для начала...

Кстати, интересно, а в чем смысл загонять CP/M в ПЗУ? Сэкономить 2 дорожки на диске?

и кстати - это есть живой контроллер ПЦ клавы для Корвета ???

Ну, да. А что мне оставалось делать? Мне досталась голая слегка покуроченная плата 8010. Без клавиатуры, разъемов, корпуса... Пришлось извращаться. Взял мегу8515, завел на нее все адреса, строб чтения клавиатуры и ее выходную шину данных. Но ширины одного импульса RD явно нехватало для подготовки выходных данных контроллером - пришлось растягивать чикл чтения клавиатуры через сигнал RDY процессора. В результате изредка имеем непонятные подвисания, природу которых я пока не понял. Ну и некоторые варианты биоса вообще отказываются работать с такой клавиатурой.

Я ведь эмулировал только построчное чтение, и чтение половины матрицы МК целиком (это когда выставляется адрес 00). Чтение произвольных сочетаний строк клавиатуры я делать не стал - слишком долго, нельзя тормозить процессор на такое время. Вобщем, получился костыль, но где мне взять родную корветовскую клавиатуру?

откуда 10 секунд ?!
контролле работает с SD и корвету отдает "блоки"

Вообще-то в данном контексте разговор шел об эмуляции сетевого диска через разъем LAN. Понятно, что через боковой разъем будет летать пулей - быстрее чем с реальной дискеты. Просто тут высказывали мысль, что сделать переходник на LAN проще, чем мудрить с контроллерами...

[esl]

А вот тут я не уверен. ДЕло в том, что ОПТС читает ПЗУ нелинейно - вначале читает только отдельные байты заголовка, а потом уже делает 2 полных прохода - для подсчета КС и загрузки. И тут надо смотреть, не попадутся ли подряд 2 байта с одинаковым младшим битом адреса.

он в строго определённом порядке читает

Reset (check ext rom)
0004
0005
0006
0007
0000...00xx
0000...00xx

---------- Post added at 15:09 ---------- Previous post was at 15:07 ----------

при этом к МК можно подцепить 4Мбитную SPI флешку, коих как грязи на сдохших матерях. И записать туда целую ОС, даже с утилитами.

зачем SPI
SD Card и всё на ней.

---------- Post added at 15:13 ---------- Previous post was at 15:09 ----------

Кстати, интересно, а в чем смысл загонять CP/M в ПЗУ? Сэкономить 2 дорожки на диске?

на реале эти 2 дорожки секунд наверное 5 грузяться ?
уже не помню точно,

т.е. экономия на секундах,
но если работа постоянно идёт с дисковода - то смысл имеет

хотя я бы не ставил такой ром

---------- Post added at 15:20 ---------- Previous post was at 15:13 ----------

Я ведь эмулировал только построчное чтение, и чтение половины матрицы МК целиком (это когда выставляется адрес 00). Чтение произвольных сочетаний строк клавиатуры я делать не стал - слишком долго, нельзя тормозить процессор на такое время. Вобщем, получился костыль, но где мне взять родную корветовскую клавиатуру?

по идее чтение "блок" идёт при xxFF а не 00

наличие PS/2 контроллера это круто!

Вообще-то в данном контексте разговор шел об эмуляции сетевого диска через разъем LAN.

я так и надеялся, но решил уточнить


---------- Post added at 15:07 ---------- Previous post was at 15:02 ----------

Сергей, а возможно оставить совместимость с дисководами? Мне видится, что нет. Но было бы удобно - A и B для физических устройств, а C...Z для монтирования образов.

(рам-диск наверно и не нужен с такой штукой)

это надо делать конфигурябельно
пользователь сам определяет (например в конфиге), какие диски мапить на образ а какие на реальное железо
это позволит форматировать/копировать на реальные диски - если они есть
или для пк8010 вообще быть без дисководов реальных
рамдиск вообще не мешает

в голову приходило что в cp/m диском D монтировать образ где всегда есть "менеджер виртуальных дисков" и другие полезные программы (в 800к их можно все напихать)

мое имхо больше дисков то и не нужно, при возможности перемонтировать
кол-во дисков лимитировано в биос (буфера под служебные области) и сейчас это
в CP/M только A,B,C,D+E
в микродосе A,B (иногда E)
но если будет надо - можно сделать и больше.

---------- Post added at 15:29 ---------- Previous post was at 15:20 ----------

Можно ещё поставить статическое ОЗУ. Доступ к нему будет разрешаться битом C7 PPI2 (либо Корвет, либо Мега, наверное можно даже без мультиплексоров). Под сигнал записи в ОЗУ отдать старший бит адреса. А IRQ использовать как сигнал для обработки данных со стороны Корвета.

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

[b2m]

Боюсь, тут даже скорости STM32 не хватит на такое. Видимо, все же придется ставить полноценную параллельную Flash-память.

Можно ещё поставить статическое ОЗУ. Доступ к нему будет разрешаться битом C7 PPI2 (либо Корвет, либо Мега, наверное можно даже без мультиплексоров). Под сигнал записи в ОЗУ отдать старший бит адреса. А IRQ использовать как сигнал для обработки данных со стороны Корвета.

Получится такая схема:
1. после сброса мега грузит в ОЗУ загрузчик для Корвета и ждёт разрешения доступа C7 PPI2
2. если доступ есть, проверяет в ОЗУ флаг, загрузился ли загрузчик.
3. после того, как загрузчик загрузился, он установит вектор обработчика прерывания, подготовит команду меге, установит флаг и разрешение доступа.
4. мега, дождавшись флага, обработает команду, сбросит флаг и выдаст прерывание. После чего опять ждёт команду.

[forth32]

Можно ещё поставить статическое ОЗУ. Доступ к нему будет разрешаться битом C7 PPI2 (либо Корвет, либо Мега, наверное можно даже без мультиплексоров). Под сигнал записи в ОЗУ отдать старший бит адреса. А IRQ использовать как сигнал для обработки данных со стороны Корвета.

Так, вроде понял твою идею. Значит, после старта заливаем в ОЗУ загрузчик, ждем, когда он прочитается, запустится и дернет линию control (PPI2 C7), а потом просто ждем команды от корвета и по необходимости или заливаем ему в ОЗУ блок данных, или читаем его оттуда.

Идея, вроде бы, здравая. Если мы делаем универсальный картридж для заливки в корвет системно-независимых программ, то получается то, что надо. Правда, без мультиплексоров на шине адреса все равно не обойтись.
Дело в том, что на боковой разъем не выведен сигнал RESET. Это, конечно, типичное разгильдяйство разработчиков - всякий мусор типа -12в вывели, а такой важный сигнал забыли. В результате мы можем поймать момент перезагрузки корвета только по деганию линии control. А поскольку после сброса все каналы PPI находяится в режиме вывода данных, может возникнуть неприятный конфликт.

Ну, да ладно. Все же - что мы хотим в конечном итоге получить? Тут, вроде как, обсуждается загрузчик CP/M с эмуляцией сетевых дисков. И в таком режиме буферное ОЗУ не дает никаких реальных преимуществ. Ибо тут будет так. Программа захотела прочитать сектор диска. Сетевой драйвер BIOS отправляет запрос в наш контроллер и впадает в цикл ожидания, затем контроллер набивает байт за байтом содержимое сектора в буферное ОЗУ, и сообщает драйверу что все готово (все это время драйвер висит в цикле ожидания). Затем драйвер байт за байтом вычитывает ОЗУ в буфер DMA и отдает его пользователю.

Но тогда проще перекидать сектор байт за байтом непосредственно из контроллера в порт, без промежуточной буферизации. Времени на это уйдет не больше, а может быть и меньше. Как справедливо заметил ESL, режим 2 PPI как раз для этого и предназначен. Единственное тонкое место, в котором может потребоваться буферная память - это начальная загрузка загрузчика ОС средствами ОПТС. Там жесткие тайминги и дурацкий протокол. Но я завтра попробую средствами меги сэмулировать начальную загрузку - сразу все станет ясно.

---------- Post added at 18:01 ---------- Previous post was at 17:39 ----------

он в строго определённом порядке читает

Ну, тогда ладно. Правда, есть один неприятный момент - ОПТС вначале выставляет младший адрес, а затем, через некоторое время, старший. Причем во время чтения байтов заголовка старший адрес вообще не формируется. А ты получаешь строб по младшему адресу, и отловить момент смены старшего - несколько нетривиальная задача. Впрочем, если мы читаем только 256 байт, то тут ты на 100% прав - старшего адреса нет, можно стробироваться по A0. Это я завтра опробую.

зачем SPI
SD Card и всё на ней.

А, ну если делать полностью автономное устройство, без интерфейса к PC, то да - сдкарту и на нее все образы. Правда, карта все равно будет в SPI режиме использоваться. А поддерживают ли современные SDHC карты такой режим?
А старую 2-гиговую карту найти теперь проблема...

На карте будет файловая система, придется в мегу пихать еще и драйвер FAT. Потянет все это мега? Должна, по идее. Хотя, я бы предпочел какой-нибудь ARM , например STM32 или TI Stellaris

на реале эти 2 дорожки секунд наверное 5 грузяться ?
уже не помню точно,

Насчет 5" дисководов не скажу, у меня на 3.5" грузится примерно секунду, а то и меньше. 2 доржки - это же 1 цилиндр, перемещения головки нет.
То есть экономия копеечная и бессмысленная. Но посмотреть интересно. Сейчас найду этот ROM и в эмулятор его.

по идее чтение "блок" идёт при xxFF а не 00

Гы. Ты рассуждаешь как программист. С точки зрения программиста - да, в адрес вписыается FF. Только вот между шиной адреса и разъемом клавиатуры стоит блок инверторов, и к контроллеру уже приходит 00. То есть клавиатура опрашивается именно подтяжкой горизонтали матрицы к земле. А на выходе клавиатуры стоит еще один блок инверторов, так что для процессора нажатая кнопка выглядит как 1, а для контроллера клавиатуры - как 0.

Если кому когда-нибудь потребуется - могу нарисовать и выложить схему и исходники прошивки. Контроллер - мега 8515. Только над такими исходниками народ смеяться будет... Делались они по принципу - быстрее бы заработало и можно поиграть с корветом.

[esl]

Ну, тогда ладно. Правда, есть один неприятный момент - ОПТС вначале выставляет младший адрес, а затем, через некоторое время, старший. Причем во время чтения байтов заголовка старший адрес вообще не формируется. А ты получаешь строб по младшему адресу, и отловить момент смены старшего - несколько нетривиальная задача. Впрочем, если мы читаем только 256 байт, то тут ты на 100% прав - старшего адреса нет, можно стробироваться по A0. Это я завтра опробую.

я хотел вешать перывание PINCHANGE на A0

в аттаче табличка котороую тут рисовал для себя, может будет полезна
там выводы разъемово (оба типа)
что пишет/читает ROM
планы распиновки mega128

ESL-ExtConnector-XS1.ods.zip

[forth32]

я хотел вешать перывание PINCHANGE на A0

Поправь меня если ошибаюсь, но, насколько я помню, в меге 128 нет прерывания PINCHANGE. Его вообще почти ни в одной меге нет - это для тинек обычное дело. Если бы было - я бы не ныл тут о сложности захвата адреса, а ловил бы любое самое малое изменение в адресном порте в виде прерывания Но зато есть штук 8 обычных extint, и какое-то из них наверняка выведено на нулевой бит какого-нибудь порта.

Во, глянул даташт. PD0=INT0, как раз то что надо.

в аттаче табличка котороую тут рисовал для себя, может будет полезна
там выводы разъемово (оба типа)
что пишет/читает ROM
планы распиновки mega128

Я, наверно, еще тупой после вчерашнего, но что-то не могу понять из вкладки 3, куда ты собирался выводить старший и младший байты адреса. На порты A и C, что ли? Я так понимаю, это даже не чистая мега, а ты уже какую-то плату собрал и даже разъемы поставил (колока А табилцы).

---------- Post added at 06:34 ---------- Previous post was at 06:23 ----------

правда есть еще нечто под названием ЭУ8040*"ЭЛЕМЕНТ УПРАВЛЕНИЯ ЭУ8040"
и его дочерние платы, но имхо городить его не стоит

Кстати, в не сохранилось ли у тебя копий тех схем? Там ссылки уже дохлые. А глянуть было бы интересно.

[esl]

Поправь меня если ошибаюсь, но, насколько я помню, в меге 128 нет прерывания PINCHANGE. Его вообще почти ни в одной меге нет - это для тинек обычное дело. Если бы было - я бы не ныл тут о сложности захвата адреса, а ловил бы любое самое малое изменение в адресном порте в виде прерывания Но зато есть штук 8 обычных extint, и какое-то из них наверняка выведено на нулевой бит какого-нибудь порта.

Во, глянул даташт. PD0=INT0, как раз то что надо.

я же готовился
для мег их >1 как я понял, у тинек 1

Я, наверно, еще тупой после вчерашнего, но что-то не могу понять из вкладки 3, куда ты собирался выводить старший и младший байты адреса. На порты A и C, что ли? Я так понимаю, это даже не чистая мега, а ты уже какую-то плату собрал и даже разъемы поставил (колока А табилцы).

просто дома есть такое (оно под другую задачу было)

https://dl.dropboxusercontent.com/u/...t/P1460181.JPG
https://dl.dropboxusercontent.com/u/...t/P1800331.JPG
http://kosmodrom.com.ua/razrabotka/m...8kit-board.php
под нее и думал.

правда сейчас должны приехать ардуинки, может с ними буду пробовать
---------- Post added at 09:40 ---------- Previous post was at 09:37 ----------

Кстати, в не сохранилось ли у тебя копий тех схем? Там ссылки уже дохлые. А глянуть было бы интересно.

https://yadi.sk/d/vBSOiBOlTVDaX
https://yadi.sk/d/D0D6buftTVDmY
https://yadi.sk/d/PiSCUxKCTVDpR
https://yadi.sk/d/bJm-K9scTVDry

[esl]

На карте будет файловая система, придется в мегу пихать еще и драйвер FAT. Потянет все это мега? Должна, по идее. Хотя, я бы предпочел какой-нибудь ARM , например STM32 или TI Stellaris

ты их же есть

FatFs/Petit FatFs Module
http://elm-chan.org/fsw/ff/00index_e.html
и
https://github.com/vinxru/VinxFs
она требует по описанию 512 + 50 байтов памяти и 6-7к кода всего

stm32 это как вараинт, но по идее мег должно хватить для начала
главное разработать прототип а потом уже можно и на более "толстом" железе сделать всякие вкусности.