amiga-news DEUTSCHE VERSION
.
Links| Forums| Comments| Report news
.
Chat| Polls| Newsticker| Archive
.

amiga-news.de Forum > Programmierung > Sortieren [ - Search - New posts - Register - Login - ]

1 -2- [ - Post reply - ]

2004-01-28, 16:00 h

Mad_Dog
Posts: 1944
User 		Das beste ist eh, man hold sich die AmigaOS Developer CD 2.1.
Dort hat man die ganzen RKM's, Autodocs, Tonnen von Beispielcode und obendrein noch die Vollversion von StormC 3.0.

--

http://www.norman-interactive.com

[ - Answer - Quote - Direct link - ]
2004-01-28, 17:57 h

Solar
Posts: 3680
User
Zitat:
Original von Mad_Dog:

gcc steht unter GPL.

Das ist etwas ganz anderes als "PD"...

[ - Answer - Quote - Direct link - ]
2004-01-28, 18:52 h

Ralf27
Posts: 2779
User
Zitat:
Original von dante:
Es ist schon etwas haarig, gcc zu installieren. Als Einsteiger in die Materie ist auf Amiga wohl am ehesten das GoldEd-Package zu empfehlen, da ist ein komplettes gcc-Paket dabei. Guckst du hier: http://golded.dietmar-eilert.de/ . Ist aber Löhnware. :D

Und wenn man MaxonBasic benutzt, sollte der Umstieg auf c/c++ doch nun wirklich leicht fallen! Ich bin damals vor dem Teil zurück geschreckt, das war mir zuwenig Basic... :)


Wenn man AmigaBasic kann, dann kann man direkt 100%tig gleich in MaxonBasic programmen, weil es einfach gleich ist. Genau so sieht es auch mit QBasic für DOS aus. Nur die Befehle z.b. für Screen sieht logischerweiße anderst aus, aber der Rest ist 100%tig gleich.

Nur hat MaxonBasic auch einige Erweiterungen wie z.b. TAGLISTS (ab OS2.04) oder z.b. Hook.
Ich hab sogar schon MaxonBasic-Listen gesehn die ich gar nicht verstanden habe, weil da viel mit TAGLISTs und dergleichen abgeht, mit dem ich nichts am Hut habe.

Leider ist es so das ich damals zum Amiga über ein Kumpel gekommen bin der auch gleich auf PC umgestiegen ist und damals nur gespielt habe. Alles was ich weiß über den Amiga und das programmieren habe ich mir selbst beigebracht. Und ich kenne auch keinen der einen Amiga hat (seit zu langer Zeit). Ohne das Internet wäre ich wohl auch vor ca. 10 Jahren vom Amiga "gegangen".
Ich will damit eigentlich nur tippen das es alleine schon schwierig ist sowas neues zu lernen wie eine neue Programmiersprache, aber ich geb mir mühe wenn ich mich dazu überreden kann. ;-)
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]
2004-01-28, 19:03 h

dante
Posts: 111
User
Zitat:
Original von Ralf27:
Wenn man AmigaBasic kann, dann kann man direkt 100%tig gleich in MaxonBasic programmen, weil es einfach gleich ist. Genau so sieht es auch mit QBasic für DOS aus. Nur die Befehle z.b. für Screen sieht logischerweiße anderst aus, aber der Rest ist 100%tig gleich.

Siehste, AmigaBasic hatte ich nie, ich bin damals vom C64 zum A600 gekommen, und meine erste Software-Käufe fürn Amiga hiessen MaxonASM und BlitzBasic. :P Hab ich auch nie bereut, Blitz pack ich heute noch gerne aus, wenn ich fix mal was probieren will.


Zitat:
Nur hat MaxonBasic auch einige Erweiterungen wie z.b. TAGLISTS (ab OS2.04) oder z.b. Hook.
Ich hab sogar schon MaxonBasic-Listen gesehn die ich gar nicht verstanden habe, weil da viel mit TAGLISTs und dergleichen abgeht, mit dem ich nichts am Hut habe.

Eben, ich hab damals, als MaxonBasic rauskam, bei den Testberichten und auch Beispiellistings erstaunt geguckt - MaxonBasic sah imo aus wie C mit Basic-Syntax. ;)

