PDA

Просмотр полной версии : DirSys - система каталогов для TR-DOS



CityAceE
18.08.2007, 13:17
В этой теме идёт обсуждение DirSys (Directory System) - программного расширения файловой TR-DOS, позволяющего без потери совместимости (конечно же, с оговорками!) с остальным программным обеспечением иметь каталоги на стандартных TR-DOS дискетах и их образах.

Основной файловый менеджер, поддерживающий эту систему - TR-DOS Naviagtor (TRDN) (http://zx-pk.ru/threads/2952) от автора DirSys. Однако не сегодняшний день накопилось немало других программ, как на самом ZX Spectrum, так и в виде утилит на PC, которые поддержали DirSys. Вот некоторые из них:

42 Text Viewer V1.1 48/128K (http://era-cg.su/grands/zxcreat.htm) by Grand, 2009
BMP Service v1.0 (https://vtrd.in/system/BMPSERV1.zip) by Brothers, 2000
Disk Trouble! V0.244 (https://vtrd.in/system/TROUB244.ZIP) by Nuts, 2001
Grand's Boot by Grand, 1997-2020
Grand's Screen Viewer V1.12 и V1.10DS (http://era-cg.su/grands/zxcreat.htm) by Grand, 2016 и 2008
и, конечно,
TR-DOS Navigator by CityAceE & AlexUzer & Grand, 2000-2019

Также на IBM PC существуют плагины для FAR Manager (https://vtrd.in/pcutilz/HALFELF.ZIP) by HalfElf and A.Medvedev.

(Актуальный список (https://zx-pk.ru/threads/5998-dirsys-sistema-katalogov-dlya-tr-dos.html?p=984968&viewfull=1#post984968) ведет Grand)

Полное описание DirSys входит в дистрибутив TRDN. Для удобства данное описание дублируется и здесь:


Directory System for TR-DOS
Документация на систему
=======================

Этот документ предназначен для программистов, желающих
поддержать систему каталогов для TR-DOS в своих программах.

Возможности системы
===================
Directory System (DS) представляет из себя надстройку над
популярной системой TR-DOS, и снимает ограничение на отсутствие
в TR-DOS каталогов. DS позволяет хранить на стандартном диске
системы TR-DOS до 128 файлов и одновременно до 128 каталогов,
включая корневой каталог. Каталоги могут иметь любую степень
вложенности, а так же любое содержимое. В одной директории может
располагаться до 127 каталогов и до 128 файлов. DS находится в
свободных секторах нулевой дорожки и не использует для своих
целей другого дискового пространства.

Совместимость
=============
DS полностью совместима с большинством программного
обеспечения и самой системой TR-DOS. Это значит, что любая
программа, не поддерживающая DS увидит все файлы, находящиеся на
диске, в том числе и находящиеся в каталогах, сами же каталоги
видны не будут. Это же касается стандартных команд TR-DOS LIST и
CAT. Можно копировать, стирать и переименовывать файлы на диске
с DS любыми коммандерами, а также стандартными командами TR-DOS
COPY, ERASE и NEW. В этом случае при переименовании файла, его
расположение в каталоге не изменится, а при создании или
копировании файла, новый файл будет помещен в корневой каталог.

Ограничения
===========
Ограничения использования другого программного обеспечения
совместно с DS связано прежде всего с использованием свободных
секторов нулевой дорожки. Поэтому конфликты могут возникнуть
лишь с теми программами, которые используют эти сектора. Хотя,
например, теневой сервис-монитор компьютера Scorpion может
хранить свои настройки на дискете с DS без конфликта с системой
до тех пор, пока количество каталогов не будет превышать 115.
Запись программ на диск с DS при помощи кнопки MAGIC уничтожит
систему, тем не менее, часть информации можно будет
восстановить.

Еще одно ограничение на систему накладывают стандартная
команда TR-DOS MOVE и уплотнение диска обычными коммандерами. В
этом случае будет нарушена сортировка файлов по каталогам. Для
уплотнения диска необходимо пользоваться программами,
поддерживающими DS и учитывающими ее особенности.

Возможности по восстановлению системы
=====================================
При повреждении системы, но не полном ее уничтожении
(должен быть не тронутым как минимум 10 сектор нулевой дорожки),
система частично может быть восстановлена. А именно, сохранится
сортировка всех файлов по каталогам, а также сортировка первых
117 каталогов.

Детальное описание системы
==========================
Система начинается в начале 10-го сектора сразу же за
системным сектором (сдвиг указан относительно начала 10 сектора
нулевой дорожки):

Дескриптор системы. 11 байт:

+ [#00], + [#01] CRC системы, обсчитываются байты с +[#02]
до + [N*#0B+#10B], где N -
порядковый номер последнего заданного
каталога;
+ [#02]... + [#07] сигнатура "DirSys" - идентификатор системы;
+ [#08] сигнатура "1" - целая часть номера версии
системы;
+ [#09], + [#0А] сигнатура "00" - дробная часть номера версии
системы;
Текущая версия системы 1.00

Таблица размещения файлов и каталогов. 256 байт:

+ [#0B] порядковый номер каталога, к которому принадлежит
0-ой файл;
+ [#0С] порядковый номер каталога, к которому принадлежит
1-ый файл;
...
+ [#89] порядковый номер каталога, к которому принадлежит
126-ой файл;
+ [#8A] порядковый номер каталога, к которому принадлежит
127-ой файл;

+ [#8B] порядковый номер каталога, к которому принадлежит
1-ый каталог;
+ [#8C] порядковый номер каталога, к которому принадлежит
2-ой каталог;
...
+ [#108] порядковый номер каталога, к которому принадлежит
126-ой каталог;
+ [#109] порядковый номер каталога, к которому принадлежит
127-ой каталог;

+ [#10А] #00 - байт зарезервирован;

Список имен каталогов. Размер варьирует:

+ [#10B]... + [#115] 11 символов - имя 1-го каталога;
+ [#116]... + [#120] 11 символов - имя 2-го каталога;
...
+ [N*#0B+#100]... + [N*#0B+#10A] 11 символов - имя
последнего, заданного каталога с порядковым
номером N;

+ [N*#0B+#10B] #00 - конец системы.

Размер списка имен каталогов зависит от количества заданных
каталогов. Минимальный размер - 1 байт, при отсутствии каталогов
на диске (единственный нулевой байт указывает на конец системы).
Максимальный размер - 1398 байт, при 127 заданных каталогах плюс
один нулевой байт указатель конца системы.

Порядковые номера каталогов нигде явно не заданы, а опре-
деляются простым счетом по порядку: от 1-го до 127-го. Корневой
каталог имеет порядковый номер 0.

Система инициализируется путем записи в 10 и 11 сектора
нулевой дорожки (сразу после системного сектора)
последовательности байт: #19, #D0, "DirSys100", 257 байт нулей.

Имена каталогов должны содержать символы с кодами ASCII от
#20 до #7F (в соответствующем plag-in'е by HalfElf для FAR
Manager'a на PC, в именах каталогов разрешено использование
русских символов в DOS-кодировке, это было согласовано с автором
DirSys). Если первый символ имени каталога равен коду #01, такой
каталог считается удаленным. Незначащие символы имени каталога
заполняются кодом ASCII #20 (пробел). Например, имя каталога "My
Dir", будет задана в списке имен каталогов как
последовательность байт: #4D #79 #20 #44 #69 #72 #20 #20 #20 #20
#20.

При уплотнении диска для освобождения диска от удаленных
файлов и каталогов необходимо провести уплотнение файлов как
обычно, затем произвести уплотнение списка имен каталогов, затем
провести пересчет и соответствующую коррекцию таблицы
расположения файлов и каталогов.

В своем минимуме DS занимает два сектора и при этом может
хранить полную информацию о 22 каталогах. Дальнейшее увеличение
количества каталогов вызовет увеличение числа секторов,
занимаемых системой.

Наличие системы на диске определяется по наличию в 10
секторе нулевой дорожки сигнатуры "DirSys" со сдвигом он начала
сектора +02. Целостность системы проверяется по совпадению
рассчитанной CRC с записанной CRC в самом начале 10 сектора.

После каждого изменения, затрагивающего DS (перемещение
файла или каталога в другой каталог, создание нового каталога,
переименование или удаление каталога, уплотнение системы)
необходимо скорректировать и записать CRC. CRC рассчитывается
начиная от 2 байта начала системы и до последнего символа
последнего заданного каталога включительно. Нулевой байт
идентификатор конца системы при подсчете CRC не учитывается.

CRC подсчитывается следующей программой:

;Входные параметры:
;HL - начальный адрес блока
;DE - конечный адрес блока
;Выходные данные:
;BC - контрольная сумма блока

CRC PUSH HL
INC DE
LD BC,#0000
CRC1 PUSH DE
LD A,C
XOR (HL)
LD E,A
PUSH BC
PUSH HL
LD BC,#0000
LD D,#08
CRC2 PUSH BC
LD A,C
RRA
LD A,B
RRA
LD B,A
LD A,C
RRA
LD C,A
POP HL
LD A,E
XOR L
AND 1
JR Z,CRC3
LD A,B
XOR #A0
LD B,A
LD A,C
XOR #01
LD C,A
CRC3 LD A,E
RRCA
AND #7F
LD E,A
DEC D
JR NZ,CRC2
POP HL
POP DE
LD A,D
XOR C
LD C,A
LD A,E
XOR B
LD B,A
INC HL
POP DE
LD A,H
CP D
JR NZ,CRC1
LD A,L
CP E
JR NZ,CRC1
DEC DE
POP HL
RET

Значение, возвращаемое в регистре B, сравнивается с байтом со
смещением + [#00], а возвращаемое в регистре C - + [#01].

Координаты автора
=================
По всем вопросам, возникшим по описанной системе,
обращайтесь по следующим координатам:

mailto:[email protected]
https://zx-pk.ru/threads/5998 (обсуждение на форуме "Speccy ─
наш выбор!")

----------------------------------------------------------------
(С) 2000 Станислав Юдин aka CityAceE
(С) 2000 Дмитрий Пьянков
(С) 2000 SIMM




3) Есть такая замечательная вещь как DirSys, было бы очень здорово заюзать это расширение TR-DOS, опять же необходимо для моей системы
О! Неужели поддержишь DirSys? :)

breeze
18.08.2007, 14:52
О! Неужели поддержишь DirSys? :)

Ну если отмотать в далёкий 1998 год ;) то уже в те далёкие времена Doors поддерживала работу с директориями ;) Я ещё не разбирался что из себя представляется DirSys, но директории в tr-dos моя давняя мечта ;)

CityAceE
18.08.2007, 16:10
Я ещё не разбирался что из себя представляется DirSys, но директории в tr-dos моя давняя мечта ;)
Ну, если вдруг дело дойдёт до реализации и появятся вопросы, то всегда готов ответить! :)

breeze
18.08.2007, 17:31
Ну, если вдруг дело дойдёт до реализации и появятся вопросы, то всегда готов ответить! :)

Вопросы это конечно хорошо ;) но я бы с радостью не отказался от готовых решений в виде либы: readFile, saveFile, deleteFile, createDir, removeDir :rolleyes:

CityAceE
19.08.2007, 03:22
Вопросы это конечно хорошо ;) но я бы с радостью не отказался от готовых решений в виде либы: readFile, saveFile, deleteFile, createDir, removeDir :rolleyes:

Уже неоднократно слышал про необходимость такой библиотеки, но её, к сожалению, не существует. Невозможно процедуры работы с каталогами выудить и из TRDN - слишком там всё запутано и переплетено. Однако если бы был некий стандарт на подобные библиотеки, то можно было бы её создать! Под стандартом я понимаю ВЕСЬ НАБОР необходимых функций, способ передачи их библиотеки, получение результата и т.д. Например, в твоём перечислении как минимум отсутствует moveFile, moveDir, так как для того чтобы переместить какой-то каталог или файл на новое место на диске требуется изменить один единственный файл, а пользоваться для этого процедурами копирования и удаления будет неправильно. Подозреваю, что ещё могут понадобиться функции просмотра текущего каталога и много чего ещё :)

Возможно, Elf/2 сможет сказать какой набор функций необходим, так как он прикручивал DirSys к FAR'у...

GriV
19.08.2007, 09:20
Стандарт есть, модульная архитектура от витамина, ничего сложного запортить туда нет, тем более что оно в АЛЯСМе всё...

breeze
19.08.2007, 14:14
Ну так давайте вычистим код и сделаем две либы для zx и pc.
Для zx желательно даже без турболоадеров всяких чисто #3d13 ?

CityAceE
19.08.2007, 14:38
Ну для PC пусть кто-то другой делает. А что касается ZX наверное стОит такую библиотеку сделать. Вот только чёткое ТЗ нужно.

Добавлено через 30 секунд

модульная архитектура от витамина
Где она лежит?

Vitamin
19.08.2007, 15:37
Где она лежит?
http://zxdocs.fatal.ru/coding/module.zip

Хотя, судя по давней дискуссии, народу она не приглянулась абсолютно. Но никаких конкретных предложений по улучшению не поступило...

breeze
19.08.2007, 19:36
Ну для PC пусть кто-то другой делает.

Ну насчёт этого видимо стоит поговорить с автором плагина для FAR'а там то оно явно поддерживается ? :rolleyes:


http://zxdocs.fatal.ru/coding/module.zip

спасибо почитаем...:cool:


Хотя, судя по давней дискуссии, народу она не приглянулась абсолютно. Но никаких конкретных предложений по улучшению не поступило...

К сожалению, зачастую так бывает, что нафиг никогму ничего не надо :mad:

valeron
19.08.2007, 21:15
...

К сожалению, зачастую так бывает, что нафиг никогму ничего не надо :mad:

Глупости, я вон в Майкрософт ни одного предложения по улучшению ХР не запостил, так что теперь ХР не нужна никому, давайте все на 98 переходить?
Просто народ сталкивался вплотную с этим делом, вот ни у кого эмоций и не возникло. А вот ты создай тупую и глючную операционку и тогда тебе столько выскажут, что подумаешь лучше бы никому нафиг ничего не надо было бы. :smile:

breeze
19.08.2007, 23:19
Глупости, я вон в Майкрософт ...

да вообще-то я по этому поводу особо и не гружусь :)

человек написал - я ему ответил ;)

valeron
19.08.2007, 23:52
да вообще-то я по этому поводу особо и не гружусь :)

человек написал - я ему ответил ;)

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

breeze
20.08.2007, 01:50
;) Людям свойственно меняться...

elf/2
20.08.2007, 11:52
Возможно, Elf/2 сможет сказать какой набор функций необходим, так как он прикручивал DirSys к FAR'у...


Ну насчёт этого видимо стоит поговорить с автором плагина для FAR'а там то оно явно поддерживается ?

боюсь что в ФАРских плагинах поддержка DirSys'а гвоздями прибита к FAR API. вряд ли имеет смысл ее оттуда в отдельную либу вытаскивать. я уже плохо помню что там и как, но по смутным воспоминаниям, прикрутить поддержку было не сложно.

в любом случае исходники открыты, хотя комментариев там чуть-чуть :(

Grand
22.08.2007, 03:19
Наверное не лишне будет сообщить для тех, кто вообще не знаком с Directory System, что единственным на сегодняшний день командером, где полностью реализована работа с этой системой, является TR-DOS Navigator (http://zxfiles.hut2.ru/system/trdn.zip) (с ним прилагается и соответствующая документация); его можно обсудить на нашем Форуме в теме "TRDN" (http://www.zx.pk.ru/showthread.php?t=2952).

http://mix.wol.bz/screens/trdn.png




я бы с радостью не отказался от готовых решений в виде либы: readFile, saveFile, deleteFile, createDir, removeDir;Уже неоднократно слышал про необходимость такой библиотеки, но её, к сожалению, не существует.Я тоже задумывался над созданием библиотеки функций Directory System (DirSys).
Предлагаю обсудить для начала ее структуру. Вот какой она видится мне: Установка текущего устройства, проверка наличия на нем DirSys, определение ее версии и целостности.
Вх.: логический номер устройства.
Вых.: DirSys: нет, есть, повреждена, версия, поддерживается ли библиотекой; другие ошибки. Создание DirSys на текущем устройстве.Вх.: нет.
Вых.: ошибки. Установка текущего подкаталога DirSys.
Вх.: адрес строки пути или номер подкаталога.
Вых.: ошибки: не найден подкаталог; другие. Возврат номера или строки пути текущего подкаталога DirSys.
Вх.: вид операции и адрес для строки пути (если надо).
Вых.: номер текущего подкаталога или его строка пути. Создание подкаталога в текущем подкаталоге.
Вх.: адрес стоки имени.
Вых.: номер созданного подкаталога; ошибки: уже существует, нет места, другие. Удаление подкаталога (в текущем подкаталоге или нет).
Вх.: номер или имя удаляемого подкаталога или адрес строки его пути.
Вых.: ошибки. Поиск подкаталогов, входящих в текущий подкаталог, и создание таблицы их номеров.
Вх.: адрес таблицы (ее длина не более 128-и байтов).
Вых.: таблица; ошибки: подкаталогов нет, другие. Поиск файлов, входящих в текущий подкаталог, и создание таблицы их номеров.
Вх.: адрес таблицы (ее длина не более 128-и байтов).
Вых.: таблица; ошибки: файлов нет, другие. Переименование текущего подкаталога.
Вх.: адрес строки имени.
Вых.: имя уже существует; другие ошибки. Помещение существующего файла в текущий (или существующий) подкаталог.
Вх.: номер файла; номер подкаталога.
Вых.: ошибки: нет файла, нет каталога, другие.
В библиотеке, по моему мнению, должны использоваться вызовы 15635 (#3D13).
Можно добавить функцию "Переименование фала", как отсутствующую в сатандартном наборе 15635, а также, и другие для работы с файлами.

Alexandr Medvedev
22.08.2007, 15:42
боюсь что в ФАРских плагинах поддержка DirSys'а гвоздями прибита к FAR API. Подтверждаю, вот только делать библиотеку для PC нет никакого смысла, т.к. использовать её негде.
А если и надо то никто не мешает написать переходник для FAR планинов. Эмуляторы и так TR DOS эмулируют, FAR уже понимает. Можно только авторов плагинов для TC попинать на предмет поддержки DirSys.

breeze
22.08.2007, 17:02
Подтверждаю, вот только делать библиотеку для PC нет никакого смысла, т.к. использовать её негде.

гм... ну если бы это действительно нафиг не нужно было :) я бы и не парился этим вопросом, как я уже писал в другой ветке, эта поддержка мне нужна в sjasmplus. Не думаю что автор прямо горит желанием реализовать это самостоятельно ;) но тем не менее у меня сейчас собирается DOORS из сорцов в загружаемую дискету TRD ;) Встал вопрос как мне соорудить в этой дискете необходимые директории и разместить файлы именно там. Если есть какая-то утилита или как-то можно хитро вызвать FAR c ключами, что бы он это сделал ???

Добавлено через 11 минут


Я тоже задумывался над созданием библиотеки функций Directory System (DirSys).


Обсудить конечно можно, но я сейчас работаю над драйверами для своего DOORS и на данном этапе я разделяю драйвер floppy и драйвер filesystem.

драйвер floppy чисто тупо читает блок данных с физического носителя в указанное место, дравер fs выдаёт требуемый результат, велосипед решил не изобретать, а взять стандарные функции для fs:


Mount - mount file system
Umount - unmount file system
GetFreeSpace - get free space on file system
ReadDir - read directory content
Access - check file is exist, can be read or write
Stat - get information about file
Open - open exist file or create new
Read - read data from opened file
Write - write data to the opened file
Lseek - positioning into opened file
Lock - lock access to the opened file
Close - close opened file
Unlink - delete file or symlink
Link - create symlink for file
Mkdir - create directory
Rmdir - delete directory

elf/2
22.08.2007, 17:38
Встал вопрос как мне соорудить в этой дискете необходимые директории и разместить файлы именно там. Если есть какая-то утилита или как-то можно хитро вызвать FAR c ключами, что бы он это сделал ???

список файлов фиксированный? лежат всегда в одних и тех же каталогах?

если да, то можно один раз их разложить руками и любым хекс-редактором выдернуть DirSys'ные сектора. а потом либо готовой тулзой (если она есть), либо написанной на коленке класть выдернутый блок на то же место в новых trd'шниках

breeze
22.08.2007, 17:41
список файлов фиксированный? лежат всегда в одних и тех же каталогах?

Да, нет... файлы могут и меняться (размер), что-то может новое появиться и.т.д. я ж написал, что TRD собирается с нуля из сорцов... :rolleyes:

elf/2
22.08.2007, 18:44
Да, нет... файлы могут и меняться (размер), что-то может новое появиться и.т.д. я ж написал, что TRD собирается с нуля из сорцов...
на размер наплевать.. новые файлы будут попадать в некий каталог по умолчанию

забыл сказать, важно чтобы порядок копирования файлов на диск сохранялся

breeze
22.08.2007, 22:27
Ну может ты и прав, в принципе dir всё время один и тот же ;)

Vitamin
23.08.2007, 00:30
Встал вопрос как мне соорудить в этой дискете необходимые директории и разместить файлы именно там.
Имхо, простейший путь- расширить функционал SAVETRD:

SAVETRD <filenameoftrdimage>,<filename_in_trdos>,<startadress>,<lengthofcode>

если filename_in_trdos будет составным (с путем), то создавать структуру и каталоги в образе.

Опять-таки, вопрос к автору... :)

boo_boo
20.10.2007, 19:30
hullo
у мя просьба: напишите плз псевдокодом алгоритм расчета дирсисовской crc

CityAceE
22.10.2007, 03:26
boo_boo, я брал эту процедуру в готовм виде из ZX-Ревю. Так что предложить что-то другое не могу. Но точно знаю, что elf/2 разобрлася с процедурой и перевёл её на ПЦ для поддержки в своём плагине для FAR. Может быть он поделится своим наработками? :)

elf/2
22.10.2007, 11:49
boo_boo, я брал эту процедуру в готовм виде из ZX-Ревю. Так что предложить что-то другое не могу. Но точно знаю, что elf/2 разобрлася с процедурой и перевёл её на ПЦ для поддержки в своём плагине для FAR. Может быть он поделится своим наработками? :)



WORD crc(BYTE* ptr, WORD len)
{
WORD crc = 0;

for(; len; len--)
{
BYTE tmp = crc ^ *ptr++;

WORD bCRC = 0;
for(int i = 0; i < 8; ++i)
{
WORD lBit = bCRC & 1;
bCRC >>= 1; bCRC |= lBit<<15; // RRA crc

if((tmp & 1) ^ lBit) bCRC ^= 0xA001;
tmp >>= 1;
}
crc = bCRC ^ (crc<<8 | crc>>8);
}
return (crc<<8 | crc>>8);
}

WORD Manager::calcDScrc(void)
{
return crc(zeroTrk+9*sectorSize+2, 256+9+11*noFolders);
}

вот как-то так :)

Grand
20.11.2007, 03:19
Самое важное применение часов, возможность сохранять в каталоге информацию о дате и времени создания файла.
Это заложено в систему или нет?Согласен, что это их самое полезное применение! Но к сожалению, места в системе слишком мало, чтобы хранить эту информацию, но теоретически придумать как прикрутить эти вещи можно :) Да и часы изначально были поддержаны только потому, что они у меня были :)

Добавлено через 48 минут
Вот прикинул...


Диапазон BIN Bit

Часы 23 10111 5
Минуты 59 111011 6
Секунды 59 111011 6

Год 63 111111 6
Месяц 12 1100 4
Число 31 11111 5
Год можно хранить с 1969 по 2031, ну или другой диапазон длительностью 63 года. Это для того, чтобы всю информацию о дате упихать в 4 байта. Хотя, конечно, можно отказаться от хранения секунд для расширения диапазона лет.

DirSys позволяет хранить информацию о 128 файлах и 128 каталогах. Таким образом для хранения всех дат потребуется аж 4 сектора нулевого трека.

DirSys в своём максимуме имеет размер 1398 байт и занимает при этом 6 секторов. Таким образом невозможно запихнуть на нулевой трек стандатную информацию о файлах (9 секторов), DirSys (6 секторов) и информацию о датах (4 сектора). Однако, если устаовить предел на максимальное количество каталогов до 64 штук, тогда вся эта информация поместится на нулевой дорожке TR-DOS диска:

Файловая система - 9 секторов
DirSys - 4 сектора
Информация о датах - 3 сектора

Я думаю, что 64 каталога на дискете - это более чем достаточно! При этом нулевая дорожка будет задействована на 100%.



Год можно хранить с 1969 по 2031, ну или другой диапазонДиапазон дат лучше сделать 1979-2043: я Спектруму и всем нам желаю долгой жизни! :)
Должна быть предусмотрена ситуация, когда дата объекта отсутствует (на это могут указывать нули в битах года).


