Nachrichten

1561

Lowlevel-Coding / PIT

« am: 20. March 2005, 11:24 »

weil << 8 das low byte ins high byte verschiebt. welchen sinn soll das haben?

1562

Lowlevel-Coding / PIT

« am: 18. March 2005, 22:28 »

das heisst, dass nur das untere byte von counter an den port 0x40 geschickt wird.

counter ist eine 16bit-zahl und muss in zwei getrennten 8 bit (=1 byte) paketen geschickt werden. einmal das highbyte und einmal das lowbyte. (welches zuerst war weiss ich auch nicht so genau. steht ja im code )

1563

Lowlevel-Coding / PIT

« am: 17. March 2005, 20:12 »

Doch es gibt da auch was. Unter dem informativen Titel 8253/54 CPU Timer Datasheet. Dieses PDF find ich persönlich wenig informativ.

Hier gibt es bessere Artikel zum "8253".

1564

Lowlevel-Coding / pointer

« am: 17. March 2005, 19:02 »

Hi,

GhostCoder: das wäre zwar richtig, wenn man nur die funktionsdeklaration anschaut, aber im aufruf sieht man, dass eine zeichenkette übergeben wird.

die funktionsdeklaration ist also falsch. es muss void print(char* eing) heissen

VideoMem sollte global sein, damit du nicht bei jeden aufruf von print() wieder oben links mit der ausgabe anfängst, sondern die position gespeichert wird.

Code: [Auswählen]


char *VideoMem = (char*)0xB8000;

void print(char* eing) { // eing ist ein zeiger auf eine zeichenkette, deswegen char*
char *Text = eing;
while(*Text){
    *VideoMem = *Text;
    VideoMem++; // wir verändern den zeiger, nicht den wert in VideoMem[0] (das * muss weg)
    *VideoMem = 7;
    VideoMem++; // das * muss weg. siehe oben
   Text++; // das * muss weg. siehe oben
   line++; // <---- was bedeutet das?
}//end while

}//end outp


wenn dir das mit den *foo zu kompliziert wird schreib einfach foo[0], wenn du was in den speicher schreiben willst und foo wenn du den zeiger verändern willst.

merke: *VideoMem bedeutet das gleiche wie VideoMem[0]


edit: woher kommt diese komische funktion? die hab ich doch schon mal hier gesehen. mit ähnlichen (oder genau den gleichen?) fehlern. wie wärs mal mit einem Tutorial über Pointer in C in der nächsten Ausgabe oder in der Tutorialsammlung?

1565

Offtopic / Minix Installation

« am: 14. March 2005, 20:44 »

du musst also nicht hd0 sondern fd0 eingeben.

Minix ist ein System für Freaks. Da muss man leider auch das Manual lesen.
Die Installationsanleitung ist hier: http://www.cs.vu.nl/pub/minix/2.0.2/usage.txt

    After loading the root diskette into the RAM disk  you  will  be
     asked to finish the name of the device to mount on /usr.  Type fd0c for a
     diskette that contains both ROOT and USR, otherwise replace ROOT  by  USR
     and type fd0.  Login as root.

replace ROOT by USR meint hier disketten tauschen.. wenn ich mich recht erinnere

1566

Offtopic / Minix Installation

« am: 14. March 2005, 17:04 »

wenn ich das richtig verstehe bist du noch beim setup. da musst du erstmal die diskette mounten, nicht die festplatte. (deswegen steht da auch "mount as /usr" und nicht "format as /usr")

1567

Offtopic / Nochmal fragen in C...

« am: 12. March 2005, 21:46 »

ich hab mal an die veränderten zeilen // <- zeile xxx rangeschrieben damit man sie besser erkennt.

wenn du eine funktion (hier die print-funktion) verwendest, die du erst weiter unten definierst, musst du sie vorher deklarieren.
und dann noch ein paar sachen, wo du das * vergessen hast.

sollte so funktionuckeln, hab ich aber nicht getestet ...

Code: [Auswählen]


char*VideoMem=(char*)0xB8000;

int xPos=0;
int yPos=0;

// du musst print deklarieren _bevor_ du es verwendest:
void print(unsigned char _zeichen); // <------- zeile 20/30

void printf (char *string)
{
   char zeichen=*string; // <------- zeile 8
   while(zeichen != '\0')
   {
      switch(zeichen)
      {  
         case '\n':
            /*NewLine();*/
            break;
         case '\t':
            /*PrintTab();*/
            break;
         default:
            print(zeichen);
      }
      *string++;
      zeichen=*string; // <------- zeile 23
   }
}



