OA III/IV Open Access Pause+Enter Patch (Download siehe Button oben)

[leecher]

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:

cs:1B28 BB0100         mov    bx,0001
cs:1B2B 32E4           xor    ah,ah
cs:1B2D CD1A           int    1A    ; Get System Time 
cs:1B2F 52             push   dx
cs:1B30 8BC3           mov    ax,bx
cs:1B32 B9F10A         mov    cx,0AF1
cs:1B35 E2FE           loop   1B35    ; AF1mal einfach hier loopen
cs:1B37 48             dec    ax
cs:1B38 75F8           jne    1B32    ; Schleife je nach Systemtime
cs:1B3A 32E4           xor    ah,ah
cs:1B3C CD1A           int    1A    ; Nochmal systemtime holen
cs:1B3E 59             pop    cx
cs:1B3F 3D0100         cmp    ax,0001    ; Mitternacht vergangen?
cs:1B42 74E4           je     1B28    ; ..dann nochmal
cs:1B44 2BD1           sub    dx,cx    ; Differenz errechnen
cs:1B46 83FA02         cmp    dx,0002
cs:1B49 7307           jnb    1B52    ; >=2, dann ok
cs:1B4B F8             clc
cs:1B4C 43             inc    bx
cs:1B4D 73DC           jnb    1B2B
cs:1B4F BBFFFF         mov    bx,FFFF    ; Return -1, Fehlgeschlagen
cs:1B52 36891E3219     mov    ss:[1932],bx
cs:1B57 CB             retf        ; Und Ende 
 

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:

PHP-Code:

1) Open Access IV beenden
2) Öffnet die OA4.SPI oder die CMP.SPI je nachdem was ihr patchem wollt 
mit einem Texteditor der auch HEX Suche kann. 
3) Sucht nach: 3D 01 00 74 E4 2B D1 83 FA 02 und ändert den Wert 
ganz hinten von 02 auf 00 


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:

cs:2BEA BADA03         mov    dx,03DA       ; I/O Port 03DA
cs:2BED 2E8B0E202C     mov    cx,cs:[2C20]
cs:2BF2 AD             lodsw
cs:2BF3 8BD8           mov    bx,ax
cs:2BF5 EC             in     al,dx         ; Einlesen
cs:2BF6 D0D8           rcr    al,1          ; Sync?
cs:2BF8 72FB           jb     2BF5          ; Nein, dann nochmal.
cs:2BFA EC             in     al,dx
cs:2BFB D0D8           rcr    al,1
cs:2BFD 73FB           jnb    2BFA 

Wer auch dieses "Problemchen" beheben will: Es reicht, den Sprung in der ersten einfach
einfach auszuNOPpen.
Also für die Hexeditor-Benutzer: Suche nach

AD 8B D8 EC D0 D8

und ersetze die zwei folgenden Bytes

72 FB

durch

90 90

.
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 !

[RKabis]

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

[Gerd.Schmitz]

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

[mhonline]

Lob !!

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

Danke
Martin

[leecher]

Hallo Gerd,

Zitat von Gerd.Schmitz

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.

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

BB 01 00 32 E4 CD 1A 52

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

01 00

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?

[waldbauer.com]

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.

[waldbauer.com]

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.

[leecher]

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):

cs:1B00 8AC4           mov    al,ah
  cs:1B02 E642           out    42,al        ; Timer 3 für Frequenz Speaker setzen
  cs:1B04 E461           in     al,61
  cs:1B06 8AE0           mov    ah,al        ; Alten Wert sichern
  cs:1B08 0C03           or     al,03
  cs:1B0A E661           out    61,al        ; Speaker ein
  cs:1B0C 368B163219     mov    dx,ss:[1932]    ; Delayzyklen laden
  cs:1B11 B9D80E         mov    cx,0ED8
  cs:1B14 E2FE           loop   1B14
  cs:1B16 4A             dec    dx        ; .. und solange loopen bis
  cs:1B17 75F8           jne    1B11        ; verbraucht
  cs:1B19 4B             dec    bx
  cs:1B1A 75F0           jne    1B0C        ; und das für alle 10ms intervalle
  cs:1B1C 8AC4           mov    al,ah
  cs:1B1E E661           out    61,al        ; Speaker aus
  cs:1B20 CA0400         retf   0004        ; bye
  cs:1B23 0000           add    [bx+si],al    ; Start Müll...
  cs:1B25 00FF           add    bh,bh
  cs:1B27 FF             db     FF        ; ..Ende Müll
  cs:1B28 BB0100         mov    bx,0001        ; Einsprungpunkt Timerloop
  cs:1B2B 32E4           xor    ah,ah        ; Den Rest kennen wir ja schon...
  cs:1B2D CD1A           int    1A
  cs:1B2F 52             push   dx
  cs:1B30 8BC3           mov    ax,bx
  cs:1B32 B9F10A         mov    cx,0AF1
  cs:1B35 E2FE           loop   1B35
  cs:1B37 48             dec    ax
  cs:1B38 75F8           jne    1B32
  cs:1B3A 32E4           xor    ah,ah
  cs:1B3C CD1A           int    1A
  cs:1B3E 59             pop    cx
  cs:1B3F 3D0100         cmp    ax,0001
  cs:1B42 74E4           je     1B28
  cs:1B44 2BD1           sub    dx,cx
  cs:1B46 83FA02         cmp    dx,0002
  cs:1B49 7307           jnb    1B52
  cs:1B4B F8             clc
  cs:1B4C 43             inc    bx
  cs:1B4D 73DC           jnb    1B2B
  cs:1B4F BBFFFF         mov    bx,FFFF
  cs:1B52 36891E3219     mov    ss:[1932],bx
  cs:1B57 CB             retf 

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:

cs:1B06 8AE8           mov    ch, al        ; In ch-Register statt ah, cx bleibt ja unberührt
 cs:1B08 0C03           or     al,03
 cs:1B0A E661           out    61,al        ; PC-Lautsprecher ein    
 cs:1B0C 90             nop            ; 1 Byte blieb übrig ;)
 cs:1B0D 1E             push   ds        ; DS sichern
 cs:1B0E 33D2           xor    dx,dx
 cs:1B10 8EDA           mov    ds,dx        ; DS auf 0 legen fürs Lesen von BIOS-Dataarea
 cs:1B12 BA9B2E         mov    dx,2E9B        ; 100hz Timerauflösung für 8523-5 Baustein
 cs:1B15 E82D00         call   1B45        ; Divisor setzen
 cs:1B18 E81200         call   1B2D        ; Warteroutine aufrufen
 cs:1B1B 1F             pop    ds        ; DS wiederherstellen
 cs:1B1C 8AC5           mov    al,ch        ; Aus ch statt ah-Reg. holen
 cs:1B1E E661           out    61,al
 cs:1B20 CA0400         retf   0004
 cs:1B23 0000           add    [bx+si],al    ; Start Müll
 cs:1B25 00FF           add    bh,bh
 cs:1B27 FF             db     FF        ; Ende Müll
 cs:1B28 BB0100         mov    bx,0001        ; Loopwert mit 1 init (unbrauchbar!)
 cs:1B2B EB25           jmp    1B52        ; Zur Initialisierung d. Speicherstelle und ret
 cs:1B2D BA0800         mov    dx,0008        ; -- Hier beginnt unsere Delayroutine --
 cs:1B30 03166C04       add    dx,[046C]    ; Endzeit in dx
 cs:1B34 B88016         mov    ax,1680        ; Release current VM timeslice
 cs:1B37 CD2F           int    2F        ; CPU in VM entlasten!
 cs:1B39 3B166C04       cmp    dx,[046C]    ; Loop abgelaufen?
 cs:1B3D 79F5           jns    1B34        ; Nein -> Warte weiter
 cs:1B3F 4B             dec    bx        ; Warteschleife bis zum Ablauf der Zeit
 cs:1B40 75EB           jne    1B2D
 cs:1B42 BAFFFF         mov    dx,FFFF        ; Timer 0 des 8523-5 wiederherstellen
 cs:1B45 B036           mov    al,36        ; Setze Timeraufl.
 cs:1B47 E643           out    43,al
 cs:1B49 8BC2           mov    ax,dx
 cs:1B4B E640           out    40,al
 cs:1B4D 8AC4           mov    al,ah
 cs:1B4F E640           out    40,al
 cs:1B51 C3             ret            ; Fertig 
 

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
Feedback, ob es bei euch funktioniert ist erwünscht!

Schönes verlängertes Wochenende!

[Hans Jürgen]

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.

[leecher]

Hallo Hans Jürgen!

Zitat von Hans Jürgen

es funktioniert perfekt - das ist eine Leistung, die den Nobelpreis verdient!

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

Zitat von Hans Jürgen

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

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?

[waldbauer.com]

Zitat von Hans Jürgen

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.

Der 2000er Patch ist bei DISPI direkt zu bekommen :-)
http://www.do-it-so.com/index.php?ds=&page=DOWNLOAD

