code:

---

FOR runs%=0 TO 50 REM 50 sekunden

 ticks&=ReadEClock&(VARPTR(myEClockVal&(0)))
 diff&=ticks&/Intervall%

 newLow&=myEClockVal&(1) + diff&
 IF newLow& >= 0 AND myEClockVal&(1) < 0 THEN INCR myEClockVal&(0)
 myEClockVal&(1)=newLow&

 POKEW tr& + IORequestio_Command%, TR_ADDREQUEST&
 POKEL tr& + tr_time%+tv_secs%, myEClockVal&(0)
 POKEL tr& + tr_time%+tv_micro%, myEClockVal&(1)
 SendIO&(tr&)


 WHILE repeat1%<10001 REM 8001 184 92 Samples
        newLow&=myEClockVal&(1) + diff&
        IF newLow& >= 0 AND myEClockVal&(1) < 0 THEN INCR myEClockVal&(0)
        myEClockVal&(1)=newLow&
        junk&=WaitIO&(tr&)
        POKEW tr& + IORequestio_Command%, TR_ADDREQUEST&
        POKEL tr& + tr_time% +tv_secs%,  myEClockVal&(0)
        POKEL tr& + tr_time% +tv_micro%, myEClockVal&(1)
        SendIO&(tr&)
        POKEB MySample&+repeat1%, PEEKB(&hBFE101)-128
        INCR repeat1%
 WEND

IF outst% THEN repeat1%=0:outst%=0:junk&= WaitIO(aio&(1)) ELSE repeat1%=0  REM überschreibt zwar währen spielen geht aber
PlaySample MySample&, 10000, 1, 63 REM 8000

NEXT runs%

IF outst% THEN junk&= WaitIO(aio&(1)):outst%=0

---

code:

---

POKEW tr& + IORequestio_Command%, TR_ADDREQUEST&
       POKEL tr& + tr_time% + tv_secs%, 0&
       POKEL tr& + tr_time% + tv_micro%, 43& REM 125=8000Hz  34=7.65 38=7.63 40/42=8.0 43=10.067 44=12.65

       SendIO&(tr&)
       INCR mycount%:IF mycount%=8000 THEN mycount%=0:INCR myseconds%
        
       junk& = WaitIO&(tr&)

---

[ - Antworten - Zitieren - Direktlink - ]

@MaikG:

Hm, hatte ich das damals nicht mehr erwähnt? Die "zufälligen" Ergebnisse kommen wohl dadurch zustande, daß Du in Deinem Programm nicht schnell genug auf die Message des timer.device reagierst (bzw. reagieren kannst).

Um da ein recht zuverlässiges Timing hinzubekommen (wenn Du es ganz genau haben wolltest, müßtest Du sogar mit Interrupts arbeiten), mußt Du quasi "sofort" den nächsten Request losschicken, wenn Du die Message bekommen hast, daß der vorige Request "erledigt" ist.

Wenn Du "zu viel" Zeit brauchst, kann Dir ein anderer Task "dazwischenpfuschen" und das Absenden des nächsten Requests verzögern. Diese Verzögerung ist (aus naheliegenden Gründen) natürlich nicht vorausberechenbar, der "bremsende" Task kann z.B. eine weit höhere Priorität als Deiner haben und gerade eine Menge CPU-Last verursachen, IO-Operationen in diesem Moment starten usw. usf.

Dazu kommt, daß auch das "Aufwachen", ausgelöst durch die Message vom timer.device, nicht immer in exakt der gleichen Zeit abläuft (aus den oben schon genannten Gründen, denn wenn Dein Programm noch nicht "an der Reihe ist", wirds auch nicht aufgeweckt sondern bekommt die Message etwas später bzw. wird etwas später aktiv. Dieses "etwas später" hängt natürlich auch wieder von vielen Faktoren ab, die man schlecht vorausberechnen kann). Eine gewisse (nicht feststehende) Latenzzeit ist also immer dabei.

