ImageUtils

[BlaireCas]

Может я не очень понимаю смысл ImageUtils - но такой вопрос.
Если верно понимаю - утилитка для работы с образами вида .dsk?
А оно может сделать аналог "sq LD0:"?
Было-бы очень круто.
(да да, я знаю что есть rt11.exe и там можно такое набрать и всё нормально, но по некоторым причинам мне допустим не очень она удобна)

[Hunta]

Если верно понимаю - утилитка для работы с образами вида .dsk?

C образами дискет и дисков, в том числе - интерлейсными - но если она знает про конкретный вариант интерлейса. Причём не только с ФС от RT-11.

А оно может сделать аналог "sq LD0:"?

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

[BlaireCas]

как вариант - фоновая распаковка и создание образа

Было-б очень неплохо иметь такой функционал.

Ну собственно почему я влез с такими вещами. Просто ну вот я пишу некий код. Он компилируется в винде (кроссплатформ все дела). На выходе получаю ну допустим .sav и какие-нибудь .dat файлики. Их надо закинуть в образ .dsk. То что плагин к тотал коммандеру это умеет я знаю, но там надо руками кидать, а это невесело. Я закидываю через утилитки от nzeemin чтобы ну можно было одним .bat-ником все скомпилять закинуть и сразу запустить на проверку.
При этом запросто возникает ситуация когда лезут пустые места в образе и они плодятся и множатся и надо squeez-ить в итоге однажды дисковый образ. Пока-что это делаю через rt11.exe, но она как-то не то чтобы криво работает, она просто может сбросить фокус в винде с активного окна, может оставить какой-то артефакт навроде незакрытого окна. Ну и патрон (вроде его штука) вряд-ли будет это чинить.

Если вот просто распаковать образ куда-нибудь в C:\Temp\Blablabla и затем там поменять файлики и запаковать назад в .dsk - было-б неплохо, но кажется тогда ведь потеряется нулевой блок с загрузчиком и что-то вообщем произойдет нехорошее.

[Hunta]

Если вот просто распаковать образ куда-нибудь в C:\Temp\Blablabla и затем там поменять файлики и запаковать назад в .dsk - было-б неплохо, но кажется тогда ведь потеряется нулевой блок с загрузчиком и что-то вообщем произойдет нехорошее.

Из плюсов - исходно авторами программы (на С), на которой основан функционал ImageUtils было реализовано сохранение и запись первичного (блок 0) и вторичного (блоки 2-5) загрузчиков, так что это есть и в ImageUtils.

Из того, что сейчас добавляется (планируется к добавлению) - улучшенное управление процессом создания - возможность указать метку для образа, количество сегментов каталога, расположение файлов - в идеале, при распаковке должно (как-то) сохранятся максимум информации, что бы можно было (при её наличии и желании) воссоздать первоначальный образ - один-в-один.

Но пока текущая цель - уверенность в правильном создании образа.

Так что создание образов - в процессе тестирования-отладки-доработки и я ещё не готов отдавать этот вариант - не уверен, что всё работает как надо, хотя результаты и есть.

[Hunta]

Удобная всё таки получилась идея - аттрибутами указывать расположение частей объектов в сырых данных (ака образ диска) Работа с ФС RT-11 первоначальна была переписана в лоб из исходника на C и было много кода ака "возьми байт (слово) по такому то смещению (блок плюс смещение в блоке)" плюс активное использование восьмеричных чисел в документации. Но работы с ФС RSX-11 уже была написана мной с нуля - и там всё было гораздо проще, хотя ФС сложней.

Сейчас переделываю работу с ФС RT-11 на аттрибутивный подход и вот как, скажем, выглядит парсинг сегментов каталога:

private int ParseDirectory()
{
  firstDirectorySegmentNum = (TPDP11Word)((homeBlock.DirectoryFirstBlockNumber - 6) / 2 + 1); // runs from (1 - default)

  RT11BlockNum dirBlk = DirSegmentToBlkNum(firstDirectorySegmentNum);  // start block of first directory segment
  firstDirectoryHeader = new(ImageData[dirBlk..(dirBlk + 2)].Bytes);   // first directory header

  RT11BlockNum firstDirBlk = DirSegmentToBlkNum(1);                                                                 // first block of direstory headers
  RT11BlockNum lastDirBlk = (RT11BlockNum)(DirSegmentToBlkNum(firstDirectoryHeader.TotalNumberOfSegments) + 1 + 1); // last block + 1 of direstory headers

  DirectorySegments directorySegments = new(ImageData[firstDirBlk..lastDirBlk].Bytes);

  TPDP11Word currentDirectorySegmentNum = firstDirectorySegmentNum;
  TPDP11Word nextDirectorySegmentNum    = 0;

  RT11BlockNum startBlockNum = firstDirectoryHeader.StartDataBlock; // start blocknumber for file data

  for (int idx = 0; idx < directorySegments.Length; idx++) //to avoid looping
  {
    DirectorySegment currentSegment = directorySegments[currentDirectorySegmentNum];

    /*** iterate directory entries in segment ***/
    int idy = 0;
    for (; idy < currentSegment.DirectoryEntries.Length; idy++)
    {
      DirectoryEntry currentEntry = currentSegment.DirectoryEntries[idy];

      if (currentEntry.Status.Has(F_ESTAT.E_EOS)) break;

      if (currentEntry.Status.Any(F_ESTAT.E_PERM | F_ESTAT.E_TENT | F_ESTAT.E_MPTY))
      {
        RT11File f = new()
        {
            Status          = currentEntry.Status
          , FileName        = currentEntry.Name.TrimEnd()
          , Extension       = currentEntry.Extension.TrimEnd()
          , IsGoodFile      = Yes
          , SpecifiedLength = currentEntry.FileSize
          , BlkNum          = startBlockNum;               // startblock on disk
          , BlkCount        = currentEntry.FileSize;
          , CreationDate    = currentEntry.Date.RDateTime;
        };

        files.Add(f); //save
      }

      startBlockNum += currentEntry.FileSize; // advance file start block in data area, also for empty entries
    }

    nextDirectorySegmentNum = currentSegment.DirectoryHeader.NextSegment;
    if (nextDirectorySegmentNum == 0) break;
  }

  return ERROR_OK;
}

Не всё, правда, получается сделать аттрибутами - скажем, вычисление количества сегментоа пришлось делать в лоб - (размер сырых данных)/(размер сегмента) Может что и придумаю

Заготовки сделал, теперь надо доделать вариант работы с сегментами на запись На Home блоке основа сделана, теперь доделать под (более сложный) вариант сегментов каталога (дописать код)

[Hunta]

Работу с сегментами каталога тоже переделал на работу через объекты.

Из оставшегося - работа с расширением элемента каталога (RT-11 позволяет добавить в элемент каталога произвольный набор байт фиксированного размера, вся работа с ними ложится на пользовательский код) и префикс-блоки в файл (доп блоки в начале файла, помимо блоков с обычными данными, опять же - вся работа с ними ложится на пользовательский код).

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

[Advertiser]

[Hunta]

Extra bytes доступны на чтение Стандартным способом

      firstDirectorySegmentNum = (TPDP11Word)((homeBlock.DirectoryFirstBlockNumber - 6) / 2 + 1); // runs from (1 - default)

      RT11BlockNum dirBlk = DirSegmentToBlkNum(firstDirectorySegmentNum);  // start block of first directory segment
      firstDirectoryHeader = new(new(ImageData[dirBlk..(dirBlk + 2)].Bytes)); // first directory header

      RT11BlockNum firstDirBlk = DirSegmentToBlkNum(1); // first block of direstory headers
      RT11BlockNum lastDirBlk = (RT11BlockNum)(DirSegmentToBlkNum(firstDirectoryHeader.TotalNumberOfSegments) + 1 + 1); // last block + 1 of direstory headers
      directorySegments = new(new MappedToByteArray(ImageData[firstDirBlk..lastDirBlk].Bytes));

      firstDirectoryHeader = directorySegments[firstDirectorySegmentNum].DirectoryHeader;
      dirExtrBytes = firstDirectoryHeader.ExtraBytesPerEntry;
      dirMaxSegmentInUse = firstDirectoryHeader.HighestExtent;
...
      TPDP11Word currentDirectorySegmentNum = firstDirectorySegmentNum;

