Zitat:

---

Original von gni:

Zitat:

---

thomas:
Korrekt muß es also so lauten:

code:

---

/* Die Uhr hat sich gemeldet... */
if(Signale & (1UL << TimerMP->mp_SigBit))
{
   WaitIO ((struct IORequest *) TimerIO);

   TimerIO->tr_node.io_Command = TR_GETSYSTIME;
   DoIO((struct IORequest *) TimerIO);

---

---

Und ohne Casts wäre es noch viel besser...

---

Würde aber reichlich Warnungen bringen

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Zum WaitIO(): Aus welchem Grund muß denn, wenn das timer.device das Signal gesetzt hat, nochmal extra auf Beendigung des Requests gewartet werden?

---

Zitat:

---

Darf man nicht davon ausgehen, daß der Request bearbeitet wurde, wenn das gewünschte Signal eintrifft?

---

Zitat:

---

Ich frage so dusslig, weil ich zum WaitIO() an dieser Stelle weder in den RKMs noch in den AutoDocs was finde...

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von thomas:
@whose:

Zitat:

---

Zum WaitIO(): Aus welchem Grund muß denn, wenn das timer.device das Signal gesetzt hat, nochmal extra auf Beendigung des Requests gewartet werden?

---

WaitIO wartet nicht, wenn der Request bereits beantwortet wurde. Aber es räumt auf und das fehlt in deinem Programm.

Zitat:

---

Darf man nicht davon ausgehen, daß der Request bearbeitet wurde, wenn das gewünschte Signal eintrifft?

---

Der Request wurde bearbeitet, aber du mußt die Antwort noch abholen.

Zitat:

---

Ich frage so dusslig, weil ich zum WaitIO() an dieser Stelle weder in den RKMs noch in den AutoDocs was finde...

---

Doch, das steht da irgendwo.

---

Ach, Du meinst das Räumen des MessagePorts von unterschiedlichen Replys, jetzt verstehe ich. Na, das ist hier doch aber nicht gegeben. Es kommt immer der gleiche IORequest zur Anwendung. Da wäre das Aufräumen etwas Overkill, vor allem für die, die gerade hineinschnuppern. Da sollte man besser ein Beispiel mit mehreren asynchronen Requests aufsetzen, da läßt sich das (meiner Meinung nach) viel besser zeigen, wozu die GetMsg()-Mimik überhaupt gut ist.

Das könnte man evtl. auch so machen, indem man für TR_GETSYSTIME einen eigenen Request nimmt und dann in der Wait()-Schleife TR_ADDREQUEST an erster Stelle in der Bearbeitung setzt. Da wäre dann ein WaitIO() vor dem DoIO() fällig oder auch ein GetMsg(TimerMP), um die unterscheidlichen Requests aus dem Port zu bekommen. Besonders verständlich wäre es aber wieder nicht, denke ich. Dafür ist das Programm an sich einfach zu simpel (soll heißen: Zu geradlinig im Ablauf. Das kann kaum einer nachvollziehen, warum man dann so ein "Tamtam" um die Replies macht).

Grüße

Edit: Ich habe das Beispiel nun an die Anregung angepaßt und den dussligen Fehler beim Test auf die Signale beseitigt.
--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 26.06.2006 um 16:28 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

@thomas:

Mal ne ganz andere Frage an den Fachmann für anfängerfreundliche Tutorials (das ist nicht ironisch gemeint):

Wie würdest Du es lösen, mehrere Requests zu verwenden, ohne die IORequest-Strukturen an sich zu kopieren? Mir kam und kommt der Ansatz, das betreffende Device für jeden IORequest einfach nochmal zu öffnen, nicht so besonders "elegant" vor. Andererseits beherrschen manche der älteren Compiler das Kopieren von Strukturen ja nicht.

Würdest Du es für gut heißen, sich in diesem Fall auf die AmigaOS-internen Strukturen (und Definitionen) zu stützen, um alle notwendigen Felder der weiteren IORequest-Strukturen "von Hand" zu initialisieren? Das wäre jetzt ad hoc die einzige Lösung, die mir dazu einfällt...

Ich habe das Beispiel inzwischen so modifiziert, daß TR_ADDREQUEST und TR_GETSYSTIME jeweils ihren eigenen IORequest benutzen und diese ordentlich bearbeitet (und aus der Message Queue "entsorgt") werden, wenn sie ausgeführt wurden. Nur die Chose mit dem mehrfachen Öffnen des timer.device schmeckt mir nicht so ganz. Da muß es doch nen eleganteren Weg geben, um auch ältere Compiler da nicht auszuschließen.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von thomas:

Ich weiß nicht genau, was du meinst. Wenn du mehrere Timer brauchst, solltest du das timer.device auch mehrmals öffnen. Könnte ja sein, daß du unterschiedliche Units für unterschiedliche Genauigkeiten brauchst. Und wenn sich das erst zu einem späteren Zeitpunkt während der Programmentwicklung herausstellt, dann mußt du das ganze Programm umbauen.

---

Zitat:

---

Wenn du mehrere Requests nacheinander machst, reicht natürlich ein OpenDevice, dann kannst du den gleichen IORequest weiterbenutzen.

---

Zitat:

---

Speziell für GETSYSTIME würde ich eher die Funktion GetSystTime benutzen, die ist auch ausdrücklich als schneller dokumentiert. Oder gleich DateStamp oder CurrentTime, was man eben braucht.

---

Ja, das sehe ich ein. Für das Uhr-Beispiel ist es aber ganz praktisch, wenn man die Verwendung mehrerer, asynchroner Requests demonstrieren will. Ich habe das Beispiel schon darum erweitert, aber mir gefällt die Sache mit dem mehrfachen Öffnen ein und derselben Unit des timer.device halt nicht so besonders.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von thomas:

Ich finde es nicht unelegant, das timer.device mehrmals zu öffnen. Wie gesagt, wenn du dich später entschließt, die Unit eines Requests zu ändern, mußt du sonst das ganze Programm umschreiben.

---

Zitat:

---

Für das Demonstrieren mehrerer Signale, finde ich, reicht es aus, wenn man auf den Timer, auf das Fenster und auf Ctrl-C wartet, das sind ja schon drei asynchrone Sachen.

---

Naja, das hatten wir vorher ja auch schon, immerhin wurde auch aufs Close-Gadget gewartet... das ist aber nicht das Gleiche wie asynchrone IORequests

Zitat:

---

Ich habe hier auch mal ein Beispiel für eine Uhr gebastelt: http://thomas-rapp.homepage.t-online.de/examples/uhr.c

---

Gewohnte Qualität... eine Frage hab ich aber: wozu dient das Dragbar-Gadget?

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

das ist aber nicht das Gleiche wie asynchrone IORequests

---

Zitat:

---

wozu dient das Dragbar-Gadget?

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von thomas:

... und gleich nochmal verbessert (jetzt hat es zwei Timer, allerdings mit unterschiedlichen Units).

Zitat:

---

das ist aber nicht das Gleiche wie asynchrone IORequests

---

Wieso nicht ? Du hast eine Wait()-Anweisung, in der du auf alle Signale wartest. Wenn ein Signal erkannt wird, reagierst du entsprechend. Ob das nun ein Fenster, ein Timer, eine Soundausgabe, eine Message von einem Sub-Task oder ein Break-Signal ist, die Behandlung läuft immer gleich ab.

---

Schon, aber bei verschiedenen, asynchronen IORequests mußt Du die Request-Replies selbst noch einmal unterscheiden. Sonst weißt Du ja nicht, auf welchen Timer-Event Du nun reagieren sollst. Das ist doch schon ein kleiner Unterschied zu den bekannten Signalen, finde ich. Kann jedenfalls nicht schaden, das mal zu demonstrieren

Zitat:

---

Zitat:

---

wozu dient das Dragbar-Gadget?

---

Ähm, als Drag-Bar... Damit kannst du das Fenster durch die Gegend ziehen, obwohl es keinen Rahmen hat (WFLG_BORDERLESS). Um zwei Uhren miteinander zu vergleichen, sollten sie möglichst nahe beieinander sein und dafür muß man mindestens eine der Uhren bewegen können ;-)