Da ich Dich eigentlich als "och, das probieren wir einfach mal"-Entwickler kenne, dachte ich, daß Du schon mit Task-Prioritäten rumexperimentiert hättest. Spätestens da wäre es Dir aufgefallen, daß diese "zufällige" Timing-Geschichte u.A. mit der Taskpriorität Deines Programms zu tun hat.

Also, 100%-Timing wirst Du so nicht hinbekommen, aber recht nahe ans Ideal kommt man schon (für Audio in nicht allzu hoher Qualität reicht es).

Dazu solltest Du Dir Berechnungen jeder Art zwischen Empfang der Message und Senden des nächsten Requests sparen, die Priorität Deines Tasks erhöhen und vor allem möglichst wenig andere Sachen, die ordentlich CPU-Last erzeugen können, nebenbei laufen lassen.

Oder Dich in das Thema "Timer-Interrupts mit AmigaOS" einlesen.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:

Wenn Du "zu viel" Zeit brauchst, kann Dir ein anderer Task "dazwischenpfuschen" und das Absenden des nächsten Requests verzögern. Diese Verzögerung ist (aus naheliegenden Gründen) natürlich nicht vorausberechenbar, der "bremsende" Task kann z.B. eine weit höhere Priorität als Deiner haben und gerade eine Menge CPU-Last verursachen, IO-Operationen in diesem Moment starten usw. usf.

---

Wenn's nur darum gehen sollte, dann kann er ja für die Zeit des Einlesens eines Zeitfensters das Multitasking abschalten (forbit und permit, böse, böse ). Dann ist sicher, dass Dir da kein anderer Task Dein Timing versaut.

Aber ich glaube, in dem Thread vor einem Jahr war das Problem, dass die Periodendauer der Abtastung nicht konstant war. So erklärt sich auch der "ausgelutschte-Musikkassetten-Effekt".

Nochmal für Mike: Du musst dafür sorgen, dass der zeitliche Abstand, in dem Du "hinschaust" (d.h. Dir den Wert vom Sampler holst), (bis auf vernachlässigbare Fluktuationen) konstant ist. Dann klappt das auch ohne "Leier-Effekt".

--
http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

@Mad_Dog:

Genau das meinte ich ja damit... wenn er die Abtasterei nicht innerhalb des "Zeitfensters" halten kann, kommt er in Schwulitäten. Der Leiereffekt kommt dadurch genauso zustande wie das scheinbar ungenaue Timing-Verhalten (das Problem in dem Thread damals, was wir dann ja zu einem großen Teil "beheben" konnten).

Das timer.device benutzt er ja, um in einem konstanten zeitlichen Abstand "hinzuschauen", aber er muß es flott "bedienen" und mögliche Störungen durch andere Tasks minimieren, damit das nicht aus dem Zeitfenster "rausrennt".

Stell Dir ein Zeitdiagramm mit senkrechten Flanken vor, die Plateaus geben an, wie viel Zeit ihm bleibt, um einen Wert ans audio.device weiterzureichen (das ist die Zeit, die bis zum Eintreffen der nächsten Message vergeht). Kann er diese Zeiten nicht halten (zum Beispiel weil er zu viel Zeit bei der Bearbeitung der gewonnenen Daten braucht, Stichwort Goertzel), gerät der Takt durcheinander. Er kommt quasi zu spät zum Wait().

Genauso, wenn die "Täler" nicht gehalten werden (welche die verfügbare Zeit zwischen Message-Empfang, Auslesen des aktuellen Wertes und Absenden des nächsten IORequests darstellen, und sie sind erheblich kürzer als die Plateaus. Streng genommen dürfte dort überhaupt gar keine Zeit "verbraten" werden, aber das geht nun mal nicht, Abtasten braucht Zeit).

Hilft halt nichts, wenn z.B. zwischen Message-Empfang und neuem Request auch noch "zufällige" Pausen eingefügt werden. Kommen z.B. zwei größere Pausen nacheinander geht ihm ein Abtastzeitpunkt flöten und er liest ein Datum weniger, als in die gewünschte Dauer hineingehört. Das passiert ein paar Mal und schon "leiert" es.

