Zitat:

---

Original von platon42:

Zitat:

---

Original von Thorsten:
Echtes Irda gibt es meines Wissens nicht. Es fehlen fürn Amiga (wie so oft) die Treiber.

---

Ich wollte mal bei Gelegenheit nen Treiber für USB-IrDa Interfaces schreiben, leider fehlt mir derzeit die nötige Hardware :-

---

Zitat:

---

Original von Maja:

Hallo, Solar!

Wir sprechen hier über Amiga, und da gilt:

Zitat:

---

Original von whose::
Was der Rest der Welt macht, ist für den Amiga-Bereich doch erstmal zweitrangig, genauso, wie für den Rest der Welt Amiga auf den allerhintersten Rängen spielt.

---

Irgendwie scheint das zu gefallen. Man will sich ja schließlich vom bösen Mainstream abgrenzen. Und eines muss man den Leuten rund um die Amiga-Entwicklungen der jüngsten Zeit lassen. Zumindest das ist ihnen gründlich gelungen. Und jeder darf sich in dem Gefühl ergehen, etwas ganz Besonderes zu sein. Schließlich ist man Einer von nur ganz Wenigen.

Ein wenig paradox ist dabei nur, dass eingefleischte Amiganer fast einstimmig Linux in den höchsten Tönen loben. Und das, obwohl gerade Linux und seine Entwickler und Anwender schon lange erkannt haben, mit welchem Zug man fahren muss, damit man eben nicht in der Wüste landet. Sie sitzen dabei zwar immer nur im letzen Wagon, aber sie sitzen immerhin mit im Zug. Das sollte doch zu denken geben.

---

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Es reicht völlig, wenn ihr denen, die fragen, ordentliche Antworten ohne Hinweis auf die völlige Überalterung des AOS-API oder ähnlichen Krampf gebt. Simpel, einfach, themenbezogen.

---

Nochmal: was willst Du mit diesem Blödsinn sagen?
Welche Frage haben wir nicht beantwortet? Wieso unterstellst Du uns permanent, daß wir den Autoren von neuer Amiga-Software nicht helfen würden?
Liefere eine Referenz, oder hör mit diesen Unterstellungen auf!

---

Zitat:

---

Original von Solar:

Zitat:

---

Anstatt das ihr solchen Leuten wirklich mit Rat und Tat zur Seite steht, entmutigt ihr sie.

---

Weil es einfach Schwachsinn ist, sich hinzustellen, und noch einen Schmalspur-Browser zu entwickeln - es sei denn, man macht's als Programmierübung, dem Amiga bringt das Null. Na klar hast Du Ruck-Zuck einen Browser, der halbwegs die Grundlagen beherrscht. Davon hat der Amiga schon drei oder mehr. Das ist aber nicht das, was gebraucht wird - gebraucht wird ein Browser, der sich nicht verschluckt, wenn's über die Grundlagen hinausgeht.

---

Zitat:

---

Original von gni:

Zitat:

---

whose:
Okay, den GCC 3.3 statt den 2.95.2, aber das wäre kein so großer Akt denke ich, wenn sich gni mal dransetzen würde, um die StormC-Targets für den 3.3 zu implementieren. Source ist ja vorhanden.

---

Hast Du Dir die Storm-Quellen des GCC mal angesehen? Nachdem ich die AmigaOS/68k Modifikationen besser vertstand, habe ich mir die Storm Quellen nochmal angesehen: Schlimm! Dort wurde alles getan um die Nachnutzung so schwer wie möglich zu machen. Obs Absicht oder Unvermögen war, kann ich nicht sagen. Selbst deren eigener Versuch auf eine neuere GCC Version wurde dort unnötig erschwert.
Ich bin mit dem "normalen" GCC ganz zufrieden ;-)

---

Zitat:

---

Zitat:

---

Hätt ich den Durchblick beim GCC hätte ich das schon längst getan.

---

Man muß nur wollen :-)

---

Ich will ja, aber mir erklärts ja keiner

Zitat:

---

Zitat:

---

Aber mein Ausflug in Sachen ARM-GCC (Crosscompiler) hat mir gereicht...:lach:

---

Die AmigaOS/68k Binaries wurden per Cross-Compiler gebaut (und entwickelt). Kann man sehr schön mit -v sehen ;-)

---

Glaube ich Dir ja, aber mein Versuch, nen Cross-Compiler zu bauen schlug halt ein bißchen fehl

