Орион-ПРО. Софтверные дела

Цитата:

---

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

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

---

Да, есть такой эффект. Закинул сейчас на диск 4 файла по 650кб, первые три читаются нормально, а четвертый - "улетает". Трудно сказать почему.

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

Жуть. Во дело пошло. Я вас подбадриваю). Мне в сентябре нечего будет делать.

На вид явный заворот адреса. Это как слет LBA48 на дисках более 120ГБ под XP до SP1/SP2. Слет на LBA32 херил все на диске по причине затирания начала при завороте адресов. В вашем случае, это можно попробовать определить, загрузив файлы с определенным содержимым (текстом) и посмотреть что выведет ДОС при глюке.

Цитата:

---

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

Да, в этом и вопрос: зачем авторы BDOS изначально сделали искусственное ограничение - переполнение счетчика экстентов файла не по заполнению всего байта

---

Видимо, для обратной совместимости. Почитай на досуге вот это: http://www.seasip.info/Cpm/format22.html

Скрытый текст

Код:

---

The CP/M 2.2 directory has only one type of entry:

UU F1 F2 F3 F4 F5 F6 F7 F8 T1 T2 T3 EX S1 S2 RC  .FILENAMETYP....
AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL  ................

UU = User number. 0-15 (on some systems, 0-31). The user number allows multiple
    files of the same name to coexist on the disc.
    User number = 0E5h => File deleted
Fn - filename
Tn - filetype. The characters used for these are 7-bit ASCII.
      The top bit of T1 (often referred to as T1') is set if the file is
    read-only.
      T2' is set if the file is a system file (this corresponds to "hidden" on
    other systems).
EX = Extent counter, low byte - takes values from 0-31
S2 = Extent counter, high byte.

      An extent is the portion of a file controlled by one directory entry.
    If a file takes up more blocks than can be listed in one directory entry,
    it is given multiple entries, distinguished by their EX and S2 bytes. The
    formula is: Entry number = ((32*S2)+EX) / (exm+1) where exm is the
    extent mask value from the Disc Parameter Block.

S1 - reserved, set to 0.
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

    If RC is 80h, this extent is full and there may be another one on the disc.
    File lengths are only saved to the nearest 128 bytes.

AL - Allocation. Each AL is the number of a block on the disc. If an AL
    number is zero, that section of the file has no storage allocated to it
    (ie it does not exist). For example, a 3k file might have allocation
    5,6,8,0,0.... - the first 1k is in block 5, the second in block 6, the
    third in block 8.
    AL numbers can either be 8-bit (if there are fewer than 256 blocks on the
    disc) or 16-bit (stored low byte first).

---

[свернуть]

Кстати, ограничение в 512кБ было в CP/M 1.4, там на сайте про это есть.

Цитата:

---

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

Видимо, для обратной совместимости. Почитай на досуге вот это: http://www.seasip.info/Cpm/format22.html

---

Эти описания такие описания...
Штука в том, что
"formula is: Entry number = ((32*S2)+EX) / (exm+1)"
нифига не работает. Играет только EX, как только он заполняется - всё, кирдык, 32 куска по 16к = 512кб.
А "S2 = Extent counter, high byte." на самом деле в коде - 4 бита (глючных при том).

Вот кстати. Та CP/M, что практически повсюду, на Башкирии выдаёт версию 1.2! Это, конечно, просто текст из биоса CP/M, который писали в КБ завода им. Кирова, но наводит на мысли, что это никакая не 2.2
А ещё, на том сайте есть такая фраза: CP/M 1.4 fits in 6.5k. Так вот вместе с биосом оно именно столько и занимает.

Интересно, почему все решили, что это версия 2.2?

Корвет, например, выдаёт:
CP/M-80 v. 2.2
ОФП НИИЯФ МГУ BIOS
Ver. 1.2 (c) III 1988

Вроде как рядом со словом CP/M стоит 2.2, но и тут есть про версию 1.2! Хотя вроде как это типа версия биоса.

Совпадение? Не думаю :)

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

Но, вообще-то, функция выдачи номера версии честно выдаёт 22h. :confused:

Цитата:

---

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

На вид явный заворот адреса. Это как слет LBA48 на дисках более 120ГБ под XP до SP1/SP2. Слет на LBA32 херил все на диске по причине затирания начала при завороте адресов. В вашем случае, это можно попробовать определить, загрузив файлы с определенным содержимым (текстом) и посмотреть что выведет ДОС при глюке.

---

правки в COMPRAND не повлияли.
Да, похоже на заворот адреса - вместо четвертого файла, оно начинает читать каталог (т.е. нулевой экстент).
Но вот что мне не ясно - почему оно на разных файлах имеет как бы "продолжающийся счетчик" (который и заворачивается)? Когда переменные все инициализируются при открытии файла, т.е. счетчик экстента каждый раз должен начинаться с нуля. Я бы понял если бы файл был более 2мб и по оно заворачивалось по границе в 2мб (т.к. я порушил разрядность в сторону увеличения размера до 2мб). Но первые то три отдельных файла читаются нормально, и каждый - от начала и до конца (конец тоже определяется). Шиза какая-то.

Цитата:

---

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

А "S2 = Extent counter, high byte." на самом деле в коде - 4 бита (глючных при том).

---

Вот комментарий из исходников:

Код:

---

;  For random i/o, set the fcb for the desired record number
; based on the 'r0,r1,r2' bytes. These bytes in the fcb are
; used as follows:
;
;      fcb+35            fcb+34            fcb+33
;  |    'r-2'      |      'r-1'      |      'r-0'    |
;  |7            0 | 7            0 | 7            0|
;  |0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0|
;  |    overflow  | | extra |  extent  |  record #  |
;  | ______________| |_extent|__number___|_____________|
;                    also 's2'

