Zitat:

---

Original von DirkR:
@Yvan:

Hab ein par weitere test vorgenommen.
Texte über Editor und ko kommen.
Beim ersten mal hatte ich PDF's probiert .
PDF's gehen nicht mehr .

---

Hm, sehr seltsam... ich war gerade quasi gezwungen, ein PDF zu drucken... ging auch reibungslos. Sieht zwar nicht so schön aus (recht grob gerastert eigenartigerweise), aber es hat geklappt? Hab den Workbench-Treiber in AmiPDF gewählt.

Nachtrag: So, noch mit PS-Ausgabe probiert... 1A. Eigenartig, daß es bei Dir nicht funktioniert.
--
---

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


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

Zitat:

---

Original von gerograph:

2) aus dem Notepad funktionierts nicht, bekomme aber auch keine Fehlermeldung ? (Workbenchdruckertreibereinstellungen ist Postscript und netprinter.device eingestellt)

---

Zitat:

---

3) sollte nicht ein

> echo "drucktest" >prt:
oder
> echo "drucktest" >par:

die Zeile "drucktest" auf dem Drucker ausgeben ? Bei mir nicht, bekomme auch keine Fehlermeldung.... ebenso kann ich keine Asciidatei z.B. mit

> copy ram:test.txt par:
oder
> copy ram:test.txo prt:

ausdrucken ! Brauche ich eine prt mountliste ?

---

Zitat:

---

Ich meine (!) bei upd2 ging alles....

---

Gut möglich... bei Update 3 wurde ja noch einiges an den Interna geschraubt, da kann durchaus etwas nicht mehr so ganz astrein laufen, was unter Update 2 noch einwandfrei lief. Und umgekehrt.

Wie gesagt, hier tuts mit lpr.device einwandfrei in Sachen PostScript. Sogar besser als je zuvor.


--
---

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

Zitat:

---

Original von Yvan:
@whose:

Freut mich für dich

Hab ich das richtig verstanden? Du druckst über's Netz aber nicht mit dem netprinter.device sondern mit dem lpr.device?

Dirk druckt über's Netz mit dem netprinter.device und hat das gleiche Problem wie ich.

Ich hab meine SAM gerade nicht vor mir. Das lpr.device ist standardmässig drauf? Dann probier ich es mal mit dem.

---

Nein, das findest Du hier.

Schau aber trotzdem nochmal nach den Printer-Prefs, wie ichs in meinem letzten Beitrag angedeutet hatte. Gut möglich, daß da was nicht so ist, wie es sein sollte.
--
---

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

Zitat:

---

Original von Yvan:

Eher ein Postscript Problem. Nun fragt sich, was hat sich mit dem Update3 in Sachen Postscript geändert?

---

Gute Frage... ich werde gleich auch mal experimentieren, ich benutze einen LaserJet4M/Plus hier, der ist PS-fähig und hängt über Netz an den Computern.

Wenn ich hier auch Probleme bekomme, liegts am PS-Treiber der WB (dann ists Zeit für einen Bugreport bei Hyperion, der mal nichts mit USB zu tun hat ). Kriege ich über Netzwerk den Ausdruck ohne Fehler hin, dürfte das usbprinter.device wohl die Daten durcheinanderwürfeln...

Edit: Hm, wenns ein PS-Problem ist, dann aber ein sehr subtiles. Ich benutze lpr.device, jetzt auch auf dem SAM440ep, und es tut einwandfrei tuten tun, Text wie auch Grafik. Keine Fehlermeldung vom Drucker, und sogar Multiview möchte nun endlich problemlos drucken (ging auf dem Micro irgendwie nicht).
--
---

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


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

Zitat:

---

Original von Blackbird:
Hast ja Recht Wolfgang....
Da BS aber intern auf 640x480 eingestellt ist wird wohl nix passieren in der von dir beschriebenen Art, denn wenigstens ein Screenmode wird wohl bei jedem Rechner vorkommen

Zumindest werde ich beim nächsten Game (falls ich jemals nochmal was derartiges mache) daran denken und darauf Rücksicht nehmen...

Ich denke mal dieser Thread ist dann bis 2030 erstmal gegessen

---

Meinste, dann kommt einer mit nem 64"-Monitor an?
--
---

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

Zitat:

---

Original von Blackbird:

Ach ja, Wolfgang hat übrigends Recht mit seiner Aussage das BestmodeID nicht crashen kann, sondern nur in den nächst höheren oder einzigen Screenmode fällt bzw. den dann bereitstellt....

