Других отличий от простого NemoIDE нету ?Цитата:
Сообщение от Blade
Вид для печати
Других отличий от простого NemoIDE нету ?Цитата:
Сообщение от Blade
Да, это имеет смысл.Цитата:
Сообщение от ZXMAK
А какой код в plm для обработки обращений к ide data портам у пентевы?Цитата:
Сообщение от Blade
Правильно! Самого подобные мысли посещали.Цитата:
Сообщение от Northwood
Еще CP/M нескольких модификаций (прожде всего в "Профи" и АТМ), варианты iS-DOS и TASiS. Каждая из этих систем использует свои несовместимые с FAT разделы (набор разделов), как правило небольших (8-16Мб каждый, хотя для TASiS нащупан путь увеличить размер разделов на порядки, но файловая система у него все равно останется "своя", с FAT несовместимая). Как правило, многие из этих систем используют те или иные сектора в начале винта (чаще всего дорожка 0) под свои конфигурационные записи. Насчет "Профи" не помню, пусть по нему соовтетствующие товарищи подключаются к дискуссии, а загрузчик классического iS-DOS (прошитый в ПЗУ) сканирует нулевой сектор каждого цилиндра от 0 до 255 в поисках загрузочной записи системы - где раньше найдет, оттуда загрузочную запись и читает. Загрузчик с винта, прошитый в ПЗУ ATM-turbo 2+ (через который грузится пока местный вариант iS-DOS/TASiS), читает загрузочную запись строго со второго сектора нулевого трека., а вот ATMовский вариант CP/M создает и читает оную строго с нулевого сектора, нулевого трека. Вроде бы этот нулевой сектор используется также и Профиком, SMUCом (точнее, поддержка им виртуальный дисков TRD). Это накладывает определенные ограничения на вольницу создания FAT-разделов (хотя бы потому, что стандартный MBR создается опять-таки строго в нулевом секторе), если, автор, конечно, не хочет наплевать на все наследие софта по работе с контроллерами винта разных производителей (я бы, например, не хотел, создавая разделы FAT, разрушить структуру разделов TASiS и CP/M), хотя, судя из упоминания в переписке готовности поддержать SMUC, не хочет.Цитата:
На данный момент на Спектруме с софтом для HDD дела обстоят очень плачевно:
WDC - копировщик, умеет работать только с одним первичным разделом. Такого понятия как "логические диски" на HDD в этой программе просто не существует.
Wild Player - проигрыватель, который умеет работать только с 1 первичным разделом и 1 логическим диском из расширенного раздела.
DNA-OS - умеет работать с 1 первичным разделом и до 4 логических дисков из расширенного раздела.
Частичный выход я вижу, правда без учета пока Профика, в связи с отсутствием информации по устройству загрузочной записи на оном., но тем не менее:
1. Делать поддержку как CHS, так и LBA, потому что сосуществующие на винте прочие системы могут быть в каком угодно варианте, и не факт, что можно перенести один вариант в другой. Например iS-DOS/TASiS на ATM умеет и CHS, и LBA, но евойная же CP/M умеет только CHS, поэтому и TASiS у меня тоже вынуждена сидеть на CHS ровно до того момента, когда я смогу найти столько времени, чтобы наконец-то покопаться в ПЗУ CP/M для переделки, загрузчик iS-DOS на прочих клонах умеет только CHS и т.д..
2. Предусмотреть возможность создавать не только FAT16/32-разделы, но и "пустые" разделы - т.е. выделять пустое пространство (инициализируя его в MBR именно как раздел), в котором можно размещать как раз "классические" разделы iS-DOS/TASiS, CP/M, SMUC и проч. В этом случае пользователь при желании может такой "пустой" раздел создать первым, в начале винта, и тогда многие "старые" ОСи, которые работают при загрузке с начальными треками, не будут портить FAT (тот же TASiS с его загрузчиков во втором секторе, а классический iS-DOS на других клонах, может создавать загрузчик, не в нулевом, а с кажем, в первом цилиндре).
3. Запись MBR в нулевом секторе создавать особым образом. Тут опять же, не могу сказать на Профик и Смук, но CP/M в ATM из 512 байт нулевого сектора использует (утилитой FDISK и другими инструментами) только первые 128 байт, тогда как "классический" MBR требует для себя из этих 512 байт только ПОСЛЕДНИЕ 64 байта. Т.е. информация CP/M и MBR не пересекаются, и это хорошо. Более того, при записи загрузочной информации в нулевой сектор, CP/M все байты, что выше 128 нужных байт, НЕ ЗАТИРАЕТ! Т.е. происзодит так: читается загрузочный сектор целиком, в первые 128 байт записывается инфа, и сектор записывается обратно. Создание MBR в твоем Partition MAGIC должно проходить также, без затирания прочей информации окромя последних 64 байт.
Таким образом, если Профинский CP/M и Смук не поставят перед разработчиком какие-то дополнительные условия, возможно будет сделать утилиту, максимально "толерантную" к прочему наследию спектрума по работе с HDD.
Кроме внутрисистемных под CP/M и iS-DOS, но они не универсальный, это да...Цитата:
И ни одной программы, которая бы умела размечать винчестеры на разделы и форматировать диски.
Фундамент под виртуальный памятник тебе я уже заложил! :)Цитата:
Решился засесть за написание программы, некого подобия Partition Magic на ПЦ.
Как я написал выше, надо предусмотреть возможность создавать "пустые" разделы и без инициализации в них FAT.Цитата:
Что предполагается сделать:
...
Возможность удалять и создавать первичные разделы, расширенный раздел и логические диски в нем.
+100500Цитата:
Возможность быстрого форматирования (без обнуления всех секторов) дисков в файловую систему FAT-16 и FAT-32, с возможностью выбора желаемого размера кластеров (выбор из списка, ограниченным в соответствии с выбранной файловой системой и размером раздела).
В TASiS стандартная TRDшка грузится с винта в RAM примерно за 3.5-4 секунды, итого мы имеем 160-180 Кб/сек, правда в турбе. При этом чтение идет по команде INIR.Цитата:
При необходимости, можно сделать и полное форматирование, но при размерах дисков 10...80 Гигабайт, на форматирование может уйти время от нескольких дней до несколько недель, т.к. скорость чтения и записи на Спектруме без турбо-режима выходит что-то около 50 Кбайт/сек. Считайте сами. На моём Пентагоне-1024 турбированном на 7 МГц без wait-а скорость выходит ровно в 2 раза выше - около 100 Кбайт/сек.
Как я попытался аргументировать своим скромным ИМХО, таки такая необходимость есть.Цитата:
Будет использоваться адресация LBA. Пока сомневаюсь, нужно ли поддерживать древние винчестеры, которые поддерживают только адресацию CHS.
Тут уже написали, что лучше предусмотреть возможность подключения внешнего драйвера на свой вкус в виде маленького кодового файлика фиксированной длины (2-3 сектора), "ложимого" сразу после основного тела программы и имеющими три стандартные точки входа:Цитата:
Программа работает с жёсткими дисками через контроллер Nemo-IDE.
1. Запись сектора (на входе координаты в CHS/LBA, плюс флаг выбора одного из двух этих режимов, на выходе возможный номер ршибки и сопутствующие данные (например, ошибка записи в битый сектор - номер трека/сектора)
2. Чтение сектора (вход и выход как и в п.1)
3. Инициализация винта, чтение служебной информации (например - конфигурация, номер, название производителя и проч.)
Информация по контроллеру ATM и пример драйвера здесь:
http://atmturbo.nedopc.com/inf/books...c/atm_hard.zip
Там можно и Профик, и АТМ тестировать.Цитата:
Теоретически её можно доработать и под SMUC, но за неимением такого контроллера у меня, не будет и возможности проверять её на работоспособность под SMUC. Хотя можно будет попробовать тестировать на Unreal Speccy.
А так, могу пожелать только удачи. Если нужна будет какая консультация или еще что, пиши. Что будет по силам, помогу...
Для Q-DOS по моей просьбе, ещё в 1998-м году, один мой товарищ написал fdisk. Почти полный аналог с дос6.22 по интерфейсу. Писал он его на Turbo-Pascal 6. Я надеялся потом его быстро доработать до возможности компиляции в TP3 на профи. Но не тут то было, везде юзается тип Longint, которого, как известно в TP3 нету. + ещё там кое что недописано в плане поиска свободного места на диске (fdisk в msdos не просто так откусывает очередной кусок от свободного места, производится ещё проверка поверхности). Недавно Sayman адаптировал другую утилиту для разбивки винта, первичный диск она создает, но и не более того. Забросил он. Форматтер FAT 12/16 я в январе/феврале почти дописал, но там не хватает опять же проверки на битые секторы (оставил на последний момент и пока забросил).
Вадим, ты по Профику специализируешься вроде? Не подскажешь, случаем, что и как CP/M творит на винте в плане загрузочных секторов и прочей конфигурации?Цитата:
Сообщение от Vadim
Если интересует МикроДОС+CBIOS5, то там несовместимые с ПЦ разделы, по 8метров. Как именно реализовано, сейчас сказать не могу, надо смотреть исходники. В моей системе разбиение изначально было совместимо с ПЦ.Цитата:
Сообщение от Максагор
Интересуют все системы (в т.ч. и CP/M), которые так или иначе работают с винтом на Профике, и прежде всего не размер и количество разделов, а расположение и содержание конфигурационных записей - насколько они будут мешать созданию стандартной MBR с описателями FAT-разделов...Цитата:
Сообщение от Vadim
Как в этом плане дело обстоит с CP/M и iS-DOS/TASiS на АТМке я выше описал....
Вадим, тут в соседней ветке прикручивали поддержку винта Profi к эмулятору ZXMAK2 и имеются вопросы по поводу совместимости винтов созданных на Профи с другими контроллерами, можешь проверить, прокоментировать?Цитата:
Сообщение от Vadim
Я понял. Думаю, что лучше иметь ввиду, что на Профи система разбиения совместима с ПЦ. У меня в планах сделать адаптацию и МикроДОС и ещё нескольких систем совместимых с CP/M к винту. Используя модифицированный драйвер от QDOS. Смысл в том, что и разделы диска будут ПЦ совместимые и никаких аналогов assign будет делать не надо. А то, как было сделано в 1994/1995гг в CBIOS5 - надо забыть как страшный сон.Цитата:
Сообщение от Максагор
Я посмотрю, отвечу.Цитата:
Сообщение от Дмитрий