TOS/MagiC // Uhr abschalten (Timerevent verhindern)

[rainers]

Hallo Markus,

vielen Dank für Deine tolle Hilfe und das Lob 
Sobald ich meine Pascal-Bücher wieder zur Verfügung habe, suche ich nach den Äquivalenz-Befehlen in ST-Pascal und setze Deinen Vorschlag um.

-R.

[rainers]

In dem Programm, das die Uhr loshaben will, schickst Du die entsprechende Nachricht (UHR_AUS) per appl_write() an dein Uhrenprogramm, dessen ap_id Du vorher mit appl_find() gesucht und gefunden hast. Die Uhr muß drauf reagieren und sich schlafen legen. Am Ende schickst Du ein UHR_AN and das Accessory und sie malt wieder auf dem Bildschirm rum.

Hallo Markus,

schade  , das wäre auch zu einfach gewesen.
Wie ich schon vermutet hatte, ST-Pascal hat die Funktionen appl_find/appl_write in der Form wohl nicht in seinem Befehlsumfang.
Leider "beherrsche" ich gerade mal diese Sprache so leidlich, so daß eine Portierung nach C für mich nicht in Frage kommt.

Danke nochmals für Deine Hilfe.
-R.

[rainers]

So. Habe mir das ganze mal unter richtiger Hardware angesehen.
Meine Uhr läuft oben/rechts. TwiLight schaltet sich ein. Die Uhr ist nicht mehr zu sehen (zeichnet nicht neu). TwiLight wird ausgeschaltet. Man kann kurz noch die Uhrzeit sehen, welche zum Zeitpunkt des Einschaltens von TwiLight aktuell war, kurz darauf wird die Uhrzeit aktualisiert.
Meine Uhr weiß nichts von TwiLight, "hört" also auch nicht auf Nachrichten von TwiLight. Und dennoch kann TwiLight dafür sorgen, daß die Uhr "stehen" bleibt.
Wie macht es das?

Würde mich riesig freuen, wenn einer der Programmier-Gurus hier einen Tip hat. Offenbar nutzt TwiLight irgendeine Systemfunktion, die es ermöglicht, die Uhr "anzuhalten".

Danke.
-R,

[mfro]

Nachdem es für diesen Zweck keine Systemfunktion gibt, ist es sehr wahrscheinlich, daß die Uhr gar nicht wirklich ausgeschaltet wird, sondern fröhlich weiterarbeitet und bloß nichts (oder eben etwas anderes) zu sehen ist.

