Эмулятор контроллера дисковода для Специалиста_МХ
Moderator: Lavr
-
- Devil
- Posts: 909
- Joined: 06 Oct 2006 03:17
- Location: г.Лянтор,Сургутского р-на,ХМАО
Эмулятор контроллера дисковода для Специалиста_МХ
С одобрения PVV я решил открыть тему по новому устройству к Специалисту_МХ - эмулятор контроллера дисковода. Сначала я хотел заменить только К1818ВГ93, но по мере создания схемы и написания программ я решил эмулировать весь контроллер дисковода.
Идея такова. Нельзя ли образ дискеты (файл odi) хранить в SPI Flash памяти. Считывать в неё образ, работать с файлами, в конце записывать образ. После экспериментов с SD контроллером от Vinxru я научился считывать образ в память по 25 кБайт (весь образ - 800 кБайт).
При выборе памяти я остановился на AT45DB161D. В неё можно поместить два образа (для дискет А и В). Объём всей микросхемы - 2 МБайта.
Для эмуляции я взял микроконтроллер PIC16F876A. Эмуляция состоит из подсовывания MX-DOS команд чтения/записи/др. К1818ВГ93. Эмулируются не все команды ВГ93, а только те, с какими работает Специалист_МХ.
Процесс эмулирования odi образов дискет я назвал монтированием, по аналогии со Скорпионам ZS256. В качестве дополнения можно ещё ввести часы/календарь на DS1302, что позволяет при входе в RAMFOS сделать автоматический ввод данных о текщей дате. Для работе с ней я задействовал порт /u2, пока числящийся резервным.
Устройство в разработке, на макетке ещё не запаяно до конца. Схема приложена. Так же в атачах скриншоты в Протеусе и программы эмуляции, файлы проекта.
Идея такова. Нельзя ли образ дискеты (файл odi) хранить в SPI Flash памяти. Считывать в неё образ, работать с файлами, в конце записывать образ. После экспериментов с SD контроллером от Vinxru я научился считывать образ в память по 25 кБайт (весь образ - 800 кБайт).
При выборе памяти я остановился на AT45DB161D. В неё можно поместить два образа (для дискет А и В). Объём всей микросхемы - 2 МБайта.
Для эмуляции я взял микроконтроллер PIC16F876A. Эмуляция состоит из подсовывания MX-DOS команд чтения/записи/др. К1818ВГ93. Эмулируются не все команды ВГ93, а только те, с какими работает Специалист_МХ.
Процесс эмулирования odi образов дискет я назвал монтированием, по аналогии со Скорпионам ZS256. В качестве дополнения можно ещё ввести часы/календарь на DS1302, что позволяет при входе в RAMFOS сделать автоматический ввод данных о текщей дате. Для работе с ней я задействовал порт /u2, пока числящийся резервным.
Устройство в разработке, на макетке ещё не запаяно до конца. Схема приложена. Так же в атачах скриншоты в Протеусе и программы эмуляции, файлы проекта.
Last edited by fifan on 02 May 2016 00:55, edited 1 time in total.
-
- Devil
- Posts: 909
- Joined: 06 Oct 2006 03:17
- Location: г.Лянтор,Сургутского р-на,ХМАО
Re: Эмулятор контроллера дисковода на Специалисте_МХ
Вот ещё схема, даташит на память и файлы программы эмуляции.
Last edited by fifan on 06 May 2016 03:36, edited 2 times in total.
-
- Devil
- Posts: 909
- Joined: 06 Oct 2006 03:17
- Location: г.Лянтор,Сургутского р-на,ХМАО
Re: Эмулятор контроллера дисковода для Специалиста_МХ
Жду высказываний, советов.
-
- Doomed
- Posts: 463
- Joined: 12 Feb 2016 13:39
Re: Эмулятор контроллера дисковода для Специалиста_МХ
Приветствую всех.
Идея эмулятора контроллера дисковода отличная, те кто хочет полной аутентичности будет использовать и ВГ93 и дисковод, а как только встает вопрос использования эмулятора дисковода, то совершенно логично вытекает вопрос, а зачем то сама ВГ93 в цепочке между эмулятором дисковода и ПК? Я сам столкнулся с проблемой покупки дискет, купить можно только через интернет магазин упаковку с доставкой курьером — за эти деньги спокойно можно купить дешевый контроллер и SD карту и собрать подобный эмулятор…
Теперь же по предложенной схеме. Судя по датам в коде эта идея уже сформировалась давно, но у меня глобальные вопросы все же возникли.
Нет понимания как будет образ дискеты (файл odi) записываться в SPI Flash память? Из SD карты? Если да, то зачем вообще перекидывать образы с SD на SPI Flash, а затем обратно, почему не использовать сразу SD карту? Работа с SD в нашем случае это тот же SPI. Если вопрос в том, что бы иметь фиксированные адреса начала и конца образа в SPI Flash, то на SD это элементарно организуется при форматировании карты, начало раздела отодвигается на нужное число секторов, и будет область, в которую можно писать нужное число образов дискеты. (В ARM процессорах режим загрузки с SD выглядит именно так, при старте загрузчик(u-boot) вычитывается из пространства между 2м сектором и до начала размещения 1го раздела).
Как вообще должен выглядеть процесс монтирования образа? Должны ли мы запуститься в режиме МХ, из ROM запустить некую оболочку — файл(ODImounter), и выбрать какие диски хотим примонтировать в позиции А и В? Опять же, с какого носителя будут читаться образы дисков, SD? Значит SD должна либо присутствовать в конфигурации адресного пространства МХ и решать вопрос с доступом МХ/эмулятор, либо быть подключена непосредственно к эмулятору и напрямую МХ_у не видна.
Без разъяснения этих двух пунктов, дальше двигаться сложно.
Будет ли этот эмулятор работать только на Специалист_МХ или его можно будет расширить и на другие ПК?
В каком эмуляторе на PC можно протестировать приведенные коды программ? пример конфига для b2m возможен?
Идея эмулятора контроллера дисковода отличная, те кто хочет полной аутентичности будет использовать и ВГ93 и дисковод, а как только встает вопрос использования эмулятора дисковода, то совершенно логично вытекает вопрос, а зачем то сама ВГ93 в цепочке между эмулятором дисковода и ПК? Я сам столкнулся с проблемой покупки дискет, купить можно только через интернет магазин упаковку с доставкой курьером — за эти деньги спокойно можно купить дешевый контроллер и SD карту и собрать подобный эмулятор…
Теперь же по предложенной схеме. Судя по датам в коде эта идея уже сформировалась давно, но у меня глобальные вопросы все же возникли.
Нет понимания как будет образ дискеты (файл odi) записываться в SPI Flash память? Из SD карты? Если да, то зачем вообще перекидывать образы с SD на SPI Flash, а затем обратно, почему не использовать сразу SD карту? Работа с SD в нашем случае это тот же SPI. Если вопрос в том, что бы иметь фиксированные адреса начала и конца образа в SPI Flash, то на SD это элементарно организуется при форматировании карты, начало раздела отодвигается на нужное число секторов, и будет область, в которую можно писать нужное число образов дискеты. (В ARM процессорах режим загрузки с SD выглядит именно так, при старте загрузчик(u-boot) вычитывается из пространства между 2м сектором и до начала размещения 1го раздела).
Как вообще должен выглядеть процесс монтирования образа? Должны ли мы запуститься в режиме МХ, из ROM запустить некую оболочку — файл(ODImounter), и выбрать какие диски хотим примонтировать в позиции А и В? Опять же, с какого носителя будут читаться образы дисков, SD? Значит SD должна либо присутствовать в конфигурации адресного пространства МХ и решать вопрос с доступом МХ/эмулятор, либо быть подключена непосредственно к эмулятору и напрямую МХ_у не видна.
Без разъяснения этих двух пунктов, дальше двигаться сложно.
Будет ли этот эмулятор работать только на Специалист_МХ или его можно будет расширить и на другие ПК?
В каком эмуляторе на PC можно протестировать приведенные коды программ? пример конфига для b2m возможен?
-
- Devil
- Posts: 909
- Joined: 06 Oct 2006 03:17
- Location: г.Лянтор,Сургутского р-на,ХМАО
Re: Эмулятор контроллера дисковода для Специалиста_МХ
Идея этого эмулятора была в том чтобы загружать образы odi файлов в Специалист_МХ именно обманув MX-DOS подсунув ему вместо реальной железки некую область памяти, чтоб он с нею работал.
Хорошо что откликнулся кто-то. Вот так в рассуждениях из вне и меняешь свои пути решения проблемы. PVV, твоя идея вместо SPI всё писать/читать с/на SD не лишена здравого смысла. Я сейчас где-то на половину заюзал возможности SD контроллера от Vinxru, т.е. могу выводить каталоги, читать файлы. А ведь в этом девайсе есть и возможность открывать файл (и даже два файла одновременно) и модифицировать его содержимое. Вот описание его функций. А мы может задействовать вот эти:
Open Открыть файл (A=2, D=0, HL=имя файла / A=код ошибки)
Read Прочитать из файла (A=4, HL=размер, DE=адрес / A=код ошибки, HL=сколько загрузили)
Write Записать в файл (A=5, HL=размер, DE=адрес / A=код ошибки)
Для всех этих манипуляций необходим небольшой буфер для операций и место под каталог (который можно ограничить по количеству файлов).
Процесс монтирования дисков заключается в следующем. При запуске на SD карте odi файла в памяти резервируется место, куда переписывается весь файл (объёмом 800 кБайт). Теперь мы подсовываем Специалисту_МХ эту "дискету" и он сначала переписывает MX-DOS к себе и потом работает с FAT'ом (выводит каталог). При этом общение с "контроллером дисковода" необходимо организовать командами БИС К1818ВГ93, такими как: считать сектор, записать сектор и т.д. А иначе нужно будет переписывать весь MX-DOS.
Т.к. эти общения с "контроллером дисковода" у меня было задумано сделать через PIC микроконтроллер, то у меня связь PIC <-> SPI была логична. А теперь, что всё выкинуть и писать чисто программный эмулятор?
Всё это касательно Специалиста_МХ, в обычном (стандартном) Специалисте этого (контроллера дисковода) не было, да и сейчас не нужно что-то монтировать, просто запускаем rks файлы с SD карты.
По поводу доступа. На сегодняшний момент мы имеем для Специалиста_МХ, Специалиста_МХ2 (в режиме МХ) следующие устройства:
1. контроллер дисковода;
2. SD контроллер;
3. таймер/календарь (нет, но охота...).
Для стандартного Специалиста, Специалиста_МХ2 (в режиме Std):
1. SD контроллер;
2. Flash-диск (только для МХ2, в других нужно прошивку менять).
Распределим выборки (здесь я буду ссылаться на схему Селектора адресов):
1. контроллер дисковода - /U3, /U5;
2. SD контроллер (схема VInxru) - /U6;
3. SD контроллер (схема на ПЛИС в МХ2) - /U2 или /U3 - необходимо выбрать;
4. Flash-диск - /U6;
5. таймер/календарь - /U2.
Видите сколько противоречий, нужно сделать стандарт.
Ну - жду мыслей 
Хорошо что откликнулся кто-то. Вот так в рассуждениях из вне и меняешь свои пути решения проблемы. PVV, твоя идея вместо SPI всё писать/читать с/на SD не лишена здравого смысла. Я сейчас где-то на половину заюзал возможности SD контроллера от Vinxru, т.е. могу выводить каталоги, читать файлы. А ведь в этом девайсе есть и возможность открывать файл (и даже два файла одновременно) и модифицировать его содержимое. Вот описание его функций. А мы может задействовать вот эти:
Open Открыть файл (A=2, D=0, HL=имя файла / A=код ошибки)
Read Прочитать из файла (A=4, HL=размер, DE=адрес / A=код ошибки, HL=сколько загрузили)
Write Записать в файл (A=5, HL=размер, DE=адрес / A=код ошибки)
Для всех этих манипуляций необходим небольшой буфер для операций и место под каталог (который можно ограничить по количеству файлов).
Процесс монтирования дисков заключается в следующем. При запуске на SD карте odi файла в памяти резервируется место, куда переписывается весь файл (объёмом 800 кБайт). Теперь мы подсовываем Специалисту_МХ эту "дискету" и он сначала переписывает MX-DOS к себе и потом работает с FAT'ом (выводит каталог). При этом общение с "контроллером дисковода" необходимо организовать командами БИС К1818ВГ93, такими как: считать сектор, записать сектор и т.д. А иначе нужно будет переписывать весь MX-DOS.
Т.к. эти общения с "контроллером дисковода" у меня было задумано сделать через PIC микроконтроллер, то у меня связь PIC <-> SPI была логична. А теперь, что всё выкинуть и писать чисто программный эмулятор?
Всё это касательно Специалиста_МХ, в обычном (стандартном) Специалисте этого (контроллера дисковода) не было, да и сейчас не нужно что-то монтировать, просто запускаем rks файлы с SD карты.