---

Hoooo Brauner, ich hab nicht gesagt, daß es nicht crashen kann

Im Normalfall geht mit BestModeID() eigentlich immer alles glatt, aber auch da gibts natürlich, wie immer, Ausnahmen. Wenn Du einen Screen anforderst, der jeglichen Rahmen des jeweiligen Systems sprengt (beispielsweise 4096 x 3000hassenichgesehn in 24Bit auf OS4 Classic mit ner BVisionPPC), dann sollte es passieren, daß BestModeID() mit einem Fehler zurückkehrt. Was dann auch passiert, auf allen bekannten Systemen.

Der wird laut Thilo gecheckt, das ist gut. Über einen OS4-spezifischen Bug von BestModeID() ist bisher auch nichts bekannt, das ist ebenfalls gut.

Worüber ich noch theoretische Überlegungen angestellt hatte war der Fehler, den tploetz vor Urzeiten angegeben hatte (der Reaper). Der war sehr ominös und aus meiner bisherigen Erfahrung raus ein OpenScreen()-Problem.

Sprich, man übergibt OpenScreen() eine Screenmode-ID (woher die kommt, ist Sache des Programms), die ID existiert aber auf dem bewußten System gar nicht und man hat zu allem Übel noch vergessen, den Erfolg von OpenScreen() zu checken. Dann gibts die "out of memory"-Meldung und den nachfolgenden Reaper. Zumindest ist das der einzige Weg, mit dem ich das zuverlässig hinbekommen hab *hüstel*

Wobei, ist der User nur unerfahren oder übereifrig genug, kann das auch alle möglichen anderen Gründe haben

--
---

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

Zitat:

---

Original von Der_Wanderer:
@whose

Ich hatte mich darauf bezogen:

> habe den Fehler gefunden, in Prefs/env/SYS stand eine screens.prefs, die gab es auf der neuen OS 4.1 Installation nicht, auf der alten Partition habe ich screens.prefs umbenannt,Neustart gemacht und BlackShoot startet wieder einwandfrei.

Ich bin mir aber nicht sicher ob ich das richtig interpretiert habe. Kam durch diese Aktion ein Screenmodus wieder dazu, den es vorher nicht gab?

---

Zitat:

---

Die Rückgabe von BestModeID() wird natürlich geprüft.
Allerdings weis ich nicht, ob Blackbird nicht trotzdem weitermacht...
Ich denke aber ehr nicht.

---

Aber weil das außer ihm keiner weiß, habe ich gefragt. Den Fehler kenne ich ja. Und zwar aus genau dem Grund, den ich erwähnt hatte. Vergessen, daß OpenScreen() auch schon mal fehlschlagen kann

BestModeID() schlägt im Normalfall auch gar nicht fehl, es sei denn, man fordert einen wirklich monströsen Screen an. Da liegt das Problem höchstwahrscheinlich nicht.

Wenn man z.B. 640 x 480 via BestModeID() anfordert, welches im System A Standard ist, im System B aber (durch Pfuscherei z.B.) nicht vorhanden ist, wählt BestModeID() auf System B definitiv den nächst größeren Screen, meist 800 x 600.

Ich habs mit Amijeweled unter 4.1 Update 2 noch ausprobiert, es öffnet immer einen Screen, auch wenn der dann 1600 x 1200 ist (beim Test zum Schluß einzig vorhandene Auflösung) statt 640 x 480.

Bei der Gelegenheit habe ich dann auch das "ID-Shuffle" bemerkt, wenn man an den Screenmodes dreht oder DCC an- und/oder abschaltet.

Zitat:

---

Dass man bei einem zu grossen Screen das Spielfeld doppelt sieht ist wegen dem "Screenhack". Der ist allerdings notwendig, weil Classic Amigas sonst zu langsam sind, wegen dem bescheidenen Swapping Verhalten von Picasso96. Deshalb wird die Offscreen Bitmap mit auf den Screen gezwungen, in den - normalerweise - unsichtbaren Bereich des Screens.

---

Für Uninformierte war das sicherlich eine wertvolle Information. Für mich ists kalter Kaffee, mit dem P96-Scheiß habe ich mich damals auch rumschlagen müssen. Unter OS4 läuft das aber inzwischen fast reibungslos

