Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
So siehts aus. bei CGFX und P96 ists so, daß WritePixelArray() bei passendem Format der Grafikdaten einfach ein MemCopy() durchführt, viel schneller geht nur mit handoptimiertem Assembler und direktem Zugriff aufs Video RAM. Warum man das vermeiden sollte, muß ich, glaub ich, nicht erklären, oder?

---

Man sollte vor allem unabhängig von der Frage, ob die momentan betrachtete Hardware das so macht, berücksichtigen, daß manche Systeme den entsprechenden Transfer von der Grafikkarte und nicht vom Prozessor erledigen lassen könnten.
Und dann kann der Assembler-Code noch so handoptimiert sein, gegen ein Busmaster-Transfer kommt er nicht an.

---

Naja, das stimmt schon, und müßte den Leuten auch einsichtig sein, sobald die sich in der Materie etwas besser auskennen. Allerdings gings hier hauptsächlich um Amiga und MaxonBasic, da kann man dieses Thema ruhigen Gewissens etwas vernachlässigen

Zitat:

---

Deshalb ist auch ein Transfer ohne Konvertierung besser. Nicht weil sie Zeit kostet (meist kann sie parallel ausgeführt werden), sondern weil manch ein Chip möglicherweise Direkttransfers unterstützt, aber keine Pixelformat-Konvertierung in Hardware besitzt. Und somit die Frage Konvertierung oder nicht über die Frage Hardwarebeschleunigung oder nicht entscheidet.

---

Siehe oben. In MaxonBasic dürfte parallel ausgeführte Konvertierung ein wenig kompliziert werden Ansonsten hast Du natürlich Recht, wobei das Arbeiten mit mehreren Tasks (Konvertierung/Transfer) nicht unbedingt jedermanns Sache ist

Grüße

--
---

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

Zitat:

---

Original von Ralf27:
So, erstmal Stück für Stück:

BMB_SPECIALFMT:
Leider hab ich diesen Flag nicht in meiner Include gefunden und hab eben mal in der C-Include nachgesehn und ihn dort gefunden. Ist der Wert 7? Denn müßte ich dann auch in meinen MB-Includes einfügen.

---

Zitat:

---

Rohdaten BGR:
Ich hab die Daten ins RGB-Format gewandelt, weil es so die WritePixelArray-Funktion verlangt.

---

Ja, das habe ich mir schon gedacht

Zitat:

---

Wenn ich aber die BGR-Daten so in eine mit AllocBitmap generierte Map (mit BGR-Format) ablege, kann ich also die BGR-Daten direkt in ein BGR-Screeen mit ClipBlit(?) kopieren?

Langsam bekomm ich en Knoten im Hirn.

---

Alles halb so wild Ja, wenn Du die Daten bereits im passenden Format (also passender Byte-Reihenfolge, Endianess beachten!) aus der Datei bekommst, kannst Du die direkt in Deine eigene Bitmap reinschreiben und diese dann auf die GraKa rüberblitten.

Zitat:

---

Andere Frage:
Ich hab versucht mit CModeRequestTagList eine Auswahl mit entsprechenden Screens (Farbtiefe vorgegeben=24, RGB-Farbformat=9) zur Auswahl zur stellen, aber leider bringt er mir dann nur 8Bit-Screens?
PS: Mir ist klar das man ASL-Requester nehmen sollte.

---

Das hat mit der Art des verwendeten Requesters wenig zu tun. Das liegt schlicht daran, daß der Permedia2-Grafikchip, der auf der C-/BVisionPPC eingesetzt wird, in den Modi >8Bit nur BGR-Reihenfolge unterstützt (soweit ich weiß. Wenns anders ist, bitte korrigieren). Nur bei den 8Bit-Modi bietet der Chip RGB-Format für die _Paletten-Einträge_ an. Daher siehst Du eben auch nur die 8Bit-Modi im Requester. Probiers doch mal umgekehrt, dann müßten die 8Bit-Modi verschwinden

Du solltest allerdings in Deinem Programm darauf verzichten, bestimmte Pixelformate bei der Screen-Auswahl vorauszusetzen. Nicht jeder hat ne GraKa, die BGR-Pixelformat bietet und diejenigen bleiben dann außen vor. Schreibs lieber gleich so, daß es die Bilddaten gleich in das von der GraKa benötigte Pixelformat konvertiert, dann läufts überall. Ist zwar mehr Arbeit, bringt aber auch mehr "Kunden"

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 21.04.2005 editiert. ]

