Проблемы с чтением CF через int13h на некоторых старых BIOS
- Rio444
- Почётный пользователь
- Сообщения: 26861
- Зарегистрирован: 14.09.2014,19:11
- Откуда: Ростов-на-Дону
-
Вклад в сообщество
Проблемы с чтением CF через int13h на некоторых старых BIOS
i8088, думаю вполне интересно.
А нельзя ли исхитриться и использовать не стандартную память, а, например, верхнюю?
Хотя, сдругой стороны, потеря 1Кб не так и велика. Разница в размерах разных драйверов мыши может быть гораздо больше.
А нельзя ли исхитриться и использовать не стандартную память, а, например, верхнюю?
Хотя, сдругой стороны, потеря 1Кб не так и велика. Разница в размерах разных драйверов мыши может быть гораздо больше.
Электронка: копия
-
- Advanced Member
- Сообщения: 4383
- Зарегистрирован: 30.01.2015,17:06
- Откуда: г. Баку, Азербайджан
-
Конкурсы
Вклад в сообщество
Проблемы с чтением CF через int13h на некоторых старых BIOS
Спасибо за ответ! Тут дело в том, что код в 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
- Почётный пользователь
- Сообщения: 26861
- Зарегистрирован: 14.09.2014,19:11
- Откуда: Ростов-на-Дону
-
Вклад в сообщество
Проблемы с чтением CF через int13h на некоторых старых BIOS
Думаю это очень хороший способ. И надо сначала сделать именно так.
В дальнейшем можно будет подумать, чтобы как-то перенести куда-то этот килобайт. Например, запуском утилиты уже после старта DOS.
Сколько байт реально нужно?
Электронка: копия
-
- Advanced Member
- Сообщения: 4383
- Зарегистрирован: 30.01.2015,17:06
- Откуда: г. Баку, Азербайджан
-
Конкурсы
Вклад в сообщество
Проблемы с чтением CF через int13h на некоторых старых BIOS
А вот про перенос потом я не подумал, спасибо! Вектор прерывания должен быть доступен в real mode,
поэтому возможно использовать тоько HMA при открытом вентиле A20. Код нужно еще написать, но по
опыту работы с 286 autodetect, скорее всего около 800-900 байт и будет.
Последний раз редактировалось i8088 26.07.2020,12:41, всего редактировалось 1 раз.
- Rio444
- Почётный пользователь
- Сообщения: 26861
- Зарегистрирован: 14.09.2014,19:11
- Откуда: Ростов-на-Дону
-
Вклад в сообщество
Проблемы с чтением CF через int13h на некоторых старых BIOS
Тогда только в верхнюю, если получится. Если бы несколько байт, можно было бы попытаться всунуть в какую-нибудь из областей стандартной памяти.
Электронка: копия
-
- Advanced Member
- Сообщения: 4383
- Зарегистрирован: 30.01.2015,17:06
- Откуда: г. Баку, Азербайджан
-
Конкурсы
Вклад в сообщество
Проблемы с чтением CF через int13h на некоторых старых BIOS
Да, там код довольно объемистый, масса тайм-аутов, обработок ошибок, установок флагов в BDA.
Если делать только для одного конкретного BIOS, то многие процедуры можно пользовать из него,
но это очень уж неуниверсально, и легко наделать ошибок, определенно дело того не стоит.
Последний раз редактировалось i8088 04.08.2020,11:28, всего редактировалось 2 раза.
Проблемы с чтением CF через int13h на некоторых старых BIOS
На 386+ можно выделить блок в UMB (если есть) стандартными средсвами DOS и перенести туда.
Но на 286-ом UMB нет, для DOS 5.0+ можно в HMA (если HIMEM запущен и DOS=HIGH),
после загрузки DOS в HMA там остается свободных несколько килобайт даже для жирной 6.22.
Недокументированный интерфейс запроса и выделения можно посмотреть в TECHHELP -
прерывание INT 2Fh, функции 4A01h/4A02h.
Но на 286-ом UMB нет, для DOS 5.0+ можно в HMA (если HIMEM запущен и DOS=HIGH),
после загрузки DOS в HMA там остается свободных несколько килобайт даже для жирной 6.22.
Недокументированный интерфейс запроса и выделения можно посмотреть в TECHHELP -
прерывание INT 2Fh, функции 4A01h/4A02h.
-
- Advanced Member
- Сообщения: 4383
- Зарегистрирован: 30.01.2015,17:06
- Откуда: г. Баку, Азербайджан
-
Конкурсы
Вклад в сообщество
Проблемы с чтением CF через int13h на некоторых старых BIOS
Только сегодня сообразил - глупость написал:) Упомянутые процедуры в BIOS все
NEAR, а вызывать надо из другого сегмента.
Спасибо, пригодится! Если DOS=HIGH, то вентиль A20 все время открыт и можно гарантировать,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.
что он будет всегда открыт при запросе int13h? Ну, по крайней мере, если не запускались программы,
работающие с A20 напрямую, через 8042 или другим способом (порт 92h и подобное).
У меня еще вопрос встал - после восстановления размера памяти (в 40h:13h и CMOS), как заставить
DOS понять, что стандартной памяти больше стало?
Проблемы с чтением CF через int13h на некоторых старых BIOS
Вполне возможно. В тестовом режиме можно на это положиться, но если будут проблемы -
придется вставлять какую-то процедурку проверки. Да, корректная обработка ошибок и
непредвиденных ситуаций существенно увеличивает размер кода, особенно когда сам код
должен быть как можно меньше, но лучше предусмотреть максимум неприятностей заранее.
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-ом (но конкретно это я ранее не делал).
Проблемы с чтением CF через int13h на некоторых старых BIOS
кстати, подобное откусывание как раз используется для размещения расширенной области данных BIOS (EBDA), поэтому здесь нет ничего нелегальногоForza3dfx писал(а): ↑27.07.2020,21:59 А вообще полагаю, что плата в "минус 1 кб от памяти BIOS" более чем приемлемая за получаемый
результат. Это, кстати, стандартная схема для подавляющего числа загрузочных вирусов, причем
многие откусывали и более 1 кб, ничего страшного, простейший способ в реализации и минимальный
размер кода, если укладывается в 1 кб.
-
- Advanced Member
- Сообщения: 4383
- Зарегистрирован: 30.01.2015,17:06
- Откуда: г. Баку, Азербайджан
-
Конкурсы
Вклад в сообщество
Проблемы с чтением CF через int13h на некоторых старых BIOS
Forza3dfx, спасибо! Я думаю, не стоит тогда заниматься перемещением, тем более,
что многие системы, для которых актуальна проблема CF бага, не имеют расширенной памяти.
границей 1KB от стандартной памяти, не подозревая, что он модифицирован, и может делать с ним
что требуется. А кстати, для чего вообще DOS перехватывает int13h?
Я еще обратил внимание, что MS-DOS/PC-DOS перехватывают и обработчик IRQ14, а DR-DOS - нет.
меняется в зависимости от <scratch RAM option>
что многие системы, для которых актуальна проблема CF бага, не имеют расширенной памяти.
Ну так это и требуется, DOS примет обработчик int13h, размещенный в "защищенном месте" подForza3dfx писал(а): ↑27.07.2020,21:59 Тут еще такой момент... Если при старте из MBR перехватывать прерывание INT 13h, то потом
его перехватит сама DOS, а после еще возможно другие программы, и при перемещении текущего
обработчика в верхнюю память возникнет проблема "прохода по цепочке" прерывания INT 13h,
т.к. DOS запомнит адрес в отрезанном килобайте и будет передавать управление туда.
границей 1KB от стандартной памяти, не подозревая, что он модифицирован, и может делать с ним
что требуется. А кстати, для чего вообще DOS перехватывает int13h?
Я еще обратил внимание, что MS-DOS/PC-DOS перехватывают и обработчик IRQ14, а DR-DOS - нет.
Спасибо, очень полезно! Кстати смещения HDPT таблиц в этом BIOS как раз 3dh/4dh, а сегмент
меняется в зависимости от <scratch RAM option>