Turbo Pascal 3 / Assembler Profis gesucht: Aus 8-Bittern das letzte Quentchen Speed rausholen

Guten Abend!

Ich besitze einen NCR-DMV, ein 8-Bit-Bus System mit NEC V20 Cpu. Die modernste Software darauf ist TurboPascal 3 oder zB auch Wordstar 3.4 (mit Patch und zusätzlicher Hilfssoftware auch Wordstar 4). Das ganze unter DOS 2.11, 512KB RAM, 20MB Harddisk. Das Gerät ist so gut wie nicht "IBM-kompatibel" (andere Portnummern, andere BIOSdatenadressen, etc.).

Der DMV ist seit Jahrzehnten gut verstaut und ich hoffe, er läßt sich problemlos wieder in Betrieb nehmen, wenn ich erstmal einen genügend großen Arbeitsplatz dafür gefunden habe.

Jedenfalls habe ich vor, einige meiner Programme von damals (Ende 80er/Anfang 90er Jahre) nochmals zu überarbeiten, vor allem mit dem Ziel aus der Maschine mit deutlich mehr Wissen heute als damals rauszuholen was nur geht.

Nach Durchsicht einiger der sourcecodes von damals sehe ich enormes Potential zur Verbesserung in vielerlei Hinsicht und ich habe in den letzten Monaten im "Trockenen", also ohne irgendwie testen zu können, begonnen, die Programme zu überarbeiten.

Im Netz finden sich auch heute noch Tonnen an Sourcecodes (Pascal, gemischt mit Assembler), um die Turbo-eigenen Routinen durch schnellere Varianten zu ersetzen. Dabei dreht sich alles um schnelle Videoausgabe oder Ersatz der "string"-routinen wie pos(), insert(), delete(), upcase(), copy(), move() oder auch Vergleichsoperationen von Speicherblöcken, min() max() etc.

Nicht gefunden habe ich auch nur ein einziges Stück sourcecode, das sich mit den FILE procedures beschäftigt, also zB BLOCKREAD/WRITE(). Tips wie man sie optimal parametrisiert gibt es schon, aber keinen einzigen Versuch, die Routinen TurboPascals durch eigene zu ersetzen.

Die blockread-routine, der ein file-handle (nach assign(), reset()/rewrite()) übergeben wird, liest in einen vorbereiteten Speicherbereich X eine vorgegebene Menge Y Bytes einer Datei ein. Das ist natürlich in den meisten Anwendungsfällen notwendig und unumgänglich, nicht aber, wenn eigentlich mit den bytes/words (einzeln) gar nicht viel geschehen soll, sie also nicht wie zB für einen Editor lange Zeit im Speicher gehalten und im Verbund bearbeitet werden.

Wenn also wie in meiner Aufgabenstellung die Bytes/Words der Dabei nur als solche Einheiten von Interesse sind, also nicht ihre Zusammensetzung zu größeren Strukturen wie records/strings und ihre Be-/Verarbeitung minimal ist und sie sofort an ein anderes device (ser/par/vga/disk) weitergegeben werden, ist der Einsatz der von turbopascal zur Verfügung stehenden readfile-routinen in Bezug auf möglichst schenllen Programmablauf stark verbesserungsfähig.

Ein Beispiel:

Der NCR-DMV hat eine Grafiklösung (NEC yGD7220), die anders als die "IBM"kompatiblen den Videospeicher nicht an bestimmten Stellen (B000/B800) im Hauptspeicher einblendet und dort zur schnellen Bearbeitung zur Verfügung stellt, sondern nur über eine 8bit-Port ein- und ausgelesen werden können. Wie alle anderen devices auch.

Wenn nun zB auf Disk abgespeicherte Screenshots (4000 bytes, 25x80*2) eingelesen, das einzelne Attributbyte abgeändert und das Paar Zeichen/Attribut am Bildschirm ausgegeben werden sollen, so wäre die "natürliche" Programmierung in Kurzform etwa so (Pseudocode):

var buffer:[0..3999] of byte

f:file

bytesgelesen:integer;

fname = "C:\scrdata\scrshot.001"

assign(f,fname)

reset(f)

blockread(f, buffer, 4000, bytesgelesen)

show_screenshot(buffer)

Das sieht völlig normal aus und ich glaube jeder würde im Grunde die Aufgabe so lösen. Auf der Suche das letzte Quentchen Geschwindigkeit rauszuholen bin ich zum Schluß gekommen, daß das in Wahrheit hochgradig ineffizient und langsam ist.

