AWE32 und MT32 vertragen sich nicht?

[Mystery]

Tag zusammen,

ich habe momentan unter anderem einen MT32 an meine AWE32 angeschlossen. Der Rechner ist ein P233MMX mit Dos6.22.
Der MT32 funktioniert soweit, dass er Midi Messages erhält und auch von Sierra Titeln erkannt wird.

Das Problem ist, dass die Instrumente in z.B. Space Quest oder auch Spielen wie Monkey Island 1 komplett falsch sind, wenn überhaupt was kommt, das Intro von Monkey Island 1 ist komplett still und SpaceQuest3+4 hören sich scheußlich an, es werden komplett die falschen Instrumente angesprochen.

Andere Spiele wiederum laufen. Wizardry7 oder Monkey Island 2 spielen die Musik einwandfrei am MT32 ab, weshalb ich einen Defekt am Roland ausschließen würde und auf einen Konfigurationsfehler hoffe.

Der MT32 bekommt die MIDI Daten vom Gameport der AWE32 und schickt sie ans Line-In der AWE32 zurück, sollte ja in Ordnung sein.


Weiß jemand Rat?

Edit: Firmware ist 1.07 und das Gerät hat ein Rev0 Board (Seriennummer 83xxxx)

[CptKlotz]

Bei einigen Spielen können solche Fehlfunktionen daran liegen, daß die AWE32 nicht den "intelligent mode" für das MPU-Interface beherrscht. Teilweise gibt's dafür Patches (für die Spiele, nicht für die AWE :-) ).

Wenn Spiele falsch klingen, kann das auch daran liegen, daß sie das MT-32 beim Start nicht initialisieren/umprogrammieren. Monkey Island 1 nutzt z.B. einfach die Presets des MT-32. Da könnte es helfen, einfach einen Reset zu machen. Dafür gibt's eine Tastenkombination am MT-32, die ich gerade vergessen habe. Als Behelf kannst Du das Ding aber auch einfach kurz ausschalten und dann wieder einschalten.

[Mystery]

Den Reset habe ich bereits durchgeführt, ohne Erfolg.

Ich dachte immer die AWE32 (nicht 32PNP) unterstützt als eine der wenigen Karten eben diesen intelligenten Modus, ein Grund warum ich das Ding im Rechner habe.


Aber ich glaube ich bin auf die Ursache des Problems gestoßen: Die alte Firmware auf dem Roland kommt nicht damit zurecht wenn die "schnelle" CPU MIDI Daten schickt, d.h. sie können nicht verarbeitet werden was in dem beschriebenen Fehler resultiert.
Ich habe probeweise die CPU auf 100MHz (weniger ging nicht) heruntergetaktet und internen sowie externen Cache abgestellt und jetzt läuft es. Indy4 gibt zwar noch eine Exec. Buffer Overflow Nachricht, aber im Großen und Ganzen spielt es recht solide.

Ist natürlich keine Dauerlösung immer unter den Tisch zu krabbeln, das Gehäuse aufzuschrauben und die CPU umzujumpern. Gibt es unter DOS ein Tool welches die Performance des Systems drastisch in den Keller zieht und quasi im Hintergrund läuft? Hatte mal mit MoSlo experimentiert, aber lang ists her und ich habe keine meßbaren Unterschiede feststellen können (damals noch um Ultima7 auf annehmbare Geschwindigkeit runterzuregeln)

[kpanic]

Sorry, dass ich hier schon wieder einen relativ alten Thread exhumiere...
Aber genau das selbe Problem habe ich auch gehabt. Und zwar bereits auf einem P90...
Es liegt in der Tat daran, dass die betreffenden Spiele die SysEx/Midi-Messages zu schnell rausballern (Timing-Bug), und die MT32 deswegen die Hälfte verschluckt. Das Problem konnte ich auch dadurch beheben, dass ich den internen CPU-Cache deaktiviert habe.
Unter reinem DOS (also nicht unter Windows) kann man mit diesem Tool den internen Cache ein und ausschalten, ohne jedes Mal ins BIOS zu müssen. Man kann sich also einfach eine Batch-Datei schreiben, die den Cache deaktiviert, das Spiel startet und danach den Cache wieder aktiviert.
Testweise hatte ich die MT32 auch mal an einen 386er mit SB1.5 gehängt, dort trat das Problem nicht auf.