Der Trick ist einfach: Physbase() (XBIOS #2), Logbase() (XBIOS #3) und Setscreen() (XBIOS #5). Mit Setscreen() kann man die physikalische Bildschirmadresse (der Speicherbereich, der auf dem Schirm erscheint) und die logische Bildschirmadresse (der Speicherbereich, den die Zeichenfunktionen als Bildschirm betrachten) auf unterschiedliche Adressen setzen.

Das Programm könnte folgendermaßen vorgehen:

• mit Physbase() und/oder Logbase die aktuelle Bildschirmadresse in Erfahrung bringen
• mit Malloc() einen zweiten Bildschirmspeicher allokieren
• den löschen

[li]mit Setscreen() den physikalischen Bildschirmspeicher auf den neuen Puffer setzen
[/li][/list]

Die Uhr malt weiter fröhlich ihre Uhrzeit, man sieht bloß nix, weil sie die auf den "versteckten" Bildschirm malt.

[HamSTer]

die antwort stand hier doch schon. mit wind_update() den bildschirm für andere applikationen sperren.

[rainers]

Der Trick ist einfach: Physbase() (XBIOS #2), Logbase() (XBIOS #3) und Setscreen() (XBIOS #5). Mit Setscreen() kann man die physikalische Bildschirmadresse (der Speicherbereich, der auf dem Schirm erscheint) und die logische Bildschirmadresse (der Speicherbereich, den die Zeichenfunktionen als Bildschirm betrachten) auf unterschiedliche Adressen setzen.

Danke für Deine Tips. Das werde ich so versuchen. Hört sich logisch an.
Erste Tests sehen schon ganz gut aus ;-)

die antwort stand hier doch schon. mit wind_update() den bildschirm für andere applikationen sperren.

Nein, das stand hier noch nicht. Aber ich denke, es ist auch nicht das Gesuchte, denn "wind" klingt mir nach "windows" und es handelt sich bei der Uhr doch nicht um ein Fenster.
In ST-Pascal finde ich auch keine Funktion, die so heißt. Danke für den Tip.


-R.

[rainers]

@mfro: Das ist echt toll, Deine Hilfe. Auf jeden Fall ist das eine Möglichkeit, die Uhr auszublenden.

Habe leider z.Zt. keine echte HW, so daß ich es nur im STeEm testen kann. Der scheint ein Problem mit MALLOC zu haben (nach langem guggeln habe ich im englischsprachigen Forum einen entsprechenden Beitrag gefunden). Jedenfalls kann ich keine 32000 Bytes mit MALLOC allokieren.
Das "switchen" der physikalischen Bildschirmadresse funktioniert aber bestens und die Uhr zeigt sich nicht mehr (bzw. aktuell an einer anderen Stelle).

Danke.
-R.

[mfro]

Jedenfalls kann ich keine 32000 Bytes mit MALLOC allokieren.

Kannst Du ein statisches Feld mit 8000 LONG_INTEGERs anlegen? Das wär' doch genauso gut (zumindest solange das im ST-RAM angelegt würde)?

[mfro]

die antwort stand hier doch schon. mit wind_update() den bildschirm für andere applikationen sperren.

Das wird m.E. nicht funktionieren.

wind_update(BEG_UPDATE) sorgt lediglich dafür, daß die AES keine Bildschirmausgaben (Fensterelemente, Menüs, Fileselect-Boxen, ...) mehr machen und die Rechtecklisten "eingefroren" werden.

"Normale" VDI-Funktionen werden dadurch nicht ausgebremst, sondern lediglich die Aktionen, die sich streng an GEM-Konventionen halten und nur dahin malen, wo es die AES-Rechtecklisten erlauben.

[rainers]

Kannst Du ein statisches Feld mit 8000 LONG_INTEGERs anlegen? Das wär' doch genauso gut (zumindest solange das im ST-RAM angelegt würde)?

Meinst Du in etwa so:
----------
VAR lPBase, lLBase, lNewAddress : long_integer;
    aScreen : ARRAY[1..8064] OF long_integer;


lNewAddress := Adr_Long_Integer(aScreen[1]);
IF lNewAddress <> 0 THEN
BEGIN
   lPBase := PHYSBASE;
   lLBase := LOGBASE;
   IF lPBase > lNewAddress THEN
   BEGIN
      lNewAddress := ((lPBase - lNewAddress) mod 256) + lNewAddress;
   END
   ELSE
   BEGIN
      lNewAddress := (256 - ((lNewAddress - lPBase) mod 256)) + lNewAddress;
   END;
   SETSCREEN(lNewAddress, -1, -1);

   .......
            
   SETSCREEN(lPBase, -1, -1);
----------

Ja. Das funktioniert prima. Die Uhr ist weg.
Einzig, nach jedem Prog-Aufruf fehlen 14 Bytes im RAM.
Sollte ich das Prog. ev. mit PTERM beenden?

[mfro]

Einzig, nach jedem Prog-Aufruf fehlen 14 Bytes im RAM.
Sollte ich das Prog. ev. mit PTERM beenden?

Das kann eigentlich nicht durch deinen Code - zumindest den Teil, den Du gezeigt hast - verursacht sein.

Ich gehe davon aus, daß die ST-Pascal Runtime-Library am Programmende bereits einen Pterm()-Aufruf macht, so daß ein zusätzlicher Aufruf höchstens noch zusätzlich was durcheinander brächte. Passiert das nur bei diesem oder auch bei anderen Pascal-Programmen?

Ich habe irgendwie in blasser Erinnerung, daß manche TOS-Versionen beim Programmende Filehandles nicht korrekt freigeben. Hast Du alles wieder zugemacht, was Du geöffnet hast?

[m0n0]

mit Setscreen() den physikalischen Bildschirmspeicher auf den neuen Puffer setzen

Soweit ich weiss ist das ein No-Go unter Multi-Tasking Betriebs-Systemen, da die anderen Anwendungen nicht wissen das sich die Adresse des Bildschirmspeichers verändert hat...

Würde es für sowas eine VDI Konforme Funktion geben, dann wäre das eine Option, aber das ganze ist noch eine schicht darunter (XBIOS) und somit bringt man alle VDI Funktionen die von anderen Programmen aufgerufen werden durcheinander, AFAIK.

[mfro]

mit Setscreen() den physikalischen Bildschirmspeicher auf den neuen Puffer setzen

Soweit ich weiss ist das ein No-Go unter Multi-Tasking Betriebs-Systemen, da die anderen Anwendungen nicht wissen das sich die Adresse des Bildschirmspeichers verändert hat...

Würde es für sowas eine VDI Konforme Funktion geben, dann wäre das eine Option, aber das ganze ist noch eine schicht darunter (XBIOS) und somit bringt man alle VDI Funktionen die von anderen Programmen aufgerufen werden durcheinander, AFAIK.

Ich meine, daß das in dem Fall gar nichts ausmacht.

Die VDI-Funktionen (egal, wer sie aufruft) malen weiterhin schön auf den (nicht mehr sichtbaren) Bildschirm - und nichts anderes will der Rainer erreichen. Problematisch ist m.E. lediglich die Ausgabe auf dem "physischen" Bildschirm. Offensichtlich kriegt man da mit Systemfunktionen nichts mehr zur Anzeige (muß sich also seine Ausgaberoutinen selber basteln).

Natürlich gibt es Grenzen (wie fast überall beim Atari). Die Methode dürfte mit vielen Grafikkarten (die die Umschaltung nicht beherrschen) nicht funktionieren.
Meines Wissens verwendet der Pure-C Debugger PD diese Methode, um seine eigene Ausgabe und die des zu debuggenden Programms auseinanderzuhalten (und der hat auch Probleme mit Grafikkarten).

[mfro]

Ach so, eins habe ich vergessen.

Auch wenn nichts zu sehen ist - Mausbewegungen und -klicks sowie Tastatureingaben landen immer noch auf dem logischen Bildschirm. Nur eben ohne "optische Rückmeldung". Damit da nichts passiert, wäre es sinnvoll dafür zu sorgen, daß die kein Unheil anrichten können (womit wir dann doch wieder bei wind_update(BEG_UPDATE) bzw. wind_update(BEG_MCTRL) wären). Oder noch besser (weil wir ja sowieso schon abseits "sauberer GEM-Konventionen" sind) per Umbiegen der Tastatur- und Mausvektoren (Kbdvbase()) auf eigene Routinen. 

[rainers]

Das Programm, welches die Uhr "abschalten" soll, läuft nur unter TOS (single-task-Modus).
Ich denke, da kann nichts weiter passieren.
Mit dem von "mfro" Vorgeschlagenen bin ich glücklich. Es funktioniert wie ich es mir gewünscht hatte.
Das mit dem Speicher "fressen" liegt ganz offensichtlich nicht an meinem Programm. Egal, welches Programm ich aufrufe, es fehlen danach immer ein paar Bytes.

Danke nochmals.
-R.