Zitat:

---

Original von xXSoul-Reaver-2006Xx:
Nein ein 68K-Version von TurboPrint hab ich nicht, schade ich glaube hier komme ich auch nicht weiter, man kann nur hoffen das Hyperion neue Treiber in der OS 4.2 enthält, den ein Aktuelle Drucker Treiber ist genau so wichtig wie ein Office die wir auch dringend benötigt.

---

Leider ist die Wahrscheinlichkeit dafür nicht so besonders hoch... die höchste Wahrscheinlichkeit haben so halb-aktuelle HP-Treiber, wobei auch das nicht so einfach werden dürfte. Wir haben es mit Insane-Software mal versucht, um wenigstens einige der moderneren Photosmarts mit Treibern auszustatten, die wirklich alle Funktionen nutzen können.

Nun ja, unter 50000 EUR Jahresumsatz und "Hose runter in Sachen Geschäftsführung" ist da wenig zu machen... oder man braucht heftig Vitamin B.

Bei den anderen Anbietern wie Epson oder Canon siehts noch düsterer aus, die möchten sogar über Betriebsgeheimnisse informiert werden, bevor sie Treiberinfos herausrücken. Nicht wirklich diskussionswürdig, wie ich finde.

Einzige Lösung ist mal wieder, bei OpenSource zu "spionieren", allerdings halten sich die Anbieter auch dort sehr bedeckt. Es gibt nur wenige Treiber, die die modernen Geräte wirklich voll ausnutzen und gerade bei denen wird wiederum mit closed source gearbeitet...

Es bleibt schwierig, aber man soll die Hoffnung nicht aufgeben.

--
---

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

Zitat:

---

Original von tploetz:
Ich habe in Prefs/WbStartup ftp entfernt und in der user-startup eingegeben "mount ftp:"
ftp befindet sich in Storage/DosDrivers.
Jetzt wird dann das Icon von ftpmount angezeigt.

---

Das klingt aber so, als hättest Du Deine ftpmount-Installation mächtig verwurstet.

Bei einem manuellen "Mount ftp:" sollte es z.B. keinerlei Unterschied machen, ob sich das FTP-Icon in Storage/DosDrivers befindet oder in DEVS:DosDrivers. Der Ablauf und die Funktion ist identisch, es sei denn, Du hast in Storage/DosDrivers eine andere Mountlist verwendet als in DEVS:DosDrivers.

Du sagtest aber, es würde nicht gemountet, wenn es sich in DEVS:DosDrivers befindet, was darauf hinweist, daß irgendetwas an Deiner FTP-Mountlist, die sich dann dort befindet, nicht hasenrein ist.

Aber solange wir nicht wissen, was genau Du da veranstaltet hast, können wir Dir kaum helfen. Schon gar nicht, wenn Du immer so sparsam mit Informationen bist.

Also, wird die exakt gleiche Mountlist, die sich in Storage/DosDrivers befindet und per "Mount" gemountet wird, in DEVS:DosDrivers tatsächlich nicht gemountet? Oder hast Du etwa zwei unterschiedliche Mountlists auf Deiner Workbench rumgeistern?


--
---

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

Zitat:

---

Original von AmigaHarry:
BTW: Ich finde es auch sehr beeindruckend wenn man sich mal die Leistung eines SCSI im Pegasos (Symbios-UltraWide-LVD) gegenüber dem IDE ansieht.....da kommt richtig Freude auf.....

---

Och, nicht nur da... ich habe so ein Spielchen mal mit einem relativ kleinen, aber relativ aktuellen PC (Sempron 3000+) abgezogen... Adaptec UW-LVD-Controller rein und eine relativ alte 19GB-IBM-UW dazu... da hättest Du ein paar Augen (die des PC-Besitzers) glänzen sehen können, kein Vergleich zu vorher! Der bootete dann sogar unter einer Minute, ich hab selbst gestaunt

Ich möchte nicht wissen, wie heftig das dann im Peg mit ner LVD-Platte abgeht

