Zitat:

---

Original von Holger:

Das funktioniert so auch in Basic.

Das versagt erst <über den Daumen peil>ab ca. einer Stunde Wartezeit</über den Daumen peil>.

Allerdings fällt mir hier gerade ein Fehler auf. Das Ergebnis der Addition muss in jedem Fall in's Low-Word geschrieben werden...

Also korrekt eher so:

C code:

---

ULONG newLow = eclockval.ev_lo + diff;
if(newLow < eclockval.ev_lo)
{
  eclockval.ev_hi++;
}
eclockval.ev_lo = newLow;

---

---

Upps... ich habs irgendwie geahnt, daß ich da noch einen Bock drin habe... ich bin nur nicht drauf gekommen, was das sein könnte. Wald und Bäume und so...

Danke für die Korrektur.

Grüße

--
---

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

Zitat:

---

Original von TerAtoM:

Zitat:

---

Original von dandy:
Kann man hier nicht eine Deutsch-Rechtschreibprüfung zur Voraussetzung machen, bevor man hier die Mitgliedschaft erhält und posten darf?

Habe langsam keine Lust mehr, mir ständig die Postings irgendwelcher legasthenischen Pisa-Birnen 3-4 mal durchlesen zu müssen, bevor mir dann langsam ansatzweise klar wird, was dieser verhinderte Göthe denn nun von mir will!

Oder nehmt den Analphabeten endlich mal die Computer weg!

---

...ist mir jetzt eigentlich unverständlich warum dieses Posting nicht gelöscht wurde.

1. Diskriminierend
2. Beleidigend
3. Aufruf zur Enteignung einer Minderheit

Was kommt als nächstes? Die Deportation in KZ's?

---

Da isser doch, der AntiFa-Reflex... wie wäre es denn, wenn man diese Verunglimpfungen einfach mal beiseite läßt, wenn einem die andere Meinung nicht paßt? Argumentation statt plumper "Du bist'n Nazi!"-Sprüche, das wäre doch mal ein echter Fortschritt. Ganz nebenbei müßte Dein Post dann auch nicht gelöscht werden (streng betrachtet, Punkte 1 und 2 wären erfüllt).

Ich finds auch nicht in Ordnung, wenn man auf die Art wie dandy kommt, weil einem die aktuelle Verwendung der deutschen Sprache nicht paßt. Nichts desto trotz sollte man ihn schon fragen, ob er das so meint, wie er es schreibt. Es könnte ja auch sein, daß er einer der Menschen ist, die sich kaum unter Kontrolle haben, wenn sie in Rage kommen (durchaus keine kleine Minderheit). Allerdings frage ich mich, was hat das (abgesehen von der Wortwahl) mit Nationalsozialismus und dessen Folgen zu tun?

Tut mir leid, aber die Tour ist in meinen Augen genauso dumpf und beleidigend wie seine.

Grüße

--
---

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

Zitat:

---

Original von Maja:

@whose

> Sorry, ich finde, da machst Du Dir die Sache etwas zu einfach. Die
> Politik, die jetzt die ach so schmerzhaften Reformen voranbringen
> müßte, die wir ja nun brauchen, hat in all den Jahren zuvor nichts
> dafür getan, daß es eben nicht so weit kommt.

Die Regierung Kohl hat 16 Jahre lang überhaupt nichts getan, und wurde erst dann abgewählt, als selbst für Lieschen Müller klar wurde, dass das nicht der richtige Weg sein kann.

---

Zitat:

---

Dass sich danach so lange nichts bis kaum etwas bewegt hat und heute noch alles leider nur sehr zäh und oft genug nicht zufriedenstellend läuft, lieg überwiegend an der Art, wie hierzulande Gesetzfindung betrieben wird. Blockiert wurde und wird in diesem Land überweiegend von den Entscheidungsträgern im Bundesrat. Da wird von den Ministerpräsidenten der Länder schon lange vorher mit Blockade gedroht, wenn sich der Bundestag noch gar nicht einig ist.

---

Zitat:

---

Man kann nur hoffen, dass die Föderalismusreform dem zumindest teilweise ein Ende setzen kann. Übrings etwas, was die derzeitige Regierung endlich mal in die Gänge gebracht hat. Rot/Grün war dieses Eisen offenbar zu heiß.

---

Zitat:

---

> Eben. Die merken ganz genau, wo die Schwächen der "etablierten"
> Parteien liegen und nutzen sie aus. Was machen die etablierten
> Parteien dagegen? Auf den AntiFa-Reflexen herumreiten, statt
> wirklich gute Argumente und gute Politik für das Volk zu bringen.

Na ja, hier warst Du es, der auf die "AntiFa-Refelex" rumgeritten ist.

---

Neinnein, bei mir wars der Anti-AntiFa-Reflex

Zitat:

---

