TTD Forum

Hallo Leute,

gibt es irgendwo eine Version von TSRCommander, die auf dem Masterpiece vernünftig läuft? (Ich vermute jedenfalls dass es ein MP Problem ist)
Anscheinend kommt TSRCommander nicht mit dem OSD klar. So blendet er sich immer ein, wenn man im Improbox Papierkorb Exit drückt oder im SubSwitch Menue oder im EPGUploader.

Meiner Meinung nach scheint die Funktion OSDActive() nicht sauber zu funktionieren.

Aushilfsweise wäre mir auch mit ein paar Tips von den TAP Gurus geholfen, um den TSRCommander selber zu modifizieren.

Danke im Voraus
Umtauscher

Hallo, weiß zwar nicht genau wie es beim MP aussieht, aber kannst ja mal versuchen die startreihenfolge zu ändern, hatte da auch schon mal probs mit.

MFG Markus

nö, das ist nicht der Grund. TSRCommander startet zuerst, dann Improbox und anschließend der Rest.
Da Problem ist, dass TSRComander bei manchen TAPs nicht erkennt, dass schon ein anderes TAP aktiv ist und sich mit der Exit-Taste einblendet.

Umtauscher

ok, habe da dann keine antwort für dich. sorry.

umtauscher hat geschrieben:nö, das ist nicht der Grund. TSRCommander startet zuerst, dann Improbox und anschließend der Rest.
Da Problem ist, dass TSRComander bei manchen TAPs nicht erkennt, dass schon ein anderes TAP aktiv ist und sich mit der Exit-Taste einblendet.

Umtauscher

Evtl. hilft Dir da mein kleines StopExit-TAP?

Da mußt Du 2x Exit innerhalb einer Sekunde drücken, damit es durchgereicht wird...

Danke, aber ich würde schon lieber dem Problem auf den Grund gehen.
Was kann denn grundsätzlich die Ursache sein, wenn ein Fenster welches mit TAP_Win_Create erzeugt wird, beim Abfragen des OSD-Memorys nicht gesehen wird?

umtauscher hat geschrieben:Was kann denn grundsätzlich die Ursache sein, wenn ein Fenster welches mit TAP_Win_Create erzeugt wird, beim Abfragen des OSD-Memorys nicht gesehen wird?

Weil der Masterpiece eine andere Ebene und somit einen anderen Speicherbereich für die Win-Funktionen verwendet.

Das habe ich auch schon vermutet. Irgendwelche Ideen, wie man diese Inkompatibilität umgehen kann bzw. die OSD-Prüfung erweitern kann?

Elle4u hat geschrieben:Evtl. hilft Dir da mein kleines StopExit-TAP?

Da mußt Du 2x Exit innerhalb einer Sekunde drücken, damit es durchgereicht wird...

Danke für den Link . Ich hatte in Erinnerung dass es dieses TAP gibt, aber vergessen wie es hieß, von wem, .... also nix mit Stichworten für die Suche


Bzgl. TSR Commander:
Ich hab mich ja nie mit TSR Commander beschäftigt - lt. Happy soll der TAP Commander das gleiche können. Vielleicht funkt der korrekt am MP.

Info hier: viewtopic.php?t=2749

Sigittarius-E hat geschrieben: Bzgl. TSR Commander:
Ich hab mich ja nie mit TSR Commander beschäftigt - lt. Happy soll der TAP Commander das gleiche können. Vielleicht funkt der korrekt am MP.