---

Ach je... gar nicht registriert, daß das ein Borderless-Window ist

Danke für den Augenöffner

Edit: Hehe, das war Gedankenübertragung, oder? Auf das "Nachlaufproblem", wenn die Systemzeit zurückgestellt wird, wollte ich Dich gerade aufmerksam machen

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 26.06.2006 um 21:17 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Schon, aber bei verschiedenen, asynchronen IORequests mußt Du die Request-Replies selbst noch einmal unterscheiden. Sonst weißt Du ja nicht, auf welchen Timer-Event Du nun reagieren sollst.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von thomas:

Zitat:

---

Schon, aber bei verschiedenen, asynchronen IORequests mußt Du die Request-Replies selbst noch einmal unterscheiden. Sonst weißt Du ja nicht, auf welchen Timer-Event Du nun reagieren sollst.

---

Ok, das liegt wohl daran, daß du den IORequest kopierst und dann den selben Message-Port für mehrere Timer benutzt. Dann hast du natürlich das Problem, daß du beim Auftreten des Signals erstmal nachschauen mußt, welcher Request denn jetzt zurückgekommen ist. Dann kannst du auch schlecht mit WaitIO arbeiten, sondern mußt die Messages mit GetMsg abholen und kannst dann am Pointer erkennen, welcher Request es ist.