Was wäre denn eine gute Politik "für das Volk"? So wie es ausschaut, wäre das eine Politik der Polemik und Ausländerfeindlichkeit. Oder wie erklärst Du Dir sonst den Zulauf zu den extrem Rechten? Ganz offensichtlich erzählen die genau das, was "das Volk" hören will. "Alle Ausländer raus, und alles wird gut." Wer solchem Schwachsinn nachrennt, wer hinter "Deutschland den Deutschen" Transparenten herrläuft, dem kann keine noch so vernünftige Politk gut genug sein.

---

Zitat:

---

> Unsinn. Das ist etwas, vor dem Deutschland aus blanker
> Bequemlichkeit und allgemeiner Politikverdrossenheit mehr oder
> weniger kapituliert. Du kannst noch so viele Gegendemos aufziehen,
> an den Dingen des täglichen Lebens, der Unzufriedenheit, der
> Faulheit, der Rücksichtslosigkeit und Phantasielosigkeit der
> Menschen (und auch der Politik) wirst Du damit nichts ändern.

Polemik. Das Wort "Politikverdrossenheit" sagt alles. Das heißt nichts weiter als: "Wenn sie es nicht so machen, dass ich davon keinerlei Nachteile habe, will ich es nicht."

---

Zitat:

---

Ja, ich weiß. Die Erhöhung der MWST wird dieses Land ins Chaos stürzen. Das wurde von der Letzen und der Vorletzen auch behauptet....

---

Zitat:

---

> Das alles ist die Grundlage für den Erfolg der Rechten in manchen
> Gegenden. Die "bieten was an", was eben nicht nach dem üblichen
> Zeugs klingt und dem Eigennutz der Menschen entgegenkommt.

Und Du glaubst, mit solchen Politikikern würde es uns besser gehen? Denn offenbar erwartest Du von den Etablierten dasselbe. Was sollen sie denn erzählen, CDU/CSU, SPD, FDP?

---

Zitat:

---

> Das nennt sich demokratisch-freiheitliche Grundordnung. Genauso
> traurig ist es da, daß ein Ex-Kanzler auf relativ illegalen Pfaden
> wandeln kann, ohne dafür belangt werden zu können. Nur wäre es noch
> schlimmer, wenn es diese "Freiheiten" nicht gäbe, oder?

Wenn Du Kohls Spendenaffäre meinst. Der könnte sehr wohl belangt werden. Es traut sich nur keiner.

---

Zitat:

---

Du darfst aber gern versuchen mir das Wort im Mund herumzudrehen. In dieser demokratisch, frieheitlichen Grundordnung gibt es auch den Tatbestand der argwöhnischen Täuschung. Und traurig ist, dass der Verfassungsschutz scheinbar nicht in der Lage ist, verfassungsgemäß die Verfassung zu schützen.

---

Ich will Dir das Wort gar nicht im Munde herumdrehen. Sicher ist es traurig, daß beim Verfassungsschutz hoch dotierte "Experten" zu dämlich sind, eine Aktion, die auf V-Leuten basiert, rechtlich wasserfest durchzuziehen.

Andererseits wäre es aber auch traurig, wenn jemand in den Bau wandert, weil ein "Spitzel" ihm etwas andichtet. Also quasi auf vagen Verdacht, ohne ausreichende Beweise und aufgrund einer zweifelhaften Aussage. Das wäre ein Zustand wie unter Adolf, und das will ja eigentlich keiner.

Dummerweise ist der andere Weg nicht unbedingt der einfachere. Der freiheitliche Weg hat halt seinen Preis, und das ist u.A. verpatzte Aktionen gegen Feinde einer demokratisch-freiheitlichen Grundordnung.

Abgesehen davon ist es aber auch wieder etwas zu einfach, sich da nur auf den Verfassungsschutz zu verlassen, was unsere werte Politik ja derzeit vorzuziehen scheint, statt sich wirklich Gedanken zu machen, wie man die Rechten politisch kaltstellen kann. Ähnlichen Schmuh hat man in der Weimarer Republik auch verbockt...

Grüße

--
---

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

Zitat:

---

Original von Maja:

Allerdings sehe ich kaum, wie etablierte Parteien mit ihrer Politik wirklich etwas daran ändern können. Die Reformen, die dieses Land braucht, werden - so oder so gestaltet - diesen Bauernfängern die Anhänger in die Arme treiben.

---

Zitat:

---

Das hat auch herzlich wenig mit dem Bildungsniveau des Einzelnen zu tun. Eine höhere Schulbidung ist noch kein Garant für soziale Kompetenz und schützt auch nicht vor gefälliger Propaganda. Und die "Macher" der DVU sind leider ganz und gar nicht dumm.

---

Zitat:

---

Sonst wäre ihre Partei so weit nicht gekommen. Das ist etwas, wo Deutschland wieder viel zu tolerant geworden ist.

---

Zitat:

---

Alle wissen, worum es ihnen geht, doch auf grund fadenscheiniger Formulierungen kann ihnen keiner was. Traurig.

---

