Zitat:

---

Original von Maja:
@malte2:

Entschuldigung, das tät ich Beides lassen. Ich weiß, derlei Tipps liest mam viel im Internet. Meiner eigenen Erfahrung nach überlebt das aber kein Druckkopf wirklich lange. Da ist Jokis Tipp mit dem Isopropyl praxistauglicher.

---

Naja, das hängt vom Drucksystem ab. Bei dem Epson würde ich das auch lassen, der verwendet Permanent-Druckköpfe mit dem Unterdruck-System im Kopf, ebenso wie die meisten Canon-Drucker. Da kann selbst die Isopropyl-Geschichte in die Hose gehen, wenn man den Kopf zu voll kippt und Farbe in den Unterdruck-Kanal gerät und dort antrocknet.

Im schlimmsten Fall kann man den Drucker "entsorgen", bei den älteren Canons konnte man ja wenigstens noch die Druckköpfe tauschen (wenn auch recht teuer). Wie das bei den neueren aussieht, weiß ich nicht, seit dem BJC-Desaster (Drucker streikt nach soundsoviel abgeschossenen Tropfen elektronisch und ließ sich nicht mehr zurücksetzen) habe ich nur noch Epson-Drucker für Farbe.

Bei HPs mit in der Patrone integriertem Druckkopf ist das problemlos machbar und die Druckköpfe überleben das auch bestens (Lexmark verwendet das gleiche System bei den Consumer-Druckern). Ich habe hier Patronen für den Deskjet 500 (3 Stück), die ich seit der Anschaffung des Druckers (1989) ständig neu befülle und reinige (mit der Warmwasser-Methode oder auch schon mal mit Isopropyl, wenn der Drucker zu lange nichts zu tun hatte ).

Bis auf den altersbedingten Verschleiß (die Düsen "fransen aus" mit der Zeit) tun diese Patronen ihren Dienst bestens. Es fehlt kein Druckpunkt und der Druck ist, trotz der "ausgefransten" Düsen, immer noch erstaunlich sauber (auf gutem Papier).

Im Groben kann man sagen: Bei Permanent-Druckköpfen besser die Finger rauslassen und nur die Drucker-Reinigungsfunktion nutzen, bei Druckkopf-/Patrone-Kombi macht man im schlimmsten Fall die Patrone kaputt und muß ne neue kaufen.

In den allermeisten Fällen lassen sich eingetrocknete Druckkopf-/Patrone-Kombis aber wieder flott machen. Und Warmwasser schadet da nicht (also wirklich nur warm, nicht die Dinger kochen oder so ).

Ich kann mir auch nicht vorstellen, daß die eine Ultraschall-Reinigung nicht überstehen, da dort ja im Grunde nicht viel anderes passiert als im Druckkopf selbst (nur sanfter. So ein Bubblejet ist im Grunde ne ziemlich heftige Maschine, da treten erstaunliche Drücke auf und die Tinte ist eine ziemlich rauhe Angelegenheit ).

Um mal wieder aufs Thema zurückzukommen: Und wenn Du die Patronen alle leer orgelst, reinigen, Düsentest, reinigen, Düsentest... so lange, bis das Ding wieder tut, was es soll. Wenn es das nicht tut und sich im Druckbild nichts ändert während der Reinigungsorgie, kannst Du wohl getrost von einem Elektronik- bzw. Kopfschaden ausgehen (sofern mit dem Druckertreiber alles ok ist. Versuch mit einem anderen Gerät kann da nie schaden!).

Grüße

--
---

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

Zitat:

---

Original von CarstenS:
@schluckebier:
> Du hältst also Rock Ridge und HFS für "exotischste Standards"?

Nicht nur halten, es sind im Desktop-Bereich sehr exotische Standards. Sollte Windows irgendwann mal deutlich an Marktanteilen an Linux verlieren und Linux zu dem Zeitpunkt noch auf Rockridge setzen, wird spätestens dann auch der Marktführer der Windows-Brennprogramme Rockridge-Support erhalten - verlass dich darauf.

---

Ermh... wenn wir hier schon anfangen, in Sachen CD-Standards Erbsen zu zählen:

RockRidge ist DER Standard für CD-Dateisysteme, auf dem andere "Standards" (sprich: Spezial-Lösungen) wie HFS und Joliet aufsetzen sollten (die beiden verbiegen das aber eher nach Gusto, daher sollten).

Ein kleiner Blick in die entsprechenden Dokumentationen zu CD-Dateisystem-Standards (also die tatsächlichen, nicht die marktfaktischen!) hilft bei der Aufklärung sicherlich weiter.

MakeCD bzw. alle "modernen" Brennprogramme für AmigaOS benutzen (wie es sein sollte) ISO/RockRidge als Basis und erweitern dieses um z.B. die AmigaOS-eigenen Dateiattribute. Das hat zur Folge, daß die Basis-Informationen zu einer Datei auf CD weiterhin für z.B. Linux-Systeme (aber auch Windoof und MacOS) lesbar bleiben, ohne daß es zu Konflikten durch die Erweiterungen kommt (die Erweiterung wird schlicht ignoriert).

Das Ende vom Lied: RockRidge ist für alle Systeme (selbst für die "exotischen", wie eben Windows mit Joliet) der kleinste gemeinsame Nenner.

Das durch die enorme Verbreitung von Windows mehr Joliet-konforme CDs gebrannt werden macht aber noch lange keinen "Standard" im tatsächlichen Sinn. Der wird woanders definiert, u.A. im schon genannten "Yellow Book" und einigen anderen Standardisierungsverfahren und -Dokumentationen.

Grüße

--
---

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

Zitat:

---

Original von MaikG:
>Bisherige Erkenntnis ist nur, dass das von MaxonBasic erzeugte
>Programm der grauenhafteste code ist, der mir seit langem
>(bzw. überhaupt?) untergekommen ist.

Mh, idr. läuft dieser aber korrekt, auf sämtlichen Klassics,
einiges sogar auf AONE wie ich hörte.
BlitzBasic hingegen ist sehr Instabiel, fast alles was ich
probiert habe stürzte auf 060 ab.

---

Zitat:

---

Das mit den Zeilennummern ist normalerweise nur bei sehr langen
Programmen...
Man könnte das Timing auch per Assembler code in MB einbinden,
wenn ich mich nur noch an meine Assembler zeit erinnern würde...

---

Schon eine Idee, wann die Erinnerung zurückkehrt?

