SD карта и SDOS для 8и битных ПК

[PVV]

Полноценную запись файлов интегрированную в SDOS делать не планирую. На текущий момент SDOS минимально самодостаточна.
Основная 'фишка' SDOS - её размер.
Вообще SDOS надо рассматривать не как ОС, а как загрузчик полноценной ОС с несколько расширенным функционалом.
Весь дополнительный функционал можно реализовать в виде 'внешних' команд. Как аналог реализация такого в linux. Создаем в корневом каталоге папку SYSBIN, и уже в этой папке размещаем исполняемые файлы del, copy, mkdir, create и тп. Писать же эти команды уже не обязательно на asm, а на любом высокоуровневом языке, по типу Си, можно. Место в ОЗУ наших 'маленьких' ПК для этих 'внешних' команд в данном случае легко организовать имеющимся в SDOS функционале. Для этого в каталоге SYSBIN держим файл TMP.DAT размером, допустим 32КБ. Перед загрузкой 'внешней' команды пишем в этот файл содержимое ОЗУ, в это место загружаем команду, а по завершению восстанавливаем ОЗУ из нашего темп файла. Конечно, даже для этого в код SDOS нужно будет внести правки, но они гораздо проще и не столь объемные по коду чем все эти del, copy, mkdir, create...
Начинать эту работу с нуля желания и времени нет, но подключиться в процессе вполне смогу.

[Advertiser]

[Improver]

Полноценную запись файлов интегрированную в SDOS делать не планирую. На текущий момент SDOS минимально самодостаточна.

Ок, насчёт этого не возражаю.
У меня была идея добавить поддержку FAT16 в одну из Векторовских операционок, и только для жёсткого диска, возможно даже в виде внешнего модуля-драйвера, т.к. применяемое там разбиение НЖМД на кучу дискеток не очень удобно, но без функций создания и записи новых файлов это будет неполноценная замена... Как вариант, на первом этапе можно на FAT-диске насоздавать необходимое количество файлов "DISKETA001", "DISKETA002" и т.п., и использовать их, как дискеты, но, как я понял, программа записи в SDOS не умеет писать данные в произвольное место файла, только с его начала. Это ведь так? Значит понадобится как-то вычислять их расположение и писать данные на диск напрямую, мимо ФС... Да и такое решение усложнит ДОС, и не облегчит обмен файлами с большими ПК.

Для этого в каталоге SYSBIN держим файл TMP.DAT размером, допустим 32КБ. ...

С этим на Векторе проблем нет -- все существующие для него ОС, кроме одной забытой, требуют наличия электронного квази-диска на 256кб, там можно и хранить дополнительные утилитки, и даже запускать их прямо на нем, подменяя ОЗУ.

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

За это спасибо, делать что-то за меня не обязательно, а подсказать и посоветовать -- ценное предложение.

Не знаю, насколько далеко у меня пойдёт энтузиазм в этом направлении, но могу поделиться исходниками собранной мной на скорую руку первой тестовой программки для проверки работы Вектора с FAT, вот архив с исходниками и откомпилированным бинарником: TESTFAT.7z

Все обращения к DOS заменены на стандартный вызов через "CALL 5", подпрограммы для обращения к НЖМД использовал из МДОС Т-72, немного их модифицировав. Для экспериментов использовал образ карты SD3.IMG, взятый тут.

Тестовая программка подключает диск, выводит RKX-файлы корневой директории, переходит в директорию MX, возвращается в корень, читает и пишет в файл "TESTMX.RKX" -- в общем, тестирует работу всех имеющихся функций FAT16.

И, кстати, я немного поправил подпрограмму чтения файла с FAT -- теперь не надо указывать размер чтения, он выставляется по размеру файла из ФС.

[Error404]

но без функций создания и записи новых файлов это будет неполноценная замена...

Вот тут еще посмотрите:
https://github.com/lmaurits/lm512