Das nennt sich demokratisch-freiheitliche Grundordnung. Genauso traurig ist es da, daß ein Ex-Kanzler auf relativ illegalen Pfaden wandeln kann, ohne dafür belangt werden zu können. Nur wäre es noch schlimmer, wenn es diese "Freiheiten" nicht gäbe, oder?

Grüße

--
---

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

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Ab und an scheint sich da auch noch was anderes bemerkbar zu machen, weil hin und wieder weniger Zeit angezeigt wird (im Rahmen bis -20000µs, ich tippe da auf einen Kontext-Switch zur unpassenden Zeit).

---

An sich kein Wunder, wenn man sich Dein Programm ansieht. Du holst Dir die EClock, welche die Basis für Dein Warten ist, dann machst Du diverse Dinge, wie Textausgabe, Berechnungen und ersten Request verschicken, und dann erst holst Du die Systemzeit, die den Beginn der Aktion markieren soll, Deine EClock, die Du als Basis für WAIT_ECLOCK benutzt, liegt aber schon deutlich früher.

---

Zitat:

---

Nur scheinen das Multitasking oder die Eigenheiten von GetSysTime() meistens noch größere Verfälschungen zu produzieren.

---

Zitat:

---

Die Abrundung der Wartezeit (diff = ticks / intervall;) fällt da kaum noch in's Gewicht (verkleinert aber auch...).

---

Zitat:

---

Übrigens ist die while((TimerMsg = GetMsg(TimerMP))) Schleife ("Für den Fall, das unser Programm zu langsam sein sollte") sinnlos. Du verschickst zwischen den WaitPort-Aufrufen nur genau einmal einen Request, und das ist auch gut so, denn Du hast ja auch nur den einen. Wenn mehr als eine Message an dem Port ankommen würde, wäre das ziemlich mystisch.

Ich versteh nicht, warum Du da nicht einfach WaitIO() benutzt.

---

Aah... sorry, das ist ein Test-Überbleibsel (habe ich heute Nacht vergessen rauszunehmen). Ich hatte da mit zwei IORequests experimentiert.

Wird ersatzlos gestrichen

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 17.09.2006 um 22:46 Uhr geändert. ]

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Wie meinst Du das mit der Echtzeit-Uhr? GetSysTime() bzw. GETSYSTIME läuft ja im Grunde nur via EClock, die wird ja beim Start einmal auf den "aktuellen Stand" gebracht und läuft dann "allein" weiter, da tut sich zwischen Emulator und Amiga nicht viel...

---

Nun, dass mein Programm mit der EClock synchron ist, habe ich ja schon geschrieben. Deshalb habe ich auch keinen weiteren Test durchgeführt, der auf der EClock basiert. Bringt ja nix.
Ich habe mit Date vor und nach dem Programm die reale Differenz gemessen, was man bei längeren Laufzeiten durchaus machen kann. Und da spielt's halt ne Rolle, ob man ne Echtzeituhr simuliert oder nicht, zumindest, solange die emulierte EClock von der Echtzeit erheblich abweicht.

---

Ah, ok. Nu hab ichs

Zitat:

---

Zitat:

---

Ab und an scheint sich da auch noch was anderes bemerkbar zu machen, weil hin und wieder weniger Zeit angezeigt wird (im Rahmen bis -20000µs, ich tippe da auf einen Kontext-Switch zur unpassenden Zeit).

---

Das habe ich bisher noch nicht bemerkt.

---

Zitat:

---

Zitat:

---

Man kann natürlich auch mal schauen, was die EClock dazu sagt (also die EClock-Unit als Referenz verwendet statt mit GetSysTime() zu messen).

---

Wozu?
ReadEClock() liefert doch schon die aktuelle EClock. So habe ich ja auch bei meinem Programm verifiziert, dass nach "WaitUntil x" die EClock auch "x + minimale Differenz" (aufgrund der nachträglichen Abfrage) enthält.
Also kann ich Dir schon mal sagen, dass die EClock den erwarteten Wert enthält. Aber Du kannst ja nach dem Programm einfach noch mal ReadEClock() aufrufen...

---

Naja, wenn Du das schon gemacht hast, brauche ich das ja nicht mehr. Ich darf also davon ausgehen, daß das jetzt paßt mit dem Timer?

Zitat:

---

Zitat:

---

Ach nochwas: Mein Überlauf-Test ist ja wirklich etwas sehr einfach... hast Du da evtl. was Passendes auf Lager, was man an der Stelle einsetzen könnte?

---

Eigentlich habe ich in meinem Programm 64Bit-Arithmetik benutzt, um genau darüber nicht nachdenken zu müssen.

---

Och mööönsch

Gibts da evtl. einen Link zu dem Thema, den Du posten könntest? Ich hab da mal nach gesucht, aber was wirklich brauchbares mit lesbarem Code habe ich dazu nicht gefunden. Alles mögliche, sogar 128Bit-Operationen, aber nichts über "simple" 64Bit-Operationen.

Ok, mit den "Hauruck"-Operationen in meinem Programm kann man sich wohl behelfen, aber ich könnte mir gut vorstellen, daß es da noch wesentlich elegantere Methoden gibt?

