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

[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 -- теперь не надо указывать размер чтения, он выставляется по размеру файла из ФС.

[Advertiser]

[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]

остались мелочи -- сделать создание и удаление файлов.

Как прогресс с мелочами? Не бросайте! Полезная либа получится. А там глядишь и fat32...

[Improver]

Как прогресс с мелочами?

Отвлёкся немного от FAT в сторону CP/M, в попытке определиться, как всё это туда прикрутить, но там, оказалось, всё сложнее... В свободное время доделаю эти мелочи, не оставлять же на полпути?

[Error404]

Отвлёкся немного от FAT в сторону CP/M, в попытке определиться, как всё это туда прикрутить, но там, оказалось, всё сложнее... В свободное время доделаю эти мелочи, не оставлять же на полпути?

Тоже думал на тему скрещивания CPM с FAT. Вариант MSX-DOS не нравится тем что несовместим на уровне BIOS (а точнее разметки файловой системы) и не все ПО поэтому заработает. Пришел к выводу, что удобнее всего на FAT как файлы хранить "сырые" образы дисков CP/M внутри которых CP/M распутает структуры сама, и в ee BIOS как раз и будет "конвертор секторов" для такого доступа:

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

Конечно, в такой образ CPM-файлы надо импортировать, а не просто прямо читать с FAT. Но и образов можно иметь много, и кидать их на флешку "как есть" (многое распространяется прямо в виде образов дисков)

[Improver]

удобнее всего на FAT как файлы хранить "сырые" образы дисков CP/M внутри которых CP/M распутает структуры сама, и в ee BIOS как раз и будет "конвертор секторов" для такого доступа

Да, тоже думаю, что такой вариант будет проще прикрутить к СР/М. Но тут может потребоваться ещё одна функция для драйвера FAT: произвольное чтение и запись в файл. Сейчас пока этого нет, файлы либо читаются, либо пишутся из памяти целиком.

Но и образов можно иметь много, и кидать их на флешку "как есть" (многое распространяется прямо в виде образов дисков)

Достаточно сложная задача получится, если учесть, что для этого нужно будет адресацию СР/М вида "трек / сектор(128байт)" переводить в кластеры, потом в физические секторы диска и читать/писать их по 512 байт через буфер. Но можно её существенно упростить, если не кидать файлы "как есть", а обеспечить их расположение в непрерывных областях, т.е. полное отсутствие фрагментации этих файлов, а также фиксированный размер образов. В этом случае будет достаточно знать первый сектор файла-образа на диске и читать/писать туда имеющимися уже в BIOS средствами. По сути, существующая реализация FAT уже имеет все функции для этого.

[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:	...		; тут, например, вывод ошибки "файл не найден"

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