Хотя, конечно, можно отказаться от хранения секундНаверное секунды секунды действительно лишние. И еще: так ли нужна дата создания каталога? может лучше ограничится только датами изменения файлов?
Кто как думает?


DirSys в своём максимуме имеет размер 1398 байт и занимает при этом 6 секторов.У меня результат другой: 1666 байтов, или чуть больше 6,5 секторов.


Однако, если устаовить предел на максимальное количество каталогов до 64 штук, тогда вся эта информация поместится на нулевой дорожке TR-DOS диска:

Файловая система - 9 секторов
DirSys - 4 сектора
Информация о датах - 3 сектораНужно, чтобы общая структура новой версии DirSys не сильно отличалась от старой, чтобы переделка программ, поддерживающих старую версию, была минимальной. Кроме того, и поддержка старой версии в новых программах тоже должна сохраниться.

CityAceE
20.11.2007, 07:05
Чем дальше, тем больше мне нравится идея с датами. И я убеждён, что её просто необходимо реализовать!


Диапазон дат лучше сделать 1979-2043
Я бы предпочёл начать отсчёт с 1980-го года. Вроде бы на PC именно с этой даты отсчёт шёл. А можно и с 1982 - года рождения Спектрума.


Должна быть предусмотрена ситуация, когда дата объекта отсутствует (на это могут указывать нули в битах года).
В этом случае скорее всего в области дат будут нули. И если это будет так, то можно принудительно назначать дату 01.01.1980, ну или, например, 18.04.1982 - ДР Спектрума.


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