Schade eigentlich, denn sonst wäre der auch mit der StormC-IDE einsetzbar gewesen (ich hab versucht, den aus den StormC-Quellen zu bauen. Die Fehlermeldungen hat er sogar in der IDE ausgegeben, aber was hilfts, wenn er schon unter simpelsten Umständen keinen ordentlichen Code erzeugt? (Unknown Identifier) )

Grüße

Zitat:

---

Original von Holger:
Dann warte erstmal, bis dieses Projekt die Features einer Software ala Mozilla hat, und schau dann wie die Wartung und Weiterentwicklung dieser Software voranschreitet. Oder ob der Author es bis dahin nicht schon längst hingeschmissen hat, evtl. mit der "großzügigen" OpenSource-Abgabe an die Community, wie bereits mit so vieler Software geschehen.

---

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:

Zitat:

---

Als Amiga-User ist man anderes "gewöhnt". SAS/C habe ich nie in den Fingern gehabt, aber MaxxonC++ und StormC "fühlten" sich deutlich besser an als eine "nackte" GCC-Installation... mit dem Unterschied, daß der enthaltene Compiler nun eben nur einen Teil der Sprache beherrschte.

---

StormC4 noch nicht angesehen, wie?

---

Was willst Du damit sagen?
Ist StormC4 nicht besser als eine nackte gcc-Installation?
Was ich von StormC bisher gesehen habe, war schlimm, aber sooo schlimm nun auch wieder nicht.

---

Im Gegenteil. Ich wollte damit sagen, das StormC4 eigentlich genau seinen Geschmack treffen müßte. GCC mit ner netten, leicht zu handhabenden IDE dazu, (leider nur) internes CVS, paar nette andere Tools... was will man denn mehr? Okay, den GCC 3.3 statt den 2.95.2, aber das wäre kein so großer Akt denke ich, wenn sich gni mal dransetzen würde, um die StormC-Targets für den 3.3 zu implementieren. Source ist ja vorhanden.

Hätt ich den Durchblick beim GCC hätte ich das schon längst getan. Aber mein Ausflug in Sachen ARM-GCC (Crosscompiler) hat mir gereicht...:lach:

Und was bitte ist denn so schlimm am Storm? Das einzige, was mich bisher gestört hat war das Verschwinden der globalen Variablen im Debugger bei 68K-Programmen, sonst konnte ich nichts Nachteiliges entdecken. Ich konnte da aber immer etwas erreichen, wenn ich auf den StormC3 zurückgeschaltet habe. Alles, was ich bisher gemacht habe, ist mit Hilfe von StormC4 entstanden. Darunter z.B. die Amiga-Version des CC65 (die einzige Änderung, die nötig war, war die "Auslöschung" des unheiligen fork() ), EliteTNK in einer frühen Fassung etc.

Wenn ich mich recht entsinne, sind auch die ersten Versionen von GhostScript 8 auf dem StormC4 compiliert worden. Irgendwo habe ich die Projektdateien noch. Lief wunderbar mit dem Storm.

Versteh sowieso nicht, warum so viele Leutz über den StormC4 jammern, aber das ist ja wohl schon bekannt...

Grüße

Zitat:

---

Original von Solar:

Das Problem am Amiga-GCC ist, daß er für viele Amiganer zu "Unixoid" war und evtl. immer noch ist. Ich erinnere mich, daß ich schon deutliche Schwierigkeiten hatte, den GCC von der damaligen GeekGadgets vernünftig installiert zu bekommen.

Als Amiga-User ist man anderes "gewöhnt". SAS/C habe ich nie in den Fingern gehabt, aber MaxxonC++ und StormC "fühlten" sich deutlich besser an als eine "nackte" GCC-Installation... mit dem Unterschied, daß der enthaltene Compiler nun eben nur einen Teil der Sprache beherrschte.

---

StormC4 noch nicht angesehen, wie?

Grüße

Zitat:

---

Original von Maja:
@ dante

> , auf Portierungen aus dem Windows/Linux-Umfeld wären
> wir "eigentlich" nicht angewiesen...

Du hast zwar schon nicht ohne Grund eigentlich in Anführungszeichen gestellt, aber trotzdem ....

*dazwischenfrag*

Was wäre denn einfacher bzw. weniger Aufwändig? Zum Beispiel TurboCalc in Sachen Funktionsumfang auf die Höhe von OpenOffice zu bringen oder OpenOffice auf AmigaOS(4) zu portieren?

---

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Wenn allerdings jemand behauptet, ohne entsprechende Plattformen oder "Technologien" wäre kein Geld zu machen, der weiß schlicht und ergreifend nicht, wie Märkte funktionieren.

