Übersicht
Wiki
Hilfe
Suche
Einloggen
Registrieren
121
tyndur / Re: VFS und Ressourcen
« am: 24. July 2014, 21:33 »
Ohne jetzt tyndur im Detail zu kennen: Ein Verzeichniseintrag wird in einem Dateisystem gespeichert, eine node im Arbeitsspeicher. 
28. April 2024, 23:04
Beiträge anzeigen
Diese Sektion erlaubt es dir alle Beiträge dieses Mitglieds zu sehen. Beachte, dass du nur solche Beiträge sehen kannst, zu denen du auch Zugriffsrechte hast.
122
Lowlevel-Coding / Re: Neustart nach GDT setup
« am: 21. July 2014, 13:15 »
Du hast schlecht abgetippt. Das "limit" im gdtp ist ein uint16_t, kein uint64_t.
123
Softwareentwicklung / Re: Hardware-Entwicklungsboard
« am: 21. June 2014, 20:46 »das Intel ist ja ein SOC.SoC heißt an sich erstmal nichts, außer, dass der eine Chip allein schon ein (fast) vollständiges System ist.
Ein Notebook hat mir zuviel Hardware... soviel brauche ich erstmal nicht.. ausserdem möchte ich ja direkt "flashen"Du musst Hardware, die dich nicht interessiert, ja nicht benutzen. Wenn es dir aber um das BIOS geht (also die direkte Programmierung der Hardware), bist du beim Galileo auch falsch. Auf dem Board läuft ein spezielles Linux, was nach außen hin so tut, als wäre es ein Arduino.
Wie gesagt.. ein kleines OS, USB Tastatur, LCD ansteuern. Gerne auf Arduino Basis (halt mit bisschen mehr Speicher) und gut dokumentiert.Die USB-Tastatur wird ohne fertige Bibliothek schon sehr aufwändig, glaube ich. Allerdings liefert die Arduino-Gemeinde fertige Treiber und Dokumentation mit - das ist ja schließlich deren Konzept.
Möchte also eigentlich einen eigenen Minicomputer bauen, bzw. die Software drumherum. und suche dazu die ideale "Umgebung"..Da habe ich leider nur wenig Ahnung von, weil die günstig zu habenden Systeme entweder zu kompliziert oder ungeeignet sind.
Arduino ist keine schlechte Sache, aber man sperrt sich in deren Bibliotheken ein. Die eigentliche Hardware ist dadrin ziemlich gut wegabstrahiert, was dazu führt, dass man relativ schnell an Lösungen kommt. Aber man lernt halt nur wenig über die Hardware, weil man davon nicht allzuviel sieht. Und mit einem AVR, der auf dem ursprünglichen Arduino drauf ist, kann man sowieso kein "richtiges" Betriebssystem (also mit Anwendungen) machen, weil der seine Programme nur aus dem Flash ausführen kann, aber nicht aus dem RAM.
Und damit wären wir beim größeren Problem: Mikrocontroller haben wenig RAM, meist 512 KB oder weniger, was für einen echten Computer schlecht ist (wobei z.B. RetroBSD, ein echtes Unix, auch mit 128 KB auskommt). Systeme mit mehr Speicher sind dann meist SoCs mit viel komplexer Peripherie.
Insofern weiß ich nicht genau, was du eigentlich willst (außer "spielen"
) und kann dir nicht wirklich helfen.
124
Softwareentwicklung / Re: Hardware-Entwicklungsboard
« am: 21. June 2014, 18:47 »
Nö, das ist schon ein paar Jahre her und scheint es wohl nicht mehr zu geben. Der Vortex86SX ist nicht mehr das Mittel der Wahl, weil kein modernes Betriebssystem mehr etwas mit einem 486SX-Kern zu tun haben möchte. Wird deswegen auch nicht mehr produziert.
Der 86duino sieht ganz interessant aus, ist aber trotzdem nur ein PC-on-Chip. Da laufen DOS und Windows drauf, also kannst du gleich ein altes Notebook nehmen. Der einzige Vorteil wäre wahrscheinlich vorhandene Dokumentation. Wenn es dir um den Prozess geht (also Toolchain- und Cross-Compiler-Stress, programmieren auf Hardware-Ebene usw.) solltest du dich (meiner Meinung nach) lieber bei den ganzen billigen ARM-Kits umschauen (TI Launchpad, ST Discovery usw.). Allerdings hast du dort keine großen Speichermengen, wie man sie für ein "richtiges" Betriebssystem gern hätte, weil das kleine Controller sind.
Der 86duino sieht ganz interessant aus, ist aber trotzdem nur ein PC-on-Chip. Da laufen DOS und Windows drauf, also kannst du gleich ein altes Notebook nehmen. Der einzige Vorteil wäre wahrscheinlich vorhandene Dokumentation. Wenn es dir um den Prozess geht (also Toolchain- und Cross-Compiler-Stress, programmieren auf Hardware-Ebene usw.) solltest du dich (meiner Meinung nach) lieber bei den ganzen billigen ARM-Kits umschauen (TI Launchpad, ST Discovery usw.). Allerdings hast du dort keine großen Speichermengen, wie man sie für ein "richtiges" Betriebssystem gern hätte, weil das kleine Controller sind.
125
Softwareentwicklung / Re: Hardware-Entwicklungsboard
« am: 20. June 2014, 13:07 »
Hallo,
bei ARM-Boards ist es üblich, dass die Plattformen alle inkompatibel zueinander sind, aber bei x86 ist das nicht üblich. Dort hat sich eine Standardplattform durchgesetzt, der PC. Wenn es dir nur um ein x86-OS geht, dann kannst du dafür eigentlich jeden PC nehmen, oder emulieren, und es dir einfacher machen.
Es gibt x86-Prozessoren für eingebettete Systeme, z.B. die Vortex86-Reihe, und auch einen Standard für SBCs. Das Stichwort dazu wäre PC/104, aber wie das mit Industriezeugs so ist, gibt es den Preis oft nuf "auf Anfrage".
Das Board, was ich gerade für dich raussuchen wollte, finde ich leider nicht mehr. Da war aber ein Vortex86SX drauf, und es hatte - wenn ich mich richtig erinnere - SPI, I2C, GPIO-Pins und so weiter.
Gruß,
Svenska
bei ARM-Boards ist es üblich, dass die Plattformen alle inkompatibel zueinander sind, aber bei x86 ist das nicht üblich. Dort hat sich eine Standardplattform durchgesetzt, der PC. Wenn es dir nur um ein x86-OS geht, dann kannst du dafür eigentlich jeden PC nehmen, oder emulieren, und es dir einfacher machen.
Es gibt x86-Prozessoren für eingebettete Systeme, z.B. die Vortex86-Reihe, und auch einen Standard für SBCs. Das Stichwort dazu wäre PC/104, aber wie das mit Industriezeugs so ist, gibt es den Preis oft nuf "auf Anfrage".
Das Board, was ich gerade für dich raussuchen wollte, finde ich leider nicht mehr. Da war aber ein Vortex86SX drauf, und es hatte - wenn ich mich richtig erinnere - SPI, I2C, GPIO-Pins und so weiter.
Gruß,
Svenska
126
Lowlevel-Coding / Re: Werte übergeben
« am: 30. May 2014, 13:48 »
Lern C.
Variablennamen sind keine Zeichenketten.
Variablennamen sind keine Zeichenketten.
127
Lowlevel-Coding / Re: Werte übergeben
« am: 30. May 2014, 12:49 »
Was du vor hast, funktioniert nicht.
128
Lowlevel-Coding / Re: Werte übergeben
« am: 29. May 2014, 21:57 »
Das sind Grundlagen. Von Libs bist du im Augenblick ungefähr so weit weg wie von Australien. 
Du hast dem Compiler nicht gesagt, was Test1 ist. Also weiß er das nicht. Also kann er das auch nicht an die Funktion übergeben. "WertDieErste" ist dagegen ein Stringliteral (eine konstante, ausgeschriebene Zeichenkette), die kann er ohne Probleme übergeben.
In Headerfiles deklariert man Funktionen nur, man implementiert sie dort besser nicht. Lass den Header für den Anfang weg und schreibe alles in eine einzige (C oder C++) Datei.
"extern" sagt dem Compiler, dass die Funktion woanders zu finden ist. Keine Ahnung, ob das bei Funktionen überhaupt sinnvoll ist, ich kenne es nur im Zusammenhang mit Variablen. Brauchen tut man es nur selten.
Tut zwar immernoch nichts, aber compiliert.
Du hast dem Compiler nicht gesagt, was Test1 ist. Also weiß er das nicht. Also kann er das auch nicht an die Funktion übergeben. "WertDieErste" ist dagegen ein Stringliteral (eine konstante, ausgeschriebene Zeichenkette), die kann er ohne Probleme übergeben.
In Headerfiles deklariert man Funktionen nur, man implementiert sie dort besser nicht. Lass den Header für den Anfang weg und schreibe alles in eine einzige (C oder C++) Datei.
"extern" sagt dem Compiler, dass die Funktion woanders zu finden ist. Keine Ahnung, ob das bei Funktionen überhaupt sinnvoll ist, ich kenne es nur im Zusammenhang mit Variablen. Brauchen tut man es nur selten.
Code: [Auswählen]
void myfunc(char* fu1, char* fu2)
{
/* tu was */
}
int main(void)
{
myfunc("Test1", "Test2");
return(0);
}
Tut zwar immernoch nichts, aber compiliert.
129
Lowlevel-Coding / Re: Wie benutzt man das Dateisystem?
« am: 19. May 2014, 12:10 »
Eine IDE-Festplatte steuerst du (größtenteils) über die Ports der ATA-Schnittstelle an, ein gewöhnliches Diskettenlaufwerk über die Ports des FDC. Damit kannst du Lese- und Schreibzugriffe auf bestimmte Sektoren durchführen. Das ist bei jedem Dateisystem gleich. FAT gibt dir eine mögliche Antwort auf die Frage, was du wo auf die Festplatte schreiben solltest, damit andere damit auch etwas anfangen können.
Das sind zwei Ebenen. Aus der Sicht ist das ähnlich wie bei CGA: Mit den Ports steuerst du die Hardware an, aber damit erzeugst du nur einen korrekt eingestellten schwarzen Bildschirm. Die eigentliche Benutzeroberfläche (also das was und das wo auf dem Bildschirm) machst du anders. (Wie, hängt davon ab, wie du die Ports programmiert hast.)
Das sind zwei Ebenen. Aus der Sicht ist das ähnlich wie bei CGA: Mit den Ports steuerst du die Hardware an, aber damit erzeugst du nur einen korrekt eingestellten schwarzen Bildschirm. Die eigentliche Benutzeroberfläche (also das was und das wo auf dem Bildschirm) machst du anders. (Wie, hängt davon ab, wie du die Ports programmiert hast.)
130
Lowlevel-Coding / Re: Wie benutzt man das Dateisystem?
« am: 19. May 2014, 00:41 »
Dateisysteme und Geräte sind verschieden. FAT kann man auf Disketten, Festplatten, USB-Sticks, SD-Karten usw. benutzen. Die steuert man alle unterschiedlich an. Nicht jede Hexadezimalzahl ist eine Portadresse. Ich verstehe deine Frage nicht.
131
Lowlevel-Coding / Re: Bochs PANIC bei zugriff auf CDROM
« am: 15. May 2014, 23:34 »
Ich kenne mich jetzt nicht so ganz mit Bochs aus, aber bist du sicher, dass du auf das virtuelle CD-Laufwerk auch wie auf ein CD-Laufwerk (d.h. ATAPI) zugreifst? "Device: HD" liest sich für mich eher wie ein Festplattenzugriff. Außerdem haben (Daten-)CDs eine andere logische Blockgröße (2048 Byte) als Festplatten (512 Byte).
132
Offtopic / Re: ARM oder x86?
« am: 14. May 2014, 01:54 »
Trotzdem x86, weil die Plattform standardisiert ist.
Erklärung: Um die CPU rum ist gaaanz viel Hardware gebaut. Bei x86 kennst du die, weil die bei jedem PC gleich ist. Bei ARM ist sie überall anders.
Erklärung: Um die CPU rum ist gaaanz viel Hardware gebaut. Bei x86 kennst du die, weil die bei jedem PC gleich ist. Bei ARM ist sie überall anders.
133
Offtopic / Re: RAM auslesen bis 4GB
« am: 13. May 2014, 02:06 »Weil 32-Bit doch nur bis 4GB RAM unterstützt und erst ab 64-Bit mehr als 4GB möglich sind...PAE ermöglicht es auch auf 32-Bit-Prozessoren, mehr als 4 GB RAM zu benutzen. Die Multiboot-Informationen (oder das BIOS) können daher auch mehr als 4 GB RAM mitteilen. Ein 32-Bit-Windows mit Standardeinstellungen benutzt PAE allerdings nicht.
134
Lowlevel-Coding / Re: Higher half kernel, general protection fault
« am: 12. May 2014, 14:27 »
Segmentierung gab es früher und hat sich aus verschiedenen Gründen nicht durchgesetzt. Wegen der Kompatiblität ist sie aber auf x86-Prozessoren (im 16- und 32-Bit-Modus) voll funktionsfähig. Außerdem kann man damit Speicher auch auf Prozessoren ohne NX-Bit als "nicht ausführbar" markieren.
Oder sie halt für Higher-Half-ohne-Lower-Half-Loader missbrauchen.
Oder sie halt für Higher-Half-ohne-Lower-Half-Loader missbrauchen.
135
Softwareentwicklung / Re: [All In One]-Question lolxdfly
« am: 08. May 2014, 17:07 »
Wenn du mit GDB einen Breakpoint direkt auf den "mov cr0, %%"-Befehl setzt und danach die CPU einmalig single-stepst, dann hast du Paging aktiviert, bevor der Crash auftritt. Dann kannst du dir im Qemu-Monitor mit "info mem" und "info tlb" besser anschauen, was die CPU gerade denkt.
Bei deaktiviertem Paging gibt der Qemu-Monitor bei beiden Befehlen nur "PG disabled" aus.
Bei deaktiviertem Paging gibt der Qemu-Monitor bei beiden Befehlen nur "PG disabled" aus.
136
Lowlevel-Coding / Re: Ports und Index
« am: 08. May 2014, 17:03 »
Der Index ermöglicht es, mit wenig Adressen viele Register anzusteuern und funktioniert im Prinzip überall ähnlich.
Dazu definiert man eine Adresse für das Auswahlregister (Indexregister) und eine weitere Adresse für das eigentliche Register (Datenregister). Um von einem Register zu lesen (schreiben), schreibt man den Index in das Indexregister und liest (schreibt) dann das Datenregister.
Für CGA ist 0x3D4 das Indexregister, 0x3D5 das Datenregister.
Wenn du ein Register nicht lesen kannst, weil die Hardware das nicht ermöglicht, kriegst du keine Fehlermeldung und niemand wird dich darüber informieren. Du bekommst einfach nur ungültige Werte.
Dazu definiert man eine Adresse für das Auswahlregister (Indexregister) und eine weitere Adresse für das eigentliche Register (Datenregister). Um von einem Register zu lesen (schreiben), schreibt man den Index in das Indexregister und liest (schreibt) dann das Datenregister.
Für CGA ist 0x3D4 das Indexregister, 0x3D5 das Datenregister.
Wenn du ein Register nicht lesen kannst, weil die Hardware das nicht ermöglicht, kriegst du keine Fehlermeldung und niemand wird dich darüber informieren. Du bekommst einfach nur ungültige Werte.
137
Lowlevel-Coding / Re: Wie ist das mit den Adressen? Bit beschreiben?
« am: 06. May 2014, 01:00 »Das versteh ich jetzt nicht,Dein "0x0B" sagt eigentlich nicht mehr aus als "Dorfstraße 5". Welches Dorf gemeint ist, steht da nicht drin.
also wenn ich auf 0x0B zeige kann ich auch irgendwas anderes ansprechen als die CMOS?
Wie sprech ich denn dann die CMOS an ohne das ich was falsches anspreche?
Wenn du im I/O-Adressraum auf Adresse 0x0B zugreifst, dann greifst du auf das CMOS zu, deswegen auch die inb()- oder outb()-Funktionen. Das gilt natürlich nur, wenn da auch ein CMOS angeschlossen ist, aber davon darfst du ausgehen. Würdest du ganz normal einen Zeiger auf die Adresse erzeugen und davon lesen, dann liest du ganz normalen RAM. Anders ist es, wenn du einen ganz normalen Zeiger auf 0xB8000 erzeugst und den benutzt: Dann greifst du direkt auf die Grafikkarte zu (sofern vorhanden). Was sich wo befindet, ist in der Memory Map der Plattform dokumentiert. Die ist beim PC aus historischen Gründen recht komplex und außerdem von Chipsatz zu Chipsatz verschieden, deswegen fragst du normalerweise das BIOS (wenn du dem Tutorial aus dem Wiki folgst, dann fragt der Bootloader für dich und legt dir das Ergebnis vor die Nase).
Ist das so richtig (mit den Bits)?Nein. Lies dir bitte mal den Artikel auf Mikrocontroller.net durch. Da ist das gut beschrieben.
Ich wusst zwar schon, dass das auf die Dauer nicht so gut ist(falls die addressen nicht frei sind in der Bios memory map), aber die Vorstellung damit Hardware zu beschädigen ist schon - ich nenns mal gruselig.Es ist sehr unwahrscheinlich, dass Hardware kaputt geht. Das war vor 20 Jahren alles noch gefährlicher.
Wahrscheinlicher ist es dagegen schon, dass das System schlicht abstürzt, wenn du einem Gerät quer auf die Füße trittst. Moderne Bussysteme (z.B. PCI, USB, ISAPnP) verraten dem System, welche Geräte dort angeschlossen sind. ISA-Geräte muss man aber proben, d.h. ansprechen und gucken, ob da was reagiert. Zuckt da nichts (oder falsch), dann war die gesuchte Hardware nicht angeschlossen, und im schlimmsten Fall hast du die dort angeschlossene Hardware gerade verwirrt.
138
Lowlevel-Coding / Re: Wie ist das mit den Adressen? Bit beschreiben?
« am: 05. May 2014, 12:25 »
Eine x86-CPU unterscheidet historisch zwei Arten von Adressen, weil es zwei Adressräume gibt: Speicher und I/O. Die Unterscheidung wird durch den Befehl getroffen, mit dem der Zugriff stattfindet; der Adresse selbst sieht man das nicht an. Eine Adresse ist nur eine Zahl und ein Zeiger speichert auch nur diese Zahl.
Wenn du von "0x0B" liest, dann schreibt die CPU diese Zahl auf den Adressbus und sagt an, dass sie jetzt lesen möchte. Das ist eine Anweisung für alle anderen Geräte, von denen jetzt das eine Gerät, was sich bei "0x0B" angesprochen fühlt, die Daten auf den Datenbus legen soll. Bei den meisten (Speicher-)Adressen ist da entweder nichts (Lesen: Müll, Schreiben: passiert nichts) oder Speicher (Lesezugriffe lesen das, was Schreibzugriffe vorher da hingeschrieben haben). (Anmerkung: Grundsätzlich ist das immernoch so, aber die Details sind anders.)
Allerdings kann hinter einer Adresse auch eine Hardware stehen. Dafür ist der I/O-Adressraum da, geht aber auch im Speicheradressraum (MMIO). Dann liest man nicht das, was man da vorher reingeschrieben hat, sondern das, was die Hardware z.B. gerade denkt. Und man schreibt nicht, was man später wieder lesen will, sondern man weist das Gerät z.B. an, etwas zu tun. (Anmerkung: Deswegen sollte man nicht auf wahllose Adressen schreiben. Manche Hardware geht kaputt, wenn man sie falsch anspricht.)
Bits beschriften kann man in C z.B. mit Bitfeldern, oder man benutzt Bitmasken zusammen mit Bitoperationen:
0x80 ist dasselbe wie 1000 0000b, ~0x80 ist das Inverse davon (also dasselbe wie 0x7F oder 0111 1111b). Wenn du 0x80 ODER "irgendwas" machst, dann kommt als Ergebnis "irgendwas" raus, wo zusätzlich das Bit 7 gesetzt ist. Wenn du ~0x80 UND "irgendwas" machst, dann kommt als Ergebnis "irgendwas" raus, wo aber das Bit 7 gelöscht ist.
Direkt Bits adressieren kannst du auf einer x86-CPU nicht. Es gibt aber Mikrocontroller, wo das geht.
Wenn du von "0x0B" liest, dann schreibt die CPU diese Zahl auf den Adressbus und sagt an, dass sie jetzt lesen möchte. Das ist eine Anweisung für alle anderen Geräte, von denen jetzt das eine Gerät, was sich bei "0x0B" angesprochen fühlt, die Daten auf den Datenbus legen soll. Bei den meisten (Speicher-)Adressen ist da entweder nichts (Lesen: Müll, Schreiben: passiert nichts) oder Speicher (Lesezugriffe lesen das, was Schreibzugriffe vorher da hingeschrieben haben). (Anmerkung: Grundsätzlich ist das immernoch so, aber die Details sind anders.)
Allerdings kann hinter einer Adresse auch eine Hardware stehen. Dafür ist der I/O-Adressraum da, geht aber auch im Speicheradressraum (MMIO). Dann liest man nicht das, was man da vorher reingeschrieben hat, sondern das, was die Hardware z.B. gerade denkt. Und man schreibt nicht, was man später wieder lesen will, sondern man weist das Gerät z.B. an, etwas zu tun. (Anmerkung: Deswegen sollte man nicht auf wahllose Adressen schreiben. Manche Hardware geht kaputt, wenn man sie falsch anspricht.)
Bits beschriften kann man in C z.B. mit Bitfeldern, oder man benutzt Bitmasken zusammen mit Bitoperationen:
0x80 ist dasselbe wie 1000 0000b, ~0x80 ist das Inverse davon (also dasselbe wie 0x7F oder 0111 1111b). Wenn du 0x80 ODER "irgendwas" machst, dann kommt als Ergebnis "irgendwas" raus, wo zusätzlich das Bit 7 gesetzt ist. Wenn du ~0x80 UND "irgendwas" machst, dann kommt als Ergebnis "irgendwas" raus, wo aber das Bit 7 gelöscht ist.
Direkt Bits adressieren kannst du auf einer x86-CPU nicht. Es gibt aber Mikrocontroller, wo das geht.
139
Lowlevel-Coding / Re: In Videospeicher schreiben
« am: 04. May 2014, 00:48 »
Am besten, du schaust dich im hiesigen Wiki um. Da steht alles drin, was du für Textausgabe brauchst. Den Link hast du ja schon bekommen.
Der VGA-Textmodus ist kompatibel zum CGA-Textmodus. Eine Zeile hat 80 Zeichen, jedes Zeichen belegt 2 Bytes im Videospeicher. Wo fängt die zweite Zeile an? Wo fängt die dritte Zeile an?
Grafik solltest du erstmal sein lassen. Das ist wesentlich komplizierter als du dir das vermutlich gerade vorstellen kannst und wird (leider) auch mit viel Erfahrung nicht wirklich viel besser. Aber wenn du unbedingt willst, findest du Informationen zum VGA-Grafikmodus und zu VESA ebenfalls im Wiki. Ich vermute aber, dass dir das ohne viel zusätzliches Grundlagenwissen noch nicht viel bringen wird.
Der VGA-Textmodus ist kompatibel zum CGA-Textmodus. Eine Zeile hat 80 Zeichen, jedes Zeichen belegt 2 Bytes im Videospeicher. Wo fängt die zweite Zeile an? Wo fängt die dritte Zeile an?
Grafik solltest du erstmal sein lassen. Das ist wesentlich komplizierter als du dir das vermutlich gerade vorstellen kannst und wird (leider) auch mit viel Erfahrung nicht wirklich viel besser. Aber wenn du unbedingt willst, findest du Informationen zum VGA-Grafikmodus und zu VESA ebenfalls im Wiki. Ich vermute aber, dass dir das ohne viel zusätzliches Grundlagenwissen noch nicht viel bringen wird.
140
Lowlevel-Coding / Re: In Videospeicher schreiben
« am: 03. May 2014, 21:51 »
Manche Zahlen ergeben in verschiedenen Darstellungen einen Sinn, deswegen muss man immer zusätzlich angeben, welche Darstellung man gerade meint. Keine Angabe steht meistens für "dezimal".
0xZAHL oder ZAHLh beschreibt eine Hexadezimalzahl (Basis 16, Ziffern 0..9, a..f, Beispiel 0x0D).
0bZAHL oder ZAHLb beschreibt eine Binärzahl (Basis 2, Ziffern 0..1, Beispiel 0b1101).
0ZAHL beschreibt oft eine Oktalzahl (Basis 8, Ziffern 0..7, Beispiel 0377).
Letzteres ist gemein, da musst du aufpassen. Für einen C-Compiler sind 120 und 0120 verschiedene Zahlen! (0120 oktal ist 80 dezimal.)
0xZAHL oder ZAHLh beschreibt eine Hexadezimalzahl (Basis 16, Ziffern 0..9, a..f, Beispiel 0x0D).
0bZAHL oder ZAHLb beschreibt eine Binärzahl (Basis 2, Ziffern 0..1, Beispiel 0b1101).
0ZAHL beschreibt oft eine Oktalzahl (Basis 8, Ziffern 0..7, Beispiel 0377).
Letzteres ist gemein, da musst du aufpassen. Für einen C-Compiler sind 120 und 0120 verschiedene Zahlen! (0120 oktal ist 80 dezimal.)