И еще: так ли нужна дата создания каталога?
Обязательно нужна! Ведь именно по дате каталога чаще всего придётся судить о его содержимом, так как в большинстве случаев даты у файлов будут отсутствовать.


Нужно, чтобы общая структура новой версии DirSys не сильно отличалась от старой
А структура почти и не будет отличаться! Всё, что потребуется - это изменить номер системы с 1.00, на, скажем, 1.10. Это будет говорить софту, что можно работать не более чем с 64-мя каталогами и о необходимости искать даты в последних трёх секторах.

В последних трёх секторах поселить информацию о датах:

00-02 - контрольная сумма трёх последних секторов без первых двух байт, высчитывается по тому же алгоритму, что в DirSys. Позволит судить о целостности системы.

03-04 - свободные байты, можно поселить в них какой-то дескриптор или зарезервировать под будущие нужны. Под дескриптор можно задействовать только один байт, чтобы КС не была равна нулю. Эта информация будет сигнализировать софту, что информация о датах присутствует, а мы не имеет дело просто с пустыми секторами.

128*4 - данные о датах для 128 файлов.

63*4 - данные о датах для 63-х каталогах, 0-й каталог - корневой и не имеет даты. В крайнем случае дату корневого каталога можно хранить где-то в 9-м секторе - там много свободного места!