По поводу доступа. На сегодняшний момент мы имеем для Специалиста_МХ, Специалиста_МХ2 (в режиме МХ) следующие устройства:
1. контроллер дисковода;
2. SD контроллер;
3. таймер/календарь (нет, но охота...).
Для стандартного Специалиста, Специалиста_МХ2 (в режиме Std):
1. SD контроллер;
2. Flash-диск (только для МХ2, в других нужно прошивку менять).
Распределим выборки (здесь я буду ссылаться на схему Селектора адресов):
1. контроллер дисковода - /U3, /U5;
2. SD контроллер (схема VInxru) - /U6;
3. SD контроллер (схема на ПЛИС в МХ2) - /U2 или /U3 - необходимо выбрать;
4. Flash-диск - /U6;
5. таймер/календарь - /U2.
Видите сколько противоречий, нужно сделать стандарт.


-
- Supreme God
- Posts: 16676
- Joined: 21 Oct 2009 08:08
- Location: Россия
Re: Эмулятор контроллера дисковода для Специалиста_МХ
Ну в общем-то да, если не трогать софт, который есть, нужна железка, которая изображает софту дисководfifan wrote:Идея этого эмулятора была в том чтобы загружать образы odi файлов в Специалист_МХ именно обманув MX-DOS подсунув ему вместо реальной железки некую область памяти, чтоб он с нею работал.
и понимает команды К1818ВГ93.
А вторая идея - написать для Специалист_МХ нормальную дисковую ОС, которой у него нет.
В этом случае при смене носителя с реального дисковода на SD карту меняются только
низкоуровневые подпрограммы работы с устройством - так устроена СР-М.
iLavr
-
- Admin
- Posts: 23989
- Joined: 08 Jan 2003 23:22
- Location: Silicon Valley
Re: Эмулятор контроллера дисковода для Специалиста_МХ
а ShaOS ещё лучше - там цепочки драйверов можно заводить, каждый из которых обрабатывает свой логический диск A,B,C и т.д. 

