Pause+Enter Patch (siehe Project)
 

Wir OpenAccess-User kennen ja alle das Problem:

Wenn man oavision in der NTVDM unter windows startet, dann geht die CPU-Last auf 100% und oa tut solange nix, bis man PAUSE + ENTER drückt, dann startet es. Ein lästiges Problem, was leider auch im dosemu unter Linux auftritt. Der Workaround mit PAUSE+RETURN geht zwar unter Windows, unter Linux über ein Terminal funktioniert das mit dem Pause aber leider nicht mehr.

Grund genug, das Problem zu analysieren und zu beheben.

Ich habe mich also mit meinem Debugger mal auf die Suche gemacht und bin dabei auf folgende Schleife gestoßen, in die ich eigentlich immer reingekommen bin. Ich habe sie rudimentär kommentiert, damit man hoffentlich auch als Assembler-Unkundiger ungefähr versteht was hier los ist:

Aufgefallen ist mir, dass, sobald ich in den Debugger reingebreakt bin und dann den Programmfluss fortgesetzt habe, OA relativ schnell da war. Nur wenn mans einfach so aufgerufen hat wieder die hohe CPU-Auslastung. Denkt man dann an den Workaround mit PAUSE+ENTER wird einem schnell klar, was hier abläuft: Drückt man PAUSE, hält man temporär den Programmfluss an, drückt man eine beliebige Taste setzt man ihn wieder fort. Durch das kurzfristige Anhalten bewirkt man, dass zwischen den beiden "Get System Time" - Aufrufen eine Unterbrechung entsteht. Wenn wir dann noch die Geschwindigkeit heutiger Rechner und der Rechner vergleichen, für die OA entwickelt wurde kommt man zu dem Schluss: Die Differenz ist auf modernen Systemen und in der VDM ziemlich lange <2, was bewirkt, dass die Funktion sehr lange loopt.

Das Umgehen des Problems ist dann auch schnell mit einem 1-Byte-Patch getan:


Update 28.11.2008:
Das Ganze funktioniert übrigens auch für die Runtime CMP.SPI. Der Patcher berücksichtigt nun auch die Runtime. Assembler-Sourcecode vom Patcher gibt's auf Anfrage... ;)

Doch halt! Update 07.12.2008:
Wie Leser Gerd unten richtig bemerkt hat, funktioniert dann das Music-Kommando nicht mehr richtig, da die verbleibende Wartezeit 1 ist!
Für einene saubereren Workaround also bitte unten meinen Artikel lesen.
Ich habe meinen angehängten Patcher in patch.zip entsprechend auf die neue Methode aktualisiert, dieser Patch überspringt nicht nur die lästige Warteroutine am Programmanfang sondern korrigiert auch das Timing-Verhalten.
Bitte vor dem Patchen die OA4.SPI sichern, sicher ist sicher...!

Beim Debuggen ist mir dann auch aufgefallen, warum oa4.exe im Vergleich mit oavision relativ langsam läuft:

OA4 verwendet zur optimierten Bildschirmausgabe Informationen über den Vertical Retrace aus dem VGA I/O Port 3DAh. Dies funktioniert zwar auf einer echten VGA-Karte sehr schnell, wenn man das Ding allerdings in der NTVDM laufen lässt kann man den I/O Port nicht direkt abfragen und die VDM muss das Syncen übernehmen, was sehr langsam ist. Daher die verzögerte Ausgabe. Wen's interessiert kann sich The vertical retrace durchlesen. OAVISION verwendet hingegen einen Videotreiber, welcher die Ansteuerung übernimmt und da fällt das Ganze dann weg.
Der Code ist im Prinzip folgender:
Wer auch dieses "Problemchen" beheben will: Es reicht, den Sprung in der ersten einfach
einfach auszuNOPpen.
Also für die Hexeditor-Benutzer: Suche nach und ersetze die zwei folgenden Bytes durch .
Bequemer geht's wieder mit angehängtem Patch vdmpatch.zip. Auf einem echten DOS-System bringt dieser Patch aber eher Nachteile, also nur für Benutzer interessant, die OA4 in einer VDM z.B. unter Windows oder Linux betreiben.
Nachdem man das Problem mit oavision ja umschiffen kann ist der Patch wahrscheinlich hauptsächlich für Benutzer der Runtime CMP.SPI interessant.

Update 04.12.2008:
Asche auf mein Haupt! Der alte Patcher hatte einen Fehler und hat die falschen Bytes an die falsche Stelle gepatcht.. Sowas Dummes, ist mir erst jetzt aufgefallen. Ich habe den vdmpatch.zip aktualisiert, jetzt sollte es passen. Als Entschädigung kann er dafür auch OA3 patchen.