Ok, immer noch kein Geschwindigkeitswunder, wenn das VRAM voll ist, aber das dürfte der "Vorfreude" auf Gallium3D geschuldet sein. Wurde halt nicht mehr viel am "offenen Herzen" operiert.
--
---

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

Zitat:

---

Original von Der_Wanderer:
Ich spekuliere mal dass beim Start immer BestScreenModeID ausgeführt wird und nichts gespeichert.
Wenn es halt einn illegalen Screenmode bekommt wegen einem OS4 Bug dann kann BlackShoot nix dafür.

---

Wir sind uns einig, daß es Bugs gibt, auch in OS4. Trotzdem bist Du mir, was das angeht, immer etwas zu schnell mit "Bug!" bei der Hand.

Ich kann Dir versichern, daß BestModeID() auch unter OS4 exakt wie dokumentiert funktioniert, und tploetz hat das implizit nochmal bestätigt mit seinem letzten Post. Gäbe es den von Dir gemutmaßten Bug, hätte Blackshoot wohl kaum in der erwähnten Weise funktioniert, nämlich mit "Bild ist zweigeteilt und läuft".

Was immer tploetz da an seiner alten Installation gebastelt hat, daß BS mit dem Eingangs erwähnten Fehler wegsemmelt... BestModeID() ist ein ziemlich unwahrscheinlicher Kandidat dafür.

Genau deswegen frage ich nach einem möglicherweise "wiederverwendeten" Screenmode-ID. So ein Fehler tritt nämlich u.A. genau dann auf, wenn es eine entsprechende ID nicht in der Screenmode-Liste gibt und das Programm die Rückgabe von OpenScreen() nicht überprüft.

Sowas soll mitunter auch vorkommen
--
---

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

Zitat:

---

Original von huepper:
So recht nach Overlay sieht das aber noch nicht aus.

---

Doch, siehts Man merkts ja auch sofort beim Abspielen.

Spätere Versionen sollten vor allem mit libhassenichgesehn in optimierter Fassung compiliert werden. Ich schätze, da liegen noch die größten Unterschiede zur MOS-Variante.
--
---

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

Zitat:

---

Original von cgutjahr:

Zitat:

---

Original von whose:
Vorher hat das keinen Zweck, außer wieder mal sinnfrei Unruhe zu stiften.

---

Genau, huepper der alte Dreckstroll - auf den Scheiterhaufen mit ihm!

---

Ich schätze, er weiß, daß ich nicht ihn persönlich mit "Unruhe stiften" meine Mir war zumindest vorher schon bekannt, daß er letztendlich nur seltsamen Wünschen, die woanders geäußert wurden, nachgekommen ist. Und seltsam sind die Wünsche, wenn man bedenkt, daß da zwei völlig verschiedene Dinge miteinander verglichen werden.

Daher: Wenn beide Varianten auf dem gleichen Stand sind, dann sieht man mehr. Allerdings nicht zwingend, welches Betriebssystem schneller oder sonstwas besser ist. Eher, auf welchem OS sich die Software leichter tut. Da spielen aber so viele Faktoren mit, daß man nicht mal genau sagen könnte, weswegen z.B. die MOS-Variante am Schluß einen Frame/s schneller ist. Festplattentreiber? Speicherverwaltung? Compilerbibliotheken? Gfx-Subsystem? AGP-Hardware? und so weiter...

Zitat:

---

Zugegeben, einmal mit Overlay und einmal ohne Oberlay zu testen ist relativ sinnlos. Aber mit zweimal Overlay wäre es doch genauso sinnlos, oder nicht? Wie schnell ein Programm Daten in den Videospeicher schreiben kann, ist ja keine Frage des Betriebssystems.

---

Nicht?

Zitat:

---

Im Übrigen würde ich als OS4-Fan bei Diskussionen zur Grafik-Perfomance ganz schnell das Weite suchen. Frag einen OS4-Entwickler deiner Wahl, und er wird Picasso96 zum Teufel wünschen. Der den ich damals gefragt habe, hat die Formulierung "elende Krücke" benutzt.

---

Ja, aber das hat andere Gründe, als die reine Geschwindigkeit. Intern sind sich CGFX und P96 sehr ähnlich, CGFX wurde zügiger aufgeräumt, auf Geschwindigkeit getrimmt und Bugs wurden mit Engagement gefixt.

Nach vielen Jahren, in denen gar nix passierte, will das heute bei P96 keiner mehr machen, vor allem nicht, wo schon an nem neuen Subsystem gewerkelt wird. Machbar wärs aber.