---

Zitat:

---

Das ist alles einfacher, wenn man das Device mehrmals mit je einem eigenen IORequest und MsgPort öffnet. Dann hat jeder Request ein eigenes Signal und man kann bereits am Signal erkennen, welcher Request es ist.

---

Ja, auf die Art ist es ziemlich simpel

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

whose:

Zitat:

---

gni:
Und ohne Casts wäre es noch viel besser...

---

Würde aber reichlich Warnungen bringen ;)

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

whose:
Andererseits beherrschen manche der älteren Compiler das Kopieren von Strukturen ja nicht.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von gni:

Zitat:

---

whose:

Zitat:

---

gni:
Und ohne Casts wäre es noch viel besser...

---

Würde aber reichlich Warnungen bringen

---

Soweit ich weis, hat timerequest einen eingebetteten IORequest. Damit kann man sich solch unsinnige Casts wie in dem Beispielprogramm sparen.

---

Sofern man dem Compiler mitteilt, daß man die entsprechenden Warnungen nicht sehen möchte, kann man das. Wie an so vielen anderen Stellen auch. Aber ich caste lieber, statt "Kleinigkeiten" zu verwechseln und mich dann zu fragen, weshalb etwas kracht

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von gni:

Zitat:

---

whose:
Andererseits beherrschen manche der älteren Compiler das Kopieren von Strukturen ja nicht.

---

Was für Museumsstücke verwendest Du denn? ;-) Du kannst immer "zu Fuß" kopieren, zb. mit memcpy.

---

Ich verwende keine Museumsstücke mehr Aber es soll noch Leute geben, die mit dem Lattice/SAS5.2 arbeiten, der kanns z.B. nicht.

Danke für den Tip mit dem blanken Speicher-Kopieren... irgendwie rostet man ein, wenn man nicht hin und wieder Museumsstücke benutzt, glaube ich

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:
Hm, ich hatte eigentlich nur eine einfache Frage nach dem Sekundentakt gestellt und wie ich nun in diesem Thread kann, ist dies unter umständen recht kompliziert.

---

So kompliziert ist es eigentlich gar nicht. Es gibt halt nur recht viele Möglichkeiten, das zu realisisieren und je nach Anspruch einiges zu beachten (z.B. Genauigkeit, Gleichlauf mit der Systemzeit etc.). Für Dein spezifisches Problem hat sich ja ne Lösung gefunden, das andere ist mehr theoretischer Natur

Zitat:

---

Bzw. finde ich auch die Diskusion unter C-Profis schon recht interesant, die sich sogar bei diesem Thema noch Hürden finden.

---

Wie gesagt, das ist mehr eine Frage der Ansprüche. Je höher die Ansprüche, desto höher die Hürden

Zitat:

---