Ich tendiere dazu, erst einmal die schon angesprochene Variante mit dem C-Code als "Nebentask" auszuprobieren. Das müßte sich ja per einfachem Signaling erledigen lassen.

Grüße

--
---

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

Zitat:

---

Original von MaikG:
>Also, wenn das nicht reicht, stimmt die Zeitangabe für den
>Goertzel-Lauf nicht. Definitiv.

Definitiv funktioniert meine Stoppuhr korrekt!!! Die hat nix mit
Basic oder Computern zu tun.

---

Zitat:

---

>Der Goertzel ist zwar nicht besonders aufwändig, benötigt aber
>sicherlich etwas mehr Zeit als die Kombination WaitPort()/GetMsg()/EClockVal-Berechnung
>und SendIO().

Tja so sollte es sein, aber wenn ich ebend diese sachen ausklammere
rennt das Programm.

---

Zitat:

---

>Im C-Code haut das auch einwandfrei hin, MIT Goertzel. Auf einem
>060er. Bis 12000Hz.

Alternativ könnte man ein C Programm in betracht ziehen, so
das das Basic Programm irgendwie mit dem C Programm kommuniziert
oder auch als Maschienencode in Basic einbinden.
Mich wurmt das aber das bei dem MB Prog was nicht stimmt.

---

Zitat:

---

>Der C-Code funktioniert.

Ist der wirklich Identisch mit dem Basic code? Da wurden einige
änderungen vorgenommen z.B. wo ReadEclock abgestürzt ist.

---

Zitat:

---

>Da die Benutzung des timer.device (soweit ich das überblicken kann)
>identisch mit der C-Variante ist, klemmt es wohl an einem anderen
>Punkt des Programms.

Das glaub ich nicht. Es kann sein das es bei der C->Basic umwandlung
zu fehlern gekommen ist aber wenn dann irgendwo im Time Code.

---

Zitat:

---

Holger hat den goertzel teil auch schon in Basic mit einer
Datei gemacht und das Funktioniert und entspricht der C geschwindigkeit.

---

Hattest DU den dann auch mal getestet?

Grüße

--
---

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

Zitat:

---

Original von MaikG:
>Eben. Rechne doch mal nach.
>[über den Daumen peil]
>55µs benötigt der Goertzel bei Dir (9.46 / 8000 / 20)
>[/über den Daumen peil].
>Das bedeutet, für WaitIO() (inkl. Message-Handling) und die
>Neuberechnung der EclockVal bleiben 70µs (da sind die Sprünge
>sowie SendIO() noch nicht drin). Das langt locker.

Anscheinend aber nicht.

---

Zitat:

---

>Das sieht für mich eher so aus, als würde die Zeitmessung via
>MB-Funktion nicht ganz hasenrein laufen, vermutlich ähnlich wie
>mit GetSysTime(), nur noch ungenauer, je nach Last.

Nein das ist nicht so, einmal merke ich den Unterschied von
20 auf 27 sekunden und ausserdem habe ich ebend nochmal
mit der Stoppuhr geguckt, die MB Zeit stimmt mit der auf der
Stoppuhr überein.

---

Wir können jetzt noch eine halbe Ewigkeit weiter raten. Der C-Code funktioniert. Er ist ausreichend schnell, liefert Zeitwerte, die sich von Deinen dahingehend unterscheiden, daß sie immer rund um eine Sekunde ergeben (ziemlich oft sogar exakt eine Sekunde, mit maximalen Abweichungen von 80000µs/Durchlauf statt 600000), der selbiges 20 mal problemlos wiederholt (und das sicherlich auch bei 1000 Wiederholungen problemlos erledigt) und wahlweise auch den Goertzel-Algorithmus beinhalten darf, ohne daß sich am Verhalten etwas groß verändert (nur die maximal erreichbare Frequenz sinkt etwas ab).

Frage: Welcher Code liefert ein anderes als das gewünschte Ergebnis?

Offensichtlich der BASIC-Code. Also müssen wir jetzt schauen, woran es bei Deinem Code genau hapert.

Da die Benutzung des timer.device (soweit ich das überblicken kann) identisch mit der C-Variante ist, klemmt es wohl an einem anderen Punkt des Programms.

Grüße

--
---

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

Zitat:

---

Original von MaikG:
> Zitat:
> Also Timing+goertzel=26,6 sekunden, Timing ohne goertzel=20.07422,
> görtzel incl. 16Bit->8Bit ohne Timing=9.46 Sekunden.
> Jeweils bei 20 Sekunden echtzeit.
>
>Hm, bei dem Text kann ich mich des Eindrucks nicht erwehren, daß Du nicht verstanden hast, wozu das Timing eigentlich dient.

Doch das habe ich zu 100% verstanden. Aber warum benötigt görtzel
ohne Timing nur 9.46 Sekunden aber mit Timing 26,6 sekunden?
Das heisst alleine das Timing benötigt mindestens 17 sekunden.
Jeweils liegt gar kein Einganssignal an also die Einganswerte sind
trotz unterschiedlicher Rate die selben.
Das goertzel findet ja zwischen den Timing statt und nicht danach...

---

Eben. Rechne doch mal nach.
[über den Daumen peil]
55µs benötigt der Goertzel bei Dir (9.46 / 8000 / 20)
[/über den Daumen peil].

Das bedeutet, für WaitIO() (inkl. Message-Handling) und die Neuberechnung der EclockVal bleiben 70µs (da sind die Sprünge sowie SendIO() noch nicht drin). Das langt locker.

Das sieht für mich eher so aus, als würde die Zeitmessung via MB-Funktion nicht ganz hasenrein laufen, vermutlich ähnlich wie mit GetSysTime(), nur noch ungenauer, je nach Last.

Grüße

--
---

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


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

Zitat:

---

Original von MaikG:

>Aber, wie schon mehrfach gesagt, erstmal solltest Du ein
>funktionierendes Programm haben (dem nähern wir uns ja jetzt),
>und dann können wir uns um die Geschwindigkeit kümmern. Denn
>bislang haben wir noch nicht wirklich optimiert (was ja auch
>richtig so ist).

Ich hab doch jetzt ein Programm was ein Timing liefert, auch
wenn das Timen doch noch recht lang dauert scheint es zu Funktionieren.
Besser währe natürlich ein Timing über den CIA.

---

Zitat:

---

Also Timing+goertzel=26,6 sekunden, Timing ohne goertzel=20.07422,
görtzel incl. 16Bit->8Bit ohne Timing=9.46 Sekunden.
Jeweils bei 20 Sekunden echtzeit.

---