Und bei nem A1200 geht sowieso nichts über SCSI... egal, welche Art von IDE-"Beschleuniger" man reinpömpelt, das Blizzard-SCSI-Kit schlägt das immer noch. Ich möchte meins jedenfalls nicht missen, auch wenn der IDEFix Express dem internen IDE ziemlich Beine macht. Trotzdem sieht der keine Sonne gegen den SCSI-Strang
--
---

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

Zitat:

---

Original von Bluebird:
@whose: ich schreib 40 > , was allgemein bedeutet 40 und heoher ... dazu bei einer 40er und 60er wird die fpu meist vorrausgesezt und findet so meghr nutzen !

---

Zitat:

---

bei einem 30er nuzt die einfach nichts , nichts was man wie ich schrieb mit der stopp uhr messen koennte , auser man betreibt einige gfx lastige sachen oder gleich einen rautracer wobei mir da jeder leid tut der nicht wie schon geschrieben eine 40er oder 60 er hat !

---

Zitat:

---

dazu kommt das die fpu der 30er relativ gesehen eine kruecke ist im vergleich zur onboard fpu der 40/60er ...

---

Zitat:

---

wer unbedingt eine haben muss um zu sagen er hat alles was man fuer geld kaufen kann solls sich dran aufgeilen aber wirklichen nutzen kann ich beim besten willen siehe ausnahmen oben , nicht sehen

---

Das Gleiche könnte man bei einem 68EC040/25 statt eines 68030/50 im A1200 sagen...

Der Thread-Eröffner hatte gefragt, was er auf die Blizzard noch "drauffummeln" könnte, um da quasi alles Machbare gemacht zu haben. Eine FPU gehört definitiv dazu. Und es ist halt keineswegs dumm, da eine draufzustöpseln
--
---

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

Zitat:

---

Original von Bluebird:
ein scsi kit vielleicht aber sonst ?

---

Zitat:

---

sei bloss nicht so doof da noch ne FPU verbauen zu wollen !
ohne scheiss wenn mich eines bis heute reuht dann die tatsache das ich je an einer 30er karte eine fpu verbaut hab , das geld haette ich leichter versoffen

---

Zitat:

---

sorry aber FPU ist toll solange sie in einem gescheiten prozzesor wie 40 > steckt ...

---

Zitat:

---

an einem 30er nuzt kaum eine software das ding aus und wenn wie zb bei den image dekodern von ibrowse , kann man den vorteil nicheinmal mit der soppuhr messen also

---

Software, die keinerlei speziellen FPU-Code enthält, nutzt selbstverständlich nicht die FPU aus. Wie sollte sie?

Die mathe-Libraries des OS hingegen nutzen eine FPU, sofern vorhanden. Das beginnt bereits mit dem 68020 und endet noch längst nicht beim 68040.

Ums mal etwas drastischer zu sagen: Auch Dir nutzt ein 68040 überhaupt nichts, wenn Du darauf hoffst, daß die integrierte FPU irgendetwas beschleunigt, wenn sie gar nicht genutzt wird.

Noch dazu solltest Du wissen, daß die FPU vor allem das beschleunigt, was in ihrem Namen enthalten ist. Fließkomma-Berechnungen. Bei Integer-Berechnungen, wie sie oft bei Image-Decodern vorkommen, bringt eine FPU nicht wirklich viel. Messen kann man den Unterschied bei Fließkomma-Berechnungen hingegen schon.
--
---

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

Zitat:

---

Original von tploetz:
@whose:
bei Problemen lässt sich pfs3 leichter reparieren mit pfsdoctor,
sfs hst kein Reparaturprogramm.

---

Hmm, manchmal könnte man meinen, Du willst nur das verstehen, was Dir aktuell in den Kram paßt... man hat Dich doch auf SFSSalv verwiesen, das Bestandteil des SFS-Archivs ist. PFSDoctor macht ziemlich genau das Gleiche wie SFSSalv. Technisch sind sich PFS und SFS gar nicht so unähnlich, wie manche Leute meinen. Das PFS noch (bzw. nur) TD64 unterstützt sagt letztendlich nur aus, daß die Entwicklung stehen geblieben ist, nicht mehr, nicht weniger.

