ImageUtils

Поскольку подготовительные работы по добавке новой ФС (BRU+ODS1+ лента или диск) практически закончены, начал было вчера потихоньку писать код и в процессе приходит мне в голову мысль..

Мало того, что в образе (и диска и ленты) может быть несколько бэкапов BRU, а на ленте, технически, ещё и в перемежку идти не только данные от разные программ (на вскидку - ROLLIN, PRE, BRU и вроде как DSC), но ещё и просто файлы.

Скажем, лента BRU - это лента в формате ANSI (не помню, как он правильно у буржуинов называется, в нашем случае - это вроде ГОСТ 25752-83), так что там могут быть и простые файлы.

На диске с бэкап-сетами BRU создается файловая система ODS-1 (ака RSX) с единственным файлом BACKUP.SYS, который, насколько я знаю, иммитирует ленту.

Ну и так же есть диски MSCP, которые RT-11 умеет "бить на разделы", а так же мои CF, на которых могут быть одновременно и разделы с ФС RT и разделы с ODS-1.

А что бы окончательно добить.. Бэкап-сеты BRU (и возможно ROLLIN, PRE и DSC - тут не скажу, надо копаться в исходниках и доках) могут многотомными - то есть несколько лент или дисков (вон, для отладки ImageUtils валяется многодисковый бэкапсет MicroRSX образов RX50)

Вобщем, покрутив всё это безобразие в голове, пришёл к выводу, что в ImageUtils надо сначала добавить понятие Контейнер. Который сначала будет биться на отдельные образы в нём, а потом уже с образом будет разборка - какая ФС и что с ней хотят делать. Ну и плюс возможность - контейнер разобрать на отдельные образы и сохранить их в файлы. Или наоборот - из файлов собрать контейнер. Что то похожее я начал делать в программе CFMaint, но не все задумки закончил. Теперь, похоже, всё это плавное перейдёт в ImageUtils :)

И ещё бы придумать, как всё это богачество запихать в командную строку.. Пока приходит в голову только что-то типа командного файла..

Думаю дальше...

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

А ещё вспомнилось, что есть у меня SD-шки от PDP-11X - тоже контейнеры, только уже устройств (пока RK05 и RL02, но там ещё и RP были у автора)

А потом пришло в голову, что на CF могут быть и XXDP/DOS-11 разделы (стоит только написать драйвер CF для этих систем)...

А ещё есть RSTS.. А ещё есть другие ОС и не только от DEC.. Но этот момент пока сильно-глубоко в стороне.. Мне бы поддержку вышеописанного нарисовать :)

А так же опять всплывает момент с автоопределением ФС.. Но это тоже пока в сторону - пока только ручное указание ФС

Шерстю список (и описание) устройств с прицелом на проверки характеристик (типа размера блока и количества блоков), более полное описание (не только имя устройства но и имя контроллера), выявление тех, кто может быть контейнерами.

Попутно некоторые устройства (с интерлейсом) лишаются своих безинтерлейсных двойников, так как двойники создавались для возможности конвертирования интерлейс->без интерлейса без задания размера для выходного образа, но теперь, с упрощением команды конвертирования, это стало не нежным :)

Ну и как обычно перед серьёзным расширением функционала - был проведён рефакторинг :)

Обнаружились неожиданные контейнеры-кандидаты - диски от ОС ОСА от МС-0515, точнее говоря, образы, снятые с обеих сторон :)

Проверку и добавление описаний устройств вроде закончил, если только что-то новое после чтения документации всплывёт..
Начинаю эксперименты и доработку под контейнеры, подопытный кролик - DU :)

Новостей пока нет - продолжаются рефакторинг, доработки и эксперименты под контейнерными образы.

И думаю над тем, как передавать информацию из командной строки о ФС конкретных частей в контейнере. Пока только вариант - если работа с одной частью контейнера - можно из кс, а если со многими - через файл-описание, но возникает вопрос - как указать, что контейнер и как называется файл описание. Пока склоняюсь в пользу передачи как аргумента ключа с неким именем по умолчанию - примерно сделано для логов с ошибками чтения образа. Но есть некоторая проблема - контейер может быть как на входе, так и на выходе.. Вобщем - думаю..

Ещё из мыслей вслух.

ImageUtils была основана на переписанном с С коде TU58fs. И даже сейчас осталось прилично кода, напрямую переписанного оттуда. Как и много идей. Пусть и ImageUtils лишилась функционала - эмуляции TU58 - оттуда.

И одна из особенностей и TU58Em и ImageUtils - образ ЦЕЛИКОМ читается в память. Плюсы - быстрота работы, минусы - если образ большой - то и памяти понадобиться больше :) В принципе, я уже столкнулся с большии образами - самый большой на текущий момент - RSX-11_Freeware_Disk_2.iso - 635 Mб.

Но с образами-контейнерами, я думаю, может всплыть сценарий, когда образ не получится целиком прочитать в память - если образ будет больше 2 Гб. Так как максимальный размер массива в .NET (ну или по крайне мере в C#) - 2 Гб - 1 элемент. И технически такие образы у меня есть - с CF карт :) Тоже есть над чем подумать :)

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

Код:

>type stest.cmd ImageUtilsX @icf >type icf.cmd -unpack Src\11SKIT1_try1.tap 1\@11SKIT1_try1.tap dos11 tape -from 1\@11SKIT1_try1.tap Path WinFS -to 1\11SKIT1_try1.Pack.tap tape dos11 >stest.cmd ImageUtilsX @icf [2024-Jul-26 00:01:55 info ] 'Src\11SKIT1_try1.tap' proceeding... [2024-Jul-26 00:01:58 info ] '1\@11SKIT1_try1.tap' proceeding... [2024-Jul-26 00:01:58 info ] initialize empty WinFS file system on "1\@11SKIT1_try1.tap" [2024-Jul-26 00:01:58 info ] Converting... [2024-Jul-26 00:01:58] Files from "Src\11SKIT1_try1.tap" written to "1\@11SKIT1_try1.tap". [2024-Jul-26 00:01:58] 00:00:03.1703666 [2024-Jul-26 00:01:58 info ] '1\@11SKIT1_try1.tap' proceeding... [2024-Jul-26 00:01:58 info ] '1\11SKIT1_try1.Pack.tap' proceeding... [2024-Jul-26 00:01:58 info ] initialize empty DOS11 file system on "1\11SKIT1_try1.Pack.tap" [2024-Jul-26 00:01:58 info ] Converting... [2024-Jul-26 00:02:00] Files from "1\@11SKIT1_try1.tap" written to "1\11SKIT1_try1.Pack.tap". [2024-Jul-26 00:02:00] 00:00:02.1844931 >dir 1 Volume in drive ... is ..... Volume Serial Number is ..... Directory of ...\1 26.07.2024 00:02 <DIR> . 26.07.2024 00:02 <DIR> .. 26.07.2024 00:02 1 987 852 11SKIT1_try1.Pack.tap 26.07.2024 00:02 14 434 11SKIT1_try1.Pack.tap.FromFsToFs.MyLog.txt 26.07.2024 00:01 <DIR> @11SKIT1_try1.tap 2 File(s) 2 002 286 bytes 3 Dir(s) 159 370 285 056 bytes free

Вывод результата выполнения команд сдвинут вправо на два символа (что бы заметнее были команды в окне командной строки), результат вывода лога ImageUtils сдвинут на 4 символа вправо по той же причине.

В общем, в реализации не сильно много кода, наваял и отладил где-то за час :) В основном - время занял парсинг строк из ККФ по аналогии с Windows.