Es hat seinen Sinn, daß manche Steuerprogramme für Parallelport-Sampler das System für die Abtast-Dauer "einfrieren", 22,05KHz ist schon eine ziemlich frickelige Angelegenheit, was das Timing angeht

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

>Der Leiereffekt kommt dadurch genauso zustande wie das scheinbar
>ungenaue Timing-Verhalten (das Problem in dem Thread damals, was
>wir dann ja zu einem großen Teil "beheben" konnten).

Da gings um zu große abweichungen beim Timing. Ein Prog was
halbwegs was erkennt lief nur auf den 68060. Das halbwegs
wird dann auch vom leiern sein.


>Stell Dir ein Zeitdiagramm mit senkrechten Flanken vor, die Plateaus
>geben an, wie viel Zeit ihm bleibt, um einen Wert ans audio.device
>weiterzureichen

Es leiert auch wenn ich eine Sekunde Sample, 1 Sekunde wiedergebe und
dann wieder Sample. Also keine Audiowiedergabe während des Samplen.


>Es hat seinen Sinn, daß manche Steuerprogramme für
>Parallelport-Sampler das System für die Abtast-Dauer "einfrieren",
>22,05KHz ist schon eine ziemlich frickelige Angelegenheit, was das
>Timing angeht

22,05 Khz macht mein Sampler Problemlos in Stereo.
44 Khz in Mono.
Ich glaub das ging beim 68030er schon.

Über Interrupts hab ich nicht wirklich was gefunden, aber das
Programm Multimon(macht in etwa das selbe) setzt lt. Scout zumindest
kein Interrupt.

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:

Es hat seinen Sinn, daß manche Steuerprogramme für Parallelport-Sampler das System für die Abtast-Dauer "einfrieren", 22,05KHz ist schon eine ziemlich frickelige Angelegenheit, was das Timing angeht

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
>Der Leiereffekt kommt dadurch genauso zustande wie das scheinbar
>ungenaue Timing-Verhalten (das Problem in dem Thread damals, was
>wir dann ja zu einem großen Teil "beheben" konnten).

Da gings um zu große abweichungen beim Timing. Ein Prog was
halbwegs was erkennt lief nur auf den 68060. Das halbwegs
wird dann auch vom leiern sein.

---

Zitat:

---

>Stell Dir ein Zeitdiagramm mit senkrechten Flanken vor, die Plateaus
>geben an, wie viel Zeit ihm bleibt, um einen Wert ans audio.device
>weiterzureichen

Es leiert auch wenn ich eine Sekunde Sample, 1 Sekunde wiedergebe und
dann wieder Sample. Also keine Audiowiedergabe während des Samplen.

---

Zitat:

---

Über Interrupts hab ich nicht wirklich was gefunden, aber das
Programm Multimon(macht in etwa das selbe) setzt lt. Scout zumindest
kein Interrupt.

---

Gut, dann wissen wir noch mehr. Es geht also, auch ohne Tricksereien mit dem CIA. Da bleibt dann nicht mehr viel, MultiMon müßte demnach auch mit dem timer.device arbeiten und vor allem entweder mit der UNIT_ECLOCK oder UNIT_MICROHZ, den UNIT_VBLANK wäre für den Zweck nicht geeignet.

Am Sinn meiner Antwort ändert das jedenfalls nichts. Irgendwo hast Du eine Unregelmäßigkeit in Deinem Timing, die mußt Du finden.

Schau Dir doch nochmal den Thread von damals an, Mad_Dog hat, wenn ich mich recht erinnere, genau aus diesem Anlaß, ein kleines Sampler-Programm geschrieben. Das funktioniert recht gut und die Sourcen kannst Du Dir auch ansehen. Eventuell fällt Dir dann ein Unterschied zu Deinem Programm auf.

@Mad_Dog:

Ich habe nicht gesagt, daß das unmöglich wäre. Ich habe nur gesagt, daß es nicht trivial ist.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:

Schau Dir doch nochmal den Thread von damals an, Mad_Dog hat, wenn ich mich recht erinnere, genau aus diesem Anlaß, ein kleines Sampler-Programm geschrieben. Das funktioniert recht gut und die Sourcen kannst Du Dir auch ansehen.

---

Zitat:

---

@Mad_Dog:

Ich habe nicht gesagt, daß das unmöglich wäre. Ich habe nur gesagt, daß es nicht trivial ist.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
>Was darauf hinweist, daß Dein Timing (aus welchem Grund auch immer) unregelmäßig abläuft.

Sagte ich doch. Ich möchte sagen der Code ist von dir.

---

Zitat:

---

Übrigens wird bei Multimon - 18000 HZ eine CPU Last von ganzen
5% angezeigt.

---

Wo kann man dieses ominöse Multimon eigentlich herbekommen? Ich habe gestern schon mal danach gesucht, aber finde nichts dergleichen, nur Zeugs für Multi-Monitor-Betrieb.

Ich persönlich glaube nämlich nicht daran, daß es ohne den Timer-Interrupt des CIAs arbeitet. Übrigens, man kann seine eigene Interrupt-Behandlung in eine sog. Interrupt-Server-Chain einhängen, das wird also nicht unbedingt als richtiger Interrupt angezeigt und inwieweit Scout das anzeigt weiß ich auch nicht.

Maik, ich kann Dir immer noch nur folgenden guten Rat geben: Untersuch Dein Programm genau, erkläre nicht alle, die Dir nicht auf Anhieb helfen können für inkompetent und vor allem setz die Ratschläge doch einfach mal so um, wie sie Dir gegeben werden.

Dein BASIC-Programm von oben läuft jedenfalls nicht so, wie man es Dir angeraten hat, im Gegenteil. Und es ist auch nicht das, was man Dir in dem DTMF-Thread als Hinweis gegeben hat.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

C code:

---

// Ein Zeitfenster lesen.
void ReadFrame(struct Scope *sc)
{
   unsigned int t;

   /*  Hier werden die Werte gesammelt
    */
   for (t=0;t<sc->Size;t++)
   {
      sc->TimerIO->tr_node.io_Command = TR_ADDREQUEST;
      sc->TimerIO->tr_time.tv_secs = 0;
      sc->TimerIO->tr_time.tv_micro = sc->Period;

      READ_PAR(sc->Data[t]);  // Wert vom Parallelport kopieren

      SendIO((struct IORequest *)sc->TimerIO);
      WaitIO((struct IORequest *)sc->TimerIO);

   }
}

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Mad_Dog:
Ich habe mir nochmal meinen Code von damals angeschaut.

Zur Erinnerung poste ich hier nochmal die Stelle, wo ich die Daten für ein Zeitfenster einlese:

...

Wie man sieht, hole ich den Wert vom Parallelport (ja, böse - ich lese direkt aus dem CIA-Register), sende dann ein Timer-Request und warte dann, bis ich eine Antwort erhalte. Optional hätte ich das Auslesen des Wertes auch zwischen dem SendIO und WaitIO machen können, wenn ich davon ausgehe, dass das fix genug geht.

---

So hätte ich das auch gemacht. Was ich mich allerdings bei den Samplern frage ist folgendes: Geht die Wandlung da immer mit "Fullspeed" oder wie wird das gehandhabt? Ich stelle mir das eigentlich immer als getakteten Vorgang vor und was passiert dann, wenn man mit dem Auslesen des Werts "außerhalb" des Wandlertakts liegt?

Was mir noch an Maiks Code aufgefallen ist: Er benutzt immer noch UNIT_ECLOCK, obwohl man ihm damals schon gesagt hat, daß UNIT_MIKROHZ praktikabler ist (und nicht ungenauer).

@MaikG

