AWE32 und Rechnergeschw.

[plentus]

Hallo,

ich bin nun an eine schöne AWE32 CT3900 (noch nicht pnp) gekommen.
Nun habe ich aber leider Probleme die Karte ordentlich zum klingen zu bringen. Im aktuellen Diagnose (V4.05) prg läuft alles ordnungsgemäß.

Insbesondere bei X-Wing geht der Adlib Sound aber nur, wenn ich den CPU (K6-3 400) Cache abschalte und auf 166 MHZ runtertakte - es scheint also irgendwie geschwindigkeitsbedingt zu sein.

Der Adlibtracker http://www.adlibtracker.net/ läuft in der alten Version 2.0.27 - aber nicht in der auf der webseite aktuellen version - auch nicht, wenn ich die kiste langsam mache.

An der Karte scheint es nicht zu liegen - bei einer anderen AWE32 auch CT3900 tritt das selbe phänomen auf.

Weiss jemand zufällig was näheres über diesen effekt?

update:
hmm - hab jetzt selber was gefunden:
http://vogons.zetafleet.com/viewtopic.php?t=28152
und
http://vogons.zetafleet.com/viewtopic.php?t=28364

"8-bit I/O Recovery Time" im bios hochsetzen soll wohl was bringen. Werd das mal ausprobieren

Gruss, und Danke

[DOSferatu]

Soweit ich weiß, ist das ein Problem von "AdLib" selber (bzw des entsprechenden Chips). Irgendwie erwartet der, daß nach Senden eines Befehls (über die "AdLib"-Ports) ein wenig Zeit verstreichen muß, bevor man einen neuen Befehl sendet, sonst kommt der durcheinander. Das war auch alten Rechnern (086, 286) kein Problem, weil die langsam genug waren, daß das keine Rolle spielte. Man mußte nicht "warten", weil zwischen zwei Befehlen sowieso genug Zeit verging.

Anders ist es dann bei neuen Rechnern (schnelle 386, 486 und höhere). Das Problem ist, daß die ALTEN Programme (und Programmierer derselben) wohl nicht davon ausgingen, daß die Rechner mal so schnell würden und daher keine eigene "Bremse" da eingebaut haben - so daß bei schnelleren Rechnern die Befehle an den AdLib-Port (es sind wohl, soweit ich's noch im Kopf habe, 0x388 und 0x389) zu schnell hintereinander kamen. Dieses "AdLib-Chip-Durcheinanderbringen" hat im realen Leben dann das Ergebnis, daß es: Entweder komisch klingt (Geräusche/Töne erzeugt werden, die so nicht gedacht waren), ODER es "hängende Noten" gibt, d.h. eine Musik wird kurz angespielt (oder schlimmstenfalls nur die erste Note davon) und dann bleiben die letzten Noten einfach stehen und erzeugen einen Dauerton, ODER der Chip hängt sich in der Art auf, daß er quasi stumm wird, d.h. man gar nichts mehr hört - mitunter beeinflußt das auch die restliche Soundkarte, d.h. auch die anderen Funktionen reagieren dann irgendwie nicht mehr (oder nicht mehr richtig) und nur Neubooten der Karte (per Reset des Rechners, am besten Hardreset) kann dem Abhilfe schaffen.

Die Lösung des Problems ist (für schnelle Rechner eben) :

1. Bei alten Programmen, deren Source man nicht selbst geschrieben hat: Bremsprogramme starten, die so viele Interrupts oder so erzeugen, daß der Rechner pottenlangsam wird. Zusätzliches Ausschalten des "TURBO" (wenn vorhanden) kann auch helfen.

2. Bei alten Programmen, deren Source man selbst hat/geschrieben hat: Die Programme ändern, indem man zwischen die AdLib-Port-Befehle Bremsschleifen (oder ähnliches) einfügt.

3. Für manche der alten Programme gibt es gelegentlich Patches, die diese "Fehler" beheben - meist sind die aber für etwas anderes gedacht: Borland hat in seinen alten C-Versionen und in Turbo-Pascal eine bekannte Routine eingebaut, die zu Anfang die Rechnergeschwindigkeit mit Hilfe einer Schleife mißt, die aber mit einer zu klein dimensionierten Variable arbeitet - so daß bei zu schnellen Rechnern ein Überlauf passiert. (In Pascal betrifft dies die Unit CRT.) Der ermittelte Wert wird später in einer Warte-Funktion benutzt, wird aber auch ermittelt, wenn die Warte-Funktion im Programm nicht auftritt. Der Überlauf führt auf zu schnellen Rechnern zum gefürchteten Runtime Error 200 (auch kurz als RTE200 bekannt). Für Borland C heißt der "integer divide by 0 (6001)" oder so (weil INT0 ausgelöst wird - allerdings wird der sowohl bei Teilung durch 0 als auch bei Teilung mit zu großem Ergebnis ausgelöst).

Die oben angesprochenen Patches beheben den Fehler etwas, indem sie Code einfügen, der den Überlauf verhindert - dadurch arbeitet die Wartefunktion auf langsamen Rechnern weiterhin korrekt - allerdings auf zu schnellen Rechnern wartet sie zu kurz. Die Patches sind eigentlich ja nur gedacht, damit das Programm nicht gleich beim Starten mit der entsprechenden Fehlermeldung aussteigt.
Es KANN reichen, den Patch zu verwenden - d.h. daß auch die kürzere Wartezeit der Warte-Funktion ausreicht (denn ich habe den Verdacht, daß genau diese Wartefunktion später (286er) manchmal eingesetzt wurde, um diese Adlib-Pausen zu ermöglichen) - aber wenn der Rechner zu schnell ist, nützt das natürlich nichts: In diesem Fall muß eine Kombination von RTE200-Patch UND Bremsprogramm eingesetzt werden, damit a) das Programm überhaupt läuft und b) der Sound korrekt abgespielt wird.