При таком раскладе весь существующий софт, который обучен DirSys будет работать и с новой системой. Я не думаю, что кто-то на сегодняшний день ухитрился сохранить на дискете более 64-х каталогов не в качесвте эксперемента, а для реальной работы! А других ограничений нет!

Так что надо делать! Чтобы система стала максимально полезной нужно как минимум включить её поддержку в TRDN и в плагин для FAR'а.

GriV
20.11.2007, 11:22
1) Ещё раз хочу повториться - хочется чтобы использовалась модульная структура библиотеки
2) Должна быть возможность выбора #3d13 и турболоадера
3) Поддерживаю всё вышесказанное

Nomy Graphics
20.11.2007, 15:21
CityAceE, просто хотел спросить - почему народ спрашивает про отдельные библиотеки? ведь исходник DirSys , надеюсь, имеется? а в нем разве отдельные функции не реализованы отдельными процедурами, о которых и стоит вопрос?
ведь небольшой же труд их просто оттуда изъять, или все настолько запутано??

CityAceE
20.11.2007, 15:42
DirSys - это система каталогов, подробно описанная и документированная. На Спектруме она в полной мере поддержана коммандером TR-DOS Navigator. Но в нём действительно всё настолько переплетено и запутано, что вытащить отдельные функции для работы с каталогами не представляется возможным. Гораздо проще всё написать самому с нуля. Тем более, что это не так сложно.

elf/2
21.11.2007, 13:20
Чем дальше, тем больше мне нравится идея с датами. И я убеждён, что её просто необходимо реализовать!
позволю себе добавить ложку дегтя:
для того чтобы идея с датами начала работать необходима поддержка расширения DirSys'а наиболее популярными редакторами, поскольку дата файла должна меняться при каждой его модификации. боюсь что вероятность появления подобной поддержки стремиться к нулю :(

CityAceE
21.11.2007, 13:46
Да, всё верно. Но тем не менее надо же с чего-то начать. Я попробую начать с модификации TRDN, а там, глядишь, и народ потянется. Хотя, учитывая суровую реальность, вряд ли.