Grüße

--
---

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

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Also UNIT_WAITECLOCK benutzen.

---

Die Schlussfolgerung hatte ich auch schon ;-)
Schließlich macht mein Programm oben (mit UNIT_WAITECLOCK) ja auch schon das richtige. Es weicht halt nur von der Echtzeit ab, messbar für das Programm nur in dem Fall, wenn der Emulator die Echtzeit-Uhr auch mitemuliert.
Ansonsten merkt das Programm selber davon nichts. Auf nem realen Amiga verhält es sich deshalb logischerweise etwas anders...
Jetzt werd ich mal Dein Programm ausprobieren.

---

Wie meinst Du das mit der Echtzeit-Uhr? GetSysTime() bzw. GETSYSTIME läuft ja im Grunde nur via EClock, die wird ja beim Start einmal auf den "aktuellen Stand" gebracht und läuft dann "allein" weiter, da tut sich zwischen Emulator und Amiga nicht viel (sofern der Emulator nicht an entscheidenden Stellen gebremst wird, was mir aber der Fall zu sein scheint. Manchmal weichen die Ergebnisse auf WinUAE wesentlich stärker ab als auf einem echten Amiga).

Abweichungen der GetSysTime()-Zeit wirst Du trotzdem bemerken, aber aufgrund der seltsam glatten Zahlen glaube ich, daß diese Abweichungen vom GetSysTime()-"Overhead" stammen (meine Vermutung geht eher da hin, daß GetSysTime() auf den nächste VBlank wartet, bevor der Zähler das nächste Mal ausgelesen wird).

Die Abweichungen treten übrigens stärker auf, je kleiner die Differenz wird (ich tippe auf zu hohe Last beim timer.device, so daß die GetSysTime()-Anfrage etwas zu spät "angenommen" wird). Es gibt aber einen Punkt, wo Du bei keinem Versuch mehr das "korrekte" Ergebnis bekommst, das ist der Punkt, wo die Systemzeit "abhaut" (bei mir inzwischen um die 12000Hz).

Ab und an scheint sich da auch noch was anderes bemerkbar zu machen, weil hin und wieder weniger Zeit angezeigt wird (im Rahmen bis -20000µs, ich tippe da auf einen Kontext-Switch zur unpassenden Zeit).

Bei geringeren Frequenzen überwiegt die Anzahl der "Treffer" bei weitem, aber auch dort kann man hin und wieder diese Abweichungen bei GetSysTime()beobachten.

Zu doof, daß ich keinen Sampler habe, sonst hätte ich das schon etwas genauer ausloten können, ob diese Abweichungen tatsächlich aus der Richtung stammen, wo ich sie vermute.

Man kann natürlich auch mal schauen, was die EClock dazu sagt (also die EClock-Unit als Referenz verwendet statt mit GetSysTime() zu messen).

Ach nochwas: Mein Überlauf-Test ist ja wirklich etwas sehr einfach... hast Du da evtl. was Passendes auf Lager, was man an der Stelle einsetzen könnte? Ich hatte nie viel mit 64Bit-Zahlen zu tun (wenn man mal von Fließkommazahlen absieht), daher keine großen Kenntnisse zu dem Thema.

Ein neckischer Trick, um auch mit vorzeichenbehafteten Zahlen korrekt umzugehen wäre etwas (auch wenn sowas in unserem Fall eher weniger von Verwendung ist, aber gebrauchen kann man sowas immer mal, denke ich)

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 17.09.2006 um 13:52 Uhr geändert. ]

Zitat:

---

Original von Holger:
@whose:
Nur eine Frage, so beim Überfliegen:
Wieso hält sich eigentlich hartnäckig die Verwendung der AOS1.x Supportlib-Funktionen, wo es seit AOS2.0 die Funktionen CreateMsgPort() und CreateIORequest() gibt?
Ich mein, bei einem Programm, das mit #ifdef __amigaos4__ anfängt, erscheint mir das irgendwie unangemessen.

Ist zwar hier nicht wichtig, scheint aber irgendwie in die Gewohnheiten- Richtung zu gehen, mir fällt das irgendwie immer wieder hier auf.

---

Upps, ja da hast Du Recht. Ich sag ja, das war auf die Schnelle zusammengestrickt und CreateExtIO() ist tatsächlich eine blöde Angewohnheit. Das #ifdef __amigaos4__ stammt von Cubic und ich habs dringelassen, für den Fall, daß das jemand auf so einer Maschine mal testen mag.

Ich versuche, mir CreateExtIO() & Co. abzugewöhnen

Grüße

--
---

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

C code:

---

/* -----------------------------------------------------------------------------

  Testprogramm für die Funktion der UNIT_WAITECLOCK des timer.device
  
*/

#ifdef __amigaos4__
 #define __USE_INLINE__
#endif

#include <stdio.h>

#include <exec/exec.h>
#include <exec/ports.h>
#include <exec/libraries.h>
#include <dos/dos.h>
#include <devices/timer.h>

