Эмулятор контроллера дисковода для Специалиста_МХ

[PVV]

Нет, Ваше непонимание работы МХа гораздо глубже...
RAMFOS по определению не умеет обращаться к дисководу. Это файловая OS, заточенная на работу
с RAM-диском.

В RAMFOS есть только подпрограмма начального загрузчика. Как и в большинстве дисковых ОС,
эта подпрограмма считывает с 0-дорожки дискеты в свою служебную область...

Как то противоречиво 'по определению не умеет обращаться к дисководу' и 'считывает с 0-дорожки дискеты', значит все же умеет...
Однако, в целом я суть RAMFOS понял...
НО вопрос с последовательностью действий остался.

[PVV]

Как я хочу сделать. Некое ПО, например odimounter считывает блоками по 25 кБайт (на большую память Специалист_МХ практически нельзя рассчитывать) образ дискеты с SD карты во SPI Flash память (можно её я пока оставлю).

Это базовая идея, все так. Откуда возъмется это ПО(odimounter)? Мы его грузим с магнитофона, SD карты в std режиме, ROM диска? Это ПО будет выполняться в каком режиме std или MX? Я понимаю что все эти варианты возможны, но давайте определимся и пойдем дальше прорабатывать это ПО. Я этого хочу добиться, составить некий план работ и двигаться, а уже когда будет один из вариантов реализован, тогда и, при необходимости, реализовывать остальные.

[fifan]

Объясню ситуацию. Включаем комп (Специалист_МХ или Специалист_МХ2), радуемся заставке RAMFOS. Так условимся что у нас есть SD контроллер, но нет контроллера дисковода. Нашу запускаемую программу, назовём её НАША.COM пишем в ROM-диск пользователя, который мы лицезреем по клавише F6. Запускаем НАША.COM, та в свою очередь определяет наличие SD контроллера (смысл дальнейших действий не вижу без оного) и далее программа выводит список odi файлов, находящихся на SD карте. Выбираем файл, эмулятор монтирует образ и мы переходим в то место RAMFOS, где идёт определение наличия контроллера дисковода. Тут или обходим условие или, если мне не изменяет память пишем единицы на шину данных по адресу /U3. Всё, далее читаем руководство по работе в MX-DOS и радуемся голубовато-синему цвету экрана. Тут всё таки нужно в системе найти место, где происходит загрузка и исполнение запускаемого файла для того, чтобы найти и написать свои коды для размонтирования образа - а то, то что мы творили с "дискетой" не сохранится.
НАША.COM - это минимальное ПО. В своём SpetsCommnder'е я хочу сделать монтирование/размонтирование по запуску кнопкой ВК на файле odi. Это скриншот коммандера.

[Lavr]

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

Никакого противоречия я не вижу. BIOS практически любой современной машины умеет только загрузить boot-сектор и ничего более.
Точно также сделано и в "Специалист_МХ".

А манипуляции с файловой системой на диске возложена всегда на какую-то-DOS.
Ответ в полном соответствии Вашему вопросу.

В RAMFOS с дисками и характерными для них операциями ничего сделать нельзя.
Да и загрузчик по F6 появился лишь в поздних версиях RAMFOS.
В начальных там не было вовсе никакого загрузчика. У меня, к примеру, boot-loader отдельная
программа на ПЗУ-диске.
Ну не выпаивать же с платы 2 штуки РФ4 в два этажа из-за boot-loader-а?

[PVV]

Отлично, именно это я и хотел услышать.
НАША.СОМ — пусть уже она будет OdiMount.COM. По поводу размонтирования. Пусть в момент монтирования на SD записывается признак(в сам образ, в отдельный файл, или в файл с именем этого образа, но другим расширением - .LOС), что данный образ примонтирован, а OdiMount.COM пусть занимается не только монтированием но и размонтированием. В SPI flash так же, помимо образа хранить название этого примонтированного образа, и все конфликты разруливать в OdiMount.COM. В этом случае любые сбои/сброс не страшны.

[fifan]

Ну вот и хорошо. Осталось выбрать контроллер. У меня от Vinxru с готовой файловой системой. Если PVV, ты предполагаешь писать программу, то необходимо для твоего контроллера (SD_MX2) написать что-то вроде ОС, ну хотя бы пока поиск и загрузка odi файлов.

Напомню, что у меня в odimounter'е чтение файла сделано по 25 кБайт это 800/25=32 раза. Читается сразу в PIC контроллер путём выставление команды "запись сектора" для ВГ93 потом идёт проверка того что записали с тем что осталось в памяти - выставление команды "чтение сектора". Чтобы знать куда писать контроллеру нужно заранее выставить номера сектора/дорожки, потом инкрементировать их. У меня в начале темы выставлен архив программы с новыми исходниками, а файлы cpu/i80 со старой версии. Пока постараюсь всё обновить и показать потом этот описанный мною процесс.