Hm, bei dem Text kann ich mich des Eindrucks nicht erwehren, daß Du nicht verstanden hast, wozu das Timing eigentlich dient.

Es nützt Dir rein gar nichts, wenn Du ungesteuert sampelst. Sicher liest Du dann auch 8000 Werte vom Parallelport, aber die so gelesenen Werte sind nutzlos. Du hast dann keinen Schimmer (bzw. der Algorithmus), welche Frequenz die vorliegende Wellenform besitzt, weil Dir die Zeitbasis fehlt, Du bekommst nur verzerrte Amplituden (manche Werte tauchen doppelt auf, manche gar nicht, völlig ungesteuert halt).

Das Timing mit 125µs dient dazu, die Zeitbasis zu erhalten, die Dir eine Frequenzermittlung mittels Goertzel überhaupt erst ermöglicht.

Angenommen, Du hast bei einer gesteuerten Sample-Frequenz von 8000Hz alle 2 Sample-Werte einen Wechsel der Amplitude (positiv nach negativ und umgekehrt). Dank der Tatsache, daß Du 8000Hz Samplefrequenz gewählt hast, weißt Du somit, daß die gesamplete Wellenform eine Frequenz von 4000Hz besitzt (ein primitives Beispiel, gebe ich zu).

Schlußfolgerung: Wir müssen es hinbekommen, daß Sampling und Auswertung der Sample-Werte im notwendigen Zeitrahmen abgewickelt werden können.

Deine Versuche mit und ohne Timing sowie die Erkenntnis, daß das ohne Goertzel zeitmäßig hinhaut, mit Goertzel aber nicht, bringen Dir überhaupt nichts.

Der C-Code packt es auf schnellen Maschinen mit Goertzel ziemlich problemlos, also mußt Du Dich evtl. mit Holgers Hilfe (ich kann da, mangels MB, wohl nicht allzu viel helfen) hinsetzen und das Programm optimieren, bis alles im gewählten Zeitrahmen abgearbeitet werden kann und Dein Ziel somit erreicht ist.

Grüße

--
---

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

Zitat:

---

Original von MaikG:
>Da der C-Code hier bis auf die Ungenauigkeiten von GetSysTime() immer
>brav Zeiträume von 1 Sekunde ausspuckt (sogar inzwischen MIT
>Goertzel), liegt der Haken vermutlich bei MB.

Ich nehme die Timer funktion von MB zur kontrolle, die stimmt
mit meiner Armbanduhr überein.

---

Zitat:

---

>Allerdings weiß ich nicht, wie flott Dein Amiga ist. Aber ein 030er/50MHz
>sollte das eigentlich eben gerade schaffen...

An dem ich Progge ist ein 060@60MHZ drin, später soll es mal
auf 030er/50MHZ laufen.

---

Zitat:

---

>Ich sags mal so: Wenn das System ausschließlich für Deinen Gebrauch
>bestimmt ist, kannst Du Dir ja (wissentlich) beim Eingeben der
>Ziffern Zeit lassen. Also so: 1. Ziffer, 1 Sekunde warten,
>2. Ziffer...

Und woher weiss der Computer das grade die erste Ziffe angekommen
ist und nicht nur ein Umweltgeräusch?

---

Zitat:

---

Das ist ja das Problem
mit der Spracherkennung, innen kein Problem aber aussen ist
es niemal still.

---

Zitat:

---

>Der Goertzel erkennt die Störgeräusche aber normal doch nicht als
>DTMF-Töne?

Nein, Goertzel nicht aber ich kann ja nicht 1 sekunde Samplen
2 sekunden auf Goertzel warten, wieder 1 sekunde Samplen usw.
Wenns nicht in Realtime geht müsste ich das vorauswerten.

---

Zitat:

---

Zitat:
> WHILE Repeat1% < (intervall% * seconds%)
> WEND

Bei seconds%=20 bekomme ich so 4.78125 Sekunden realtime???

>Irgendwie lustig, da ist es auf einmal VIEL schneller... intervall%
>bezeichnet doch das Warte-Intervall in Hz (Takte/s). Wenn man dann
>das Intervall (z.B. 8000) mit 20 multipliziert, ergeben sich 160000
>Durchläufe der Schleife. Die Schleife wird also erst dann verlassen, wenn repeat% den Wert 160000 erreicht.

Aber es kann doch nicht schneller als Echtzeit sein wenn es über
einen Timer läuft!

---

Zitat:

---

>Ach, warte: % bezeichnet nicht zufällig ein 16Bit-Integer?? Wenn
>ja, hast Du da wieder ein Überlauf-Problem (-32768 bis 32767).
>Mach daraus dann mal ein &.

Oh, stimmt Repeat wird ja immer erhöht und muss ja irgendwann 160000
sein.

Hängt sich auf wenn man Repeat1& und 20sek nimmt.

---

Umso schlimmer. Schau doch auch mal nach, wie MB die Datentypen wandelt, wenn das Ergebnis nicht mehr "reinpaßt". Eventuell müßtest Du auch die anderen Variablen, die an dieser Rechnung beteiligt sind, als 32Bit-Integer wählen.

Grüße

--
---

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

Zitat:

---

Original von MaikG:
>Öhm, nicht? Beherrscht MB keine verschachtelten Schleifen??

Doch, aber wenn ich das mache passiert gar nichts mehr.

>Abgesehen davon: 1.648439 ist eindeutig zu lang. Also scheint der
>Goertzel in BASIC etwas zu langsam zu sein.

Nein, nicht langsamer als C.

---

Zitat:

---

Ohne goertzen ists 1.164063 ergo läuft der Code genausowenig
wie die anderen...

---

Zitat:

---

>Da wäre es evtl. sinnvoller, den Telefon-Sound in einen Puffer
>zu samplen und dann auszuwerten

Das geht nicht wirklich gut, es soll z.B. ein Zuganscode bearbeitet
werden, da ist die erste Ziffer noch nicht fertig wenn ich
die letzte eingegeben habe.

---

Zitat:

---

Ich müsste versuchen das vorauszuwerten, aber das geht nicht,
weil wir dann wieder bei störgeräuschen sind. Wind/Autos/Züge/Wasser
kann ich nur genauso wie DTMF als Amplitude sehen...

---

Zitat:

---

> WHILE Repeat1% < (intervall% * seconds%)
> WEND

Bei seconds%=20 bekomme ich so 4.78125 Sekunden realtime???

---