---

Максимальный номер записи 65535.

Покопался в исходниках - вроде всё должно работать. Если не работает, надо проверять DPB.

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

Цитата:

---

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

Да, есть такой эффект. Закинул сейчас на диск 4 файла по 650кб, первые три читаются нормально, а четвертый - "улетает". Трудно сказать почему.

---

А размер каталога не 4Кб? А то для 4-х файлов по 650Кб надо как минимум 5.2Кб.

Цитата:

---

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

правки в COMPRAND не повлияли.
Да, похоже на заворот адреса - вместо четвертого файла, оно начинает читать каталог (т.е. нулевой экстент).
Но вот что мне не ясно - почему оно на разных файлах имеет как бы "продолжающийся счетчик" (который и заворачивается)? Когда переменные все инициализируются при открытии файла, т.е. счетчик экстента каждый раз должен начинаться с нуля. Я бы понял если бы файл был более 2мб и по оно заворачивалось по границе в 2мб (т.к. я порушил разрядность в сторону увеличения размера до 2мб). Но первые то три отдельных файла читаются нормально, и каждый - от начала и до конца (конец тоже определяется). Шиза какая-то.

---

Ну окромя относительных адресов-счетчиков есть еще и абсолютный. О чем и была речь в моем сообщении. На примере все тех же HDD, LBA это уже метрика самого диска. Какой разрядности абсолютный счетчик ДОС? Для дисковода, я так понимаю, это CHS формат.

Цитата:

---

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

Вот комментарий из исходников:

Код:

---

;  For random i/o, set the fcb for the desired record number
; based on the 'r0,r1,r2' bytes. These bytes in the fcb are
; used as follows:
;
;      fcb+35            fcb+34            fcb+33
;  |    'r-2'      |      'r-1'      |      'r-0'    |
;  |7            0 | 7            0 | 7            0|
;  |0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0|
;  |    overflow  | | extra |  extent  |  record #  |
;  | ______________| |_extent|__number___|_____________|
;                    also 's2'

---

Максимальный номер записи 65535.

Покопался в исходниках - вроде всё должно работать. Если не работает, надо проверять DPB.

---

Да, есть такой комент, он страницей раньше в моем посте даже есть. :)
Там все очень коряво: эти переменные (экстент EX и переполнение extra_extent=S2) существуют в двух ипостасях одновременно: в байтах FCB+12,+14 (для любых операций) и FCB+33,+34 (для прямого позиционирования, причем в коде довольно часто перепрыгивает с подпрограмм произвольного на последовательный и обратно). При этом FCB+12 - ровный байт, и FCB+14 - ровный байт (номер записи отдельно в третьем байте), а вот FCB+33 и +34 - это 5 (EX) и 4 (extra=S2) битов упакованные вместе с номером записи в общий 16-битный целый. Т.е. S2 не может быть больше 4 битов даже там, где он хранится целым байтом. И BDOS постоянно на сдвигах тасует их между этими двумя способами представления, где-то сглюкивая (не отрабатывает переполнение EX либо тупо не умеет позиционироваться по EX+extra_extent, а только по EX). Погнались за совместимостью (какой?с чем?) и наколбасили.

Ну я поначалу и думал: раз оно не умеет отрабатывать переполнение EX увеличением extra_extent (хотя по коду вроде должно, собственно поэтому в реальности максимальный номер записи не 65535, а 4096, т.е. 512кб), или что более вероятно не адресуется по extra_extent (а вот это я по коду не понял - да или нет), то тупо увеличу EX в разрядности за счет пропорционального уменьшения extra (чтобы упакованно осталось как и ранее 16 бит) - и "на наш век хватит". Ан нет, где-то "совместители" еще одну (а может и не одну) "мину подложили под наше молодое государство" (с) главстерх

Цитата:

---

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

А размер каталога не 4Кб? А то для 4-х файлов по 650Кб надо как минимум 5.2Кб.

---

Размер каталога - одна группа (меньше не сделаешь), т.е. 16кб. Т.е. в теории в такой каталог должно влезать 16384/32=512 файловых дескрипторов, *8=4096 групп, *16=65536кб (64Мб) дискового пространства, плюс системные треки. Размер партиции/ФС совпадает - 64Мб (или даже меньше, не помню - образ на рабочем компе).

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

Цитата:

---

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

Ну окромя относительных адресов-счетчиков есть еще и абсолютный. О чем и была речь в моем сообщении. На примере все тех же HDD, LBA это уже метрика самого диска. Какой разрядности абсолютный счетчик ДОС? Для дисковода, я так понимаю, это CHS формат.

---

Если про BIOS, то для IDE/SD в глобальном адресе (по всей поверхности носителя) поддерживается 32-битный LBA секторами по 512 байт. Который внути каждого конкретного раздела слегка уменьшается в разрядности за счет работы 128-байтными блоками. Но все равно этих секторов там "номер трека"(16 бит)*"номер сектора"(16 бит). Т.е. в разрядность CP/M-овского 16-битного произвольного адреса записи попадает гарантированно даже в комбинациях (1трек на 65536 секторов) или (65536 треков по 1 сектору). Да и заворачивается оно не на нулевой сектор раздела, и не на нулевой сектор целого диска, а на нулевую группу (группа - это сугубо понятие BDOS, она может начинаться и не от начала раздела, собственно в данном образе так и есть) т.е. уже после системных дорожек текущего раздела. Где-то в BDOS какашка.