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

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

Цитата:

---

Сообщение от PVV

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

---

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

Цитата:

---

Сообщение от PVV

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

---

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

Цитата:

---

Сообщение от PVV

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

---

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

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

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

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

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

Цитата:

---

Сообщение от Improver

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

---

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

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

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

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

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

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

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

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

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

Цитата:

---

Сообщение от Error404

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

---

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

Код:

---

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

---

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

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

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

Цитата:

---

Сообщение от HardWareMan

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

---

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