Я тут за главного - если что шлите мыло на me собака shaos точка net
-
- Supreme God
- Posts: 16676
- Joined: 21 Oct 2009 08:08
- Location: Россия
Re: Эмулятор контроллера дисковода для Специалиста_МХ
И её адаптировали к "Специалисту" уже?Shaos wrote:а ShaOS ещё лучше - там цепочки драйверов можно заводить...
iLavr
-
- Doomed
- Posts: 463
- Joined: 12 Feb 2016 13:39
Re: Эмулятор контроллера дисковода для Специалиста_МХ
Я просмотрел выложенный код, часть вопросов исчезла, но не все.
Надо действительно выработать хоть какой то стандарт в распределении устройств по портам и его придерживаться, а когда возникнут конфликты, то думать как их устранять…
Как я понимаю в МХ версии SD контроллер от Vinxru программно все же не поддерживается, хотя и имеет назначенный адрес /U6, и опять я возвращаюсь к вопросу процесса монтирования образа. Как это должно происходить?
Я совершенно не помню работу МХа, хотя и выписывал, в свое время, брошюру и прошитые ПЗУ из Магнитогорска и дорабатывал свой Специалист в МХ.
SD контроллер (схема на ПЛИС в МХ2, давайте ее называть SD_MX2, тк есть ее реализация на рассыпухе) — давайте остановимся на /U2, а /U3 оставим для дисковода(как было заложено изначально)/нашего эмулятора. Будет определенность, на что можно будет опираться. Для SD_MX2 нужно 2 адреса, выделено на/U2 - 4, соотв. оставшиеся 2 на часы. Если А1=1 то обращение к часам, А1=0 то SD_MX2.
SD контроллеров вообще аж три версии существует, к двум выше означенным есть еще вариант от msx, Для Std версии на FPGA девбордах его делают и размещают внутри пространства /U6(для него и ПО есть), так пусть и для МХ2 в режиме стандарт SD_MX2 будет на /U6, только сместиться внутри этого 2К участка от нуля, например А7=1 и отключать порт программатора, а при А7=0 программатор включать, а там Flash диск MX2, или SD_Vinxru(организуется двумя диодами и резистором). ПО от версии msx элементарно дорабатывается под контроллер SD_MX2, код только меньше становится. Отвлекся...
b2m эмулятор SD от Vinxru поддерживает?
Надо действительно выработать хоть какой то стандарт в распределении устройств по портам и его придерживаться, а когда возникнут конфликты, то думать как их устранять…
Как я понимаю в МХ версии SD контроллер от Vinxru программно все же не поддерживается, хотя и имеет назначенный адрес /U6, и опять я возвращаюсь к вопросу процесса монтирования образа. Как это должно происходить?
Я совершенно не помню работу МХа, хотя и выписывал, в свое время, брошюру и прошитые ПЗУ из Магнитогорска и дорабатывал свой Специалист в МХ.
SD контроллер (схема на ПЛИС в МХ2, давайте ее называть SD_MX2, тк есть ее реализация на рассыпухе) — давайте остановимся на /U2, а /U3 оставим для дисковода(как было заложено изначально)/нашего эмулятора. Будет определенность, на что можно будет опираться. Для SD_MX2 нужно 2 адреса, выделено на/U2 - 4, соотв. оставшиеся 2 на часы. Если А1=1 то обращение к часам, А1=0 то SD_MX2.
SD контроллеров вообще аж три версии существует, к двум выше означенным есть еще вариант от msx, Для Std версии на FPGA девбордах его делают и размещают внутри пространства /U6(для него и ПО есть), так пусть и для МХ2 в режиме стандарт SD_MX2 будет на /U6, только сместиться внутри этого 2К участка от нуля, например А7=1 и отключать порт программатора, а при А7=0 программатор включать, а там Flash диск MX2, или SD_Vinxru(организуется двумя диодами и резистором). ПО от версии msx элементарно дорабатывается под контроллер SD_MX2, код только меньше становится. Отвлекся...
b2m эмулятор SD от Vinxru поддерживает?
Last edited by PVV on 04 May 2016 21:50, edited 1 time in total.
-
- Supreme God
- Posts: 16676
- Joined: 21 Oct 2009 08:08
- Location: Россия
Re: Эмулятор контроллера дисковода для Специалиста_МХ
Да там всё довольно просто. В базовом варианте 2 страницы ОЗУ по 64К - 32 байта портов.PVV wrote:Я совершенно не помню работу МХа, хотя и выписывал, в свое время, брошюру и прошитые ПЗУ из Магнитогорска и дорабатывал свой Специалист в МХ.
Страницы перекрываются в области BIOS, что позволяет в этом месте, переключив через порт 0FFFFH
номер страницы, работать в любой из них.
Позже страниц ОЗУ стало больше.
Существует ПЗУ страница - с нее процессор стартует с адреса 0000Н по RESET и разворачивает в 0-вую
страницу ОЗУ (та, в которой графическое видео-ОЗУ) RAMFOS с адреса 0С000Н (он начинается со
знакогенератора) и BIOS с адреса 0F800H.
Большинство привычных вызовов BIOS при этом дублируются в RAMFOS, что дает совместимость
со старой ПЗУ Монитора "Специалиста" (частично).
Поскольку на месте системных ПЗУ в МХ находится ОЗУ, то систему можно заменить в любой момент, просто
записав в ОЗУ коды старых Мониторов.
Но есть одно несовместимое НО! Следует скорректировать адреса УВВ, т.к. все порты теперь в 32 ячейках
с адреса 0FFE0...0FFFFH - общих для всех страниц.
В общем выглядит это всё примерно вот так: В области портов ВВ с адреса 0FFE0H посажен ВВ55 клавиатуры. Остальные адреса изначально распределили вот так: А вот что еще потом и куда добавляли, мне сказать довольно затруднительно...
You do not have the required permissions to view the files attached to this post.
iLavr
-
- Admin
- Posts: 23989
- Joined: 08 Jan 2003 23:22
- Location: Silicon Valley
Re: Эмулятор контроллера дисковода для Специалиста_МХ
А надо? Там только сесть да сделатьLavr wrote:И её адаптировали к "Специалисту" уже?Shaos wrote:а ShaOS ещё лучше - там цепочки драйверов можно заводить...