#include <proto/dos.h>
#include <proto/exec.h>


struct timerequest *TimerIO;
struct MsgPort *TimerMP;
struct Message *TimerMsg;

struct Library *TimerBase;

int main(void)
{
    struct timeval ref1, ref2;
    struct EClockVal eclockval;
    unsigned long intervall, ticks;
    long diff;
    LONG error;

    unsigned int repeat = 0;

    TimerMP = (struct MsgPort *)CreatePort(NULL, 0);
    if(!TimerMP)
    {
        printf("Konnte Timer-Port nicht anlegen!n");
        exit(RETURN_FAIL);
    }

    TimerIO = (struct timerequest *)CreateExtIO(TimerMP, sizeof(struct timerequest));
    if(!TimerIO)
    {
        printf("Konnte Timer-IORequest nicht anlegen!n");
        exit(RETURN_FAIL);
    }

    error = OpenDevice(TIMERNAME, UNIT_WAITECLOCK, (struct IORequest *)TimerIO, 0L);
    if(error)
    {
        printf("Konnte timer.device nicht öffnen!n");
        exit(RETURN_FAIL);
    }
    
    TimerBase = (struct Library *)TimerIO->tr_node.io_Device;

    printf("Gewünschtes Intervall in Hz: ");
    scanf("%lu", &intervall);

    ticks = ReadEClock(&eclockval);
    diff = ticks / intervall; /* Normal müßte man auf - testen */

    printf("Hi: %lu Lo: %lun", eclockval.ev_hi, eclockval.ev_lo);

    /* sehr simpler Überlauf-Test */
    if( ((eclockval.ev_lo) + diff) < eclockval.ev_lo)
    {
        eclockval.ev_hi++;
    }
    else
    {
        eclockval.ev_lo += diff;
    }

    //printf("New Hi: %lu New Lo: %lun", eclockval.ev_hi, eclockval.ev_lo);

    TimerIO->tr_node.io_Command = TR_ADDREQUEST;
    TimerIO->tr_time.tv_secs = eclockval.ev_hi;
    TimerIO->tr_time.tv_micro = eclockval.ev_lo;

    SendIO((struct IORequest *)TimerIO);

    GetSysTime(&ref1);

    while(repeat < intervall)
    {
        TimerMsg = WaitPort(TimerMP);
        
        /* Vorsicht, wilde Überläufe ;) */
        if( ((eclockval.ev_lo) + diff) < eclockval.ev_lo)
        {
            eclockval.ev_hi++;
        }
        else
        {
            eclockval.ev_lo += diff;
        }
        TimerIO->tr_node.io_Command = TR_ADDREQUEST;
        TimerIO->tr_time.tv_secs = eclockval.ev_hi;
        TimerIO->tr_time.tv_micro = eclockval.ev_lo;
        SendIO((struct IORequest *)TimerIO);
        /* hier was sinnvolles tun, sofern vorhanden */
        
        repeat++;
    }    

    GetSysTime(&ref2);

    AbortIO((struct IORequest *)TimerIO);
    WaitIO((struct IORequest *)TimerIO);    

    CloseDevice((struct IORequest *)TimerIO);
    DeleteExtIO((struct IORequest *)TimerIO);
    DeletePort(TimerMP);

    printf("n");
    printf("Intervall(EClock-ticks): %ldn", ticks / intervall);
    printf("Referenz 1: %ld %ldn", ref1.tv_secs, ref1.tv_micro);
    printf("Referenz 2: %ld %ldn", ref2.tv_secs, ref2.tv_micro);
    SubTime(&ref2, &ref1);
    printf("Differenz:  %9ld %ldn", ref2.tv_secs, ref2.tv_micro);
    
    exit(RETURN_OK);
}

---

Grüße

--
---

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


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


[ Dieser Beitrag wurde von whose am 17.09.2006 um 02:48 Uhr geändert. ]

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

Zitat:

---

Original von Beeblebrox:
@whose:
Danke, habe es mit dem Beispiel hingekriegt. Kannte die Beispiele noch nicht. Trotzdem finde ich es echt kompliziert die AmigaOS-Api zu programmieren.

---

Nein, ist nicht wirklich kompliziert, unterscheidet sich nur von dem, was man aus der Windows-/Linux-Welt so kennt.

Eine kleine Faustregel: Bei Gadgets, die eine Auswahl anbieten, wird fast immer mit Exec-Lists (doppelt verkettet) gearbeitet, um die Auswahl "einzuklinken" und ein evtl. auftretendes Ergebnis "auszulesen". ListView, Page, Chooser etc. zählen zu dieser Spezies.

Weitere Faustregel: Sobald man vorhat, etwas an so einer Liste zu ändern, sollte (muss) diese Liste erst einmal aus dem Gadget "ausgeklinkt", danach bearbeitet und dann wieder "eingeklinkt" werden.

Probier einfach mal ein wenig mit unterschiedlichen Gadgets rum, irgendwann gibts das "Aha!"-Erlebnis und auch Dir kommt ReAction/MUI/BOOPSI dann einfach vor.

