Int 25 - MIDI - BROOK

Assembler lernen...

...aber lieber nicht mit CD 25 und großen Festplatten rummachen?

...gibt es keinen Interrupt für die Kommunikation mit einem MIDI Hardware
Instrument/Soundkarte mit MIDI-Schnittstelle?

Wieso überhaupt noch RealMode-Assembler weiterlernen? Wäre es nicht 1000mal sinnvoller, seine Zeit
in die Parallelprogrammierung zu investieren?

Assemblerprogramme im RealMode zu testen, ist heutzutage ja supereinfach - aber was ich brauche, sind gezielte Hardwarebenchmarks - dazu müsste ich bei meinem
VistaNotebook mit mit dem C++/ML arbeiten und Protected Mode Umschaltung aber
wo liegen denn hier die Gefahren? Mach ich mir z.B. bei Tests mit einem fehlerhaften Primzahlprogramm die Hardware kaputt? Ich weiß noch, wie bei
einem Freund der Rechner nach dem Experimentieren mit DPMI nicht mehr lief.
Ganz schön kompliziert...

Nobuo T

mentalmadness schrieb:

Assembler lernen...

...aber lieber nicht mit CD 25 und großen Festplatten rummachen?

mentalmadness schrieb:

...gibt es keinen Interrupt für die Kommunikation mit einem MIDI Hardware
Instrument/Soundkarte mit MIDI-Schnittstelle?

Interrupts sind keine Gottgegebenheit. Interrupts sind eine einfache Moeglichkeit, eine API bereit zu stellen. Die muss aber von irgendwo her kommen.
Also iaR. entweder vom Betriebssystem oder vom BIOS.
Ob und welche Interrupt-API zur Steuerung einer Hardware du hast, haengt vom Betriebssystem und den Treibern der Hardware ab.

mentalmadness schrieb:

Wieso überhaupt noch RealMode-Assembler weiterlernen? Wäre es nicht 1000mal sinnvoller, seine Zeit
in die Parallelprogrammierung zu investieren?

AFAIK: Weil es noch immer deutlich mehr/bessere Anfaengertutorials und -Buecher fuer alte Plattformen gibt als fuer neuere. Davon ab sind die Prinzipien der Assemblerprogrammierung seit mindestens 30 Jahren weitgehend die gleichen. "Parallelprogrammierung" (was auch immer du genau damit meinst), hat erstmal auch nicht wirklich viel mit Assembler zu tun.

mentalmadness schrieb:

Assemblerprogramme im RealMode zu testen, ist heutzutage ja supereinfach - aber was ich brauche, sind gezielte Hardwarebenchmarks - dazu müsste ich bei meinem
VistaNotebook mit mit dem C++/ML arbeiten und Protected Mode Umschaltung aber
wo liegen denn hier die Gefahren? Mach ich mir z.B. bei Tests mit einem fehlerhaften Primzahlprogramm die Hardware kaputt? Ich weiß noch, wie bei
einem Freund der Rechner nach dem Experimentieren mit DPMI nicht mehr lief.
Ganz schön kompliziert...

In Windows-Programmen brauchst (/kannst) du dich idR. nicht um Modus-Umschaltungen, Segmentierungen, Interrupts o.Ae. zu kuemmern. Das macht Windows schon von alleine. Ansonsten ist es eigentlich mit Assembler genauso schwer oder einfach, dein System zu verkrueppeln, wie mit jeder anderen vernuenftigen, Binaerprogramme erzeugenden Programmiersprache auch.

-> Vor allem in modernen Betriebssystemumgebungen ist mit "Assembler-Magie" nicht mehr wirklich viel zu reissen. Deshalb: Je nachdem was du vor hast, koennte es lohnen, die Arbeit entweder mit Windows oder Assembler noch einmal zu ueberdenken.

Vielen Dank für die ausführlichen Antworten Nobuo T!

Nobuo T schrieb:

CD259D ist der Hexcode vom Interrupt 25 + POPF, weil ja die Flags bei diesem Interrupt auf dem Stack "liegen bleiben". Ist es also kein Problem, 2GB meiner 250 großen, 48 Bit kontrollierten Festplatte auszulesen? Ich habe im Moment nur
diese eine Festplatte (schäm)

