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

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

Zitat:

---

Original von Chritoph:
@MaikG:
Mag sein, allerdings gibt/gab es aus der Ecke genug Leute, die 17h und
mehr am Tag Online-RPGs spielen. Wenn die statt dessen Amiga-Software
entwickeln würden, gäbe es keine Probleme mehr.

---

Dann erzähl doch mal, wer von den RPG-Zockern sowas kann. Ich kenne inzwischen keinen einzigen dieser "nur-noch-Konsumenten" mehr, der dazu wirklich in der Lage wäre. Ein bißchen rumscripten, sofern die noch im IRC unterwegs sind, das wars dann meist auch schon.

AOS ist etwas... komplexer zu handhaben als ein mIRC-Script

Grüße

--
---

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

Zitat:

---

Original von Maja:

@all

Sagt mal, was macht dieser Amiga eigentlich aus uns? Sollte das nicht ein Hobby sein, das Spaß macht? Hallo?! Ein Hobby!

Bitte wieder locker werden. Ich geh jetzt in die Heia und schlaf ne Runde. Dann gehts wieder.

---

Och, wenn es finanziell derzeit möglich wäre, würde ich lieber eine Lebensaufgabe und einen Beruf daraus machen

AmigaOS macht Spaß, in allen Formen (ja, sogar als MOS, ich habs endlich mal zum Laufen gekriegt auf meiner CSPPC. Ist zwar doch irgendwie "anders", aber fühlt sich trotzdem gut an).

Aber sich deswegen über die menschlichen "Aussetzer" mancher bis zum Exzess aufregen ist sicher nicht der Sinn der Sache.

Schlafen gehen werde ich aber erst später, ich hab noch ein bißchen zu arbeiten. Mit AmigaOS

Grüße

--
---

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

Zitat:

---

Original von DariusBrewka:

Zitat:

---

Original von bernd_roesch:
AROS nutzen kostet nix weil die Hardware schon vorhanden ist.wenn nicht ists trotzdem billiger als PPC

---

Dieses Kostenlose seit 6 Jahren erhältliche AROS hat diesen Typen, dennoch gehindert auch nur eine AROS Source Zeile zu schreiben, stattdessen "klaut" er AROS Code um als Retter von AOS68k aufzutreten.

---

Naja, es ist halt bedeutend leichter, auf bereits existierendem Code aufzusetzen als selbst was Fertiges zu zaubern. Irgendwie muß "man" sich ja richtig ins Licht setzen, so als "Macher" und so. Aus der Position heraus läßt sich ja auch leichter gegen die wettern, die zwar machen, das Gemachte aber nicht sofort und allen zur Verfügung stellen

Zitat:

---

Keine App vom Mister 68k für AROS und noch Peinlicher ist es sich hier so für AROS den Arsch aufzureissen, aber vor einiger Zeit auf meine Frage, warum er AB2 nicht auf AROS macht, zu sagen es lohne Sich nicht und wenn man einen vernünftigen 68K Emulator hat ist das auch garnicht nötig, ey wann merkt dieser nervige Type Endlich da man ihn nicht Ernst nimmt besser gesagt nahe am Kotzen ist?

---

Zitat:

---

Sorry für diese Sprache, aber jetzt geht die Selbe gesülze auch im Forum los. Das macht keinen Spaß (mehr).

---

Ist nicht böse gemeint, aber von der Schreibweise und Lesart her klingt das auch etwas nach Bernd

Grüße

--
---

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

Zitat:

---

Original von Andreas_Wolf:
@ Kronos:

> Escena hatte schon laaaaaaaaange vorher die Entwicklung eingestellt,
> und das war auch gut bekannt. So hatte Jürgen Haage das schon Monate
> vor der OS4-Ankündigung durch Hyperion verlautbart das er nie einen
> AOne gesehen hätte, und auch nicht mehr an den (Escena)-A1 glaubte

Exakt. Im Juni 2001 gaben Alan Redhouse und Jürgen Haage auf der Benelux Amiga Show bekannt, daß sowohl der Escena-AmigaOne als auch das AmigaOS4 noch sehr lange bis zur Fertigstellung brauchen würden. "Witzigerweise" gab McEwen am *selben Wochenende* im Rahmen der Ankündigungen zur Ende Juli 2001 stattfindenden AmiWest bekannt, daß dort der Escena-AmigaOne samt darauf laufendem AOS4 präsentiert werden würde. Er kündigte sogar die Enduser-Verfügbarkeit dieser Kombination für August 2001 an.