Grüße

--
---

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

Zitat:

---

Original von Holger:

Eine Variable da zu deklarieren, wo sie gebraucht wird, statt irgendwo am Anfang von irgendetwas, ist das normalste von der Welt. So halten es C++, C99, Java und noch diverse andere Programmiersprachen, die nicht in den Denkmustern aus den 80ern, bzw. man müsste ja bei C eher 70ern stehengeblieben sind.

---

Zitat:

---

Zitat:

---

Lieber Holger, UNIT_WAITUNTIL ist sogar nur mit UNIT_VBLANK vergleichbar, was die Genauigkeit angeht.

Da wundert es nicht, wenn das bei 125µs aus dem Ruder läuft. Allerdings hättest Du als Kenner der Materie das eigentlich wissen müssen

---

Ja, ich hatte das Programm mehrfach umgestellt, von µHZ auf EClock, Wait... und zurück. Da habe ich wohl vor lauter "the same as" in den Autodocs die Falle übersehen. Ja ja, die Leute bei Commodore wussten halt, was Spass macht.

---

Komisch... ich habe das auf Anhieb gefunden und sofort gesehen, welche Unit mit welcher Granularität arbeitet. Steht direkt bei den Beschreibungen zu den Units im RKM. Auch in den Autodocs ist das recht klar ersichtlich, finde ich.

Nun ja, also bauen wir (bzw. ich) das Ganze mal für den Anfang mit UNIT_MICROHZ, später dann in einer Fassung mit UNIT_WAITECLOCK.

Und ich wette, daß das problemlos (mit Abweichungen +- 3-4µs) funktioniert.

Grüße

--
---

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

Zitat:

---

Original von Mad_Dog:

Zitat:

---

Original von MaikG:

Getsystime
sind 125 sekunden Vergangen?

---

Bleibt die Frage zu klären was in folgendem Fall passiert:

1. Hole die aktuelle Systemzeit - nennen wir diesen Zeitpunkt t_0
2. Berechne Zeitpunkt t_0 + gewünschte Wartezeit - nennen wir diesen Zeitpunkt t_1
3. Mach irgendwas (z.B. Parrallelport auslesen, Berechnungen anstellen...)
4. Warte bis zum Zeitpunkt t_1

Wenn in 4. der Zeitpunkt t_1 bereits überschritten ist, müsste AFAIK eine dieser "Warte Bis" Funktionen des timer.device das Warten trotzdem beenden, da dieser Zeitpunkt t_1 ja nie mehr erreicht werden kann, weil schon vorbei...

---

Das tun sie auch. UNIT_WAITUNTIL gibt allerdings erst mit dem nächsten VBLANK Laut, was in den meisten Fällen viel zu spät sein dürfte. Daher kommt auch die Annahme, daß die Timer viel zu langsam laufen würden.

Maik arbeitet nun aber mit reinem Polling, wenn ich das recht verstanden habe, das ist naturgemäß etwas schwieriger zu handhaben.

Grüße

--
---

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

Zitat:

---

Original von CarstenS:
@whose:
> Und Hyperion hat sich demnach also verpflichtet, Hardware zu liefern?

Nein, sie haben versprochen, ein Desktop-Betriebssystem für PowerUp und weitere Hardware auf den Markt zu bringen.

---

Nun ja, ersteres haben sie nahezu erfüllt, zweiteres scheint (wenn man den Italienern da etwas vertraut) in Arbeit zu sein.

Wo ist nun das Problem bzw. die "Schuld" von Hyperion?

Ich sehe Bill & Flee (genial ) immer noch als das Hauptproblem in der ganzen Sache.

Grüße


--
---

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

Zitat:

---

Original von CarstenS:
@DariusBrewka:
[...]
> Und was hat das mit Hyperion zu tun?

Darius, das alles habe ich in den letzten Tagen mehr als zur Genüge erläutert (Stichwort Vertagsunterzeichnung). Und Eyetech würde mit Sicherheit noch Boards anbieten, wenn sie dies mit einem kleinen Gewinn könnten. Ganz offensichtlich können sie das aber nicht. Eyetech würde dann eine Schuld treffen, wenn sie sich verpflichtet(!) hätten, (ständig) Boards verfügbar zu machen. Von einer solchen Klausel ist aber nichts bekannt, und ich halte deren Existenz auch für ziemlich unwahrscheinlich, denn als so blöd schätze ich Alan Redhouse nicht ein.

---

Aha? Und Hyperion hat sich demnach also verpflichtet, Hardware zu liefern? Hä?

Grüße

--
---

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

Zitat:

---

Original von Reth:

Zitat:

---

Original von whose:
Von meiner Warte aus kein Problem... ich sehe halt nur das Problem der Zeit dabei. Ich habe wenig, Holger und Thomas sicherlich auch. Dann ist da noch das Durchhaltevermögen... leider auch nicht gerade bedeutungslos und oftmals ein Problem