Zitat:
Ich will damit eigentlich nur tippen das es alleine schon schwierig ist sowas neues zu lernen wie eine neue Programmiersprache, aber ich geb mir mühe wenn ich mich dazu überreden kann. ;-)

Ich bin ja der Meinung, kennt man eine, kennt man alle. :) Also, wenn man in Basic, Asm oder was weiss ich in der Lage ist, Programme zu schreiben, kann man das auch in C, Java etc... Man weiss ja, was man will, nur die Syntax unterscheidet sich hier und dort. Und dafür kann man ja in einer help-datei oder im Inet oder so nachgucken.


[ - Answer - Quote - Direct link - ]
2004-01-28, 22:28 h

Holger
Posts: 8116
User
Zitat:
Original von Ralf27:
Mir hat mal ein PC-Programmierer[...] mir mal auf einem 2,4GHz-Pentium sein VisualBasic vorgeführt.

Hey, das ganz war so Arsch langsam! Selbst compiliert! Sorry, aber da zieht MaxonBasic auf meinem kleinen Amiga ab wie eine Rakete!

(Das Testprogramm zeichnete einfach auf den Bildschirm einige Punkte dessen Farbwert mit SIN/COS errechnet worden ist)
Ich gehe mal davon aus, daß Dein Testprogramm in einer Schleife alle Pixel mit Farbwerten setzt. Damit bist Du in eine typische Falle moderner Rechnerarchitekturen gelaufen.

Auf dem C64 bedeutete das Setzen eines Pixels das Schreiben in eine Speicherzelle des Hauptspeicher, das war trivial.

Auf dem classic-Amiga bedeutete es schon den Aufruf einer Betriebssystemfunktion, die das Clipping und die Berechnung der tatsächlichen Speicheradresse aus der relativ zum Fenster angegebenen Position übernimmt und einen Zugriff auf das tendenziell langsamere Chip-RAM ausführt.