Bei 4 involvierten 8-bit-Devices, CPU (intern 16 bit), DISK, RAM, VGA), die über einen 8bit-Bus miteinander kommunizieren, tauschen alle Geräte die Daten seriell-byteweise miteinander aus. Das geht gar nicht anders.

Was passiert auf TurboPascal-Ebene bei obigem Programm eigentlich (grob):

TPs blockread: Aufgabe: 4000 bytes von DISK in den RAM Speicherbuffer einlesen

Annahme: turbos blockread bedient sich des interrupts 21H, Funktion 3FH, und übergibt diesem dazu den file-handle (erhalten von assign()), die Anzahl der zu lesenden Bytes und die Adresse des Pufferspeichers)

Interrupt-routine:

* DISK -> BUS -> CPU (Einlesen in die CPU)

* CPU -> BUS -> RAM (Schreiben in den buffer[i])

show_screenshot: 2000 zeichen einlesen, 2000 attribute einlesen, 2000 attr nochmals einlesen, 2000 veränderte Attribute schreiben (RAM), 2000 zurück in die CPU, 2000 in die VGA

* RAM -> BUS -> CPU (einlesen Zeichen ch:=buffer[i])

* CPU -> BUS -> VGA (an den VGA schicken )

* RAM -> BUS -> CPU (attr einlesen und verändern des Attr zB: buffer[i+1]:=buffer[i+1] AND 15

* CPU -> BUS -> RAM (schreiben des Attributs nach buffer[i+1])

* RAM -> BUS -> CPU (wieder einlesen für ausgabe attribut nachg vga)

* CPU -> BUS -> VGA (an den VGA port schicken)

Wie man sieht ist verdammt viel los am BUS und im RAM. Für cycles-Fuchser viel zu viel, denn das ließe sich zb mit einem Assembler-Unterprogramm (Kernroutine) jedenfalls einfacher lösen:

2000x:

* disk -> bus -> CPU (Zeichen in CPU einlesen)

* disk -> bus -> CPU (attr in CPU einlesen)

---------------- CPU (in der CPU attribut direkt ändern)

2000x:

* CPU -> bus -> VGA (zeichen in den vga-port schreiben)

* CPU -> bus -> VGA (attr in den vga-port schreiben)

Mit vergleichsweise deutlich weniger Programmcodebytes ohne auch nur ein Datenbyte im RAM zwischenzuspeichern.

Im letzten Fall würden nur 8000 Datenbytes über den Bus geschickt werden.

Ganz anders im ersten Fall. Hier werden 4000 + 4000 + 6x2000 = 20000 Bytes über den Bus geschickt, gemeinsam mit einem x-fachen Aufwand an Programmcodebytes und der Dauer der Ausführung.

Es sollte sich hier also eine deutliche Verringerung der Gesamtablaufsdauer durch entsprechende direkte Programmierung einer "blockread"-Ersatzprozedur in einem external-Assemlberprogramm herbeizaubern lassen.

Es müßte also eigentlich eine Routine geschrieben werden, die im Prinzip das gleiche tut wie die TP-Blockread / Dos-Interruptroutine (aber keine ist), bis auf daß die Daten nicht in einen RAMbuffer geschrieben werden, sondern gleich wie hier zB an den VGA-port weitergeleitet werden.

Jetzt könnte der Einwand gebracht werden, daß es doch schneller sein müßte, einen großen Block in einem Rutsch zu lesen. Und einen großen Block in eiem zurüchzuschreiben (wohin auch immer). Das stimmt wohl für den allergrößten Teil der Anwendungen, nicht aber in einem Fall wie geschildert, wo die Daten mit minimaler Änderung, welche gleich direkt in der CPU vorgenommen werden kann, an ein Zielgerät geschickt werden sollen. Die Disk wie jedes andere Device hat einen 8 Bit Port. Alle Daten müssen stets durch dieses Nadelöhr, hintereinander. Blockzugriff hin oder her.

Ein weiterer Anwendungsfall fällt mir dazu ein, eine Datei von einem LW (A) auf ein anderes (B) zu kopieren. Auch dazu wäre ein Auslagern der Daten ins RAM unnötig und kostet enorm Zeit. Das gleiche LW darf es zwar technisch sein, aber die zehntausendfachen Lesekopfausrichtungen auf andere Sektoren wäre überaus zeitaufwändig und würde die LWsmechanik extrem belasten. Außerdem werden Sektoren immer als ganzes von der LWsintelligenz in interne Buffer gelesen, die jedesmal verworfen werden müßten, weil nach jedem Schreibvorgang neuerlich derselbe vorherige Lesesektor eingelesen werden müßte um innerhalb dessen das nächste Byte am Port auszugeben.

Ich weiß zwar, wie man mit den Lese/Schreibvorgängen über die Ports von VGA/ser/par Schnittstelle umgeht, nicht aber bei Laufwerken.

Wenn sich hier im Forum jemand damit auskennt, würde ich mich über entsprechende code-Schnippsel sehr freuen.

Pyewacket,

Zitat von Pyewacket

Unklar ist auch was du mit 2000 Zeichen an den VGA Port schicken meinst. Der DMV hat keine VGA Karte, nur

ein serielles Terminal oder/und den NEC Grafikprozessor.

ich schrieb doch:

Zitat von DoPe

Der NCR-DMV hat eine Grafiklösung (NEC yGD7220), die anders als die "IBM"kompatiblen den Videospeicher nicht an bestimmten Stellen (B000/B800) im Hauptspeicher einblendet und dort zur schnellen Bearbeitung zur Verfügung stellt, sondern nur über eine 8bit-Port ein- und ausgelesen werden können. Wie alle anderen devices auch

Zitat von Pyewacket

Du kannst von Disketten nur blockweise lesen, auch bei direkter Ansteuerung

der Hardware kann der Floppycontroller nur sektorweise lesen und in einen Speicherbereich schreiben.

Ich schrieb doch

" Außerdem werden Sektoren immer als ganzes von der LWsintelligenz in interne Buffer gelesen, die jedesmal verworfen werden müßten, weil nach jedem Schreibvorgang neuerlich derselbe vorherige Lesesektor eingelesen werden müßte um innerhalb dessen das nächste Byte am Port auszugeben."

Und ich schrieb auch:

"Die Disk wie jedes andere Device hat einen 8 Bit Port. Alle Daten müssen stets durch dieses Nadelöhr, hintereinander. Blockzugriff hin oder her."

Der Controller von HD/FD verfügt über einen internen Pufferspeicher (der WD1002 hat 1024Byte), in den jener Sektor geladen wird, der vom BIOS/DOS/Software angefordert wurde. Es entscheidet das Programm, wieivele Bytes es haben möchte, nicht der Controller.

Dagegen kann der Controller gar nicht anders, als gleich einen vollständigen Sektor (bzw. soviele wie im internen Puffer Platz haben) von der Platte zu laden, weil 1. eijn Sektor die kleinstmögliche einer Datei zugehörige Speichereinheit ist und 2. ein Sektor sowieso nur zu einer Datei gehören kann und nicht zu zweien.

Das der Controller einen ganzen Sektor in seinen eigenen Puffer erstmal einliest ist ja auch sinnvoll, weil man davon ausgehen kann, daß selbst wenn ein Datensatz in einer Datendatei nur 1 Byte Länge hat, 511 (bei 512Byte Sektoren) weitere Datensätze gleich zur weiteren Verfügung stehen, ohne daß der Controller ein weiteres Mal lesen muß.

Der Punkt ist, daß wenn ich wie beschrieben den blockread() Befehl von turbo pascal verwende, ich damit automatisch veranlaße, daß die angeforderte Anzahl an Bytes in den Buffer im RAM geschrieben werden. Das schreiben dorthin macht aber nicht der Controller - der spuckt über seinen Port einzelne Bytes aus und die gehen über den Bus an die CPU, nicht in den RAM - sondern die von blockread() selbst verwendete DOS Interrupt routine, der mitgeteilt wird, wieviele Bytes auszulesen sind was sie mit diesen Bytes machen soll: an die übergebene Adresse des Puffers im RAM schreiben.

Der HD/FD-Controller weiß nicht was mit den Bytes die seinen Datenport verlassen geschieht. Er ist nur dazu da auf Anforderung hin x Bytes zu liefern.

Eine eigenen Routine hingegen nimmt die Daten entgegen und reicht sie direkt an die VGA weiter. Ganz ohne RAM Nutzung und damit einhergehende Busaktivität. Und somit VIEL schneller.

Disk [ portnummer ] ----> CPU (entnimmt diskport 2 bytes, schickt diese direkt an -----> VGA [ portnummer ] ----> CPU nimmt die nächsten 2 Bytes entgegen - schreibt sie in den VGA-port usw.usf. bis daß alle 4000 (2000 Zeichenbytes, 2000 Attributbytes) übertragen wurden.

tofro,

siehe bitte auch meine Antwort auf Pyewacket.

Die Verwendung einer optimalen Blockgröße ist Optimierung auf TurboPascal-Ebene. und dann ist eben Schluß. Man holt damit das Maximum des Machbaren mit der blockread() Methode heraus.

Man kann dem TP aber nicht mitteilen, daß es die CPU veranlassen soll, die von der DISK kommenden Bytes in einem CPU-Register zu halten und gleich an einen VGA-Port weiterzureichen. Der TP blockread() Befehl lautet "lade x Bytes in den Pufferspeicher im RAM".

Selbstverständlich macht es Sinn statt 4000 Mal 1 Byte gleich 1 x 4000 anzufordern. Aber das ändert gar nichts an der beschriebenen Problematik - es istja die Problematik bei gewissen Anwendungen. Der "Block" hat bei gewissen Anwendungen überhaupt nichts im RAM verloren weil er dort gar nicht hingehört - das Ziel ist der VGA-RAM.

In meinem beschriebenen Szenario ist die Blockgröße, wenn man so will, 2 Bytes groß (Zeichen + Attribut). Die passen in ein CPU-Register (WORD) und können dort maximal schnell bearbeitet/verändert werden. Und dann werden die direkt dorthin gebracht, wo sie hingehören, ins VRAM und nicht ins RAM, per Portzugriff auf den Grafikcontroller.

1ST1

nein, der DMV ist eine NCR Eigenentwicklung.

tofro

Ein jedes Gerät in einem PC kann in einem Rutsch nur maximal soviele Bytes herausrücken/aufnehmen, wie breit der Bus ist an den es angeschlossen ist.

Auf einem 8-bit Bus (8088/V20 System) kann nur 1 Byte / cyklus auf die Reise von A nach B geschickt werden, auf einem 16-bit System (8086/286) können gleichzeitig 16 Bit geschickt werden, usw. bis zum heutigen 64 Bit System. Diese Busverbreiterung ist ja einer der Hauptgründe, warum die Systeme immer schneller wurden.

Alle Geräte in einem System tauschen ihre Daten immer über den Bus miteinander und es können nie mehr als x Bits/cyclus (Vielfaches von 8 jen nach Busbreite) gleichzeitig auf die Reise geschickt werden. Alle Geräte müssen sich daran halten, besser gesagt haben gar keine Wahl. Sie sind so gebaut.

Intern können Geräte mit höheren Busbreiten arbeiten, so ist ja zB bei Grafikkarten der VRAM meist mit 128/256 Bit ansprechbar.

In einem System können Geräte unterschiedlicher Busbreiten (Bussysteme) zusammen sein. Die Zusammenarbeit regeln eigene Controller ("Bridges"). Heute ist es üblich, daß man PCIXpress und PCI Steckplätze findet, davor ISA (8/16Bit) gemeinsam mit PCI (32bit) und/oder VLB zu 486er Zeiten, mein Asus P5A hat 2 ISA, 5 PCI und 1 AGP Schnittstelle, die über den 32 Bit PCI-Systembus miteinander kommunizieren. Eine Komponente mit 128Bit Ansschluß, die auf einem 32bit Bus Daten liest/schreibt, hat immer dazwischen eine "Bridge" sitzen, die zB die 128bit (16 Byte) auf 4 Byte (32Bit) runter"SERIALSIERT". Dh statt 1 x 16 Bytes zu schicken tut es dies per 4 x 4 Bytes hintereinander. Die aufgeblasenste Komponente kann immer nur soviel Bytes auf einmal schicken, wie es der Systembus erlaubt. Dh pro Systemtakt. Das gilt immer. Deswegen dauert es umso länger, je größer der Block ist, weil mehr Zyklen notwendig sind, um ihn zu übertragen.

Wieder zurück zu meinem alten 8-Bit System. Alle Komponenten haben ein 8 Bit Interface, über das sie angesprochen werden können (PORTS). Und können nur 1 Byte / Zyklus aufnehmen/rausschreiben. Weder die Festplatte noch die Flexdisk noch die Grafikeinheit noch der Hauptspeicher und auch nicht die CPU können mehr als 1 Byte / Zyklus lesen/schreiben. . Deswegen ist ja der 8086 dem 8088 in dieser Disziplin so überlegen (und nur in dieser): er ist an einem 16-Bit Bus angeschlossen und kann daher 2x soviel Bytes (/Zyklus) auf einmal entgegennehmen oder abschicken. Und wenn die anderen Komponenten auch 16-Bit Interfaces haben, dann schlägt das voll durch.

Zugriffe in Hochsprachen wie C/Pascal etc bieten über ihre eingebauten Funktionen Möglichkeiten an, die es erlauben festzulegen, wieviel Bytes pro Zugriff eingelesen/geschrieben werden sollen. Damit erhält der Programmierer die Möglichkeit zB 8192 Bytes durch 1 !!! Aufruf der Funktion zu bearbeiten. Das ist effizienter/schneller als 8192 Mal die Funktion mit einer Zugriffsbreite von 1 Byte aufzurufen:

blockread (input, 8192, buffer, bytesgelesen);

versus

for i:1 to 8192 do

blockread (input, 1,buffer, bytegelesen)

HInter der Fassade der blockread-funktion wird aber in beiden Fällen eine dos-funktion aufgerufen, die bei einem 8-bit Port die Bytes EINZELN hintereinander vom Diskcontroller einliest, in jener Anzahl wie sie beim Aufruf der blockread-funktion übergeben wurde.

Und dahinter macht der Diskcontroller unabhängig von der gewünschten Anzahl an Bytes folgendes: er liest IMMER mindestens 1 Sektor in seinen internen Puffer ein (je nachdem wie groß der Puffer ist), unabhängig ob die Datei 1 Byte oder 100KB groß ist, ein. Der Sektor ist die kleinste Verwaltungseinheit des Controllers und eine Datei belegt immer mindestens 1 Sektor, auch wenn sie nur 1 Byte groß ist.

Byte für Byte gilt übrigens auch für sogenannte DMA Zugriffe.

Die Technik ist nur eine andere und erfordert einen DMA-Controller am Systemboard und die explizite Fähigkeit der involvierten Komponenten, DMA Zugriffe durchführen zu können. Der Vorteil der DMA Methode liegt nicht darin, daß es so etwas wie einen DMA Bus gäbe, über den parallel X Bytes / Zyklus übertragen werden können. So einen Bus gibt es nicht.

Er liegt darin, daß abgesehen vom Setup der beiden Komponenten (also der Programmierung der Komponenten daß sie jetzt gleich einen DMA-Vorgang durchführen sollen), die CPU während des Ablaufs nicht involviert ist und sich anderen Dingen widmen kann. Die beiden Komponenten wissen nach ihrer Programmierung was zu tun ist und tun dies nach dem Startsignal selbständig. Und transferieren dann ganz normal wie sonst auch X Bytes einzeln hintereinander (es ist nur Platz für 1 Byte am 8 Bit Bus) über den Bus.

fritzeflink

Hallo flinker fritz

Ich kenn mich hier mit der forensoftware noch nicht so aus .... bei deinem obigen posting erscheint bei mir eine grafik unterhalb des zitats mit glocke und such-symbol in olivgrün und darunter weiß auf schwarzem hintergrund das Wort "Konversationen". Es sieht so aus als ob man darauf klicken könnte, aber man/ich kann nicht.

tofro

Ich schrieb das alles in einem ganzen Absatz zur DMA Behandlung wie das dabei zugeht; DMAing ist aber sowieso für meine Aufgabenstellung irrelevant.

ich antwortete auf diesen Part

Zitat von tofro

halte es aber für extrem unwahrscheinlich, dass der Floppycontroller einzelne Bytes zum Abholen bereitstellt. An sich hat man schon sehr früh gesehen, dass das extrem unperformant ist.

und habe damit erklärt, daß der FloppyController sehr wohl wie jedes andere Gerät auch, die Bytes immer nur einzeln rausrückt. Er kann nicht anders. Das ist der Punkt.

Diese einzelnen Bytes wandern - wenn nicht DMA-Methode eingesetzt wird - IMMER in die CPU. Und dort kann der Programmierer entscheiden, was mit dem Byte geschieht.

In der TP-Variante blockread() wird das byte aber in den RAM geladen. So ist nunmal die TP-Routine programmiert.

Im RAM brauche ich es aber gar nicht, hat dort nichts verloren außer viel Zeit um dorthin zu kommen. Und muß von dort erst wieder über den Bus in die CPU geschoben werden, um dann von dort in den VGAport geschoben zu werden. Diese unnötige Hin-/Herschieberei kann und soll eingespart werden.

Die Aufgabe besteht ja gerade darin, eine eigene Routine für das Einlesen der Bytes der Datei in die CPU zu schreiben. Das weiß ich nicht wie das genau geht, weil man ja die sonst verwendeten DOS/BIOS Routinen selbst schreiben muß. Man muß an die Hardware ran.

In der von mir erwünschten Variante wird das Byte das vom Port des Diskcontroller kommt postwendend an den VGA-Port geschickt:

Die Kernroutine in Assembler sieht (um Statusabfragen an den Ports DataREADY/BUSY/etc hier gekürzt) etwa so aus:

mov cx, 4000

doit:

IN AL,PortDiskcontroller

OUT VGAController, AL

loop doit

Noch schneller kann man kein Byte und auch keinen noch so großen "Block" an Bytes auf einem 8-Bit System von einem Port zum anderen schicken .

Und "Block"s werden explizit durch die Schleife abgearbeit. Das ist unter "Block" / "In einem Rutsch" zu verstehen. Nie anders. Ob 8, 16, 32, ... Bitsystem wird ein "Block" in jenen Häppchen über den Bus geschoben, die der Bus in seiner Breite hergibt. Und der Schleifenzähler gibt die Anzahl der Happchen an.

Der Teil der mir fehlt ist jener Programmcode bevor die Schleife beginnt, um den Diskcontroller dazu zu bringen, die Bytes zu übergeben.

Danke für den Tip, aber der DMV hat einen WD1002. Habe die Beschreibung gerade vor mir am Bildschirm

Mal sehen ob ich mit meinen Amateurfähigkeiten das selbst hinkriege ...

Der WD1002 im DMV ist eine Variante, die den Flexcontroller beinhaltet.

Aber um das Lesen von der Flex geht es mir vorerst gar nicht. Das FLexlaufwerk ist sowieo dermaßen dominierend langsam (Anlaufzeit, Positionierungszeit, Lesezeit), daß eine Beschleunigung hier zwar auch möglich wäre, meßbar, aber für den Benutzter kaum merkbar.

Ich konzentriere mich erstmal auf die Harddisk.

PAW

Zitat von PAW

bei deinen Betrachtungen betreffend Busbelastung gehst du immer nur von den Daten aus. Bei einer Befehlsschleife mit der CPU wird der Bus aber auch noch zusätzlich mit den Instruktionen (OP-Codes) belastet. Dies fällt bei einem DMA-Transfer praktisch weg. Da du aber mit den Daten noch etwas in der CPU tun möchtest, fällt die DMA sowieso raus.

richtig :),

jedes byte braucht seine zeit; daß opcodes auch nichts anderes sind als Daten (für die Cpu) die im RAM stehen und von dort erstmal geholt werden müssen und sich den Bus mit den anderen daten teilen schrieb ich allerdings bereits:

Zitat von DoPe

Ganz anders im ersten Fall. Hier werden 4000 + 4000 + 6x2000 = 20000 Bytes über den Bus geschickt, gemeinsam mit einem x-fachen Aufwand an Programmcodebytes und der Dauer der Ausführung.

Deswegen wäre eine erfolgreiche Implementierung meiner Idee ja so interessant: wenig programmcode, schnelle cpu befehle, mimimalste busbelastung weil kein Byte unnötig bewegt wird, keinerlei Involvierung langsamer RAM-Zugriffe.

Das Geheimnis liegt im sourcecode des Int 21H / Unterfunktion 3F bzw. der darunterliegenden Bios Routinen

Sie ist eigentlich ein Doppelung der blockread() procedure von TurboP

TP: blockread ( filehandle, buffer, anzahl (,recsread))

Int21:

Man sieht daß blockread() nur ein Wrapper ist, der optional als 4. Parameter die tats. gelesene anzahl zurückgibt.

Wie ich oben schrieb scheint blockread() nur ein wrapper für den int 21/3Fh zu sein. Die bei blockread() übergebenen Parameter werden einfach in die entsprechenden regs geschoben und dann int 21 aufgerufen. Im Prinzip weiß ich also mittlerweile, was blockread() macht. Aber bin damit dem Ziel nur einen Millimeter weiter.

Die Interruptroutine ist es, die die Daten zurückschreibt in den der blockread()prozedur übergebenen puffer. da redet tp gar nicht mehr mit. Was es also braucht ist das Wissen, was der int21 dann eigentlich konkret macht, allso wie er es umsetzt, daß der wd-controller die gewünschten Daten schickt.

Die Frage könnte auch lauten: Wie schreibe ich einen Festplattentreiber für Dos. Von diesem Wissen brauche ich nur einen ganz kleinen Teil.