Вынос первого мегабайта.

Господа подскажите пожалуйста как вынести все из первого мегабайта или выключить (в плане микросхем). Известно что железо поддерживается ACPI. Хочу по максимуму освободить первый мегабайт.
Как например переназначить видеопамять в верхнюю память и активировать при этом отсутствующую память?

 

Там SMI прячиться так, что в видео память тебя просто так не пустят. Защита есть, но биосы ее не пользуют. Так что попытаться можно. Остальное тоже можно освободить изучай северный чипсет своей материнке.

 

Там куча регистров и в целом как решить вопрос непонятно. В описании видеоконтроллера ничего нету про его базовые адрес.

 

NoName
А как северный контроллер называется?
Тут не видео контроллер. А контролере памяти виноват. Или кто там первый в очереди?
Напиши что за материнка.

 

http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330_9863_13022^13054^9919,00.html
"AMD Geode™ CS5530A Companion Device Data Book"

 

Верхняя память, 64кб. Я понимаю чтобы получить к ним доступ нужно открыть шлюз a20. Я так и сделал.

Код (Text):

1. ;void SysOpenA20Gate(void);
2. _SysOpenA20Gate proc far
3.     push ax
4.     push dx
5.     mov dx,92h
6.     in  al,dx
7.     or  al,2
8.     out dx,al
9.     pop dx
10.     pop ax
11.     ret
12. endp

И с ужосом обнаружил что там лежит чей то труп. Как его убрать оттуда? Мне очень нужна эта память. Мне нужен весь первый метр. Спасибо если поможите!

PS. Дос подлежит уничтожению.

 

хех. Проблема с 64кб решилась загрузкой с внутреннего накопителя.

 

NoName
Так контролер памяти встроен в процессор. Описание надо на него смотреть.
http://www.amd.com/files/connectivitysolutions/geode/gx1_ds.pdf
Смотри Internal Bus Interface Unit Registers
Там просто отключаешь перенаправление на видео канал. И разрешаешь доступ чтение запись PCI и кэш по вкусу. И еще я бы в VGACTL отключилбы SMI.
Только учти что в DRAM по этим адрессам лежит SMI и его не подвинишь его откючать надо.

 

Там три видео региона как я понял. Если перенести реальный видеобуфер в третий регион и отключить два первых, msdos сможет нормально работать?

 

NoName
Там написано про 3 видео региона. 0B0000h-0B7FFFh 0B8000h-0BFFFFh и 0A0000h-AFFFFh
Как видно первые по 32кб последний 64кб. Все эти регионы используются для видео. Переключать их можно этого никто не заприщая даже напротив стандартными средствами VGA позволяют это сделать. Дос на это должен нормально реагировать. Что нельзя сказать насчет всех программы для дос.
А почему бы не отключить все три региона? И использовать LFB для вывода?

 

Я не имею большого опыта работы с дос. Не застал то время. Знаю защищенный режим. С SMI не работал с LFB и другими вещами касающимися графики тоже.
Мне нужно чтобы дос просто мог запустить мою программу а она делает обычные printf и хотелось бы чтобы они выводились на экран. Если это можно сделать через lfb то здорово. Если видео можно перенесте в 0xFFFF:0000 тоже здорово. Сейчас получилось грузануться через LOADHIGH в 0xFXXX:0000. В зависимости от модели железа адреса загрузки так немного меняются, но в целом я понимаю что это получается удобнее всего учитывая возможный перенос видео памяти. Незнаю, нужен совет такого опытного человека как вы
Загружаю через LOADHIGH загрузчик. Гружу автономную программу поверх дос. Очень нужно высвободить как можно больше памяти внизу (непрерывный участок). Загружаемой автономной программе передается вершина памяти. Естественно что возврата в дос нету.

Тема про загрузку вот - http://wasm.ru/forum/viewtopic.php?pid=280883#p280883 (WASM.LANG.C » Создать com файл из си кода с помощью borland 3.1 или 4.5)

 