[PVV]

Так как по сути серьезной программной поддержки SD_MX2 в МХ/МХ2 нет, а есть только в std в виде лоадера от HardWareMan'а и адаптированного мною xsd, то получается нужно написать некий sdbios_mx2, по функцияи и их параметрам совместимый с sdbios от Vinxru. В таком случае ПО работающее с SD картой от Vinxru через sdbios, весьма вероятно будет работать и с SD_MX2. Я так и не получил ответ на вопрос- эмулятор b2m поддерживает ли SD от Vinxru? но похоже что нет. Тогда как SD_MX2 поддерживается, тогда можно будет заниматься отладкой этого ПО в эмуляторе.

[fifan]

Не обязательно подстраиваться под ПО от Vinxru. Необходимы только файловые процедуры вставить. У меня используются: загрузка каталога, открытие файла. Вот видео работы программы в эмуляторе от b2m, обращение к SD карте отключено. Используется специально подготовленный файл с каталогом. Это для отладки.



Здесь на видео последовательно показаны функции программы: инициализация SPI Flash памяти, ввод времени и даты, создание пустого имиджа, монтирование имиджа.

В эмуляторе b2m SD-MX2 поддерживается. Так что можно творить.

[PVV]

Сделал первую прикидку трансляции вызовов sd_bios от Vinxru для работы с SD_MX2. Пока делал понял, что asm вм80 забыл напрочь:(, так что код написан — не стреляйте в пианиста, он играет как умеет... кто захочет исправить/предложить варианты реализации, буду только приветствовать. Однако, на данном этапе, для проверки идеи, этого достаточно.
Все реализовано на xsd и sd_bios от Vinxru. Поддерживается, с ограничениями, только два вызова- запуск файла и прочитать список файлов, здесь-же смена каталога. Ограничение — shell.rks должен быть в корне, а не в папке BOOT. spets_br.rks от fifan_а запускается с 'правками' — в коде 'жестко' забит адрес вывоза SD_BIOS, а Vinxru реализовал возможность размещать таблицу вызовов в любом месте, с передачей в B адреса этой таблицы( LXI B, BiosEntry ; Точка входа SD BIOS), соотв я в коде исправил переходы на таблицу в sdbios_mx2, благо их всего 4 места по коду. Надо бы fifan_у доработать spets_br.rks для стандартизации...
Код сильно не тестировался, глюки быть должны... Из shell.rks spets_br.rks не запускается, а наоборот, запускается...
Дальше надо копать в сторону Odimount, запускать его в этой оболочке, смотреть какие вызовы нужны ему в sdbios_e, и их реализовывать.

[fifan]

Сейчас нет времени, но в ближайшие дни посмотрю твои вояния. Я вот наполовину написал драйвер дискеты для Commander'а на Специалист_МХ. Здесь подробности, что такое Commander (http://www.spetsialist-mx.ru/Soft/MXOS.rar).

[PVV]

Не пойму, как собрать OdiMount, и как его, затем, подкинуть в файловую систему для МХ в b2m? Что нужно сделать?

asm_odi.PNG

Перебросил комментарий SDDir, ошибок нет, а исполняемый файл не создается, только файл листинга.
Аналогичные действия с spetsbrowser.a80 - все ок, я получившийся бинарный файл в расширение rks переименовал, закинул на образ SD карты в b2m в std режиме, и все работает... А как его в МХ системе внедрить то-же не пойму.

[fifan]

Всё верно он пишет - нет файла test_cat_odi.bin. Это файл с тестовым каталогом, но в формате от Vinxru, а именно дескриптор файла состоит не из 16, а из 12 байт. Вот он. Только зачем нужен? Необходимо же низкоуровневый доступ к FATу, который нужно организовать программно. А я ставил этот файл именно для того, чтобы эмулировать каталог. В архиве ещё и файл fon_spets.bin (шрифт от HardWareMan), он тоже понадобится.

Я так до сих пор и не посмотрел твои файлы, извиняюсь, займусь на досуге.

[PVV]

вопрос то был не об этом... процитирую сам себя с комментариями, возможно ранее плохо сформулировал вопросы...

Не пойму, как собрать OdiMount, и как его, затем, подкинуть в файловую систему для МХ в b2m? Что нужно сделать?

два вопроса:
первый - как собрать OdiMount, получить бинарный(исполняемый) файл?
второй - как собраный бинарник OdiMount подкинуть в файловую систему для МХ в b2m?

asm_odi.PNG

Перебросил комментарий SDDir, ошибок нет, а исполняемый файл не создается, только файл листинга.

на скриншоте две попытки сборки, первая неудачная, ругается на отсутствующий файл тестового каталога test_cat_odi.bin, я в исходнике нашел где этот файл используется:
;SDDir defs #0190 ; буфер для каталога SD карты
SDDir
*B test_cat_odi.bin

перебросил коммент:
SDDir defs #0190 ; буфер для каталога SD карты
;SDDir
;*B test_cat_odi.bin

вторая попытка сборки удачная, ошибок нет, а бинарный файл не создался! есть только файл odimounter.lst. fon_spets.bin я взял из папки с исходниками spets_br2/Source/ , соотв. на него ошибок и нет.

Аналогичные действия с spetsbrowser.a80 - все ок, я получившийся бинарный файл в расширение rks переименовал, закинул на образ SD карты в b2m в std режиме, и все работает... А как его в МХ системе внедрить то-же не пойму.

здесь я привел пример, что я механизм сборки понимаю, и делаю, вроде бы, все правильно.

Решил повторить действия по сборке, только в linux:
.../специалист/fdd/ODImounter$ wine ASM80WIN.EXE ODImounter.a80
Aссемблер 512 для Z80 V2.02 Win (c)1995,96,97,99 Медноногов В.C.
Проход:01 Ошибок:00
Проход:02 Ошибок:00
Кодовый блок: 20480..29485
Формат объектного кода: двоичный

и! появился файл odimounter.bin, так что вопрос номер 1 отпал, с виндой буду разбираться отдельно, а второй - как собраный бинарник OdiMount подкинуть в файловую систему для МХ в b2m остался.

я просмотрел какие вызовы в sd_bios использует odimounter и начал их прорабатывать, но пока нет программы из которой эти вызовы можно трассировать отлаживать код проблемно. В odimounter адрес точки входа в sd_bios аналогично spetsbrowser забит жестко, я его соот. поправил.

[fifan]

Используется компилятор для Z80 asm80win. Его вызов: asm80win, тогда нужно указать компилируемый файл с расширением a80 или сразу писать в командной строке: asm80win файл.a80.
Создаются два файла: файл.bin и файл.lst. Если создаётся только последний, то в нём нужно искать ошибки.
В эмуляторе с соответствующей поддержкой SD контроллера для запуска в MX режиме нужно загружать (File/Open/AVSh files) файл.cpu, который строится по принципу:
0000
0000
что означает адрес загрузки и адрес запуска (соответственно с 0000). Наш откомпилируемый файл.bin необходимо переименовать в файл.i80. Оба файла cpu и i80 должны храниться в одном директории (я клоду в emu/Specialist).
В любом случае необходимо смотреть как создаётся файл в листинге файл.lst. Если в начале файла a80 написать аргументы *L+ и *D-, то файл листинга будет выглядить так:

Code: Select all

#F306іCD03C8  і00:0017	 	  	call	#C803				; Ожидание ввода с клавиатуры

шестнадцатеричный адрес программы код программы номер строки мнемокод комментарий.
В процессе отладки необходимо добиться ноль ошибок, это ясно. При запуске файла в эмуляторе могут быть различные глюки. Я допустим не соблюдал адреса расположения кода, буфера под переменные и др. В частности компилятор под Z80, а эмулятор знает коды только 8080 соответственно и в неисполняемых кодах несоответствия процессоров эмулятор тупо встаёт.

Вот структура кода odimount.a80:
org #6400
программы, подпрограммы, тексты
...
SD_BIOS equ #8d1b
тут описываются переменные с адреса #8d1b и далее, можно вплоть до #9000. С начального адреса у меня расположен буфер под считанные данные с имиджа, в частности буфер под кусок имиджа я выделил в 25 кБайт - BufferSD. Еще есть буфера с адресов #e400 и #e800 (Buffer1 и Buffer2) - специально отведенное место для нужны работы с контроллером дисковода.

Из видео несколько постов назад видно, что на экран выводятся счётчики дорожек и секторов - это необходимо для отладки, в конечной программе нужно исключить т.к. процесс монтирования по времени растягивается. Без этого вывода на экран монтирование обоих образов (2*800 кБайт) занимает приблизительно около 10 секунд.

[fifan]

Для отладки в эмуляторе b2m я поступаю так. Чтобы узнать состояние регистров в определённом участке программы я тупо останавливаю программу, например для ввода символа. Программа тормозится, я захожу в отладчик (View/Start debugger/F1) и вижу не только состояние регистров, но и исполняемый код, всю память (RAM/ROM-диски, основную память, видеопамять).