[ Dieser Beitrag wurde von whose am 22.04.2005 editiert. ]

Zitat:

---

Original von Ralf27:

Zitat:

---

Original von MaikG:
>Zur Zeit benutze ich ja in Basic einfach denn Screen
>Befehl, um einen Screen zu öffnen. Ich muß wohl
>bald die Systemroutinen benutzen.

Solltest du unbedingt, dir scheint nicht bekannt zu
sein das MB für Screen und Windows Chip-Speicher benutzt?

---

Ne, das ist mir wirklich nicht bekannt. Auch wenn der Screen auf der Grafikkarte aufgemacht wird?

---

Eben. Deswegen: Keine Panik!

MaxonBasic nutzt dazu (wie es sich gehört ) OS-Funktionen, die durch das RTG-System schon "zurechtgepatcht" sind damit nix im ChipRAM landet, wenn nicht zwingend notwendig.

Ich weiß allerdings nicht, ob Du an die RastPort-Struktur der MB-internen Screens/Windows herankommst. Die brauchst Du, wenn Du von Deiner "selbstgebauten" in die Screen-/Window-Bitmap "blitten" willst. Aber selbst, wenn das nicht gehen sollte: Dir bleiben immer noch die OS-Funktionen

Grüße

--
---

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

Zitat:

---

Original von Ralf27:
Die Rohdaten liegen im BGR-Format vor und wenn ich so die Daten in denn Speicher bekomme und ich auch so "blitten" kann, dann geht es wirklich sehr viel schneller.

---

Allerdings nur für den Fall, daß die GraKa die Bitmap im BGR-Format anlegt. Das gilt "leider" nicht für alle GraKas. Denk auch an die armen "Schweine", die keine B/CVisionPPC ihr eigen nennen können

Probiers aber erstmal aus. Später kannst Du ja immer noch die Konvertierung ins jeweils passende Bitmap-Format in Deine Laderoutinen einbauen.

Grüße


--
---

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

Zitat:

---

Original von Ralf27:
Nicht so einfach mit dem BGR-Screen aufmachen. Hab es eben mit dem CModeRequestTagList versucht, aber leider lief das auch nicht richtig. Ich hab als einzige TAG-Übergabe angegeben das ich nur BGR-Screens will, die Auswahl bringt mir nur 8Bit-Screens... ?

Gehe ich recht in der Annahme, das ein RGB-Screen nur eine andere ID hat als ein BGR-Screen?

Was für eine ID hat 1024*768*24 RGB (BGR) auf der BVision?
--
http://www.alternativercomputerclub.de.vu

---

Erst ists BGR, dann gehts nicht? Naja, lange Rede, kurzer Sinn: Schau Dir mal in den CGFX-Autodocs die Abteilung über das modifizierte AllocBitMap() an, damit kannst Du einer Bitmap bereits beim Anlegen das benötigte Format mitgeben und die später relativ einfach z.B. via Blit...-Funktionen in eine Screen-Bitmap "blitten" (klingt komisch, wenn man bedenkt, daß die Daten im FastRAM liegen können ). AllocBitmap() ist wie gesagt durch CGFX (P96) modifiziert, um auch Bitmaps eines anderen Formats als Planar einigermaßen systemkonform anlegen zu können. Das entsprechende Flag hört auf den Namen BMB_SPECIALFMT

Du kannst diese "selbstgebaute" Bitmap allerdings nicht zum Öffnen eines Screens verwenden, mußt schon noch die Daten selbst von Deiner selbstgebastelten Bitmap in den gewünschten Screen übertragen, z.B. über die Blit...-Funktionen.

Also erst das Pixelformat des geöffneten Screens ermitteln und dann dementsprechend per AllocBitmap() eine Bitmap basteln lassen, die später die geladenen Bilddaten im dem Screen genehmen Format enthält.

Mit der Methode kannst Du alle möglichen Formate verarzten (sofern die von CGFX/P96 unterstützt werden).

