Ein paar Beispielprogramme in x86 Assembler für DOS - Teil 4: Benchmark Programm

Teil 4 - Ausgabe von farbigen Zeichen, Cursor Position holen und setzen, Messen von vergangener Zeit (5 Sekunden) und Schleifendurchläufe

Hier hat mich doch glatt die Liste von Ralph Brown (BIOS und DOS Interrupt List) auf's Glatteis geführt.

Denn dort wird der Video-Interrupt 10h mit der Funktion 0Eh zur Ausgabe von farbigen Zeichen falsch beschrieben !

Die besagte Funktion 0Eh kann nur im Grafik-Modus Zeichen farbig ausgeben, befindet man sich im Textmodus, bleibt alles monochrom.

Die Ausgabe der Schleifendurchläufe ist mit der aus den früheren Beispielen bereits bekannten Ausgaberoute (print) gemacht worden.

Die Zeitmessung geschieht durch den Vergleich des Ticks Wert an Stelle 0040:006C , der Timer läuft nämlich weiter solange keine Interrupts gesperrt sind.

Die im Programm abgewarteten 91 Ticks sind genau 5 Sekunden (ein Tick ist 1/18.2 Sekunden lang).

Die Ausgabe alteriert drei Zeichen immer im Wechsel, außerdem alle 16 Farben.

Ob das Programm auch mit einer Monochrom-Video-Karte läuft, habe ich nicht ausprobiert.

Da aber nicht in den Videospeicher direkt reingeschrieben wird, könnte es trotzdem klappen.

Im ZIP ist wieder die Quelldatei, das fertige ausführbare Programm und die kleine Batchdatei zum Erstellen drin.

Interessant ist folgendes: PCem ist mit einem emulierten Pentium MMX 233 schneller als die DOSBOX. Scheinbar hat die DOSBOX einen Zwischenspeicher nur für eine begrenzte Menge an Zeichenausgaben, beim Überschreiten der Menge wird DOSBOX recht langsam. Ein echter Rechner verhält sich da definitiv anders, PCem macht das (auch) besser.

Kleiner Zusatz:

Ich glaube ich brauche von ein paar real existierenden IBM PC kompatiblen Rechner (bis Pentium II einschließlich) mal ein paar Werte.

Es scheint, also ob PCem da auch Quatsch in Sachen Emulationsgeschwindigkeit liefert.

Mein AMD K6-2/400 Rechner mit PCI-Videokarte liefert "nur" einen Wert von 129.

Der zweite Rechner, den ich habe (ein 386DX33) startet momentan nicht, kann also keinen weiteren Vergleichswert liefern.

Der hat aber auch keine CMOS-RAM-Pufferbatterie momentan drin, bisher ging das Einschalten auch ohne... mal sehen was da los ist.

Es kann auch sein, dass die Subtraktion der zwei Timerwerte etwas optimistisch betrachtet war. Es ist ja eigentlich ein 32-Bit Wert, ich nehme aber nur den unteren 16-Bit Wert, daher kann es auch sein, dass ich vor der Messung den Ticks-Wert sichern muss, dann auf Null setzen und am Schluß wieder den gesicherten Wert (+91 Ticks) zurückschreiben muss. Da muss wohl noch ein Update her - kommt heute noch.

Hat sich geklärt, hatte lokal eine alte Version der Brown-Liste. Kann man aber wohl trotzdem überlesen (offensichtlich).

Hier eine aktualisierte Version vom Sourcecode inkl. ausführbarem Programm.

Timer Werte werden vor der Messung jetzt immer auf 0 gesetzt, und später wieder restauriert.

Der AMD K6-2/400 bringt komischerweise trotzdem weiterhin so schlechte Werte. Scheint wohl auch mit der ATI Karte zusammenzuhängen.

Mein 386DX33 habe ich wieder zu laufen gebracht, der bringt auch den Wert von 27 loops in "echt".

Scheint wohl brutale Unterschiede in Sachen Zeichenausgabegeschwindigkeit bei den Videokarten zu geben.

P.S.: Dass die Funktion 0Eh nicht im Textmode funktioniert, ist trotzdem ärgerlich, weil es das Ganze komplizierter macht.

Das ist aber ein recht guter Wert (im Vergleich).

Was für ein Grafikchip ist das denn in Deinem Compaq ?

Das der Ticks-Wert nicht immer 1/18.2 Sekunden beträgt würde ich verneinen, zumindest mit allen Rechnern die mehr als 10 Jahre alt sind.

P.S.: Wollte nicht direkt in den Grafikkartenspeicher schreiben, weil das bei CGA Karten sonst den berühmten Schnee zusätzlich erzeugt. Und ich war mir nicht sicher, ob das immer bei jeder Art von Videokarte gut geht. Manche Dinge gehen bestimmt auch einfacher, wenn man mit 386+ Code arbeiten würde, aber die Software sollte hat selbst mit einem IBM PC/XT arbeiten...

So oder so, man misst halt wie der Rechner sich in der Praxis verhält. Ich wollte ja nicht nur die CPU-Geschwindigkeit ermitteln, das wäre ja langweilig.

Da ich bisher wenig Feedback bekommen habe, stelle ich diese Beitragsserie mit dem nächsten, letzten Teil 5 ein.

Das wird das bisher größte Beispielprogramm sein, mit XMS Nutzung, und diesmal auch mit einer großen Menge an Subroutinen.

Das Programm ist noch in der Mache und hat Fehler, aber so sieht es schon mal nach dem Starten aus:

Ist ja auch noch nicht fertig

Im vogons.org Forum für die DOSBOX hat es zwar keine Erklärung gegeben, warum der Effekt mit der Verlangsamung in DOSBOX auftritt, aber es gibt eine Abhängigkeit, um das überhaupt sehen zu können. Der "Cycle" Wert muss mind. auf 4000 stehen, oder halt am Besten auf "max", dann ist die Verlangsamung schön zu sehen. Wer es nicht selbst ausprobieren will - habe ein Youtube Video davon gemacht: https://www.youtube.com/watch?v=hsuNpOgipDg ...