nedoPC.org

Запустить получилось самособранный odimount, с этим теперь все ок. Возникли другие вопросы - с каким монитором МХ запускает эту программу, m2? и где этот монитор хранится, в spmx.bin?
Мне же нужно к коду монитора добавить с адреса 0xd000 код sdbios_mx2.
Еще один момент нужно будет отследить, xsd область 0xe000-0xe7ff использует под работу с fat sd карты, и этот же участок памяти пересекается с буфером дисковода...

По поводу вложения xsd_mx2.zip. Ну конфигурацию SpecialistFD.cfg я завёл, файл SD образа sd1.mmc я подставил. Дальше что смотреть? Запуск в мониторе по GD000? Описанные манипуляции выводят на экран Browser с непонятной цепочкой дескрипторов файлов. Что дальше то делать? Куда вставлен обработчик файловых функций?

Сорри за оффтоп... а чьи это рожи синие?

Стандартный RAMFOS находится в файле spmx.rom, но лучше этот стандартный код не трогать. Можно только менять программы пользователя. Если изменится область 0000...3fff, то RAMFOS будет покацанный.

2 килобайта не знаю где взять. Это всё занято:

Можно процесс работы разделить по пунктам:
1. Загружается каталог с SD карты в область SDDir.
2. Далее идёт процесс сортировки файлов в каталоге. До этого бы сделать фильтрацию только по расширению odi (нам зачем другие файлы?) - потом сделаю.
3. Идёт процесс печати файлов на экран. Пока вводятся только 10 файлов, но можно организовать прокрутку. Да и я сделал по умолчанию только корневой каталог, а необходимо просмотреть всю SD карту.
4. Выбранный файл подгружается в память с #0000 частями, там затирается каталог (SDDir) по 25 кБайт за раз.
5. В контроллер дисковода (SPI память) при помощи функции ВГ93 записать сектор (1 кБайт) записываются 25 раз блоки.

Значит для работы с FAT и для каталога в начальном этапе можно использовать всю область #0000...#63ff. Но она потом затрётся.

Слева направо: Vinxru, Fifan. Мне уже высказали комплименты. Но в новых версиях программ ODImounter и Standard Spetsialist Browser'е я дяденек удалил.

(с) Так вот ты какой, северный олень! ( анекдот... не обижайся )

Ну в общем правильно, что удалил... а то зело напоминает стенд "Их разыскивает милиция"...

Во-во и я такой не скромный, да и заметил что картинки грузятся долговато... Пусть нас не знаю в лицо.

Ну да, и я заметил на глаз, что картинки примерно в 3 Кбайт, если они BW...

sdbios хоть оригинальный от Vinxru, хоть новый sdbios_mx2, должен как то размещать свой код в памяти и работать совместно с монитором. В МХ при запуске std программ должен загружаться требуемый для этой std программы монитор, по крайней мере я так себе этот процесс представляю, а в эмуляторе в файлах *.cpu есть записи типа m2_d400.mon, m1_d800.mon, m3_6800.mon. Это ведь те самые мониторы? Где они хранятся?
Или же, я поставлю вопрос иначе - у меня есть монитор с увеличенным размером(m2+sdbios_mx2), как этот 'новый' монитор интегрировать в МХ систему, что бы odimount мог обращаться по нужным sd_bios функциям? Проверять сейчас я все буду под эмулятором b2m.
Как сейчас odimount обращается к функциям sd_bios? как этот sd_bios попал в память МХ системы?

Так это же запускается реальная, фактичеки, sd карта, и работает с браузером, можно запускать файлы... образ sd карты можно любой дать, с любым набором файлов(только не забыть SPETS_BR.RKS или SHELL.RKS добавить в корень) и это на SD_MX2 интерфейсе. Можно и на реале проверить работу.