---

Zitat:

---

> eine Folge davon war das altbekannte "Party-On"

Nicht ganz. "Party on" auf ANN war die Folge von Jürgen Haages erhellenden Aussagen über Amiga Inc. in den Kommentaren zu einer News-Meldung hier Anfang Oktober 2001, also kurz vor der Übernahme des Projekts durch Hyperion und Monate nach seinen Aussagen auf der Benelux Amiga Show.

> Also wenn Hyperion im November 2001 noch wirklich an den Escena-A1
> geglaubt hat, dann war ihnen auch nicht mehr zu helfen...

Mit der Bekanntgabe der Übernahme von AOS4 Ende Oktober 2001 wurde der Escena-AmigaOne offiziell abgekündigt. Dies geschah beides innerhalb einer einzigen Pressemitteilung von Eyetech. Es gibt also definitiv keine zeitliche Überschneidung des Escena-AmigaOne-Projekts und des Hyperion-AOS4-Projekts.

---

Und genau das wollte ich u.A. mit meinem, in Kronos' Augen "konfusen", Post sagen.

Grüße

--
---

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

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

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.

Du müßtest also mit PEEKL arbeiten, so wie in den von Dir auskommentierten Zeilen.

In der C-Variante läuft es (wenn auch nicht ganz so, wie es da steht), und die Timer-Events kommen zur vorgesehenen Zeit, wenn man das alles richtig sortiert.

Ich setz mich am Mittwoch mal dran und bau Mad_Dogs Programm so weit um, daß das Timing korrekt läuft und es verhältnismäßig leicht in BASIC übersetzbar ist (das ist bei seinen Programmen meist das geringste Problem, schön sauber und lesbar gehalten, wie ich finde). Testen müßt ihr das dann aber, weil ich keinen Sampler habe

Morgen müßte ich ein bißchen Zeit finden, um den Goertzel mal zu "messen". Dann sehe ich, ob das überhaupt direkt funktionieren kann oder ob wir doch ein Array mit den gesampleten Werten brauchen.

Grüße

--
---

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

Zitat:

---

Original von Kronos:

Zitat:

---

Original von whose:

Bullshit. Du vergißt da ein gewisses Unternehmen namens "Escena".

---

Da der Rest ähnlich konfus ist reicht der Quote.

---

Soso. Ich würde eher sagen, daß Du den Rest verstanden hast und keine Argumente dagegen hast.

Eventuell solltest Du Dir den ganzen Verlauf der OS4-Geschichte nochmal genauer ansehen. Escena hatte einen nicht unbeträchtlichen Anteil an den Verzögerungen und Hyperion kam auch erst recht spät ins Gespräch bzgl. OS4. Bis zum Sommer 2001 war es noch reichlich unklar, wer dieses Projekt nun wirklich durchzieht bzw. wer überhaupt noch Lust dazu hat.

Grüße


--
---

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

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
@MaikG

Guggst Du!

code:

---

POKEL tr& + tr_time% + tv_secs%, mysecs& REM und so!
POKEL tr& + tr_time% + tv_micro%, mymicros&+125&

---

---

Äh, schon mal daran gedacht, dass beim Addieren der µs ein Überlauf stattfinden könnte?

---

Zitat:

---

Und da TimeVal keine einfache 64-Bit-Zahl ist, sondern der µs-Wert nur bis 1Mio gehen darf, ist das Zusammenzählen auch keine triviale Addition. Man sollte einfach AddTime() benutzen. Ich hab's in meinem C-Programm benutzt, und es läuft. Na ja, bis auf die Tatsache, dass es insgesamt zu langsam läuft... Aber, nebenbei gesagt, mit anderen Zeitintervallen kann es durchaus auch zu schnell laufen, ganz wie Du meintest...

---

Und das ist es, was ich nicht verstehe... ich hab nun einiges mit den Timern gemacht und gerade bei diesen kleinen Zeiträumen keine großen Probleme mit der Genauigkeit der Timer gehabt. Bei größeren zu messenden Zeiträumen sieht das schon anders aus, ganz genau so, wie es in den RKMs beschrieben ist. Naja, noch ein bißchen mehr testen und suchen, würde ich sagen...

Grüße

--
---

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

Zitat:

---

Original von bernd_roesch:

hier mal OS4 wie es geschah.

---

Zitat:

---

OS4 wurde 2001 angekündigt.6 monate später sollte es auf cybppc erscheinen.Heute noch nix.aber ainc ist ja schuld gelle.

---

Zitat:

---

april 2002 war schon die aone Hardware erhältlich.Das ist die Hardware die die meisten User haben(siehe aone Umfrage ca 600 der 800 die daran teilnahmen).
aber es kam kein OS4 dazu.Das sollte nachgeliefert werden.Weihnachten hies es damals.
Dann kam kurz vor Weihnachten die Nachricht bis dahin wird es nix,aber OS4 soll zur cebit 2003 präsentiert werden.

---

Zitat:

---

also wartete man.kurz vor der cebit wurde es abgesagt.Dann hoffte jeder vor Weihnachten.
Kurz vor Weihnachten 2003 wurde gesagt ein prerelease ist fertig kommt evtl noch vor Weihnachten oder kurz danach.
Aber dann wurden Probleme mit dem pressen genannt.So dauerte es bis juni 2004.Dann gab es das erste pre1.Das war total lahm.
benutzbar war OS4 ca ende 2004.allerdings stand in der computerzeitschrift CT sogar drin,dass OS4 ende 2004 final kommen sollte.
danach wurde OS4 nie mehr in der Ct erwähnt.scheinbar wollten sich die Redaktuere nicht weiter verschaukeln lassen.

---

Zitat:

---

dann kam glaub ich anfang 2005 die micro aone hardware bis sich eyetech dann zurückzog.nicht verwunderlich wenn man die Zahlen der aone umfrage sieht.

---

Zitat:

---

>Hätten Hyperion nichts gemacht, wäre der Markt exakt genauso vor die Hunde gegangen.

mit Sicherheit nicht.Dann wäre AROS weiter und es gäbe mehr apps.schon ein grösserer anreiz für neue.
Da es weniger kostet AOS zu nutzen hätte man auch logischerweise mehr User.

---

Zitat:

---

Das ist genauso wie man ein altes leistungsmässig unterlegenes prog für 10 Eur öfter verkaufen kann wie dasselbe für 100 Eur.
PPC ist schlicht zu teuer für das was es leistet.

---

Und was hat das wieder mit AROS zu tun? Abgesehen davon, daß sich mir der Sinn des Ganzen nicht so wirklich erschließt... was ist denn noch teurer, aber noch besser? Coldfire?

Zitat:

---

>Da muß der Frust dann raus, und anscheinend haben viele der "Berufsmeckerer" hier den Weg des "Hyperion-Bashing" zum Frustabbau ausgewählt.
>Zwar nicht besonders fair und meist auch weit an den Tatsachen vorbei, aber anscheinend befreiend.

Das ist bei mir mit Sicherheit nicht so.An OS4 gibts derzeit eh nix intresantes an Soft.

---

Zitat:

---

Was mich an PPC stört, ist dass es die weiterentwicklung von AOS Soft gebremst hat.Bars&Pipes hat in den letzten Jahren featuremässig fast nix zugelegt
weil es nur portiert wurde.

---

Aha... da hat der PPC die Weiterentwicklung gebremst, weil z.B. B&P erst portiert werden mußte... das wäre bei AROS x86 natürlich nicht nötig, hm?

Zitat:

---

Na gut nahm ich halt hd.rec.Aber da wollte der Author auch später dass es auf MOS OS4 läuffähig ist mit native effekten obwohl er keinen PPC Rechner will
weil es ein paar wenige User gab die es da nutzen wollten.Tja und somit hat es da die Entwicklung auch gebremst.Ohne PPC OS hätte ich AOS Soft mit mehr Features
weil PPC OS einen hohen portieraufwand erfordert.

---

Darüber hatten wir uns schon mal unterhalten. Der Aufwand ist nicht annähernd so hoch, wie Du weismachen willst. Was ist den z.B. mit PfP, da hattest Du genauso gejammert, daß das hoher Aufwand wäre. Blackbird scheint die Sache aber inzwischen etwas anders zu sehen.

Ich sehe das sowieso anders, weil ich nicht auf AmiBlitz angewiesen bin, sondern GCC/VBCC nutzen kann. Merkwürdigerweise habe ich da sehr wenig Mehraufwand wegen OS4... durch den Compiler damit, fertig. Eventuell hier und da etwas nachbessern, weil ich zu hart mit Registern und Zeug und wa gearbeitet habe, aber das wars dann auch.