Hast aber sicher gemerkt, daß Du da um eine Konvertierung so oder so nicht herumkommst, aber auf diese Weise verlegst Du die Konvertierung geschickt auf den Ladevorgang, wo es nicht so auffällt . Zusätzlich umgehst Du damit das (in CGFX) lahme WritePixel() (bevor wer weint: P96 hat auch so seine "Flaschenhälse" in der 68K-Version).

Im Zweifelsfall bleibt Dir immer noch der harte Weg des direkten Zugriffs offen, aber vor dem Weg warne ich Dich nicht ohne Grund. Müßtest nämlich _alle_ möglichen Bitmap-Formate berücksichtigen

Grüße

P.S.: Übrigens: Halt Dich nicht so sehr an den "speziellen" Formaten und schon gar nicht an bestimmten Screenmode-IDs fest, das geht ins Auge! Nimms einfach hin, daß es verschiedene Formate gibt und leg entsprechend aufgebaute Bitmaps mit den dafür vorgesehenen Systemfunktionen an. Dann läufts nämlich auch auf anderen GraKas als der BVisionPPC Kleiner Tip noch zum Schluß: Schau mir mal die BlitzBasic2-Includes von Thilo Köhler an, da findet man ne Menge Information, wie man mit GraKa-Bitmaps >8Bit und Systemfunktionen arbeitet, und das sogar ziemlich fix.

--
---

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

Zitat:

---

Original von Ralf27:

Zitat:

---

Original von whose:
Naja, mal schauen was Ralf uns jetzt dazu sagt

---

Ich hab immer was zu tippen!

---

Das hab ich mir irgendwie schon gedacht

Zitat:

---

Also, das mit dem Format ist so eine Sache. Es wäre wohl wirklich am besten wenn beides zusammenpast: Screen und Daten.

---

So siehts aus. bei CGFX und P96 ists so, daß WritePixelArray() bei passendem Format der Grafikdaten einfach ein MemCopy() durchführt, viel schneller geht nur mit handoptimiertem Assembler und direktem Zugriff aufs Video RAM. Warum man das vermeiden sollte, muß ich, glaub ich, nicht erklären, oder?

Zitat:

---

Hm, mal sehn wie ich das mach. Muß mich mal später mal durch die AutoDocs stöbern und mal sehn wie ich das mach. Eigentlich würde dieser Speed auch reichen, aber ich will mehr!

---

GetCyberMapAttr() dürfte das Gesuchte sein

Zitat:

---

Wie hoch ist aber denn nun eigentlich der theoretische MaxSpeed von der 603e über den miniPCI-Port in die Grafikkarte?
--
http://www.alternativercomputerclub.de.vu

---

Gute Frage, nächste Frage. Kannst ja mal mit direktem Zugriff aufs Video RAM messen (und nur zum Messen direkter Zugriff )

Grüße



--
---

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

Zitat:

---

Original von Holger:
Ist das in jedem Fall RGB oder auch BGR etc, ja nach Bedarf? Wenn ich mich recht entsinne, erlaubt die CGX-Funktion verschiedene Formate, die dann in das tatsächliche Screen-Format konvertiert werden. Das tatsächliche Pixelformat vorher zu ermitteln, und die Bilddaten gleich in diesem Format vorzuhalten, könnte durchaus die Performance verbessern.

---

Das ist auch bei P96 so, weil sonst z.B. die Workbench auf nem 24Bit-Screen nicht machbar wäre.

Allerdings hätt ich auch darauf kommen können, daß das Format der zu übertragenden Daten dem Screen "nicht paßt". Das könnte des Rätsels Lösung sein, diesen Zusammenhang übersieht man leicht.

Naja, mal schauen was Ralf uns jetzt dazu sagt

Grüße

--
---

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

Zitat:

---

Original von Ralf27:

Wie schnell ist eigentlich die BVision? Wie schnell kann ich Daten auf die Grafikkarte schaufeln?

Es müßte doch eigentlich schneller gehn als 3,6MB pro sek, oder?


PS: Need more Speed.
--
http://www.alternativercomputerclub.de.vu

---

Dann beschreib doch mal, auf welche Weise Du die Bilddaten zur GraKa übertragen läßt, davon hängt die Geschwindigkeit nämlich unmittelbar ab. Im übrigen solltest Du ganz scharf darauf achten, ob Du die Bilddaten nicht zufällig im Chip RAM liegen hast. Wenn doch, brauchst Du Dich über die "Geschwindigkeit" nicht zu wundern