Я тут за главного - если что шлите мыло на me собака shaos точка net
-
- Supreme God
- Posts: 16676
- Joined: 21 Oct 2009 08:08
- Location: Россия
Re: Эмулятор контроллера дисковода для Специалиста_МХ
Это вопрос скорее к топикстартерам, чем ко мне...Shaos wrote:А надо? Там только сесть да сделатьLavr wrote:И её адаптировали к "Специалисту" уже?Shaos wrote:а ShaOS ещё лучше - там цепочки драйверов можно заводить...

Поскольку у меня есть сам "Специалист_МХ" со всем его железом, дисководами
и мешком дискет 5.25, я вряд ли буду его трогать, потому что он теперь в некотором
роде как эталон, так и раритет.
Хотя, по моему опыту, там одной функции явно не хватает, но вроде её потом добавляли.
В "Орионе-128", мне кажется, она уже была...
Функция: открыть файл для добавления (OPEN file FOR APPEND).
iLavr
-
- Doomed
- Posts: 463
- Joined: 12 Feb 2016 13:39
Re: Эмулятор контроллера дисковода для Специалиста_МХ
Как распределяется память и порты в МХе, я все это уже неоднократно видел. Меня интересует конкретная задача:
Дано — Специалист_МХ с RAMFOS, SD карты в режиме МХ нет(или есть?), только ROM диск. SD есть в Std режиме.
Вопрос - что и как нужно запустить( какая последовательность действий), что бы перебросить в эмулятор дисковода образ дискеты, что нужно сделать затем, дабы из RAMFOS можно было обратиться к дисководу(в RAMFOSе, как я понимаю, дисковод поддерживается, да?).
Ответ - ?
В этом кроется мое непонимание работы МХа.
Дано — Специалист_МХ с RAMFOS, SD карты в режиме МХ нет(или есть?), только ROM диск. SD есть в Std режиме.
Вопрос - что и как нужно запустить( какая последовательность действий), что бы перебросить в эмулятор дисковода образ дискеты, что нужно сделать затем, дабы из RAMFOS можно было обратиться к дисководу(в RAMFOSе, как я понимаю, дисковод поддерживается, да?).
Ответ - ?
В этом кроется мое непонимание работы МХа.
-
- Supreme God
- Posts: 16676
- Joined: 21 Oct 2009 08:08
- Location: Россия
Re: Эмулятор контроллера дисковода для Специалиста_МХ
Нет, Ваше непонимание работы МХа гораздо глубже...PVV wrote:что нужно сделать затем, дабы из RAMFOS можно было обратиться к дисководу(в RAMFOSе, как я понимаю, дисковод поддерживается, да?).
Ответ - ?
В этом кроется мое непонимание работы МХа.
RAMFOS по определению не умеет обращаться к дисководу. Это файловая OS, заточенная на работу
с RAM-диском.
В RAMFOS есть только подпрограмма начального загрузчика. Как и в большинстве дисковых ОС,
эта подпрограмма считывает с 0-дорожки дискеты в свою служебную область, так называемый
МХ-DOS, который полноценной ОС тоже не является, но умеет манипулировать с FAT, дорожками
и секторами. Т.е. в оригинальном МХе МХ-DOS организует дисковый "мешок для хранения файлов",
а вот полноценных файловых функций и дискового API у него нет.
А вот кто и чего потом наворотил поверх и вместо этой системы - вопрос к ним лично.
Другое дело, что Шевцов адаптировал к Специалисту_МХ полноценную СР-М, версии Бриджиди
и Рогова, кажется, но популярной она не стала.
iLavr
-
- Devil
- Posts: 909
- Joined: 06 Oct 2006 03:17
- Location: г.Лянтор,Сургутского р-на,ХМАО
Re: Эмулятор контроллера дисковода для Специалиста_МХ
То блин один ели отозвался, то сразу толпа насела, я даже растерялся кому отвечать. Постараюсь по пунктам.
1. На счёт выборок. В std (будем придерживаться данного сокращения, чем писать Специалист и его клоны) у нас есть только один незанятый порт, называл его кто-то, когда-то как порт программатора. Никто конечно сюда не будет подключать программатор. По схеме Волкова - это выборка 5 DD51, по аналогии с МХ назовём её /U6. Сюда, наверное мы подключим только SD контроллер от Vinxru, т.к. пока он (контроллер) только один действующий. Существующая софт поддержка - Standart Spetsialist Browser от Fifan'а т.е. от меня
.
Выборка SD контроллера в МХ - давайте возьмём схему от HardWareMan'а, дефакто расположенной в ПЛИС в МХ2 и реально работающую у PVV (SD_MX2) и тоже присвоим адрес выборки /U6. Существующая софт поддержка - Loader от HardWareMan'а. Данный факт мною подтверждается - существует загрузка любого Монитора, записанного в файл bios.bin на данном Специалисте - http://www.spetsialist-mx.ru/index34.html.
2. Остаётся /U2. Переименуем его из резервного в порт таймера/календаря на DS1302. Даже если с эмулятором дисковода и обломится, давайте DS1302 оставим для автоматического ввода даты при старте RAMFOS'а.
3. Дано — Специалист_МХ с RAMFOS, SD карты в режиме МХ нет(или есть?), только ROM диск. SD есть в Std режиме.
Вопрос - что и как нужно запустить (какая последовательность действий), что бы перебросить в эмулятор дисковода образ дискеты, что нужно сделать затем, дабы из RAMFOS можно было обратиться к дисководу (в RAMFOSе, как я понимаю, дисковод поддерживается, да?).
Ответ - В RAMFOSе дисковод можно сказать не поддерживается. Там есть определение наличия контроллера дисковода при нажатии на F6. При положительном исходе в память переписывается MX-DOS из области дискеты, который вообщем и является некой ОС. Это теория.
Как я хочу сделать. Некое ПО, например odimounter считывает блоками по 25 кБайт (на большую память Специалист_МХ практически нельзя рассчитывать) образ дискеты с SD карты во SPI Flash память (можно её я пока оставлю). Ставим RAMFOS'у флаг типа наличия контроллера дисковода. Затем позволяем RAMFOS'у переписать с SPI Flash памяти MX-DOS (тут, кстати можно подсунуть свою ОС, например мой SpetsCommander имеет полностью свои процедуры работы с дискетой). Далее идёт работа MX-DOS с его стороны типа с контроллером дисковода, с нашей стороны происходит эмуляция команд ВГ93. Всё это по моему предположению делается PIC контроллером, он даже отслеживает так называемые порты контроллера дисковода, такие как номер стороны, номер дискеты, доступ процессору. В конце работы с эмулятором, например после запуска какого-то выбранного файла, мы должны переписать "покоцанный" образ дискеты из SPI Flash памяти в тот же когда-то открытый образ дискеты в виде odi файла.
Вот такова работа эмулятора. И она больше всего происходит в PIC контроллере. Тут есть две реализации устройства, цитирую Lavr'а:
1. Если не трогать софт, который есть, нужна железка, которая изображает софту дисковод
и понимает команды К1818ВГ93. - ха! мой PIC+SPI Flash
2. написать для Специалист_МХ нормальную дисковую ОС, которой у него нет.
В этом случае при смене носителя с реального дисковода на SD карту меняются только
низкоуровневые подпрограммы работы с устройством - так устроена СР-М.
1. На счёт выборок. В std (будем придерживаться данного сокращения, чем писать Специалист и его клоны) у нас есть только один незанятый порт, называл его кто-то, когда-то как порт программатора. Никто конечно сюда не будет подключать программатор. По схеме Волкова - это выборка 5 DD51, по аналогии с МХ назовём её /U6. Сюда, наверное мы подключим только SD контроллер от Vinxru, т.к. пока он (контроллер) только один действующий. Существующая софт поддержка - Standart Spetsialist Browser от Fifan'а т.е. от меня