Fakt ist, daß es über die Jahre hinweg immer wieder Berichte über beide Filesysteme bezüglich "ungültige Partitionen" und "nicht behebbare Fehler" gibt.

Was Du jetzt tun kannst ist, Deine Daten zu retten und Dein System auf PFS3 umzustellen. Ob Du damit und mit Deiner wackeligen Hardware dann besser fährst, wird die Zeit zeigen. Ich habe nur gesagt, daß ich an diese Möglichkeit nicht glaube, eben weil PFS auch so seine Macken hat, die ich selbst erfahren durfte.

Und jetzt hör bitte auf hier ständig nur rumzujaulen, das PFS doch so viel besser ist. Richte es auf Deinem System ein und werde glücklich damit. Oder auch nicht. Je nach dem. Vielleicht hast Du ja Dusel und es läuft dann einwandfrei. Vielleicht aber auch nicht.

Ich frage mich sowieso, was Deine ständigen Einwürfe ala "PFS ist aber besser" hier bringen sollen. Bei Deinem Problem hilft das nicht wirklich weiter und die Wiederaufnahme der Entwicklung von PFS wirst Du so sicherlich auch nicht erreichen.

Dazu müßtest Du in niederländischen Foren weiterjammern, wobei ich jedoch nicht glaube, daß es die Firma, die PFS damals entwickelte, heute noch interessiert. Falls die überhaupt noch existieren und sich mit Amiga irgendwie beschäftigen, heißt es...
--
---

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

Zitat:

---

Original von Maja:
Jetzt verallgemeinerst Du aber kräftig.

---

Nö. Das ist schlicht eine Erfahrung, die ich im Alltag gemacht habe. "Mal eben intuitiv" eine CD brennen kann fürchterlich in die Hose gehen. Im Grunde wollte ich die ganze Zeit sagen, daß es immer etwas zu verbessern gibt

Zitat:

---

So lange nicht Daten mit Audio (wav) und/oder unkommprimiertem Video gemischt werden, geht da auch nichts schief. Gleiches gilt für das Einhalten des max. Fassungsvermögens des Datenträgers.

---

Jetzt verallgemeinerst Du aber kräftig Es gibt durchaus noch ein paar andere "Gelegenheiten", bei denen das Brennen schiefgeht. Seis drum.

Das eigentliche Thema des Threads haben wir ja schon mal geklärt und tploetz kann nun auch Daten-CDs mit MakeCD brennen.

Nun muß sich "nur noch" eine Lösung für das individuelle Anordnen der Dateien finden und eine Anregung haben wir dank Dir ja schon mal
--
---

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

Zitat:

---

Original von Maja:
Wenn Dateien wie Archive, Bilder, Dokumente und Binaries als Mode 2 Form 2 gebrannt werden und oder Datenträger kein Lead-Out haben, könnte das auch am Einstellungsübereifer des Nutzers liegen.

---

Oder einfach nur an den Standard-Einstellungen des intuitiven Brennprogramms. Ich habe lange gebraucht, um der Dame klarzumachen, das es keine gute Idee ist, Dateien "einfach so" in das Fenster zu ziehen, wenn vorher schon welche drin waren, weil der erste Brennversuch "intuitiv" schiefging. Aber nunja, es war halt intuitiv richtig...

Zitat:

---

Zitat:

---

Original von tploetz:
Hallo,
ich finde, wenn man eine Audio-CD brennen will, ist MakeCD sehr gut. Unter "Image-Dateien anhängen" kann man ein ganzes Verzeichnis auswählen mit Audio-Dateien, indem
die linke Maustaste gedrückt gehalten werden muss, können mehrere Dateien ausgewählt werden. Die können dann mit "Hoch"auch sortiert werden.

---

Und die Datein werden dann auch in der so geänderten Reihenfolge auf CD gebrannt? Das wäre afaik echt mal was auf Amiga, was es anderswo so nicht gibt.

---

Naja... im Groben werden die "Dateien" schon in der geänderten Reihenfolge gebrannt, was an sich ja nicht schlecht ist. Blöderweise behandelt MakeCD diese "Dateien" in diesem speziellen Fall als Track-Images, was den von Dir erhofften Vorsprung etwas relativiert