Grüße

--
---

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

Zitat:

---

Original von Tobibrocki:

Wie meinst du das, das P96 nicht zu empfehlen ist ?

---

Er meint damit, daß er _persönlich_ CyberGraphX bevorzugt, ohne wirklich Plan davon zu haben, wie dieses intern im Gegensatz zu P96 funktioniert. Wüßte er das, hätte er sich diesen Kommentar gekniffen. Ich könnte Dir ein A1200/040-System mit CyberVision64/3D vorführen, das abwechselnd mit CGFX und P96 betrieben werden kann. Einen Unterschied in der normalen Anwendung wirst Du nicht bemerken. Die beiden RTG-Systeme tun sich nämlich nicht mehr wirklich viel (gemeint sind die 68K-Versionen). Subjektiv ist IMHO kein Unterschied bemerkbar.

In der Bedienung läßt CGFX dem Anwender mehr Möglichkeiten zur Screenmode-Erstellung, die Du aber wirklich nicht unbedingt brauchst.

Ich selbst nutze beide Systeme (u.A. weil es für die CyberVisionPPC keinen P96-Treiber gibt) und bin mit beiden zufrieden.

Nimm das RTG-System, welches Dir selbst am besten gefällt und mit dem Du persönlich am besten klarkommst, und gut is.


Grüße

--
---

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

Zitat:

---

Original von thomas:

Ich kann mich dunkel an ein Problem erinner, wo der 3.9-Installer nicht alle Dateien kopiert hat. Allerdings hatte ich das nie und kann mich auch nicht an die Lösung erinnern.

---

Ich kann mich auch nur noch dunkel erinnern, aber es gab zwei Versionen der OS3.9 CDs. Die erste "Edition" hatte ein fehlerhaftes Installskript, welches einige Dateien nicht kopierte. Abhilfe schaffte das BB1, welches die fehlenden Dateien ggf. nachträglich installierte.

Ob das bei diesem Problem hier hilft, kann ich aber beim besten Willen nicht sagen. Für mich klingts auch mehr danach, als wäre die Bootpartition gar nicht bootfähig.

Grüße

--
---

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

Zitat:

---

Original von aPEX:

es ist einfach das problem das alle wollen, aber am besten nichts
dafuer machen. und so geht die rechnung eben nicht auf...

@harague/kneteknut
das all-in-one projekt schlaeft auch, leider. ich habe ja ein paar
leute gefunden die was machen wollten... aber wenn man da nicht
staendig dran ist die leute zu motivieren usw. schlaeft so ein
projekt ein. meine hochachtung an dieser stelle an geri der sich
mehr als nur gedanken zum speicherinterface gemacht hat, bzw. auch
alle anderen die ANFANGS sehr fleissig geholfen haben.

aber wir sind z.b. nicht an das driver development kit fuer picasso
rangekommen und somit konnte niemand in richtung grafik
experimentieren. ich dachte auch jens koenne mehr machen, aber der
ist auch im stress...
wenn sich da jemand drum kuemmern will, gerne, ich versuche zu
helfen wo ich kann...

---

Zitat:

---

in diesem sinne, ich hoffe es versteht mich niemand falsch...

---

Im Gegenteil, Du sagst doch nur, wie es in der Realität ausschaut. Andererseits hast DU auch gezeigt, wie es anders gehen kann, wenn die Begleitumstände günstig sind

Grüße

--
---

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

Zitat:

---

Original von aPEX:
dann bleibe ich erstmal beim internen ide, ist alles momentan zu teuer... fuer 2 adapter bin ich dann 120¤ los...

---

Ja, das ist auf alle Fälle die günstigste Lösung. Arbeiten kann man damit, ich brenn auch CDs über den internen IDE, geht zwar langsamer als möglich wäre, aber geht

Grüße


--
---

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

Zitat:

---

Original von aPEX:

...jetzt erfahre ich allerdings das das ganze noch
langsamer sein soll, als der interne IDE...

STIMMT DAS??? kann das noch jemand bestaetigen?

waere es dann eine bessere loesung 2 SCSI-zu-IDE adapter zu
kaufen und den brenner und die hd da ranzuhaengen????

---