Ansonsten: Who cares? Ist doch keine Frage des OSses, wie schnell ne Software was in den Bildspeicher schiebt.

Oder doch?
--
---

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

Zitat:

---

Original von Polluks:
@huepper:
Sehr interessant, in diesem Fall ist OS4 also 60% langsamer

---

Nein, MUI-MPlayer ist 60% langsamer

Zitat:

---

AltiVec wird wohl bei beiden genutzt ...

---

Ja, aber Overlay eben nicht.

Solche Vergleiche sind völlig witzlos, solange eine Software Optionen zur Beschleunigung nutzt, die die andere gerade nicht nutzt.

Das Ganze nochmal, sobald MUI-MPlayer in der OS4-Variante Overlay nutzt. Vorher hat das keinen Zweck, außer wieder mal sinnfrei Unruhe zu stiften.

Eventuell läuft MUI-MPlayer dann auch auf den wirklich langsamen OS4-Maschinen brauchbar, was für einige Video-Formate nicht unpraktisch wäre.
--
---

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

Zitat:

---

Original von thomas:
Das ist Unsinn. Die dos.library kann jede Festplattengröße verarbeiten, die man am Amiga betreiben kann, also z.Zt. bis 2 TB.

Das Problem hier ist einzig und allein der Installer, der bei der Berechnung von Bytes aus Blockgröße und Anzahl Blöcken den Überlauf ignoriert. Abhilfe bringt ein neuer Installer. Der neueste ist 44.10 und ist im NDK 3.9 enthalten.

http://www.haage-partner.de/download/AmigaOS/NDK39.lha

Die 2 GB Beschränkung bezieht sich auf Dateigrößen und ist nicht allein in der dos.library verankert, sondern auch in den meisten Dateisystemen.

---

code:

---

;(if (< (getdiskspace "SYS:") 409600)
;	(abort "nnApproximately 400K of disk space is needed on your SYS: volume."
;	 "nnYou only have " (/ (getdiskspace "SYS:") 1024)	"K free.nn"
;	 "Delete or transfer some files from the SYS: volume and try again." )
; )

---

Wie Du siehst, ist das auskommentiert. getdiskspace war (und ist unter OS3.1) hauptsächlich das Problem, wenn Installer-Scripte Hellseherei in Sachen "verfügbarer Platz auf dem Volume" betreiben und damit scheitern.

Man kann als "Abhilfe" den V44-Installer nehmen, aber weise ist das auch nicht unbedingt. Ist ja eben nicht "nur" der Installer, der bei Größenangaben >2GB Bockmist produziert. Abgesehen davon ist der auch gar nicht für Kickstart3.0/3.1 gedacht.

Ich empfehle Dich ja immer gern als Kapazität auf dem Gebiet "68k-Amiga und große Festplatten", aber bei solchen Ausfällen wie heute zweifel ich etwas daran. Anderen "Unsinn erzählen" vorwerfen, aber selbst noch größeren Unsinn produzieren, indem man formal korrekte, praktisch aber nicht haltbare Aussagen in die Runde schmeißt.

Anfängern oder Anwendern, denen Dein umfangreiches Wissen fehlt, tust Du damit ("Unsinn, die dos.library kann alle Größen verarbeiten...") jedenfalls keinen Gefallen. Die fühlen sich dann sicher und machen beim ersten Programm, das nicht auf Überläufe gefaßt ist, ein dummes Gesicht, wenn all die schönen Daten die Reise ins Nirvana angetreten haben. Nur deswegen, weil Du ihnen das Wichtigste verschweigst, während Du Dich als Autorität, mit Anwürfen gegen andere, produzierst.

Und regst Dich dann wieder künstlich über die "Dummheit" der Unaufgeklärten auf, wenn die um Hilfe schreien.

--
---

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

Zitat:

---

Original von TomSoniq:
@Bluebird: Nein, eine reine 68k Version von AmigaAMP2 gab es noch nicht, ich kann aber mal eine machen!

FLAC/OGG Unterstützung für 68k/WarpUP für AmigaAMP2 wird es allerdings nicht geben. Das, was ich da in den OS4-AmigaAMP3 eingebaut habe, basiert auf fertig für OS4 verfügbaren Link-Libraries, die ich einfach nur einbinden und deren Funktionen aufrufen muss. Für 68k/WarpUP gibt's die nicht, das heißt, ich müsste die selber machen und an diesen ganzen Hickhack mit WarpUP Task switching, etc. anbinden. Da fehlt mir echt die Zeit und die Motivation zu.

