atari-home.de - Foren
Software => Coding => Thema gestartet von: rainers am Mo 08.04.2013, 20:13:11
-
Hallo,
der Bildschirmschoner "TwiLight" hat eine Option "Uhren ausschalten".
So etwas würde ich gern in einem Programm ebenfalls tun, damit eine Bilddarstellung im Vollbildmodus nicht durch eine laufende Uhr gestört wird.
Hat jemand bitte einen Tip für mich, wie ich das bewerkstelligen kann? Sprache ist egal, solange es nicht Assembler ist (ich suche mir dann schon das Passende in ST-Pascal).
Ich kann mir denken, daß es irgend etwas wie "Disable Timer" geben wird, aber welche Funktion (GEM, BIOS, XBIOS) wäre es konkret.
Vielen Dank.
Gruß
-R.
-
Wie meinst Du das? Malt da im Hintergrund ein anderes Programm eine Uhrzeit über den Bildschirmschoner oder was? O.o
-
Kopf kratz ??? ;-)
Also Screensaver kennt doch TOS in dem Sinne nicht. Man kann die nur nachstellen.
Aber darum geht's mir nicht primär.
Meistens läuft doch oben/rechts in der Menüleiste eine Uhr. Und die reagiert auf ein Timer-Event.
Wenn nun ein Prog (zum Beispiel eben ein Screensaver) im Vollbildmodus läuft, dann sieht's ja echt bescheiden aus, wenn alle Sekunde oder zwei, die Uhrzeit neu dargestellt wird.
TwiLight zum Beispiel ist offenbar so programmiert, daß es per Option ermöglicht, das aussenden des Timer-Events zu unterdrücken (oder so etwas in der Art, ich kann da nur mutmaßen) und dadurch wird verhindert, daß die Uhr weiter angezeigt wird.
Im GFA-Basic gibt es zum Beispiel die Funktion "KILLTIMER", aber leider finde ich nichts Weitergehendes dazu.
-R.
-
...Ich kann mir denken, daß es irgend etwas wie "Disable Timer" geben wird, aber welche Funktion (GEM, BIOS, XBIOS) wäre es konkret.
Ich weiß nicht, ob sich das generell beantworten läßt, Uhrenprogramme können verschiedene Methoden benutzen, um sich auf den Schirm zu zaubern.
Die ganz grobe Methode müsste funktionieren (aber mit ziemlicher Sicherheit andere, möglicherweise unangenehme Nebeneffekte haben):
Jdisint(5); (* XBIOS #26 *)
Damit sperrst Du den Timer C Interrupt des MFP - die Uhrenroutine wird nicht mehr aufgerufen.
Nicht vergessen, vor Programmende mit
Jenabint(5); (* XBIOS #27 *)
den Timer C wieder zu aktivieren.
Gruß,
Markus
-
Ach so. Nein, oben läuft normalerweise keine Uhr. Es gab ACC´s, die oben eine Uhr einblenden konnten. Manche Programme wie der Tempus Editor hatten oben auch die Uhr drin. Ich würde einfach nach dem Programm oder ACC suchen, das die Uhr anzeigt und es beenden. Die Uhr anhalten geht nicht, und wenn würde oben eine stehende "Zeit" kommen. ;-)
-
Hallo Markus,
ja, in die Richtung zielt meine Frage. Aber ich befürchte, mit dieser "groben" Methode, werden gar keine Timer-Events mehr ausgelöst und damit wird das System höchstwahrscheinlich instabil.
Aber die XBIOS-Funktionen helfen mir schon einmal weiter, da kann ich weitersuchen. Vielen Dank dafür.
Grüße,
-R.
PS: @Imo: Die Uhr ist von mir ;-) und sie läuft oben/rechts ;-) Ich will sie nicht beenden, nur anhalten. Und wenn sie angehalten ist, zeigt sie auch keine Zeit mehr an, denn sie wird ja einfach nicht aufgerufen.
-
PS: @Imo: Die Uhr ist von mir ;-)
Wenn die Uhr von dir ist, dann müsstest Du ja wissen, wie sie programmiert ist, oder nicht?
Accessory oder Timer C?
-
Ich denke mal, das sind zwei völlig verschiedene Dinge. Die Uhr wird vom ST intern immer weiter getickt. Ob der Inhalt der Uhrzeit Variable auch irgendwie irgendwo ausgegeben wird, das ist dann die andere Frage. Ich vermute, Du willst die Darstellung der Uhr los werden, nicht die ganze Uhr. ;-)
-
Ich habe oben Mist geschrieben. Jdisint() ist XBIOS #26, nicht 25. Ich hab's korrigiert.
-
Ich vermute, Du willst die Darstellung der Uhr los werden, nicht die ganze Uhr. ;-)
Jaaaa. Genau das. ;) Nur die Darstellung soll "weg".
Schei..., ich drück mich immer so verquer aus ;)
-
Prima, also bleibt die Frage der Fragen: Wenn Du das selbst programmiert hast, wieso weißt Du dann nicht, an welcher Stelle des Programms Du die Uhr eingebaut hast? Die kannst doch dann auch selbst einfach wieder rauswerfen?! O.o
-
moin
ich hab ja keine ahnung vom programieren aber ich denk mir doch das dein program die uhr in den Bildschirmspeicher schreibt.
Wenn dann beim Aufruf der routine die Uhrfarbe auf dein Hintergrund oder sonstwelche farbe gesetzt wird, ist sie ja auch nicht sichtbar.
Weil, ich habe mir so gedacht das der Uhranzeige ja auch eine farbe zugeordnet werden muss
Iss nur angelesenes halbwissen :-\
-
Also jetzt kann ich nicht mehr folgen.
Die Uhr ist doch ein ACC. Die läuft immer. Sie tickt mit einem 250ms-Timer, schreibt die Zeit aber nur alle 2 sec.
Das Prog, welches im Vollbild-Modus läuft, ist ein anderes. Das ist ne Art Diashow von Bildern.
So.
Nun zeigt das Prog ein Bild an und die Uhr schreibt weiterhin ihren "Output". Und dann schreibt sie in "über" das Bild und das sieht doof aus.
Also soll das Prog, welches die Bilder (Diashow) anzeigt, dafür sorgen, daß die Uhr "ruht".
Mmmmhhhhh.
-
Reiner, wenn du die Uhr selbst geschrieben hast, dann solltest du sie einfach erweiteren, entweder dass sie eine feste Speicherzelle/Systemvariable/Cookiejar regelmäßig abfragt, oder über das Messagesystem von GEM Nachrichten empfangen kann. So kannst du deinem Uhren-ACC dann den Befehl geben, solange die Schnauze zu halten, bis ein gegenteiliger Befehl gesetzt wird. Den sendest du dann aus deinem Screensaver.
Ein unsauberer, fieser Trick, sozusagen "1980er Jahre Style"; wäre, den Bildschirmspeicher im Shifter zu verschieben, dein Bildschirmschoner nutzt dann den vom Shifter angesteuerten tatsächlichen Bildspeicher für seine grafische Effekthascherei, während alle GEM-konformen Programme weiterhin in den alten Bildspeicher malen. Sobald der Screensaver abgeschltet wird, wird das Register im Shifter wieder auf den Zustand davor restauriert. Das funktioniert aber nicht mit Grafikkarten. Das ist im Prinzip die Methode "Verdeckter Bildaufbau".
-
1ST1, (hach, jetzt weiß ích, wofür das ST steht, der Brüller :D :D),
ja, die Idee hatte ich auch. Und letztendlich werde ich es wohl auch so tun.
Nur, meine Intention war es ja, die Uhr auch abzustellen, wenn Fremdprogramme im Vollbildmodus laufen. Und die werden ja wohl kaum meiner Kuckucksuhr sagen: Schnauze halten!
;)
-
Wenn Du die Uhr selbst geschrieben hast, hast Du das doch ganz bestimmt richtig und systemkonform gemacht. Nämlich den System Timer Vektor per XBRA-Verfahren verbogen.
Wenn das so ist, mußt Du in deinem Screensaver doch nur den XBRA-Eintrag suchen und temporär aus der Vektorkette aushängen. Zum Programmende trägst Du den "richtigen" Vektor wieder ein und alles ist gut.
Gruß,
Markus
-
Stimmt, XBRA sollte auch gehen, da habe ich garnicht mehr dran gedacht.
-
Hallo,
Die Uhr wir oben rechts im Menu angezeigt? Das heißt also es ist ein Programm das unter GEM läuft? Dann würde ich form_dial probieren, denn eigentlich sollte der Bildschirmschoner den Bildschirm sperren, und somit würde das neuzeichnen der Uhr so lange warten bis der Bildschirmschoner den Bildschirm wieder freigibt. Das hat auch den Vorteil das die Uhr kein CPU verbraucht während der Bildschirmschoner läuft.
Oder denke ich da Falsch und ein ACC kann form_dial nicht aufrufen?
Schwieriger wirds wenn die UHR auch im Kommandozeilen modus angezeigt werden soll - so wie bei clocky....
-
Öööhm.
Ich bin doch kein "Hardcode coder". Ich wälze mich durch Bücher und wenn was Passendes gefunden wurde, dann nehme ich es und passe es meinen Bedürfnissen an. Sorry, wenn ich den Eindruck erweckt habe, ich könne programmieren. :D :D
Also meine Uhr ist praktisch ein Abfallprodukt. Sie ist in dem ACC enthalten, welches die CapsLock-LED steuert. Da dieses timer_event-gesteuert ist, dachte ich mir: Warum nicht dann darin auch gleich die Zeitanzeige verwirklichen.
Höchstwahrscheinlich ist der Begriff "Uhr" falsch. Es ist nur eine Zeitanzeige.
Weder XBRA habe ich verwendet, noch einen "System Timer Vektor" verbogen.
Hier ist der Auszug aus dem Code.
-----------------------------
BEGIN
IF Init_Gem >= 0 THEN
BEGIN
i := 8;
iDateTime_ := 0;
TEXT_COLOR(BLACK);
TEXT_HEIGTH(6);
SYS_FONT_SIZE(d, ch, d, d);
WHILE TRUE DO
BEGIN
IF (i mod i2Seconds) = 0 THEN
BEGIN
i := 8;
iDateTime := GET_DATE;
if iDateTime <> iDateTime_ THEN
BEGIN
iDateTime_ := iDateTime;
sDate := '00.00.00';
dt := iDateTime & $1F;
sDate[1] := Chr(dt div 10 + 48);
sDate[2] := Chr(dt mod 10 + 48);
dt := Shr(iDateTime, 5) & $F;
sDate[4] := Chr(dt div 10 + 48);
sDate[5] := Chr(dt mod 10 + 48);
dt := Shr(iDateTime, 9) & $7F - 20;
sDate[7] := Chr(dt div 10 + 48);
sDate[8] := Chr(dt mod 10 + 48);
END;
sTime := '00:00:00';
iDateTime := GET_TIME;
dt := Shr(iDateTime, 11) & $1F;
sTime[1] := Chr(dt div 10 + 48);
sTime[2] := Chr(dt mod 10 + 48);
dt := Shr(iDateTime, 5) & $3F;
sTime[4] := Chr(dt div 10 + 48);
sTime[5] := Chr(dt mod 10 + 48);
dt := 2 * (iDateTime & $1F);
sTime[7] := Chr(dt div 10 + 48);
sTime[8] := Chr(dt mod 10 + 48);
DRAW_STRING(570, ch - 9, sDate);
DRAW_STRING(570, ch, sTime);
END;
i := i + 1;
iEvent := Get_Event(E_Timer, 0, 0, 0, 250,
false, 0, 0, 0, 0, false, 0, 0, 0, 0,
mbMsg, d, d, d, d, d, d);
END;
END;
END.
-----------------------------
Danke Euch.
-R.
-
Öööhm.
Ich bin doch kein "Hardcode coder". Ich wälze mich durch Bücher und wenn was Passendes gefunden wurde, dann nehme ich es und passe es meinen Bedürfnissen an. Sorry, wenn ich den Eindruck erweckt habe, ich könne programmieren. :D :D
Wieso? Das ist doch gut!
Allerdings waren wir ein wenig auf dem falschen Dampfer. Du hast dich nicht in den Timer-Event gehängt, sondern die "saubere" Methode gewählt (Accessory mit GEM-konformen AES Timer Events). Vergiß, was ich oben geschrieben habe (XBRA).
Das beste wird sein, Du baust in deine Uhr noch zwei Eventhandler (MU_MESAG) ein, die als "Uhr aus" und "Uhr an" interpretiert werden. Dazu evnt_timer() durch evnt_multi() ersetzen und zusätzlich zum Timer auf zwei selbst gewählte Nachrichtennummern (UHR_AUS, UHR_AN) warten.
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.
Ein schönes Beispiel für GEM-Multitasking ohne MiNT und Magic!
-
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.
-
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.
-
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,
-
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.
-
die antwort stand hier doch schon. mit wind_update() den bildschirm für andere applikationen sperren.
-
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.
-
@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.
-
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)?
-
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.
-
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?
-
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?
-
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.
-
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).
-
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.
-
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.