Выборка SD контроллера в МХ - давайте возьмём схему от HardWareMan'а, дефакто расположенной в ПЛИС в МХ2 и реально работающую у PVV (SD_MX2) и тоже присвоим адрес выборки /U6. Существующая софт поддержка - Loader от HardWareMan'а. Данный факт мною подтверждается - существует загрузка любого Монитора, записанного в файл bios.bin на данном Специалисте - http://www.spetsialist-mx.ru/index34.html.
2. Остаётся /U2. Переименуем его из резервного в порт таймера/календаря на DS1302. Даже если с эмулятором дисковода и обломится, давайте DS1302 оставим для автоматического ввода даты при старте RAMFOS'а.
3. Дано — Специалист_МХ с RAMFOS, SD карты в режиме МХ нет(или есть?), только ROM диск. SD есть в Std режиме.
Вопрос - что и как нужно запустить (какая последовательность действий), что бы перебросить в эмулятор дисковода образ дискеты, что нужно сделать затем, дабы из RAMFOS можно было обратиться к дисководу (в RAMFOSе, как я понимаю, дисковод поддерживается, да?).
Ответ - В RAMFOSе дисковод можно сказать не поддерживается. Там есть определение наличия контроллера дисковода при нажатии на F6. При положительном исходе в память переписывается MX-DOS из области дискеты, который вообщем и является некой ОС. Это теория.
Как я хочу сделать. Некое ПО, например odimounter считывает блоками по 25 кБайт (на большую память Специалист_МХ практически нельзя рассчитывать) образ дискеты с SD карты во SPI Flash память (можно её я пока оставлю). Ставим RAMFOS'у флаг типа наличия контроллера дисковода. Затем позволяем RAMFOS'у переписать с SPI Flash памяти MX-DOS (тут, кстати можно подсунуть свою ОС, например мой SpetsCommander имеет полностью свои процедуры работы с дискетой). Далее идёт работа MX-DOS с его стороны типа с контроллером дисковода, с нашей стороны происходит эмуляция команд ВГ93. Всё это по моему предположению делается PIC контроллером, он даже отслеживает так называемые порты контроллера дисковода, такие как номер стороны, номер дискеты, доступ процессору. В конце работы с эмулятором, например после запуска какого-то выбранного файла, мы должны переписать "покоцанный" образ дискеты из SPI Flash памяти в тот же когда-то открытый образ дискеты в виде odi файла.
Вот такова работа эмулятора. И она больше всего происходит в PIC контроллере. Тут есть две реализации устройства, цитирую Lavr'а:
1. Если не трогать софт, который есть, нужна железка, которая изображает софту дисковод
и понимает команды К1818ВГ93. - ха! мой PIC+SPI Flash
2. написать для Специалист_МХ нормальную дисковую ОС, которой у него нет.
В этом случае при смене носителя с реального дисковода на SD карту меняются только
низкоуровневые подпрограммы работы с устройством - так устроена СР-М.