---

Das hat auch niemand behauptet.
Es ist nur wesentlich einfacher, Software unter Verwendung bestimmter Technologien zu entwickeln. Und ein solcher Vorteil würde auch dem Amiga gut tun.

---

Zitat:

---

In Grundzügen bereits da und nicht mehr weit sind zwei verschiedene Dinge und zudem noch äußerst dehnbare Begriffe.

---

Zitat:

---

Abgesehen davon, ist es ja nicht so, daß ich mir das Projekt nicht schon angesehen hätte, leider ist es weder in Assembler, noch in Java, es ist in _C_. Und das ist nicht so meine Welt. Außerdem, wenn man täglich mehrere Stunden programmieren muß, hat man nicht so viel Bedürfnis, in der Freizeit auch noch dasselbe zu tun.

---

Zitat:

---

Original von Solar:

Ach Menno... wieso mußt Du uns mit sowas profanem wie sachlichen Argumenten stören? ;-)

Nein, ich halte es tatsächlich für ausgeschlossen, das man mit Amiga-spezifischen Entwicklungen noch Geld verdienen kann. Vielleicht kann man die eine oder andere Lizenz verkaufen, aber ich glaube einfach nicht, daß sich geleisteter Entwicklungsaufwand noch rentiert.

---

Sry

Hm, da gibts ein paar sehr innovative Produkte, die verkauft und weiterentwickelt werden. Ich rede da bspw. von USB. Rentiert im Sinne von "unterm Strich ist was übriggeblieben" hat sichs bestimmt. Das man davon nicht gerade prall leben kann, habe ich ja bereits angedeutet.

Im übrigen: Mein Posting ging nicht speziell an Deine Adresse Gibt ja noch ein paar Profis mehr hier.

Zitat:

---

Habe ich nie behauptet. Assembler macht durchaus Sinn - bei identifizierten zentralen Flaschenhälsen, oder im Custom-Embedded-Bereich.

Wogegen ich argumentiere ist der Tenor, "wozu Java und .NET (und Perl und Ruby und Python und...), MaxxonBasic und ASMPro (und vielleicht noch GCC) sind alles, was wir brauchen".

---

Wie gesagt, es ging nicht speziell an Dich. Und was das Thema "ASMPro etc. pp. ist alles was wir brauchen" betrifft, hab ich doch auch etwas entsprechendes gesagt, oder?

Zitat:

---

Nein, natürlich nicht, dafür sind sie ja da: Damit sich nicht eine Vielfalt von C-"Standards" breit macht, sondern ein C-Programm mit jedem C-Compiler übersetzt werden kann. Gleiches für andere Sprachen.

Beachte bitte, daß ich nicht von Java oder irgendeiner anderen Sprache als allein seligmachend rede. Aber eine Sprache ohne Standard - POSIX, ISO, ANSI, ECMA, proprietär, oder sonstwas - ist so gut wie wertlos.

Erst ein Standard in irgendeiner Form gibt mir die Sicherheit, daß meine Arbeit auch mit der nächsten Compilerversion noch läuft, und mein angeeignetes Know-How nicht mit dem nächsten Plattformwechsel zum Teufel geht.

---

Zitat:

---

Zitat:

---

Denkt einfach mal an das Thema "Software-Patente".

---

Das hat mit Sprachstandards nicht das Geringste zu tun. (Und nebenbei engagiere ich mich aktiv gegen SW-Patente.)

---

Zitat:

---

Fragt mal chkamiga, ob er mit seinen heeren ASM-Kenntnissen nicht einen JIT für die Jungs zusammenstrickt...

Ich für meinen Teil habe schon genug andere Projekte zu laufen. Schöner, portierbarer C/C++-Code, läuft (dank Standardbibliothek) auf jeder Plattform...

---

Ich hoffe, da sind keine POSIX-abhängigkeiten drin? Und das mit chk isn guter Witz

Grüße

Zitat:

---

Original von platon42:
...

---

Ohne Worte!

Danke Dir für die enorm detailreiche Erläuterung. Nu hab ichs begriffen. Die Zeichnerei spielt sich immer in einem kleinen Bereich des Chiprams ab, nur die Ausgangsposition des Scrollings wird jedesmal verschoeben, so daß das Bild andauern an anderer Position neu entsteht. Je nach dem, wo man gerade mit dem Scrolling ist. Genial! Danke Dir auch für den Link. Diese Technik werde ich als positives Beispiel für die Möglichkeiten der Amiga-Customchips anführen. Damit auch die Jünger der "Scrolling durch brutale Busgeschwindigkeit"-Fraktion einmal sehen, was man mit einem lahmen Systembus alles erreichen kann wenn man das Drumherum genial entwirft.