Grüße

---

Zeit spielt keine Rolle! Ich arbeite an meinem "Projekt" ja auch nur, wenn Lust und Zeit es zulassen!

Aber bei eurer geballten Power sollte das doch programmiertechnisch in wenigen Monaten gelöst sein, auch wenn man nur freizeitlich daran sitzt!

---

Naja, stell Dir das nicht so einfach vor... ich weiß nicht, wie weit sich z.B. Holger mit dem Thema "Sprites" beschäftigt hat. Es gibt doch noch eine Menge auszuprobieren, bevor man sich an sowas mit "aller Kraft" dransetzen kann. Sowas kostet einiges an Zeit und Geduld.

Wie gesagt, von meiner Warte aus sehe ich da keine Sachen, die großartig hemmen könnten. Nur ganz allein packe ich das nicht in meiner Freizeit, dafür ist das doch etwas viel Arbeit.

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 13.09.2006 um 00:13 Uhr geändert. ]

Zitat:

---

Original von Reth:

Aber mal im Ernst!
Son Amiga-Programmiercrack wie Du oder Thomas oder whose können doch mal aufhören irgendwelche Sachen auszuprobieren, nützliche Beispiele zu programmieren, usw. und ihr Können in so nem Projekt zusammenlegen!



Oder wie oder was?

[ Dieser Beitrag wurde von Reth am 12.09.2006 um 23:28 Uhr geändert. ]

---

Von meiner Warte aus kein Problem... ich sehe halt nur das Problem der Zeit dabei. Ich habe wenig, Holger und Thomas sicherlich auch. Dann ist da noch das Durchhaltevermögen... leider auch nicht gerade bedeutungslos und oftmals ein Problem

Grüße

--
---

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

Zitat:

---

Original von Turrican:
@holger

du arbeitest alleine an einem amiga-browser!?!?! *RESPECT*
soll das teil auch CSS & javascript unterstützen?
wann wirds fertig? ;-)

---

"Two more weeks" (tm)

Grüße

--
---

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

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Ja, ich weiß. Und ich hab mit Deinem Programm die Variante "Wir treffen uns in 125µs ab jetzt zzgl. 50ms wegen printf()" ausprobiert und sie paßt. Immer. Mit einer maximalen Abweichung von +-2-4µs, je nach Last.

---

Das interessiert mich nicht die Bohne. Auf den Ansatz "ich definiere die Aufgabenstellung so lange um, bis das Programm mit ihr übereinstimmt", kann ich verzichten.

Die Aufgabe ist seit fast 100 Posting klar umrissen, ich habe sie etwas weiter oben noch mal extra für Dich zusammengefasst. 8000 Samples in einer Sekunde. Das war jetzt noch kürzer.

Bring ein Programm, das zeigt, dass man diese Aufgabe mit dem timer.device lösen kann, als Bonus noch auf eine für Menschen verständliche Art und Weise, aber das muss nicht, und dann sind wir alle glücklich.

Oder hör auf zu labern.

---

Verdammt nochmal, jetzt langts mir aber mit Deinem Großkotz-Gehabe!

Die 125µs sind mir bekannt und ich habe keine Aufgabenstellung umdefiniert, als ich die Tests gemacht habe. Mir ist dabei nur aufgefallen, daß es dabei so gut wie keine Drift gibt, wenn ich das Intervall periodisch gegen die Systemzeit abgleiche. Sogar ohne printf(), nur mit einer "leeren" Schleife!

Ist das jetzt klar??

Und ausgerechnet Du mußt mit "...auf eine für Menschen verständliche Art und Weise" kommen, mit einem Testprogramm, das übelst zusammengehackt ist und vor allem auf Anhieb abstürzt auf einem normalen Amiga, noch dazu mit Deklarationen und Definitionen "wie es uns gefällt", irgendwo mitten im Text.

Mir ist es Latte, ob das von C99 nun zugelassen wird oder nicht, ich finds zum Weinen und gnadenlos unleserlich.

Lies die RKMs, verstehe, was darin steht und dann schreib ein dazu passendes Programm. Oder halt einfach die Finger still, wenn jemand was in die Runde bringt, was Du nicht ausprobiert hast und was Dir einfach nur gegen Deine "innere Überzeugung" geht, aber möglicherweise die Lösung des Ganzen ist.

Manchmal benimmst Du Dich echt zum Kotzen.

Für heute langts mir erst einmal. Ein Programm mit funktionierendem Timing folgt die Tage.

--
---

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


[ Dieser Beitrag wurde von whose am 12.09.2006 um 23:32 Uhr geändert. ]

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Nun ja, wenn Du meinst... also laufen alle Programme, die das timer.device mit UNIT_MICROHZ benutzen und kleinere Zeiträume damit abmessen alle falsch. Ist in Ordnung, so notiert und werde ich mir merken.

Was wohl die OS-Entwickler dazu sagen?

---

Wieso fragst Du? Hast Du nicht eben behauptet, dass sie es im RKRM als "richtig" umdefiniert haben?