Nobuo T schrieb:

AFAIK: Weil es noch immer deutlich mehr/bessere Anfaengertutorials und -Buecher fuer alte Plattformen gibt als fuer neuere.

Stimmt, eines der besten Anfängerbücher überhaupt, dass ich kenne, ist das von Rodnay Zaks
zum Programmieren des Z80 Prozessors. Der Autor bietet das Buch als Pdf auf einer eigenen Downloadseite an:
http://www.z80.info/zaks.html

Nobuo T schrieb:

-> Vor allem in modernen Betriebssystemumgebungen ist mit "Assembler-Magie" nicht mehr wirklich viel zu reissen. Deshalb: Je nachdem was du vor hast, koennte es lohnen, die Arbeit entweder mit Windows oder Assembler noch einmal zu ueberdenken.

Also was ich vorhabe ist: Ein Betriebsystem schreiben für einen kleinen energiesparenden Roboter, welcher dann auf Friedhöfen einsetzbar ist. Dort werden nämlich ständig die Gießkannen mitgenommen und an den Gräbern liegengelassen oder in den Büschen versteckt. Aufgabe des Roboters ist, die verstreuten Gießkannen des Friedhofs alle wieder einzusammeln, am Eingang aufzuhängen(alles möglichst unauaffällig) und sich dann gut zu verstecken,
damit er nicht versehentlich selbst mitgenommen wird.

Nobuo T

mentalmadness schrieb:

CD259D ist der Hexcode vom Interrupt 25 + POPF, weil ja die Flags bei diesem Interrupt auf dem Stack "liegen bleiben".

Nochmals:
Was fuer eine API soll das sein? Eine BIOS-Standard-Funktion (dazu noch Protected-Mode kompatibel) ist das AFAIK jedenfalls nicht und sehr viel Anderes wirst du im Betriebssystembau nicht benutzen koennen.

mentalmadness schrieb:

Ist es also kein Problem, 2GB meiner 250 großen, 48 Bit kontrollierten Festplatte auszulesen?

Du kannst prinzipiell so viele GB auslesen, bis die Hardware im Dauerbetrieb unter der Belastung ausfaellt. Das koennen schon einige PB sein.
Wenn du ansonsten wirklich ein eigenes Betriebssystem mit PM schreiben willst (dazu auch noch weiter unten mehr), wirst du eh keine BIOS-Funktionen nutzen koennen und deine eigenen Treiber schreiben muessen.

mentalmadness schrieb:

Also was ich vorhabe ist: Ein Betriebsystem schreiben für einen kleinen energiesparenden Roboter, welcher dann auf Friedhöfen einsetzbar ist. Dort werden nämlich ständig die Gießkannen mitgenommen und an den Gräbern liegengelassen oder in den Büschen versteckt. Aufgabe des Roboters ist, die verstreuten Gießkannen des Friedhofs alle wieder einzusammeln, am Eingang aufzuhängen(alles möglichst unauaffällig) und sich dann gut zu verstecken,
damit er nicht versehentlich selbst mitgenommen wird.

Hm... Fuer so einen Roboter waere es IMHO ein wenig am falschen Ende verbratener Enthusiasmus, ein eigenes OS zu entwickeln. Mit dem ganzen Rest wie Hardware und das Steuerungsprogramm wirst du schon mehr als genug Arbeit haben.
Nimm also besser ein bereits bestehendes System.
Wenn du das Ganze auf einem PC aufsetzt (Embedded-PC-Teil oder Netbook), duerfte es hier ja sogar ein Windows tun. Da hast du keinen Aerger mit dem ganzen Low-Level-Kram, hast mit hoher Wahrscheinlichkeit sogar schon Treiber und mehr oder weniger ausgefeilte APIs fuer die ganze Perepherie... und kannst sobald du ein gewisses Konzept hast dann sofort mit C++ und co. mit der Entwicklung der Steuerungssoftware anfangen.