Software > Coding

TOS/MagiC // Uhr abschalten (Timerevent verhindern)

<< < (7/7)

mfro:

--- Zitat von: Rainer (s) am Di 16.04.2013, 11:08:32 ---Einzig, nach jedem Prog-Aufruf fehlen 14 Bytes im RAM.
Sollte ich das Prog. ev. mit PTERM beenden?

--- Ende Zitat ---

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:

--- Zitat ---mit Setscreen() den physikalischen Bildschirmspeicher auf den neuen Puffer setzen
--- Ende Zitat ---

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:

--- Zitat von: m0n0 am Di 16.04.2013, 12:54:33 ---
--- Zitat ---mit Setscreen() den physikalischen Bildschirmspeicher auf den neuen Puffer setzen
--- Ende Zitat ---

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.

--- Ende Zitat ---

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.

Navigation

[0] Themen-Index

[*] Vorherige Sete

Zur normalen Ansicht wechseln