Irgendwie lustig, da ist es auf einmal VIEL schneller... intervall% bezeichnet doch das Warte-Intervall in Hz (Takte/s). Wenn man dann das Intervall (z.B. 8000) mit 20 multipliziert, ergeben sich 160000 Durchläufe der Schleife. Die Schleife wird also erst dann verlassen, wenn repeat% den Wert 160000 erreicht.

Ach, warte: % bezeichnet nicht zufällig ein 16Bit-Integer?? Wenn ja, hast Du da wieder ein Überlauf-Problem (-32768 bis 32767). Mach daraus dann mal ein &.

Grüße

--
---

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

Zitat:

---

Original von MaikG:
>Den Mausadapter kann er ja voll übernehmen, in seinem Portfolio
>findet sich ja nichts vergleichbares.

Na doll ist der aber nicht, ohne Scroolrad. Dann würde ich mich
lieber mit dem PS2m Programmschreiber in verbindung setzen und
fragen ob man das PIC Programm komerziell verwenden kann.
Bei dem Teil gehen zwar die Scroll/4./5. Taste Signale über den
Joyport, dafür gibts keine Schwierigkeiten mit Spielen die
dann ruckeln etc.

---

Ich nehme mal an, daß Du Dir die Spezifikationen nicht ganz durchgelesen hast. Scrollrad ist prinzipiell möglich, die Software dazu fehlt aber. Sobald jemand das per FreeWheel o.Ä. zum Laufen kriegt, hat sich dieser "Makel" auch erledigt.

Für einen Adapter als "Lohn" könnte ich mich ja mal dranmachen, Training kann nie schaden

Grüße

--
---

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

Zitat:

---

Original von Han_Omag:
@whose:

>> Naja, selbst bei einem All-in-One-System käme man ohne die Boom-Boxen schlecht aus, wenn man denn "Boom" haben will.

Wenn man auf das letzte Quentchen "Boom" verzichten kann, geht es inzwischen auch ohne. Bin mal mit meinem SX4 zu ACR gefahren, um nachzufragen, "wo noch Verbesserungen in Sachen Sound machbar sind". Der Test war überraschend. Antwort: Na ja, an das Bose System für den Audi A8 kommts nicht ran (welche Überraschung, das kostet schliesslich mehr, als mein ganzes Auto), aber ne kleine Endstufe und ein maximal 30er Bass wären völlig ausreichend. Der Rest wäre für eine Ab-Werk-Inclusiv-Anlage akustisch erstaunlich gut.

---

Dir ist aber schon klar, daß so ein 14"-Bass auch seinen Platz braucht? Von der "Befeuerung" gar nicht zu reden

Zitat:

---

>> CD-Wechsler hat natürlich auch seine Vorteile, aber das ließe sich dank MP3 ziemlich leicht relativieren.

Ein CD-Wechsler ist in dem Moment absolut entbehrlich, wo man auf eine Festplatte zugreifen kann. Ein Slot-in DVD-Player wäre dann völlig ausreichend, oder stattdessen ein USB Anschluss, um Sachen auf die Platte zu kriegen.

---

Naja, auf ne Pladde könnte man im Grunde ganz verzichten. Wäre bei einem KFZ-System auch empfehlenswert, die dort auftretenden Stöße sind teilweise nicht von schlechten Eltern. Das OS auf Solid-State-Datenträger (ich weiß nicht, ob eine Austausch-Version ratsam wäre in Hinblick auf Viren etc.), OS4 ist ja nun wirklich klein genug, den Rest via DVD-Laufwerk/USB. Vielleicht eine 1GB-CompactFlash oder ähnliches, mit geschütztem Bereich für das Betriebssystem, den Rest frei für Audio-/Video-Daten...

Ganz nebenbei ergäbe sich da noch ein "Sahnehäubchen" als Verwendungszweck für eine moderne Amiga-Plattform. Konkurrenz zum IPod z.B. in Form eines tragbaren Kleinst-Amiga mit USB-Schnittstelle.

Da hätte dann evtl. auch der Amiga Inc. Briefkasten als derzeitiger "Content-Provider" etwas von. Sinnige und unsinnige kleine Spielchen für dieses System zum Download anbieten und verticken

Zitat:

---

Und MP3 im Auto gibt es bereits. Mein "Radio" spielt auch auf CD gebrannte MP3s ab.

---

Das tut nahezu jedes moderne Autoradio mit CD-Laufwerk. Was mich dabei stört ist die ewige Sucherei nach Titeln. Wenn man eine ganze CD mit der privaten Sammlung vollgeballert hat, wirds nervig mit dem Herumgeklicker auf der Suche nach einem bestimmten Titel o.Ä. Da stört das Mini-Display in der Tat nur noch geringfügig.

Richtig genial wäre es dann in Verbindung mit ner Art Amiga-IPod. Anschließen, der Player im "Radio" sucht nach einer Playlist (oder zeigt alle verfügbaren Playlists auf dem Mini-Amiga an) und legt los. Ohne das man ein oder mehrere Knöpfchen drücken muß. Das Gleiche funktioniert dann genauso "seemless" mit gebrannten MP3-CDs. Playlist mit drauf und gut. Selbst aussuchen kann man dann ja trotzdem noch.

Davon abgesehen kann man mit ziemlich wenig Aufwand zu allen möglichen Playlist-Formaten kompatibel bleiben. Wie wäre es mit einem "Playlist-Datatype"?

Grüße

--
---

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

Zitat:

---

Original von Holger:

Zitat:

---

Original von aPEX:
@Michael
Habe gerade mit Jens telefoniert, vielleicht können ja die grossen den Vertrieb und die Produktion der kleinen übernehmen. So würde man sich nicht in die Quere kommen und könnte miteinander den Classic-Markt unterstützen.

---

Das klingt doch mal richtig konstruktiv.

---

In der Tat. Da müßte sich doch auch eine Lösung für den Tastaturadapter finden, denke ich. Kaspert das mal in Ruhe aus, ich denke, da kann man sich durchaus einigen und "die Großen" können den Kunden etwas bieten, wonach sie augenscheinlich verlangen.

Im Prinzip würde ich beide Adaptertypen gern käuflich erwerben, denn die bieten doch etwas mehr, als die bereits auf dem Markt erhältlichen Adapter.

@aPEX:

Schlag ihm doch mal vor, die Adaptertypen preislich etwas unterschiedlicher zu gestalten (Lyra günstiger). Auf dem Weg wird er evtl. seinen Lagerbestand an Lyra-Adaptern los, kann aber über den Adapter von Reptile "am Geschäft teilhaben" und später, wenn Lyra ausverkauft sein sollte oder sich wenigstens nicht als Verlustgeschäft herausstellt, voll auf den von Reptile setzen.