Bei B&P liegt die Sache sogar noch anders, aber da solltest Du Alfred mal zu befragen, statt wieder erstmal Mutmaßungen von Dir zu geben. Eventuell dauert es so lange, weil er neue Features einbaut?

Zitat:

---

Durch die ganze portiererei kam AOS Soft zu windows Soft noch weiter ins hintertreffen

---

Zitat:

---

Und wenn es jetzt eh keine Hardware für PPC mehr gibt und es nicht weitergeht war die Zeitverschwendung für die Katz.

---

Zitat:

---

eyetech und ainc haben wenigstens ehrlich gesagt es lohnt nicht sie machen nix mehr.Nur das ganze hingehalte mit warten auf neue Hardware muss doch nicht sein.

---

Zitat:

---

Entweder es besteht tatsächlich aussicht auf neue HW schön,aber den usern jahrelang nur vorgaukeln es kommt was ist nicht nett.

---

Zitat:

---

>Um das nochmal klarzustellen: Es war sonst keiner mehr da, der irgendwas hätte machen wollen.
>Es war ja nicht so, als hätten Hyperion massenhaft Mitbewerber ausgestochen.

Aros war da und es lief auch schon ein wenig.Genesi war da und sie waren weiter mit MOS.Aber bei OS4 wurde immer angekündigt dass es bald kommt.Wenn die bei OS4 ehrlich gewesen wären
vor 2004 ist eh nicht mit OS4 zu rechnen,wären die User zu Genesi gegangen.Und das wollten sie mit unseriösen Marketing vermeiden.So kam es das
jeder seit 2002 mti einem OS4 rechnete.Aber nun kommen tatsächlich welche und sagen man hätte es gewusst dass es solange mit OS4 dauert.

---

Zitat:

---

Das soll wohl ein Witz sein.Wenn nicht,dann lest euch doch einfach mal die Kommentare von damals durch.Es waren genug dabei die sagten OS4 käme nie zu dem
Zeitpunkt.Die wurden dann als Trolle abgetan.Heute weis man dass diese Leute recht hatten.Also dass alle wussten wie lange sich das hinzieht stimmt so nicht.

---

Zitat:

---

Jeder hatte geglaubt dass es bald kommt.Es muss ja nur AOS auf dem Aone laufen.dazu braucht es keine jahrelange Sysiphus arbeit.

---

"Nur auf dem AmigaOne laufen"... das muß man sich auf der Zunge zergehen lassen. Es hat sogar noch um einiges länger gedauert, bis man entdeckte, daß der Onboard-Sound bei den SEs doch funktioniert. Dank der tollen Dokumentation zur Southbridge...

Aber nichts desto trotz hast Du eine Menge verpaßt... die Kommentare bezüglich der sicheren Verspätung von OS4 wurden schon zu einer Zeit abgegeben, als vom heutigen AmigaOne noch gar keine Rede war. Damals war noch das Escena-Board aktuell.

Es ist wie immer mit Dir: Läufst Du mit einer wirren Argumentation ins Leere, stellst Du flugs eine noch wirrere auf, um Recht zu behalten. Eventuell wäre die Zeit besser genutzt, wenn Du den AB-Compiler CPU-unabhängig implementierst. Dann kann das Nachfolgesystem PPC oder x86 sein, egal, AB läuft und macht keinen Ärger. Das wäre endlich mal das, was DU von allen anderen forderst: Neue Software mit echtem Nutzen.

Grüße

--
---

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

Zitat:

---

Original von Maja:
@cgutjahr:

> Es ist nur eben emotional ein bisschen anstrengender, weil man
> jetzt zum ersten Mal seit Commodores Pleite etwas wirklich
> greifbares vor Augen hat (nicht nur eine Ankündigung, ein Gehäuse-
> Design o.ä.) und trotzdem noch nicht rankommt.

Sag, kannst Du Dich noch an die Specs für den "NG-Amiga" erinnern? Oder AmigaOS 5.0? Meine Fresse, was waren wir doch begeistert.

---

Oder, etwas früher, den Amiga5000 und Amiga6000?

Zitat:

---