Если в коде поправить
aShellRks: .db "SPETS_BR.RKS",0
;aShellRks: .db "SHELL.RKS",0
на
;aShellRks: .db "SPETS_BR.RKS",0
aShellRks: .db "SHELL.RKS",0
то запустится оболочка SHELL.RKS от Vinxru.

Точка входа sdbios_mx2 на текущий момент 0xd5dd. Непонятная цепочка дескрипторов файлов это глюк:), я же обещал, что они будут...

Так и есть. Вот рабочий код для Специалиста_МХ2:


Ну его же как бы нет... Я же все обращения к sd bios закомментировал, работаю просто с готовым каталогом (только печатаю файлы с каталога). А вообще я под МХ не работал с SD картой. Но сам Vinxru говорил мне что это можно сделать изменив адреса ВВ55 в shell.rks. У меня был опыт загрузки всего 800 кБайтного odi файла под std, останавливался после загрузки каждого 25 кБайтного блока, проверял загруженный код с образом.
В случае SD_MX2 я думаю нужно поступить так. Организовать подпрограммы ввода каталога, открытия файла, чтения с файла с определённого адреса, запись в файл с определённого адреса. Это всё есть в ODImounter'е для SD контроллера от Vinxru. Отладка/загрузка cpu/i80 файлов в эмуляторе на начальном этапе. Потом готовая программа ляжет в ROM-диск, оттуда и запускать её потом.

Я был абсолютно уверен, что RAMFOS в своем ROM диске или прямо в своем коде содержит несколько мониторов, которые загружаются, в зависимости от требований запускаемой программы, те это не так?! В каком ключе тогда упоминаются мониторы SP580, магик_ж2 в описании RAMFOS, что вызовы в них подправлены под измененную адресацию клавиатуры?

В RAMFOS вообще есть такая возможность, попасть в некий 'стандартный' монитор, получить его приглашение? Или же, надо загрузить некую программу, которая в себе будет содержать требуемый монитор?
У меня не сходится понимание, как тогда предполагалась работа с Vinxru's sdbios_ом в МХ?
Кто разместит код этого sdbios в ОЗУ?
Я думал, что все должно работать так- стартует RAMFOS, запускаем с ROM диска odimount, при запуске odimount_а RAMFOS_ом копируется соответствующий монитор, к которому приклеен код sdbios, и мы получаем рабочую связку- монитор, sdbios и наша программа, odimount в частности. Далее никто не мешает переключиться обратно в RAMFOS, и запускать MXDOS с нашего эмулятора дисковода...

Их можно положить в ROM-диск самому, соблюдая его формат. В RAMFOS мониторов нет.
Это в эмуляторе "Специалист_МХ" Шевцова эти мониторы подгружаются сами, если нужно.
Да и то - это следует в начале прямо указать в специальном файле, сопровождающем исполняемый бинарник.

В реальном, железном "Специалист_МХ" с RAMFOS эти мониторы просто загружались с ленты в RАM-диск, и их можно было запустить с диска.
У них саморазворачивающийся формат и они записывают в ОЗУ копии бинарников ПЗУ на свои места, затирая RAMFOS .

Выход из них в RAMFOS только по полной перезагрузке по Reset.

В общем-то это всё вроде как и написано в желтенькой брошюрке по RAMFOS...

Всё так, как написал Lavr. А зачем для работы некой программы нам нужно использовать какой-то левый Монитор? В RAMFOS'е и так есть все стандартные вызовы, повторяющие стандартные подпрограммы. Вообще я стараюсь использовать свои проверенные подпрограммы и стандартные редко использую. Например, в ODIMounter'е применяются:
1. OutSymbol - вывод символа на экран;
2. OutText - печать строки текста;
4. SystemBeep - вывод звука через ВИ53;
5. CompareMem - сравнить области памяти;
6. Window - печать окна;
7. DecPrint - печать десятичного числа;
8. BytesRemove - перенос данных и другие.
Часть я позаимствовал в Loader'е, часть написал сам. По большому счёту RAMFOS не используется, да и зачем если и так все подпрограммы есть.