Zitat:

---

Original von Mad_Dog:

Zitat:

---

Original von whose:

testen kann ich das mangels Sampler leider nicht selbst

---

Naja... testen kannst Du's auch ohne Sampler - Du bekommst dann eben eine Flatline (Patient tot ).

---

Naja, aber nen toten Patienten kitzeln bringt irgendwie wenig Spaß

Ich werds auf jeden Fall mal laufen lassen und auch schauen, ob man da noch was dran verbessern kann. Für die Grafik-Geschwindigkeits-Frage wäre es aber schon besser, wenn ich einen Sampler zum Testen hätte *schnüff*

Hat vielleicht jemand der Mitlesenden einen über? Ein Billigheimer-Modell (von mir aus auch ein Mono-Sampler) würde es schon tun, für ernsthaftes Soundsampling habe ich eine Delfina bzw. Toccata bzw. µA1-onboard-Soundkarte.

Grüße

--
---

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


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

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von whose:
Inzwischen konnte ich mich näher mit dem Testprogramm beschäftigen. Die "Drift" zwischen Systemzeit und WAITUNTIL-Zeit ist ganz einfach zu erklären: Du hast vergessen, nach dem ersten Holen der Systemzeit target entsprechend in der while-Schleife zu setzen (auch in dem Teil, wo auf checkTime geprüft wird. Mach einfach die Bedingung immer wahr, dann siehst Du es).

Um die korrekte WAITUNTIL-Zeit zu bekommen, muß man sich vorher mittels TR_GETSYSTIME die aktuelle Systemzeit holen und dann erst die Differenz aufaddieren. Das fehlt in der while-Schleife, da addierst Du immer nur die Differenz auf die zu Beginn von main() gelesene SysTime, nicht auf die aktuelle. Daher driftet das auseinander, weil ja trotz allem immer ein wenig Zeit "verplempert" wird. Je länger das läuft, desto größer die "Drift" (die in Wirklichkeit gar keine ist).

---

Zitat:

---

Allein das end_timer() sorgt schon für kleinere Differenzen, der Goertzel für noch größere. Vor allem unterscheiden sich die Differenzen immer etwas, weil end_timer() nie ganz exakt gleich "wartet", bis der Request erledigt wurde.

---

Zitat:

---

Das erklärt übrigens auch, weshalb das auch ohne Goertzel und Textausgabe irgendwann einfach "durchrauscht". Die WAITUNTIL-Zeit ist ja, dank der "Drift" immer schon überschritten, wenn der Request gesendet wird. In der Folge kehrt das sofort zurück, statt 125µs zu warten.

---

Zitat:

---

2. braucht printf() (nicht Printf(), die läuft etwas schneller) auf meinem WinUAE-System ca. 20 tausendstel, um Text auszugeben. Das läßt sich dann prima ablesen. Sogar die Differenzen passen bis auf 2µs genau bei jedem Durchlauf.

---

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von whose:
@Holger:

Also, ich hab den GCC auf Standardeinstellungen laufen, der übersetzt das nicht. Wäre mir irgendwo auch neu, daß Definitionen/Deklarationen "irgendwo im Code" unterstützt würden. Aber seis drum.

---

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von whose:
Abgesehen davon hängt es sich auf dem WinUAE weg, nachdem der Timer gestartet wurde und das Signal eintrifft (im Storm-Debugger sieht man aber sehr gut, daß das Signal wie gewünscht noch eintrudelt und auch noch registriert wird).

---

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von whose:
@MaikG:

Zu dem BASIC-Code kann ich Dir relativ wenig sagen, weil ich MB nicht besitze. Eine Anmerkung habe ich aber:

code:

---

target&=PEEKL(tr& + tr_time%)

---

Das funktioniert nicht. target& muß eine timeval-Strukur sein, keine einfache 32-Bit-Zahl. Im C-Code funktioniert das, weil der C-Compiler Strukturen komplett kopieren kann. MB kann das nicht.

---

code:

---

target&=PEEKL(tr& + tr_time%)
AddTime& target&, offset&(0)

---

code:

---