NoName
Честно говоря совершенно непонятно зачем так извращаться?
чем unreal режим (см. 2) оперативная память) не устраивает? оставь захламлённый тяжким наследием первый Мб в покое и наслаждайся свободными Гб за его пределами )
lfb - это видеопамять расположенная за пределами всей ОЗУ, т.е. в пространстве 4Гб свободно доступных из унреал режима безо всякого гемороя с сегментами. (помоему даже то извращение что в статье по переходу в унреал не нужно - вроде у меня биос сам его делал и конструкции типа mov [edi], eax сразу нормально работали с 4Гб, есно в пределах рельно имеющейся памяти). Где конкретно сидит lfb определяй через vesa, я когда-то оочень давно в Turbo Pascal v.6 с асм вставками нормально оперировал этой памятью и обычной и видео, правда как перенаправить writeln, printf и т.п. в lfb не преставляю - наверно всё таки придётся туда ручками выводить или просто не париться с переносом памяти (меня тогда интересовал вывод своей графики и отсутствие в lfb необходимости переключать окна вывода было благодатью .

 

Есть сертифицированный код который я и гружу. Сам код включает в себя дофига всего, что пришлось бы менять при использовании Um, это исключается. Unreal mode я использую чтобы загрузить его на дос. Менеджеры памяти меня не устраивают потому что код расчитан на жестко определенное время выполнения. Насчет графики - мне нужно пока изучить маны по переносу.

 

меня переглючило конкретно, он не туда грузит куда надо. Вообще возвращаюсь к исходному варианту 64кб. Кстати если написать в config.sys dos=high,umb. При запуске дос пишет что неможет загрузится в hma. Я пробовал менять настройки в bios но это не помогло.

 

NoName
Расскажи поподробнее про задачу.
Что за сертифицированный код - exe? bin? есть исходник С? С++?
Большой объём кода? или ему нужно много памяти под данные? память выделяется динамически или он уже при загрузке хочет съесть всю доступную?
Что он делает с этими большими данными - хранит как базу? или интенсивно что-то по ним вычисляет?
Выводит только текст? или графика тоже нужна?
Почему не нужен ДОС? - прога что работает с диском через bios? или прога не обращается к нему вообще (только один раз загружается на старте)? А твой загрузчик - тоже сам разбирает FAT и читает сразу сектора через биос/порты?

 

1. Следуя указанию DOS=HMA, будучи в "реальном" режиме, ДОС сама себя пытается переместить в самые старшие 64k, формально расположенные за границей первого мегабайта. Чтобы это у неё получилось, "во первЫх строках" config.sys должен грузиться HIMEM.SYS (device=c:\dos\himem.sys).
2. Для того, чтобы ДОС занялась распределением памяти от границы 640k до 1М, той самой, где размещаются видеобуферы и ПЗУ поддержки для всяких древних контроллеров, нужно вскомандовать: DOS=UMB. Однако память (RAM) в тех адресах должна выделяться/управляться ещё одним предварительно загруженным драйвером. Обычно этим занимается EMM386, но он переводит процесор в защищённый режим. Были также драйверы, использующие расурсы северного моста для "реанимирования" shadowRAM (если не забыл, то rdos и LASTBYTE). Кстати, при помощи последнего, можно было заюзать под UMB видеобуфер монохромного режима...

После таких манипуляций (да ещё fileshigh=5; fcbshigh=0,0; stakshigh=0; buffershigh=16; lastdrivehigh=C в "нижней памяти" оставалось около 620K - любую "самую тяжёлую" программу можно запустить.

 

Y_Mur
Исходный код есть. Но показать я его не могу. Объем кода не очень большой, в основном данные. Память кушает всю сразу (по указанной границе), вычисляет. Только текст. С диском работает только загрузчик который запускается из под доса. Кстати сейчас получилось нормально загрузить com. Загрузчик грузит сам себя в верхнюю память и передает себе управление, printf работает

ConstZ
1. Сейчас я делаю с загрузкой дос только вниз.
2. Почему не DOS=NOUMB (upper memory block)? Я не уловил разницу. Наверное по умолчанию дос вообще там ничего не делает (640KB - 1MB). Можно ссылку на LASTBYTE? Я все же думаю что придется писать загрузчик который имеет первый метр сам и полностью. Хочу выжать все до последнего байта.

 

NoName
Как вариант - заранее посчитать релоки и сохранить загружаемый exe как базозависимый бинарник - тогда если ещё и диск дефрагментировать, то загрузчик можно свести к одной команде bios - прочитать последовательный блок секторов (на крайняк сделать это несколько раз, если в ограничение на количество читаемых секторов упрёшься) он будет сверхкомпакным, а при желании и самозатираемым, хотя имхо самозатирание уже перебор - лишний десяток байт тебя не спасёт (главное стек в безопасное с точки зрения затирания место поместить).

Но раз есть исходник и тем более код не очень большой - то я бы не стал так категорически отвергать унреал - его достоинство в том, что он ничего не требует от ДОС проги Достаточно вынести большой массив с данными за пределы 1Мб и написать на асм вставках функции доступа к нему (они элементарные), при этом вся логическая структура программы полностью сохранится, только обращение к данным будут через ещё один уровень абстракции, который с учётом отсутствия гемороя с сегментацией может даже ускорить работу программы А дальше при желании можешь и более оптимально интегрировать эти обращения в программу, но это уже не обязательно.
Наверняка компилятор не трогает FS, GS (а если трогает, то можно запретить указав в настройках только 8086) так что адресация относительно них даст тебе все преимущества flat модели, без серьёзной переделки логики программы. Все сервисы bios и дос (которую затирать уже не потребуется) будут доступны, поскольку код останется в 1Мб, а вынесены будут только данные, которые ни досу ни биосу не нужны.

 

Y_Mur
Дос нужен потому что используется еще кое какое ПО для диагностики целостности файлов.
Насчет унриала я конечно подумаю, но это врятли потому что я защ. реж уже написал (жестко заточеный под поставленные задачи), но под него еще не все готово из прикладного ПО. Я думаю будет достаточно выиграть все свободное место первого метра за время пока оно готовится. Это сейчас самый реальный путь для меня.
Покажите мне компилятор который позволяет использовать gs или fs для защищенного режима чтобы загрузить туда сегмент данных только для чтения и я буду очень рад Так его вообще никто не трогает. Только автор http://members.tripod.com/~ladsoft/cc386.htm согласился мне помочь, но мы дело до конца не довели поскольку неизвестна надежность компилятора (( Так и осталась генерация на промежуточной стадии (типо теоретически должно работать). Автор компилятор с января уже не обновляет (мы весной где то общались), т.е. ему это видимо не интересно. А самому разбираться в чужом компиляторе это очень стремно. Наверное проще свой написать, но это слишком трудоемкая задача если подходить серьезно.

Кто-нибудь знает как точно запускать com? Я нашел туманные описания в инете, они друг другу противоречат. Я ошибся в коде написав вместо push ds, push cs:

Код (Text):

1.     ;mov bx,0FFFFh
2.     ;mov ah,50h
3.     ;int 21h
4.  
5.     cli
6.     mov ax,0FFFFh
7.     mov sp,0FFF0h
8.     mov ss,ax
9.     mov ds,ax
10.     mov es,ax
11.     sti
12.  
13.     mov bx,0
14.     push bx
15.     ;push word 0
16.    
17.     mov ax,3
18.  
19.     push cs
20.     push 0100h
21.     retf

Т.е. передавал управления на саму же прогу, а если управление передавать по правильному адресу то все виснет. Только курсор еще мигает после передачи управления (у меня должна пищалка вызваться). Интересно что борланд по встроенной переменной "_psp" после неправильной передачи управления без установки адреса нового псп считает что он лежит по адресу 0xFFFF

Если передавать управления по правильному адресу без копии псп то каким то непонятным образом происходит выход обратно в командную строку, хотя предполагалось услышать звуковой сигнал и увидеть jmp $

Похоже что нужно также настроить psp, может быть это и есть основная проблема.
Загрузил простенькую программу на тасме, она правильно работает со звуком

 

интересно куда пропал мой последний пост после сообщения ConstZ. Глюк какой-то, наверное это у меня прокси сервер глючит.