intensevideo schreibt ins BIOS?

Es gibt da eine Funktion im DJGPP, um in DOS helle Hintergrundfarben zu ermöglichen, aber ich habe damit ein kleines Problem:

www.delorie.com/djgpp/doc/libc/libc_490.html schrieb:

intensevideo

Syntax

#include <conio.h>

void intensevideo(void);

Description

Bit 7 (`MSB') of the character attribute byte has two possible effects on EGA and VGA displays: it can either make the character blink or change the background color to bright (thus allowing for 16 background colors as opposed to the usual 8). This function sets that bit to display bright background colors. After a call to this function, every character written to the screen with bit 7 of the attribute byte set, will have a bright background color. The companion function blinkvideo (see section blinkvideo) has the opposite effect.

Note that there is no BIOS function to get the current status of this bit, but bit 5 of the byte at 0040h:0065h in the BIOS area indicates the current state: if it's 1 (the default), blinking characters will be displayed.

Heißt das, dass diese Funktion tatsächlich ins BIOS schreibt, diese Einstellungen also auch nach einem Neustart und selbst nach dem Formatieren der Festplatte noch vorhanden sind?

Oh, das ist schon ein paar Jahre her.
Schau mal in einer Bücherei nach ob da das Buch "PC Intern" noch greifbar ist.

Also PC vor etwa 20 Jahren: Beispiel 286 hatte 1MB Speicher - davor 640kB für Programme <- stimmt nicht ganz: Platz für Treiber, Speicherverwaltungsprogramme brauchen ja auch noch Platz. Die oberen 64kB waren in der Regel für das BIOS reserviert. Und der Speicher der nun noch übrig bleibt, wird je nach dem wo dieser am dringensten benötigt wird vergeben oder bleibt gar frei. In letzterem Bereich können BOIS-Erweiterungen untergebracht sein Beispiel von Erweiterungskarten. Die Grafik erhielt da je nach Ausführung auch noch ihr Plätzchen. Oder die Speicherverwaltungprogramme konnten die 640kB entlasten und einige Treiber in dem Bereich unterbringen.

Die Bios-Daten konnte man damals nur mit speziellen Programmen, wenn entsprechende Jumper auf dem Mainboard gesetzt waren neu schreiben. Dies ohne Gewähr - a ist es lange her und b ich kannte nicht alle Mainboards.

Du kannst dir vorstellen das, wenn 2 Programmen unabhängig voreinander denselben Speicher nutzen wollen Ärger angesagt ist.

Das BIOS wurde in den normalen Speicher gespiegelt, da die Datengeschwindigkeit des BIOS-Speichers relativ langsam war.

Dieser Text erhebt keinen Anspruch auf Vollständigkeit.

MfG f.-th.

SG1

f.-th. schrieb:

Das BIOS wurde in den normalen Speicher gespiegelt, da die Datengeschwindigkeit des BIOS-Speichers relativ langsam war.

Ich glaub, das ist das einzig relevante. Ich bin mir ziemlich sicher, dass die angesprochene Funktion nur in diese Kopie des BIOS schreibt.

OK, danke erstmal für die Informationen. Um ganz sicher zu gehen werd ich mal eine Virtual Machine aufsetzen und mit dem Wert dort ein bisschen rumspielen.

Um auf den Speicherbereich zuzugreifen, reicht da ein

int *pointer = reinterpret_cast<int *>(0x00400065);

oder muss ich da was anderes machen?

SideWinder

Höchstwahrscheinlich reicht das nicht. Kommt aber natürlich darauf an welches OS du verwendest. Hat das neueste MS-DOS denn nicht auch pro Prozess einen eigenen Adressraum? Dann geht das so nicht. Bei Windows sowieso nicht.

BTW: In einer VM zu probieren ist zwar ganz nett, aber du darfst das nicht als Test für "dann ist es auch im echten System so" verwenden. Kann sein, dass die VM nicht alle Befehle 100%ig genau so umsetzt wie man es auch im "echten" System erwarten kann.

MfG SideWinder

sieht ganz so aus, hier ist eine code-seite, die hilft dir vielleicht weiter:

http://permalink.gmane.org/gmane.comp.gnu.grep.bugs/1556

Ganz allgemein hinterlässt die entsprechende Funktion einen "poorly" dokumentierten Eindruck, so dass ich es vorzöge, den Interrupt selbst zu steuern, bzw. zu "handlen".