---

Hm, zumindest für rein 68k könnte das hier für Dich interessant sein. Irgendwie muß der Autor ja OGG/FLAC-Support da rein bekommen haben, und ich glaube eher weniger, daß er das alles selbst gezaubert hat
--
---

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

Zitat:

---

Original von tOrbiT:
klasse das hat auch wieder gut geklappt. Nun läuft ClickToFront
Ich habe das OS 3.9 von der CD automatisch installieren lassen.

---

Zitat:

---

Kann natürlich sein das das der Fehler war. Bis jetzt komme ich gut mit OS 3.9 voran. Aber wie kann ich ein laufendes Programm beenden?

---

Das hängt davon ab, wie das Programm gestartet wurde. Ich nehme aber an, daß Du "Programm, welches in der Shell gestartet wurde" meinst.

Den einfachsten Fall hat Dir schon jemand hier genannt. CTRL + C drücken. Die meisten für die Shell gedachten Programme reagieren darauf und terminieren.

Bei sog. "Commodities" (und ClickToFront gehört in diese Kategorie) klappt das allerdings meist nicht. Für solche Programme findest Du (ebenfalls in der Schublade "Commodities") das kleine Progrämmchen "Exchange".

Wenn Du das startest (kann sein, daß Du auch da das gleiche Spielchen wie bei ClickToFront treiben mußt, damits funktioniert), siehst Du eine Liste mit allen gestarteten "Commodities" (inklusive "Exchange", welches ebenfalls ein Commodity ist).

Darunter befinden sich dann ein paar Schalter, einer davon trägt den Namen "Entfernen".

Die weitere Vorgehensweise dürfte recht selbsterklärend sein: "ClickToFront" in der Liste wählen, "Entfernen" drücken... voilá, "ClickToFront" ist raus.
--
---

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

Zitat:

---

Original von tOrbiT:
Aber nochmals zurück zu kommen zu ClickToFront. Ich kann das Programm auch nicht manuell starten. Wenn ich es versuche dann steht dort immer.diesem Piktogramm ist kein Standartprogramm zugeordnet. Was könnte das bedeuten.

---

Das bedeutet, daß Du Deine OS-Installation irgendwie leicht vergurkt hast

Klick ClickToFront einmal an, dann wähle im "Piktogramm"-Menü "Informationen anzeigen".

Neben "Name" siehst Du "ClickToFront", und DANEBEN steht dann, um welchen Typ von Datei es sich handelt. Dort wird bei Dir wahrscheinlich "Projekt" stehen, was falsch ist.

Wähle im gleichen Fenster im Menü "Typ", dort "Programm", und dann unten im "Informationen"-Fenster "Speichern".

Dann dürfte ClickToFront wieder per Workbench ausführbar sein.

Zum Beenden der Shell: Naja, die läßt sich schon schließen, wenn Du "irgendwas" eingibst. Problematisch wirds erst, wenn Du von dort aus ein Programm startest und selbiges dann nicht beendest. Dann läßt sich die Shell meist nicht schließen (es läuft ja noch ein Programm im Shell-Kontext).
--
---

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


[ Dieser Beitrag wurde von whose am 20.03.2011 um 14:48 Uhr geändert. ]

Zitat:

---

Original von tOrbiT:
Ich weis nicht ob es damit etwas zu tun hat. Derzeit habe ich kein CD-Rom am Amiga. Beim Starten bekomme ich dann eine Fehlermeldung das kein CD-Romlaufwerk gefunden werden kann.

---

Du bist doch der, der vor ein paar Tagen ein CD-ROM am 4fach-Adapter betreiben wollte? Die Fehlermeldung kommt höchstwahrscheinlich von der CD-ROM "Mountlist".

Ziehe das Piktogramm namens "CD0" (oder bei Dir vermutlich "EMERGENCY_CD") aus der Schublade "Devs/DosDrivers" nach "Storage/DosDrivers" (auf der Partition namens "Workbench"). Das letztere ist zum "Aufbewahren" von Mountlists, diese werden dann beim Booten NICHT aufgerufen.

Die in "Devs/DosDrivers" werden beim Booten ausgeführt, und wenn dann kein CD-ROM gefunden wird, gibts ne Fehlermeldung.
--
---

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