Benutz doch bitte mal UNIT_MIKROHZ, wie Mad_Dog es hier zeigt. Und bitte spiel das Sample erst nach dem kompletten Sample-Vorgang ab, um das zu überprüfen. Ich wette, da leiert es auf einmal nicht mehr.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

C code:

---

/*  Scope
 *
 *  Oszilloskop erzeugen:
 *
 *  Eingabeparameter: ULONG f  - Die Samplingfrequenz
 *                    double t - Dauer des Samples in Sekunden
 *                    LONG p   - Pen Nummer zum Zeichnen
 *                    LONG b   - Pen Nummer für Hintergrund
 *  Rückgabe:         struct Scope* - Zeiger auf Scope Struktur
 *
 */
struct Scope *CreateScope(ULONG f,double t,LONG p, LONG b)
{
   struct Scope *sc;

   sc = (struct Scope *) AllocMem(sizeof(struct Scope),MEMF_CLEAR);

   sc->SamplingFreq = f;
   sc->Time = t;
   sc->Period = (int)1E6/f;
   sc->Size = (ULONG)(f*t);
   sc->Data = (UBYTE *)AllocMem(sc->Size,MEMF_CLEAR);
   sc->Pen = p;
   sc->Background = b;
   sc->TimerMP = CreateMsgPort();
   sc->TimerIO = (struct timerequest *) CreateIORequest(sc->TimerMP,sizeof(struct timerequest));

   return sc; 
}

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Was ich mich allerdings bei den Samplern frage ist folgendes: Geht die Wandlung da immer mit "Fullspeed" oder wie wird das gehandhabt? Ich stelle mir das eigentlich immer als getakteten Vorgang vor und was passiert dann, wenn man mit dem Auslesen des Werts "außerhalb" des Wandlertakts liegt?

---

[ - Antworten - Zitieren - Direktlink - ]

@Mad_Dog:

Danke für die Links. Das bestätigt nochmal, was ich mir bereits (trotz technischer Unwissenheit auf dem Gebiet) dachte. Man hat demnach (abhängig vom Typ des A/D-Wandlers) etwas Zeit, bevor der nächste Wert ansteht und der Wandel-Vorgang an sich läuft in einem bestimmten Takt ab.

Wenn man diesen Zeitrahmen überschreitet, der sich aus dem Wandlertakt ergibt, arbeitet man am Wandlertakt vorbei und verliert irgendwann zwangsläufig Werte bzw. liest Werte mehrfach. Ist das so korrekt gedacht?

Wenn ja, dann würde das bedeuten, daß man mit bestimmten Samplefrequenzen letzten Endes am "Leiern" gar nicht vorbeikommt, wenn der Samplevorgang zu lang angesetzt ist, da sich der Abtast-Takt und der Wandlertakt mit der Dauer des Samplevorgangs bei diesen Frequenzen auf jeden Fall gegeneinander verschieben und man im ungünstigen Fall mehrfach "alte" Werte liest oder mehrfach Werte "überspringt".

Eine Sample-Frequenz von z.B. 10000 wäre dann per se schon eine schlechte Idee, wenn der Wandler auf die "üblichen" Frequenzen von z.B. 22,05KHz getrimmt ist. Man kann dann nur geradzahlig gebrochene Frequenzen der maximalen Samplingfrequenz des Wandlers einigermaßen korrekt abtasten, also z.B. 11,02KHz oder 5,51. Die dazwischen liegenden Abtastfrequenzen wären dann nur "mehr oder weniger" brauchbar, je nach Verhältnis Samplefrequenz/Wandlerfrequenz und Dauer des Vorgangs.

Wenn ich hier jetzt falsch denken sollte, dann klärt das bitte auf. Wenn ich aber richtig denke, dürften wir dem "Fehler" schon um ein ganzes Stück nähergekommen sein.

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

code:

---