Так же была реализована (но ещё не оттестирована) и идея строк с продолжением - то есть если в конце строки определённый символ (в RSX, ЕМНИП - тире, для ImageUtils решил использовать &) - то следующая строка считается продолжением данной - и так пока в очередной строке в конце спец символа нет (или файл закончился) - тогда начинаем обрабатывать команду. Так что можно будет делать ОЧЕНЬ длинные команды, при этом не ухудшая читаемость :)

Добавил возможность из одного ККФ вызывать другой ККФ (есть проверка на зациклинность) и устроил комплексное тестирование.

Из неожиданностей - несколько ускорилась работа командного файле комплексного тестирования. Последний вариант работал около получаса, с добавлением ККФ - порядка 15 минут. Технически вроде понятно - ImageUtils вызывается не на каждой команде заново, но все равно - такого не ожидал :) Надо будет восстановить исходный вариант (без ККФ) и сравнить более точно.

Из ожиданностей - пара или тройка.. ну даже не сказать - ошибок, а скорей небрежностей при переносе с C на C# и неучёта того, что парсинг команды начинается не совсем с нуля. Поправил, пока всё ОК

Подведение итогов

Теперь ImageUtils понимает файл с командами (ККФ), команда в ККФ может состоять из нескольких строк (в конце стоит &), один ККФ может ссылаться на другой ККФ.

Появились мысли с добавлением одной или двух команд с прицелом на ККФ, но.. срочной необходимости в них нет - поэтому - потом :)

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

Со временем выполнения теста ошибся, там помимо ImageUtils работают ещё команды, в частности - сравнение файлов, так что не 15 минут, а 21, но тоже быстрее :)

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

Плюсом - рефакторинг, разборки с вариантами дисков с выделенной зоной замены плохих блоков (кодовое назавание - last track devices) - вроде теперь всё сделано правильно, а не вариант - ура, работает, и пофиксил ошибку в выводе подробной информации о ФС - в части информации о физических блоках (если есть отличие от логических блоков).

Из минусов - выходные закончились - времени будет меньше...

Пошерстил слегка общение с ФС.. Подправил код чтения из файла и записи в файл и...
Концепт для образов дисков в первом приближении

Код:

>dir 1 Directory of 1 29.07.2024 15:33 <DIR> . 29.07.2024 15:34 <DIR> .. 29.07.2024 14:31 <DIR> @m013-0.dsk 29.07.2024 14:46 <DIR> @m013-1.dsk 0 File(s) 0 bytes 4 Dir(s) 159 373 152 256 bytes free >ImageUtilsX -pack 1\@m013-0.dsk 1\m013.Test.dsk schema:du p:0 rt11 >ImageUtilsX -pack 1\@m013-1.dsk 1\m013.Test.dsk s:du partition:1 rt11 >ImageUtilsX -dir 1\m013.Test.dsk s:du p:0 rt11 >ImageUtilsX -dir 1\m013.Test.dsk s:du p:1 rt11 >dir 1 Directory of 1 29.07.2024 15:34 <DIR> . 29.07.2024 15:34 <DIR> .. 29.07.2024 14:31 <DIR> @m013-0.dsk 29.07.2024 14:46 <DIR> @m013-1.dsk 29.07.2024 15:34 67 108 864 m013.Test.dsk 29.07.2024 15:34 390 m013.Test.dsk.du.p0.Dir.MyLog.txt 29.07.2024 15:34 312 m013.Test.dsk.du.p0.Pack.MyLog.txt 29.07.2024 15:34 608 m013.Test.dsk.du.p1.Dir.MyLog.txt 29.07.2024 15:34 538 m013.Test.dsk.du.p1.Pack.MyLog.txt 5 File(s) 67 110 712 bytes 4 Dir(s) 159 306 035 200 bytes free >type 1\m013.Test.dsk.du.p0.Dir.MyLog.txt FDF331.DOC 302 27-OCT-1989 FDF333.DOC 118 27-OCT-1989 FILE .BAD 1 09-FEB-1990 EMPTY.FIL 65088 D 4 files, 421 blocks 65088 Free blocks >type 1\m013.Test.dsk.du.p1.Dir.MyLog.txt DDP278.LDA 38 13-FEB-1974 DDU278.LDA 39 13-FEB-1974 LDP278.LDA 35 13-FEB-1974 LDU278.LDA 35 13-FEB-1974 NDP278.LDA 37 13-FEB-1974 NDU278.LDA 37 13-FEB-1974 EMPTY.FIL 65246 D 7 files, 221 blocks 65246 Free blocks

Дальше - игры с получившимся результатом на предмет правильности, удобство в использовании и неучтённых нюансов.. :)

На неделе был прилично занят, так в основном мелкие косметические изменения. Вчера и сегодня удалось прилично посидеть.

Из изменений

Рефакторинг парсинга командной строки, но для удобства работы с ним, а не что-то внешнее. Хотя нет - внешнее тоже есть - более читабельный вывод результата встроенного генератора текста для команды -help.

Первой под работу сразу с несколькими (точнее говоря - пока вариант - ВСЕ разделы) разделами попала команда -dir:

Код:

