Вопрос к сообществу:
Поддержка Вектор-06ц нннаада?:)
Вид для печати
Вопрос к сообществу:
Поддержка Вектор-06ц нннаада?:)
Итак по поводу Вектора.
Мною отсюда http://asdasd.rpg.fi/~svo/scalar/categories/ были скачаны 42 образа Вектора.
Вот список:
Код:11jur2.fdd 849920 2001.4.5 20:32.14
add1200.fdd 849920 2009.2.2 19:10.56
cdpacman.fdd 839680 2001.4.24 1:34.42
desant.fdd 839680 2008.10.9 12:16.22
designer.fdd 839680 2009.1.26 1:29.56
DF00GFX.fdd 839680 2009.2.17 0:14.50
DICT.fdd 839680 2012.4.10 11:55.38
DRAW.fdd 839680 2009.2.4 14:32.38
EXAMPLES.fdd 839680 2000.3.23 13:24.34
galery.fdd 839680 2009.1.26 15:39.44
game-15.fdd 839680 2001.4.24 1:56.26
gt.fdd 839680 2003.7.7 20:58.10
incubus.fdd 839680 2001.4.24 2:15.22
komrab.fdd 839680 2008.10.9 12:43.46
lemmings.fdd 839680 2008.10.7 23:53.34
lines.fdd 839680 2001.4.24 8:24.46
madcow.fdd 839680 2009.1.26 1:1.22
mdos28.fdd 839680 2009.4.2 11:52.24
mfi.fdd 839680 2009.2.3 14:26.46
mreversi.fdd 839680 2008.10.7 23:45.42
MUZSPACE.fdd 839680 2011.7.30 2:4.0
newyear.fdd 839680 2010.9.28 0:15.56
pencil.fdd 839680 2010.1.25 0:1.34
PPCLIB30.fdd 839680 2000.12.15 7:51.40
puzznic.fdd 839680 2001.5.10 19:54.10
RAB.fdd 839680 2004.3.15 16:34.24
rmp.fdd 839680 2008.11.21 15:10.12
robocop.fdd 839680 2008.10.19 22:24.6
ROBOTZ.fdd 839680 2012.8.25 21:34.8
rykov.fdd 839680 2003.2.9 17:49.32
scaner5.fdd 839680 2015.9.13 21:18.16
SKYNET.fdd 542720 2015.9.13 21:17.54
sstv.fdd 839680 2009.2.1 23:8.28
stmpro.fdd 849920 2001.4.4 21:56.20
tet3d.fdd 839680 2008.10.6 23:49.36
tretyakov.fdd 839680 2003.2.17 8:44.38
t-rex-05.fdd 839680 2001.4.24 2:18.46
vetka.fdd 839680 2008.10.7 23:42.10
viewgrph.fdd 849920 2009.2.4 13:30.46
vmfi.fdd 839680 2009.2.3 14:18.2
waveay.fdd 839680 2009.1.19 18:4.52
zoo.fdd 839680 2008.10.14 12:11.12
[свернуть]
После того как, как я натравил на них KDI CheckSum Reader, был выяснен следующий формат:
У всех этих образов он одинаковый.Код:len: #03
den: #01
sec: #0005
trk: #0050
----------
spt: #0028
bsh: #04
blm: #0F
exm: #00
dsm: #0187
drm: #007F
al: #00C0
cks: #0020
off: #0008
----------
SecSize: #0400
TrkNum: #00A0
BlockSize: #0800
ExtentSize: #004000
После смены расширения на xdi, все образы были успешно скормлены ATM CP/M Explorer - образы нормально открывались, текстовые файлики успешно читались (правда кодировка где КОИ, где ДОС, кое-где даже Профи).
Конечно, это не все образа Вектора, какие есть в природе, но выкачивать их все по одному мне просто скучно.
Кроме того, у всех проверенных файлов расширение fdd, само собой, не уникальное.
В общем, пока поддержка только через xdi. Последовательность такая:
- Открываете ATM CP/M Explorer;
- Забиваете вышеуказанные параметры формата
в меню Опции-->Настройки-->.xdi, чтобы не вводить их постоянно;Скрытый текст
Код:len: #03
den: #01
sec: #0005
trk: #0050
----------
spt: #0028
bsh: #04
blm: #0F
exm: #00
dsm: #0187
drm: #007F
al: #00C0
cks: #0020
off: #0008
----------
SecSize: #0400
TrkNum: #00A0
BlockSize: #0800
ExtentSize: #004000
[свернуть]- Меняете расширения у образов вектора на xdi;
- Работаете с ними в ATM CP/M Explorer, как обычно.
Пока только так. А ваще сюда - в эту тему - Вектористов бы.
Забыл сказать.
Могут быть проблемы с вычислением свободного места, так как с dsm у Вектора напутано точно:
dsm=187
Размер_блока=800
dsm*Размер_блока=с3800;
При том, что:
SecSize=400
sec=5
TrkNum=A0
Размер_образа= TrkNum*sec* SecSize=c8000;
Тогда вроде получается, что на систему и каталог остается:
c8000-с3800=4800;
По факту же одни только системные дорожки (которых аж 8) занимают (8*5*400) A000.
Вечером буду глядеть, как это влияет на работу с образом.
Или я чего-то не понимаю.
Как выяснилось, значение dsm в работе утилиты не используется.Цитата:
Вечером буду глядеть, как это влияет на работу с образом.
Однако с вычислением свободного места, тем не менее, проблемы обнаружились. И это касается не только Вектора. Дело в том, что я считал свободное место исходя из РАЗМЕРА ИСХОДНОГО ФАЙЛА ОБРАЗА. Логичнее же считать исходя из числа дорожек, числа секторов на 1 дорожке и размера секторов. В следующей версии так и будет.
KDI Checksum Reader v1.4
Добавил поддержку ком. строки до кучи и сюда.
Код:kdichkreader [filename] [--lang <lang>/-l <lang>] [-log/-l]
Options:
-log Save log to file;
-l
--lang <lang> Change interface language (--lang en --> set English language for example).
-l <lang>
Здрасьте.
Чета перечитывал седня старую почту по сабжу и выяснил, что я, похоже, до фига чего понаобещать успел.
Посему обращаюсь ко всем:
Если я чего-то обещал и это все еще актуально, освежите, пожалуйста мою память.
Спасибо.
Поддержку CP/M внутри образа жесткого диска *.OHI (формат MBR с 4-мя основными партициями). Фактически тупо оффсет до партиции посчитать по MBR, а дальше все тоже что и с *.ODI (у которого оффсет=0). Партиции CP/M - c типом 52h, в образе может быть несколько CP/M-партиций.
Вот с партицией CP/M:
http://zx-pk.ru/showpost.php?p=514811&postcount=31
А вот с двумя партициями: CP/M, UZIX
http://zx-pk.ru/showpost.php?p=776311&postcount=38
во вложениях постов
Вот тут можно почитать:
https://ru.wikipedia.org/wiki/%D0%93...B8%D1%81%D1%8C
Классическая структура главной загрузочной записи MBR (начального 512-байтного сектора образа):
В описателях разделов нас интересуют только 3 переменные (далее смещение от начала 16-байтной записи раздела)Код:Смещение Длина, байт Описание
0000h 446 Код загрузчика
01BEh 16 Раздел 1 Таблица разделов
01CEh 16 Раздел 2
01DEh 16 Раздел 3
01EEh 16 Раздел 4
01FEh 2 Сигнатура (55h AAh) - опознаватель MBR
04h Код типа раздела (uint8) - 0=удаленный/свободный, 052h=CP/M, <>052h - прочие типы
08h Смещение первого 512байтного сектора от начала образа (uint32)
0Ch Количество секторов раздела (uint32)
Дааа... В память такой не запихаешь... Че ж делать-то?...
Хотя, конечно, можно... смотря какого размера раздел...
Раздел может быть до сотни мегабайт в реализации на Орионе (а максимальное теоретическое ограничение CP/M на файловую систему - 65356*16384=1073741824 байт, т.е. 1Гбайт).
Решение - не помещать в память, а работать с файлом. Или сделать "проекцию" - функцию, которая вместо обращения к элементу массива в памяти обращается к нужному сектору на диске.
Мне в плагине было это просто сделать, т.к. изначально в памяти храню только структуры каталога, а сами файлы читаются непосредственно из образа. Т.е. достаточно было просто добавить +offset (нулевой в случае дискет и ненулевой для образов HDD) в процедуру чтения с "диска" (и записи)
Error404, есть вопрос по поводу байтов 12 и 15 в директории.
В этой доке http://www.classiccmp.org/cpmarchive.../format22.html написано:
То есть по логике, я считываю байт 12. вычленяю у него соответствующие (включенные в exm) биты, в итоге узнаю размер соответствующих данной записи дериктории и номер части (экстента файла, если я не путаюсь в терминах).Цитата:
RC - Number of records (1 record=128 bytes) used in this extent, low byte.
The total number of records used in this extent is
(EX & exm) * 128 + RC
Вопрос, как происходит (должен происходить) обратный процесс?
При добавлении файла в образ например.
я просто оставлю здесь эжто
http://disktrouble.narod.ru/troublr.html
лучьше позно чем никогда :)
Прошу прощения за оффтоп, но крайняя версия Касперского стала определять
ATM CP/M Explorer (версия 0.3.2.1356, от 05.03.2014), как троян:
https://www.virustotal.com/ru/file/7...is/1450822619/
C чего бы это?
Более новая версия 0.5.1.1362, от 07.09.2015 уже не детектится:
https://www.virustotal.com/ru/file/f...is/1450822202/
Ну я обещал переезд. Он будет. Вместе с релизом, который и так есть у Джони и Анасана. Ну хз. мб он еще кому пригодится. Подробнее, как станет легче.
Сим даю право (на всяк случай) распространять нерелижженное, если в этом есть необъодимость
По поводу просмотра образа дискет Вектора06Ц.
В принципе при изменении расширения на odi или kdi файлы отображает, но какой-то глюк с файлами записанными не для юзера 00. Видно удалённые файлы при выборе отображения "all". Метка юзера 02 (для него есть файлы) вроде как не активна, но его файлы отображает. Для юзеров 01 и 03 нет файлов но их мерки "активны". Или выделение некоторых имён чёрным и серым я не правильно понял...
И при открытии образа постоянно предупреждает "Превышен максимально допустимый номер блока. Номер блока = 380. Макс. номер блока = 379. Смещение = 0000AB14". Знать-бы, что это означает...
Ещё что-то с файлами, длина которых превышает 16КБ (более одной записи в директории), он их (записи в директории) в списке файлов показывает как разные файлы (с одинаковыми именами), один длиной 16КБ, второй 2КБ (в оригинале файл 18КБ). А если сохранить этот образ, то записей для этого файла в директории будет уже 3 (две по 16КБ и одна 2КБ).
KTSerg, извиняюсь как-то пропустил сообщения. В ближайшее время отвечу подробнее и разберусь со всеми приведенными багами.
Про номер блока, причина довольно проста: в dph на диске прописывается число трэков (два байтам по смещению 000E-000F) равное 0050, утилита и вычисляет число максимально число блоков на диске исходя из этой информации. При этом почему-то диски, с которых сняты образа, обычно отформатированы на большее число дорожек, нежели указанно в dph. Тем не менее утилита должна корректно обрабатывать эти "лишние" дорожке, выдавая на всякий случай соответствующее сообщение.
И да. В любом случае, желательно бы мне образа, которые вызывают перечисленные ошибки.
- - - Добавлено - - -
Просто эта версия (та что выложена на всеобщее обозрение) немного устарела, поэтому вполне возможно многие проблемы уже решены.
После проведения значительного количества экспериментов над содержимым "глючного" образа дискеты Вектора, переименованной в .odi, выяснил следующее...
Сообщение о превышении номера макс.блока видимо прекращает дальнейшую обработку директория и выводит его в текущем (не обработанном) виде, т.е. с двойными именами длинных файлов, не корректным распределением файлов по "юзерам", не подсчитанными CRC (может ещё чего)...
Дальнейшее сохранение такого образа естественно приводит к искажению информации в образе дискеты, и делает его не пригодным для дальнейшего использования по назначению.
Указание на "смещение" в сообщении точно указывает на адрес (в файле образа) в котором обнаружено "нарушение структуры" (типа номер блока за пределами 80ой дорожки). В моём случае это номер блока (сектора) файла, причём сам файл помечен как удалённый (юзер Е5). После удаления этого файла из директория (заполнение записи кодом Е5, в сторонней программе), образ дискеты стал открываться абсолютно корректно и все перечисленные мной "глюки" пропали.
KTSerg, ага. Все именно так. И да. В данной версии обработка на это прерывается. Причем прерывается и сборка всех экстентов в файлы. Для этого смещения я и указываю (ну то есть это больше для себя, чтобы посмотреть где и что не так:)).
А можно сюда (или даже в личку) такой образ, кое-что хочется проверить:)
Вот такой образ дискеты для Вектора 06Ц.
Не зная правда, можно ли на форуме такие большие файлы (500Кило) к сообщениям цеплять...
Итак, наконец-то настало время давно обещанного переезда (и естественно обновления). В данный момент как раз оформляю тему. Потом размещу ссылку здесь. Отныне все, что касается моей утилиты, будет обсуждаться именно в той теме.
Обещанная ссылка: http://zx-pk.ru/showthread.php?t=26454