Ich hoffe, der Text hat etwas geholfen. Falls Interesse für einen Patch zumindest für alte Pascal-Programme (hab ich hier) und/oder Rechner-Brems-Programme (hab ich auch hier), wäre das kein Problem. Die sind Freeware und ich könnte sie auf meinen Webspace hochladen.

[plentus]

Hey vielen Dank für die ausführliche Antwort!
Die Idee mit den Bremsprogrammen ist gut - das werde ich auch noch mal testen.

Bisher hatte ich mich auf die I/O recovery time option gestürzt, bin aber nicht wirklich weitergekommen.
In dem Bios meines derzeitigen Boards (Epox MVP3G2) taucht die option leider nicht auf.
Bisher hab ich folgendes ausprobiert:
Bios mit dem "biospatcher" bearbeiten und brennen
http://www.rom.by/articles/BP/index_english.htm
-> "it can add or open new features, i.e. some features that your BIOS has but they are closed by manufacturer of your motherboard."
hat leider nix gebracht. Aber der rechner läuft immerhin noch

mit WPCREDIT an der pci - isa bridge rumgespielt
http://www.k6plus.com/index.php?name=Do ... load&cid=1
hat leider auch nicht zum erfolg geführt, weil ich nicht weiss, an welcher stelle ich was ändern müsste.

Der Adlibtracker ist ja in pascal geschrieben - Der Autor stellt den sourcecode auf sourceforge zur verfügung. Da wäre es in der Tat mal sehr interessant, deinen Patch auszuprobieren. Vielleicht kannst du mir den link dazu und den bremsen ja mal zumailen.

Besten Dank jedenfalls erstmal!

[Dosenware]

für BP habe ich zuhause einen Patch, bei dem das delay nicht verkürzt wird, kann ich evtl. morgen hochladen, wenn Bedarf besteht.

[CptKlotz]

Hmm... Speedprobleme bei Adlib? Das habe ich noch nie gehört/erlebt. Was natürlich nicht heißen muß, daß es die nicht gibt.


Die Floppy-Version von X-Wing ist meiner Erfahrung nach sowieso relativ dumm, was Soundkarten angeht. Die CD-Version ist da besser, wobei da der MT-32-Soundtrack etwas anders klingt (ich habe keine eindeutige Präferenz).

Siehe auch: http://www.dosforum.de/viewtopic.php?f=3&t=5786

[DOSferatu]

Hmm... Speedprobleme bei Adlib? Das habe ich noch nie gehört/erlebt. Was natürlich nicht heißen muß, daß es die nicht gibt.

Ja, es ist aber so. Ich hatte mich - eben wegen solcher Probleme - mal darüber informiert.
Und es ist so, daß die AdLib eine kleine Weile braucht, um die ankommende Information zu verarbeiten, bevor sie neue annehmen kann. Kommen zwischendurch neue, geschehen unvorhersehbare Dinge, weil sich das irgendwie vermischt - oder die AdLib (den Chip) dadurch ganz blockiert.
Ganz alte Programme (086er, 4.77 MHz, Befehle mit etlichen Taktzyklen) haben das gar nicht berücksichtigt, weil die Zeit, die zwischen zwei Portzugriffen verging, sowieso größer war als die benötigte Wartezeit der AdLib, um sich nicht zu verschlucken. Neuere Programme (deren Programmierer) wußten bereits um dieses Problem und lösten es mit Timerschleifen (oder eben den bewußten DELAY-Befehlen) - leider haben diese die (damals noch nicht so vorauszusehende) Macke mit dem Überlauf.
Irgendwie schien sich auch niemand über diesen Umstand Gedanken gemacht zu haben (nämlich, daß Register bedingt durch ihre Bitbreite eine begrenzte Reichweite haben und evtl beim hoch/runterzählen überlaufen könnten). Und zwar, weil das Heulen und Zähneklappern wirklich erst anfing, als Computer-CPUs plötzlich auch mit 200 MHz und schneller ticken konnten und plötzlich alte Programme mit dem bekannten Runtime-Error ausstiegen. Und erst dann ging das Gebremse und Gepatche los...

