Вытягиваема, и уж точно не выкидывать.Цитата:
Сообщение от dk_spb
В дампе читается "МОСРВМ [001,001] DECFILE11A"
Можно попробовать разложить полный дамп в программе ods1reader .
- - - Добавлено - - -
ODS1 FILES-11 DECFILES11A reader
Вид для печати
Вытягиваема, и уж точно не выкидывать.Цитата:
Сообщение от dk_spb
В дампе читается "МОСРВМ [001,001] DECFILE11A"
Можно попробовать разложить полный дамп в программе ods1reader .
- - - Добавлено - - -
ODS1 FILES-11 DECFILES11A reader
Банальные шаги типа ods1reader и плагина Patron'а я попробовал уже....
ods1reader если не вываливается, то говорит что ничего типа ods-1 в предложенном файле не нашел.
putr видит заголовок тома, но говорит что ошибка чтения directory
--
Добавил в начало пустой (0x00) сектор. Переименовал в .rd
Теперь ods1reader стабильно вываливается.
А откуда у него 18 секторов? В мануале обозначено 17.Цитата:
Сообщение от dk_spb
На чём читается?Цитата:
Сообщение от dk_spb
>А откуда у него 18 секторов?
Видимо создатели СМ1425 этого мануала не читали. Секторов и правда до 17-го, но с учетом нулевого получается 18. И вообще я нулевой сектор как-то первый раз вижу....
>На чём читается?
На самодельной универсальной MFM читалке.
- - - Добавлено - - -
Может какой-нибудь эмулятор посоветуете, которым можно открыть этот образ.
Собственно интересует больше всего наличие на диске тестов железа.
SIMH возможно?Цитата:
Сообщение от dk_spb
https://ru.wikipedia.org/wiki/SIMH
http://simh.trailing-edge.com/
У Patron'а есть плагин под FILES-11? Интересно где он.Цитата:
Сообщение от dk_spb
Раз putr видит, значит anasanе есть на чем поработать. На мой взгляд ods1reader пока что может только идеальные (не битые) образы раскладывать, и то специфичные к Э-85.Цитата:
Сообщение от dk_spb
Вообще сектора софтово делают, можно хоть 1, хоть 10, хоть 25. А 17 вроде как оптимальный вариант для МФМ т.к. нужно ещё пространство для межсекторных маркеров, КС и прочего. Секторов 17 это количество секторов всего или 18 с учетом нулевого, скорее 18 т.к. у Вас 7 головок прочиталось нормально.Цитата:
Сообщение от dk_spb
Фото можно? Как 2й ST-4096 читается? На втором как правило отсутствует терминатор, надо бы переставить.Цитата:
Сообщение от dk_spb
Пока putr не возьмёт, эмулятор бесполезно. Ну если хочется, можно под Е11 где подключать на контроллер RQDX.Цитата:
Сообщение от dk_spb
Данные очень похожи на живые, дайте, plz, образ куском побольше для обзора, там, якобы:
- Maximum number of files, h_fmax: 8529
- Index file header begin LBN block, ifhbn: 82137
это сильно большой винт? ну, во всяком случае точно не дискета, расположение самого "вкусного" (файловая структура) полюбому сдвинуто куда-то вглубь дампа.
Если я правильно понял про винт, то это у него примерно ~165888 (1024 * 9 * 18) доступных блоков диска.
в хексе область с описанием файлов/каталогов выглядит как-то вот так: https://yadi.sk/i/ILe8MbExxu5on
если начало её расположения опознать, то можно будет уверенно "подрихтовать" размер образа на предмет реального числа секторов на дорожке и выровнять сам образ в корректный вид
а ридер падает, потому что какая-то величина из "опорных" значений за диапазон выделеной памяти вылазит, я такое в отладчике сразу увижу.
Кусок побольше снять пока не получилось, пока только первые почти три метра из 80. Ждем следующих выходных. Винт сейчас представляет достаточно мерзкий вариант ручного пуска: сам не справляется вытащить головку с автопаркинга. Иногда работает несколько раз нормально, а иногда - каждый раз вскрывать и расщелкивать. Плата такого же винта на пробу будет не раньше чем через две-три недели, так что пока не понятно лечится ли проблема малой кровью.
>расположение самого "вкусного" (файловая структура) полюбому сдвинуто куда-то вглубь дампа.
А разве где-нибудь в начале диске нет данных о месте расположения "самого вкусного"?
>реального числа секторов на дорожке
Секторов реально 18 (0-17), я же их целые (по CRC) заголовки вижу. И головок 9. Тоже заголовки видны.
>- Index file header begin LBN block, ifhbn: 82137
Если это в 512-байтных блоках от начала диска, то это похоже на 507 цилиндр - середину диска
Ещё на 512 умножить.Цитата:
Сообщение от anasana
Кстати не факт что винчь отформатирован именно по такой геометрии. Может тот кто форматировал, не вдаваясь в подробности отформатировал геометрией другого винча (например предложенной по дефолту). Вот и не читаются две головы.
>Ещё на 512 умножить.
Зачем????? Чтобы вместо блоков получить байты?
>Кстати не факт что винчь отформатирован именно по такой геометрии. Может тот кто форматировал, не вдаваясь в подробности отформатировал геометрией другого винча
Что-то мне подсказывает что для этого винта это невозможно.
Да и зачем искать кошу в тёмной комнате. Ведь заголовки секторов прочитаны - кошки в этой комнате стопудово нет.
Да это я по инерции...Цитата:
Сообщение от dk_spb
Вод ведь какое дело. В мануале неформатированная ёмкость 96.0Мб, форматированная 80.2. Т.е. 15,8Мб на служебную информацию.
Нехило как-то.
Дальше
512*1024 * 9 * 18= 84 934 656
512*1024 * 9 * 17= 80 216 064
получается.
Что конкретно?Цитата:
Сообщение от dk_spb
- - - Добавлено - - -
В стартапе по 12 вольтам он потребляет 4А, и это не считая ещё по 5 вольтам.Цитата:
Сообщение от dk_spb
У меня такая есть на пробу.Цитата:
Сообщение от dk_spb
подцепил этот образ к simh, пытается грузиться и обваливается -- не хватает данных (LBN 1C54 = смещение 3713024):
Код:sim> bo rq0
DBG(7)> RQ REQ: initialization started
DBG(462)> RQ INIT: CSTA=0, SAW=0x8000
DBG(917)> RQ INIT: CSTA=2, SAW=0xE84
DBG(1372)> RQ INIT: CSTA=3, SAW=0x0
DBG(1387)> RQ INIT: CSTA=6, SAW=0x1
DBG(1387)> RQ REQ: initialization complete
DBG(1590)> RQ REQ: poll started, PC=1C58
DBG(1790)> RQ REQ: cmd=0009(ONL), mod=0000, unit=0, bc=00000000, ma=00000000, lbn=00000000
DBG(1790)> RQ REQ: rsp=0089, sts=0000
DBG(2005)> RQ REQ: poll started, PC=1C58
DBG(2205)> RQ REQ: cmd=0021( RD), mod=0000, unit=0, bc=00000200, ma=00000000, lbn=00000000
DBG(3067)> RQ REQ: RQ0 sim_disk_rdsect lbn: 00000000 len: 00000200
DBG(3067)> RQ REQ: 0000 B0 00 04 01 00 00 54 1C 10 5B 21 73 00 01 DF 95 ......T..[!s....
<...>
DBG(3067)> RQ REQ: 01F0 07 0A 07 0A 07 0A 07 0A 07 0A 07 0A 07 0A 07 0A ................
DBG(3067)> RQ REQ: rsp=00A1, sts=0000
DBG(3074)> RQ REQ: initialization started
DBG(3617)> RQ REQ: initialization started
DBG(4075)> RQ INIT: CSTA=0, SAW=0x8000
DBG(4530)> RQ INIT: CSTA=2, SAW=0x458
DBG(4985)> RQ INIT: CSTA=3, SAW=0x0
DBG(5000)> RQ INIT: CSTA=6, SAW=0x1
DBG(5000)> RQ REQ: initialization complete
DBG(6677)> RQ REQ: poll started, PC=7C4
DBG(6877)> RQ REQ: cmd=0009(ONL), mod=0000, unit=0, bc=00000000, ma=00000000, lbn=00000000
DBG(6877)> RQ REQ: rsp=0089, sts=0000
DBG(8630)> RQ REQ: poll started, PC=7C4
DBG(8830)> RQ REQ: cmd=0021( RD), mod=0000, unit=0, bc=00000600, ma=00000000, lbn=00001C54
DBG(9330)> RQ REQ: RQ0 sim_disk_rdsect lbn: 00001C54 len: 00000600
DBG(9330)> RQ REQ: 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
DBG(9330)> RQ REQ: 0010 thru 05FF same as above
DBG(9330)> RQ REQ: rsp=00A1, sts=0000
DBG(9361)> RQ REQ: initialization started
shattered, А не дадите краткую инструкцию по simh для подцепления этого образа?
MiX,
>Что конкретно?
Как Вы представляете себе форматирование диска с интерфейсом ST-506 в другой геометрии?
>У меня такая есть на пробу.
Сможете дать на выходные?
конфиг simh:
отладка включаетсяКод:; неточно
set cpu 11/34
set clk 50hz
; смена SIMH console escape на ^]
set console wru=035
; чтобы не обрезались esc sequences
set tti 7b
set tto 7b
set -L rq0 rauser=165888
att rq0 dddiii.bin
загрузка -- boot rq0Код:set debug stdout
set rq debug
По идее практически в начале (в HOMEB) имеется только ссылка (а точнее поле: Index file header begin LBN block, ifhbn), что оно, здесь заявлено, будет начинаться с блока 82137.Цитата:
А ... где-нибудь в начале диске нет данных о месте расположения "самого вкусного"?
(старт:
512 * 0 = DISKBOOTBLOCK (BOOTB | bootstrap code)
512 * 1 = HOMEBLOCK (HOMEB | hblock) // Home block is normally the next block after the boot block, but failing that try search multiples of 256.
512 * 2.. = INDEXFILEBITMAP IMAPB // Bitmap of file headers in use to control the allocation of file numbers (and hence file headers), обычно занимает несколько секторов
... блоки данных - файлы "в кусках") и по идее
512 * 82137...n = где уже и ожидается indexf.sys - само ссылочное хранилище ФС (занимаемое им число секторов в дампе зависит от количества файлов в томе)
... следом обычно будет расположена корневая директория (000000.dir) и дальше блоки данных...
и всё оно так буйно переплетено..
В самом начале образа видна (сейчас для нас скучная) область IMAPB со списоком активных/живых/неудаленных "номеров файлов" (filenum), но вся сама детальная расшифровка лежит начиная с ifhbn.
"Список файлов в директориях" лежит в секторах с данными как и обычные файлы, но в них внутри нету ни своего имени ни своей "родительской" привязки, только дальнейшее дерево.
Вот парочку встретившихся секторов, после декодировки имен файлов из RAD50:
Скрытый текст
chunk LBN: 3
Filename: alex .cmd;1, #filenum: 457 lifetime seq: 5
Filename: akt .doc;1, #filenum: 459 lifetime seq: 3
Filename: ozom .cmd;1, #filenum: 462 lifetime seq: 3
Filename: chpm .cmd;1, #filenum: 465 lifetime seq: 3
Filename: pkl .cmd;1, #filenum: 471 lifetime seq: 8
Filename: broker .ust;1, #filenum: 474 lifetime seq: 3
Filename: firma .ust;1, #filenum: 477 lifetime seq: 3
Filename: copy .cmd;12, #filenum: 480 lifetime seq: 4
Filename: kosyrev . ;1, #filenum: 482 lifetime seq: 4
Filename: edt .cmd;4, #filenum: 484 lifetime seq: 3
Filename: nedt .cmd;1, #filenum: 489 lifetime seq: 3
chunk LBN: 10
Filename: dapres .tsk;1, #filenum: 13 lifetime seq: 4
Filename: dapres .stb;1, #filenum: 33 lifetime seq: 2
Filename: fcsfsl .stb;1, #filenum: 50 lifetime seq: 1
Filename: fcsres .stb;1, #filenum: 52 lifetime seq: 1
Filename: fcsfsl .tsk;1, #filenum: 49 lifetime seq: 1
Filename: fcsres .tsk;1, #filenum: 51 lifetime seq: 1
Filename: version .cmd;1, #filenum: 83 lifetime seq: 3
Filename: exemc .mlb;1, #filenum: 106 lifetime seq: 1
Filename: debug .olb;1, #filenum: 107 lifetime seq: 1
Filename: lpa .obj;1, #filenum: 108 lifetime seq: 1
Filename: odt .obj;1, #filenum: 109 lifetime seq: 1
Filename: odtid .obj;1, #filenum: 110 lifetime seq: 1
Filename: exelib .olb;2, #filenum: 111 lifetime seq: 1
Filename: kitident .dat;4, #filenum: 112 lifetime seq: 1
Filename: vmlib .olb;1, #filenum: 113 lifetime seq: 1
Filename: mocpbm .sml;1, #filenum: 114 lifetime seq: 1
Filename: fcs .obj;1, #filenum: 78 lifetime seq: 4
Filename: fcsmbf .obj;1, #filenum: 116 lifetime seq: 1
Filename: fcsnolog .obs;1, #filenum: 117 lifetime seq: 1
Filename: fcslog .obs;1, #filenum: 119 lifetime seq: 1
Filename: fcsmta .obj;1, #filenum: 120 lifetime seq: 1
Filename: fcsfull .obs;1, #filenum: 121 lifetime seq: 1
Filename: noanslib .olb;1, #filenum: 122 lifetime seq: 1
Filename: sudresab .tsk;1, #filenum: 88 lifetime seq: 4
Filename: sudlbl .tsk;1, #filenum: 124 lifetime seq: 1
Filename: sudlbm .tsk;1, #filenum: 125 lifetime seq: 1
Filename: sudres .stb;1, #filenum: 126 lifetime seq: 1
Filename: suddap .olb;1, #filenum: 127 lifetime seq: 1
Filename: sudlib .olb;2, #filenum: 128 lifetime seq: 1
Filename: sudmac .mlb;1, #filenum: 129 lifetime seq: 1
Filename: sudfun .obj;1, #filenum: 130 lifetime seq: 1
Filename: r0sud1 .mac;6, #filenum: 131 lifetime seq: 1
chunk LBN: 11
Filename: sudres .tsk;1, #filenum: 132 lifetime seq: 1
Filename: sudrotab .tsk;1, #filenum: 133 lifetime seq: 1
Filename: sudrotab .stb;1, #filenum: 134 lifetime seq: 1
Filename: sudrotab .map;1, #filenum: 135 lifetime seq: 1
Filename: sud11x .odl;3, #filenum: 115 lifetime seq: 3
Filename: sudrlx .odl;3, #filenum: 137 lifetime seq: 1
Filename: sud11 .odl;3, #filenum: 139 lifetime seq: 1
Filename: sud12x .odl;3, #filenum: 140 lifetime seq: 1
Filename: sud12s .odl;4, #filenum: 141 lifetime seq: 1
Filename: sud11s .odl;4, #filenum: 142 lifetime seq: 1
Filename: daprlx .odl;3, #filenum: 143 lifetime seq: 1
Filename: dap11x .odl;3, #filenum: 144 lifetime seq: 1
Filename: macro .mac;1, #filenum: 148 lifetime seq: 1
Filename: syslib .olb;1, #filenum: 150 lifetime seq: 1
Filename: adalib .olb;1, #filenum: 16 lifetime seq: 6
Filename: ad1lib .olb;1, #filenum: 31 lifetime seq: 33
Filename: f77ots .olb;1, #filenum: 611 lifetime seq: 5
Filename: io77 .olb;1, #filenum: 1217 lifetime seq: 5
Filename: rlclib .olb;1, #filenum: 655 lifetime seq: 1
Filename: vidi .olb;1, #filenum: 656 lifetime seq: 1
Filename: adarsx .olb;1, #filenum: 337 lifetime seq: 9
Filename: itrsx .olb;1, #filenum: 342 lifetime seq: 7
Filename: snab .txt;8, #filenum: 734 lifetime seq: 40
Filename: snab .dat;4, #filenum: 736 lifetime seq: 33
Filename: snab .vie;4, #filenum: 737 lifetime seq: 19
Filename: sbyt .txt;5, #filenum: 739 lifetime seq: 25
Filename: sbyt .dat;2, #filenum: 775 lifetime seq: 102
Filename: sbyt .vie;2, #filenum: 776 lifetime seq: 90[свернуть]
Довольно много переведенного текста кстати в дампе, ещё встречаются корни
///This kit is labelled RSX11MPBL24
///O C P B M distribution kit
///M O C P B M distribution kit. Version 1.0 Base level 24
///This kit is labelled MOCPBMWRK
А-а-а! Хочу! :DЦитата:
Сообщение от anasana
дык :), этот MOCPBM вообще не гуглится толком, там вообще всё интересно! (донор-то ясен, подпихнуть если чего-то будет критически не хватать)
P.S. А я пока помучаю вывод в дополнительный лог, если сектор используется но вдруг не считался (0xEE), что бы там сразу было видно какой именно файл пострадал.
но надеюсь, что обойдётся.
> А я пока помучаю вывод в дополнительный лог, если сектор используется но вдруг не считался (0xEE)
Да я вот как раз в раздумьях про эти 0xee. Просто сейчас если CRC не совпало - я тупо сектор забиваю 0xEE. А там может всего один битик съехал....
У СМ-1425.5144 это именно CRC, не ECC.
Но если это битик, жалко всю остальную информацию терять, забивая её 0xEE. Вот я и в раздумьях как лучше. Два образа делать (один с забитием сбойных секторов 0xEE, чтобы сразу было видно; другой со всем что считалось) или еще как-то извратиться... В принципе есть лог, в котором видно какие сектора с ошибкой по CRC.
Сейчас еще если сектор не нашелся - то же 0xEE. Но это уже придумал как отслеживать и отмечать.
Ну по всему видно, что это обычный M+ V3.0 - в этой версии как раз прошло большинство "современных" модификаций M+ ([обязательное монтирование, векторизация итд], которые частично были добавлены и в P/OS V3.0). Я бы предположил, что ОСРВМ - это был M+ версии 2.1, а МОСРВМ - 3.0, а более поздних версий "советских" скорее всего не было :)Цитата:
Сообщение от anasana
Ах, да, забыл добавить что это я пока только с одной читалкой пробую, где ФАПЧ аппаратный. У меня еще другая есть (не моё поделие), там программно всё, может и вытянет последние две поверхности.
- - - Добавлено - - -
[offtop]кстати, если у кого-нибудь есть отечественные HDD или их фото с логотипами, датами выпуска и т.д. - поделитесь фото.
Особенно интересны пермские HDD серии EC531x. Что-то там совсем мутно с производством HDD на Пензенском заводе ВЭМ. Точно была перемаркировка, а вот были ли свои..... [/offtop]
это которая им. т. D. Gesswein?Цитата:
Сообщение от dk_spb
>им. т. D. Gesswein
угу
Вот такая тулза, по замыслу должна вытаскивать файлы с образа ODS-1/Files-11. Пока многого не умеет, но буду благодарен за отзывы.
Ну и по мере считывания образа можно приложенной программой контролировать успешность/целостность файловой структуры (могу и лог считывалки прикрутить, чтобы битые файлы сразу отмечать, я так в подобной программе для RT-11 делал).
Вложение 58709
eugeneak, Не удалось заставить Вашу утилиту работат в режиме листига: начинает вываливать файлы на диск
Главное - правильно перекодировать ascii/binary при доставании (и перекодировать обратно если в дальнейшем предполагается запись в образ) на подобии как это делает FLX при передаче в/из RT-11.
Пока лучше всего получилось у DOS'овской утилиты...
Вложение 58713
Вторая читалка тоже не справилась нормально прочитать последние две головки. Похоже там механика (уж очень в одном месте сбои).
В двух местах обещали чуть позже дать плату HDD на проверку, может полегчает.
Лог чтения в аттаче (4-нашли корректый заголовок, но сбой CRC данных, 5-не нашли корректный заголовок)
Вложение 58714
Вытянутый утилитой eugeneak файл vidi.olb попадает на битые сектора. Я могу попробовать считать его в ручной режиме, если содержание похоже на правду (битые сектора целиком заполнены 0xEE). В файле почему-то начала кусков 0xEE не кратны 512 байтам...Вложение 58715
Смещение это моя вина, спасибо за отчёт, детскую ошибку (!) уже исправил. Теперь значительно больше файлов находит.Цитата:
Сообщение от dk_spb
исправленная версия: Вложение 58718
Логи считывалки за выходные прикручу.
- - - Добавлено - - -
До этого пока не добрался (как и до типов, даты/времени, атрибутов и точных размеров файла). Но это будет.Цитата:
Сообщение от form
А перекодировку, КМК, это уже чем-то отдельным лучше делать. Или это обязательно ? Надо ещё узнать мне - чего и как перекодировать :)
- - - Добавлено - - -
А она тогда ещё и не умела так. Теперь умеет.Цитата:
Сообщение от dk_spb
Отдельным не получится. Нужна перекодировка формата из FILES-11 в чистые данные. Примерно так: к бинарным файлам (OBJ, STB) нужно добавлять в начало прочитанного (каждой записи) длину, в конце конце контрольную сумму, для текстовых в конце каждой строки нужно добавлять <CR><LF>, и уже в таком виде писать в исходящий файл. Подробнее можно почитать в описании утилиты FLX (из RSX-11). В противном случае прочитанные файлы данных форматов окажутся бесполезными ибо дальше с ними нечего будет делать.Цитата:
Сообщение от eugeneak
- - - Добавлено - - -
А где сам образ? Чтобы не перечитывать все вверх :)Цитата:
Сообщение от dk_spb
Прочитаю родными средствами...
- - - Добавлено - - -
Ну тут все просто достаточно - там все это в виде ASCII текста пишется. Насчет Y2K только есть особенности - под год выделено 2 символа. Подробности разборок с Y2K кажется в описании Ersatz-11 есть.Цитата:
Сообщение от eugeneak
- - - Добавлено - - -
Насчет файлов можно два режима предусмотреть. Поиск файлов по каталогам и прямое вычитывание индексного файла. Второй способ позволяет именно найти потерянные файлы (хотя и редко когда нужно).Цитата:
Сообщение от eugeneak
Я, честно говоря, просто ориентировался на описание файловой системы от Dec, там сказано что FCS к собственно файловой системе не относится будучи user-пакетом. Но теперь, после подсказки, пересмотрев ещё раз описание, понимаю что файлы нужно сохранять вместе с блоком FCS атрибутов. Предлагаю, как один из вариантов, ничего не конвертировать, но сохранять отдельно атрибуты файла в текстовом виде в специальном файле (т.е. например DATABASE.OBJ => database.obj и database.obj.ods1), типа как на маке. Конвертор можно сделать внешним.Цитата:
Сообщение от form
RSX я пока ещё в глаза не видел, если есть описание FLX под рукой буду благодарен за него, и дальнейшие отзывы.
Ну и просмотр индекса на примет скрытых из каталогов файлов сделать легко.
Ну это идеальный вариант - если делать архив. В общем же случае файлы делятся на три типа: image (поблочное копирование 1:1), ascii (файл с переменной длиной записи в котором каждая запись - строка) и binary (файл с переменной длиной записи которые предваряются длиной записи и завершаются контрольной суммой). Могу немного уже не вспомнить чего, подробнее можно почитать описание утилиты FLX для RSX-11 - она как раз выполняет такие преобразования при копировании в/из RT-11 (именно этот вариант можно рассматривать при копировани в/из windows-unix) и DOS-11 форматы. Такого преобразования вполне достаточно в большинстве случаев.Цитата:
Сообщение от eugeneak
Можно вживую зайти :)Цитата:
Сообщение от eugeneak
Сейчас поищу в каком мануале оно...Цитата:
Сообщение от eugeneak
- - - Добавлено - - -
Да собственно он один в RSX для простых утилит - RSX-11 Utilities ManualЦитата:
Сообщение от form
- - - Добавлено - - -
Смонтировал вышеупомянутый образ в RSX. Он слегка побитый - часть индексного файла затерта мусором, часть файлов покоцана (в том числе библиотека VIDI). Зато вытащил редактор TED из этого образа, а то для RSXа у меня его не сохранилось :)
form, что-нибудь еще попытаться вытащить с HDD ?
Индексный файл я попробую перечитать на досуге. Вероятность небольшая, но.....
А систему не нужно попытаться с этого диска спасти, или она уже и так есть? Может еще и в дистрибутивах?
Не, только то, что заинтересовало.Цитата:
Сообщение от dk_spb
Слишком много битых файлов. Некоторые сразу видно проверкой структуры, а некоторые формально живые, но данные попорчены.Цитата:
Сообщение от dk_spb
Дистрибутивной части там нету - только готовая система с очень ограниченным набором драйверов. Зато DECnet есть :)Цитата:
Сообщение от dk_spb
Заглянуть в образ системы не получается - файл STB от него испорчен.
Я на досуге попробую переснять образ с игнорированием ошибок CRC - может еще что-то получится вытащить.
А, кстати, каким оборудованием поддерживалась DECnet на см1425?
Не представляю даже. Ну как минимум терминальными линиями. В каталогах валяется драйвер DEQNA/DELQA для DECnet.Цитата:
Сообщение от dk_spb
Слегка допилил утилитку, всё ещё сырая, но теперь:
сохраняет время модификации файла (понимает RSX даты >1999 года)
преобразует (по желанию) текстовые файлы в нормальный ASCII cr-lf формат (-c)
сохраняет имя тома
может доставать файлы только с конкретными номерами (fnum,fseq)
может сохранять атрибуты в отдельном, текстовом файле (-a)
Не поддерживает очень большие (или сильно фрагментированные) файлы, больше чем с одним header-блоком (если у кого есть такой образ, поделитесь, допилю и проверю).
С бинарными файлами пока никаких преобразование не производится.
Вложение 59012
Рекомендую также посмотреть на файлы [20,10]MOU*.MAC (MOUDSK.MAC наверное достаточно) из дистрибутива RSX-11M+ - там есть разборки с разными уровнями FILES-11 по которым не найти документации, вроде даже с ODS-2 (ну по нему-то как раз есть), но кроме VMSовского ODS-2 есть еще дополнительные уровни ODS-1...Цитата:
Сообщение от eugeneak
Мне пока идеологически непонятно, для чего извлекать бинарные файлы, ну кроме как посмотреть, т.к. они специфично устроены и нигде кроме RSX не пригодятся (так?). Можно по образцу FLX обьектные преобразовывать, а вот что с другими ?Цитата:
Сообщение от form
Нет, не так. Они пригодятся в других системах. RT-11 например. Файлы OBJ, STB совместимы и переносимы между системами, но формат нужно конвертироватьЦитата:
Сообщение от eugeneak
Это и есть бинарные с точки зрения RSXовских программ переноса файлаов :)Цитата:
Сообщение от eugeneak
Другие варианты - это текст - файлы с атрибутом FD.CR - там надо учитывать, что никаких CRов и LFов в RSX в этих файлах нет, и даже более того - и то и другое может быть частью строки в любом месте. Вот пример как EDT показывает такой файл:Цитата:
Сообщение от eugeneak
Ну что делать с такими хитрыми строками, я честно говоря не знаю, но это в сущности редкость (хотя листинги компиляторов, карты памяти TKB и дампы от DMP могут содержать в себе левые CR/LFы, но не посреди строки). В общем случае, нужно просто при переносе из RSX убирать длину записи и добавлять CRLF (или просто LF если в UNIX переносится) в конец строк.Код:test <CR> test test <LF> test test
test <CR><LF> test test
[EOB]
Ну и остается IMAGE (или BLOCK) mode - просто копирование 1:1 без учета структуры. Файлы TSK, OLB, ULB, SYS можно копировать в этом режиме (ULB, к слову, годятся для архивации файлов, переноса их, и последующего восстановления).
Есть еще текст с фортрановским форматированием, там не знаю как проще переносить: или сохранить символ форматирования или при переносе преобразовать его (во что?) :)
заголовок в начале (01,00) и контрольная сумма ? будет.Цитата:
Сообщение от form
уже сделаноЦитата:
Сообщение от form
Образец бы такого файла найти....Цитата:
Сообщение от form