Grüße

Zitat:

---

Original von platon42:

Nein, es findet eben kein Kopieren statt (außer eben für das Zeichnen der reingescrollten Randbereiche), und tatsächlich wird für die Displayhardware das Chipram "virtuell" umgekrempelt, weil der Copper ja an jeder beliebigen Bildschirmposition Register ändern kann -- wie bei Turrican z.B. die vier Bitplanepointer, um an z.B. in Zeile 172 den Bildschirmspeicher wieder von oben anfangen zu lassen.

---

Ah ja Wie hat man sich das technisch vorzustellen? Ich hab da im Moment keine konkrete Vorstellung davon, wie der Copper das dann handhabt. Irgendwie müssen die Bilddaten, die sich durch das Scrolling ja verändert haben, wieder an eine bestimmte Startposition für das Scrolling gebracht werden um neu Zeichnen zu können. Wie macht der das konkret, ohne die Bilddaten wieder an die Scrollposition 0 zu kopieren? Im Moment kann ich mir das nur so vorstellen, daß das übergroße Display technisch gesehen durch das gesamte Chipram "durchwandert". Wäre nett wenn Du mir das mal erläutern könntest, wahlweise auch per Mehl, das wäre nämlich prima Futter für meine Artikelreihe. Auch mal etwas für die Nicht-GraKa-Besitzer

Grüße

Zitat:

---

Original von platon42:

Zitat:

---

Original von eye-BORG:
Nein, tile-basierende Games haben immer den Screen geswapt und komplett neu gezeichnet.

---

Heh, das wäre ja lustig und ziemlich doof -- das waren dann solche Games, die nur 25fps hatten...

---

Nein, im Gegenteil

Ist natürlich bissi sehr verallgemeinert mit dem "komplett neuzeichnen", aber im Grunde war und ists schon so. Ein vernünftig geproggtes Tile-Game arbeitet nur auf veränderte Bereiche, das bedeutet, daß nur veränderte oder (von Sprites) überschriebene Tiles neu gezeichnet werden, Kopieroperationen werden mit dem Blitter im Backbuffer durchgeführt. Das geht bedeutend fixer als man manchmal glaubt. Bei AsteroidsTR wird im Scroll-Zyklus der komplette Bildinhalt mit dem Blitter umkopiert, das erreicht locker 75 Frames auf ner CVPPC...

Zitat:

---

Bei 8-Wege-Scrolling kann man einen minimal größerer Screen verwenden als der sichtbare, man braucht also *nicht* einen vier mal größeren Screen und dann horizontal und vertikal vierfach Updaten. Der Trick war, dass man einfach per Copper den Screen vertikal gewrappt hat: Sprich, wenn man nach unten gescrollt hat, und man nun eigentlich Speicher von "weiter unten" anzeigen müsste, wird an der Bildschirmzeile, an der der Speicher zuende ist der Anfang des Bildschirmspeichers wieder angezeigt. Horizontales Scrolling kann man dann auch beliebig in beide Richtungen machen, ohne dass man irgendwie irgendwas groß kopieren müsste.

---

Ich hoffe mal ich stelle jetzt keine dumme Frage:

Ist das nicht auch nur eine Art, den kompletten Bildspeicher mit dem Blitter zu kopieren? Ich meine, das klingt für mich so, als würde der Blit letztendlich mit Hilfe des Coppers durchgeführt, statt das Ganze vom Programm selbst aus zu steuern. Liege ich da richtig? Ich mein, man kann ja das Chipram schlecht "umkrempeln", oder?


Grüße

Zitat:

---

Original von dante:
whose, du hast mein Posting scheinbar nicht gelesen. Oder nicht verstanden? Der Aufbau des nächsten Bildes erfolgt im VB-IRQ, mit diesen Blits von jeweils ein paar Tiles, wie oben beschrieben. Glaubs mir, das funktioniert, hab ich schon so programmiert... auch wenns lange her ist, ich kann mich erinnern.

Ich glaub, ich hack gleich mal nen Example in BB2 zurecht, wenn du es mir weiterhin nicht glaubst.

[ Dieser Beitrag wurde von dante am 19.06.2004 editiert. ]

---