Einen weiteren Tip gibt's dann zum Abschluss noch für die Verwendung von OA4 mit Dosemu:

Leider verbraucht das Programm 100% CPU-Leistung in dosemu, weil es ja für dne Realmode ausgelegt ist und daher die CPU normalerweise für sich beanspruchen und schön die Tastatur pollen kann. Nachdem das aber doch einiges an Saft verbraucht und eigentlich nicht nötig ist gibt's auch dafür nen schönen Workaround (ist nicht von mir, aber die Idee ist gut):

auslast.zip

Einfach die auslast.com vor dem Start von OA ausführen. Das Ding hängt sich in den Tastaturinterrupt 0x16 als TSR hinein und setzt ein paar Release Current Virtual Machine Time-Slice Kommandos ab, was die VM zwingt, den Timeslice aufzugeben. Das funzt auch im dosemu, nicht nur unter Windows (dort hat man das Problem ja nicht) und senkt die CPU-Last merklich.

Soda, genug OA-Optimierung für heute ;)

EDIT: Die Patcher findet ihr im Download Bereich !

Super, und einen Dank an alle, die sich noch so unermüdlich mit dem Datenbank-Oldie OA auseinandersetzen und immer noch Lösungen anbieten.

Funktioniert Super ! Vielen Dank.

Ein kleiner Nachteil hat sich jedoch dadurch eingestellt:
Um einen automatischen Import (Lager Barcode-Buchungen) aus eine Fremdsystem durchzuführen, hatten wir im OA eine Schleifenfunktion programmiert, die nach Ablauf (Alle 5 Minuten) nachsieht ob eine Neue Importdatei vorliegt.

MUSIC (25000,20000) ! (Frequenz,Dauer)

Auch ein hochsetzten der Dauer bringt nichts. Der Import startet sofort wieder ohne die 5 Minuten zu warten.

Jedoch der Vorteil überwiegt ! Super !

Gruß Gerd Schmitz

Lob !!

Und die Sache mit AUSLAST.COM ist
für mich - und andere Anwendungen - nochmal so genial

Danke
Martin

Hallo Gerd,

Irgendsowas in der Art habe ich befürchtet.

Also ich erklär mal die Problematik, viell. fällt euch was ein: Mit dem jetzigen Patch ist die Delayzeit, die er sich errechnet eigentlich immer 1, dh. solche Verzögerungsschleifen wie bei MUSIC gehen nimmer.

Ich habe auch dieses Problem mal etwas genauer unter die Lupe genommen:

Mit der bisherigen PAUSE+Enter Methode war das Ganze auch schon ein bisserl so wie Russisches Roulette: Wenn mans ganz schnell drückt ist der Wert der Delayschleife relativ klein, MUSIC wartet kürzer. Lässt man sich mit Pause+Enter Zeit rennt die Schleife länger und MUSIC wartet dementsprechend auch länger. Selbst wenn man auf PAUSE+ENTER verzichtet erhält man tw. unterschiedliche Werte je nachdem, wie der Task Scheduler des Multitasking-Betriebssystems arbeitet. Bekommt der Prozess mal nicht die volle Rechenleistung ist eventuell die Abbruchbedingung mit 2 erfüllt und der Wert entspreicht jenem zum Zeitpunkt des Abbruchs.

Ist euch viell. auch schon aufgefallen, ohne PAUSE+Enter wartet OA4 beim Start auch unterschiedlich lang.

Insofern lässt sich für ein Multitasking-System kein wirklich "korrekter", eindeutiger Wert ermitteln.
Ich bin nun also auf Ideensuche, wie man das Problem am Besten umschiffen kann. Eine Idee wäre, dass man von einem alten PC den Wert ermittelt und dann auf die CPU-Geschwindigkeit hochrechnet, bräuchte man aber irgendeine Formel dafür. Man könnte theoretisch auch nen Wert hardcodieren aber das ist dann auch keine saubere Lösung. Hat irgendwer ne Idee wie man das Ganze "sauber" lösen könnte? Bin für Vorschläge offen. :)

Was Du einstweilen als Workaround machen kannst:
Bei mir lag der Delaywert so grob gepeilt um die 700h. Dh. du kannst den Initialisierungswert des Resultatregisters BX einfach von 1 auf 700 ändern. Dazu musst Du nur folgenden zusätzlichen Patch mit Deinem Hexeditor machen:

