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

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

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

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

Сообщение Rio444 » 26.07.2020,11:53

i8088, думаю вполне интересно.
А нельзя ли исхитриться и использовать не стандартную память, а, например, верхнюю?
Хотя, сдругой стороны, потеря 1Кб не так и велика. Разница в размерах разных драйверов мыши может быть гораздо больше.
Email для связи Изображение

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

Конкурсы

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

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

Сообщение i8088 » 26.07.2020,12:07

Rio444 писал(а):
26.07.2020,11:53
i8088, думаю вполне интересно.
А нельзя ли исхитриться и использовать не стандартную память, а, например, верхнюю?
Спасибо за ответ! Тут дело в том, что код в MBR работает до загрузки DOS, и зарезервировать память
для нового обработчика заранее вроде бы никак нельзя. Но при работе с проектом 286 autodetect, я
разбирался с опцией scratch RAM. Когда она 2, то BIOS уменьшает размер стандартной памяти на 1KB
(40h:13h и ячейки CMOS). И в зазоре между 639 и 640Kb (это если стандартная память 640, код BIOS просто
отнимает от известного размера памяти 1KB) и размещается HDPT. Физический доступ к этой памяти
конечно не нарушается, но если программа пользуется сервисами DOS для выделения памяти, то она
никогда туда не залезет. В верхней памяти я не знаю надежного способа ограничения. DOS сама по себе
может пользовать только HMA, но BIOS-ом ее размер не ограничить. Остальная память XMS работает
через драйверы, здесь еще хуже (в CMOS есть ее размер, но смотрят ли на него драйверы?). Меньше 1KB
тоже не сделать, тк гранулярность размера стандартной памяти в ячейке 40h:13h и в CMOS именно 1KB.
Последний раз редактировалось i8088 26.07.2020,12:12, всего редактировалось 1 раз.

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

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

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

Сообщение Rio444 » 26.07.2020,12:12

i8088 писал(а):
26.07.2020,12:07
я разбирался с опцией scratch RAM. Когда она 2, то BIOS уменьшает размер стандартной памяти на 1KB
(40h:13h и ячейки CMOS). И в зазоре между 639 и 640Kb (это если стандартная память 640, код BIOS просто
отнимает от известного размера памяти 1KB) и размещается HDPT.
Думаю это очень хороший способ. И надо сначала сделать именно так.
В дальнейшем можно будет подумать, чтобы как-то перенести куда-то этот килобайт. Например, запуском утилиты уже после старта DOS.
Сколько байт реально нужно?
Email для связи Изображение

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

Конкурсы

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

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

Сообщение i8088 » 26.07.2020,12:15

Rio444 писал(а):
26.07.2020,12:12
Например, запуском утилиты уже после старта DOS.
Сколько байт реально нужно?
А вот про перенос потом я не подумал, спасибо! Вектор прерывания должен быть доступен в real mode,
поэтому возможно использовать тоько HMA при открытом вентиле A20. Код нужно еще написать, но по
опыту работы с 286 autodetect, скорее всего около 800-900 байт и будет.
Последний раз редактировалось i8088 26.07.2020,12:41, всего редактировалось 1 раз.

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

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

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

Сообщение Rio444 » 26.07.2020,12:21

i8088 писал(а):
26.07.2020,12:15
скорее всего около 800-900байт и будет.
Тогда только в верхнюю, если получится. Если бы несколько байт, можно было бы попытаться всунуть в какую-нибудь из областей стандартной памяти.
Email для связи Изображение

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

Конкурсы

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

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

Сообщение i8088 » 26.07.2020,12:39

Rio444 писал(а):
26.07.2020,12:21
Тогда только в верхнюю, если получится. Если бы несколько байт, можно было бы попытаться всунуть в какую-нибудь из областей стандартной памяти.
Да, там код довольно объемистый, масса тайм-аутов, обработок ошибок, установок флагов в BDA.
Если делать только для одного конкретного BIOS, то многие процедуры можно пользовать из него,
но это очень уж неуниверсально, и легко наделать ошибок, определенно дело того не стоит.
Последний раз редактировалось i8088 04.08.2020,11:28, всего редактировалось 2 раза.

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

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

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

Сообщение Forza3dfx » 26.07.2020,20:22

На 386+ можно выделить блок в UMB (если есть) стандартными средсвами DOS и перенести туда.
Но на 286-ом UMB нет, для DOS 5.0+ можно в HMA (если HIMEM запущен и DOS=HIGH),
после загрузки DOS в HMA там остается свободных несколько килобайт даже для жирной 6.22.
Недокументированный интерфейс запроса и выделения можно посмотреть в TECHHELP -
прерывание INT 2Fh, функции 4A01h/4A02h.

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

Конкурсы

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

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

Сообщение i8088 » 27.07.2020,16:15

i8088 писал(а):
26.07.2020,12:39
Если делать только для одного конкретного BIOS, то многие процедуры можно пользовать из него,
но это очень уж неуниверсально, и легко наделать ошибок, определенно дело того не стоит.
Только сегодня сообразил - глупость написал:) Упомянутые процедуры в BIOS все
NEAR, а вызывать надо из другого сегмента.
Forza3dfx писал(а):
26.07.2020,20:22
На 386+ можно выделить блок в UMB (если есть) стандартными средсвами DOS и перенести туда.
Но на 286-ом UMB нет, для DOS 5.0+ можно в HMA (если HIMEM запущен и DOS=HIGH),
после загрузки DOS в HMA там остается свободных несколько килобайт даже для жирной 6.22.
Недокументированный интерфейс запроса и выделения можно посмотреть в TECHHELP -
прерывание INT 2Fh, функции 4A01h/4A02h.
Спасибо, пригодится! Если DOS=HIGH, то вентиль A20 все время открыт и можно гарантировать,
что он будет всегда открыт при запросе int13h? Ну, по крайней мере, если не запускались программы,
работающие с A20 напрямую, через 8042 или другим способом (порт 92h и подобное).

