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

[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 какашка.

[Advertiser]