Danke für den Hinweis. Er funktioniert leider auch nicht richtig, nur anders. Er macht sein Fenster hinter den schon geöffneten Dialogen (Improbox, Pipswitch) auf. Leider kann man diese Dialoge dann gar nicht mehr beenden.
Also doch zurück zu TSRCommander :-(

Gruß
Umtauscher

Hi,

umtauscher hat geschrieben: Irgendwelche Ideen, wie man diese Inkompatibilität umgehen kann bzw. die OSD-Prüfung erweitern kann?

Ich bin nicht gestolpert, sondern habe bewusst nach dem Stein des Anstoßes gesucht.

Zuerst ein paar Grundlagen: Die Emma hat 3 OSD-Ebenen. Die oberste, namens Hardware Cursor, kommt zwar in der Firmware vor, mir ist aber noch nicht untergekommen, wann sie verwendet wird. Bleiben also zwei, wobei Plane 2 hinter der Plane 1 liegt.

Beim 5000er finden normalerweise alle TAP_Osd und TAP_Win Funktionen in der Plane 1 statt. Ausgenommen ist ein TAP_Osd_Create mit dem Flag OSD_Flag_Plane2. Kleiner Bug: Erzeugt man ein Fenster mit einer Plane2-Region, dann landet dieses trotzdem in der Plane 1 und hat damit den Nebeneffekt, dass beim Löschen des Fensters beide Planes gelöscht werden. Das wird in der Praxis aber nur selten vorkommen.

Beim MP sieht die Sache ganz anders aus. Fenster werden grundsätzlich in der Plane 1 angelegt, OSD-Operationen ebenfalls grundsätzlich in der Plane 2. Deshalb scheint selbstgemalter Text immer hinter einem Fenster auf. Da TAP_Osd_GetBaseInfo auch auf den Speicher der Plane 2 verweist, bleiben alle Fenster für die div. OSD-Abfragen unsichtbar. Großer Bug: TAP_Osd_Delete löscht den Bereich immer in beiden Planes. Wenn Korea durch die Aufteilung eine Kollision zwischen OSD und Dialogboxen verhindern wollte, haben sie sich mit diesen Bug ins Knie geschossen.

Workaround: Natürlich beide Bereiche testen. Nachdem man sich nicht auf TAP_Osd_GetBaseInfo verlassen kann, organisiert man sich die beiden Speicherbereiche aus den Hardwareregistern der Graphic Controlers.
Die beiden zeigen leider noch nicht direkt auf den OSD-Speicher, sondern auf eine Struktur, die unter anderem die Speicheradressen enthält. Bevor man weitermacht, sollte man die beiden Register auf 0 prüfen. Das kann nach dem Löschen der letzten Region vorkommen. Zuerst berechnet man die Adresse der Info-Struktur. Das sieht umständlich aus, da das oberste Nibble der DGRP-Register für eine andere Information verwendet wird.
Und danach organisiert man sich die Startadresse der even und odd Frames der beiden Planes.
Den Workaround habe ich zwar noch nicht praktisch ausprobiert, ich weis aber, wo ich dann abschreiben kann.

Super, vielen Dank. Sobald ich Zeit habe, werde ich das Umsetzen. Nur noch eine kurze Frage: ist dieser Controller identtisch für alle Modelle, oder muss man da Unterscheidungen treffen?

Gruß

Umtauscher

Das sollte zumindest bei allen 5000er funktionieren.

Hi Firebird,

meine ersten Versuche haben leider nicht zum gewünschten Erfolg geführt. OSDActive() ist jetzt immer TRUE. Ich vermute daher, dass bei der Berechnung der Pointer etwas nicht stimmt.

FireBird hat geschrieben:

Code: Alles auswählen

dword			*pOSD1Info, *pOSD2Info;

pOSD1Info = (dword *) ((*DGRP_OSD1CTR & 0x0fffffff) | 0xa0000000);

Bist Du sicher, dass das so stimmt? Du löschst erst das oberste Nibble und setzt anschließend die bit 3 und 1 fest auf 1?
Ich wäre für eine kurze Erkärung dankbar.

Umtauscher

P.S.: Hast Du vielleicht einen Link für mich für das Hardwaremanual des Grafikchips?

umtauscher hat geschrieben:Bist Du sicher, dass das so stimmt? Du löschst erst das oberste Nibble und setzt anschließend die bit 3 und 1 fest auf 1?

Im Register steht z.B. 0x21F72B70, die korrekte Adresse lautet 0xA1F72B70.

Ich habe mir gerade OsdActive angesehen und wundere mich, dass das jemals funktioniert hat. Nachdem das OSD in gerade und ungerade Zeilen unterteilt ist, ist jeder der 4 Speicherblöcke nur 720 x 288 Pixel groß. Die Routine checkt aber bis zur Zeile 500 und läuft somit in einen Bereich, der für andere Dinge benutzt wird. Oder übersehe ich etwas?

umtauscher hat geschrieben:P.S.: Hast Du vielleicht einen Link für mich für das Hardwaremanual des Grafikchips?

Der "Chip" ist Bestandteil der Emma und für dieses Manual würden manche töten. Ich habe es nicht.

FireBird hat geschrieben: Ich habe mir gerade OsdActive angesehen und wundere mich, dass das jemals funktioniert hat. Nachdem das OSD in gerade und ungerade Zeilen unterteilt ist, ist jeder der 4 Speicherblöcke nur 720 x 288 Pixel groß. Die Routine checkt aber bis zur Zeile 500 und läuft somit in einen Bereich, der für andere Dinge benutzt wird. Oder übersehe ich etwas?

Das sehe ich auch so und habe das bereits geändert. Es könnte aber sein, dass die beiden Blöcke hiontereinander liegen. Dann könnte es zufällig funktionieren. (Habe ich aus faulheit nicht geprüft. ;-)

umtauscher hat geschrieben:Es könnte aber sein, dass die beiden Blöcke hiontereinander liegen.

Laut MemDump tun sie das nicht und dazwischen ist etwas, dass die Routine fälschlicherweise als Pixeldaten interpretiert.

Bist Du sicher, dass die Maskierung für alle Register korrekt ist?

Eigentlich schon. Ich habe jetzt aber die Dumps nicht griffbereit.