Проблемы с чтением CF через int13h на некоторых старых BIOS

Описания, советы, ремонт, эксплуатация старых IBM PC-совместимых ПК
Forza3dfx
Advanced Member
Сообщения: 682
Зарегистрирован: 01.03.2015,08:51

Вклад в сообщество

Проблемы с чтением CF через int13h на некоторых старых BIOS

Сообщение Forza3dfx » 28.07.2020,12:45

wbcbz7 писал(а):
27.07.2020,22:38
кстати, подобное откусывание как раз используется для размещения расширенной области данных BIOS (EBDA), поэтому здесь нет ничего нелегального :)
Ну так опция "Scratch RAM option" и предлагает выбор :

1 - Using BIOS stack area at 0030:0000
2 - Reducing base memory size by 1 kb

На моем 286-ом с AMI D286 биос-ом от 90-го года так, конечно это легально))
i8088 писал(а):
28.07.2020,08:33
Ну так это и требуется, DOS примет обработчик int13h, размещенный в "защищенном месте" под
границей 1KB от стандартной памяти, не подозревая, что он модифицирован, и может делать с ним
что требуется.
Это то да, я имел ввиду что при последующем переносе кода в HMA с освобождением откушенного килобайта возникнет
необходимость корректировки значения вектора INT 13h, которое сохранил DOS и по которому он будет передавать управление
дальше (типа в БИОС, но на самом деле в обработчик в откушенном килобайте). Обработчик в бывшем откушенном и теперь
освобожденном килобайте будет затерт транзитной частью command.com или другой программой и на этом все, придется
жать "Reset". Скорректировать это значение можно, оно сохраняется в сегменте 0070, на другое которое уже будет указывать
на обработчик в HMA, но это опять же лишний доп.код.
i8088 писал(а):
28.07.2020,08:33
А кстати, для чего вообще DOS перехватывает int13h?
Обработчик находится в io.sys / ibmbio.com, делает кучу каких-то внутренних проверок и передает управление дальше.
Даже не знаю стоит ли с ним копаться, лучше получить так или иначе оригинальный вектор биос-а и работать с ним
в обход всего.
i8088 писал(а):
28.07.2020,08:33
Я думаю, не стоит тогда заниматься перемещением, тем более,
что многие системы, для которых актуальна проблема CF бага, не имеют расширенной памяти.
Да, полностью поддерживаю.

Передо мной встала подобная дилемма, когда давно-давно делал программку для загрузки с дисковода B:
Маленький код, уместившийся в boot-сектор, но уменьшающий базовую память на 1кб таким вот способом,
или городить схему перемещения ради освобожения этого килобайта, к тому же этот доп.код еще надо было размещать
в других секторах на дискете, так как boot-сектор не резиновый, и еще добавлять в boot-сектор доп.доп.код, чтобы
считывать тот первый доп.код )) В общем, в данном случае первый простой вариант оказался гораздо лучше.

i8088
Advanced Member
Сообщения: 3057
Зарегистрирован: 30.01.2015,17:06
Откуда: г. Баку, Азербайджан

Конкурсы

Вклад в сообщество

Проблемы с чтением CF через int13h на некоторых старых BIOS

Сообщение i8088 » 29.07.2020,07:57

Forza3dfx писал(а):
28.07.2020,12:45
Это то да, я имел ввиду что при последующем переносе кода в HMA с освобождением откушенного килобайта возникнет
необходимость корректировки значения вектора INT 13h, которое сохранил DOS и по которому он будет передавать управление
дальше (типа в БИОС, но на самом деле в обработчик в откушенном килобайте). Обработчик в бывшем откушенном и теперь
освобожденном килобайте будет затерт транзитной частью command.com или другой программой и на этом все, придется
жать "Reset". Скорректировать это значение можно, оно сохраняется в сегменте 0070, на другое которое уже будет указывать
на обработчик в HMA, но это опять же лишний доп.код.
Теперь понял, спасибо! Теперь уже однозначно, перемещать ничего не стоит.
Forza3dfx писал(а):
28.07.2020,12:45
Обработчик находится в io.sys / ibmbio.com, делает кучу каких-то внутренних проверок и передает управление дальше.
Даже не знаю стоит ли с ним копаться, лучше получить так или иначе оригинальный вектор биос-а и работать с ним
в обход всего.
Ну да, оригинальный я нашел дизассемблированием, да и код в boot-sector получит именно его.

