ага, по этому поводу есть давно ждущие планы,
однокристалку на боковой разъем
имеем загрузку из "внешнего пзу", и делаем что-хотим
К сожалению, не все так просто. Дело в том, что ОПТС при чтении внешнего ПЗУ не использует линии стробирования 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 ----------

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

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

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