>dir Directory of . 04.08.2024 15:04 <DIR> . 04.08.2024 00:49 <DIR> .. 04.08.2024 15:04 136 c.cmd 03.08.2024 20:09 67 108 864 m013.Test.dsk 2 File(s) 67 109 000 bytes 2 Dir(s) 159 236 890 624 bytes free >ImageUtilsX -dir m013.Test.dsk s:du part:all rt11 >type m013.Test.dsk.Dir.MyLog.txt Partition '0' FDF331.DOC 302 27-OCT-1989 FDF333.DOC 118 27-OCT-1989 FILE .BAD 1 09-FEB-1990 EMPTY.FIL 65088 D 4 files, 421 blocks 65088 Free blocks Partition '1' A .MAC 1 11-DEC-1972 BADB .SYS 1 11-DEC-1972 CILUS .LDA 39 11-DEC-1972 CL0 .SYS 1 11-DEC-1972 CL1 .SYS 1 11-DEC-1972 CL2 .SYS 1 11-DEC-1972 CL3 .SYS 1 11-DEC-1972 CL4 .SYS 1 11-DEC-1972 CL5 .SYS 1 11-DEC-1972 CL6 .SYS 1 11-DEC-1972 CL7 .SYS 1 11-DEC-1972 CREF .LDA 10 11-DEC-1972 DTBLD .BAT 7 11-DEC-1972 EDIT .LDA 13 11-DEC-1972 FILCOM.LDA 14 11-DEC-1972 FILDMP.LDA 7 11-DEC-1972 LDUMP .LDA 29 11-DEC-1972 LIBR .LDA 9 11-DEC-1972 LINK .LDA 57 11-DEC-1972 MACRO .LDA 39 11-DEC-1972 MONLIB.CIL 175 11-DEC-1972 ODT .OBJ 10 11-DEC-1972 PIP .LDA 35 11-DEC-1972 PIP .LIB 120 11-DEC-1972 SYSMAC.SML 26 11-DEC-1972 TEST .TXT 1 11-DEC-1972 VERIFY.LDA 68 11-DEC-1972 EMPTY.FIL 64798 D 28 files, 669 blocks 64798 Free blocks

По результатам доработки-эксперимента (помимо того, что теперь -dir умеет) - некоторый рефакторинг работы с разделами.

Плюс - идея - новый вариант передачи информации о разделах, которые попадают под работу. То есть на текущий момент команда -dir умеет - или один конкретный раздел или все. А будет уметь - не один, но и не все :) В том числе в варианте - разные разделы с разной ФС.

Но пока дальше, как обычно - комплексное тестирование. И только после его успешного выполнения - дальнейшие доработки

Текущий вариант для указания разделов

Код:

-dir 1\SectionsTest.dsk sectionschema[du]:0:2 rt11 -dir 1\SectionsTest.dsk s[du]:0:2[rt11] rt11

Работы продолжаются :)

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

Код:

>dir 1 Directory of K:\Repo\ForDebug\ImageUtils\!Test\1 04.08.2024 15:28 100 663 296 SectionsTest.dsk >ImageUtilsX -unpack 1\SectionsTest.dsk 1\@SectionsTest.dsk s[du]:0:2 rt11 >dir 1 Directory of K:\Repo\ForDebug\ImageUtils\!Test\1 10.08.2024 15:09 <DIR> @SectionsTest.dsk 04.08.2024 15:28 100 663 296 SectionsTest.dsk 10.08.2024 15:08 1 198 SectionsTest.dsk.du.s000.UnPack.MyLog.txt 10.08.2024 15:09 534 SectionsTest.dsk.du.s002.UnPack.MyLog.txt >dir 1\@SectionsTest.dsk Directory of K:\Repo\ForDebug\ImageUtils\!Test\1\@SectionsTest.dsk 10.08.2024 15:09 <DIR> S000 10.08.2024 15:09 <DIR> S002 >dir 1\@SectionsTest.dsk\S000 Directory of K:\Repo\ForDebug\ImageUtils\!Test\1\@SectionsTest.dsk\S000 10.08.2024 15:09 <DIR> @LOSTAndFound@ 10.08.2024 15:09 <DIR> @metaFiles@ 05.11.1998 00:00 512 BADB.SYS 05.11.1998 00:00 16 896 CILUS.LDA 05.11.1998 00:00 4 608 CREF.LDA 05.11.1998 00:00 6 656 EDIT.LDA 05.11.1998 00:00 6 144 FILCOM.LDA 05.11.1998 00:00 4 608 FILDMP.LDA 06.11.1998 00:00 1 536 FOO.BAR 05.11.1998 00:00 5 120 LIBR.LDA 05.11.1998 00:00 34 304 LINK.LDA 05.11.1998 00:00 19 968 MACRO.LDA 05.11.1998 00:00 92 160 MONLIB.CIL 05.11.1998 00:00 2 560 OVRLAY.LIB 05.11.1998 00:00 18 432 PIP.LDA 05.11.1998 00:00 33 280 VERIFY.LDA >dir 1\@SectionsTest.dsk\S002 Directory of K:\Repo\ForDebug\ImageUtils\!Test\1\@SectionsTest.dsk\S002 10.08.2024 15:09 <DIR> @LOSTAndFound@ 10.08.2024 15:09 <DIR> @metaFiles@ 12.06.1972 23:00 41 984 CREF.04A 12.06.1972 23:00 512 DOSV4.PAL 12.06.1972 23:00 144 896 MACRO.04A 12.06.1972 23:00 9 216 PST.04A 12.06.1972 23:00 7 680 SYSMAC.SML

Возможен так же вариант s[du]:all - под работу попадут все секции в дисковом образе
И на текущий момент (вроде бы) работоспособны только команды -dir и -unpack. И до какой-то степени комбинация -from -to - если -to ссылается на ФС Windows

Теперь оценка изменений и более детальное тестирование -unpack, а так же вариант, когда секция из образа будет распаковываться в файл образа секции - то есть образ с секциями можно будет разобрать не только на файлы из секций, но и на секции целиком

А затем -pack :)

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

Вдогонку - пока существует только один вариант разбиения образа на секции - как это сделано для дисков MSCP (ака DU) в RT-11, но модель расширяемая - это позволит добавить мои секционированные CF (два варианта), а также образы SD от PDP-2011 - в вариантах RK, RL и, в принципе - RH - но для него надо посмотреть - какие варианты возможны.

Более-менее.. :)

Код:

>dir 1 Directory of ...\1 10.08.2024 22:32 <DIR> @Dosv10-01A-RK.dsk 10.08.2024 22:32 <DIR> @gs0002.dta 10.08.2024 22:32 <DIR> @m013.dsk >type SectionsTest.cmd -pack "1 @Dosv10-01A-RK.dsk\[1,1]" 1\SectionsTest.dsk s[du]:0 rt11 -pack 1\@m013.dsk 1\SectionsTest.dsk s[du]:1 rt11 -pack "1\@gs0002.dta\[1,1]" 1\SectionsTest.dsk s[du]:2 rt11 -unpack 1\SectionsTest.dsk 1\@SectionsTest.dsk s[du]:0[]:2 rt11 -dir 1\SectionsTest.dsk s[du]:1[rt11] rt11 -dir 1\SectionsTest.dsk section[du]:0:2[rt11] rt11 >ImageUtilsX @SectionsTest.cmd K:\Repo\ForDebug\ImageUtils\!Test>dir 1 Directory of ...\1 10.08.2024 22:32 <DIR> @Dosv10-01A-RK.dsk 10.08.2024 22:32 <DIR> @gs0002.dta 10.08.2024 22:32 <DIR> @m013.dsk 10.08.2024 22:37 <DIR> @SectionsTest.dsk 10.08.2024 22:37 100 663 296 SectionsTest.dsk 10.08.2024 22:37 1 794 SectionsTest.dsk.Dir.MyLog.txt 10.08.2024 22:37 1 128 SectionsTest.dsk.du.s000.Pack.MyLog.txt 10.08.2024 22:37 386 SectionsTest.dsk.du.s001.Dir.MyLog.txt 10.08.2024 22:37 308 SectionsTest.dsk.du.s001.Pack.MyLog.txt 10.08.2024 22:37 456 SectionsTest.dsk.du.s002.Pack.MyLog.txt 10.08.2024 22:37 534 SectionsTest.dsk.du.s002.UnPack.MyLog.txt >dir 1\@SectionsTest.dsk Directory of ...\1\@SectionsTest.dsk 10.08.2024 22:37 33 554 432 S000.section 10.08.2024 22:37 <DIR> S002

По результатм тестирования - исправление неточностей, ошибок, рефакторинг.

-unpack вроде ок (если только с дальнейшей доработкой что-то не вылезет)

Теперь -pack

-pack, первый подход к снаряду

Код:

>dir 1 Directory of ...\1 >type icf.cmd -unpack Src\DOSv10-01A-RK.dsk 1 @Dosv10-01A-RK.dsk rk035 dos11 -unpack Src\gs0002.dta 1\@gs0002.dta tu56 dos -unpack Src\m013.dsk 1\@m013.dsk rx01 rt -unpack Src\maindec-11-dzzgc-c-yb.img 1\@maindec-11-dzzgc-c-yb.img RX01 xx -pack "1 @Dosv10-01A-RK.dsk\[1,1]" 1\SectionsTest.dsk s[du]:0 rt11 -pack 1\@m013.dsk 1\SectionsTest.dsk s[du]:1 rt11 -pack "1\@gs0002.dta\[1,1]" 1\SectionsTest.dsk s[du]:2 rt11 -unpack 1\SectionsTest.dsk 1\@SectionsTest1.dsk s[du]:0[]:1[]:2[rt11] -unpack 1\SectionsTest.dsk 1\@SectionsTest2.dsk s[du]:0[]:1[rt11]:2[rt11] -unpack 1\SectionsTest.dsk 1\@SectionsTestAll.dsk s[du]:all[] -dir 1\SectionsTest.dsk rt11 -dir 1\SectionsTest.dsk s[du]:0[rt11] rt11 -dir 1\SectionsTest.dsk s[du]:1[rt11] rt11 -dir 1\SectionsTest.dsk section[du]:0:2[rt11] rt11 -pack 1\@SectionsTest1.dsk 1\SectionsPackTest1.dsk s[du]:0[]:1[]:2[rt11] -pack 1\@SectionsTest2.dsk 1\SectionsPackTest2.dsk s[du]:0[]:1[rt11]:2[rt11] >ImageUtilsX @icf >dir 1 11.08.2024 21:05 <DIR> @Dosv10-01A-RK.dsk 11.08.2024 21:05 <DIR> @gs0002.dta 11.08.2024 21:05 <DIR> @m013.dsk 11.08.2024 21:05 <DIR> @maindec-11-dzzgc-c-yb.img 11.08.2024 21:05 <DIR> @SectionsTest1.dsk 11.08.2024 21:05 <DIR> @SectionsTest2.dsk 11.08.2024 21:05 <DIR> @SectionsTestAll.dsk 11.08.2024 21:05 100 663 296 SectionsPackTest1.dsk 11.08.2024 21:05 456 SectionsPackTest1.dsk.du.s002.Pack.MyLog.txt 11.08.2024 21:05 100 663 296 SectionsPackTest2.dsk 11.08.2024 21:05 308 SectionsPackTest2.dsk.du.s001.Pack.MyLog.txt 11.08.2024 21:05 456 SectionsPackTest2.dsk.du.s002.Pack.MyLog.txt 11.08.2024 21:05 100 663 296 SectionsTest.dsk 11.08.2024 21:05 1 198 SectionsTest.dsk.Dir.MyLog.txt 11.08.2024 21:05 1 128 SectionsTest.dsk.du.s000.Pack.MyLog.txt 11.08.2024 21:05 1 794 SectionsTest.dsk.du.s000.s002.Dir.MyLog.txt 11.08.2024 21:05 420 SectionsTest.dsk.du.s001.Dir.MyLog.txt 11.08.2024 21:05 308 SectionsTest.dsk.du.s001.Pack.MyLog.txt 11.08.2024 21:05 386 SectionsTest.dsk.du.s001.UnPack.MyLog.txt 11.08.2024 21:05 456 SectionsTest.dsk.du.s002.Pack.MyLog.txt 11.08.2024 21:05 534 SectionsTest.dsk.du.s002.UnPack.MyLog.txt >fc 1\SectionsTest.dsk 1\SectionsPackTest1.dsk /b Comparing files 1\SectionsTest.dsk and 1\SECTIONSPACKTEST1.DSK FC: no differences encountered >fc 1\SectionsTest.dsk 1\SectionsPackTest2.dsk /b Comparing files 1\SectionsTest.dsk and 1\SECTIONSPACKTEST2.DSK FC: no differences encountered

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

Теперь включу новые тесты в общую цепочку и прогоню все

Поскольку существенные доделки и поскольку опять рабочая неделя - на неделе скорее всего оценка ущерба :) и рефакторинг

Как обычно - реализовав что-то, поигравшись и посмотрев на реализацию - понял, что все на самом деле проще, чем казалось :)

Несколько переработал код (тестирую), что, как ни странно, позволило сделать пару шагов к реализации поддержки секций в паре -from -to :)

После исправления ошибок и неучтённостей последних переделок - оказалось - это не два шага было :)
Заработали сразу:

Код:

-from "1\@DOSv10-01A-RK.dsk\[1,1]" Path WinFS -to 1\SectionsTest0.dsk s[du]:0 rt11 -from 1\@gs0002.dta Path WinFS -to 1\SectionsTest1.dsk s[du]:1 rt11

То есть - надо напридумывать тестов - и вперёд :)

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