Gleb
Member
Сообщения: 165
Зарегистрирован: 30.10.2016,20:46
Откуда: Прага

Проблемы с чтением CF через int13h на некоторых старых BIOS

Сообщение Gleb » 29.07.2020,13:52

i8088 писал(а):
28.07.2020,08:33
А кстати, для чего вообще DOS перехватывает int13h?
Как минимум для буферизации на старых системах, где установлены диски с низким числом секторов на дорожку, и для чтения большого количества секторов за один вызов int13h, нужно переключать не только головки, но и цилиндры. БИОС этого не делал.

А после подмены вектоа ДОСом становится возможным считывать большее количество секторов за раз (до 127 [7Fh]).
И если при написании собственного обработчика int13h исключить из цепочки этот обработчик DOS, а передавать прямо в оригинальный БИОС-овский int13h, то можно столкнуться с ситуацией, когда маленькие файлы читаются, а большие нет.
Столкнулся с этим на XT с классическим 17-ти секторным MFM диском.
В более современных системах это возможно иррелевантно, не проверял.

Еще стоит учитывать, что при вызове int19h (перезагрузка) DOS восстанавливает вектора (в частности и int13) на запомненный ею при собственной загрузке вектор, что может нарушить цепочку вызовов и в некоторых случаях привести к зависанию при нажатии Ctrl-Alt-Del. Тогда нужно самому перехватвать int19h и восстанавливать свои изменения, потом передавать управление дальше по цепочке.

===

При желании можно обойтись без модификации загрузочного сектора.
Но ценой "теплой" перезагрузки без очитски памяти.
ДОС (как минимум 3.30, 6.20 и 6.22) вызывет int12h еще до начала дисковых операций, поэтому достаточно у себя в приложении (желательно чтобы оно грузилось первым) подменить int12h, перегрузиться без очистки памяти, сделать в подмененном int12h свои дела (то, что делаете в загрузочном секторе), восстановить int12h и продолжить.
Я эту схему использовал на практике в некоторых приложениях.

Аватара пользователя
Rio444
Почётный пользователь
Сообщения: 12813
Зарегистрирован: 14.09.2014,19:11
Откуда: Ростов-на-Дону

Вклад в сообщество

Проблемы с чтением CF через int13h на некоторых старых BIOS

Сообщение Rio444 » 29.07.2020,13:57

Gleb писал(а):
29.07.2020,13:52
ДОС (как минимум 3.30, 6.20 и 6.22) вызывет int12h еще до начала дисковых операций, поэтому достаточно у себя в приложении (желательно чтобы оно грузилось первым) подменить int12h, перегрузиться без очистки памяти, сделать в подмененном int12h свои дела (то, что делаете в загрузочном секторе), восстановить int12h и продолжить.
Я эту схему использовал на практике в некоторых приложениях.
Очень интересный вариант. :thumbup:
Но откуда взять код, если работа с HDD ещё невозможна?
Email для связи Изображение

Gleb
Member
Сообщения: 165
Зарегистрирован: 30.10.2016,20:46
Откуда: Прага

Проблемы с чтением CF через int13h на некоторых старых BIOS

Сообщение Gleb » 29.07.2020,14:13

Я возможно не все прочел внимательно - но где код возьмете Вы ?
Неужели он так мал, что его весь можно добавить в загрузочный сектор ?