DIM target&(2)
target&(0)=PEEKL(tr& + tr_time% + tv_secs%)
target&(1)=PEEKL(tr& + tr_time% + tv_micro%)
AddTime& VARPTR(target&(0)), VARPTR(offset&(0))

---

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Inzwischen konnte ich mich näher mit dem Testprogramm beschäftigen. Die "Drift" zwischen Systemzeit und WAITUNTIL-Zeit ist ganz einfach zu erklären: Du hast vergessen, nach dem ersten Holen der Systemzeit target entsprechend in der while-Schleife zu setzen (auch in dem Teil, wo auf checkTime geprüft wird. Mach einfach die Bedingung immer wahr, dann siehst Du es).

Um die korrekte WAITUNTIL-Zeit zu bekommen, muß man sich vorher mittels TR_GETSYSTIME die aktuelle Systemzeit holen und dann erst die Differenz aufaddieren. Das fehlt in der while-Schleife, da addierst Du immer nur die Differenz auf die zu Beginn von main() gelesene SysTime, nicht auf die aktuelle. Daher driftet das auseinander, weil ja trotz allem immer ein wenig Zeit "verplempert" wird. Je länger das läuft, desto größer die "Drift" (die in Wirklichkeit gar keine ist).

---

Um Himmels Willen, das wäre ja exakt das Gegenteil von dem, was es tun soll. Wenn ich will, dass das Programm 8000 Mal wartet und danach exakt einen Sekunde vergangen sein soll, muss das timer.device auch auf die korrekte Zeit warten, wenn ich sage dass es Zeitpunkt zum Programmstart plus 8000 * 125 µs warten soll. Würde ich zu diesem Zeitpunkt die Systemzeit erneut holen, obwohl ich ja weiß, dass bis zur Ausführung von TR_GETSYSTIME schon wieder Zeit vergangen ist, dann wäre vollkommen klar, dass die Gesamtwartezeit größer als 125µs ist. Genau das will ich aber nicht. Wenn ich sage "warte bis zum letzten Meßzeitzeitpunkt plus 125µs", dann ist klar, dass zu diesem Zeitpunkt schon etwas Zeit vergangen ist und deshalb die eigentliche Wartezeit kleiner als 125µs sein wird. Aber genau das will ich ja, jetzt klar?

---

Zitat:

---

Zitat:

---

Allein das end_timer() sorgt schon für kleinere Differenzen, der Goertzel für noch größere. Vor allem unterscheiden sich die Differenzen immer etwas, weil end_timer() nie ganz exakt gleich "wartet", bis der Request erledigt wurde.

---

end_timer() warte auf das Erreichen eines Zeitpunkts, genau das ist der Sinn von WAIT_UNTIL. Bei größeren Intervallen funktioniert das auch. Natürlich ist die Systemzeit nach end_timer() etwas größer als die Zielzeit, und die Differenz schwankt. Aber sie bleibt in der gleichen Größenordung.

---

Zitat:

---

Zitat:

---

Das erklärt übrigens auch, weshalb das auch ohne Goertzel und Textausgabe irgendwann einfach "durchrauscht". Die WAITUNTIL-Zeit ist ja, dank der "Drift" immer schon überschritten, wenn der Request gesendet wird. In der Folge kehrt das sofort zurück, statt 125µs zu warten.

---

Und genau das nicht nicht verständlich. Auf meinem System brauchen Goertzelberechnung und Textausgabe zusammen weniger als 125µs, genauer gesagt, weniger als 50µs. Erst die Verwendung des timer.devices sorgt für diese Drift. Das heißt, der Overhead des timer.device scheint zu hoch zu sein.

---

Zitat:

---

Zitat:

---

2. braucht printf() (nicht Printf(), die läuft etwas schneller) auf meinem WinUAE-System ca. 20 tausendstel, um Text auszugeben. Das läßt sich dann prima ablesen. Sogar die Differenzen passen bis auf 2µs genau bei jedem Durchlauf.

---

Da ich ja nur zur vollen Sekunde eine Ausgabe mache (oder gar keine, wenn ich sie deaktiviere), ist das irrelevant.

---