[Hans Jürgen]

Zitat von leecher

Hallo Hans Jürgen!

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?

Hallo Leecher,

habe die OA3.SPI von Hand genau nach Deiner Anleitung gepatched und danach war das Timing-Problem weg. Die Hex-Suche hat zumindest genau Deinen String gefunden, ich habe die 02 durch 00 ersetzt und wir sparen uns jetzt mit 6 Mann täglich mindestens 2 Tastendrücke. Du kannst den Patcher somit auf die OA3.SPI erweitern, wenn Du willst, dann ist er universell.

Noch besser kommt allerdings der VDM-Patch. Wir konnten bisher im Fenster nicht arbeiten, da schnelle Tastatureingaben hoffnungslos verschluckt wurden. Also immer Umschalten in den DOS-Vollbildmodus und zurück. Jetzt ist es im Fenster augenscheinlich schneller als im Vollbild.

Gruß und nochmals vielen Dank,
Hans Jürgen

[Hans Jürgen]

Zitat von waldbauer.com

Der 2000er Patch ist bei DISPI direkt zu bekommen :-)
http://www.do-it-so.com/index.php?ds=&page=DOWNLOAD

Hallo Waldbauer (=Günther?),

irgendwo im Forum habe ich gelesen (kann auch irgendwo bei Google gewesen sein in den unendlichen Weiten des Internet), dass der 2000-Patch Probleme macht.

Wie sind Deine Erfahrungen?

Die Links dort sind kaputt, zumindest jetzt im Moment. Und es gibt 2 Versionen, eine kleine "2000 patch for Open Access (Authentical)" mit 9KB und eine große mit 300KB ohne Authentical.

Hast Du noch einen anderen Link oder kannst Du mir die Dateien mailen?

Gruß
Hans Jürgen

[waldbauer.com]

Hallo hier Günther :-)

Ich habe den 2000er Patch seit Anfang an und überhaupt keine Probleme damit (zumindest sind mir nie welche aufgefallen)...*grml* und ich habe damals sogar die ~ 5 USD an DISPI überwiesen :-)

[Hans Jürgen]

Hallo Günther,

habe gefunden, dass die Dateien oaup_001.exe und oapatch.exe heißen, finde aber nirgendwo eine Downloadmöglichkeit und die Links bei do-it-so.com funktionieren nicht mehr.

Was war/ist der Unterschied zwischen den beiden außer dass die eine 9KB und die andere 300KB hat?

Kannst Du mir die Dateien vielleicht mailen?

Gruß
Hans Jürgen

[waldbauer.com]

Die OAUP hab ich noch, die oapatch aber nicht mehr. Ludwig sieht sich das Jahr 2000 Problem an dann haben wir vielleicht eine Lösung für das Jahr 2100 auch :-)

[Hans Jürgen]

Was war denn nun der Unterschied zwischen den beiden Dateien?

Als Problem sehe ich derzeit eigentlich nur, dass das Datum immer mit 1900 anstatt mit 2000 ergänzt wird, was zu vielen überflüssigen Tastendrücken führt.

Ansonsten wüsste ich nichts, was gepatched werden müsste.

Gruß
Hans Jürgen

[waldbauer.com]

Ich habe - ehrlichgesagt - keine Ahnung was damals Dispi alles patchen musste. Das Jahr 2000 Problem habe ich seit 2000 nicht mehr aber ich habe Ludwig gebeten nachzusehen was an welcher Stelle gepatcht wird damit die Eingabe von 99 zu 2099 statt zu 1999 wird.

Ich nehme an es wird nicht allzulange dauern dann wissen wir es :-)

[Hans Jürgen]

Super, das ist eigentlich auch alles, was mich stört. Wenn mir nicht noch etwas anderes einfällt.

[RKabis]

Hallo Zusammen,

habe gerade die Disk's (2000 Patch) gefunden.

Zum einen gab's eine getrennte Disk, eine für Einzelplatz und eine fürs Netzwerk.

Die Dateien sind in Unterverzeichnisse gepackt gewesen.

Das eine Verzeichnis mit der OAUP_001.exe (10 KB) ist im Verzeichnis NORMAL.
Die OAPATCH.EXE ist in einem Verzeichnis PENTIUM2.

Gruß Rainer

[Hans Jürgen]

Hallo Rainer,

wo befinden sich denn die Verzeichnisse PENTIUM2 und NORMAL?

Hoppla, schon gemerkt, vermutlich auf der gefundenen Disk, nicht hier irgendwo im Forum.

Gruß
Hans Jürgen

