Вряд ли в этом есть необходимость, похоже этот фрагмент работает правильноЦитата:
Сообщение от b2m
Вид для печати
Вряд ли в этом есть необходимость, похоже этот фрагмент работает правильноЦитата:
Сообщение от b2m
Блин, опять поднял волну зазря :)
- - - Добавлено - - -
Вот не хотел я в вашем мдосе копаться, но раз уж назвался груздем...
Проблема тут:
Задаём диск 2В. Исходный номер сектора 0101E6h, делим на 120h (18*16 секторов на дорожке). Процедура L_D8F3 делит 16-битное на 16-битное с остатком. Потом двигаем остаток на 8-бит и берём младшие 8 бит, и снова делим на 16-бит.Код:MOV H, A ; (HL,E) = (A,HL)
POP B ; для подчистки стека, загружаем временно в BC
CALL L_D9D9 ; проверка готовности НЖМД, получение кода ошибки и RET
PUSH B ; возвращаем BC в стек
ANI 0C0h ; 1110 0000
CPI 040h ; 0100 0000 устройство готово к операции
RNZ ; выход, если не готово
DI ; запрет прерываний на время установки параметров
PUSH D
CALL L_D8F3 ; расчёт номера цилиндра = 00h
OUT 055h ; Цилиндр, младшие биты номера цилиндра
POP D
MOV H, L
MOV L, E
CALL L_D8F3 ; расчёт номера цилиндра = 00h
OUT 054h ; Цилиндр, старшие биты номера цилиндра
Проблема только в том, что остаток 16-битный.
О способе деления я умолчу, он тут работает как задумывалось. Но это тоже мрак.
- - - Добавлено - - -
Получается, выражение "секторов*головок" должно быть <256
Не успел. Только я все же хотел впихнуть нормальную процедуру деления 24/16 (быстро нашлась 32/16, поэтому ее), т.к. сейчас эта комбинация делит неправильно. Просто так впихнуть не получается, надо разбираться, где свободное место, уверен, что Improver легко поправит, он знает где там запас.
Я думаю, если выкинуть все эти "патчи" для старой процедуры деления, то место появится.
- - - Добавлено - - -
По-моему, можно даже обойтись процедурой 24/8, первый раз делим на кол-во секторов (остаток - номер сектора-1), второй раз на количество головок (остаток номер головки). Частное (16-битное) - номер цилиндра.
- - - Добавлено - - -
Тогда будет ограничение "цилиндров*головок"<65536 (это если частное 16-битное).
- - - Добавлено - - -
Деление 24/8
По-моему - оптимально.Код:MVI C,16 ; HL=AHL/B, A=AHL%B
L1: DAD H
ADC A
JC L2
CMP B
JC L3
L2: SUB B
INR L
L3: DCR C
JNZ L1
RET
Сегодня котелок уже не варит, сделал тупо (с делением 24/16 через процедуру 32/16), ну и там еще потупил. Исходник этого сна разума не выкладываю, но бинарник вроде заработал правильно, пусть будет.
ivagor поскромничал выложить исходники... ;) Попробую сам поправить в Т-72 драйвер на основе кода 24/8 от b2m. Но, с другой стороны, общественный разум опять победил! На этот раз многолетнюю проблему глюка с жёсткими дисками.
P.S. Кстати, появилась идея перевести обращение к диску на LBA, для этого, по сути, будет достаточно дополнить номер сектора с 24 до 28 бит нулями. Это избавит от всех вычислений, привязки к количеству цилиндров/головок/секторов диска и т.п., но только пока не известно, как поведут себя разнообразные CF-карты, комбодевайсы и поддерживают ли эмуляторы Вектора режим LBA для жёстких дисков...
Сделал по заветам b2ma, убрал много лишнего. К этому варианту уже не стыдно приложить исходники, вернее только измененные файлы. Improver, b2m, спасибо!
- - - Добавлено - - -
Забыл спросить один момент. Регистры 55h и 54h - в досах в 54h пишут младший байт, в 55 - старший, в памятке Tim0xи написано наоборот. Если бы оба были по 8 бит, то без разницы, но разрядность старшего меньше, или это только для старых hdd важно а в новых и старший 8 бит?
Я сначала опирался на инфу с базиса из HDD.TXT, и свои комментарии в исходниках ставил по ней, но там скорее всего опечатка, в порт 055h пишутся старшие биты, а в 054h -- младшие.Цитата:
Сообщение от ivagor
Можно я поворчу. Процедуру деления я бы на место старой поместил (у тебя лишний jmp), столь короткие метки не стал бы использовать.Цитата:
Сообщение от ivagor
А так - да, всё как я и полагал.
- - - Добавлено - - -
И да, цикл чтения/записи сектора я бы разделил. Какой смысл каждые 2 байта анализировать чтение нужно или запись? Ускорение будет 5-10%.
jmp несомненно лишний, я даже убирал оттуда процедуру, но в процессе поиска ошибки (надо было раскомментить mvi d,0) грешил на размещение процедуры, вернул ее под jmp и забыл вернуть обратно. Метки короткие, да нехорошо. Можно даже внутри процедуры все сделать без меток, c $+-. Больше я трогать не буду, лучше Improver доработает (если захочет). Но если еще есть загадки/ошибки, то я всегда готов (если только не очень сложные :) ).
Насчет 55 и 54 похоже действительно опечатка в описании. C ВУ приходит инверсный адрес, они его инвертируют и подают на IDE.
Я исполнил то, о чём ворчал b2m, удалил лишнее, плюс ещё развернул ненужный уже вызов подпрограммы и собрал все исходники в один архив: Вложение 72087
В остальном это вариант ivagor-а.
И не стоит забывать, что в этой версии есть ограничение:
- - - Добавлено - - -Цитата:
Сообщение от b2m
В последней версии разделил, для проверки. Прирост в скорости копирования файлов с одной дискеты НЖМД на другую примерно 5%, но это с учётом того, что сейчас расчёт цилиндра/головки/сектора выполняется по новому алгоритму.Цитата:
Сообщение от b2m
Насчет ограничения (цилиндров*головок)<65536. Как я понимаю, максимальный возможный размер в этом случае 4095*16*63*512=2113413120 байт, т.е. >2 Гб. Если понадобится 8 гигов, то можно процедуру деления и апгрейдить, вопрос в востребованности.
Не останавливаемся на достигнутом. :)
Новая версия, Т-72hl, теперь обращение к диску выполняется в режиме LBA: Вложение 72088
Ограничение по размеру диска составляет 8Гб (используются 24 бита, 25..28 -- нули), все остальные ограничения снялись сами собой, единственное, что читается из конфигурации НЖМД -- это максимальное количество дискет. Проверил в эмуляторе, работает с разными дисками корректно, причём скорость возросла ещё примерно на 5%, но вот только на реале проверить не успел, поэтому пока пользуйтесь с долей осторожности...
Запись сектора сейчас требует 92 такта/каждые 2 байта, можно сократить до 84, признак чтения/записи в E вроде не нужно сохранять
Скрытый текст
Код:L_D8CF:
mov e,m
inx h
mov a,m
out 58h
mov a,e
out 50h
inx h
dcr d
jnz L_D8CF
[свернуть]
- - - Добавлено - - -
Познавательный вопрос - винты и CF могут читать по 255 секторов или только по 1?
Ну... Два сектора подряд читают (и пишут) без проблем, больше не пробовал. Подозреваю, что есть желание читать сразу весь файл в память? ;)Цитата:
Сообщение от ivagor
- - - Добавлено - - -
Кстати, а что если в 25..28 битах использовать не нули? Тогда же можно будет разбивать физический диск на логические, до 16 штук, и переключать их, граница будет в 120Гб, если не ошибаюсь... Или подвинуть используемую Вектором область в конец жёсткого диска, а в начале сделать стандартный раздел для ПК... В общем, тут тоже есть скрытые возможности.Цитата:
Сообщение от Improver
Если максимально развернуть чтение сектора, то чтение байта с записью в память стремится к 28 тактам, пусть с минимальными накладными расходами (раз уж LBA) будет 32. Тогда можно стримить видео без компрессии с винта. При 25 кадрах/секунду успеваем прочитать до 3744 байт, если использовать двойную буферизацию и читать прямо в видеопамять, то это и будет доступный размер кадра. Как использовать - возможны варианты, например при 8 цветах (или оттенках) можно играть в окошке 112x88, при 2 цветах - 192x152. Минута такого видео - примерно 5 Мб.
- - - Добавлено - - -
Чтение, конечно, мимо доса, сугубо "свое".
Вот сдвинуть образ на CF-карте было бы очень полезно.Цитата:
Сообщение от Improver
Сначала рассчитать размер, и записать на CF-карту "пустой" файл, а за ним всегда будет образ диска для Вектора.
Тогда без заморочек образ можно писать/читать на ПК и без плясок с бубном.
Кстати смещение, может быть заложено в ДОС установкой нужного (25...28) бита в "1".
Упс... CF-карточки обычно не больше 8Г. У меня самая крутая 256М :(
Использовать старшие биты LBA для смещения можно, но как показывает пример KTSerg неудобно. Но это не помеха введению смещения, сейчас оно "жесткое", а можно сделать настраиваемым (пусть даже в рамках 24 бит).
Ещё один вариант использования смещения: при должном умении, на диске или карте, отформатированной в FAT, можно создать файл, а МДОС с Вектора будет писать точно в эту область. А на ПК этот файл можно использовать, как образ в эмуляторе, единственное, нужно будет следить, чтобы файл физически оставался на тех же секторах диска/карты.
А вот смещение не кратное 8Гб сделать будет немного сложнее, но вполне осуществимо -- нужно просто поправить константы в подпрограмме команды "9", и она будет выдавать увеличенные на нужный размер значения. Ну ещё и доступ к конфигурации диска в нулевой сектор тоже как-то сместить...
- - - Добавлено - - -
Упс... Это та же идея, что и у меня, или "за ним" обозначает немного другой метод?Цитата:
Сообщение от KTSerg
А смещение пусть загрузчик рассчитывает, с учётом того, что карта/винт отформатирована FAT. Этот код может быть каким угодно большим, он же не будет перемещаться по нужным адресам. Можно даже имя файла запросить/выбрать, если таких образов на карте/винте несколько (в корневой директории). Можно даже наличие таблицы разделов учесть. Часть такого кода можно взять из моей читалки SDOS, которую PVV развивает. Сначала устанавливаем смещение 0, затем вычисляем и устанавливаем смещение нужного раздела (если есть таблица разделов), и под конец - смещение нужного файла.Цитата:
Сообщение от ivagor
- - - Добавлено - - -
Просто добавь воды:Цитата:
Сообщение от Improver
после получения 24-битного номера в A,HLКод:LXI D,xxxx
DAD D
ACI yy
Хороший вариант, если не для современного винта, а для старого (сравнительно небольшого) или для CF, то твоя реализация FAT16 хорошо подходит. Ну и надо, чтобы фрагментации образа hdd не было.Цитата:
Сообщение от b2m
Я предлагаю проще, изменять константу тут:Цитата:
Сообщение от b2m
И тогда не потребуется даже менять подпрограмму чтения/записи сектора... :)Код:LaD954: MOV A, E ; восстанавливаем номер диска
CALL LaD9B2 ; получаем ссылку на нужную таблицу
MOV M, C
INX H
MOV M, B
INX H ; запись в таблицу номера дискеты НЖМД
PUSH H ; сохр.в стек
LXI H, 0F3BEh ; = 2 - 0622h * 2
MVI A, 0FFh
INX B
LaD96A: LXI D, 00622h ; суммарное количество секторов на одной дискете
Чуть занудства - FFh в следующей строке тоже надо выделить
А также, чтобы он не был фрагментирован.Цитата:
Сообщение от Improver
- - - Добавлено - - -
От первых 2-х секторов тоже можно отказаться (если останется доступ LBA), количество флоппи-образов рассчитывается исходя из размера файла.Цитата:
Сообщение от Improver
На всякий случай ссылка на тему с текущими реинкарнациями FAT b2mа в развитом PVV виде. Работа с SD оттуда вряд ли понадобится, а FATную часть можно подсмотреть/позаимствовать.
- - - Добавлено - - -
Кстати, а как станет работать такая система с суперзагрузчиком в эмуляторе? Меня больше всего смущает фрагментация. Разве что позиционировать такую систему только для реала.
ПоясниЦитата:
Сообщение от ivagor
Правильный вопрос. Загрузчик не будет догадываться обо всех этих смещениях, либо его тоже надо будет обновлять...Цитата:
Сообщение от ivagor
Я пока не очень представляю, как это может быть организовано, но если внутрь эмулятора дать реальные параметры физического ПКшного диска, то может получиться нехорошо. И образ hdd наверняка будет фрагментирован (у меня точно) и вектор может накуролесить в ПКшном разделе и раздел современного диска вряд ли будет в FAT16. Как вариант - отдельный образ ПКшного диска с FAT16 и файлом с образом hdd внутри.Цитата:
Сообщение от b2m
- - - Добавлено - - -
Ну или компромисс - отдельный раздел FAT16, но это не очень удобно.
Не забудь про доступ к дорожкам 0-7 и псевдо-дорожке 255.Цитата:
Сообщение от Improver
- - - Добавлено - - -
Эмулятор не работает с физическими носителями, только файлы. Придётся копировать образ CF на ПК и обратно.Цитата:
Сообщение от ivagor
Либо учитывать в суперзагрузчике, что CF-карта не отформатирована под FAT и тогда в эмуляторе мдос будет работать по-старинке, без смещения. С указанием в конфиге образа (в старом формате) на CF-карте.
Хорошо, хотя к дорожкам 0-7 доступ нужен крайне редко, но можно это тоже поправить, изменив константу тут:Цитата:
Сообщение от b2m
А к 255 (или нулевому сектору) вообще доступ будет не обязателен, если задать максимальное количество дискет на диске каким-либо другим способом. Хотя и его расположение тоже правится изменением константы.Код:LDA L_E86D ; дорожка, = FFh при инициализации НЖМД (чтении 1-го сектора)
CPI 008h
JNC L_D85F ; переход если дорожка >= 08h (несистемная область)
LXI D, 00002h
XRA A
JMP L_D86C
А он вообще используется? Или мдос грузится из rom-диска?Цитата:
Сообщение от Improver
Если в ДОСе сделать смещение на размер FAT(выяснить, какой он максимальный для CF-карт большого размера) + не большой зазор. То к сожалению и загрузчики подправить нужно будет.
Хотя у меня например, загрузчик с HDD - не большая отдельная программка (адаптированный кусок загрузчика), т.к. на 02-ом до сих пор впаянный заводской загрузчик, в котором есссно нет загрузки с HDD.
А для работы с образом диска в эмуляторе, просто в начало образа нужно будет добавить пустой кусок (вместо FATа), компенсирующий смещение.
- - - Добавлено - - -
Имелось в виду, что если смещение по размеру больше FAT, то нужно сначала пустым файлом компенсировать размер смещения, и только потом записывать на CF-карту образ HDD.Цитата:
Сообщение от Improver
А фрагментация не возникнет, если карта исправна и на ней нет больше файлов.
Кстати в 90-ых пустыми файлами заполняли битые места на дискетах, при появлении на них не читаемых дорожек. Обзывали файлы типа "err001.err" и продолжали пользоваться дискетой.
svofski, у тебя в картотеке в разделе "розыск" есть mdos3.com (кваз 64Кб). Спасибо что добавил.
Это первый вариант доса, использующий только 64 Кб кваза, который я увидел. Скорее всего это тот самый mdos3. Файл из архива Фиронова?Цитата:
Сообщение от b2m
- - - Добавлено - - -
В эмуляторах теперь можно сделать настройку размера кваза 64/256.
- - - Добавлено - - -
Для любителей квазной экзотики дос CP/M 53 (из архива Фиронова). В архиве сам дос и сделал с ним загрузочный диск. Этот дос из серии CP/M 39, отличие в том, что использует всего 16 Кб из кваза, чтобы подменить часть видеопамяти и увеличить TPA (в описании CP/M 39 упомниается CP/M 57, это явно он с измененным названием, т.к. по адресам 1-2 значение E003h). Этот дос, как я понимаю, единственный, который мог работать с этим вариантом КНГМД (+миникваз) при установке в нем РУ6.
В эмуляторах можно сделать настройку размера кваза 16/64/256 Кб.
Дорожки 0-7 используются только загрузчиком в момент загрузки ОС из этой системной области, ну и ещё, например, sysgen-ом, если пользователь захочет обновить систему, в дальнейшей работе МДОС они значения не имеют. Тут ещё есть вариант, если делать сдвиг содержимого НЖМД, то можно оставить их и нулевой сектор на месте, для совместимости с загрузчиками, а перенести в файл только "область дискет".Цитата:
Сообщение от b2m
- - - Добавлено - - -
МДОС Т-72hl с этой поправкой: Вложение 72100Цитата:
Сообщение от ivagor
Протестил на Векторе, вроде проблем с диском нет (CF-карты тоже, говорят, нормально поддерживают режим LBA). Насколько возросла скорость записи не проверял, но с учётом того, что МДОС больше читает, чем пишет, не думаю, что эта доработка сильно увеличит работу с диском, но пусть лучше будет.
То, что LBAшный дос работает на реале - очень приятное известие.
Самая востребованная операция с записью в досе - вероятно копирование, но чтение, конечно, используется намного чаще. Ускорить чтение можно дозированным разворачиванием цикла. Текущий вариант - 38 тактов/байт, если развернуть в 2 раза, то будет 33 такта/байт, в 4 - 30.5 тактов/байт. Стоит ли ускорение небольшого разбухания кода - затрудняюсь сказать, в 2 раза наверно можно попробовать.
Внутри этого МДОСа есть такие строки:Цитата:
Сообщение от b2m
Код:* VECTOR-06C *
* BIOS V(3.1) *
ABC - DISK DRIVE
Код:??K MicroDOS Vers. 3.1
20.12.83
Edition by Shagalin O.A.
Volgograd - 1991
Похоже, тут автор известен. :)Код:poslednqq korrekciq 03.08.91g. - Shagalin O.A.
- - - Добавлено - - -
Может быть и стоит попробовать... Сейчас для этих экспериментов в БДОС есть свободных примерно 600 байт, но надо сначала вернуть работу с флопиками, чтобы было понятно, сколько там места остаётся для разворота.Цитата:
Сообщение от ivagor
Выразился не совсем корректно. Этот дос единственный известный, которому хватит кваза на РУ6 на том астраханском КНГМД. ДОСы не использующие кваз (МикроДОС 28 и CP/M 39) конечно тоже должны работать с тем КНГМД.Цитата:
Сообщение от ivagor
Я добавил http://sensi.org/scalar/ware/672/Цитата:
Сообщение от b2m
NB Вообще я совершенно запутался в этой теме. Количество микродосов и их вариантов мне не дано охватить. Даже старых многовато, а текущие разработки, которые оседают в аттачах и проваливаются на минус десятую страницу форума за два дня, и подавно. Принимаю корректировки, можно в личку.
Собственно МикроДОС везде один, версии 3.1, но у него разные БИОСы и адрес посадки (зависит от размера БИОСа). Это как ядро CP/M 2.0 - оно везде одинаковое, а БИОС (драйвер диска) адаптируется под конкретную платформу.Цитата:
Сообщение от svofski
У Вектора разные БИОСы поддерживают (в зависимости от версии):
- квазидиск (почти все), разные варианты квазидиска
- дисковод (большинство), 1 или 2 устройства
- винчестер, есть разные варианты с разным количеством логических дисков для монтирования флоппи-образа, например ABC (три) или ABCDE (пять)
- поддержка каких-то шрифтов (bold вариант)
- улучшенные драйверы вывода символа или клавиатуры
- - - Добавлено - - -
Есть ещё Т-72, там версия МикроДОСа 3.1М - вроде какую-то ошибку в самом микродосе исправили.