В какой-то момент для упрощения командной строки добавил вывод лога операции автоматом в файл. Имя файла лога формируется или по имени выходного файла (если там не каталог Windows) или по имени входного файла (если выходной файл - на самом деле каталог Windows). Всё работало достаточно логично для батников или @-файлов и файлы логов не затирались, если только в командном файле не было одинаковых выходных или входных файлов. Но это как бы уже на совести автора командного файла :)

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

Возможно, что придумаю варианты формирования лога, которые будут уменьшать вероятность совпадения имени лога, но пока (а может быть и всегда) - так :)

Ну и в планах - сделать возможным ручное указание имени лога для операции. Но это - не в первоочередных планах - пока - секции и ленты BRU :)

Вроде текушую концепцию секций добил, теперь попробую добавить ещё один вариант секций (из мира CF) и посмотреть - что вылезет :)

Некоторое время повозился с переносом своей (недоделанной) утилиты CFMaint в общую кодовую базу. Некоторые вещи из неё перенесу в ImageUtils, а так же - есть некоторые задумки по развитию CFMaint (но это потом).

Попробовал добавить схемы секций из того, старого подхода.

Выводы.

- Вариант работы со схемами - вполне себе рабочий - доработок потребовалось мало (по сути - только добавить новые варианты вычисления смещения до и размера секции)

- Нужна возможность задавать диапазон секций, что то типа 2..10. Не уверен, что пройдёт вариант 2-10, но надо попробовать - этот вариант более приемлем при формировании имен логов :)

Ну и - в работу пошли образы размером больше 2 Гб, пока, правда, сами секции - меньше, так что пока проблем нет :)

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

Одна из причин, пришедших в голову - почему желательна возможность указать диапазон :)

Код:

>dir Directory of ... 22.04.2020 22:33 4 017 807 360 001 RT под 1801ВМ3.dsk 18.08.2024 22:59 185 c.cmd 18.08.2024 22:59 0 log.txt >type c.cmd dir type c.cmd ImageUtilsX -unpack "001 RT под 1801ВМ3.dsk" "@001 RT под 1801ВМ3.dsk" s[cf11]:all[] dir dir "@001 RT под 1801ВМ3.dsk" >ImageUtilsX -unpack "001 RT под 1801ВМ3.dsk" "@001 RT под 1801ВМ3.dsk" s[cf11]:all[] >dir Directory of ... 18.08.2024 23:00 15 046 !Log.txt 22.04.2020 22:33 4 017 807 360 001 RT под 1801ВМ3.dsk 18.08.2024 23:00 2 460 001 RT под 1801ВМ3.dsk.cf11.s000.s001.s002.s003.s004.s005.s006.s007.s008.s009.s010.s011.s012.s013.s014.s015.s016.s017.s018.s019.s020.s021.s022.s023.s024.s025.s026.s027.s028.s029.s030.s031.s032.s033.s034.UnPack.MyLog.txt 18.08.2024 22:59 <DIR> @001 RT под 1801ВМ3.dsk 18.08.2024 22:59 185 c.cmd 18.08.2024 22:59 0 log.txt >dir "@001 RT под 1801ВМ3.dsk" Directory ...\@001 RT под 1801ВМ3.dsk 18.08.2024 22:59 33 554 432 $S000$.$section$ 18.08.2024 22:59 33 554 432 $S001$.$section$ 18.08.2024 22:59 33 554 432 $S002$.$section$ 18.08.2024 22:59 33 554 432 $S003$.$section$ 18.08.2024 22:59 33 554 432 $S004$.$section$ 18.08.2024 22:59 33 554 432 $S005$.$section$ 18.08.2024 22:59 33 554 432 $S006$.$section$ 18.08.2024 22:59 33 554 432 $S007$.$section$ 18.08.2024 22:59 33 554 432 $S008$.$section$ 18.08.2024 22:59 33 554 432 $S009$.$section$ 18.08.2024 22:59 33 554 432 $S010$.$section$ 18.08.2024 22:59 33 554 432 $S011$.$section$ 18.08.2024 22:59 33 554 432 $S012$.$section$ 18.08.2024 22:59 33 554 432 $S013$.$section$ 18.08.2024 22:59 33 554 432 $S014$.$section$ 18.08.2024 22:59 33 554 432 $S015$.$section$ 18.08.2024 22:59 33 554 432 $S016$.$section$ 18.08.2024 22:59 33 554 432 $S017$.$section$ 18.08.2024 22:59 33 554 432 $S018$.$section$ 18.08.2024 22:59 33 554 432 $S019$.$section$ 18.08.2024 22:59 33 554 432 $S020$.$section$ 18.08.2024 22:59 33 554 432 $S021$.$section$ 18.08.2024 22:59 33 554 432 $S022$.$section$ 18.08.2024 22:59 33 554 432 $S023$.$section$ 18.08.2024 22:59 33 554 432 $S024$.$section$ 18.08.2024 23:00 33 554 432 $S025$.$section$ 18.08.2024 23:00 33 554 432 $S026$.$section$ 18.08.2024 23:00 33 554 432 $S027$.$section$ 18.08.2024 23:00 33 554 432 $S028$.$section$ 18.08.2024 23:00 33 554 432 $S029$.$section$ 18.08.2024 23:00 33 554 432 $S030$.$section$ 18.08.2024 23:00 33 554 432 $S031$.$section$ 18.08.2024 23:00 1 073 741 824 $S032$.$section$ 18.08.2024 23:00 1 073 741 824 $S033$.$section$ 18.08.2024 23:00 796 581 888 $S034$.$section$

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

Оказалось даже проще, чем думал. Новый вариант:

Код:

>dir Directory of ... 22.04.2020 22:33 4 017 807 360 001 RT под 1801ВМ3.dsk 19.08.2024 00:54 202 c.cmd 19.08.2024 00:54 0 log.txt >type c.cmd dir type c.cmd ImageUtilsX -unpack "001 RT под 1801ВМ3.dsk" @"001 RT под 1801ВМ3.dsk" s[cf12]:..4[rt11]:64[rsx]:65[] dir dir "@001 RT под 1801ВМ3.dsk" >ImageUtilsX -unpack "001 RT под 1801ВМ3.dsk" @"001 RT под 1801ВМ3.dsk" s[cf12]:..4[rt11]:64[rsx]:65[] >dir Directory of ... 19.08.2024 00:55 6 628 !Log.txt 22.04.2020 22:33 4 017 807 360 001 RT под 1801ВМ3.dsk 19.08.2024 00:55 607 982 001 RT под 1801ВМ3.dsk.cf12.s000..s004.s064.s065.UnPack.MyLog.txt 19.08.2024 00:55 <DIR> @001 RT под 1801ВМ3.dsk 19.08.2024 00:54 202 c.cmd 19.08.2024 00:54 0 log.txt >dir "@001 RT под 1801ВМ3.dsk" Directory of ...\@001 RT под 1801ВМ3.dsk 19.08.2024 00:54 <DIR> $S000$ 19.08.2024 00:55 <DIR> $S001$ 19.08.2024 00:55 <DIR> $S002$ 19.08.2024 00:55 <DIR> $S003$ 19.08.2024 00:55 <DIR> $S004$ 19.08.2024 00:55 <DIR> $S064$ 19.08.2024 00:55 796 581 888 $S065$.$section$

