DirSys - система каталогов для TR-DOS

[elf/2]

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

на размер наплевать.. новые файлы будут попадать в некий каталог по умолчанию

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

[breeze]

Ну может ты и прав, в принципе dir всё время один и тот же

[Vitamin]

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

Имхо, простейший путь- расширить функционал SAVETRD:

SAVETRD <filenameoftrdimage>,<filename_in_trdos>,<startadr ess>,<lengthofcode>

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

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

[boo_boo]

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

[CityAceE]

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

[elf/2]

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]

Самое важное применение часов, возможность сохранять в каталоге информацию о дате и времени создания файла.
Это заложено в систему или нет?

Согласен, что это их самое полезное применение! Но к сожалению, места в системе слишком мало, чтобы хранить эту информацию, но теоретически придумать как прикрутить эти вещи можно Да и часы изначально были поддержаны только потому, что они у меня были

Добавлено через 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]

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

Диапазон дат лучше сделать 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]

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

[Nomy Graphics]

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