-
Посмотрел на образы лент с резервными копиями RSTS, которые напоминали резервные копии BRU - ImagesEditor наглядно показал - насколько я ошибался. Так что, скорее всего - этот функционал будет отложен в сторону. Чем дальше займусь - пока не знаю - после доработки ImageUtils некоторое наведение порядка в файлопомойке :)
-
Чистка кода, рефакторинг и - продолжающийся отказ создания копии из исходных данных в пользу SmartArray. Наглядные последствия - время выполнения теста:
02.07.2025 -> 00:20:44.3066525
13.07.2025 -> 00:17:25.9997705
И это при том, что где-то в райне 9-10 июля была добавлена в обший списов распаковка пофиксинного образа ленты с DEC C 1.2 RSX
Пока ещё не везде и не для всех сценариев работы с данными - но процесс продолжается
-
Чистка кода, рефакторинг плюс одна идея. Но о ней позже - когда получится сделать и что-то показать :)
-
Реализация идеи несколько затянулась (заодно почистил зависимости), но результат есть :)
Код:
>dir 1
Directory of 1
0 File(s) 0 bytes
>ImageUtilsX.exe -unpack Src\m013.dsk 1\@m013.dsk rx01 rt
>dir 1\@m013.dsk\@MetaFiles@
Directory of 1\@m013.dsk\@MetaFiles@
28.07.2025 00:46 512 $BOOT.BLK
28.07.2025 00:46 19 732 $BOOT.LST
28.07.2025 00:46 804 $META.INF
28.07.2025 00:46 118 $ORDER.INF
28.07.2025 00:46 2 048 $SECBT.BLK
28.07.2025 00:46 10 446 $VOLUM.INF
6 File(s) 33 660 bytes
>type 1\@m013.dsk\@MetaFiles@\$BOOT.LST
.NLIST
.INCLUDE /ASCII.MAC/
; .INCLUDE /HWDF.MAC/
; .INCLUDE /DSMAC.MAC/
; .INCLUDE /MYMAC.MAC/
.LIST
.IDENT /01/
TPS =: ^O<177564>
TPB =: ^O<177566>
.ASECT
.=^O<0>
START:
000000 000240 <240><0> D NOP
000002 000005 <5><0> E RESET
000004 000404 <4><1> FT BR M00016
000006 000000 <0><0> .WORD 0
000010 000000 <0><0> .WORD 0
000012 041420 <20>/C/ J_H .WORD 41420
000014 116020 <20><234> X82 .WORD 116020
M00016:
000016 000400 <0><1> FP BR M00020
M00020:
000020 004067 /7/<BS> ALW JSR R0, M00070
000022 000044 /$/<0> 6
000024 000015 <CR><0> M .WORD 15
000026 000000 <0><0> .WORD 0
000030 005000 <0><LF> AX .WORD 5000
000032 041077 /?B/ JW9 .WORD 41077
000034 047517 /OO/ L$W .WORD 47517
000036 026524 /T-/ GJD .WORD 26524
000040 026525 /U-/ GJE .WORD 26525
000042 067516 /No/ Q2N .WORD 67516
000044 061040 / b/ O. .WORD 61040
000046 067557 /oo/ Q3G .WORD 67557
000050 020164 /t / EG. .WORD 20164
000052 067157 /on/ QZ1 .WORD 67157
000054 073040 / v/ R6 .WORD 73040
000056 066157 /ol/ QM9 .WORD 66157
000060 066565 /um/ QTU .WORD 66565
000062 006545 /e/<CR> BE_ .WORD 6545
000064 005012 <LF><LF> AXJ .WORD 5012
000066 000200 <200><0> CH .WORD 200
M00070:
000070 105737 /ê/<213> VOG TSTB @#TPS
000072 177564 /tš/ ___
000074 100375 /™/<200> TYU BPL M00070
000076 112037 <37><224> W$9 MOVB (R0)+, @#TPB
000100 177566 /vš/ ___
000102 100372 /‡/<200> TYR BPL M00070
000104 000777 /š/<1> L1 BR .
000106 000000 <0><0> .WORD 0
...... Тут одни нули :)
000774 000000 <0><0> .WORD 0
000776 000000 <0><0> .WORD 0
.END START
Некоторые косяки есть (скажем - нет .TITLE), но в целом - идея вполне :)
Так что теперь для всяких первичных и вторичных загрузчиков, а так же мониторов - можно будет сразу увидеть листинги :)
- - - Добавлено - - -
Насколько сказалось в плане быстродействия - пока не скажу, но в плане размера .exe - ImageUtilsX увеличился примерно в два раза.
- - - Добавлено - - -
Посмотрел на размер DisAsm11 - увеличение примерно на 120 кб меньше, чем размер DisAsm11 - то есть - не весь код из DisAsm11 подтянулся в ImageUtilsX :) Будет время - проанализирую - что ещё можно вырезать :)
- - - Добавлено - - -
В общем, к тестам, идущим примерно 17,5 минут - добавилось ещё примерно полминуты :) Но это так - грубо и навскидку :)
-
Погулял немного по исходнику F11ACP из P/Os (тот, который работает с подкаталогами третьего уровня). Первое впечатление - файл каталога определяется как файл с расширением DIR и версией 1. Не могу сказать - насколько точно, ещё рассматриваю..
- - - Добавлено - - -
Вдогонку. Для файла каталог тип записи - фиксированной длины и длина записи 16 (20(8)) байт. Но это проверяется и в F11ACP из обычного RSX
-
В процессе (в числе прочего) разборки файло-помойки. В том числе - распаковываются образы. В процессе распаковки налетаю периодически на образы, на которых ImageUtils валится. Обычная причина - в образе есть ошибки, которые ImageUtils не смог обойти. Пофиксил некоторое количество таких сценариев. Но интересней сценарии, когда ImageUtils валится в принципе на правильном (с точки зрения ФС) образе. Наткнулся на два таких сценария.
Первый - с файловой системой RSTS. Похоже при заведении нового UIC-а для пользователя - UFD в файловой системе для него создаётся не сразу, а при первом заходе. Надо будет проверить по докам. Но нашлись два таикх образа - UIC заведён, а UFD нет. Теперь такой сценрий обрабатывается без падения.
Второй - часто попадаются образы, размер которых меньше размера устройства, для которого образ создан или с которого он снят. Типа - в хвосте образа блоки не используются - чего держать образ полного размера, давайте его УМЕНЬШИМ. Нуу.. RT-11, например, на это наплевать. XXDP, скорее всего - тоже. А вот с RSX есть некоторые проблемы. Так как у неё в ФС присутствует файл BADBLK.SYS, куда система отправляет блоки, при чтении или записи которых возникает ошибка. Если диск был без сбоев, часто в этом файле присутствует самы последний блок - туда утилита BAD заносит информцию о том - нашлись или нет плохие блоки. Если не нашлось - только последний блок и используется. Если нашлись - возможно, что такие блоков будет не один (в определённых сценриях). Технически получается что уменьшать размер образа нельзя, а практически - если аккуратно - то можно, всё равно в BADBLK.SYS ничего инетерсного нет. Но. Есть ещё сценарий, когда BADBLK.SYS, даже при отсутствии плохих блоков, будет размером больше, чем один блок. Если диск - из семейства дисков с Last Track (или как они там называются). Если на пальцах - последняя дорожка на последнем цилиндре используется для хранения информации об обнаруженных плохих блоках, а так же их подмены. Конкретный пример - RL01 и RL02. И вот налетел я на образ RL02, где last track был частично (7 блоков из 10, если не ошибаюсь) срезан. Но в BADBLK.SYS они есть :) И ImageUtils успешно падал на этом :) Тоже пофиксил :) Причем сразу оба сценария. Но для второго, чтобы ImageUtils не падал, нужно будет явное указание устройства, несмотря на то, что для образов без интерлейса для RT, RSX и, похоже, RSTS это не требуется - ФС не привязывается к геометрии диска. Но как оказалось - некоторая привязка у, по крайне мере RSX, есть :)