Дальше, как обычно - добавка тестов и комплекс тестов :)

Немного поигрался с доработками. Из замеченного

- пофиксил ошибку парсинга ФС rsx - в определённом сценарии неверной ФС программа слетает по исключению.

- ошибка парсинга ФС считалась фатальной - то есть программа сразу завершала работу. Счёл поведение неправильным, теперь программа прерывает только текущую операцию, то есть, если идёт работа @-файла - переходим на следующую операцию

- вариант указания секций all теперь работает как диапазон с первой по последнюю секцию - а то был прецедент генерации слишком длинного имени файла

Игры продолжаются

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

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

А пока - тесты.

Затем - аналог секций для лент - с прицелом в первую очередь на ленты BRU

В процесс подсовывания парсеру (теперь RT-11) разного налетел на чем-то похожую на ошибку парсера ФС rsx - в парсере ФС rt. Пофиксил - теперь тоже не падает. В целом - интересное развлечение - подсунуть парсеру ФС образ, который не то что с ошибками в ФС - а вообще с левым содержимым. По хорошему - программа не должна падать. Ругацца, материцца - но не падать :)

По тестам вроде ничего не сломалось (что сломалось - починил ранее), так что очередная версия была отправлена в "промышленную" эксплуатацию :) А разработка вернулась к тому, с чего всё началось - к лентам BRU - начинаю второй заход проб :)

Для дисков первоначальный вариант работы с секциями работал на уровне чтения отдельных секций - в том числе в плане борьбы с очень большими файлами.

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

Пришлось переделать подход. Из сделанного

- Поддержка очень больших (больше 2 гигов) массивов. Теперь могу прочитать целиком в память и файлы размером больше 2 гигов :) .
- Секции в образах дисков теперь не читаются - их объекты мапятся на "сырые", прочитанные из файла, данные и таким образом происходит работа.

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

В планах сделать другой вариант реализации сверхбольших массивов - с подкачкой и (при изменении) записью в/из исходного файла. Но не в ближайших планах.

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

Из занимательного.

Есть образ с ФС RSX на примерно полтора гига. Как оказалось, при его распаковке в виртуалке съедается почти вся память. При этом ImageUtils раздувался до почти 20 гигов =) Надо будет парсинг ODS-1 шерстить - что-то как-то многовато получается памяти в использовании :)

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

"Out of memory" - класс! Не шмагла :) Где-то утечка памяти :)

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

Неее. Это ошибка. С утра буду разбираться - где накосячил

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

Не вытерпел, поковырялся :) Да, это была ошибка. Поправил. Теперь в районе 4.5 гигов потребляет при развертывании этого образа. То есть накладные расходын 4.5-1.7 - 2.8 гига. Многовато (но не 20 гигов), но в принципе понятно - почему так.

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

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

- Если у нас есть носитель с программными интерливом и разбиением на секции (ака разделы), то - интерлив должен быть в пределах всего носителя или в каждой секции свой? :)

После раздумий решил, что оба подхода могут иметь место быть, а значит - надо указывать в описании носителя - если используется интерлив, то - какой :)

Пока секционипрование исключает интерлив. Буду выставлять проверку (не случился ли интерлив с секционированием) и если вдруг - ронять программу. Ибо в текущих описаниях устройств такого нет, а если вдруг случится - то это МОЯ ошибка

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

По результатам - надо проверять секционирование - слетели почти все тесты на эту тему.

Завтра по мере свободного времени :)

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

Начал потихоньку (времени свободного на неделе мало) парсить ленты, пока в формате BRU.

Этап первый - выделение отдельных backup-ов (ака секций).

Попутно выяснилось, что в рядах образах, в которых секции выделяются на основе данных - пополнение -с екции в ФС Windows. Как-то до начала секционирования лент не задмывался над этим. И тестов на сборку не добавил, так что и с этой стороны подсказки не было. Не страшно - и подход выделения секций похожий и вопрос дальше похоже решать. Так что - попутно сделаю.

Устал от программирования. Когда вернусь - не знаю :) Может - временами и понемногу, но.. не знаю.. :)

за что возьметесь ?
А то, что-то тема (кроме этой ветки) совсем заглохла. У многих есть рабочие PDP, Электроники, ДВК, но - тишина. Кто что на них делает ? Зачем заимели ?

Цитата:

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

Кто что на них делает ? Зачем заимели ?

Хобби. Приятные и простые машинки времен молодости!!!
Я, например, до сих пор "балдею" с MACRO (хотя с тех пор были освоены Fortran77(и далее), C, C++, Java, Perl).

Цитата:

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

У многих есть рабочие PDP, Электроники, ДВК

Увы, серия FPGA машинок от forth32 c процессорами от Vslav.
FPGA конечно "рулит" и "наше все", но мощно бесит - никакой стабильности :)))

Цитата:

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

за что возьметесь ?

Программирования сейчас на работе хватает, поэтому на неделе вообще тяжело опять в программирование погружаться.
А на выходных - назревает немного калыма, но там некоторые вещи прояснить надо - занимается свободное время.
Попробую повозиться с PDP-11X, всё таки не программирование

Цитата:

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

Кто что на них делает ? Зачем заимели ?

Играются в игрушки

Цитата:

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

У многих есть рабочие PDP, Электроники, ДВК, но - тишина. Кто что на них делает ? Зачем заимели ?

Я на МС1212 колбасу и сало на закусь режу. Удобно мне так...

Захотелось мне тут ... странного :)
Два вечера, часа четыре в сумме.
Результат:

Код:

>ImageUtilsX -unpack DECMATION_100Q_DISK2.rx02_sd @DecMATION_100Q_DISK2.rx02_sd cpm8 cpm >type DECMATION_100Q_DISK2.rx02_sd.UnPack.MyLog.txt # # -unpack "DECMATION_100Q_DISK2.rx02_sd" @DecMATION_100Q_DISK2.rx02_sd" cpm8 cpm # MOVCPM .COM 76 PIP .COM 58 SUBMIT .COM 10 XSUB .COM 6 ED .COM 52 ASM .COM 64 DDT .COM 38 LOAD .COM 14 STAT .COM 41 REC .COM 5 DUMP .COM 4 SEN .COM 4 TYPICAL .ASM 73 WP .COM 64 WPEDPRNT.WPO 30 WPEDFORM.WPO 46 WPEDINIT.WPO 37 GENSYS .COM 6 WPEDDOCM.WPO 29 WPEDTYPE.WPO 7 XDIR .COM 16 WPEDHELP.WPO 15 WPEDCOPY.WPO 31 WPEDPAGE.WPO 17 WPEDSVRD.WPO 23 WPEDFILE.WPO 26 WPEDFI .WPO 3 WPEDFD .WPO 9 WPEDFCD .WPO 15 WPEDIT2 .WPO 114 WPEFL .WPO 20 WPEDIT .WPO 72 WPEDFIND.WPO 56 WPEDPRN2.WPO 154 HELP .WPH 184 VT100AV .ASM 120 PRINTER .SUB 2 TERMINAL.SUB 2 STD10 .ASM 35 INITFL .COM 5 DAISYIIF.ASM 41 BIOS64 .ASM 62 BIOS64 .ASM 62 42 files, 0 blocks 0 Free blocks >dir @DecMATION_100Q_DISK2.rx02_sd Directory of ..... @DecMATION_100Q_DISK2.rx02_sd 17.09.2024 20:39 <DIR> @metaFiles@ 17.09.2024 20:39 8 192 ASM.COM 17.09.2024 20:39 7 936 BIOS64.ASM 17.09.2024 20:39 5 248 DAISYIIF.ASM 17.09.2024 20:39 4 864 DDT.COM 17.09.2024 20:39 512 DUMP.COM 17.09.2024 20:39 6 656 ED.COM 17.09.2024 20:39 768 GENSYS.COM 17.09.2024 20:39 23 552 HELP.WPH 17.09.2024 20:39 640 INITFL.COM 17.09.2024 20:39 1 792 LOAD.COM 17.09.2024 20:39 9 728 MOVCPM.COM 17.09.2024 20:39 7 424 PIP.COM 17.09.2024 20:39 256 PRINTER.SUB 17.09.2024 20:39 640 REC.COM 17.09.2024 20:39 512 SEN.COM 17.09.2024 20:39 5 248 STAT.COM 17.09.2024 20:39 4 480 STD10.ASM 17.09.2024 20:39 1 280 SUBMIT.COM 17.09.2024 20:39 256 TERMINAL.SUB 17.09.2024 20:39 9 344 TYPICAL.ASM 17.09.2024 20:39 15 360 VT100AV.ASM 17.09.2024 20:39 8 192 WP.COM 17.09.2024 20:39 3 968 WPEDCOPY.WPO 17.09.2024 20:39 3 712 WPEDDOCM.WPO 17.09.2024 20:39 1 920 WPEDFCD.WPO 17.09.2024 20:39 1 152 WPEDFD.WPO 17.09.2024 20:39 384 WPEDFI.WPO 17.09.2024 20:39 3 328 WPEDFILE.WPO 17.09.2024 20:39 7 168 WPEDFIND.WPO 17.09.2024 20:39 5 888 WPEDFORM.WPO 17.09.2024 20:39 1 920 WPEDHELP.WPO 17.09.2024 20:39 4 736 WPEDINIT.WPO 17.09.2024 20:39 9 216 WPEDIT.WPO 17.09.2024 20:39 14 592 WPEDIT2.WPO 17.09.2024 20:39 2 176 WPEDPAGE.WPO 17.09.2024 20:39 19 712 WPEDPRN2.WPO 17.09.2024 20:39 3 840 WPEDPRNT.WPO 17.09.2024 20:39 2 944 WPEDSVRD.WPO 17.09.2024 20:39 896 WPEDTYPE.WPO 17.09.2024 20:39 2 560 WPEFL.WPO 17.09.2024 20:39 2 048 XDIR.COM 17.09.2024 20:39 768 XSUB.COM 42 File(s) 215 808 bytes >ImageUtilsX -unpack DECMATION_100Q_DISK3.rx02_sd @DecMATION_100Q_DISK3.rx02_sd cpm8 cpm >type DECMATION_100Q_DISK3.rx02_sd.UnPack.MyLog.txt # # -unpack "DECMATION_100Q_DISK3.rx02_sd" @DecMATION_100Q_DISK3.rx02_sd" cpm8 cpm # TERLIB .HET 243 DIABLO .HEX 5 DIABLO50.HEX 6 EPSON .HEX 6 ANADEX .HEX 7 README2 .TXT 5 EPSON-G .HEX 6 IDS560 .HEX 6 IDSPRISM.HEX 10 MALIBU .HEX 6 NEC7710 .HEX 6 NEC7710S.HEX 8 NEC7710T.HEX 8 NEC7715 .HEX 6 NEC7715S.HEX 8 NEC7715T.HEX 8 OKI-83A .HEX 6 PRISM-CQ.HEX 7 PRISM-DQ.HEX 7 PRO-WTR .HEX 9 PSPC8023.HEX 10 QUME5 .HEX 6 SELLUMI .HEX 5 SPINWTR .HEX 5 STARWTR .HEX 5 XYMEC .HEX 6 ACT5A .HEX 6 DAISYIIF.ASM 41 BOLDPS .ASM 36 TYPICAL .HEX 5 PRPATCH .HEX 1 VT100AV .ASM 120 VT100NAV.ASM 120 README1 .TXT 5 DAISY-II.ASM 141 BOLDPSX .ASM 36 DIAB630 .ASM 88 BOLDPS96.ASM 46 CUBPS96 .ASM 41 EMPEROR .ASM 36 EMPERORX.ASM 36 MODERN .ASM 37 PRO-WTRF.ASM 34 STD10 .ASM 35 THEME11 .ASM 36 THEME11 .ASM 36 45 files, 0 blocks 0 Free blocks >dir @DecMATION_100Q_DISK3.rx02_sd Directory of ..... @DecMATION_100Q_DISK3.rx02_sd 17.09.2024 20:39 <DIR> @metaFiles@ 17.09.2024 20:39 768 ACT5A.HEX 17.09.2024 20:39 896 ANADEX.HEX 17.09.2024 20:39 4 608 BOLDPS.ASM 17.09.2024 20:39 5 888 BOLDPS96.ASM 17.09.2024 20:39 4 608 BOLDPSX.ASM 17.09.2024 20:39 5 248 CUBPS96.ASM 17.09.2024 20:39 18 048 DAISY-II.ASM 17.09.2024 20:39 5 248 DAISYIIF.ASM 17.09.2024 20:39 11 264 DIAB630.ASM 17.09.2024 20:39 640 DIABLO.HEX 17.09.2024 20:39 768 DIABLO50.HEX 17.09.2024 20:39 4 608 EMPEROR.ASM 17.09.2024 20:39 4 608 EMPERORX.ASM 17.09.2024 20:39 768 EPSON-G.HEX 17.09.2024 20:39 768 EPSON.HEX 17.09.2024 20:39 768 IDS560.HEX 17.09.2024 20:39 1 280 IDSPRISM.HEX 17.09.2024 20:39 768 MALIBU.HEX 17.09.2024 20:39 4 736 MODERN.ASM 17.09.2024 20:39 768 NEC7710.HEX 17.09.2024 20:39 1 024 NEC7710S.HEX 17.09.2024 20:39 1 024 NEC7710T.HEX 17.09.2024 20:39 768 NEC7715.HEX 17.09.2024 20:39 1 024 NEC7715S.HEX 17.09.2024 20:39 1 024 NEC7715T.HEX 17.09.2024 20:39 768 OKI-83A.HEX 17.09.2024 20:39 896 PRISM-CQ.HEX 17.09.2024 20:39 896 PRISM-DQ.HEX 17.09.2024 20:39 1 152 PRO-WTR.HEX 17.09.2024 20:39 4 352 PRO-WTRF.ASM 17.09.2024 20:39 128 PRPATCH.HEX 17.09.2024 20:39 1 280 PSPC8023.HEX 17.09.2024 20:39 768 QUME5.HEX 17.09.2024 20:39 640 README1.TXT 17.09.2024 20:39 640 README2.TXT 17.09.2024 20:39 640 SELLUMI.HEX 17.09.2024 20:39 640 SPINWTR.HEX 17.09.2024 20:39 640 STARWTR.HEX 17.09.2024 20:39 4 480 STD10.ASM 17.09.2024 20:39 31 104 TERLIB.HET 17.09.2024 20:39 4 608 THEME11.ASM 17.09.2024 20:39 640 TYPICAL.HEX 17.09.2024 20:39 15 360 VT100AV.ASM 17.09.2024 20:39 15 360 VT100NAV.ASM 17.09.2024 20:39 768 XYMEC.HEX 45 File(s) 167 680 bytes