Den Mausadapter kann er ja voll übernehmen, in seinem Portfolio findet sich ja nichts vergleichbares.

Wäre jedenfalls sinnvoller, das so zu regeln als sich "die Köppe einzuschlagen" oder die putzigen Adapter zu begraben.

Grüße

--
---

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

Zitat:

---

Original von MaikG:
Oh, simmt nun sind es 1.648439 - mit goertzel also 1,0 müssten es sein.
Wie muss ich das machen wenn ich 20sekunden will?
Um der Schleife noch eine geht nicht.

---

BASIC code:

---

WHILE Repeat1% < (intervall% * seconds%)
.
.
.
WEND

---

wäre z.B. ein gangbarer Weg.

Abgesehen davon: 1.648439 ist eindeutig zu lang. Also scheint der Goertzel in BASIC etwas zu langsam zu sein. Da wäre es evtl. sinnvoller, den Telefon-Sound in einen Puffer zu samplen und dann auszuwerten

Grüße

--
---

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

Zitat:

---

Original von Han_Omag:
@schluckebier:

Mag sein, das es nicht wirklich innovativ ist, aber ich vermisse bisher eine solche All-in-one Lösung zum einfachen Nachrüsten. Wenn schon nicht innovativ, so wärs für mich doch ein echter Schritt in die richtige Richtung, anstelle von Radio im Schacht, CD-Wechsler unterm Sitz, Endstufen und Boom-Boxen im Kofferraum (nein, mein SX4 sieht NICHT so aus).

---

Naja, selbst bei einem All-in-One-System käme man ohne die Boom-Boxen schlecht aus, wenn man denn "Boom" haben will. Bei Tiefbass hilft Volumen nun mal am besten Blöderweise verhält sich das bei den Endstufen ähnlich, obwohl die ja bei gleicher Leistung deutlich kleiner geworden sind als sie noch vor 10 Jahren waren. Bei 4x30W RMS scheint auch langsam die Grenze der Chip-Lösungen bei Autoradio-Endstufen erreicht zu sein.

CD-Wechsler hat natürlich auch seine Vorteile, aber das ließe sich dank MP3 ziemlich leicht relativieren. Mit einem Amiga-System im Auto könnte man wahlweise auch direkt vor Ort wandeln (mit den bekannten Programmen und GUIs). Mal ganz abgesehen von der Möglichkeit, sich Playlists anzulegen, was bei den Standard-CD/MP3-Radios nun mal nicht geht, oder zum Abspielen den Lieblings-MP3-Player zu verwenden...

Zitat:

---

Ob man dafür einen Computer BRAUCHT ist für mich nicht die Frage. Ich hätte gern einen als Laptopersatz, Navi und fürs Entertainment, und denke, auch ein solches "Gesamtkunstwerk" hätte was, wenn es unauffällig integriert wäre.

---

Genau das fände ich schon recht innovativ. Einfach, weil es exakt sowas bisher nicht käuflich zu erwerben gibt und die Linux-Lösungen doch arg "zusammengestückelt" rüberkommen.

Grüße


--
---

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

Zitat:

---

Original von MaikG:
Stürzt nicht mehr ab, aber ich glaub auch nicht das es Funktioniert.

Bei einem Intervall von 8000 HZ läuft die Schleife
183.1758 sekunden -das kann ja nicht stimmen oder?

---

Nein, kann es eigentlich nicht. Es sei denn, irgendwas in dem Programm läuft noch daneben oder es läuft schlicht zu langsam. Letzteres kann ich mir aber nicht so recht vorstellen.

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 22.09.2006 um 12:31 Uhr geändert. ]

Zitat:

---

Original von Holger:

Zitat:

---

Original von MaikG:
Nachtrag: Stürzt bei ReadEClock ab.

---

ReadEClock ist ein Art Library-Funktion des timer.device. Um die aus MaxonBasic heraus aufzurufen, muss MaxonBasic die Basisadresse der Library kennen, man kann aber ein device nicht wie eine Library öffnen.

---

Ich seh schon, ich sollte mal die Antifalten-Gurkenscheiben von den Augen nehmen

Ich hab glatt übersehen, daß das fehlt.

Grüße

--
---

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

Zitat:

---

Original von Maja:

@whose

> Abgesehen davon hält sich ganz offensichtlich der Bedarf, aktuelle
> OpenSource-Bloatware laufen zu lassen, in engen Grenzen

Hm, an wen denkst Du dabei? Amiga-User?

---

Zitat:

---

> Es geht einfach nur darum, wie man sich einen aktuellen Amiga so
> vorstellt. Ob der "optimal" ist oder nicht läßt sich offensichtlich
> nicht so einfach festlegen, wie man an den Beiträgen hier sieht.

Das Topic lautet " Sinnieren, Spekulieren und Phantasieren über die Zukunft des Amiga...". Und da stellst Du Dir etwas vor, was für Dich nicht optimal wäre? Ob es für andere auch optimal wäre, spielt doch keine Rolle. Für Dich wenigstens nicht. Es geht um Fantasie.

---

Zitat:

---

> Naja... auch das ist wieder eine Frage des Anwendungsfalls... für
> die Dinge, die ich so im Büro treibe, brauche ich kein OpenOffice.
> Und auch keinen Mozilla. Da tut es jede x-beliebige
> Tabellenkalkulation (hier: TurboCalc), eine halbwegs komfortable
> Textverarbeitung (hier: WordWorth) und eine kleine Datenbank (hier:
> MuiBase).

Ist zwar auch OT, aber egal:

So lange Du keine Daten, Dateien mit anderen Systemen austauschen musst, sondern nur für Dich arbeitest und alles in Deinem Büro bleibt, funktoniert das. Ansonsten braucht man MS-Office oder kompatible. Und erzähl jetzt bitte nicht, TurboCalc, WordWorth und MUIBase wären MS-Office-kompatibel. Das sind sie nicht.

Und was Gewerbetreibende betrifft: Die kommen um einen Java-fähigen Browser nebst passendem OS nicht mehr rum, weil sie ihre Steuererklärung via Internet abgeben müssen. Ergo braucht ein moderner Amiga Java, wenn er eine Chance haben soll.

---

Zitat:

---

Last but not least können Unternehmen mit Amiga-Software wie Du sie aufzählst für den Büroalltag heute nichts mehr anfangen. Da braucht es ein leistungsfähiges Office-Paket. Und dafür ist OpenOffice sicher nicht die schlechteste Wahl.