Ganz und gar nicht. 20tausendstel sind einiges mehr als unsere Differenz hier. Mit einem printf() sind wir dann schon weiiiiiit hinter der Systemzeit zurück, wenn wir die Basis unserer WAITUNTIL-Zeit nicht aktualisieren. Bei keiner Ausgabe zählen natürlich nur die "übrigen" Verluste.

Grüße

--
---

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


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

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

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Abgesehen davon hängt es sich auf dem WinUAE weg, nachdem der Timer gestartet wurde und das Signal eintrifft (im Storm-Debugger sieht man aber sehr gut, daß das Signal wie gewünscht noch eintrudelt und auch noch registriert wird).

---

Was hängt sich weg, und was für ein Signal meinst Du?
Ctrl+C?
Dann hast Du bestimmt diese Clipboard-Tool zu laufen. Das hat das "tolle" Feature, dass Ctrl+C als "Copy" abgefangen wird. Wenn Du aus 'ner andern Shell mittel break das Ctrl+C schickst, bricht es problemlos ab.

Oder Du meinst irgendetwas anderes?

---

Nein, ich meinte einen Absturz. Was es genau war, darfst Du mich nicht fragen, ich hab n paar kleine Umbauten gemacht, weiß aber nicht mehr, was ich da genau geändert habe. Aber es läuft ja nun.

Grüße

--
---

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

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von whose:
Angenommen, pro Durchlauf gehen Dir (seit dem Initialmeßzeitpunkt) genau 5 µs für "andere Aufgaben" flöten (schließlich schaffst Du es nie, den neuen Request sofort nach Erhalt des Signals auf den Weg zu bringen).

---

Zitat:

---

Nicht der Timer ist zu langsam, Dein Programm ist es.
Jetzt klar?

---

Zitat:

---

Nein, bleibt sie nicht. Da können durchaus mehr als 2µs Differenz bei herumkommen, besonders auf WinUAE-Systemen im Fenstermodus. Meß das einfach mal.

---

Zitat:

---

Nein. Mit den Ausführungen oben hast Du schon die Erklärung. Wenn der Goertzel vor dem Senden des neuen Requests ausgeführt wird, fehlen von den 125µs Differenz im Vergleich zur bereits weitergelaufenen SysTime schon 50µs.

---

[ - Answer - Quote - Direct link - ]

C code:

---

#include <proto/dos.h>
#include <proto/exec.h>
#define __NOLIBBASE__
#define TimerBase (tr->tr_node.io_Device)
#include <proto/timer.h>
#include <devices/timer.h>

struct timerequest *open_timer(long unit)
{
  struct MsgPort *port;
  struct timerequest *req;

  if(port = CreateMsgPort())
  {
    if(req=(struct timerequest*)CreateIORequest(port,sizeof(struct timerequest)))
    {
      if(0 == OpenDevice("timer.device", unit, (struct IORequest*)req, 0))
        return req;
      DeleteIORequest((struct IORequest*)req);
    }
    DeleteMsgPort(port);
  }
  return NULL;
}
void close_timer(struct timerequest *req)
{
  struct MsgPort *port;

  if (req)
  {
    CloseDevice((struct IORequest *)req);
    port = req->tr_node.io_Message.mn_ReplyPort;
    DeleteIORequest((struct IORequest *)req);
    DeleteMsgPort(port);
  }
}

int main(int x, char**y)
{
  struct timerequest *tr=open_timer(UNIT_WAITUNTIL);
  struct timeval target, offset={0, 10000};
  int ticksPerSecond=1000000/offset.tv_micro, i;

  if(!tr) { PrintFault(IoErr(), "Couldn't open timer.device"); return 10; }
  tr->tr_node.io_Command=TR_GETSYSTIME;
  DoIO(&tr->tr_node);
  target=tr->tr_time;
  tr->tr_node.io_Command = TR_ADDREQUEST;
  for(i=0; i<ticksPerSecond&&!(SetSignal(0L,0L)&SIGBREAKF_CTRL_C); i++)
  {
    AddTime(&target, &offset);
    tr->tr_time=target;
    DoIO((struct IORequest *)tr);
  }
  tr->tr_node.io_Command=TR_GETSYSTIME;
  DoIO(&tr->tr_node);
  VPrintf("processed %ld requestsn", (ULONG*)&i);
  VPrintf("target time { %ld, %ld }n", (ULONG*)&target);
  VPrintf("sys time { %ld, %ld }n", (ULONG*)&tr->tr_time);
  close_timer(tr);
  return 0;
}