Alexandr Medvedev
21.11.2007, 21:39
В крайнем случае дату корневого каталога можно хранить где-то в 9-м секторе - там много свободного места!Как бы не так. Назови хоть один байт. Всё там занято.
00...DF дескрипторы файлов
E0 байт 00 (признак окончания каталога)
E1...F4 служебные байты
F5...FF имя диска.
Ну и где свободные байты?

Нужно, чтобы общая структура новой версии DirSys не сильно отличалась от старой, чтобы переделка программ, поддерживающих старую версию, была минимальной.Нужна ПОЛНАЯ СОВМЕСТИМОСТЬ, не требующая изменеия кода существущих программ.
Чтобы система стала максимально полезной нужно как минимум включить её поддержку в TRDN и в плагин для FAR'а.По поводу плагина для FAR не вижу смысла делать поддержку DirSys который не совместим со старым.
Старые версии и так нигде не испозуются, а тут ещё новые придумали. Путаница да и только.
Если уж что и делать то только СОВМЕСТИМОЕ со старыми версиями.

Идея вобщем-то неплохая, но вот совместимость терять нельзя.

Добавлено через 7 минут
Чтобы не терять совместимоть базу с датами можно хранить например в отдельном файле с фиксированным именем. В таком случае совместимость сохраняется. Как и прежде такая конструкция будет бояться только команды TR DOS MOVE.

Grand
22.11.2007, 03:25
Диапазон дат лучше сделать 1979-2043Я бы предпочёл начать отсчёт с 1980-го года. Вроде бы на PC именно с этой даты отсчёт шёл. А можно и с 1982 - года рождения Спектрума.Я не настаиваю, но существуют платформы, появившиеся раньше iBM PC, и, теоритически, файл с такой платформы может быть перенесён и на Спектрум.




Должна быть предусмотрена ситуация, когда дата объекта отсутствует...В этом случае скорее всего в области дат будут нули. И если это будет так, то можно принудительно назначать дату 01.01.1980, ну или, например, 18.04.1982 - ДР Спектрума.Нет-нет! Именно именно без даты! Такая возможность есть в операционных системах на ДВК. И там она сейчас актуальна: диапазон дат был до 1999 года.




Наверное секунды секунды действительно лишние...А я всё же думаю, что не лишние...

И еще: так ли нужна дата создания каталога?Обязательно нужна!..."Ну, тут мы с вами не совпадаем..." :)



Всё, что потребуется - это изменить номер системы с 1.00, на, скажем, 1.10. Это будет говорить софту, что можно работать не более чем с 64-мя каталогами и о необходимости искать даты в последних трёх секторах.А почему не 1.01 - ведь изменения структуры минимальны?



... почему народ спрашивает про отдельные библиотеки? ведь исходник DirSys , надеюсь, имеется? а в нем разве отдельные функции не реализованы отдельными процедурами, о которых и стоит вопрос? ...Я предлагал для начала обсудить хотя бы структуру "пакета рабочих процедур". Когда будет ясно, как это должно выглядеть в общем виде, можно будет приступить и к написанию.

http://www.zx.pk.ru/showthread.php?p=98562#post98562


Назначение битов в байтах даты предлагаю таким:

Самый младший байт Самый старший байт
b0b1b2b3b4b5b6b7 b0b1b2b3b4b5b6b7 b0b1b2b3b4b5b6b7 b0b1b2b3b4b5b6b7
b0b1b2b3b4b5b0b1 b2b3b4b5b0b1b2b3 b4b0b1b2b3b4b0b1 b2b3b0b1b2b3b4b5
\--секунды-/\--минуты---/\---часы--/\--день--/\--мес--/\---год---/
Такое решение позволит легко производить сортировку по возрастанию или убыванию даты.

CityAceE
22.11.2007, 04:00
Как бы не так. Назови хоть один байт. Всё там занято.
00...DF дескрипторы файлов
E0 байт 00 (признак окончания каталога)
E1...F4 служебные байты
F5...FF имя диска.
Ну и где свободные байты?

У меня в голове всегда была примерно такая информация. Цитирую книгу Юрия Поморцева "TR-DOS для профессионалов и любителей":


Системную информацию о дискете содержит 8-й сектор нулевой дорожки, точнее, конец этого сектора, начиная с 225-го байта.



ИМЯ
АДРЕС
НАЗНАЧЕНИЕ

BUFF_ADR
0
#00
#5025
Начало системного сектора, загруженного в динамически выделяемый буфер для дисковых операций.

DCU_SEC
223
224
#DF
Слово. Содержит число секторов на диске, расформатированном при помощи DCU
(вначале равно значению в #E5). На диске расформатированом TR-DOS равно 0.

FR_S_NEXT
225
#E1
#5E06
Байт. Номер следующего свободного сектора. Инициализируется нулем.

FR_T_NEXT
226
#E2
#5E07
Байт. Номер следующей свободной дорожки. Инициализируется единицей.

TYPE DISC
227
#E3
#5E08
Байт. Тип дискеты:
#16 - 80 track, 2 side
#17 - 40 track, 2 side
#18 - 80 track, 1 side
#19 - 40 track, 1 side

N_FILES
228
#E4
#5E09
Байт. Количество файлов на диске, включая удаленные. Инициализируется нулем.

N_FRE_SEC
229
230
#E5
#5E0A
Слово. Количество свободных секторов. Инициализируется в зависимости от типа диска:
#09F0 - 80 track, 2 side
#04F0 - 40 track, 2 side
#04F0 - 80 track, 1 side
#0270 - 40 track, 1 side
При форматировании программой DCU на максимальное число дорожек:
#0A70 - 84 track, 2 side
#0AB0 - 86 track, 2 side

MAIN_BYTE
231
#E7
#5E0C
Байт. Количество секторов на дорожке. Должно быть #10, иначе диск признается неформатированным.

ZERO
232
#E8
Два байта нулей.

BLANK9
234
#EA
9 байтов пробелов (код #20).

ZERO
243
#F3
1 нулевой байт.

N_DEL_FIL
244
#F4
#5E19
Байт. Количество удаленных файлов. Инициализируется нулем.

DISC_TITL
245
#F5
#5E1A
Поле из 8 байт. Имя диска после форматирования.

ZERO
253
#FD
3 байта нулей. Конец главного сектора.


Почти всё совпадает с тем, что ты пишешь, кроме вот этого:


00...DF дескрипторы файлов

Что такое дескрипторы файлов?



Нужна ПОЛНАЯ СОВМЕСТИМОСТЬ, не требующая изменеия кода существущих программ.
Абсолютно с тобой согласен! Но давай разберёмся с предлагаемым мной вариантом.

Для начала давай вспомним, а какими программами DirSys поддержана? Во-первых, это TRDN, а во-вторых, это плагин для FAR'а. Именно эти две программы поддерживают систему в полной мере, то есть могут копировать файлы, создавать каталоги и, самое главное, делать уплотнение диска. Остальной немногочисленный список программ позволяет только видеть каталоги либо, самое максимальное, записывать в существующие каталоги файлы. Ни одна программа, кроме двух перечисленных, не умеет уплотнять диск с учётом наличия DirSys, а между тем именно уплотнение является тем критичным моментом, который может порушить систему и может повлиять на совместимость. Соответственно, если оперативно доработать эти две программы, то совместимость не пострадает.

Второй момент, это ограничение на 64 каталога на диске. Но и здесь не вижу проблем! Во-первых, есть дескриптор системы с её номером. Если номер версии равен 1.00, то работаем со 128-ю каталогами и забываем про даты. Если же 1.10, то делаем ограничение на 64 каталога и работаем с датами. И опять же повторюсь, я убеждён, что если кто-то реально и использует систему каталогов, то скорее всего не найдётся ни одного диска на котором число каталогов превышало бы цифру 64. А по сему вопрос отпадает сам собой.


По поводу плагина для FAR не вижу смысла делать поддержку DirSys который не совместим со старым.
Старые версии и так нигде не испозуются, а тут ещё новые придумали. Путаница да и только.
Если уж что и делать то только СОВМЕСТИМОЕ со старыми версиями.

Я попытался донести свои мысли, хотелось бы выслушать контраргументы.


Идея вобщем-то неплохая, но вот совместимость терять нельзя.
Да идея просто отличная! :) Даты - это последнее чего не хватало файловой системе TR-DOS для полноценного перегона из iS-DOS или MS-DOS. Трехсимвольные расширения есть, каталоги есть, дело за датами! Но я, конечно же, не беру во внимание ограничение на размер файлов в 255 секторов и другие ограничения (128 файлов, только непрерывные файлы и др.)


Чтобы не терять совместимость базу с датами можно хранить например в отдельном файле с фиксированным именем. В таком случае совместимость сохраняется. Как и прежде такая конструкция будет бояться только команды TR DOS MOVE.
Не нравится мне идея с отдельным файлом под это дело. Уже неоднократно предлагалось и саму DirSys посадить в отдельный файл, но я лично против такого подхода. Как ты сам сказал, системой практически никто не пользуется. Лишний файл явно будет мешаться, его будут удалять либо наоборот переписывать вместе с остальными файлами, там самым вводя, поддерживающий DirSys софт, в заблуждение. А когда система целиком и полностью живёт на нулевой дорожке, то про её существование никто даже и не догадывается. Если человек не пользуется системой и "грохнет" её по незнанию, то для этого человека не произойдёт ничего страшного. Но, скорее всего, система будет тихонько себе жить на нулевом треке. Главное - не уплотнять диск!

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

James DiGreze
22.11.2007, 06:11
Назначение битов в байтах даты предлагаю таким:

Самый младший байт Самый старший байт
b0b1b2b3b4b5b6b7 b0b1b2b3b4b5b6b7 b0b1b2b3b4b5b6b7 b0b1b2b3b4b5b6b7
b0b1b2b3b4b5b0b1 b2b3b4b5b0b1b2b3 b4b0b1b2b3b4b0b1 b2b3b0b1b2b3b4b5
\--секунды-/\--минуты---/\---часы--/\--день--/\--мес--/\---год---/
Такое решение позволит легко производить сортировку по возрастанию или убыванию даты.Тогда уж лучше наоборот: год-месяц-день-час-минута-секунда. Год в данном случае - старший разряд числа, а секунда - младший. Тогда и сортировку можно будет сделать хоть методом пузырька. ;)