WHILE myseconds%<10
        POKEW tr& + IORequestio_Command%, TR_ADDREQUEST&
        POKEL tr& + tr_time% + tv_secs%, 0&
        POKEL tr& + tr_time% + tv_micro%, 44& REM 125=8000Hz
        SendIO&(tr&)
        INCR mycount%:IF mycount%=8000 THEN mycount%=0:INCR myseconds% REM 11.39   
        junk& = WaitIO&(tr&)
        REM INCR mycount%:IF mycount%=8000 THEN mycount%=0:INCR myseconds%    rem 11.41   11.46 mit DOIO
      WEND

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:

So, habs nochmal getestet:

code:

---

WHILE myseconds%<10
        POKEW tr& + IORequestio_Command%, TR_ADDREQUEST&
        POKEL tr& + tr_time% + tv_secs%, 0&
        POKEL tr& + tr_time% + tv_micro%, 44& REM 125=8000Hz
        SendIO&(tr&)
        INCR mycount%:IF mycount%=8000 THEN mycount%=0:INCR myseconds% REM 11.39   
        junk& = WaitIO&(tr&)
        REM INCR mycount%:IF mycount%=8000 THEN mycount%=0:INCR myseconds%    rem 11.41   11.46 mit DOIO
      WEND

---

Also keine großen berechnungen, nur die sekundenzählung.
Bei 10sek mit 44 micros, entweder 11.39 sek oder 11.41(siehe Position).
Wie erwähnt, sind aber 44 keine 8000 HZ sondern wesentlich mehr.
Bei 125 komme ich auf etwa 18 sekunden.
In dem Minicode kann ja kaum ein Fehler sein.

---

Naja, in dem Minicode an sich nicht. Ok, die 8000 ist etwas "daneben", weil man bei 44 auf irgendwas um die 22KHz kommen müßte.

Nur verstehe ich wirklich nicht, wieso das nur bei Dir wesentlich langsamer läuft. Der "Minicode" läuft bei mir (gemessen mit EClock) auf dein paar Mikrosekunden genau und man kann das Spielchen bequem bis zu einem Wert von 22 treiben (wahrscheinlich auch noch wesentlich weiter), ohne daß sich an der Genauigkeit etwas ändert.

Allerdings habe ich keine Ahnung, was MaxonBASIC (das verwendest Du doch?) daraus macht...

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:

Danke für die Links. Das bestätigt nochmal, was ich mir bereits (trotz technischer Unwissenheit auf dem Gebiet) dachte. Man hat demnach (abhängig vom Typ des A/D-Wandlers) etwas Zeit, bevor der nächste Wert ansteht und der Wandel-Vorgang an sich läuft in einem bestimmten Takt ab.

Wenn man diesen Zeitrahmen überschreitet, der sich aus dem Wandlertakt ergibt, arbeitet man am Wandlertakt vorbei und verliert irgendwann zwangsläufig Werte bzw. liest Werte mehrfach. Ist das so korrekt gedacht?

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
Der Wert wird vom Parport gelesen AND 80 genommen, später
direkt ins Audio Register(Byteweise) geschrieben.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
Kann auch was anderes sein, ich glaube ANDI oder so hiess der befehl.

---

Zitat:

---

Jedenfalls hats die aufgabe den Wert vom Sampler auf das Amiga
übliche Format(-127 bis +128) zu bringen. Also das vorzeichen
wird hinzugefügt.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von tboeckel:
@MaikG:

Für das sinnvolle "Vorausberechnen" der Zeit sollte man dann aber nicht UNIT_MICROHZ oder UNIT_ECLOCK, sondern UNIT_WAITUNITL oder UNIT_WAITECLOCK nehmen, je nachdem welche Zeitbasis einem besser gefällt. Die beiden Units warten nicht eine bestimmte Zeitspanne, sondern bis zu einem bestimmten Zeitpunkt.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Nur verstehe ich wirklich nicht, wieso das nur bei Dir wesentlich langsamer läuft. Der "Minicode" läuft bei mir (gemessen mit EClock) auf dein paar Mikrosekunden genau und man kann das Spielchen bequem bis zu einem Wert von 22 treiben (wahrscheinlich auch noch wesentlich weiter), ohne daß sich an der Genauigkeit etwas ändert.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]