Naja, das stimmt schon... ist auch irgendwo logisch, weil die Anbindung des internen IDE beim 4000er 32 Bit breit ist (was aber nicht wirklich viel mehr Performance bringt), während der Buddha nun mal eine ZorroII-Karte (=16Bit) ist. Allerdings sind die Verluste in der Praxis leicht verschmerzbar, weil kaum zu bemerken. Liegt daran, daß der interne IDE der Classic Amigas nicht gerade der modernste zu seiner Zeit war.

Buddha unterstützt PIO bis Mode 3 und kommt bei der Übertragunsgeschwindigkeit an die Grenzen der ZII-Busbandbreite, welche der interne IDE beim 4000er mit 060 CPU wegen der 32Bit-Anbindung noch einen Hauch übertrifft, wenn eine moderne Platte dranhängt.

Dafür blockiert der Buddha nicht, wenn man mit nem IDE-Brenner arbeitet

SCSI-zu-IDE ist meiner Meinung nach trotzdem die bessere Lösung, weil Du damit die Laufwerke (wenigstens ein bißchen ) besser ausnutzen kannst und die CPU-Last (abhängig vom SCSI-Adapter) niedriger liegt.

Grüße

Zitat:

---

Original von AndreasM:

Was Apex gemacht hat kann man nicht mal ansatzweise mit ner Messe vergleichen.

---

Zitat:

---

Solche Projekte sind leider notwendig. Auch wenn ich sie momentan für unrealistisch halte. Aber wenn man neue Amiga User bekommen will (und die braucht man wenn es aufwärts gehen soll) müssen Programme her die auch ein PC-User kennt.

---

Zitat:

---

Das Problem ist eher das die User soch selbst kaputt machen. Kaum ist z.b. ein Office Paket kommerziell erschienen setzt man alles daran ein Open Office Paket umzusetzen.

---

Nicht nur die User. Du zählst doch auch zu denjenigen, die ohne Open Office/AmiZilla keine Sonne sehen

Wer redet den Usern denn den Unfug ein? Es gab mal ne Zeit, obwohl Windoof und Co. schon uneinholbar voraus waren, da war der Amiga-User stolz darauf, nichts von dem Zeugs benutzen zu müssen. Nun ists auf einmal so ne Art heilige Pflicht geworden. Das kommt doch nicht nur daher, daß das Netz mit AWeb und Co. etwas schlechter zu bereisen ist (ich z.B. merke nicht besonders viel davon, daß es schlechter geht mit AWeb). Vieles ist auch "Propaganda", wenn man so will. Dieser könnte man mit kleineren Treffen durchaus entgegenwirken und so Motivation schaffen, etwas wirklich außergewöhnliches aus dem Amiga zu machen. Der Wunsch ist jedenfalls da, das kann man häufig lesen.

Zitat:

---

Ich trau mich wetten. Wenn jemand einen guten Browser kommerziell verkaurfen würde, wäre das erste was die Community machen würde nach einen Open Source Browser zu schrein :/

---

Zitat:

---

Du tust so als ob hier massig Amiga Software täglich erscheinen würde. Nimm alleine mal den Spiele-Bereich. Selbst neue und gute PD-Games sind inzwischen ne Rarität.

---

Zitat:

---

Ja, eben, wie oft kam etwas brauchbares heraus? Ich kenne verdammt wenige Fälle. Momentan fällt mir eigentlich gar keiner ein.

---

Zitat:

---

Allerdings wie oft waren es nur Luftschlösser wo wahnsinnig viele Resourcen verschwendet wurden anstatt sie sinnvoll zu investieren.

---

Zitat:

---

Ich glaub das man nicht mal soviele aktive User weltweit zusammen bekommen würde wie auf ner Messe 1990.

---

Zitat:

---

Aber zurück zum eigentlichen Thema. Das Problem ist, das Du keine Idee hast wie man Händler und Entwickler und damit dann auch User auf so ein Treffen locken kannst.

---

Mal ne dumme Frage: Waren die User auf dem OS4-Meeting wegen Vesalia da, oder wars doch eher umgekehrt?

Entwickler finden sich immer, die an einem kleinen Treffen gern teilnehmen. Die User melden sich dann auch zu Wort. Wenns genug User sind, melden sich auch nochn paar Entwickler, vielleicht auch einer der beiden verbliebenen Händler. Die Größe der Veranstaltung ist dabei gar nicht so entscheidend.