void print(unsigned char _zeichen)
{
   if(xPos==80)
   {
      xPos=1;
      yPos++;
      if(yPos==26)
      {
         /*ClearScreen();*/
         yPos=1;
         char*VideoMem=(char*)0xB8000;
      }
   }
   *VideoMem=_zeichen; // <------- zeile 42
   xPos++;
   *VideoMem++;
   *VideoMem=7; // <------- zeile 45
}


1568

Lowlevel-Coding / 8 Bits Teilen

« am: 11. March 2005, 23:36 »

@Svenska: Es gibt Visual Basic .NET auch unter Linux in Form von Mono. Für nicht-.NET-VB gibt es dann auch noch RealBASIC und FreeBASIC. Notfalls gibt es da auch noch Wine, über das VB auch laufen soll. Es ist also nicht so, dass es da überhaupt nix gäbe.

ausser dem ist micro$oft visual basic was für kidys... und es STINKT!

solange diese Behauptung unbegründet da steht, muss sie zum Glück niemand glauben

1569

Lowlevel-Coding / 8 Bits Teilen

« am: 09. March 2005, 22:01 »

achso hab das ein bisschen verpeilt. jo eigentlich macht man das wegen der variablengröße. ist hier eigentlich überflüssig, ich mach es aber instinktiv immer, damit man an der operation sieht, wie groß die zahl ist, die da rauskommt.

1570

Lowlevel-Coding / 8 Bits Teilen

« am: 09. March 2005, 16:14 »

76543210b >> 4 = 00007654b

zeig mir ne binärzahl mit 2, 3, 4, 5, 6 oder 7 und ich zeig dir nen faulen kater (oder so ging das doch ...)

1571

Lowlevel-Coding / 8 Bits Teilen

« am: 08. March 2005, 21:59 »

ich bin ja net so:

Code: [Auswählen]

zahl = 0x3F;
highnibble = (zahl >> 4) & 0xF; // zahl um vier stellen nach rechts schieben und die 4 unteren bits (1111b = Fh) holen
lownibble = zahl & 0xF; // nur die 4 unteren bits (1111b = Fh) holen

aber sonst stimm ich joachim_neu zu.

1572

Offtopic / EAX in C lesen

« am: 07. March 2005, 15:45 »

Edit: Warum nehm ich net gleich long, dann brauch ich keine 3 funktioonen?

warum 3 funktionen für char, short und long? weil manche ports nur char, short oder long lesen und bei anderen datenbreiten fehler verursachen ...

1573

OS-Design / Interupt-List

« am: 07. March 2005, 15:44 »

Hi,

soweit ich weiss gibt es für all diese plattformen keine interrupts, wie beim pc im realmode, weil bei all diesen plattformen entweder ein betriebssystem vorhanden ist (iPod) oder die Spiele selbst ihre funktionen mitgebracht haben (Gameboy)

wenn es was für den iPod gibt, findest du das sicherlich unter http://www.ipodlinux.org

1574

OS-Design / EIN OS IN C MIT BOOTLOADER...

« am: 05. March 2005, 22:55 »

ich weiß zwar dass man bei "main" einen unterstrich vorsetzen muss, aber da
hat dann er linker [ld] unter linux gemotzt.

jupp, das ist nur unter DOS so...

Code: [Auswählen]

char *VideoMem = (char*)0xA8000;
muss 0xB8000 heissen, weil da der Videospeicher in Textmodus ist.

Code: [Auswählen]