Und genau so geht es mir als noch mit C, leider. Ich komme zwar langsam voran (sehr langsam), aber ich bin da hin und wieder dennoch im Nahkampf mit dem Compiler. Aber das ist ja ein bekanntes Problem.

Deswegen laufen zur Zeit alle meine Projekte noch unter MaxonBasic. Und vermutlich auch noch die nächsten. ...

---

Eventuell wäre Cubic ne Idee... das installiert die Compiler ordentlich, man kann zwischen verschiedenen Varianten wählen und die Konfiguration ist auch verhältnismäßig simpel zu erledigen.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Eventuell wäre Cubic ne Idee... das installiert die Compiler ordentlich, man kann zwischen verschiedenen Varianten wählen und die Konfiguration ist auch verhältnismäßig simpel zu erledigen.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:

Also, es gibt laufend Probleme die umschifft werden möchten. Das meinte ich mit Nahkampf mit dem Compiler...

---

Naja, bis auf die Zeichenprobleme (Shift-Space) und Vertipper gibts die Probleme mit Cubic nicht. Das läuft "direkt aus der Kiste" und die Optionen der Compiler sind einigermaßen verständlich aufbereitet (z.B. C99-Option für vbcc). Das Gleiche gilt für die GCC-Installation.

Das Verstehen der Optionen ist allerdings ne andere Sache (verdammtes Englisch )... aber da hilft Nachfragen

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:

das vierte, wieder fehler vom compiler an einer if-stelle, die ich einfach durch herrausloeschen der gleichen (war an dieser stelle möglich) beseitigen konnte.

erst dann(!) lief es!

---

Welches if hast Du denn rausgemacht?
--
http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:
Hm, ich hatte eigentlich nur eine einfache Frage nach dem Sekundentakt gestellt und wie ich nun in diesem Thread kann, ist dies unter umständen recht kompliziert.
Bzw. finde ich auch die Diskusion unter C-Profis schon recht interesant, die sich sogar bei diesem Thema noch Hürden finden.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Mad_Dog:
Welches if hast Du denn rausgemacht?

---

code:

---

/* Farbwert hängt vom Parameter n ab */
        n = Berechne_n( (double)(x+x_offset)/zoom,(double)(y+y_offset)/zoom);

        if (n>=100) SetAPen(rp,Pens[0])
        else SetAPen(rp,Pens[n%64]);

        WritePixel(rp,x+xmax,y+ymax);

---

das else an dieser stelle macht das Problem. Bzw. Warning 54 kommt bei vbcc. Keine Ahnung wieso.

Außerdem ist da noch eine Sache:
Mir ist schon klar, wenn man das ganze im Fastram berechnen lassen würde und dann auf einmal blitten würde, wäre das ganze schneller. Allerdings wenn ich da zum vergleich jetzt z.b. Mand2000 betrachte, der braucht für eine 320*200 Mandelbrotgrafik weniger als eine Sekunde und man kann da beim zeilenweise Aufbauen zusehn! Bzw. baut er von der Mitte aus auf. Wenn man weiter rein Zoomt, dann wird es ja auch langsamer und man kann es genauer erkennen wie er aufbaut.

Vom Geschwindigkeitsunterschied würd ich mal tippen das er so groß ist wie MaxonBasic<->C, also extrem. Ich kann mir kaum vorstellen das diese WritePixel-Orgie so stark bremst.
Mich würde das ganze mal mit Zeilenweise Aufbau, bzw. Bilschirmweise Aufbau interesieren. Bzw. was das für ein Unterschied ist. Ich werd das später mal testen, wenn ich das hinbekomme mit C. Bzw. einfach mal die Ausgabe weg lassen.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

whose:
Sofern man dem Compiler mitteilt, daß man die entsprechenden Warnungen nicht sehen möchte, kann man das.

---

Zitat:

---

Danke für den Tip mit dem blanken Speicher-Kopieren... irgendwie rostet man ein, wenn man nicht hin und wieder Museumsstücke benutzt, glaube ich

---

[ - Antworten - Zitieren - Direktlink - ]