---

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

@MaikG:

Meinst Du den "Überlauf" bei 999999 micro?

Grüße

--
---

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

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von whose:
Es ist eben nicht unwichtig, wann Du eine Differenz als Wartezeit ab einem fixen Zeitpunkt nach Systemzeit angibst, verdammt nochmal!

---

Zitat:

---

Du gibst doch einen fixen Zeitraum von 125µs ab Zeitpunkt x an mit jedem Durchlauf.

---

Zitat:

---

Die Klamotten laufen parallel (Systemzeit und Deine WAITUNTIL-Berechnung, die auf der Systemzeit zu einem Zeitpunkt basiert), aber Dein Programm "verbraucht" immer ein paar µs. Wenn Du es nicht regelmäßig "kalibrierst", läuft Dir irgendwann die Systemzeit weg.

---

Zitat:

---

Nochmal, WAITUNTIL wartet bis zu einem sehr spezifischen Zeitpunkt im Vergleich zur laufenden Systemzeit. Ist die Systemzeit erreicht, die Du mit Deinem Request vorgegeben hast, gibts das Signal. Bist Du zu langsam bei der Berechnung dieser Vorgabe (was Du immer bist, mal mehr, mal weniger), läuft das nicht lange synchron. Je kürzer das Intervall, je kürzer der Zeitraum, in dem das noch ziemlich synchron läuft.

---

[ - Answer - Quote - Direct link - ]

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

[ - Answer - Quote - Direct link - ]

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.

---

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von whose:
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.

---

Zitat:

---

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.

---

[ - Answer - Quote - Direct link - ]

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

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von whose:
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.

---

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

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?

---

[ - Answer - Quote - Direct link - ]

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

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von MaikG:
Ja, hab das inzwischen so gemacht:
[...]

---

Zitat:

---

Also Zeit holen, Programm, gucken ob 125 mics vergangen sind, wenn
ja nächste wenn nicht zu 2.
Aber das geht genauso bescheiden wie die andere Methode,
schlecher sogar braucht auf 20 Sekunden 8 Sekunden zu lange(ohne
goertzel)

---

[ - Answer - Quote - Direct link - ]

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

[ - Answer - Quote - Direct link - ]

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.

---

[ - Answer - Quote - Direct link - ]

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. ]

[ - Answer - Quote - Direct link - ]

Ach Gottchen, nun konnte ich, endlich daheim, mal einen Blick ins RKM werfen und es ist alles noch viel Schlimmer:

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

Nimm UNIT_WAITECLOCK, dann siehts besser aus.

Grüße

--
---

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

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]

Zitat:

---

Original von Holger:
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.

---

[ - Answer - Quote - Direct link - ]

@Mad_Dog:

Wie oben schon erwähnt, die Diskussion ist brotlos, solange man von falschen Annahmen über das Auflösungsvermögen der gewählten timer.device-Unit ausgeht.

UNIT_WAITUNTIL hat im günstigsten Fall eine Samplerate von 60Hz (VBlank bei NTSC), das bedeutet, daß das Signal frühestens mit dem nächsten VBlank nach Absenden des Requests kommt, was natürlich fast immer viel zu langsam ist bei einem gewünschten Zeitraum von 125µs. Durch Zufall kann das eine oder andere Signal passend kommen, das wars dann aber auch.

UNIT_WAITECLOCK bietet die passende Auflösung, UNIT_MICROHZ auch. Wenn dann noch die Warte-Mechanik des Programms paßt, dann funktioniert das.

Ich muß mir doch mal die DevCD auf den Laptop werfen, glaube ich...

Grüße

--
---

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

[ - Answer - Quote - Direct link - ]

[ - Answer - Quote - Direct link - ]