Auf modernen Rechnerarchitekturen und das wird neuere Amigas mit einschließen, bedeutet das Setzen eines Pixels:
  • Kontextwechsel in's Betriebssystem (nötig wegen Speicherschutz und Zugriffsrechten für Hardwaretreiber)
  • Ermittlung des zuständigen Treibers
  • Abschicken des Befehls an den Treiber
  • Clipping, Berechnung der tatsächlichen Speicheradresse, Konvertierung der Farbangabe in das Pixelformat der Grafikkarte
  • Zugriff auf den Speicher der Grafikkarte (Ziemlich langsam im Vergleich zum Hauptspeicher)

    Schon auf dem Amiga gehörte es zu den Optimierungsempfehlungen, niemals einzelne Pixel zu schreiben, sondern einen Puffer zu füllen und diesen in einem Rutsch übertragen zu lassen. Das gilt heute noch viel mehr.

    Aus diesem Grund gibt es in moderneren APIs (z.B. Java) erst gar keine
    Funktion zum Setzen eines einzelnen Pixels. Auf die Art wird verhindert, daß der Programmierer in diese Falle tappt und die Plattform dafür verantwortlich macht.

    Man sollte vielleicht auch nicht unerwähnt lassen, daß einen kompletten Bildschirm mit Farbe zu füllen auf dem C64 ~1kB, auf dem AGA-Amiga ~300kB und auf einem aktuellem Rechner ~2-3MB Speicher füllen muß.
    Sowohl auf dem Amiga, als auch auf dem PC benutzt man dafür vorzugsweise einen grafischen Coprozessor.
    Füllt man den Bildschirm aber mit einzelnen Prozessorbefehlen, ist der
    Copro nutzlos.

    Das mal zur Ehrenrettung von VB. Ich mag VB auch nicht, halte aber noch weniger von Pauschalverurteilungen.

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.

    [ - Answer - Quote - Direct link - ]

    		•
    2004-01-28, 23:11 h

    Ralf27
    Posts: 2779
    User
    Zitat:
    Original von Holger:
    Zitat:
    Original von Ralf27:
    Mir hat mal ein PC-Programmierer[...] mir mal auf einem 2,4GHz-Pentium sein VisualBasic vorgeführt.

    Hey, das ganz war so Arsch langsam! Selbst compiliert! Sorry, aber da zieht MaxonBasic auf meinem kleinen Amiga ab wie eine Rakete!

    (Das Testprogramm zeichnete einfach auf den Bildschirm einige Punkte dessen Farbwert mit SIN/COS errechnet worden ist)
    Ich gehe mal davon aus, daß Dein Testprogramm in einer Schleife alle Pixel mit Farbwerten setzt. Damit bist Du in eine typische Falle moderner Rechnerarchitekturen gelaufen.

    Auf dem C64 bedeutete das Setzen eines Pixels das Schreiben in eine Speicherzelle des Hauptspeicher, das war trivial.

    Auf dem classic-Amiga bedeutete es schon den Aufruf einer Betriebssystemfunktion, die das Clipping und die Berechnung der tatsächlichen Speicheradresse aus der relativ zum Fenster angegebenen Position übernimmt und einen Zugriff auf das tendenziell langsamere Chip-RAM ausführt.

    Auf modernen Rechnerarchitekturen und das wird neuere Amigas mit einschließen, bedeutet das Setzen eines Pixels:
  • Kontextwechsel in's Betriebssystem (nötig wegen Speicherschutz und Zugriffsrechten für Hardwaretreiber)
  • Ermittlung des zuständigen Treibers
  • Abschicken des Befehls an den Treiber
  • Clipping, Berechnung der tatsächlichen Speicheradresse, Konvertierung der Farbangabe in das Pixelformat der Grafikkarte
  • Zugriff auf den Speicher der Grafikkarte (Ziemlich langsam im Vergleich zum Hauptspeicher)

    Schon auf dem Amiga gehörte es zu den Optimierungsempfehlungen, niemals einzelne Pixel zu schreiben, sondern einen Puffer zu füllen und diesen in einem Rutsch übertragen zu lassen. Das gilt heute noch viel mehr.

    Aus diesem Grund gibt es in moderneren APIs (z.B. Java) erst gar keine
    Funktion zum Setzen eines einzelnen Pixels. Auf die Art wird verhindert, daß der Programmierer in diese Falle tappt und die Plattform dafür verantwortlich macht.

    Man sollte vielleicht auch nicht unerwähnt lassen, daß einen kompletten Bildschirm mit Farbe zu füllen auf dem C64 ~1kB, auf dem AGA-Amiga ~300kB und auf einem aktuellem Rechner ~2-3MB Speicher füllen muß.
    Sowohl auf dem Amiga, als auch auf dem PC benutzt man dafür vorzugsweise einen grafischen Coprozessor.
    Füllt man den Bildschirm aber mit einzelnen Prozessorbefehlen, ist der
    Copro nutzlos.

    Das mal zur Ehrenrettung von VB. Ich mag VB auch nicht, halte aber noch weniger von Pauschalverurteilungen.

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.


    • Ich war halt eben überrascht das es auf diesem System so langsam ist. Ich dachte mir auch das die Amigagrafik eh sau langsam ist im verleich zu heutigen aktuellen Grafikkarten und das aufgrund dessen das auch die CPU um etliche Faktoren schneller ist auch das Programm mindestens genau so schnell sein müßte, aber eher eigentlich um zig Faktoren schneller auf dem System, wobei auch noch die Programmiersprache auf dem PC wesentlich aktueller ist. MaxonBasic ist ja auch schon 10 Jahre alt...

    Aber mal interessenhalber:
    Wenn ich auf dem Amiga ein Punkt setze dann muß die Systemroutine z.b. bei 8 Bitplanes jedes einzelne Bit berechnen und setzen und jedes Bit dabei ist bei einem anderen Byte. (Bitplanes eben) Beim PC sind es üblicherweiße Chunky-Grafikkarten und da liegt der Pixel bei z.b. 4 hintereinanderliegenden Bytes(Long, 32Bit, ideal).
    Kurzum, ich kann mir wirklich kaum vorstellen das eigentlich in der Theorie eine so überlegende Hardware so ein Ergebniss abliefert.

    Ok, man sollte nicht jedes Pixel einzeln ansprechen, was man auch auf dem Amiga nicht machen sollte. Aber ein netter Performenstest war es wie ich finde dennoch.

    Eine Frage am Rande: Wie würdest Du unter VB ein Bild mit einzelnen Punkten generieren und zur Grafikkarte transverieren?


    Achja, nochwas: Er hat mir auch einige Programme von sich in VB gezeigt die auch nicht gerade die hohe Power zeigten. Ich konnte z.b. teilweise denn Bildschirmaufbau verfolgen. Auf einem 2,4GHz-PC mit WinXP. Ok, da lief es wohl gerade im Interpretermodus, aber dennoch.
    --
    http://www.alternativercomputerclub.de.vu

    [ - Answer - Quote - Direct link - ]
    2004-01-29, 05:23 h

    Mad_Dog
    Posts: 1944
    User
    Zitat:
    Original von Solar:
    Zitat:
    Original von Mad_Dog:

    gcc steht unter GPL.

    Das ist etwas ganz anderes als "PD"...

    Ja stimmt. Trotzdem ist es für den Endanwender kostenlos.



    --

    http://www.norman-interactive.com

    [ - Answer - Quote - Direct link - ]
    2004-01-29, 06:30 h

    Solar
    Posts: 3680
    User
    Zitat:
    Original von Mad_Dog:
    Zitat:
    Original von Solar:
    Zitat:
    Original von Mad_Dog:
    gcc steht unter GPL.
    Das ist etwas ganz anderes als "PD"...
    Ja stimmt. Trotzdem ist es für den Endanwender kostenlos.

    Trotzdem paßte Deine Antwort nicht zu meiner Frage, und tut es immer noch nicht. Ich suche nicht nach kostenlosen Compilern, sondern wirklich freien (sprich, PD) Compilern.

    [ - Answer - Quote - Direct link - ]
    2004-01-29, 06:47 h

    Mad_Dog
    Posts: 1944
    User
    Zitat:
    Original von Solar:
    Ich suche nicht nach kostenlosen Compilern, sondern wirklich freien (sprich, PD) Compilern.

    Der Begriff "PD" ist was zeimlich schwammiges. Bei vielen PD Programmen darf das fertig compilierte Programm und die Daten (unverändert) weitergeben. Der Sourcecode bleibt oft beim Urheber und wird - wenn überhaupt erst nach Jahren veröffenlicht, wenn das Projekt schon längst nicht mehr weiterentwickelt wird. Oft ist es dann auchnoch so, daß diese PD-Projekte nicht ohne Genehmigung z.B. auf kommerziellen CDs vertrieben werden dürfen, etc. .

    Bei GNU hast Du wenigstens die Möglichkeit, bei Bedarf den Sourcecode einzusehen, anzupassen, zu verändern und zu portieren.

    Und daß "Compilerbau" eine Wissenschaft für sich ist, brauche ich Dir bestimmt nicht zu erzählen.

    Für meinen Geschmack gibt's auf dem Amiga zumindest was C und C++ angeht immernoch genug (relativ) gute Compiler - entweder kostenlos oder zu einem vertretbaren Preis.


    --

    http://www.norman-interactive.com

    [ Dieser Beitrag wurde von Mad_Dog am 29.01.2004 editiert. ]

    [ - Answer - Quote - Direct link - ]
    2004-01-29, 09:09 h

    Solar
    Posts: 3680
    User
    Zitat:
    Original von Mad_Dog:
    Der Begriff "PD" ist was ziemlich schwammiges.

    Im Gegenteil, Public Domain ist sehr genau definiert, und das sogar vom Gesetzgeber, statt von irgendeiner "Foundation": Public Domain bedeutet, das niemand auf das fragliche Material ein Copyright hält, und Du damit ohne Einschränkungen machen kannst, was Dir gefällt.

    Zitat:
    Bei vielen PD Programmen darf das fertig compilierte Programm und die Daten (unverändert) weitergeben.

    Das darfst Du bei allen PD-Programmen, ob mit oder ohne Änderungen.

    Zitat:
    Der Sourcecode bleibt oft beim Urheber und wird - wenn überhaupt erst nach Jahren veröffenlicht, wenn das Projekt schon längst nicht mehr weiterentwickelt wird.

    Sache des Urhebers. Wobei das dann eher Freeware wäre - PD impliziert eigentlich die Verfügbarkeit von Quellcode.

    Zitat:
    Oft ist es dann auchnoch so, daß diese PD-Projekte nicht ohne Genehmigung z.B. auf kommerziellen CDs vertrieben werden dürfen, etc. .

    Unsinn. PD ist PD, da gibt es keine Einschränkungen. Was Du meinst, sind einige heute eher "exotische" Lizenzvereinbarungen, wie sie früher gerne verwendet wurden. PD hingegen bedeutet eben die Abwesenheit solcher Lizenzvereinbarungen.

    Zitat:
    Bei GNU hast Du wenigstens die Möglichkeit, bei Bedarf den Sourcecode einzusehen, anzupassen, zu verändern und zu portieren.

    Die habe ich bei PD (im Gegensatz zur Freeware, die zwar umsonst aber nicht Open Source ist) ebenfalls.

    Nur paßt mir die GPL nicht, darüm wurde ich beim Stichwort "PD-Compiler" hellhörig.

    Zitat:
    Und daß "Compilerbau" eine Wissenschaft für sich ist, brauche ich Dir bestimmt nicht zu erzählen.

    Nein. Ich habe das Drachenbuch hier, würde es aber vorziehen, einen PD-Compiler zu finden, statt selbst einen zu bauen.

    Zitat:
    Für meinen Geschmack gibt's auf dem Amiga zumindest was C und C++ angeht immernoch genug (relativ) gute Compiler - entweder kostenlos oder zu einem vertretbaren Preis.

    Und nochmal, es ging mir nicht um einen billigen Compiler, und auch nicht um einen Compiler für den Amiga, sondern um einen PD-C++-Compiler.

    Deinen Ausführungen entnehme ich also, daß Du auch keinen weißt.

    [ - Answer - Quote - Direct link - ]
    2004-01-29, 09:18 h

    Mad_Dog
    Posts: 1944
    User
    Zitat:
    Original von Solar:
    Zitat:
    Original von Mad_Dog:
    Der Begriff "PD" ist was ziemlich schwammiges.

    Im Gegenteil, Public Domain ist sehr genau definiert, und das sogar vom Gesetzgeber, statt von irgendeiner "Foundation": Public Domain bedeutet, das niemand auf das fragliche Material ein Copyright hält, und Du damit ohne Einschränkungen machen kannst, was Dir gefällt.

    Mag sein, daß da der Gesetzgeber irgendwas definiert hat. Aber in der Praxis wird meist sehr schwammig mit diesen Begriffen umgegangen.
    Man denke nur mal an das Aminet oder damals die diversen PD-Diskettenserien...

    Zitat:
    Deinen Ausführungen entnehme ich also, daß Du auch keinen weißt.

    Wie gesagt: Wenn Dir GPL nich frei genug ist, heißt meine Antwort: "Nein".


    --

    http://www.norman-interactive.com

    [ - Answer - Quote - Direct link - ]
    2004-01-29, 09:35 h

    platon42
    Posts: 400
    [Former member]     		Je nach Eingabedaten:
    Quicksort (schlechte Worst Case Laufzeit von O(n^2), da hilft random Quicksort dagegen, braucht aber keinen zusätzlichen Speicher)
    Mergesort/Heapsort O(n log n), braucht aber zusätzlichen Speicher und es kommt insgesamt auf die Größe an.

    Ansonsten, wenn der Zahlenraum ziemlich begrenzt ist:
    Bucket Sort: O(n+m) (m Größe des Alphabets)
    Forward Radix Sort with Groups: so ziemlich das schnellste, was Du hinkriegen kannst, liegt fast bei linearer Laufzeit, ist aber ziemlich kompliziert und man braucht ggf. lange, um es korrekt zu implementieren.
    --
    --
    Best Regards

    Chris Hodges

    [ - Answer - Quote - Direct link - ]
    2004-01-29, 10:03 h

    Solar
    Posts: 3680
    User
    Zitat:
    Original von platon42:
    Mergesort/Heapsort O(n log n), braucht aber zusätzlichen Speicher und es kommt insgesamt auf die Größe an.

    Siehe mein Posting von 27.01.2004, 10:30 Uhr... nach Holger's Links verhalten sich Mergesort und Heapsort durchaus unterschiedlich.

    [ - Answer - Quote - Direct link - ]
    2004-01-30, 11:09 h

    Holger
    Posts: 8116
    User
    Zitat:
    Original von Ralf27:
    Aber mal interessenhalber:
    Wenn ich auf dem Amiga ein Punkt setze dann muß die Systemroutine z.b. bei 8 Bitplanes jedes einzelne Bit berechnen und setzen und jedes Bit dabei ist bei einem anderen Byte. (Bitplanes eben) Beim PC sind es üblicherweiße Chunky-Grafikkarten und da liegt der Pixel bei z.b. 4 hintereinanderliegenden Bytes(Long, 32Bit, ideal).
    Kurzum, ich kann mir wirklich kaum vorstellen das eigentlich in der Theorie eine so überlegende Hardware so ein Ergebniss abliefert.
    Wenn Du tatsächlich alle 8 Bitplanes benutzt, also einen AGA-256-Farbbildschirm am besten auch in einer hohen Auflösung benutzt, dann kannst Du ja auch zugucken, wie er den Bildschirm füllt.
    Meine Ausführungen haben die durchzuführenden Operationen aufgezählt, aber offensichtlich nicht die Konsequenzen ausreichend beschrieben. Sonst würdest Du Dich nicht am Speicherformat aufhängen.
    Der Wechsel in das Betriebssystem ist die extremste Operation in dieser Kette. Die heutigen CPUs beziehen einen Großteil auf der parallelen Ausführung mehrerer Instruktionen. Betriebssystemaufrufe sind nicht parallelisierbar.

    Zitat:
    Eine Frage am Rande: Wie würdest Du unter VB ein Bild mit einzelnen Punkten generieren und zur Grafikkarte transverieren?
    Ich mußte bisher VB nicht benutzen *auf-holz-klopf*, soll besser so bleiben.

    mfg
    --
    Good coders do not comment. What was hard to write should be hard to read too.

    [ - Answer - Quote - Direct link - ]
    2004-01-30, 11:12 h

    Holger
    Posts: 8116
    User
    Zitat:
    Original von Mad_Dog:
    Mag sein, daß da der Gesetzgeber irgendwas definiert hat. Aber in der Praxis wird meist sehr schwammig mit diesen Begriffen umgegangen.
    Man denke nur mal an das Aminet oder damals die diversen PD-Diskettenserien...
    Die Gleichsetzung von PD und Freeware, bzw. der schwammige Umgang mit diesen Begriffen ist eine amiga-typische Eigenheit.

    mfg
    --
    Good coders do not comment. What was hard to write should be hard to read too.

    [ - Answer - Quote - Direct link - ]
    2004-01-30, 11:27 h

    Ralf27
    Posts: 2779
    User
    Zitat:
    Original von dante:
    Und wenn man MaxonBasic benutzt, sollte der Umstieg auf c/c++ doch nun wirklich leicht fallen! Ich bin damals vor dem Teil zurück geschreckt, das war mir zuwenig Basic... :)

    Nun, MBasic ist 100% gleich mit ABasic. Allerdings kann man in MBasic sachen machen die wären in ABasic unmöglich und diese Liste ist recht lang. So kann man wohl wirklich MBasic fast so aussehn lassen wie C. Allerdings versteh ich auch dann nicht denn Code on MBasic, wenn ich sowas irgendwo seh.. :-)

    Ich code MBasic als noch so wie vor 15 Jahren ABasic.


    I-) I-) I-)

    Back to the Roots!!! :lach: :lach: :lach:
    --
    http://www.alternativercomputerclub.de.vu

    [ - Answer - Quote - Direct link - ]
    2004-03-24, 00:09 h

    AND
    Posts: 9
    User
    Zitat:
    Original von platon42:

    Ansonsten, wenn der Zahlenraum ziemlich begrenzt ist:
    Bucket Sort: O(n+m) (m Größe des Alphabets)

    Das würde ich auch empfehlen. Habe es Seinerzeit, als ich das erste mal davon hörte (so 94), gleich mal auf meinem A500 ausprobiert.

    Bucketsort schlägt Quicksort und Co um Längen und ist sehr einfach zu implemnetieren. Eine Google-Suche hilft schnell weiter.

    Ausserdem ist Speicherplatz ja kein Problem. In diesem Fall benötigen alle Verfahren O(n), da das Orginalfeld ja gespeichert sein muss.

    Gruesse, Andre


    [ - Answer - Quote - Direct link - ]

    1 -2- [ - Post reply - ]


    amiga-news.de Forum > Programmierung > Sortieren [ - Search - New posts - Register - Login - ]


    .
    Masthead | Privacy policy | Netiquette | Advertising | Contact
    Copyright © 1998-2024 by amiga-news.de - all rights reserved.
    .