---

Zitat:

---

> Mich würde einmal interessieren, wie viele der OpenOffice-Benutzer
> dessen Funktionsumfang zu mehr als 10% ausreizen, ernsthaft. Die
> kleineren "Problemchen" von OO lasse ich dabei mal ganz außer Acht.

Ernsthaft? Dieses Argument halte ich für albern? Insbesondere, wenn es um kostenlose Software geht. Sollen Software-Entwickler zig Verschiedene Versionen erstellen, mit mal mehr, mal weniger Funktionsumfang, nur damit jeder an die 90% Nutzungsgrad kommt? XXS, XS, S, M, L, XL, XXL und XXXL Office? Das ist Quatsch.

---

Zitat:

---

> Die kleineren "Problemchen" von OO lasse ich dabei mal ganz außer Acht.

Nun tu nicht so, als würde es irgendwo Software ohne "kleiner Problemchen" geben. Das ist schlicht falsch. Was man hat wird nicht davon besser, dass man etwas was man nicht hat schlecht redet.

---

Ist halt nur schlecht, wenn die vielgerühmten und "zwingend notwendigen" Komfortfunktionen öfter mal nicht das tun, was sie tun sollen, gerade bei Standard-Programmen dieses Formats. Nur fällt das bei den großen Programmen inzwischen nicht mehr so ins Gewicht. Es gibt ja kaum noch Alternativen, dafür reichlich "Tipps und Workarounds".

Doch, eigentlich gibts die Alternativen schon, aber "man" möchte sich ja ungern "lächerlich" machen vor den Kollegen oder Geschäftspartnern...

Also, mir geht es nicht gegen Dich oder Deine Meinung zu den "üblichen" Standard-Programmen, um das noch einmal klarzustellen. Mir geht es darum, daß wir uns gar nicht so weit von dem entfernt bewegen, was tagtäglich tatsächlich gebraucht wird.

Ich sehe es durchaus ein, daß viele sich einen "optimalen" Amiga auch mit den bekannten Office-Programmen und Browsern wünschen. Dagegen ist prinzipiell auch gar nichts zu sagen. Ich sage nur etwas dagegen, daß ein moderner Amiga mit Marktchancen ohne diese Standard-Programme völlig undenkbar wäre.

Das ist nämlich Quatsch. Computer werden nicht nur ausschließlich im Büro, zu Bürozwecken daheim oder zum Surfen benutzt. Da gibts noch weit mehr Betätigungsfelder für ein Computersystem. Ein Amiga ist aber nichts desto trotz auch für diese Zwecke einsetzbar. Ein moderner vielleicht sogar in dem Maß, wie Du es Dir wünschst.

Wer weiß?

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 21.09.2006 um 03:26 Uhr geändert. ]

Zitat:

---

Original von Maja:
@fisch08:

> Meinst du ernsthaft, es gibt ansatzweise einen Bedarf 20 Jahre alte
> Software auf einem modernen Rechner laufen zu lassen?

So lange keine Aktuelle Software verfübar ist, ja.

---

Abgesehen davon hält sich ganz offensichtlich der Bedarf, aktuelle OpenSource-Bloatware laufen zu lassen, in engen Grenzen

Zitat:

---

Da es hier aber um Wunschdenken vom optimalen Amiga geht, gehen wir davon aus, dass die gewünschte Software in zeitgemäßer Funktionalität vorliegt. Dann wäre eine solche "Kompatiblitäts-Brücke" eigentlich nicht nötig.

---

Zitat:

---

> Wer es unbedingt nötig hat, greift zu einem Emulator.

Das ist alledings richtig und wäre auch die günstigere Methode als ein Hardware-Zutsatz.

---

Das hängt doch mehr von den Anwendungsfällen ab, oder? Die Chipsatz-Emulation von WinUAE z.B. zieht schon ordentlich Power, manchen wäre das evtl. nicht "optimal" genug

Ist doch Latte, wenn jemand das gern in Hardware haben möchte, warum nicht?

Zitat:

---

> Warum man allerdings einen Emulator brauch, um alte Programme
> laufen zu lassen, die von jeder OpenSource Entwicklung schon lange
> den Rang abgelaufen bekommen hat, bleibt rätselhaft.

Hier geht es doch um den Traum vom optimalen, konkurenzfähigen Amiga, wenn ich das richig verstanden habe. Wenn wir nun mal den Realismus beiseite lassen und vergessen, dass diese OpenSource-Programme, von denen Du sprichst, für AOS nun mal nicht verfügbar sind, hast Du auch damit völlig Recht.

---

Zitat:

---

In der realen Welt bliebe dann allerdings wieder nur die Emulation, weil besagte OpenSourche-Software für das System nicht verfügbar ist und für ein solch optimales System, selbst wenn es erscheinen würde, wahrscheinlich auch nicht sofort zu Verfügung stehen würden.

---

Hä? Bitte erläutern, den verstehe ich nun gar nicht in dem Zusammenhang mit dem Thema hier...

Grüße

--
---

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

Zitat:

---

Original von crack:

Zitat:

---

Original von whose:
... E-UAE läuft ja recht gut mit OS4

---

Hm, das halte ich für ein Gerücht

---

Ich nicht Wenn Du das Teil nicht ordentlich konfiguriert bekommst, ist das was anderes. Bei mir läufts prima und schnell genug für die Klassiker unter den Spielen.

Abgesehen davon: Die Aussage meinerseits beerdigt ja keineswegs automatisch jegliche Verbesserung

Grüße

--
---

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

Zitat:

---

Original von fisch08:

Zitat:

---

So what... man nehme den Amiga2000/3000 und daddelt damit ein wenig rum...Ich denke viel haftet an einem, weil man die damalige Zeit so anders (positiver) erlebt hat.

---

---

Das bleibt Dir so oder so belassen... und jedem anderen auch. Unabhängig davon, wie es mit OS4 nebst Hardware weitergeht.

Schaden kann die "Träumerei" ohne dauernden Vergleich mit den ach so tollen x86-Systemen jedenfalls auch nicht. Möglichkeiten bieten sich da jedenfalls, denn OpenSource-KFZ-Entertainment-Systeme sind wohl doch nicht so verbreitet (ich kenne nicht eines, das man im Laden kaufen kann und das mehr OS einsetzt als für den Kernel notwendig), erst recht keine, die auf modernsten x86-CPUs basieren. Für die Aufgaben sind x86-Systeme mit DualCore-CPU und "allem Pipapo" anscheinend doch nicht so gut geeignet.