CityAceE
22.11.2007, 06:32
А почему не 1.01 - ведь изменения структуры минимальны?
Всё же ограничение на 64 каталога и, самое главное, ввод поддержки дат заслуживают более глобального увеличения версии.



Тогда уж лучше наоборот: год-месяц-день-час-минута-секунда.
Grand так и написал, просто запись сделал непривычно - шиворот на выворот :)

Добавлено через 13 минут

Нет-нет! Именно именно без даты! Такая возможность есть в операционных системах на ДВК. И там она сейчас актуальна: диапазон дат был до 1999 года.
Однако чаще всего нам придётся иметь дело с FAT, NTFS, файловой системой iS-DOS. Везде присутствуют даты! Предположим, что плагин для FAR всё же доработали и он понимает даты. Также предположим, что мы имеем диск с доработанной системой DirSys, на котором есть каталог TEXT, в котором лежит несколько файлов *.txt. На самом каталоге и файлах установлен признак "без даты". Как должен поступать плагин при переводе этого каталога и файлов из TR-DOS в FAT (NTFS)? Назначить текущую дату? А при обратном перегоне уже текущая дата будет записана на диск? Тогда не совсем понятен смысл признака "без даты". На мой взгляд это лишнее. Если даты нет, значит её надо назначить принудительно: либо дефолтовой (например, 01.01.1980), либо текущей.

Costa
22.11.2007, 13:30
Не нравится мне идея с отдельным файлом под это дело. Уже неоднократно предлагалось и саму DirSys посадить в отдельный файл, но я лично против такого подхода. Как ты сам сказал, системой практически никто не пользуется. Лишний файл явно будет мешаться, его будут удалять либо наоборот переписывать вместе с остальными файлами, там самым вводя, поддерживающий DirSys софт, в заблуждение.
А если сделать системный файл невидимый или ввести атрибуты по типу read only/скрытый/архивный ?
Как раз больше вероятности убить систему если все свободные ектора задействованы и кто то по незнанию или невнимательности заюзает программу которая туда пишет тотже скорпион.
Отдельный файл ещё чем хорош, вот появятся ещё какие мысли по дальнейшему усовершенствованию а места то на 0 дорожке больше нету.


Однако чаще всего нам придётся иметь дело с FAT, NTFS, файловой системой iS-DOS. Везде присутствуют даты! Предположим, что плагин для FAR всё же доработали и он понимает даты. Также предположим, что мы имеем диск с доработанной системой DirSys, на котором есть каталог TEXT, в котором лежит несколько файлов *.txt. На самом каталоге и файлах установлен признак "без даты". Как должен поступать плагин при переводе этого каталога и файлов из TR-DOS в FAT (NTFS)? Назначить текущую дату? А при обратном перегоне уже текущая дата будет записана на диск? Тогда не совсем понятен смысл признака "без даты". На мой взгляд это лишнее. Если даты нет, значит её надо назначить принудительно: либо дефолтовой (например, 01.01.1980), либо текущей.
Если даты нет то имеем вид --:--:-- --/--/--

boo_boo
22.11.2007, 14:41
Всё, что потребуется - это изменить номер системы с 1.00, на, скажем, 1.10. Это будет говорить софту, что можно работать не более чем с 64-мя каталогами и о необходимости искать даты в последних трёх секторах. очень грустно, когда софт должен ориентироваться по номеру версии: код превращается в капусту из проверок версий, причем программеру еще надо будет держать в голове или под рукой список фич, той или иной версией поддерживаемых. жуть :)
IMNSHO такие вещи, как кол-во каталогов и поддержка дополнительных фич, должны быть непосредственно указаны в дескрипторе системы.

еще мысль -- а зачем именно даты, причем в обязательном порядке для каждого файла/каталога? почему бы не сделать поддержку абстрактных "тэгов", то есть полей данных, ассоциированных с файлом/каталогом? тогда, не меняя структуры данных, можно будет хранить хоть даты, хоть права, хоть чертей лысых

Alexandr Medvedev
23.11.2007, 16:59
очень грустно, когда софт должен ориентироваться по номеру версии: код превращается в капусту из проверок версий, причем программеру еще надо будет держать в голове или под рукой список фич, той или иной версией поддерживаемых. жутьочень метко сказал, именно по этой причине я и не вижу смысла вводить даты

Добавлено через 26 минут

Что такое дескрипторы файлов?Недокументированна� � особенность такая, в TR DOS можно не 128 а 142 файла хранить.