[CptKlotz]

Das Problem ist im Grunde noch etwas komplexer.

MT-32 der ersten Revision (zu erkennen daran, daß sie keinen Kopfhörerausgang haben) bekommen schneller den Overflow-Error als Geräte der 2. oder 3. Revision (oder CM32-L und LAPC-I, deren Tongenerator meines Wissens nach auf einem MT-32 2. Generation basiert).


Wenn jetzt also ein Spieleentwickler das nicht weiß und mit einem neueren MT-32 oder CM32-L das Spiel entwickelt, fällt ihm unter Umständen gar nicht auf, daß das Spiel eventuell auf einem "alten" MT-32 einen Fehler verursacht.

Neben dem Overflow-Bug und den zusätzlichen SFX-Sounds des CM-32L und der LAPC-I gibt's auch noch ein paar weitere subtile Unterschiede, wie ein unterschiedliches Clipping-Verhalten und unterschiedliche Vibrato-Geschwindigkeiten zwischen den Revisionen.

Sowas ist eben oft das Problem, wenn ein Produkt "verbessert" wird, aber manche Programmierer sich gerade bestimmte Fehler oder Unzulänglichkeiten zunutze gemacht haben. Mit dem alten SID-Chip 6581 und dem neuen, "verbesserten" 8580 in verschiedenen Versionen des C64 war es ja so ähnlich :-)

Ich weiß auch nicht, inwieweit Roland sich Gedanken drüber gemacht hat, wie kompatibel das MT-32 zu Spielen ist - eigentlich war das ja ein (relativ) preiswertes Soundmodul für Hobbymusiker. Meines Wissens nach hat erst Sierra das Ding unter PC-Spielern populär gemacht.

[kpanic]

Wenn jetzt also ein Spieleentwickler das nicht weiß und mit einem neueren MT-32 oder CM32-L das Spiel entwickelt, fällt ihm unter Umständen gar nicht auf, daß das Spiel eventuell auf einem "alten" MT-32 einen Fehler verursacht.

Es gibt sogar eine Handvoll Spiele (Darunter z.B. SQ3), die Bugs der ersten MT-32-Generation ausnutzen und auf den neueren bzw. der LAPC-I nicht ganz korrekt klingen. Irgendwo im Netz geistert ne Liste der Spiele mit MT-32-Unterstützung rum, in der jeweils dabei steht, ob das Spiel die zusätzlichen Sounds der neueren Geräte nutzt oder eben die Bugs der ersten Generation ausgenutzt werden.
Mir persönlich kann das relativ Wurst, ich habe hier ne MT-32 ohne Kopfhörerbuchse (also 1.G), und oben drauf steht eine CM32-L... Ich bin also mit allen Wassern gewaschen

[rftl]

Ich würde sagen in Sachen Kompatibilität des CM-32l (oder LAPC-I / CM-64) die beste Wahl.
Man hat die verbesserten Noise Level der 2th Gen Geräte. Weniger Probleme mit dem Buffer Overflow Bug.
Es funktionieren die meisten MT-32 Games und die erweiterten CM Effekt Samples.
Es gibt nur wenige Games die nicht gut funktionieren und natürlich hat man kein Display.

Leider bekommt man das MT-32 1th Gen wohl am einfachsten (und mit etwas glück in der Bucht sogar ganz günstig). Während 2th Gen Geräte seltener und teurer sind (3th Gen CM-500 = Wucher).

-----------------
Der Overflow Bug im Original MT-32 ist nun mal vorhanden.
Es gibt Games die immer dieses Problem haben (Musiker/Programmierer die nur 2th Gen nutzten). Aber er kann einfach auftreten bei Spielen deren Midi Ausgabe nicht auf neuere CPUs vorbereitet waren (vergleichbar mit Spielen die auf neuen CPUs zu schnell laufen). Das ist das hier beschriebene Problem.
Je schneller die CPU ist desto mehr Games haben dieses Problem. Für manche Games reicht es unter einen Pentium 200Mhz zu gehen. Aber je nach Game muss man deutlich drunter bleiben.