Тоже мини-ОС с минимальной поддержкой FAT16. Запись и удаление там есть, нету seek разве что (а было бы нелишне).

[Improver]

Промежуточная версия FAT16, в архиве откомпилированная версия и исходники (с моими часто неуместными комментариями): TESTFAT1.7z

Теперь она умеет корректировать размер файла при записи до нуля и в большую сторону в пределах последнего кластера. Т.е., например, при исходном значении размера файла "SHAHMMX.RKX" в 6382 байта в него можно записать данные размером от 0 до 8192 байт, при этом размер файла в файловой системе будет скорректирован по количеству записанного. Данная процедура добавила к общему размеру FAT16 всего 185 байт по отношению к предыдущей версии, и это без особой оптимизации кода.

Далее нужно научить её дописывать кластеры, как в lm512 по ссылке Error404, и создавать новые файлы -- это как бы план-минимум.
И ещё, синхронизации первой и второй таблиц FAT пока нет, надо будет добавить и это, скорее всего в функцию сброса ФС.

[Improver]

Доделал в FAT16 запись в файл любого (доступного для 8-бит ПК) объёма данных, с корректировкой размера файла в записи директории и таблице FAT. Архив с тестовой программкой и исходниками: TESTFAT2.7z

На данный момент FAT16 умеет читать данные в соответствии с размером файла и записывать данные в существующий файл с корректировкой его размера. Далее остались мелочи -- сделать создание и удаление файлов.

Вопрос есть, немного офтоп, но как можно почекать образ диска? Примонтировать его в линуксе могу, считать/записать файлы, а вот проверку файловой системы не смог запустить -- не понимает его fsck...

[Error404]

В TODO: крайне полезной была бы дополнительная функция получения в массив всех кластеров файла. Думаю что кластеров хотя секторов было бы удобнее (но их слишком много - слишком большой массив в памяти). Для чего это нужно: очень частый способ применения мини-FAT - хранение на ней образов дисков (SCL, ODI, KDI и подобных) и "монтирование" этих дисков в локальной BIOS стародавних ОС с этих ОС минимальной правкой. А для этого надо последовательно и произвольно ходить direct к секторам "образа диска" лежащего на FAT, желательно быстро - по этому самому массиву секторов/кластеров (мимо распутывания структур FAT).

[Improver]

В TODO: крайне полезной была бы дополнительная функция получения в массив всех кластеров файла.

Ничего сложного, как пример:

	LXI D,RFILE	; ссылка на строку с именем файла (оканчивается нулём)
	CALL	F_OPEN	; открываем этот файл
	JC	NOFILE	; не открылось...
	LHLD BNEXT	; читаем номер текущего кластера файла
LOOP:	PUSH H		; сохраняем в стек
	CALL	FAT_N16	; найти следующий кластер
	JNZ	LOOP	; повторять до последнего кластера
	...		; в стеке список кластеров, далее делаем с ними то, что необходимо
NOFILE:	...		; тут, например, вывод ошибки "файл не найден"

Можно это всё загнать в отдельную функцию, если надо...

[HardWareMan]

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

[Error404]

Ну так-то еще и прерывания надо стопить в такой функции, а то при прерывании есть вероятность пропила памяти (если стеком фигачить прямо в целевой запрошенный массив)
Но это не принципиально, сохранение HL в массиве можно и изменить

[Improver]

Однако, можно перед вызовом переназначать стек и конец определять по адресу вершины.

Тут есть ещё, как минимум, два варианта: сохранять указатель стека ДО и ПОСЛЕ и вычислять разнице количество записанных туда номеров кластеров, или можно просто предварительно кинуть в стек 0000h (или FFFFh -- кластеров с таким номером быть не может) и читать из стека до получения этого числа. Ну или модифицировать приведённый выше фрагмент и сохранять значения сразу в некий буфер в нужном порядке и с подсчётом их количества. В общем, это просто пример, там возможны вариации.