Zitat:

---

Usertreffen wird es immer geben. Aber Treffen wo meherer Entwickler und Händler dabei sind... das ist heutzutage kaum noch möglich.

---

Weils kaum einer angeht. Nicht, weils unmöglich wäre. Biete den Entwicklern ein Forum, und sie werden erscheinen, so sie denn können. Ich glaube, gerade kleinere Entwickler würden ihre Sachen gern zeigen, wenn sie denn dürften/könnten. War doch beim Treffen in Bremen nicht anders. Die Entwickler wurden gefragt, ob sie denn was zeigen möchten, und daraufhin hat selbst Michael Boehmer den wirklich weiten Weg nicht gescheut. Daraufhin wiederum kamen halt auch mehr User. Das dürfte auch bei 3-4 Treffen pro Jahr recht gut funktionieren, womit man dann auch die Wege für die Besucher klein halten könnte (Norden, Süden, Osten, Westen ).

Selbst, wenn eine Veranstaltung mal nicht so läuft, wie man sich das wünscht, war sie dennoch nicht umsonst, denn man hat den Willen gezeigt, etwas zu bewegen. Ein Schwalbe macht noch keinen Sommer, auch im negativen Sinne nicht.

Grüße

Zitat:

---

Original von Andreas_B:

Ja, im Retro-Bereich. Seine Projekte in allen Ehren, aber zumindest für eine Weiterentwicklung des Amigas sind sie nicht geeignet.

---

Zitat:

---

Was passiert denn schon groß im dunklen Kämmerlein? OpenOffice fast fertig, Firefox im Betatest oder proggt Adobe wieder für Amiga? Wenn das so wäre, dann würde ich Dir recht geben :-)

---

Da ist sie wieder, die überzogene Erwartungshaltung Wer ist denn ernsthaft der Meinung, daß _ausschließlich_ OpenOffice/AmiZilla notwendig sind, um Fortschritte zu erreichen? Das dort die Chancen sogar noch deutlich schlechter stehen, wird anscheinend gern übersehen, weil diese Projekte halt am meisten Echo hervorrufen. Dabei gehen die kleinen, nichts desto trotz interessanten Projekte einfach baden. Warum rede keiner von HUS? 16Bit-Grafik, läuft auch auf dem A1, obwohl 68K und eigentlich für CGX gedacht, macht Spaß und ist was Neues. Wird totgeschwiegen, weils halt keins der großen, allseits diskutierten (Luft-) Projekte ist. Das liegt aber doch nicht an dem Spiel an sich, sondern an der Erwartungshaltung der u.A. hier Diskutierenden.

Man könnte diese Haltung so skizzieren: "Wenn keins der allgemein anerkannten Groß-Projekte am besten gestern umgesetzt wird, hats eh keinen Sinn mehr".

Das ist für mich der Tenor, wenns um die Amiga-Zukunft geht. Allerdings scheint niemand zu bemerken daß alle Nasen lang neue, kleine Projekte das Licht der Welt erblicken und sang- und klanglos wieder verschwinden, weil diese Kleinode gegen die (rein virtuell vorhandene) Großkonkurrenz einfach nicht anstinken können, was das Feedback angeht. Mich macht das jedenfalls nachdenklich, genauso wie das jahrzehntelange Überleben, obwohl angeblich Alles schon lange vorbei ist.

Zitat:

---

Das ist kein Pessimismus, das ist Realismus.

Versteh das aber bitte nicht als Angriff, ist halt nur mal meine Sicht der Dinge (und das obwohl ich Amiga-Fan bin!) und glaub mir, ich würde mich sehr freuen, wenn ich damit total falsch liegen würde!
...

---

Irgendwo verstehe ich diese Sicht sogar, daher seh ich das auch nicht als Angriff Andererseits habe ich mir so meine Gedanken in den letzten Jahren gemacht und gesehen, daß diese Ansicht irgendwie nicht ganz zur Realität paßt. In welchem Bereich schafft man es denn, von Null auf Hundert in einem Schritt zu kommen? Wie oft wurde beim Amiga schon alles für tot erklärt, bevor überhaupt mal ein Schritt gemacht war? Wie oft kam zum Schluß doch etwas Brauchbares heraus, was niemand erwartet hatte?