Zum Vibrato. Es gibt ein Problem mit dem 3th Gen Devices. Das Vibrato ist massiv anders und es wurde von Roland sogar als Bug eingestuft. Für normale Nutzung scheint das aber nicht so schlimm zu sein. Der Bug wurde auch erst Jahre nach ablaufen der Garantiezeit Entdeckt und betrifft für uns nur das CM-500 Device (es gibt noch andere Module für Japanische Heim Computer). Im direkten Vergleich hört man es tatsächlich (es gibt irgendwo vergleiche im Netz).

Es gibt irgendwo eine (total veraltete) DosBox Version mit einem Hack der das buffer Overflow Problem behebt. Ok das istnur wichtig für Games die das Problem unabhängig von der CPU besitzen (für den Rest reichen ja einfach weniger CPU Cycles). Leider hilft das nichts bei echter Hardware.

[elianda]

Was auch helfen kann: 8 Bit I/O Recovery Timer im BIOS auf maximum setzen.

[freecrac]

Ich würde sagen in Sachen Kompatibilität des CM-32l (oder LAPC-I / CM-64) die beste Wahl.
Man hat die verbesserten Noise Level der 2th Gen Geräte. Weniger Probleme mit dem Buffer Overflow Bug.
Es funktionieren die meisten MT-32 Games und die erweiterten CM Effekt Samples.
Es gibt nur wenige Games die nicht gut funktionieren und natürlich hat man kein Display.

Leider bekommt man das MT-32 1th Gen wohl am einfachsten (und mit etwas glück in der Bucht sogar ganz günstig). Während 2th Gen Geräte seltener und teurer sind (3th Gen CM-500 = Wucher).

-----------------
Der Overflow Bug im Original MT-32 ist nun mal vorhanden.
Es gibt Games die immer dieses Problem haben (Musiker/Programmierer die nur 2th Gen nutzten). Aber er kann einfach auftreten bei Spielen deren Midi Ausgabe nicht auf neuere CPUs vorbereitet waren (vergleichbar mit Spielen die auf neuen CPUs zu schnell laufen). Das ist das hier beschriebene Problem.
Je schneller die CPU ist desto mehr Games haben dieses Problem. Für manche Games reicht es unter einen Pentium 200Mhz zu gehen. Aber je nach Game muss man deutlich drunter bleiben.

Zum Vibrato. Es gibt ein Problem mit dem 3th Gen Devices. Das Vibrato ist massiv anders und es wurde von Roland sogar als Bug eingestuft. Für normale Nutzung scheint das aber nicht so schlimm zu sein. Der Bug wurde auch erst Jahre nach ablaufen der Garantiezeit Entdeckt und betrifft für uns nur das CM-500 Device (es gibt noch andere Module für Japanische Heim Computer). Im direkten Vergleich hört man es tatsächlich (es gibt irgendwo vergleiche im Netz).

Es gibt irgendwo eine (total veraltete) DosBox Version mit einem Hack der das buffer Overflow Problem behebt. Ok das istnur wichtig für Games die das Problem unabhängig von der CPU besitzen (für den Rest reichen ja einfach weniger CPU Cycles). Leider hilft das nichts bei echter Hardware.

Ich verstehe es nicht was ein Buffer-Overflow mit der verwendeten CPU zu tun hat. Das ist doch ein krasser Programmierfehler(ggf. ein Fehler des verwendeten Compilers) oder etwa nicht?

Dirk

[Doctor Creep]

SpaceQuest3+4 hören sich scheußlich an, es werden komplett die falschen Instrumente angesprochen.

Was das fehlerhafte Empfangen der Sysex-Daten bei Sierra Spielen (bei schnelleren Rechnern) angeht gabs da auch mal einen Bugfix von Sierra. Kann ich bei Bedarf mal nach wühlen.