Suche nach Wie man sieht entspricht das dem Anfangscode der Routine. Wie man oben im Disassemblierten Code sehen kann befüllt er am Anfang die Variable mit dem Wert 1. So, und wir ändern das nun auf den Wert der Deinem System entspricht.
Dazu patcht Du die Bytes aus oben genannter Sequenz auf Deinen Initialisierungswert (bei mir also 700h)
Achtung: Wir sind auf einer Intel-CPU, also ist das Little Endian (also quasi "vertauscht")!
Wenn Du auf 701h patchen willst ändere einfach 00 auf 07 und fertig.
Alles unklar?

EDIT: Auf meinem Notebook mit einem Pentium 4 / 1.4 Ghz habe ich 00 07 eingetragen.
Bei music (20000, 200) habe ich dann die gewünschten ~ 2 sek. Delay.

UPDATE: Ludwig hat den VDMPATCH wegen einem Fehler upgedated. Die neue Version ist im alten Thread zu finden. Nachdem wir auch ein Problem mit dem Mailversand hatten schreibe ich hier im Anschluß dazu um zu sehen ob nun auch wieder Nachrichten aus dem Forum versendet werden.

UPDATE:
Nachdem ich eine saubere Lösung für Gerds Problem mit dem music-Aufruf wollte, habe ich mich das Wochenende mal etwas genauer damit auseinandergesetzt.
Folgende Erkenntnisse hat das Ganze gebracht:
1) Das Ergebnis dieser Schleife am Anfang des Programms scheint wirklich nur für music() verwendet zu werden (wenn wer was anderes entdeckt bitte melden!).
2) Die Erkenntnisse, die bereits in meinem vorhergehenden Post erwähnt wurde:
Die Schleife frisst 100% CPU-Zeit, das lastet den Prozessor unnötig aus und ist unter Multitasking-Systemen inakkurat (v.A. wenn man mit PAUSE+Enter abbricht).

Der hier nun vorgestellte Patch hat folgende Vorteile:
1) Er lastet die CPU nicht zu 100% aus, die VDM wird freigegeben.
2) Das timing ist in Multitasking-Umgebungen um einiges exakter als mit der OA-eigenen Methode
3) Er beseitigt natürlich - was ja die ursprüngliche Intention war - die lästige Warteroutine beim OA4-Start.

Zur Funktionsweise:
Nachdem Gerd das Problem gemeldet hat, habe ich mir einmal den originalen Code der music-Routine angesehen und auch gesehen wo er im Speicher liegt (die relevanten Teile habe ich kommentiert):

Es wird also gewartet, indem die Anzahl der beim Programmstart errechneten Zyklen geloopt, die CPU also solange mit einer Schleife beschäftigt wird, bis die jeweilige zehntelsekunde abgelaufen ist.

Außerdem habe ich entdeckt, dass derselbe Code nicht nur in OA4.SPI sondern auch noch in APP.SPI zu finden ist, wir müssen also beide Dateien patchen.

So, nun stellt sich die Frage nach einer vernünftigen Lösung fürs Warten.
Mal sehen, ob es DOS/BIOS-Funktionen hierfür gibt.
Grundsätzlich gibt es sie:
Einmal die Die BIOS-Wait funktion des INT15h und einmal die MS-DOS 4 SLEEP-Funktion.
Also gleich einmal ausprobieren, ob sie funktionieren. Es stellt sich jedoch bald Ernüchterung ein: Sie funktionieren problemlos in "echtem" DOS, die NTVDM zeigt sich aber ziemlich unbeeindruckt und scheint keine der beiden Funktionen zu unterstützen. Das war's dann also mit der Idee vom relativ einfachen Patch.
Doch es muss ja auch noch andere Möglichkeiten geben. Wenn es nicht so komfortabel geht, muss man sich wohl seine eigene Warteschleife bauen.