Na, ich glaub Dir ja, daß das funktioniert. Ich werde aber das Gefühl nicht los, daß Du das im Singlebuffering machst. Scrollt dann zwar nett, aber animierte Sprites oder gar Tile-Animationen dürften dann etwas flackernd wiedergegeben werden.

Daß Du einen 2. Buffer im Hintergrund mit dem "im Voraus" gescrollten Bild füllst ist ja nun nicht gerade Doublebuffering im herkömmlichen Sinn, eher Caching

Sollte ich das immer noch nicht richtig verstanden haben, hack uns doch bitte das Beispiel zusammen. Schließlich lernt man ja nie aus Bisher habe ich als beste Lösung das Scrollen bis zum Ende der zusätzlichen Tiles und dann Umkopieren des gesamten Bildes auf Position 0 angenommen. Ermöglichte sogar schon auf dem C64 Scrolling UND Doublebuffering.

Grüße

Zitat:

---

Original von dante:

Eine Tile-Engine auf Amiga: Screengrösse 320x256. Tilegrösse 32x32. Ergo: Screengrösse=10 Tiles x 8 Tiles. Im einfachsten Fall werden für Scrolling nun 2 Bitmaps obiger Grösse angelegt + oben, unten, links und rechts jeweils 1 Tilespalte / -zeile , also 12x10 Tiles. Nun wird hardwaremässig gescrollt in die zusätzliche Tilereihe/spalte hinein oder hinaus, gleichzeitig wird abhängig von der Richtung die andere Bitmap im VB-IRQ refreshed, Und bei einer Tilesize von 32x32 hat man ordentlich Zeit, da es ja bei 1-Frame-Scrolling 32 Frames dauert, bis eine neue Tile-Reihe/Spalte sichtbar ist, man kann sich also pro Frame damit begnügen, im VB-IRQ meinetwegen 4 Tiles zu blitten. Das bedeutet eine konstante aber geringe Belastung hauptsächlich für den Blitter.

---

Zitat:

---

Was GMB damit sagen wollte: Der *Anschluss* für das onboard-SCSI Interface im A4000T ist *nicht* auf dem Mainboard, sondern auf dem IO-Modul. Dass der A4000T SCSI hat, hat GMB nie bezweifelt.
--
--
Best Regards

Chris Hodges

---

Sry, da hab ich ihn mistverstanden. Kenne den A4000T leider nicht aus eigener Erfahrung. Alles, was ich weiß ist, daß der durchaus SCSI onboard hat. Wie das nun genau aussieht, wußte ich halt nicht. Aber jetzt weiß ichs

Grüße

P.S.: Trotzdem wären Bilder von dem Kuddelmuddel enorm hilfreich

Zitat:

---

Original von Maverik:
Der Orginal Tower hat schon immer IDE und SCSI.
Ab der Seriennummer 1 :-)
--
-------------------------------------
mfg

Andreas

---

Der 4000er, ja (hab grad mal bei BBOAH nachgeschaut). Der 3000er nur SCSI. Ich muß das wissen, hab ja einen . Leider keinen 4000T

Zitat:

---

Original von GMB:

Zitat:

---

Original von GMB:
3. Auf dem Motherboard selbst ist ein SCSI Anschluss, sondern nur ein IDE (rechts oben) und 2 fuer die Ports (Ser,Par,Joy,Mouse), welche sich am linken Rand unterhalb der Stromversorgung befinden.
Diese verbinden mit 2 kurzen Kabeln die Portplatine.

---

ARGL.,

das muss natuerlich wie folgt heissen:

3. Auf dem Motherboard selbst _KEIN_ SCSI Anschluss, sondern ...

---

Wenn es tatsächlich ein 4000T (Tower) ist, dann war das erste schon ganz richtig

Die (Original) Tower-Versionen von A3000/A4000 waren mit Onboard-SCSI ausgestattet anstatt IDE.

Trotzdem ist seine Beschreibung ziemlich konfus. Wie wärs mit ein paar Bildern? Dann könnte man sich ein paar tausend Worte sparen

Grüße

Zitat:

---

Original von gni:
K.A. was ihr mit euren GCC Installationen veranstaltet. Wenn Ihr keine Hilfe benötigt, ist ja gut.

---

Zitat:

---

Zitat:

---

Sagt Dir die Option "do-inline" was?

---

Nie gehört. Aber gut, ich kenne den GCC auch nicht so gut wie Du...

---

Zitat:

---

Zitat:

---

Übrigens: Hat nicht H. Wrobel den ersten Port des 3.x erledigt?

---

Wozu der Smiley?

---