Was letztendlich aus diesen Möglichkeiten gemacht wird, steht allerdings auf einem anderen Blatt.

Grüße

--
---

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

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
... noch durch die (korrekte) Variante aus der Sample-Schleife ersetzen, also gegen das hier:

code:

---

newLow&=PEEKL(eclockval&+ev_lo%)+diff&
IF newLow&<PEEKL(eclockval&+ev_lo%) THEN POKEL(eclockval&+ev_hi%),PEEKL(eclockval&+ev_hi%)+1
       POKEL(eclockval&+ev_lo%),newLow&

---

.

Ersteres war ein Fehler von mir, da hatte ich vergessen, ev_lo auf jeden Fall mit der Differenz zu addieren.

---

Leider funktioniert das so auch nicht. Diese Art von Überlauftest funktioniert nur, wenn die Zahl als vorzeichenlos (ULONG) behandelt wird. Denn der Überlauf muss als solcher beim Übergang von 0xFFFFFFFF nach 0x00000000 erkannt werden. Da Basic aber diese Variablen immer als vorzeichenbehaftet betrachtet, wird der Vergleich beim Übergang von 0x7FFFFFFF nach 0x80000000 positiv.

---

Ah so, sorry, ich dachte, MB wäre da schon etwas weiter gewesen als AmigaBASIC. ACE z.B. kennt auch vorzeichenlose Integer-Variablen, daher dachte ich, das wäre bei MB auch so.

Wiederum danke für die Korrektur.

Grüße

--
---

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

Zitat:

---

Original von Han_Omag:

So ein Teil zum relativ leichten Nachrüsten bis 2.500 Euro, und ich würde einen Kauf ernsthaft in Erwägung ziehen. Und wenn dann auf der Blende "Amiga" steht, warum nicht? Aber ich nehms auch von nem anderen Label

---

Hm, so viel würdest Du anlegen wollen für so ein System? *grübel* Wie viele kennst Du noch, die dazu bereit wären? Ich denke mal, da gäbs durchaus noch ein paar... die zentrale Frage ist, bekäme man 1000 Käufer dafür zusammen? Oder gar mehr?

Schade, daß die Geschichte zwischen Hyperion und Amiga Inc. noch nicht geklärt ist... ehrlich gesagt hätte ich ziemlich wenig Lust, so etwas anzuleiern, solange Mr McEwen da ein (mehr oder weniger) gewichtiges Wörtchen mitzureden hat. Im anderen Fall hätte ich da schon eine recht klar umrissene Idee, wie man sowas realisieren könnte. Eins fehlt allerdings bisher noch: Hardware im Leistungsbereich 400+ MHz in entsprechender Größe. Alles andere ist im Prinzip schon vorhanden (ja, ich meine tatsächlich die Software).

Hm, mal schauen, wie es nach Weihnachten 2006 weitergeht...

Grüße

--
---

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

Zitat:

---

Original von dirtie:
Ich weiß nicht ob ich lachen oder heulen soll


Nicht nur Bill McEwen scheint irgendwie den Realitätsbezug verloren zu haben. Warum soll ich mir hier einen Rechner erträumen?
Mein Classic funzt so lange er funzt... und dann wars das

gtx d!RT!E/mdS

---

Tststs, schon vergessen, daß der Amiga aus genau so einem Traum entstanden ist? Damals träumte man von der ultimativen Spielkonsole, obwohl es da gute und funktionierende gab...

Ok, die große hardwaretechnische Neuerung wird dabei vermutlich nicht mehr herauskommen, weil viele der technischen Neuerungen des damaligen Amiga inzwischen Einzug in die Welt der Standard-Komponenten gehalten haben (obwohl ich die Möglichkeiten eines Coppers immer noch so ein wenig vermisse).

Eine Möglichkeit, etwas "Neues" zu bringen wäre (meiner Meinung nach), die aktuellen technischen Möglichkeiten mit denen des AmigaOS zu verbinden.

Da fällt mir auf Anhieb die Screen-Drag-Geschichte ein. Da ja anscheinend Hardware-Overlay jetzt machbar ist, könnte man die beiden doch kombinieren. Wäre z.B. recht neckisch, wenn man einen Raytracer-Screen im Kleinen (also skaliert) zu Beobachtungszwecken auf die WB legen könnte, während man (im Rahmen der CPU-Belastung) weiter arbeitet.

Oder man nutzt das Overlay für "echtes" Screen-Dragging, derzeit haben wir ja nur das "halbe" Dragging, wie man es vom echten Amiga kennt (z.Z. müssen die Auflösungen/Bittiefen übereinstimmen).

Ich denke, AmigaOS an sich bietet reichlich Möglichkeiten, etwas "Neues" zu bringen. Das fängt schon mit nicht-aufgeblasenen Programmen an, die keine 20 Sekunden zum Starten brauchen, geht über die fabelhafte Reaktionszeit weiter und hört bei der Bedienbarkeit noch lange nicht auf (natürlich kann auch daran noch was verbessert werden).

Was ich richtig genial fände, wäre ein Auto-Navi-System auf AmigaOS-Basis. WindowsCE suckt da nämlich etwas, finde ich (grottenlahm, miese Reaktion, Abstürze wegen der komischen Speicherverwaltung von CE usw. usw.). Ganz nebenbei könnte man mit so einem System auch noch fein Zocken im Stau, E-UAE läuft ja recht gut mit OS4

Nur mal so ne Idee...

Grüße

--
---

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

Zitat:

---

Original von MaikG:
Stürzt nur ab:

code:

---

eclockval&=AllocMem&(EClockVal_sizeof%,MEMF_CLEAR&)

ticks&= ReadEClock&(eclockval&)
Intervall%=8000
diff&=ticks&/Intervall%

IF PEEKL(eclockval&+ev_lo%)+diff& < PEEKL(eclockval&+ev_lo%) THEN
 POKEL(eclockval&+ev_hi%),PEEKL(eclockval&+ev_hi%)+1
 ELSE
 POKEL(eclockval&+ev_lo%),PEEKL(eclockval&+ev_lo%)+diff&
END IF 

POKEW tr& + tr_node% + IORequestio_Command%, TR_ADDREQUEST&
POKEL tr& + tr_time% + tv_secs%, PEEKL(eclockval&+ev_hi%)
POKEL tr& + tr_time% + tv_micro%, PEEKL(eclockval&+ev_lo%)
SendIO&(tr&)