Doc

[philscomputerlab]

http://www.sierrahelp.com/

Diese Seite hat so ziemlich alle Patches fuer so ziemlich jedes Sierra Spiel!

Fuer Sierra Spiele gibt es auch einen treiber der es Ermoeglicht die MT-32 per Sound Blaster Midi port ohne Probleme zu betreiben...

Zum Thema welches Roland Midi modul...

Fuer Sierra und Dyamix Adventures Empfehle ich eine MT-32 (Old) ohne headphone port.

Die CM-32L ist das naechste Modul auf der Liste. Mit den beiden kann man eigentlich alle Spiele ohne Probleme spielen.

Spielt man Sierra / Dynamix Spiele auf einer neueren Roland dann koennen manche Sachen falsch klingen. Z.b. habe ich letzte Woche so einen Fall in "Heart of China" gefunden. Wenn man in den Flieger steigt kommt eine Szene wo ein Pass stempel in den Pass kommt. Auf der alten MT-32 hoert man ein fettes "PUNCH", auf der neuen nur ein "KLICK".

Bei der alten MT-32 ist auch der Volume Dreher anders. Er regelt hier die digital Lautstaerke bevor Sie verstaerkt wird. Bei den neuen regelt er die analoge Lautstaerke des Verstaerkers.

Bei Wing Command uebersteuern neue Module beim Intro (Feuerwerk), auch wenn man die Lautstaerke reduziert. Bei der alten Roland einfach die Lautstaerke auf 70 stellen und es klingt super!

[rftl]

Ich verstehe es nicht was ein Buffer-Overflow mit der verwendeten CPU zu tun hat. Das ist doch ein krasser Programmierfehler(ggf. ein Fehler des verwendeten Compilers) oder etwa nicht?

Dirk

Buffer Overflow = Puffer Überlauf
Es bedeutet nichts anderes als das ein Puffer über belegt ist.
Die 1Gen MT-32 Geräte hatten einen Bug in der Firmware. System Exklusive Messtages mussten mit einem Abstand von Mindestens 40 Millisekunden gesendet werden.
Games bei denen im Midi Teil ihrer Engine nicht darauf geachtet wurde. Haben villeicht bei aktuellen CPU keine Probleme gemacht. Aber bei schnelleren CPUs wird so schnell gearbeitet das sie SysEx Messages eben schneller kommen können.

[freecrac]

Ich verstehe es nicht was ein Buffer-Overflow mit der verwendeten CPU zu tun hat. Das ist doch ein krasser Programmierfehler(ggf. ein Fehler des verwendeten Compilers) oder etwa nicht?

Dirk

Buffer Overflow = Puffer Überlauf
Es bedeutet nichts anderes als das ein Puffer über belegt ist.

Ich habe es immer so verstanden das ein verwendeter Puffer über seine Grenzen hinaus mit Daten befüllt wird und der Puffer überläuft, so das darauf folgende Daten- oder Code-Bereiche damit unbeabsichtigt überschrieben werden.
So bekommt man dann auch ein Sicherheitsleck wenn darüber neue Opcodes in den Codebereich gelangen können.

Die 1Gen MT-32 Geräte hatten einen Bug in der Firmware. System Exklusive Messtages mussten mit einem Abstand von Mindestens 40 Millisekunden gesendet werden.

Ich vermute mal weil in kürzeren Zeitabständen die gesendeten Daten noch nicht in Empfang genommen werden können.
War das denn nicht bekannt, oder bewegt sich die Karte ausserhalb jeder Spezifikation, wird in einerm Statusregister ein Empfangsbereit signalisiert obwohl das noch gar nicht der Fall ist, oder warum redet man hierbei von einem Bug in der Firmware?

Games bei denen im Midi Teil ihrer Engine nicht darauf geachtet wurde. Haben villeicht bei aktuellen CPU keine Probleme gemacht. Aber bei schnelleren CPUs wird so schnell gearbeitet das sie SysEx Messages eben schneller kommen können.

