Почему у меня появляется такое сообщение при попытке отформатировать диск В.
ОС DSDOS последней декабрьская версии 2017 года.
ОЗУ 128 кб
Вид для печати
Почему у меня появляется такое сообщение при попытке отформатировать диск В.
ОС DSDOS последней декабрьская версии 2017 года.
ОЗУ 128 кб
RD3AY, загрузчик ОС не обнаружил в аппаратуре квазидиск, соответственно диск В: недоступен.
Вероятная причина - мало ОЗУ. Минимальный требуемый объём, чтобы была возможность организовать квазидиск - 256 Кб.
Через утилиту SYSTEM$ можно переназначить рабочий диск на другой:
http://denn.ru//8bit/orion/soft/dsdos/system.png
Но этот другой диск в системе должен быть. Без рабочего диска пользоваться ОС можно, но не будет сохраняться конфигурация программ при выходе из них, не будет работать буфер обмена, драйвер расширения и т.д..
RD3AY, но коллега, РУ7 это 256К, или ты их тупо вместо РУ5 воткнул?
Можно закрыть вопрос такой штукой - http://zx-pk.ru/threads/25367-gibrid...l=1#post880943
Или ещё лучше такой - http://zx-pk.ru/threads/21984-dsdos-...l=1#post881433
По последнему: в разработке более упрощённый, функционально полностью аналогичный вариант на ПЗУ-логике, надеюсь в ближайшее время отмакетирую и выложу проект.
Формат графических файлов ОС DSDOS
Для поддержки всего многообразия организаций экранных областей ПРК Орион разработан универсальный формат хранения растровой графики.
Файлы в этом формате имеют расширение *.GF (альтернативный вариант - *.G).
Характеристики формата
Размер изображения: 8x1...512x256 точек;
Бит-планы: передний, задний, оба вместе;
Режимы: м/х спрайт, спрайт атрибутов цвета, монохромный (палитры №1 и №2), 4-цветный (палитры №1 и №2), 16-цветный (палитровый), 16-цветный 4-плоскостной (в разработке);
Сжатие: по алгоритму D16K™.
Алгоритм сжатия D16K™
Основан на кодировании часто встречающихся в графике последовательностей одинаковых байтов в виде: "счётчик количества, значение байта".
В отличие от похожего алгоритма сжатия в популярных форматах *.PC и *.4C, в D16K™ применена более гибкая адаптация к длине последовательностей, что позволяет эффективнее сжимать данные. Например, полностью однородный фон заднего плана экрана размером 512x256 сожмётся всего в три байта.
Скорость отработки алгоритма не хуже вышеупомянутых "классических", объём кода немного больше.
Сжатая информация представляют собой последовательность конструкций вида: "идентификатор/счётчик - данные". Данные представляют собой либо последовательность различающихся байтов, либо значение повторяющегося байта. Если последовательность короче 64-х байт, то идентификатор (2 бита) и счётчик (6 бит) кодируются одним байтом, если длина последовательности 64...16384 байта, то они кодируются двумя байтами: первый содержит идентификатор (2 бита) и старший байт счётчика (6 бит), а второй содержит младший байт счётчика (8 бит).
Для удобства (оптимизации по скорости) распаковки, содержимое первого байта конструкции кодируется следующим образом: биты D7..D2 содержат соответствующее значение счётчика, бит D1 кодирует длину последовательности (0 - 1..63, 1 - 64..16384), бит D0 кодирует вид последовательности (0 - разные, 1 - одинаковые).
Окончание данных алгоритм упаковки/распаковки вычисляет в процессе работы, исходя из данных о размерах картинки.
Структура данных файлов формата *.GF
Offset - DATA
__________________________________________________ ___________
0000h - признак формата = FBh (1 байт)
0001h - видеорежим (1 байт)
0002h - высота картинки в пикселях (1 байт)
0003h - ширина картинки в байтах (1 байт)
0004h - данные изображения, сжатые по алгоритму D16K™ (N байт)
__________________________________________________ ___________
Видеорежимы
00h - монохромный, палитра №1, данные содержат только передний план;
01h - монохромный, палитра №2, данные содержат только передний план;
02h - монохромный спрайт, видеорежим не определён, данные содержат только передний план;
03h - спрайт атрибутов цвета, видеорежим не определён, данные содержат только задний план;
04h - 4-цветный, палитра №1, данные содержат передний и задний планы;
05h - 4-цветный, палитра №2, данные содержат передний и задний планы;
06h - 16-цветный палитровый, данные содержат передний и задний планы;
07h - зарезервирован (пока аналогично режиму 06h);
08h - 16-цветный 4-плоскостной (мультикарта Орион-ПРО).
На будущее заложена возможность расширения: старшие два бита видеорежима зарезервированы под кодирование алгоритма сжатия, значения D7=D6=0 кодируют сжатие по алгоритму D16K™.
Данные изображения
Видеорежимы 04..07h содержат два бит-плана изображения, в этом случае сначала идут данные переднего плана, а за ними данные заднего плана. Изображение кодируется сверху-вниз, слева-направо.
Поддержка
В настоящий момент написана утилита просмотра графических файлов во всех популярных форматах (опубликую позже), поддерживающая новый формат *.GF.
Традиционно в SDK DSDOS будет включена библиотека работы с данным форматом.
Да, удачная идея компрессии графики, т.к действительно в реальных картинках цепочки повторов не длинны. Только логичнее под счётчик брать биты D0...D5, а биты D6, D7 использовать как служебные. И это ускорит. Потому-что бит D7 проверяется проще, к тому же в цепочках длиннее 64-х байт эти 6 битов, являющиеся в этом случае старшим байтом длины, приходится сдвигать на 2 позиции.Цитата:
Сообщение от Denn
barsik, изначально так и было задумано (идентификатор в старших битах), но при программировании алгоритма выяснилось, что проще и быстрее "разматывать" именно такой "бутерброд", который сделан в финальной версии.
Помимо старшего бита D7, также нужно анализировать и предыдущий - D6, после чего оба этих бита нужно отбрасывать (обнулять) дабы получить значение счётчика. В варианте кодирования идентификатора в младших битах мы убиваем трёх зайцев: анализ каждого бита одной командой ЦПУ (ротация битов через флаг <C>) + параллельно их обнуление и после анализа биты счётчика автоматом оказываются на нужных позициях.
Пример участка кода распаковки:
Код:XRA A ; <C>=0
MOV B,A ; [B]=0
LOOP:
CALL GetBYTE
;<C>=0
RAR
JC UnpackSame
; серия разных
;<C>=0
RAR
JNC UnpackDiff1
; серия разных 64..16384
MOV B,A
CALL GetBYTE
UnpackDiff1:
MOV C,A
UnpackDiff2:
CALL GetBYTE
MOV M,A
; адрес следующего байта на экране
CALL NextScreenADDR
RZ; конец алгоритма
UnpackDiff3:
DCX B
MOV A,B
ORA C
JNZ UnpackDiff2
JMP LOOP
UnpackSame:
; серия одинаковых
CMC; <C>=0
RAR
JNC UnpackSame1
; серия одинаковых 64..16384
MOV B,A
CALL GetBYTE
UnpackSame1:
MOV C,A
CALL GetBYTE
STA UnpackSame2+1
UnpackSame2:
MVI M,0
; адрес следующего байта на экране
CALL NextScreenADDR
RZ; конец алгоритма
UnpackSame3:
DCX B
MOV A,B
ORA C
JNZ UnpackSame2
JMP LOOP
Откорректировал заглавный пост - http://zx-pk.ru/threads/21984-dsdos-...l=1#post634440
Спасибо за рацпредложение!
Отлично, а то я уже стал сам каталог составлять из темы в word файле. Теперь все стало на много удобней.
Запустил сегодня СОМ1 порт, даже не интересно, все сразу заработало:).
Хотя подходящего кварца на 7.3728 МГц не нашлось, поставил на 7200 кГц.
Просто протестировать работу клоков, работает....
Протестировал работу с ORI - сервером.
Это просто песня какая то !!!
Одно обидно, зачем КГМД делал, от теперь и не к чему...:)
Нужно теперь делать плату ROM-RAM а то ОС постоянно ругается на отсутствие диска В:
Штатных 128 кб мало.
Что посоветуете к сборке?
И вправду, тоска зелёная )) никакого ORIального секаса - так не интересно :)
По скриншоту вижу, что коннект на 14400 Бод. А разгонять до 38400 не пробовали?
Ну, это же разные песни. Сервер - это фактически эмуляция, а дискогрыз - он настоящий, тёплый ламповый ;)
Нарастить родное ОЗУ Ориона я бы всё таки порекомендовал. Квазидиск самый быстрый из всех накопителей, с ним наибольший комфорт в работе.
Электронный диск (ROM-RAM) простая конструкция, но скорость работы RAM-части довольно медленная из-за используемого интерфейса.
Наиболее удачный по объёму/скорости - RAM7. Но по схемотехнике он сложный. Как писал выше, в разработке более простой вариант RAM7, но его надо будет подождать...
Тут смотрите по имеющимся в наличии наличию ЗУ и опыту сборки. Программная поддержка всех видов дисков в ОС есть.
Любой вариант, кроме глупой установки платки расширения ОЗУ этажеркой с лишними буферами.Цитата:
Сообщение от RD3AY
Мне больше всего нравится вариант установки РУ5 в два этажа. Я ставил так 256 кб на десяток плат ОРИОНА. Но если есть хоть одна банка РУ7, то лучше использовать вариант М.Домарёва, когда 256 кб получаются из одной банки РУ7 и одной банки РУ5. А ещё можно применить две банки РУ7 и получить 512 кб (но сам я такого не делал).
А ещё приятный и экономичный по току вариант получается, если есть DIP статика типа 62256/w24512/w24257. Она ставится просто (также как ПЗУ, т.е адреса прямо от CPU без мультиплексоров). Я никогда не распаивал преобразователь 12 вольт (т.к сразу догадался, что дисковод он не потянет, зачем он тогда нужен?) и на месте преобразователя сверлил отверстия и ставил одну панельку под 62256 (2 штуки напаянные друг на друга). Так я самым первым (в январе 1991) получил на ОРИОНЕ 192 кб ОЗУ.
Фото печатной платы интерфейса Вы выложили, а где её схема? И главный вопрос - какую программу на IBM PC использовали для обмена по последовательному интерфейсу?Цитата:
Сообщение от RD3AY
barsik, схемы и ПО - всё есть в теме, нет смысла дублировать.
Denn, это прекрасно буржуйские микрухи для рам диска. Но это прошлый день. Отстаем. Так сказать не грубо (20лет прошло).
А не пора бы уже напрячь ВВ55 в отношении IDE?
Схема из топика от Denn а. Я только под свои детали заточил, ну кончились у меня ЛН1 :v2_dizzy_roll:и интегрального генератора на 7.3728 нет.
Сделал генератор по классической схеме от ориона-128 только на К555ЛА3.
Преобразователь уровней TTL-USART на SOIC-16 ST232D, что было в ящике от стола.
Дешифратор старенькая К155ИД3, 1533ИД3 в узком корпусе, тоже нет.
Тестировал через терминалку Terminal.exe
https://sites.google.com/site/terminalbpp/
ПК Windows 7 максимальная SP1 CPU Intel(R) Core(TM) 3.5 ГГц 64 разрядная.
Вопрос, как переключиться на скорость 38400 Бод, вроде бы на такой скорости тестировал работу СОМ порта в терминалке.
Изменить значение [F1] Делитель: 0DH на .....
- - - Добавлено - - -
Сейчас в ORI -сервере в установках скорости СОМ порта, пробовал разные значения, конект идет только на скорости 38400 Бод.
- - - Добавлено - - -
Сейчас в ORI -сервере в установках скорости СОМ порта, пробовал разные значения, конект идет только на скорости 38400 Бод.
RD3AY, всё верно, это я затупил, на схеме же аппаратно зафиксирована скорость протокола, поэтому от настроек теста Ориона она не зависит (это настройки 580ВИ53).
Главное, что 38400 работает стабильно (при том, что кварц неточный!). Это максимум для ВВ51, и это уже приемлемая скорость для работы.
Хотел спросить, при нажатии F5 появляется окно копирования файла, так вот, у меня на белом фоне окна не видно белых надписей,
у вас фон окна свело-серое, и белые надписи видно. В монохромном режиме, все нормально.
как это можно поправить?
Предполагаю что нужно подбирать резисторы в схеме формирования полутонов на выходе формирователя видеосигнала.
Или как то еще...
Итак, в продолжение темы графики, обещанная утилита просмотра картинок, поддерживающая различные форматы файлов растровой графики ПРК "Орион" - PICVIEW$.
Утилита имеет два режима работы: консольный (режим командной строки) и т.н. WUI (оконный интерфейс). В первом варианте при вызове утилиты, в командной строке указываются параметры (имя файла или запрос справки "/?"):
http://denn.ru/8bit/orion/soft/grf/picview00.png
Во втором варианте (вызов без параметров в командной строке) открывается собственный интерфейс выбора файлов для просмотра и некоторых других параметров:
http://denn.ru/8bit/orion/soft/grf/picview01.png
Во втором варианте требуется наличие в системе установленного драйвера расширения ExtDRV версии не ниже 2.7 !
Далее будет описание оконного интерфейса.
Поддерживаются все известные файлы картинок, включая новый формат DSDOS ( *.GF ). Применены быстрые алгоритмы распаковки и вывода изображений.
По нажатию любой клавиши, кроме [F1], [I], [Esc] и [F4], открывается диалог выбора файла для просмотра:
http://denn.ru/8bit/orion/soft/grf/picview02.png
В списке отображаются только файлы графических форматов, имеющиеся на текущем диске. Для выбора диска необходимо нажать соответствующую клавишу - [A]..[H].
Навигация по списку файлов стандартная для подобных диалогов в ОС DSDOS: [↑], [↓], [Home], [End], а также их сочетания с [Ctrl+]. Выбор файла для просмотра - [Enter].
Также действуют следующие клавиши:
[L] - включение/выключение отображения длины файлов;
[T] - включение/выключение отображения даты файлов;
[+] - увеличение количества отображаемых на экране файлов (max=22);
[-] - уменьшение количества отображаемых на экране файлов (min=3);
Выбранные значения параметров сохраняются в конфигурационном файле (PVIEW.CF) утилиты на рабочем диске ОС DSDOS.
http://denn.ru/8bit/orion/soft/grf/picview03.png
После выбора файла производится его загрузка в буфер, а затем вывод на экран:
http://denn.ru/8bit/orion/soft/grf/picview04.png
Картинка выводится на чёрном фоне, в центре экрана (утилита автоматически рассчитывает координаты, в зависимости от размеров).
Видеорежим ПРК "Орион" устанавливается в соответствии с информацией в файле. Поддерживаются все аппаратные режимы Ориона, кроме "гашения экрана".
После успешной загрузки изображения, возможен просмотр детализации его параметров (клавиша - [I]):
http://denn.ru/8bit/orion/soft/grf/picview05.png
Выводятся:
- полное имя файла;
- размеры в пикселях;
- требуемый видеорежим (в скобках указана палитра, 1 или 2);
- используемые бит-планы: передний (FG), задний (BG) или оба вместе (FG BG).
По нажатию любой клавиши, кроме [F4] (выход в ОС), детализация убирается с экрана.
Окно детализации выводится всегда в 16-цветном режиме, в связи с этим, если картинка в 4-цветном, то на время вывода детализации она может быть искажена:
http://denn.ru/8bit/orion/soft/grf/picview06.png http://denn.ru/8bit/orion/soft/grf/picview07.png
Файлы копий экрана в формате ZX-Spectrum выводятся в 16-цветном режиме Ориона:
http://denn.ru/8bit/orion/soft/grf/picview08.png http://denn.ru/8bit/orion/soft/grf/picview09.png
Утилита автоматически выполняет приведение цветового пространства к орионовскому при выводе изображения.
Выход из программы в любой момент по клавише [F4], а из режима просмотра изображения также по клавише [Esc].
Напоследок ещё пара прекрасных картинок с "вражеской" платформы :)
http://denn.ru/8bit/orion/soft/grf/picview10.png http://denn.ru/8bit/orion/soft/grf/picview11.png
Ссылки для скачивания:
в формате ORI - http://denn.ru/8bit/orion/soft/grf/PICVIEW$.ori
архивом - http://denn.ru/8bit/orion/soft/grf/picview.rar
- - - Добавлено - - -
RD3AY, вот цвета в эмуляторе:
https://pp.userapi.com/c834104/v8341...z2uOB0tYNE.jpg
А вот цвета на реале:
https://pp.userapi.com/c841639/v8416...qVF6ARCRjY.jpg
Фото с реала не один-в-один как жизни, но примерно похоже. В общем, градации яркости вполне читаемые.
Думаю в Вашем случае дело в формировании видеосигнала или в устройстве отображения. Сигнал I (яркостый "цвет") корректно заведён в монитор?
А как можно завести сигнал I при подключении по SCART?
А зачем?
Да читаю посты выше о некорректности отображения некоторых цветов. В моем Орионе тоже некоторые цвета отображаются некорректно, например вместо розового стабильно красный. Хотя основные цвета выглядят правильно.
Вот и подумал, что наверное нужно как-то задействовать выход яркостного сигнала.
Проверял директивой С.
ПысПыс: у меня пока задействованы R G B и Sync
Ну правильно. I подмешивается к RGB на самой плате. Делая их не 2х ступенчатыми (0 - нет, 1 - есть) а 4х (0 - нет, 1 - слабый, 2 - сильнее, 3 - сильный). В спектруме подмешивание таково, что 1 шаг отсутствует (что дает возможность рисовать интенсивными цветами на черном без артефактов), из-за атрибута на целое знакоместо.
mr.Lee, сигнал "I" нужно обязательно задействовать, тогда на экране будут задуманные 16 цветов. Без него будет только 8 цветов, и цвета с кодами 8..15 будут просто дублировать цвета 0..7. Замес сигнала "I" нужно делать до SCART'а (резистивные делители и диоды).
Собственно да, только 8 и наблюдаю.
Собрал на макетке делитель, уже можно различить красный и розовый:), но нужно подобрать номиналы.
Разбираюсь потихоньку с интерфейсом IDE-устройств на Орионе. В связи с этим родилась небольшая утилита вывода ТТХ винчестера, может кому-нибудь пригодится в хозяйстве:
http://denn.ru/8bit/orion/soft/hdd/hddinfo.png
Утилита униплатформенная, традиционно поддерживаются Орион-128 и Орион-ПРО (автодетект средствами API DSDOS).
КНЖМД на Орион-128 ищется по базовому адресу F790h (DS-Card), на Орион-ПРО - 50h (карта IDE-RTC).
В случае ошибки выводится её подробная расшифровка (не безликий код, как в популярных тестах).
Ссылка для скачивания - http://denn.ru/8bit/orion/soft/hdd/hddinfo.ori - обновлена 03.03.2018 !
П.С. фото с Орион-128:
https://pp.userapi.com/c840026/v8400...NtbqJZgP2k.jpg
Ссылки по теме:
Программирование жесткого диска
Описание стандарта ATA с командами
Коды обязательных команд АТА
Немного про LBA режим
Информация о жестких дисках
Я использую адаптер для монитора Zxkit VGA & PAL, к сожалению прошивка к нему не до конца доработана под ОРИОН, обрезает две верхние строки и ни как не реагирует на сигнал I.
Пробовал его отключать/подключать, ни чего не меняется.
Интересно, есть сейчас нормальная прошивка под этот адаптер Zxkit VGA & PAL для ОРИОНа?
С платой GBS 8200 V4.0 все работает, хотя изображение не такое четкое как с адаптером Zxkit VGA & PAL.
RD3AY, у меня такой адаптер - http://zx-pk.com/forum/viewtopic.php?f=7&t=3292
Вроде как тот же Zxkit VGA & PAL. Прошивка 2.08. Всё заработало сразу и без проблем.
Ну у меня не совсем тоже самое, плата от Павла Рябцова, https://yadi.sk/i/Wla12W6L3SydaS
распаивал элементы на плату и прошивал ПЛИС сам.
Пробовал "ковырять" исходники ПЛИС, получалось сместить экран вниз, вверху видно, низ подрезался.
Грешу что у меня монитор 6х9 и на нем невозможно получить раскладку экрана от стандарта ОРИОН.
Да и с градациями цветов тоже не в порядке.
Спасибо, попробую.
У вас нет случайно прошивки для используемого Вами адаптера RGB-VGA http://zx-pk.com/forum/viewtopic.php?f=7&t=3292?
Поделитесь...
Начал разбираться с редактором, набрал и скомпилировал первый файл!!!:v2_dizzy_punk:
Все работает!!!
TEST https://yadi.sk/i/EjzKKQg-3T3HuW
- - - Добавлено - - -
https://yadi.sk/i/EjzKKQg-3T3HuW
RD3AY, прошивок у меня нет. Покупал девайс готовый - тут. Прошивка 2.08.
Попробуйте обратиться к автору темы по продаже.
- - - Добавлено - - -
Отлично, поздравляю! ;)
Сейчас благодаря новому ассму я перешёл на библиотечную модель программирования, там ещё понятнее и проще, фактически программа лепится из готовых кубиков (библиотек). В планах разработать т.н. "билдер" на базе ассемблера, это вообще будет вариант для "домохозяек" :)
По возможности буду отписываться в тематической группе ВК.
https://yadi.sk/i/EjzKKQg-3T3HuW
Да, я видел эту информацию. Хоте уже попробовать, "втянул" все файлы в образ ГМД DISK_L.ODI при помощи программы SteinBlume.exe http://era-cg.su/steinblume/
Читаю диск - в ответ "Каталог пуст"
Видимо что то делаю не так, если у Вас есть возможность, выложите одним файлом все библиотеки в образе *.ODI
Попробую записать на дискету и загрузить.
(Ох как бы сейчас пригодился СОМ1 с виртуальным диском G).
Но он у меня установлен на другой плате, а там ОЗУ всего 128 кБ.
А на эту плату еще печатку не сделал, да и детали только заказал, будут не раньше 1-2 недель.
Микросхемы MSM82C51A-2RS 9-14 банк. дн.
Микросхемы TL16C550CN 9-14 банк. дн.
Кварцы 7.372 МГц (HCMOS/TTL) 7 банк. дн.
Микросхемы MAX232N
Микросхемы MC146818AP
Микросхемы КР512ВИ1
Кварцы Кварц 7.3728 МГц HC-49U
Микросхема КР1533ИД3
Без проблем. Добавил в архив SDK файл sdk.odi
P.S. пока нет возможности закидывать файлы напрямую в Орион через порт, можно действительно это делать через образы дискет. А закидывать файлы в образы можно с помощью эмулятора. Правда, предварительно их придётся закинуть в эмулятор с помощью.. эмулятора СОМ-порта %))
Сборка эмулятора тут - http://denn.ru/8bit/emu_b2m/emu.rar
Там в папке "emu\Orion\ODI\" есть образ чистой отформатированной дискеты - "~empty.odi", я обычно копирую этот файл в новый целевой, затем открываю его в эмуляторе и работаю с диском "С:" как обычно на Орионе (виртуальном), в результате содержимое файла образа наполняется необходимой информацией.
Мини отчёт, вести с полей так сказать.
Наконец-то, дошли руки до жёстких дисков. Разработан оптимизированный под 8-битные реалии формат хранения данных, написана утилита форматирования диска и драйвер под ОС DSDOS.
Вариант подключения по схемотехнике от ОРИОН-ПРО (карта IDE-RTC, как я понимаю - калька с "вражеского" NEMO_IDE).
Скорость работы порадовала безумно! Файлы летают со скоростью самолёта :) Вот небольшой наколенный ролик:
https://www.youtube.com/watch?v=O20_Nf4t69Y
Пилотная версия драйвера пока не поддерживает подкаталоги, впоследствии данный функционал будет добавлен.
Утилита форматирования выполняет разметку с учётом будущего расширения функционала драйвера. Поддерживаются накопители от 16 Мб до 1 Тб! Однако нижний предел теоретический.. Дело в том, что работа с НЖМД организована строго в режиме LBA, который, судя по информации из интернетов, поддерживают только накопители от 512 Мб и выше.
Организация информации на диске следующая. Традиционно, ОС DSDOS ничего не "знает" о больших носителях и подкаталогах, она работает с текущим диском, максимальное количество файлов на котором - 255, соответственно суммарный (теоретический) объём не более 16 Мб.
В случае больших носителей вводится понятие подкаталога (диск в диске), т.о. в основном (корневом каталоге) может быть до 255 подкаталогов (на самом деле 254 из-за особенностей устройства FAT DSFS). Подкаталог представляет собой 16-мегабайтный сегмент общего пространства. Т.о. суммарно корневой каталог + 254 подкаталога займут 16 Мб х 256 = 4096 Мб = 4 Гб. Для возможности использования ещё большего пространства используется второй уровень виртуализации - каждый подкаталог также может содержать подкаталоги. Т.о. возможно использование до 4 Гб х 256 = 1024 Гб = 1 Тб дискового пространства.
В результате имеем следующее. Если объём диска менее 4 Гб, то доступен корневой каталог и некоторое кол-во (в зависимости от объёма) подкаталогов первого уровня, если объём диска ровно 4 Гб, то доступно максимальное кол-во подкаталогов - 254. Если объём диска равен 8 Гб, то доступен корневой каталог + 254 подкаталога + по одному подкаталогу второго уровня в каждом подкаталоге первого уровня. И так далее: каждые 4 Гб добавляют ещё один "слой" подкаталогов второго уровня.
Организация достаточно мудрёная, однако её поддержка использует минимум ресурсов ПРК и при этом скорость работы чрезвычайно быстрая!
Аналогично будет сделана поддержка карт SDHC в ОС DSDOS. В следующей версии ОС поддержка больших накопителей будет включена.
А Compact Flash разве не все в режиме LBA работают? А то у мня валяются парочка на 128Мб...
Не могу сказать, всё многообразие накопителей в мире не изучал. Ранее выкладывал утилиту, которая расскажет всю правду о накопителе, в т.ч. и про поддержку LBA. Также можно "пробить" в гугле ТТХ своего диска.
Утилита форматирования проверяет факт поддержки режима LBA, и в случае её отсутствия, выдаст соответствующую ошибку.