Und kannst Du Dich erinnern, dass Jeff Schindler, Bill McEwen, Jim Collas oder Thomas J. Schmidt je so "gesteinigt" wurden, nachdem jede dieser und andere tolle Ankündigungen, ohne jede weitere "Informationspolitik", einfach so im Sande verliefen, von anderen abgelöst wurden, die ebenfals im Sande verliefen? Ich nicht. IIRC gabs ein kurzes Raunen und dann gings zur Tagesordnung über....

---

Zitat:

---

Und BBRV? Scheint auch alle Wurst zu sein, dass denen MOS jetzt Banane ist. Oder wurde das einfach nur überlesen?

---

Nein, es zeigt eigentlich nur, daß an MOS nicht das selbe Interesse hängt wie an OS4.

Grüße

--
---

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

Zitat:

---

Original von MaikG:
>Die hat aber mit der eigentlichen Timerfunktionalität wenig zu tun.
>Das ist den IORequest anlegen, timer.device öffnen etc. und wird nur
>einmal vor der Verwendung des timers durchlaufen.

Ja, aber das ist schon alles was mit den Timer zu tun hat
und ich sehe keinen Fehler.


>Wenn alle Stricke reißen, werden wir wohl doch den Weg mit der
>direkten Timer-Benutzung gehen müssen (CIA übernehmen und einen der
>Zähler direkt nutzen) und dann schauen, was dann passiert.

Ich find das mit den CIA ja nicht schlimm, oder ist das sehr
schwer? Ich mein, das ist sicherlich nicht AONE/Peg kompatibel
aber man hat ja beim CIA Timer die man legitim benutzen darf.

Ich wollte grade gucken wieviele, da sehe ich in Scout
das dieses Programm 251518:46'50.38 anfordert über die MicroHZ Unit.
Zum Vergleich bei Aweb steht 0:00'00.44 MicroHZ.

Kanns sein das es da noch eine Minutenvariable gibt die Initalisiert
werden muss?

---

Öhm... ich seh grad, folgende Zeile:

POKEL tr& + tr_node% + tv_secs%, mysecs& REM und so!

muß so lauten:

POKEL tr& + tr_time% + tv_secs%, mysecs& REM und so!

Ich hab das heut mittag im Tran getippt, da ist mir dieser Fehler unterlaufen. Wenn wir tr_node verändern, geht das natürlich schief. Sch...-Sektparties immer Sorry nochmal.

Grüße

--
---

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


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

Zitat:

---

Original von DariusBrewka:
@whose

Ich werde das wohl temporär mit IFF und Datatypes machen, irgendwie will ich auch nicht vorraussetzen, daß sich die Leute irgendwelche glues installieren, dazu ist das nicht so wichtig bzw. der ist ja nur nötig um von PPC auf 68k libs zuzugreifen, also wird das kaum ein Programm so nutzen.

Dennoch danke.

---

Jo, kein Thema. Ich machs trotzdem mal morgen. Gebrauchen kann man das mit Sicherheit irgendwann irgendwie. JPEG speichern kommt ja doch öfter mal als Anforderung vor, da macht eine Library irgendwo schon Sinn. Den Glue-Code braucht man ja nur nach LIBS: zu kopieren, genau wie die jpeg.library selbst, das dürfte niemanden überfordern

Weißt Du zufällig, obs die Quellen zur jpeg.library irgendwo gibt? Dann könnte man drangehen, die nativ (eine gute Fingerübung wäre das allemal) für die PPC-OSse und AROS zu machen.

Grüße

--
---

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

Zitat:

---

Original von DariusBrewka:
Ich will einen Standardweg haben, nicht irgendwelchen Code selberschreiben oder Fremdcode benutzen.

---

Zitat:

---

Das blöde ist immer das Testen, wenn man völlig verschiedenen Code für die Unterschiedlichen Plattformen schreibt und nicht selber diese Plattform besitzt.

---

Das ist eigentlich das geringste Problem. OS4 kann ich Dir testen oder viele andere auch. Für MOS findet sich sicher auch jemand, falls Du das auch nicht selbst haben solltest.

jpeg.l.main habe ich noch nicht "erschlagen" können, werde heut auch wohl erst spät zu Hause sein. Ich kann mich aber dunkel entsinnen, daß es dazu noch keinen Glue Code gab, also wird sich da jemand dransetzen müssen. Gemacht habe ich das noch nie, also wärs mal an der Zeit

Morgen gegen Mittag/früh Nachmittags kann ich Dir dann mehr dazu sagen, falls Dir das nicht zu spät sein sollte.

Grüße

--
---

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