Jedenfalls kann ich mich dafür verbürgen, daß das mit dem Timing-Problem bei AdLib stimmt.
1.) Ich habs gelesen (aber das will ja noch nichts sagen).
2.) Ich habs selbst erlebt.
Und zwar: Patch draufgezogen, der die Timerschleife am Anfang am Überlaufen hindert, was dafür sorgt, daß das Programm sich nicht mit diesem RTE200 (bzw der entsprechenden C-Variante) beendet - ABER eben auf schnellen Rechnern für die Delay-Routine (bzw deren C-Variante) zu kurze Zeiten erzeugt.
Ergebnis war: Das Programm (z.B. Monkey Island 1) startete und lief auch anständig. Und mit PC-Speaker-Musik auch problemlos - selbst auf schnellem Rechner. Aber: Wählte man AdLib, so kamen einige Töne, dann seltsame fiese Geräusche, manchmal auch ein Dauerton, alles mögliche nur eben keine Mucke. Und: Abhilfe konnte eben durch Bremsprogramme geschaffen werden! D.h. Patch UND Bremsprogramm (und Turbo aus und so weiter) und schon lief die AdLib-Mucke wieder einwandfrei. ABER: Wenn die AdLib einmal so "schiefhängt", muß man natürlich oft erstmal neu booten - damit sich die Soundkarte initialisiert/resettet und sich die AdLib wieder einkriegt.

Also muß doch was dran sein an diesem ganzen AdLib-Mysterium. (Und wie gesagt, ich hatte es eben gelesen, dieses "AdLib verlangt kurzes warten nach Senden an den Port bevor weiteres Senden" - und wenn ich die entsprechenden Ergebnisse meiner Tests mit diversen Programmen sehe, scheint mir das auch plausibel.)

[plentus]

SUCCESS!!


hier: http://www.k6plus.com/index.php?name=PN ... pic&t=1702
gibt es die entsprechenden pcr files für die ISA bridge und wpcredit.

- In der ISA Bridge hab ich 0xF8 im Offset 40 eingetragen und alles geht!
konkret bedeutet das:
ISA Command Delay: 1=Extra
Extended ISA Bus Ready: 1=Enable
ISA Slave Wait States: 1=5WS
Chipset I/O Wait States: 1=4WS
I/O Recovery Time: 1=Enable

Bisher nur unter W98 - muss demnächst mal testen, wie man die Register für die Via Southbridge unter Dos und am besten beim booten setzt.

[Dosenware]

TWeakbios?

[plentus]

Für windows gibts auch von h.oda noch wpcrset - damit kann man die entspechenden werte in die richtigen register laden. das funktioniert inzwischen auch.

Für dos hab ich noch keine gute idee. tweakbios bringts für mich leider nicht - hatte ich zuvor schon mal ausprobiert.
die ISA-Bridge wird nciht unterstützt.
Ausserdem wäre es nützlicher, wenn ich ein tool hätte, welches gleich beim booten die entsprechenden werte ändert

Prinzipiell weiss ich ja nun auch welche bits ich an welcher stelle verändern muss - hab ich zwar noch nicht gemacht, aber die entsprechenden Werte in die Southbridge schreiben sollte doch eigentlich nicht so schwierig zu programmieren sein. Werd ich mich demnächst mal drum kümmern.

Gruß

[Dosenware]

Ausserdem wäre es nützlicher, wenn ich ein tool hätte, welches gleich beim booten die entsprechenden werte ändert

Das kann Tweakbios (zumindest die Vollversion)

welche Isabrücke bzw. welchen Chipsatz hast du?

[plentus]

Ich schreib mal das ab, was WPCRedit sagt:

Vendor ID: 1106 VIA VT82C596B Southbridge
Device ID: 0596 ISA Bridge
Revision: 23


Update:

mit einem kleinen Assemblerprogramm kann man auch direkt den entsprechenden Registerwert setzen

-u100
1694:0100 B802B1 MOV AX,B102 ;Biosfkt FIND PCI DEVICE
1694:0103 BA0611 MOV DX,1106 ;Vendor ID
1694:0106 B99605 MOV CX,0596 ;Device ID
1694:0109 BE0000 MOV SI,0000 ;Fkt Nr
1694:010C CD1A INT 1A
1694:010E B80BB1 MOV AX,B10B ;Write Configuration Byte
1694:0111 BF4000 MOV DI,0040 ;Register Nr.
1694:0114 B1F8 MOV CL,F8 ;_der_ Wert
1694:0116 CD1A INT 1A
1694:0118 B8004C MOV AX,4C00 ; DOS fkt Programm beenden
1694:011B CD21 INT 21