Grand
27.11.2007, 03:19
Предположим, что плагин для FAR всё же доработали и он понимает даты. Также предположим, что мы имеем диск с доработанной системой DirSys, на котором есть каталог TEXT, в котором лежит несколько файлов *.txt. На самом каталоге и файлах установлен признак "без даты". Как должен поступать плагин при переводе этого каталога и файлов из TR-DOS в FAT (NTFS)? Назначить текущую дату? А при обратном перегоне уже текущая дата будет записана на диск? Да. Потому-что другого не дано: это недоработка системы MS-DOS; мы же можем и должны сделать правильно. Впрочем, в W98, в "свойствах файла" иногда появляется "Изменён: неизвестно", значит кое-что там всё-таки предусмотрели.
Представим другую ситуацию. У нас есть Спектрум-совместимый компьютер без интерфейса CMOS-часов и TR-DOS Navigator с новой Directory System, поддерживающей даты. Мы берём готовый диск TR-DOS без DirSys с целью рассортировать файлы. Создаём каталог, переносим туда файлы, и что увидим? У всех файлов одинаковая дата: "01.01.80"!



Тогда не совсем понятен смысл признака "без даты"."Без даты" (или "пустая дата") - это как "пустой стринг" в BASIC: LET a$="" :) Как-бы в стринге ничего нет, но сам он есть! :)



Если даты нет, значит её надо назначить принудительно: либо дефолтовой (например, 01.01.1980), либо текущей.Программы, записывающие диски MS-DOS на Спектруме (TRMSHOB, Domen OS) так и делают, и это выглядит глупо: недоработка MS-DOS, как я сказал.



Если даты нет то имеем вид --:--:-- --/--/--Или вообще чистую строчку.




Что такое дескрипторы файлов?Недокументированна� � особенность такая, в TR DOS можно не 128 а 142 файла хранить.Directory System её не использует, и, надеюсь, никогда не будет :). Каталоги нужнее лишних файлов. Но это моё мнение.
Однако, хотелось бы узнать, а есть ли софт, использующий эту "недокументированную особенность"?

Alexandr Medvedev
27.11.2007, 09:13
Directory System её не использует, и, надеюсь, никогда не будет :). Каталоги нужнее лишних файлов. Но это моё мнение.Да почему не будет? Что мешает-то?
Лишние файлы храняться в начале системного сектора а DirSys храниться ПОСЛЕ системного сектора. Утверждение о том что каталоги нужнее лишних файлов мне не понятно. Они друг другу абсолютно не мешают.
В плагине к FAR на дисках в DirSys файлы после 128-го всегда относятся в корневому каталогу, предлагаю так-же сделать и в TRDN, для полной совместимости.
По поводу дат не совсем понятно за что эти даты будут отвечать. В FAT и NTFS есть даты содания, модификации и последнего доступа к файлу, а что планируется в DirDys?

Grand
29.11.2007, 03:42
В FAT и NTFS есть даты содания, модификации и последнего доступа к файлу, а что планируется в DirDys?Дату последнего изменения для файлов и создания для каталогов, как я полагаю. Другое в однозадачной ОС, как считаю я, - лишнее.
В общем-то, для TR-DOS дата создания и дата изменения, в целом, одно и тоже, поскольку, в большинстве случаев, прикладные программы записывают новый файл с изменениями, а старый удаляют.


Лишние файлы храняться в начале системного сектора а DirSys храниться ПОСЛЕ системного сектора. Утверждение о том что каталоги нужнее лишних файлов мне не понятно. Они друг другу абсолютно не мешают.Опять-таки моё мнение, но как-то непрофессионально это выглядит... DirDys - это прозрачная надстройка: софт, незнающий о ее существовании будет работать без ошибок со стандартным каталогом TR-DOS, а со 142-я файлами конфликт почти гарантирован. Я никогда не решусь хранить более 128-и файлов с таким "дополнением".
Кроме того, некоторые программы проверяют целостность информации нулевой дорожки, и естественно выдадут ошибку. Такую проверку мы планиоуем сделать в будущих версиях TR-DOS Navigator'а.

Grand
13.03.2008, 03:41
DirSys в своём максимуме имеет размер 1398 байт и занимает при этом 6 секторов.У меня результат другой: 1666 байтов, или чуть больше 6,5 секторов.Однако, ошибся и я. :)
1665 байтов. В последнем секторе остаётся 127 неиспользуемых байтов.

GriV
15.03.2008, 09:16
Проблема большей частью имхо обстоит не в том, как вводить даты а в том как их хранить чтобы программы на соседних платформах не ошибались и можно было использовать имеющийся инструментарий
то есть проще говоря надо писать не только на реальный диск но и на диск TRD формата который не может содержать дополнительных секторов/дорожек и прочих извратов которые на реале вполне даже возможны.
Погрязли в эмулировании называется %)
Вариант использования последней/предпоследней дорожки не устраивает?

CityAceE
27.08.2008, 09:57
Назначение битов в байтах даты предлагаю таким:

Самый младший байт Самый старший байт
b0b1b2b3b4b5b6b7 b0b1b2b3b4b5b6b7 b0b1b2b3b4b5b6b7 b0b1b2b3b4b5b6b7
b0b1b2b3b4b5b0b1 b2b3b4b5b0b1b2b3 b4b0b1b2b3b4b0b1 b2b3b0b1b2b3b4b5
\--секунды-/\--минуты---/\---часы--/\--день--/\--мес--/\---год---/
Такое решение позволит легко производить сортировку по возрастанию или убыванию даты.

Разбираясь с форматом хранения отгрузок Nintendo GameCube наткнулся на интересный метод хранения даты (его встречал и ранее, но забыл). В четырёх байтах хранится количество секунд, которое прошло начиная с определённой даты. То есть в 4 байта умещается диапазон в 136 лет и сколько-то там дней! Весьма неплохо... Вот только процедура перевода секунд в дату займёт прилично места.

Alexandr Medvedev
27.08.2008, 18:19
В четырёх байтах хранится количество секунд, которое прошло начиная с определённой даты.Вот нечто подобное -- кусок исходника плагина FAR для работы с архиватором .tar, тока точность повыше.
// Number of 100 nanosecond units from 01.01.1601 to 01.01.1970
#define EPOCH_BIAS _i64(116444736000000000)

void WINAPI UnixTimeToFileTime( DWORD time, FILETIME * ft )
{
*(__int64*)ft = EPOCH_BIAS + (__int64)time * _i64(10000000);
}

Grand
29.08.2008, 03:47
В четырёх байтах хранится количество секунд...Идея интересная. Хочется, чтобы была написана процедура на ассемблере Z80 ;) чтобы оценить ее быстродействие на реальном ZX.

CityAceE
29.08.2008, 06:43
По большому счёту, это получается нечто типа программы вечного календаря. Наверняка эта задача уже решалась для Z80 и не раз.

caro
29.08.2008, 08:49
Если еще помните, я сделал программу INTIME, которая запрашивает время из Интернета.
Время возвращается в виде четырех-байтного числа, так называемого <Unix time>.
А вот как оно пробразуется в дату:

------------------------------------------------------------
: Как преобразовать unix time в TDateTime
------------------------------------------------------------
unix timestamp представляет собой число секунд начиная с 1.01.1970

const
SecPerDay = 86400;
Offset1970 = 25569;

function UnixTimeToDateTime(UnixTime : LongInt): TDate;
begin
Result := UnixTime / SecPerDay + Offset1970;
end;

function DateTimeToUnixTime(DelphiDate : TDate) : LongInt;
begin
Result := Trunc((DelphiDate - Offset1970) * SecPerDay);
end;


function UnixToDateTime(const AValue: Int64): TDateTime;
Const HoursPerDay = 24;
MinsPerDay = HoursPerDay * 60;
SecsPerDay = MinsPerDay * 60;
UnixDateDelta = 25569;
begin
Result := AValue / SecsPerDay + UnixDateDelta;
end;