...
      for (int idx = 0; idx < directorySegments.Count; idx++) //to avoid looping
      {
        DirectorySegment_S currentSegment = directorySegments[currentDirectorySegmentNum];
...
        /*** iterate directory entries in segment ***/
        int idy = 0;
        for (; idy < currentSegment.DirectoryEntries.Count; idy++)
        {
          DirectoryEntry_S currentEntry = currentSegment.DirectoryEntries[idy];

          if (currentEntry.Status.Has(F_ESTAT.E_EOS)) break;

          if (currentEntry.Status.Any(F_ESTAT.E_PERM | F_ESTAT.E_TENT | F_ESTAT.E_MPTY))
          {
...
            if (dirExtrBytes > 0)
            {
              // Extract extra bytes in directory entry as stream ...

              f.DirExtStream = new RT11FileStream();

              Parse2(f.DirExtStream, currentEntry.ExtraBytes);

              f.DirExtStream.Name = RT11_STREAMNAME_DIREXT;

[form]

Extra bytes доступны на чтение

Кстати в чистом RT-11 они тоже доступны на чтение/запись, но эту фичу не документируют

.CRE EMPTY.DSK/ALLO:494

.MOU LD EMPTY

.DUP LD:/Z:1/Y

.RU TEST
123456

.DUM/TER/ONL:6 LD:
LD:
BLOCK NUMBER  000006
000/ 000001 000000 000001 000002 000010 002000 114730 114730 *............X.X.*
020/ 114730 000000 000000 043124 123456 001000 000325 063471 *X.....TF.'..U.9g*
040/ 023364 000746 000000 043124 000000 004000 000000 000000 *t&f...TF........*
...

Во всяких вызовах у которых есть DBLK, если он нечетный, то по смещению 10 в AREA подразумевается подпрограмма которая вызывается из USR, при этом R1 указывает на слово с датой файла.

Код

        .TITLE  TEST
        .MCALL  .CLOSE,.ENTER,.EXIT     ;SYSTEM MACRO CALLS
        .MCALL  .FETCH,.LOOKUP,.PRINT   ;

$USRTO  =:      50                      ;USER TOP ADDRESS

START:: MOV     @#$USRTO,R1             ;GET TOP ADDRESS
        TST     (R1)+                   ;DON'T WRITE ON OURSELVES
        .FETCH  R1,#DBLK                ;FETCH HANDLER
        BCC     10$                     ;BRANCH IF OK
        .PRINT  #EFETC                  ;FETCH FAILED
        .EXIT                           ;EXIT

10$:    .ENTER  #AREA,#0,#DBLK!1,#1     ;CREATE FILE
        BCC     20$                     ;BRANCH IF OK
        .PRINT  #EENTR                  ;ENTER FAILED
        .EXIT                           ;EXIT

20$:    .CLOSE  #0                      ;CLOSE CHANNEL
        MOV     #E.GET,AREA+10          ;SET USER ROUTINE
        .LOOKUP #AREA,#0,#DBLK!1        ;LOOKUP THE FILE
        BCC     30$                     ;BRANCH IF OK
        .PRINT  #ELOOK                  ;LOOKUP FAILED
        .EXIT                           ;EXIT

30$:    .CLOSE  #0                      ;CLOSE CHANNEL
        MOV     #BUFF,R0                ;BUFFER
        MOV     EXTRA,R1                ;EXTRA WORD
        MOV     SP,R2                   ;ALLOW LEADING ZEROS
        CALL    $CBOMG                  ;CONVERT TO ASCII
        .PRINT  #BUFF                   ;PRINT EXTRA WORD
        .EXIT                           ;EXIT

E.GET:  MOV     2(R1),EXTRA             ;GET EXTRA WORD
        RETURN                          ;RETURN

E.SET:  MOV     #123456,2(R1)           ;STORE EXTRA WORD
        RETURN                          ;RETURN

EXTRA:  .BLKW                           ;EXTRA WORD
AREA:   .BLKW   4                       ;EMT AREA
        .WORD   E.SET                   ;HANDLE EXTRA BYTES

DBLK:   .RAD50  /LD XXXXXXXXX/          ;FILE NAME

BUFF:   .ASCIZ  /XXXXXX/
EFETC:  .ASCIZ  /FETCH FAILED/
EENTR:  .ASCIZ  /ENTER FAILED/
ELOOK:  .ASCIZ  /LOOKUP FAILED/

        .END    START

[свернуть]

[Hunta]

Полностью реализовано чтение-запись Extra bytes через соотвествующие объекты, а так же восстановлена работа с префикс-блоками в файлах. Как оказалась - и реализация от автора TU58fs (его ошибка) и моя реализация (свои ошибки плюс, естественно, ошибка от автора). Поправил свои ошибки и привел структуру префикс блоков в соотвествие с AA–PD6PA–TC "RT–11 Volume and File Formats Manual".

На пробных тестирования пока всё ок, RT-11 тоже нормально воспринимает такие образы, но как оказалось, по крайне мере PIP (TYPE file) плюёт на префикс блоки и тупо выводит ВСЁ на экран

- - - Добавлено - - -

Ошибки - наше всё
Первая обнаруженная - запись в Extra Bytes работает, а вот копирование информации при создании образа - нет
Поправил.

Вторая обнаруженная - если размер Extra Bytes достаточно (??) большой - что-то не так в создании каталога.
Работаю над.

[form]

размер Extra Bytes достаточно (??) большой

Для информации - вдруг пригодится.
RTEM при скане каталога делает проверки для extra bytes:

• больше 356 (8) - ошибка
• нечетное число - ошибка
• не совпадает со значением в 6 блоке - ошибка