Wie stellt man das nun am Besten an?
Hier kommt einem der programmierbare Zeitgeberbaustein 8253 in den Sinn, welcher für die Echtzeituhr zuständig ist.
Dieser erhält die Schwingungen des Oszillators 8284, welcher 1.193.180 Impulse pro Sekunde erzeugt. Dieser Zeitgeber wird übrgens auch zur Tonerzeugung mit dem PC-Speaker verwendet. Der dritte der 3 verfügbaren Timer ist mit dem PC-Speaker verschaltet und gibt dann in entsprechender Frequenz Signale, sodass ein Ton entsteht. Der erste Timer wird für die Systemzeit verwendet und schwingt 18.2mal pro Sekunde. Dem 8253er Baustein kann man nun mittels eines Divisors mitteilen, dass dieser seinen internen Zähler nur dann um 1 erhöhen soll, wenn entsprechend viele Durchläufe vergangen sind. Den Wert des Systemzeitgebers kann man aus dem BIOS-Datenbereich an 46Ch auslesen.
Die Idee ist daher folgende: Man stelle den Sytemzeitgeber so um, dass er mit 10Hz läuft und bei jedem Inkrementieren des Zählers ist eine der Zehntelsekunden, die der User als Dealy-Wert angibt, vergangen. Der Divisor für ein 10Hz-Signal wäre somit 119318. Aber halt! Der Wert ist für ein 16bit-Register zu groß! Bleibt uns also nur der Divisor 11931, welcher dann ein 100Hz-Signal erzeugt.. Reicht ja auch zum Messen, warten wir halt die entsprechende Anzahl an Durchläufen ab.
Während man nun wartet, bis der Timer entsprechend hochgezählt hat, sollte man nun zwecks Vermeidung von hoher CPU-Auslastung den Timeslot der VDM freigeben. Dies geschieht mit bereits oben vorgestellter Funktion Release Current Virtual Machine Time-Slice.
Nach getanener Arbeit muss man natürlich den Timer wieder auf seinen ursprünglichen Wert zurücksetzen.

Soviel zur Theorie. In der Praxis klingt das zwar recht nett, aber eine Routine, die das alles bewerkstelligt braucht natürlich entsprechend viel Platz. Nie und nimmer bekommt man die in dem durch das eliminieren der Schleife freigewordenen Platz unter. Was also tun?

Wer sich das oben angegebene Codestück genauer angesehen hat wird folgendes feststellen: Direkt nach der music()-Routine befindet sich unsere altbekannte Berechnungsroutine vom Programmstart. Nun ja, die brauchen wir ja eignetlich nicht mehr, die nervt uns sowieso nur. Es erscheint also naheliegend, den Code durch unsere neuen Warte-Routine zu ersetzen und mittels CALL anzuspringen. Natürlich dürfen wir nicht den Anfangscode der Routine überschreiben, sonst würde es uns beim Programmstart zerbröseln. Stattdessen lassen wir ihn das Register BX beschreiben, fügen danach einen Sprung ans Ende der originalen Routine ein, wo die Stackvariable entsprechend gesetzt wird und lukrieren den dazwischen freigewordenen Platz für uns.
Aber das Ganze ist immer noch relativ wenig Platz, weshalb man durch trickreiche Programmierung das Ganze irgendwie reinbekommen muss. Wie ich das Ganze dann gelöst habe ist dem unten stehenden Code zu entnehmen, ich werde darauf garnicht weiter eingehen, kann sich jeder selbst ansehen. 1 Byte ist sogar noch frei geblieben und wurde mit einem NOP aufgefüllt ;)

Hier ist der Code, durch den ich den originalen ersetzt habe:
Für all jene, die die Routine mit dem Hexeditor in ihre OA4.SPI, APP.SPI und CMP.SPI hineinpatchen wollen: In den Zeilen mit Assemblercode steht - wie unschwer zu erkennen ist - links neben den Mnemonics die Bytesequenz.

Zum Download
Nachdems doch ganz schön viel zu patchen ist, empfehle ich, besser die neue Version meines Patchers zu verwenden, welcher wieder am 1. Beitrag oben angehängt ist. Bitte vor dem Patchen die originale OA4.SPI wieder zurückkopieren, um sicherzugehen, dass der Patch sauber funktioniert.

..und dann soll noch einer sagen, wir Assembler-Programmierer würden nicht mehr gebraucht werden :D
Feedback, ob es bei euch funktioniert ist erwünscht!

Schönes verlängertes Wochenende!

Hallo Leecher,

es funktioniert perfekt - das ist eine Leistung, die den Nobelpreis verdient! Die Geschwindigkeitssteigerung im Fenster ist unglaublich.

Gruß
Hans Jürgen (hjlint#)

P.S.: Kann es sein, dass der Patcher die OA3.SPI vergißt?

P.P.S.: Und wenn gerade mal jemand am Patchen ist: kann man die automatisch eingesetzte 19 bei 2-stelliger Eingabe einer Jahreszahl nicht mal auf 20 umpatchen? Ist eigentlich noch lästiger als Pause-Enter und kommt häufiger vor.

Hallo Hans Jürgen!

Prima, wann ist die Preisverleihung? :D
Gut zu wissen, dass es nicht nur bei mir und Günther funktioniert. :)

Du meinst beim normalen timing-Patch? Ich hab ein OA3 hier, das hat diese Schleife am Anfang nicht, die gibt's meines Wissens nach ja nur bei OA4. Oder hat OA3 auch so ein Problem?