Возможно мне нужно перечитать всю тему, я зацепился именно за вопрос зачем ДОС перехватывает in13h и вспомнил свой опыт.
В частности делал так поддержку HDD на ЕС1840, у которой в БИОС нет соответствующей поддержки. Первая загрузка к сожалению с дискеты, потом уже благодать :-)

Аватара пользователя
Rio444
Почётный пользователь
Сообщения: 12813
Зарегистрирован: 14.09.2014,19:11
Откуда: Ростов-на-Дону

Вклад в сообщество

Проблемы с чтением CF через int13h на некоторых старых BIOS

Сообщение Rio444 » 29.07.2020,14:26

Gleb писал(а):
29.07.2020,14:13
Я возможно не все прочел внимательно - но где код возьмете Вы ?
Неужели он так мал, что его весь можно добавить в загрузочный сектор ?
Автор - i8088, вот что он писал:
i8088 писал(а):
26.07.2020,08:57
У меня такой, пока что теоретический вопрос - будет ли интересно чисто программное
решение для DOS (когда сложно прошить и модифицировать BIOS), для исправления
CF бага? Но ценой потери 1KB стандартной памяти и модификации загрузочного сектора.
Видимо код действительно очень мал.
Gleb писал(а):
29.07.2020,14:13
Первая загрузка к сожалению с дискеты, потом уже благодать :-)
Теперь понятно :thumbup:
Email для связи Изображение

Forza3dfx
Advanced Member
Сообщения: 682
Зарегистрирован: 01.03.2015,08:51

Вклад в сообщество

Проблемы с чтением CF через int13h на некоторых старых BIOS

Сообщение Forza3dfx » 29.07.2020,18:25

Gleb писал(а):
29.07.2020,13:52
Еще стоит учитывать, что при вызове int19h (перезагрузка) DOS восстанавливает вектора (в частности и int13) на запомненный ею при собственной загрузке вектор, что может нарушить цепочку вызовов и в некоторых случаях привести к зависанию при нажатии Ctrl-Alt-Del. Тогда нужно самому перехватвать int19h и восстанавливать свои изменения, потом передавать управление дальше по цепочке.
Нажатие Ctrl-Alt-Del для реального режима я отрабатывал самостоятельно, схема такая - стартуем из MBR, переносим код куда
надо (скажем, в отрезанный 1 кб или более по необходимости), устанавливаем нужные вектора прерываний на наши обработчики,
в т.ч. INT 09h (клавиатура), сохраняем таблицу векторов в таком виде хотя бы в том же отрезанном блоке (достаточно и первой
половины - 512 байт), в обработчике 09h тестируем нажатия и если обнаружен Ctrl-Alt-Del то восстанавливаем таблицу векторов
из загашника, при этом область данных BIOS в сегменте 0040 остается нетронутой, в т.ч. и уменьшенное значение базовой памяти,
далее производим попытку считывания бут-сектора дискеты в A: , если там пусто то считываем оригинальный MBR (желательно
сохранить его при инсталляции где-нибудь на нулевой дорожке, например), DOS загружается как обычно и наш код уже все
что нужно держит под контролем. При этом сам процесс перезагрузки очень быстрый, что-то аналогичное делает QuickBoot из
пакета QEMM.

Gleb
Member
Сообщения: 165
Зарегистрирован: 30.10.2016,20:46
Откуда: Прага

Проблемы с чтением CF через int13h на некоторых старых BIOS

Сообщение Gleb » 29.07.2020,18:55

Хороший вариант. :thumbup:
Но модификация MBR/Boot не всегда приемлема, поэтому я выкручивался по своему :-)

i8088
Advanced Member
Сообщения: 3057
Зарегистрирован: 30.01.2015,17:06
Откуда: г. Баку, Азербайджан

Конкурсы

Вклад в сообщество

Проблемы с чтением CF через int13h на некоторых старых BIOS

Сообщение i8088 » 30.07.2020,08:15

