Про СМ1425

[MiX]

Зачем?????

Да это я по инерции...
Вод ведь какое дело. В мануале неформатированная ёмкость 96.0Мб, форматированная 80.2. Т.е. 15,8Мб на служебную информацию.
Нехило как-то.

Дальше
512*1024 * 9 * 18= 84 934 656
512*1024 * 9 * 17= 80 216 064
получается.

Что-то мне подсказывает что для этого винта это невозможно.

Что конкретно?

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

Иногда работает несколько раз нормально, а иногда - каждый раз вскрывать и расщелкивать.

В стартапе по 12 вольтам он потребляет 4А, и это не считая ещё по 5 вольтам.

Плата такого же винта на пробу будет не раньше чем через две-три недели

У меня такая есть на пробу.

[shattered]

подцепил этот образ к 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

[dk_spb]

shattered, А не дадите краткую инструкцию по simh для подцепления этого образа?


MiX,
>Что конкретно?
Как Вы представляете себе форматирование диска с интерфейсом ST-506 в другой геометрии?

>У меня такая есть на пробу.
Сможете дать на выходные?

[shattered]

конфиг 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

отладка включается

set debug stdout
set rq debug

загрузка -- boot rq0

[anasana]

А ... где-нибудь в начале диске нет данных о месте расположения "самого вкусного"?

По идее практически в начале (в 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

[form]

vidi .olb;1

А-а-а! Хочу!

[anasana]

дык , этот MOCPBM вообще не гуглится толком, там вообще всё интересно! (донор-то ясен, подпихнуть если чего-то будет критически не хватать)
P.S. А я пока помучаю вывод в дополнительный лог, если сектор используется но вдруг не считался (0xEE), что бы там сразу было видно какой именно файл пострадал.
но надеюсь, что обойдётся.

[dk_spb]

> А я пока помучаю вывод в дополнительный лог, если сектор используется но вдруг не считался (0xEE)
Да я вот как раз в раздумьях про эти 0xee. Просто сейчас если CRC не совпало - я тупо сектор забиваю 0xEE. А там может всего один битик съехал....
У СМ-1425.5144 это именно CRC, не ECC.
Но если это битик, жалко всю остальную информацию терять, забивая её 0xEE. Вот я и в раздумьях как лучше. Два образа делать (один с забитием сбойных секторов 0xEE, чтобы сразу было видно; другой со всем что считалось) или еще как-то извратиться... В принципе есть лог, в котором видно какие сектора с ошибкой по CRC.

Сейчас еще если сектор не нашелся - то же 0xEE. Но это уже придумал как отслеживать и отмечать.

[form]

этот MOCPBM вообще не гуглится толком

Ну по всему видно, что это обычный M+ V3.0 - в этой версии как раз прошло большинство "современных" модификаций M+ ([обязательное монтирование, векторизация итд], которые частично были добавлены и в P/OS V3.0). Я бы предположил, что ОСРВМ - это был M+ версии 2.1, а МОСРВМ - 3.0, а более поздних версий "советских" скорее всего не было

[dk_spb]

Ах, да, забыл добавить что это я пока только с одной читалкой пробую, где ФАПЧ аппаратный. У меня еще другая есть (не моё поделие), там программно всё, может и вытянет последние две поверхности.

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

[offtop]кстати, если у кого-нибудь есть отечественные HDD или их фото с логотипами, датами выпуска и т.д. - поделитесь фото.
Особенно интересны пермские HDD серии EC531x. Что-то там совсем мутно с производством HDD на Пензенском заводе ВЭМ. Точно была перемаркировка, а вот были ли свои..... [/offtop]