Hab es eben mehrfach getestet, es macht kaum was aus. Der aufbau dauert fast eine Minute auf meinem 060er mit AGA. Ich vermute einfach mal das vbcc in der Standardkonfiguration auf 68000er compiliert. Macht das wirklich so viel aus? Muß mal nachsehn wie ich da auf 060er schalt und dann mal testen...

EDIT:
Hab eben einiges getestet, aber die Option fpu=68060 hat die Zeit auf 8 Sekunden reduziert. *Das* war eben ein Geschwindigkeitsschub! So, bin gerade auf Optionen warmgelaufen, wie kann man noch mehr rausholen? Hab jetzt folgendes hinzugefügt:

-cpu=68060
-fpu=68060
-speed

Was würdet ihr noch empfehlen?

--
http://www.alternativercomputerclub.de.vu

[ Dieser Beitrag wurde von Ralf27 am 27.06.2006 um 21:54 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:

code:

---

/* Farbwert hängt vom Parameter n ab */
        n = Berechne_n( (double)(x+x_offset)/zoom,(double)(y+y_offset)/zoom);

        if (n>=100) SetAPen(rp,Pens[0])
        else SetAPen(rp,Pens[n%64]);

        WritePixel(rp,x+xmax,y+ymax);

---

das else an dieser stelle macht das Problem. Bzw. Warning 54 kommt bei vbcc.

---

Zitat:

---

Keine Ahnung wieso.

---

[ - Antworten - Zitieren - Direktlink - ]

code:

---

warning 54 in line 167 of "ram:Testk.c": ; expected

---

Ok, danke, dann ist mir auch klar was da oben steht. Dann ist das also der Fehler im Code vom Maddog. Und wenn ich das richtig verstanden habe, ist das nur eine Warnung, das ganze läuft aber dennoch.

@MadDog:

Bugreport: Hab da en Fehler gefunden.

--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von gni:

Zitat:

---

whose:
Sofern man dem Compiler mitteilt, daß man die entsprechenden Warnungen nicht sehen möchte, kann man das.

---

Nix mit Warnungen unterdrücken! timerequest enthält am Anfang einen engebetteten IORequest und genau den übergibt man mittels &req->tr_node. Damit hat man ohne cast den richtigen Typ. In Amiga-Programmen wird viel zu oft mit Casts gearbeitet...

---

Zitat:

---

Zitat:

---

Danke für den Tip mit dem blanken Speicher-Kopieren... irgendwie rostet man ein, wenn man nicht hin und wieder Museumsstücke benutzt, glaube ich

---

Du kannst auch CopyMem aus Exec verwenden ;-)

---

Ja, kann ich auch. Oder von Hand jedes einzelne Byte kopieren... ich sag ja: man rostet ein, wenns zu viel Komfort gibt

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:
@thomas:

code:

---

warning 54 in line 167 of "ram:Testk.c": ; expected

---

Ok, danke, dann ist mir auch klar was da oben steht. Dann ist das also der Fehler im Code vom Maddog. Und wenn ich das richtig verstanden habe, ist das nur eine Warnung, das ganze läuft aber dennoch.

@MadDog:

Bugreport: Hab da en Fehler gefunden.

---

Der Fehler passiert aber schnell, wenn man mehrere Klamotten in einer Zeile unterbringt. Kleiner Tipp fürs nächste Mal: Gruppier die Zeilen so um, daß alles in einer eigenen Zeile für sich steht. Dann sieht man recht leicht, wo ein Semikolon fehlt. Auch ungleiche Klammern fallen dadurch etwas schneller auf.

Und wenn Du mal ne Warnung bekommst, deren Bedeutung sich Dir nicht erschließt (weil Englisch ), frag einfach mal, reißt Dir keiner den Kopf für ab, denke ich

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:

Hab eben einiges getestet, aber die Option fpu=68060 hat die Zeit auf 8 Sekunden reduziert. *Das* war eben ein Geschwindigkeitsschub! So, bin gerade auf Optionen warmgelaufen, wie kann man noch mehr rausholen? Hab jetzt folgendes hinzugefügt:

-cpu=68060
-fpu=68060
-speed

Was würdet ihr noch empfehlen?

---

code:

---

register int x,y;

---

[ - Antworten - Zitieren - Direktlink - ]