Denkt doch einfach mal darüber nach. Gleich morgen ne Messe alá Amiga 1990 ist völlig unrealistisch. Letztes Jahr OS4-Meeting war Realität.

Grüße

Zitat:

---

Original von AndreasM:

Als wird damals für ICP bei den Amiga Messen den Kartenvorverkauf und vieles andere gemacht haben, haben wir viel gelernt es hängt schon nen bisserl mehr drann als einfach irgendwo nen Halle zu mieten wenn man ne richtige Veranstaltung aufziehen möchte....

---

Hm, ich glaube, da hast Du einiges nicht richtig verstanden. Ich sprach davon, das Interesse an einer größeren Veranstaltung zu _wecken_. Das geht natürlich nicht Knall auf Fall. Am Anfang würden kleinere Veranstaltungen alá OS4-Meeting stehen, und darum gings Supimajo in der Hauptsache wohl. Bei solchen Veranstaltungen sind die Punkte, die Du aufgezählt hast, wohl eher zweitrangig. Da gehts mehr darum, die Entwickler zu motivieren, den Usern mal ein wenig zu zeigen, was sonst im stillen Kämmerlein passiert. Da brauchts keine Riesen-Organisation für, siehe OS4-Meeting. Wieso wollt ihr eigentlich immer gleich groß einsteigen?

Am Anfang steht Information, erst dann kommt Handel und Konsum verbunden mit Wachstum. Müßtest Du eigentlich wissen

Jetzt wärs noch schön, wenn man hier endlich wieder vom Zweckpessimismus runterkommen würde. Nehmt Euch doch mal ein Beispiel an aPEX. Er packt an, gibt nicht auf, ignoriert die Berufszweifler und hat Erfolg!

Grüße

Zitat:

---

Original von analogkid:

Zitat:

---

Original von aPEX:
bei dem phoenix
projekt sind ca. 40% "neue" user...

---

Das Phoenix Projekt hilft der aktuellen Amiga-Hard/Software allerdings nicht wirklich weiter, dein Engagement in allen Ehren. Die "aktuelle" Amiga-Hardware bietet, außer ein paar Hardcore-Freaks, keinen Reiz zum Kauf, im Gegenteil, sie weiss eigentlich eher abzuschrecken.

---

Das würde im Umkehrschluß ja bedeuten, daß das Phoenix-Projekt nicht nur Hardcore-Freaks angelockt hätte. Ob aPEX wohl erwartet hätte, daß er mit seinem Super-Engagement Otto-Normal-User wieder zum Amiga 1000 führt?

Und nu wieder ernsthaft: Das OS4-Event im letzten Jahr sah mir ganz und gar nicht danach aus, als ob die aktuelle Hardware oder Software die Interessenten abschrecken würde, eher im Gegenteil. Zeitweise konnte man sich in dem Raum kaum bewegen. Interesse ist also schon da, es müßte, da stimme ich mit Mario überein, nur mal wieder gefüttert werden...

Vielleicht sollten einige hier die ganze Situation nicht so zwanghaft negativ bewerten.

Grüße

Zitat:

---

Original von Coemmchen:
Gute Tips hier! Werde mich mal am WE bemühen ...

Eine Frage zu IDEFix: Ein solches liegt doch dem OS3.9 bei, oder ist das nicht das gleiche? Wenigstens liegt ein File in C und wird auch über die Startup-Sequence eingebunden -> C:IDEFix Reicht das, oder muss es doch was anderes sein, dann könnte ich mir vorstellen, warum es nicht will ...

SKIPROMs ist soweit ich mich erinnere nicht aktiv, werde dennoch auch hier nochmals nachschauen!

---

Zitat:

---

Original von alex-munich:
Hallo Leute, wollte heute mal wieder ein paar Klassiker, z.B. Der Reeder, Mag! und Kolumbus, auf meiner Festplatte installieren. Leider habe ich es nicht geschafft. Die Installationprogramme zeigen mir entweder als Laufwerke nur AwnPipe, Aux etc. an oder wollen mir weismachen das ich zu wenig Speicher habe. Ich habe einen A1200 mit BlzzardPPC 210MHz und 060 Prozessor, IDEFix, AmigaOS 3.9 mit BB2.
Woran liegt das Problem und wie kann ich es umgehen?

---

Zitat:

---