Als Folge gibt es dann gar kein Ton, oder wie macht sich das bemerkt?

Dirk

[rftl]

War das denn nicht bekannt, oder bewegt sich die Karte ausserhalb jeder Spezifikation, wird in einerm Statusregister ein Empfangsbereit signalisiert obwohl das noch gar nicht der Fall ist, oder warum redet man hierbei von einem Bug in der Firmware?

Ganz ehrlich ich weiß nicht wann der Bug entdeckt wurde. Oder ob wirklich viele davon wussten.
Oder was genau schief läuft. Ich weiß nur er ist da ist und mit neueren Firmware Versionen behoben wurde.
Für mehr technische Infos empfehle ich http://www.queststudios.com. Dort wissen viele deutlich mehr über den MT-32.

Ich vermute einfach mal das sich darüber einfach niemand Gedanken gemacht hat.

Games bei denen im Midi Teil ihrer Engine nicht darauf geachtet wurde. Haben vielleicht bei aktuellen CPU keine Probleme gemacht. Aber bei schnelleren CPUs wird so schnell gearbeitet das sie SysEx Messages eben schneller kommen können.

Als Folge gibt es dann gar kein Ton, oder wie macht sich das bemerkt?
[/quote]

Die Beiden Fehler hier im Tread beschrieben zeigen genau was passiert.
Meistens hört es sich einfach Falsch an.
Die große Besonderheit des MT-32 war das man ihn an die Bedürfnisse des Games anpassen kann. Normalerweise geschieht das beim Spielstart. Das ist auch der Grund warum SoundFont basierte Emulation nicht Funktioniert.
Diese Software Anpassungen sind dank dem Bug nicht mehr möglich (oder es ist sogar halbfertig). Es kann danach schon passieren das anstelle eines Klavier mit einer Trompete gespielt wird.

[elianda]

Ich vermute mal weil in kürzeren Zeitabständen die gesendeten Daten noch nicht in Empfang genommen werden können.
War das denn nicht bekannt, oder bewegt sich die Karte ausserhalb jeder Spezifikation, wird in einerm Statusregister ein Empfangsbereit signalisiert obwohl das noch gar nicht der Fall ist, oder warum redet man hierbei von einem Bug in der Firmware?
Dirk

Da gibt es keinen Handshake, das ist wie 3 wire serial, also send and forget. Der Empfänger muss entsprechend die Zeitbedingung in jedem Fall erfüllen, oder eben der Sender die Zeitvoraussetzungen des Empfaengers kennen.
Ist dies nicht der Fall, gehen die Daten einfach verloren. Genauso, wie wenn Du einen FIFO des 16550 befüllst mit mehr als 16 Bytes, ohne diese abzuholen.

Normalerweise zeigt das MT-32 aber einen Overflow auf dem Display an. Darauf sollte man achten, wenn man das erste mal ein Spiel startet. Wenn dies der Fall ist, muss man sich etwas einfallen lassen, damit das Programm die Daten langsamer sendet.
Entweder per BUS und/oder CPU-Bremse. Also sowas wie ISA Teiler hochsetzen, 8 Bit I/O Recovery Time hochsetzen, BusClk erniedrigen, CPU Cache deaktivieren etc.

Wenn man es perfekt machen will, baut man sich eine Box dazwischen mit einem grossen FIFO, der die Daten zeitgerecht weitersendet. Also sowas wie einen Hardware Zwischenpuffer.
Oder man baut sich eine Softwareloesung, die nochmals zwischenpuffert.

Ich weiss nicht wie gut Du Dich da auskennst, aber so eine Lösung, wie der MegaEM Emulator der GUS wuerde sich da anbieten.
Über die V8086 Features von EMM386,QEMM386 usw. verbietet man den Zugriff auf 0x330h+ per I/O Permission Bitmap und faengt die Exception mit seinem eigenen Programm ab. Dann kann man in seinem Programm in Software einen weiteren FIFO einfügen und in der privilegierten Umgebung auf den echten Hardwareport zeitlich korrekt portioniert senden.