.text 0xFF800000 : {
muss .text 0x00010000 heissen, weil der kernel an 0x1000:0x0000 (also 0x00010000 linear) geladen wird.

Das größte Problem ist allerdings, dass ihr einen 32-bit (also Protected-Mode) Kernel habt, aber nicht in den Protected Mode wechselt. Den entsprechenden Code müsst ihr noch ergänzen. (siehe pm-tuts auf dieser seite ...)

1575

Offtopic / Nochmal fragen in C...

« am: 05. March 2005, 12:33 »

Hi,

Tut mir leid, aber der Code ist totaler schrott. Ein Tipp: Kauf dir ein anständiges Buch über C. (-> Amazon) oder lies dir zumindest ein paar Tutorials zu den grundlegensten(!) Sachen von C durch.

Ich geh hier mal auf die gröbsten Sachen ein.

in void SetCursor(int _xPos,int _yPos) :
Wenn du den Zeiger VideoMem verändern willst, musst du auch VideoMem schreiben und nicht *VideoMem. Du musst *VideoMem schreiben, wenn du einen Wert, an die Stelle, auf die VideoMem zeigt schreiben willst.

Code: [Auswählen]


   *VideoMem = (char*)0xB8000;
   *VideoMem = *VideoMem + (xPos*2-2)
   *VideoMem = *VideoMem + (yPos-1)*160  

wird zu

Code: [Auswählen]


   VideoMem = (char*)0xB8000;
   VideoMem = VideoMem + (xPos*2-2);
   VideoMem = VideoMem + (yPos-1)*160;  


Das Semikolon an dem Ende der Funktion ist überflüssig. Dafür müssen hinter die Zuweisungen welche.

in void ClearScreen():
Bei for-Schleifen steht im 2. Ausdruck, das, was wahr sein muss, damit die Schleife durchlaufen wird. Es muss also for (i=0; i<4000; i++) heissen. Es muss auch wieder VideoMem = (char*)0xB8000;  heissen und diese Anweisung muss vor der for-Schleife stehen!

void print (char *string):
bekannte fehler in:

Code: [Auswählen]

for(*VideoMem = *string; *VideoMem =! '/0'; *VideoMem++)
muss wenn überhaupt so lauten:

Code: [Auswählen]

for(; *string != '\0'; VideoMem++)
*VideoMem = *string sorgt dafür, dass der erste buchstabe in string in den videospeicher geschrieben wird. das ist aber nicht so sinnvoll, wenn es ein string der länge 0 ist. dann wird nämlich eine null an den videospeicher geschrieben.

die abbruchbedingung ist erfüllt, wenn der string zuende ist, nicht irgendwas im Videospeicher (*VideoMem) 0 ist. Außerdem ist *VideoMem =! '/0' syntaktischer Schrott. Es müsste wenn überhaupt *VideoMem != '\0' heissen. Von der Logik her passt es aber wie gesagt nicht.
Das VideoMem++ würd ich eher in die Schleife tun, weil das übersichtlicher wird. Dann wird die for-schleiche vereinfacht zu

Code: [Auswählen]

while(*string)

Die Schleife würde ich so schreiben:

Code: [Auswählen]

while(*string)
   {
      *VideoMem++ = *string++; // sprich den wert in *string nach *VideoMem schreiben und beide (VideoMem und string) erhöhen
      *VideoMem++ = '7';  // sprich: 7 nach *VideoMem schreiben und VideoMem um 1 erhöhen

...


Ans ende der if-Abfragen und der for-schleifen kommen auch keine Semikolons.

Code: [Auswählen]

void NewLine

soll wohl

Code: [Auswählen]

void NewLine()
heissen

das sollten alle parse-errors gewesen sein. getestet hab ichs allerdings nicht

1576

Lowlevel-Coding / Und wieder CS und DS

« am: 04. March 2005, 20:06 »

Und wann ändert sich DS (Wenn ich nicht manuell den Wert ändere) ?

gar nicht. außer du hast irgendwelchen code, von dem du nichts weisst (BIOS, anderer Fremdcode), der DS ändert.

Achja, bei Hardware-Taskswitchen ändert sich DS, aber das passiert ja nicht mal eben so ohne dein Wissen (und ist außerdem Protected Mode Stuff)

1577

Lowlevel-Coding / Und wieder CS und DS

« am: 04. March 2005, 16:03 »

DS und ES werden nicht verändert. Sonst würde die CPU unberechbar werden. Dumm ist das nicht, sondern eher das Gegenteil: Wenn Zugriffen auf SI sich DS ändern würden, würden alle nachfolgenden Speicheroperationen sonst wohin gehen. Das wäre eine ganz schöne Sauerei. (Bzw. Segment-Register-hin-und-her-gesichere ...)

1578

Lowlevel-Coding / Globale ASM Variablen in C gebrauchen

« am: 04. March 2005, 15:57 »

Code: [Auswählen]

int * var;

var = (int*)0x1234; // unsere variable befindet sich an der adresse 0x1234

*var = 1000; // in die Variable den Wert 1000 schreiben
*var++;  // die variable um 1 erhöhen

mit *var (oder var[0]) greifst du auf den inhalt zu. mit var auf die Adresse

1579

Lowlevel-Coding / Liste aller Register

« am: 24. February 2005, 14:55 »

In der ASM86FAQ sind die x86-Register bis Pentium I in Abschnitt BAW0007 CPU-Registersatz aufgelistet.

1580

Lowlevel-Coding / Re: 16, 32, 64 Bit ?

« am: 31. January 2005, 13:52 »

Klar, dass die 64-Bit schneller sind

öhm ich würd eher sagen es ist doppelt so langsam 64 bit zu lesen/schreiben/addieren/subtrahieren wie mit 32bit ...