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

[Error404]

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

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

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

[OrionExt]

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

[HardWareMan]

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

[b2m]

Да, в этом и вопрос: зачем авторы 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, там на сайте про это есть.

[Error404]

Видимо, для обратной совместимости. Почитай на досуге вот это: 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 бита (глючных при том).

[b2m]

Вот кстати. Та 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.

[Error404]

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

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

[b2m]

А "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.

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

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

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

[HardWareMan]

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

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

[Error404]

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

;   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 бит) - и "на наш век хватит". Ан нет, где-то "совместители" еще одну (а может и не одну) "мину подложили под наше молодое государство" (с) главстерх

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

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

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

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

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