Я естественно писал на ассемблере, и заняла такая процедура не более полу-килобайта.

PS. Этот текст из FAQ для Unix.
На самом деле в интернете время с тайм-серверов возвращается как число секунд от 1.01.1900 года.

PSS. Исходник, если интересно, могу выложить.

Grand
02.09.2008, 03:31
PSS. Исходник, если интересно, могу выложить.Конечно, было бы интересно посмотреть. Мне такие задачи решать не приходилось...

CityAceE
02.09.2008, 05:14
На самом деле в интернете время с тайм-серверов возвращается как число секунд от 1.01.1900 года.
Стало быть через 29 лет, то есть в 2037-м году, эту перестанет работать :)


Исходник, если интересно, могу выложить.
Кнечно же, очень интересно!

caro
02.09.2008, 09:44
Стало быть через 29 лет, то есть в 2037-м году, эту перестанет работать :)Вот что об этом пишут в RFC 1305 (Network Time Protocol):

Note that since some time in 1968 the most significant bit (bit 0 of the integer part) has been set
and that the 64-bit field will overflow some time in 2036.
Should NTP be in use in 2036, some external means will be necessary to qualify time relative to 1900
and time relative to 2036 (and other multiples of 136 years).
Тоесть это надо будет учесть после переполнения счетчика.
Кстати счетчик, как вы наверное заметили 64-х битный, но NTP предусматривает пересылку только старших 32 бит.

Grand
05.09.2008, 03:59
Процедуры не маленькие... А еще ведь в командере придётся предусмотреть и обратную конвертацию.

Никто не знает, как дата хранится в IS-DOS?

CityAceE
05.09.2008, 07:18
А еще ведь в командере придётся предусмотреть и обратную конвертацию.
Да, я тоже сразу об этом подумал. Видимо такой способ не годится - слишком много кода получается.

elf/2
05.09.2008, 10:59
Никто не знает, как дата хранится в IS-DOS?
так же как на ФАТе:

wFatDate [in]
The MS-DOS date. The date is a packed value with the following format.

Bits Description
0-4 Day of the month (1–31)
5-8 Month (1 = January, 2 = February, and so on)
9-15 Year offset from 1980 (add 1980 to get actual year)

wFatTime [in]
The MS-DOS time. The time is a packed value with the following format.

Bits Description
0-4 Second divided by 2
5-10 Minute (0–59)
11-15 Hour (0–23 on a 24-hour clock)

Grand
10.09.2008, 03:10
Bits Description
0-4 Second divided by 2
5-10 Minute (0–59)
11-15 Hour (0–23 on a 24-hour clock)Что же получается - в MS-DOS секунды в элементах каталога всегда четные?

NovaStorm
10.09.2008, 11:13
Ну да. Даже на ntfs оно будет чётным если не пользоваться другими ф-циями api для миллисекундной точности.
О, сколько нам открытий чудных... =)

Grand
12.09.2008, 03:31
в MS-DOS секунды ... четные?
Ну да. ...CityAceE, может быть и нам это взять на вооружение? А сэкономленный бит можно зарезервировать, или сделать, чтобы он отвечал, например, файл "read only".

CityAceE
12.09.2008, 03:38
Да, я думаю, что если и делать поддержку даты, то по стандарту MS-DOS - всё равно используются те же запланированные 4 байта, к тому же реализация не отличается от той, что мы изначально обсуждали. На счёт секунд тоже согласен - такая точность в наших условиях явно будет достаточной.

boo_boo
12.09.2008, 03:48
такая точность в наших условиях явно будет достаточной а зачем в файловых датах вообще секунды? пытаюсь представить себе обычного (неразогнанного) пользователя, который извлекает из них пользу, не получается :)

CityAceE
12.09.2008, 05:54
Я с тобой согласен :) В большинстве случаев одной только даты достаточно. Но вроде как если перегонять файлы из системы в систему, то в одном из направлений будет терятся часть информации, в данном случае секунды.

James DiGreze
12.09.2008, 12:15
Далеко не всегда достаточно одной даты. Секунды конечно чаще излишни, но часы и минуты бывают очень даже полезны.

Grand
17.09.2008, 03:42
С "сэкономленным" битом раскладка даты может быть такой:

Самый младший байт Самый старший байт
b0b1b2b3b4b5b6b7 b0b1b2b3b4b5b6b7 b0b1b2b3b4b5b6b7 b0b1b2b3b4b5b6b7
b0b0b1b2b3b4b0b1 b2b3b4b5b0b1b2b3 b4b0b1b2b3b4b0b1 b2b3b0b1b2b3b4b5
\-секунды/\--минуты---/\---часы--/\--день--/\--мес--/\---год---/

Свободный бит я поставил самым первым, чтобы он не особо мешал при сортировке по дате.

Grand
03.11.2018, 16:44
Решил тут составить список известного ПО, которое поддерживает Directory System 1.00.
Список получился не внушительный, но все же... :)

42 Text Viewer V1.1 48/128K (http://era-cg.su/grands/zxcreat.htm) by Grand, 2009
BMP Service v1.0 (https://vtrd.in/system/BMPSERV1.zip) by Brothers, 2000
Disk Trouble! V0.244 (https://vtrd.in/system/TROUB244.ZIP) by Nuts, 2001
Grand's Boot by Grand, 1997-2020
Grand's Screen Viewer V1.12 и V1.10DS (http://era-cg.su/grands/zxcreat.htm) by Grand, 2016 и 2008
и, конечно,
TR-DOS Navigator by CityAceE & AlexUzer & Grand, 2000-2019

Также на IBM PC существуют плагины для FAR Manager (https://vtrd.in/pcutilz/HALFELF.ZIP) by HalfElf and A.Medvedev.

AndTorp
11.02.2019, 17:17
Здравствуйте. Возможно ли создание модуля поддержки Directory System 1.00 для Real Commander v2.6 ?

CityAceE
23.03.2020, 20:37
Про желанию основного в настоящий момент разработчика TRDN, Grand'а, добавил в первое сообщение описание системы.

Grand
24.03.2020, 04:55
Возможно ли создание модуля поддержки Directory System 1.00 для Real Commander v2.6 ?Про RC, наверное, лучше бы сказали его авторы. Впрочем, их ответ очевиден.

Есть давнышная идея, написать библиотеку процедур Directory System, и в 2007 году я выдвигал ее на обсуждение. Пока в этом направлении ничего не выработано, но я все равно надеюсь когда-нибудь к этому вернуться.

Grand
15.06.2020, 04:46
Итак, моя попытка сделать библиотеку процедур для работы с дисками TR-DOS и Directory System - Directory System Library V0.00. Смотрите вложение DSLIB.ZIP и полное описание в нем.

DirSysLib распространяется в виде исходного ассемблерного текста, и варианты ее использования такие: можно интегрировать ассемблерный текст в какой-либо свой проект, а можно скомпилировать его по необходимому адресу в ОЗУ и осуществлять вызовы от туда.


Сейчас в DirSysLib с десяток функций, вызываемых через единую точку входа. Функции пока достаточно просты, но с их помощью уже можно написать хотябы простую "бродилку" по каталогам DirSys. Смотрите во вложении пример EXAMPLE.ZIP и описание в нем.

https://i.postimg.cc/kgqVRP9J/1.png (https://postimages.org/) https://i.postimg.cc/j5wCYs6X/2.png (https://postimages.org/)


В будущем я планирую продолжить работу и добавить в DirSysLib новые функции.
Если кому-то интересен этот проект - присоединяйтесь. :)