У меня еще вопрос встал - после восстановления размера памяти (в 40h:13h и CMOS), как заставить
DOS понять, что стандартной памяти больше стало?

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

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

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

Сообщение Forza3dfx » 27.07.2020,21:59

i8088 писал(а):
27.07.2020,16:15
Если DOS=HIGH, то вентиль A20 все время открыт и можно гарантировать,
что он будет всегда открыт при запросе int13h?
Вполне возможно. В тестовом режиме можно на это положиться, но если будут проблемы -
придется вставлять какую-то процедурку проверки. Да, корректная обработка ошибок и
непредвиденных ситуаций существенно увеличивает размер кода, особенно когда сам код
должен быть как можно меньше, но лучше предусмотреть максимум неприятностей заранее.
i8088 писал(а):
27.07.2020,16:15
после восстановления размера памяти (в 40h:13h и CMOS), как заставить
DOS понять, что стандартной памяти больше стало?
DOS при загрузке не считывает непосредственно значение по адресу по 0040:0013h, а пару раз
вызывает прерывание INT 12h, возможно сохраняет значение где-то в своем сегменте данных
(я не помню уже), первый MCB-блок строится уже с учетом отрезанной памяти. Может быть
поможет корректировка размера последнего в цепочке MCB-блока на 1 кб (в параграфах)
во время запуска утилиты переноса, т.е. блока памяти самой утилиты, т.к. при запуске ей будет
выделена все свободная память (но есть нюансы - некая запущенная до этого резидентная
программа может выделить себе блок прямо под верхней границей DOS и тогда отрезанный
1 кб окажется выше блока этой резидентной программы и восстанавливать его вообще нет смысла).

Тут еще такой момент... Если при старте из MBR перехватывать прерывание INT 13h, то потом
его перехватит сама DOS, а после еще возможно другие программы, и при перемещении текущего
обработчика в верхнюю память возникнет проблема "прохода по цепочке" прерывания INT 13h,
т.к. DOS запомнит адрес в отрезанном килобайте и будет передавать управление туда.

А вообще полагаю, что плата в "минус 1 кб от памяти BIOS" более чем приемлемая за получаемый
результат. Это, кстати, стандартная схема для подавляющего числа загрузочных вирусов, причем
многие откусывали и более 1 кб, ничего страшного, простейший способ в реализации и минимальный
размер кода, если укладывается в 1 кб.

Но если страдать перфекционизмом...)) то "накладные расходы" на размер доп.кода могут
существенно превысить размер самого полезного кода. Извращенная рабочая схема как из MBR
оказаться вполне себе легально в UMB (на 386+) вообще не трогая размер памяти BIOS и целевых векторов прерываний у меня найдется, конструировал аж четверть века назад)). Можно попробовать
задействовать ее по аналогии, чтобы попасть в HMA на 286-ом (но конкретно это я ранее не делал).

wbcbz7
Advanced Member
Сообщения: 331
Зарегистрирован: 17.02.2014,12:24
Откуда: omsk || nsk

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

Сообщение wbcbz7 » 27.07.2020,22:38

Forza3dfx писал(а):
27.07.2020,21:59
А вообще полагаю, что плата в "минус 1 кб от памяти BIOS" более чем приемлемая за получаемый
результат. Это, кстати, стандартная схема для подавляющего числа загрузочных вирусов, причем
многие откусывали и более 1 кб, ничего страшного, простейший способ в реализации и минимальный
размер кода, если укладывается в 1 кб.
кстати, подобное откусывание как раз используется для размещения расширенной области данных BIOS (EBDA), поэтому здесь нет ничего нелегального :)

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

Конкурсы

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

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

Сообщение i8088 » 28.07.2020,08:33

Forza3dfx, спасибо! Я думаю, не стоит тогда заниматься перемещением, тем более,
что многие системы, для которых актуальна проблема CF бага, не имеют расширенной памяти.
Forza3dfx писал(а):
27.07.2020,21:59
Тут еще такой момент... Если при старте из MBR перехватывать прерывание INT 13h, то потом
его перехватит сама DOS, а после еще возможно другие программы, и при перемещении текущего
обработчика в верхнюю память возникнет проблема "прохода по цепочке" прерывания INT 13h,
т.к. DOS запомнит адрес в отрезанном килобайте и будет передавать управление туда.
Ну так это и требуется, DOS примет обработчик int13h, размещенный в "защищенном месте" под
границей 1KB от стандартной памяти, не подозревая, что он модифицирован, и может делать с ним
что требуется. А кстати, для чего вообще DOS перехватывает int13h?

Я еще обратил внимание, что MS-DOS/PC-DOS перехватывают и обработчик IRQ14, а DR-DOS - нет.
wbcbz7 писал(а):
27.07.2020,22:38
кстати, подобное откусывание как раз используется для размещения расширенной области данных BIOS (EBDA), поэтому здесь нет ничего нелегального
Спасибо, очень полезно! Кстати смещения HDPT таблиц в этом BIOS как раз 3dh/4dh, а сегмент
меняется в зависимости от <scratch RAM option>

Ответить