Audio-Tracks werden ja auch anderswo immer nur in der angegebenen Reihenfolge und nicht alphabetisch sortiert nach dem Namen der Quelldatei auf Audio-CDs gebrannt.

Nichts anderes macht die von tploetz beschriebene Funktion. MP3-Dateien, die in diesem Fall Track-Images darstellen, auf eine Audio-CD bannen. In der Reihenfolge, wie sie im ISO-Einstellungen-Fenster angeordnet wurden.

Bei den Dateien als solchen muß ein externes Programm nachhelfen und ich glaube nicht, daß dieser Komfort noch in MakeCD eingebaut wird. Kann man aber als Anregung für künftige Brennprogramme aufnehmen, finde ich.
--
---

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

Zitat:

---

Original von Maja:

Zitat:

---

Ich finde, MakeCD ist für das Brennen von CDs nach wie vor das Spitzenprogramm auf dem Amiga. Extrem systemkonform geschrieben (läuft auf allen Plattformen, die 68k-Emulation bieten, sogar unter WinUAE kann man damit problemlos brennen!), sehr schnelles und kompaktes GUI und nach einer gewissen Eingewöhnungszeit gut zu bedienen.

---

Das ist richtig, aber nur deshalb so, weil es bis heute auf dem Amiga an adäquaten Alternativen mangelt, die ebenso kompatibel und gleichzeitig intuitiver bedienbar sind.

---

Zitat:

---

Zitat:

---

Problem ist halt nur, daß diese Forderungen von keinem Brennprogramm wirklich erfüllt werden, nicht mal unter Windows

---

Per Wizzard die gewünschte Datenträgerart auswählen, Verzeichniss bzw. Dateien vom Quellverzeichnis ins Zielverzeichnis ziehen und den Brennvorgang starten. Das kann wohl jeder ohne deswegen vorher eine Anleitung gelesen zu haben. Dass man darüber hinaus wenigstens ein bisschen was über CD, DVD, Daten, Audio, Video und Multisession wissen sollte, tut der intuitiven Bedienbarkeit eines Programms keinen Abbruch.

---

Ich habe ehrlich gesagt schon besser gelacht. Schau Dir mal die Ergebnisse an, die die ach so intuitiv bedienbaren Brennprogramme öfter mal fabrizieren. Fehlende Finalisierung ist nur ein Ärger, mit dem man öfter zu tun bekommt. Interessant wirds auch, wenn aus Daten-CDs von diesen Programmen Mode-2-CDs gemacht werden. Gar nicht so einfach, an diese Daten wieder heranzukommen. Mit den Windows-Brennprogrammen übrigens nahezu unmöglich (ich habe keinerlei Möglichkeit gefunden, aus dem Mode-2-Track einen Mode1-Track zu machen, so daß die "verhunzte" CD wieder mit normalen Mitteln lesbar ist), mit MakeCD hingegen schon

Zitat:

---

Zitat:

---

Sofern man den Quellpfad mittels des bewußten Häkchens nicht ausdrücklich zu ändern wünscht, werden die Quellpfade ins ISO geschrieben und nichts anderes.

---

Was die Frage aufwirft, wozu es dieses "bewußte" Häcken bei der Auswahl überhaupt gibt. Wenn die Quellpfade einzelner Dateien in einem älteren ISO nicht mehr stimmen, betrachte ich es als Aufgabe des Programms, den Benutzer darauf hinzuweisen und für die betreffenden Dateien zur Auswahl der aktuellen Quelle auffordern. Zumal man als Benutzer nach Wochen oder Monaten ggf. gar nicht mehr weiß, welche Dateien einer umfangreichen Auswahl sich nicht mehr im ursprünglichen Zielpfad befinden.

---

Zitat:

---

Zitat:

---

Weiß gar nicht, ob MakeCD nen ARexx-Port hat, aber wenn, wäre das eventuell die Lösung für sein Problem.

---

Für dieses Vorhaben wäre es - mit Blick auf das oben verlinkte Beispiel aus der Windows-Welt, sinnvoller, wenn AmiAmp einen ARexx-Port hätte.

---

AmigaAMP hat einen ARexx-Port...