Всем спасибо за комментарии, очень полезно!
Gleb писал(а):
29.07.2020,14:13
Я возможно не все прочел внимательно - но где код возьмете Вы ?
Неужели он так мал, что его весь можно добавить в загрузочный сектор ?
Между MBR и первым сектором логического диска есть как минимум 16 секторов (размер дорожки
минус MBR, что более чем достаточно). Я сделал пока для отладки резидент на int13h, он получился
размером 811 байт. Его надо еще доработать, есть некоторые проблемы, но CF с ним сразу заработали.
Код обработчика команды чтения представляет собой в основном вычищенный обработчик int13h из
дизассемблированного AMI BIOS, оставлена только команда чтения для HDD, все остальное
направляется в старый обработчик.
Gleb писал(а):
29.07.2020,13:52
Как минимум для буферизации на старых системах, где установлены диски с низким числом секторов на дорожку, и для чтения большого количества секторов за один вызов int13h, нужно переключать не только головки, но и цилиндры. БИОС этого не делал.

А после подмены вектоа ДОСом становится возможным считывать большее количество секторов за раз (до 127 [7Fh]).
И если при написании собственного обработчика int13h исключить из цепочки этот обработчик DOS, а передавать прямо в оригинальный БИОС-овский int13h, то можно столкнуться с ситуацией, когда маленькие файлы читаются, а большие нет.
Столкнулся с этим на XT с классическим 17-ти секторным MFM диском.
В более современных системах это возможно иррелевантно, не проверял.
Спасибо, я не знал этого! На этом BIOS, если не изменяет память, как минимум 64 сектора прочесть
точно можно, я проверял, но подзабыл.
Rio444 писал(а):
29.07.2020,13:57
Но откуда взять код, если работа с HDD ещё невозможна?
Да, именно в этом проблема, DOS не может загрузить IBMBIO.COM. До обработки config.sys не доходит,
а то можно было бы сделать драйвер, что проще было бы.

i8088
Advanced Member
Сообщения: 3057
Зарегистрирован: 30.01.2015,17:06
Откуда: г. Баку, Азербайджан

Конкурсы

Вклад в сообщество

Проблемы с чтением CF через int13h на некоторых старых BIOS

Сообщение i8088 » 30.07.2020,08:28

У меня еще один теоретический вопрос, немного не по теме. На основе этих разработок можно будет
при желании сделать драйвер для secondary IDE, тк POWER IDE требует 386. Обычно такие драйверы
оформляются как sys, или псевдо-exe, которые из config.sys стартуют (как EMM386), чтобы расширение
int13h подключилось на раннем этапе, и дос распознал диски.

А как делается, чтобы DOS распознал диски, после установки расширения int13h из обычной резидентной программы?

Gleb
Member
Сообщения: 165
Зарегистрирован: 30.10.2016,20:46
Откуда: Прага

Проблемы с чтением CF через int13h на некоторых старых BIOS

Сообщение Gleb » 30.07.2020,12:13

Очень давно делал это путем встраивания нового элемента во внутреннюю структуру DOS.
Адрес ее получал через недокументированный вызов 52h (Get List of Lists).
Это решение зависело от версии DOS, нужно было держать таблицу смещений для разных версий.

Подключение на раннем этапе из config.sys тоже имело какие-то проблемы, уже не вспомню что именно.

То есть все это работало в стабильной системе, но изменение конфигурации, не говоря о установке другой версии DOS могло привести к необходимости доработок приложения.

Поэтому я отказался от добавления новых дисков из резидентов и драйверов и стал это делать через "мягкую" перезагрузку DOS после установки своего вектора, как описал выше с использованием int12h.
В этом случае DOS обнаруживал новый диск врожденным способом, при "второй" загрузке, и работал с ним абсолютно без проблем.

Вроде как начиная с версии DOS 5.0 и выше появилась возможность делать это через какой-то новый вызов int21h, но я с этим уже не разбирался, продолжал работать по своему методу.

Возможно более продвинутые коллеги поправят.

Ответить