Это ОЧЕНЬ ранний альфа вариант :)

Работа с образом 8-ми дюймовки с ФС CP/M выявило некоторую проблему - у неё свой вариант логического (не аппаратного) интерлива. Пока описать несколько вариантов интерлива для одного физического типа устройства ImageUtils не позволяет - только за счёт описания нескольких вариантов устройств. Подумаю над этим, а то устройства слишком плодятся :)

Я тут в понедельник всё таки заболел (вирусняк), конкретно - до больничного. Обычно не беру - на удалённой работе. А тут вот - вот так...

Ну и к сегодняшнему дню самочувстивие стало чуть-чуть лучше, так что - воспользовался и дописал парсер предпоследней из известных мне файловых систем на PDP-11.

Пока нет парсера на RSTS.

Ну а unix системы мне никогда не нравились - не думаю, что буду делать парсер :)

Итак, встречаем - CAPS-11:

Код:

>dir Directory of ... 26.04.2014 08:56 91 376 bascaps1.t60 02.10.2024 16:53 0 log.txt 02.10.2024 16:53 171 unp.cmd >ImageUtilsX -unpack bascaps1.t60 @bascaps1.t60 tu60 caps11 >dir Directory of ... 02.10.2024 16:53 1 070 !Log.txt 02.10.2024 16:53 <DIR> @bascaps1.t60 26.04.2014 08:56 91 376 bascaps1.t60 02.10.2024 16:53 988 bascaps1.t60.UnPack.MyLog.txt 02.10.2024 16:53 0 log.txt 02.10.2024 16:53 171 unp.cmd >dir @bascaps1.t60 Directory of ...\@bascaps1.t60 02.10.2024 16:53 <DIR> @metaFiles@ 09.05.1974 23:00 16 384 BAS8K.SLO 08.05.1974 23:00 4 096 BASED.OVL 08.05.1974 23:00 4 096 BASEX.OVL 11.05.1974 23:00 24 576 BASIC.SLO 08.05.1974 23:00 1 024 CTLOAD.SYS 09.08.1974 23:00 4 096 FPMPEA.OBJ 09.08.1974 23:00 3 584 FPMPEI.OBJ 09.08.1974 23:00 1 536 FPMPFP.OBJ 17.05.1974 23:00 24 576 FTBLA.OBJ 17.05.1974 23:00 1 024 PROG2.BAS 17.05.1974 23:00 512 PROG2.OBJ >type bascaps1.t60.UnPack.MyLog.txt # # -unpack "bascaps1.t60" "@bascaps1.t60" tu60 caps11 # Filesystem has 0 ufds, 11 files and 692 blocks CTLOAD.SYS 8 09-MAY-1974 BASED .OVL 32 09-MAY-1974 BASEX .OVL 32 09-MAY-1974 BAS8K .SLO 128 10-MAY-1974 BASIC .SLO 192 12-MAY-1974 FTBLA .OBJ 192 18-MAY-1974 PROG2 .OBJ 4 18-MAY-1974 PROG2 .BAS 8 18-MAY-1974 FPMPEA.OBJ 32 10-AUG-1974 FPMPEI.OBJ 28 10-AUG-1974 FPMPFP.OBJ 12 10-AUG-1974 TOTL BLKS: 668 TOTL FILES: 11

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

В силу простоты ФС, думаю набросать и обратный процесс - создание ФС CAPS-11, но посмотрим...

В процессе написания процедур создания образа CAPS-11 выявлена ошибка, недописанный код (ну тут понятно - на момент написания для проверки ничего подходящего не было, так что оставил ловушку) и не совсем правильная реализация восстановления порядка файлов при СОЗДАНИИ образов (это из постепенной реализации возможности воссоздать полностью идентичный образ на основании файлов и метоинформации от процесса распаковки образа).

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

В планах - доделать создание полностью идентичных образов CAPS-11 и ещё продвинуться в сохранении метаинформации - в том числе, с учётом информации и знаний из первой задачи

Вроде CAPS-11 - не сильно сложная ФС, но процесс создания образа потребовал доработок внутренностей, так как примерно как и у ODS-1 - есть заголовок файла, не всю информацию из которого можно сохранить в файле Windows. По сути, в Windows можно сохранить только дату-время создания (ну и изменения, который есть в ODS-1). Собственно - сохранение информации из заголовка сделать было просто (на ODS-1 механизм был более менее отработан), а вот использование её при создании ФС - такого механизма не было.

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

Пока ещё в проверке-отладке, но уже более менее работает - ленты CAPS-11 воссоздаются идентичные оригинальным :)

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