Ich habe nur schon ein bißchen weiter gedacht, nämlich an direkten Import einer Playlist in MakeCD, mit wahlweiser Übernahme der aktuellen Titelsortierung in AmigaAMP & Co. bzw. ein Hilfsprogramm, welches einem die Zusammenstellung einer Dateiliste sowohl unter Zuhilfenahme diverser vorgegebener Sortierungen als auch "wie geklickt" ermöglicht.

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 08.02.2010 um 17:55 Uhr geändert. ]

Zitat:

---

Original von Maja:

Zitat:

---

Original von whose:
MakeCD hat eher das Problem, daß man sich an die Denkweise der Autoren erst einmal gewöhnen muß, bevor man das volle Potential von MakeCD erkennt.

---

Das Problem hat nicht MakeCD, sondern deren Nutzer.

---

Zitat:

---

Programmierer sollten sich doch eher auf die Denkweise der Nutzer einstellen, statt von Nutzern zu erwarten, zu erraten, was sich der Programmierer dabei gedacht haben mag. Es sollte nicht nötig sein, eine Dokumentation zu wälzen, nur um ein paar Dateien auf CD zu brennen.

---

MIR mußt Du das nicht sagen, ich weiß das Problem ist halt nur, daß diese Forderungen von keinem Brennprogramm wirklich erfüllt werden, nicht mal unter Windows

Zitat:

---

Mehrfachauswahl plus Drag'n Drop, nebst autmatischer Übernahme der Dateipfade (Quelle) hätten MakeCD sicher nicht geschadet und wären bei dem Preis damals wohl auch nicht zu viel verlangt gewesen. MakeCD ist ein prima Tool, nur leider ziemlich, na ja, "lernintensiv". Da muss nicht jeder Freude dran haben. Just my two cents.

---

Zitat:

---

So eine "willkürliche" Sortierung ist auf jedem System problematisch. Doch auch dafür gibt es ansich simple Lösungsansätze: http://www.mpex.net/info/genyar.html ( <- leider nicht für Amiga). Wäre doch mal eine Aufgabe für einen ARexx-"Scripter"?

---

Hm, die Idee ist nicht schlecht... zwar eigentlich leicht "ugly" vom Standpunkt der Vertreter der "reinen ISO-Lehre" aus betrachtet, aber irgendwo doch clever. Hätte ich eigentlich auch drauf kommen können

Mal sehen, ob man tploetz mit einem solchen Hilfsmittel weiterhelfen kann. Weiß gar nicht, ob MakeCD nen ARexx-Port hat, aber wenn, wäre das eventuell die Lösung für sein Problem.

Ansonsten müßte man ein kleines Hilfsprogramm bauen, daß eine Dateiliste erstellt, in der die Zielpfade nach der dortigen Methode "umgebaut" werden (so braucht man kein temporäres Verzeichnis mit Platz für umbenannte MP3-Dateien).

Wenn man das Hilfsprogramm entsprechend "zurechtstrickt" stellt auch Mehrfachauswahl kein wirkliches Problem mehr dar...
--
---

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

Zitat:

---

Original von Holger:
@xXSoul-Reaver-2006Xx:
Die Endung .c steht i.A. für die Programmiersprache C und die Endung .cpp für die Programmiersprache C Plus Plus. Da gibt's für AOS4 gcc und sonst nichts.

---

Hm, bei .cpp muß ich Dir zustimmen. Da gibst wohl nichts anderes als gcc

Bei .c jedoch nicht, denn da gibts dann noch vbcc, und der ist sicherlich nicht schlechter für C-Code geeignet als gcc. Eher noch besser, weil nicht so monströs aufgepumpt und resourcenhungrig. Und der erzeugte Code ist ebenfalls sicher nicht schlechter, in manchen Bereichen m.E. sogar noch etwas besser als der vom aktuellen gcc erzeugte.

Nachtrag: Ok, im Fall dieses "game-editors" gibts nur gcc, sonst nichts. C und C++ Code gemischt, ist ja gruselig...
--
---

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


[ Dieser Beitrag wurde von whose am 05.02.2010 um 20:51 Uhr geändert. ]