t!=TIMER

      WHILE Repeat1%<Intervall%
 
       junk&=WaitPort&(timerport&)
       WHILE TimerMsg&=GetMsg&(timerport&)
       WEND
       newLow&=PEEKL(eclockval&+ev_lo%)+diff&
       IF newLow&<PEEKL(eclockval&+ev_lo%) THEN POKEL(eclockval&+ev_hi%),PEEKL(eclockval&+ev_hi%)+1
       POKEL(eclockval&+ev_lo%),newLow&

       POKEW tr& + tr_node% + IORequestio_Command%, TR_ADDREQUEST&
       POKEL tr& + tr_time% + tv_secs%, PEEKL(eclockval&+ev_hi%)
       POKEL tr& + tr_time% + tv_micro%, PEEKL(eclockval&+ev_lo%)
       SendIO&(tr&)

       INCR repeat1%
       INCR mycount%:IF mycount%=8000 THEN mycount%=0:INCR myseconds% REM :move rpS&,20,25:Text rpS&, SADD(TIME$+CHR$(0)),8
       sa&=PEEKB(&hBFE101)<<8
       IF sa&>&H7FFF THEN sa&=sa& OR &HFFFF0000&
       bla%=goertzel%(sa&)
      WEND

      move rpS&,20,45:Text rpS&, SADD(STR$(TIMER-t!)+CHR$(0)),LEN(STR$(TIMER-t!))
      move rpS&,20,55:Text rpS&, SADD(STR$(myseconds%)+CHR$(0)),LEN(STR$(myseconds%))

AbortIO&(tr&)
junk&=WaitIO&(tr&)
FreeMem eclockval&,EClockVal_sizeof%

---

---

code:

---

junk&=WaitPort&(timerport&)
       WHILE TimerMsg&=GetMsg&(timerport&)
       WEND

---

code:

---

WaitIO(tr&)

---

code:

---

IF PEEKL(eclockval&+ev_lo%)+diff& < PEEKL(eclockval&+ev_lo%) THEN
 POKEL(eclockval&+ev_hi%),PEEKL(eclockval&+ev_hi%)+1
 ELSE
 POKEL(eclockval&+ev_lo%),PEEKL(eclockval&+ev_lo%)+diff&
END IF

---

code:

---

newLow&=PEEKL(eclockval&+ev_lo%)+diff&
IF newLow&<PEEKL(eclockval&+ev_lo%) THEN POKEL(eclockval&+ev_hi%),PEEKL(eclockval&+ev_hi%)+1
       POKEL(eclockval&+ev_lo%),newLow&

---

.

Ersteres war ein Fehler von mir, da hatte ich vergessen, ev_lo auf jeden Fall mit der Differenz zu addieren.

Grüße

--
---

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

Zitat:

---

Original von MaikG:
>Ach was, halb so wild. Auf Minus müßte man streng betrachtet
>testen, weil die Methode, die ich da gewählt habe, nicht immer
>funktioniert, eben wegen dem Vorzeichen.

Na, bei der DTMF erkennung musste sie aber immer funktionieren.

---

Zitat:

---

>Dem möglichen Überlauf mußt Du Rechnung tragen, weil das Programm
>sonst ab einer bestimmten Zeit (2^32 µs)nach Start des Rechners
>Unsinn liefern würde. Entweder, Du rennst im Laufe der Zeit da
>rein oder Du startest das Programm zufällig zur falschen Zeit,
>und da wärs ja doof, wenn das Programm dann Mist baut, weil wir
>den Überlauf von ev_lo nicht beachtet haben. Für ne Alarmanlage
>wärs ohne Überlauf-Test also nicht unbedingt brauchbar.

Wie hoch geht die Zahl bis der Überlauf kommt?

---

Zitat:

---

>Ich nehme ja nicht an, daß Du versuchst, mit gebrochenen
>Frequenzen beim Samplen oder allgemein mit Zeiträumen von mehr
>als knapp ner Stunde für DTMF-Erkennung zu arbeiten.

Eigentlich nicht so lang.

---

Meine ich doch. Mit dem Zeitraum ist auch der Zeitraum gemeint, der die Wartezeit ausmacht (also hier die 125µs, im Programm diff). Bei der Berechnung von diff könnte es bei zu großen Zeiträumen Schwierigkeiten geben, aber bei 125µs (oder, wie Holger schon sagte, Zeiträumen von weniger als über den Daumen gepeilt knapp einer Stunde) passiert das nicht.

Grüße

--
---

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

Zitat:

---

Original von MaikG:
>Also, es würde mich wundern, wenn MB 64Bit-Integer kennen würde.
>Der Test in meinem Programm funktioniert aber auch damit und ist
>ziemlich simpel gehalten.

Ja, den hab ich mir ausgedruckt. Aber im Kommentar steht was mit
Überläufe und man müsste auf Minus testen...
Wenn das so noch kein 100%iges Programm ist fang ich lieber
erst gar nicht an es in Basic umzusetzen...

---

Ach was, halb so wild. Auf Minus müßte man streng betrachtet testen, weil die Methode, die ich da gewählt habe, nicht immer funktioniert, eben wegen dem Vorzeichen. Daher die "Warnung" mit dem Minus. Das habe ich bei dem "Trick" außer acht gelassen (weil in diesem sehr speziellen Fall nicht zwingend notwendig) und es funktioniert für Deine Zwecke.

Dem möglichen Überlauf mußt Du Rechnung tragen, weil das Programm sonst ab einer bestimmten Zeit (2^32 µs)nach Start des Rechners Unsinn liefern würde. Entweder, Du rennst im Laufe der Zeit da rein oder Du startest das Programm zufällig zur falschen Zeit, und da wärs ja doof, wenn das Programm dann Mist baut, weil wir den Überlauf von ev_lo nicht beachtet haben. Für ne Alarmanlage wärs ohne Überlauf-Test also nicht unbedingt brauchbar.

Du kannst es ruhig einsetzen, weil die entsprechenden Voraussetzungen mit 99%iger Wahrscheinlichkeit erfüllt sind. Ich nehme ja nicht an, daß Du versuchst, mit gebrochenen Frequenzen beim Samplen oder allgemein mit Zeiträumen von mehr als knapp ner Stunde für DTMF-Erkennung zu arbeiten. Oder das auf andere Plattformen als AmigaOS 68K zu portieren. Bei ganzen, positiven Zahlen für die Frequenz funktioniert das.

Sofern Du die von Holger korrigierte Form verwendest

Grüße

--
---

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


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