Original von Maja:
Wird wirklich der Datenbus endlos gescannt oder kann es vieleicht auch am Brenner liegen, dass der nicht initialisiert? Erlischt dessen LED kurz nach dem Einschalten?

Ansonsten klingt das in der Tat nach einem Terminierungsproblem. *duck*

---

Zitat:

---

Original von tstening:

So lange der Squirrel dranhängt passiert garnichts. Sobald ich ihn während der Suche abziehe, wacht sofort das Tool wieder auf und meldet, dass keine Geräte am Bus gefunden wurden.

---

Zitat:

---

Ich habe auch noch einen A600. An dem könnte ich es ebenfalls testen. Wenn das aber auch nicht klappt, dann werde ich den A1200 zerlegen und an den internen IDE-Anschluss noch ein ATAPI-CDBrenner hängen müssen.

---

Kannst versuchen, aber ich glaube net daran, daß der am A600 tut. Wenn die Teile einmal nimmer wollen, hats die meist zerlegt, warum auch immer.

Kannst Dir ja auch ne Blizzard mit SCSI-Kit besorgen, da gibts diese Probleme net, höchstens Kontaktschwierigkeiten im Expansionsslot. Einmal mit Isopropanol drübergewischt und gut

Grüße

Zitat:

---

Original von Borut:
Echt - und damit keine Nebengeräusche am Sound? Na dann muss es wohl defekt sein das Netzteil von mir - sonst kann ichs mir nicht anders vorstellen.

Witzig war auch, habe ein Netzteil von einem älteren ATX-PC probiert - welches definitiv funktioniert. Am AmigaMicro scheints auch zu laufen, LED läuchtet und der FAN läuft jedoch bootet er damit nicht - hatte jedoch nur 200 Watt, vielleicht deshalb?
--
mfg Borut

---

Zitat:

---

Original von Ralf27:
Also, es ist nicht wirklich sehr langsam (es geht im bruchteil einer Sekunde) und es ist auch ok, aber es hat mich halt doch verwundert das die eigentlich viel rechenintensivere WPA8-Funktion dem doch eigentlich einfach ScrollRaster "davonrennt". Aber mir ist schon klar das das wohl nur auf dem 060er so ist. Ich werde es wohl auch so lassen wie es ist und eventuell noch eine Option auf "Only WPA8" einbauen.

---

Das wäre sinnvoll. Wie gesagt, daß WPA8() auf dem 060er (und dem 040er) schneller ist, liegt halt am doch recht betagten AGA-Blitter, der allerdings in seiner Klasse (also im Vergleich mit den damals aktuellen PC-GraKas) immer noch einsam an der Spitze steht. Ein 060/040 ist dagegen deutlich zügiger bei der Bearbeitung der gleichen Datenmenge im FastRAM. Allerdings ist ScrollRaster() alles andere als "einfach", das solltest Du nicht auf die leichte Schulter nehmen. Kannst ja mal spaßeshalber versuchen, das im FastRAM per CPU "nachzuahmen". Mit Planardaten, versteht sich

Zitat:

---

Ich benutze natürlich möglichst Fastram, sonst wäre wohl WPA8 nicht so schnell.

---

Dem ist nichts mehr hinzuzufügen

Grüße

Zitat:

---

Original von Ralf27:
Hm, kann man einen anderen Befehl benutzen wenn man auf AGA das Bild scrollen möchte? Oder sollte man in so einem Fall statt Scrollen lieber doch dann das Bild immer komplett neu aufbauen? (060er, blazeWCP und AGA vorrausgesetzt)
--
http://www.alternativercomputerclub.de.vu

---

Zitat:

---

Original von Ralf27:
Ich hab hier folgendes System:
A1200 mit 060er, 64MB, OS3.1, BlazeWCP installiert

So, jetzt ist es so, wenn ich ein komplettes Bild(LowRes,8Bit) aufbaue mit WritePixelArray8(bzw. WriteChunkyPixel)aufbaue, dann geht das schnell als das Bild mit ScrollRaster um eine Zeile zu verschieben und dann WritePixelArray8 die eine Zeile aufzubauen.

Ist ScrollRaster so langsam, bzw. WritePixelArray8(WriteChunkyPixel) so schnell? Das hat mich schon sehr verwundert.
--
http://www.alternativercomputerclub.de.vu

---