Oder meinst Du die jetzigen?

---

Zitat:

---

Ansonsten ist alles gesagt. Du hast die Einladung, den richtigen code zu posten, also unter der Maßgabe, das die beiden bisherigen Anwendungen/Ansätze falsch waren.

---

Danke.

Grüße

--
---

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

Zitat:

---

Original von Holger:

Das Problem ist, dass wir keine Sekunden warten wollen, sondern 1/8000 Sekunden. Und dass das timer.device bereits da versagt, weil es anscheinend, bleiben wir bei der Darstellung, über 10 ms für "die Fahrt zum Treffpunkt" braucht.

---

Zitat:

---

Wen interessiert da noch die Drift, die nach dem langen Zeitraum von 1 s auftritt? Ich habe die Ergebnisse nur erst nach einer Sekunde ausgegeben, um die Last gering zu halten. Ich hätte sie auch sofort ausgeben können.

---

Zitat:

---

Die Variante, "wir treffen uns nach 125µs" haben wir bereits zu Beginn ausprobiert.

---

Zitat:

---

Wenn das timer.device weder für kleine, noch für große Wartezeiten taugt, dann taugt es offenbar für gar nichts.

---

Zitat:

---

Allerdings funktioniert das Beispiel mit Wartezeiten von 1/2 Sekunde bis 1/10 Sekunde. Da spielt die Abweichung aufgrund der "großen Zeiten" keine Rolle.

---

Spielt sie auch so nicht, wenn Du das timer.device so einsetzt, wie es vorgesehen ist.

Würdest Du das Intervall immer fein auf die tatsächlich vergangene Zeit (inkl. diverser kleiner Abweichungen) abgleichen, gäbs da gar kein Problem.

Grüße

--
---

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

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
@Holger:
Tu mir einfach den Gefallen und kalibriere das Programm. Nimm die Latenzen raus, hol dir die Systemzeit bei jedem Durchlauf, rechne die Ungenauigkeit des Timers von ca. 2µs da raus und probiers nochmal.

---

Nein, das werde ich nicht tun. Denn das, um das Du bittest, läuft darauf hinaus, die Latenzen zu ignorieren (man kann den Overhead einer leeren Schleife nicht weiter reduzieren), und statt auf einen konkreten Zeitpunkt einfach 125µs (meinethalben abzügl 2µs) zu warten, ganz egal, wieviel reale Zeit bis dahin vergangen ist.

Dass das Abdriften muss, liegt bereits in der Natur der Sache. Und ist vor allem genau das, wie das Programm funktioniert hat, bevor es auf WAITUNTIL umgeschrieben wurde.

Wenn "warte auf 14:00 Uhr" beim timer.device bedeutet "warte auf irgendeinen Zeitpunkt, den Du Dir selbst ausgedacht hast" bedeutet, dann hat es keinen Sinn mehr, an dem Programm etwas zu ändern. Denn dann ist selbst (oder gerade) ein Poll-Loop sauberer, denn den kann man sauber kalibrieren, ohne noch auf einen zusätzliche, falsch laufende Entität Rücksicht nehmen zu müssen.

---

Nun ja, wenn Du meinst... also laufen alle Programme, die das timer.device mit UNIT_MICROHZ benutzen und kleinere Zeiträume damit abmessen alle falsch. Ist in Ordnung, so notiert und werde ich mir merken.

Was wohl die OS-Entwickler dazu sagen?

Grüße

--
---

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

Zitat:

---

Original von Holger:
Na ja, wenn das timer.device wirklich so funktioniert wie Deine Logik, dann kann man es wohl getrost in die Tonne treten.

---

Wenn Du verstehen würdest, wie genau WAITUNTIL funktioniert, dann hättest Du eventuell die selten dämlichen Vergleiche weggelassen.

Lies nochmal das RKM "Devices" und dann versuche zu verstehen, wie genau WAITUNTIL funktionieren könnte. Was Dein Programm gerne hätte und was UNIT_WAITUNTIL liefern kann, sind manchmal einfach zwei verschiedene Dinge (abhängig vom gewählten Intervall).

Das ist ungefähr so, als würden wir uns um 14:00 zum Kaff treffen wollen, ich brauche aber eine Stunde für die Fahrt und Du sagst es mir erst um 13:15.

Eventuell hätte ich es direkt technisch erklären sollen, nicht anhand Deines Programms.

UNIT_WAITUNTIL taugt, genausowenig wie UNIT_MICROHZ (auf der UNIT_WAITUNTIL basiert) nicht zum Messen größerer Zeiträume (dazu zählen bereits Sekunden). Ganz einfach. Steht auch so im RKM.

Wenn Du trotzdem über längere Zeiträume mit Deinem Programm synchron zur Systemzeit bleiben willst, kalibrier es und gleiche es mit der aktuellen Systemzeit ab. Auch ganz einfach. Und steht sogar auch im RKM, wenn auch etwas versteckt.

Nabend.

--
---

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