[RKabis]

Hallo Jürgen,

genau, hab gerade gemerkt, dass ich etwas verdreht geschrieben habe.

Gruß Rainer

[waldbauer.com]

Der Patch ist schon fertig und im Unterschied zum Dispi Patch super klein und rasend schnell. Ludwig wird ihn vermutlich hier im Anhang gleich hochladen. Ab morgen wird er dann auch auf unserer Downloadseite zu finden sein.

[leecher]

Soda, ich hab mir mal den DISPI-Patch angesehen.
Was lustig war, der war in Borland Pascal geschrieben und dort hat die CRT einen Bug auf zu schnellen CPUs (Runtime Error 200 ...). Also zuerst mal den Patcher patchen, dass er geht
Damit auch unsere Hexeditor-Hexer wissen, was sie zu tun haben, hier mal was der Patcher prinzipiell tut:

Er sucht nach folgender Hex-Sequenz:

81 6C 07 A2 6B

Und ersetzt

6C

durch

D0

.

Alle Credits für den Patch gehen an DISPI. Nachdem ich nicht weiß, ob ich eine "gepatchte" Version (damits auf modernen CPUs funktioniert) ihres Patchers hier posten darf, habe ich schnell einen eigenen geschrieben.
Befindet sich im Anhang. Ich hoffe er funktioniert und ich habe nicht irgendwelche Spezialitäten übersehen.

[leecher]

Zitat von Hans Jürgen

habe die OA3.SPI von Hand genau nach Deiner Anleitung gepatched und danach war das Timing-Problem weg. Die Hex-Suche hat zumindest genau Deinen String gefunden, ich habe die 02 durch 00 ersetzt und wir sparen uns jetzt mit 6 Mann täglich mindestens 2 Tastendrücke. Du kannst den Patcher somit auf die OA3.SPI

Hmn, das ist interessant, meine OA3.SPI hat weder die Bytesequenz drinnen, noch hat sie die OA4-Startprobleme. Keine Ahnung was für eine Version ich hier habe, aber kannst Du mir viell. mal Deine OA3.SPI schicken?
Der Grund ist der, dass ich analysieren möchte, wo bei Dir die Sequenz liegt.
Denn wie du eventuell weiter oben gelesen hast, ersetzt ja der neue Patcher wegen dem Problem mit MUSIC nicht bloß 02 durch 00 sondern patcht meine eigene Timer-Routine hinein. Da ich wie oben beschrieben dadurch eine andre Routine eliminiere, die ganz in der Nähe der MUSIC-routine liegt, muss ich wissen, ob ich das bei OA3 auch so machen kann und dafür bräucht ich wie gesagt Deine OA3.SPI zur Analyse. Danke schonmal!

[Hans Jürgen]

Hallo Ludwig,

kann die OA3.SPI hier wegen der Beschränkung auf 100KB nicht hochladen, ist gezippt 750KB groß. Habe Sie per Mail an edv@w... geschickt. Ansonsten, schick mir bitte eine Mail, wie ich Dir die Datei zusenden kann.

Der Y2K-Patch funktioniert übrigens auch einwandfrei, danke!

Gruß
Hans Jürgen

P.S.: Habe schon versucht, die Datei per PM zu schicken, ging nicht.

[leecher]

Hallo Hans Jürgen,

Habe festgestellt, dass hier scheinbar ein Unterschied zwischen Netzwerk- und Einzelplatzverseion von OA3 besteht. Bei OA3 Einzelplatz gibt's weder das Problem, noch die Bytefolge, bei der Netzwerkversion die Du benutzt gibt's das Ganze aber.
Dh. Du hattest recht, es lässt sich genau so wie OA4 patchen.
Ich habe den Patcher entsprechend erweitert, jetzt geht er auch mit der OA3.SPI
Danke für Deine Mithilfe.

[Hans Jürgen]

Nichts zu danken, die Hauptarbeit machst doch Du!

Aber jetzt noch für mich: wie kann man in diesem Forum jemandem eine Datei schicken?

Gruß
Hans Jürgen

[waldbauer.com]

...kann man leider nicht zumindest noch nicht.

[Yvar]

Hallo

Ich benütze das OpenAccess Netzwerk und wollte das Y2K-Patch installieren. Leider geht es bei mir nicht - Ich denke das ich etwas falsch mache.

Ich habe das Y2KPatch.com auf dem Server wo das OA4.SPI ist installiert und gestartet. Jedoch hat sich beim Starten nichts geändert.

Ich danke für die Infos

Yvar Vonlanthen