Mal was Allgemeines....

[Dr. Irata]

Hallo in die Runde!
Ich habe mal eine allgemeine Frage:
Nun bin ich schon fast 3 Jahre nach meinem Wiedereinstieg hier mehr oder weniger intensiv dabei, Programme mittels Assembler zu schreiben.
Ich habe mir als erstes Projekt gleich einen Shooter vorgenommen, als 2. ebenfalls, dann eine 3D-Engine entwickelt mit Ray-Casting (das Projekt läuft noch und pausiert gerade nur) - jetzt zur Zeit bastele ich an einer neuen verbesserten Version meines ersten Shooters mit einer kleinen Überraschung...
Dabei komme ich immer wieder an Stellen, wo ich einfach merke, daß es sehr schwer wird. Da kommen immer wieder Probleme, die ich dann lösen muss (und es in der Regel auch irgendwie hinbekomme), wo ich dann denke: Geht das anderen auch so?? Habt ihr auch zwischendurch Hürden und Probleme, die auftauchen und die es zu lösen gilt?? Oder liegt es an meiner mangelnden Erfahrung bzw. an eher naiver und schlechter Programmiertechnik??
So bin ich schon in meinem ersten Projekt auf eine recht große Schwierigkeit gestossen - nämlich u.a. die sichere und korrekte Kollisionserkennung eines Sprites mit einem Charakter in einer sich bewegenden (scrollenden) Landschaft. Dann noch eine animierte Explosion hier reinzuzaubern ist echt schwierig und aufwendig. Bei meinem ersten Projekt hatte ich wochenlang geknobelt mit verschiedenen Ansätzen, bis ich dann endlich eine Lösung hatte - die aber nicht zu 100% sauber funktionierte. Und diese vielleicht 2-4 % Fehler hat das Spiel echt runtergezogen. Auch aktuell beschäftige ich mich mit dem gleichen Problem und habe jetzt einen fast völlig neuen Ansatz genommen (dabei traten neue Probleme auf) und jetzt gelöst. Geht euch das auch so, oder liegt es an mir??
Dann sieht man Spiele von damals, die scheinbar einfach aussehen und perfekt funktionieren, wo ich einfach nur denke: Respekt!! Ein einfacher Shooter von damals sieht so unscheinbar aus (Caverns of Mars, Space Invaders) und läuft perfekt und fehlerfrei.... einfach super, wie schön und gut das damals schon programmiert worden ist.
Gerne höre ich da Eure Meinungen und Erfahrungen....
Liebe Grüße
Peter

[cas]

Ja, geht mir auch so.

Ich stosse auf Probleme, und manchmal sind diese Probleme hart zu lösen. Manchmal (zu oft) lege ich ein Projekt zur Seite, weil ich nicht weiter komme. Nach Wochen oder Jahren geht es dann weiter, weil man dann (in anderen Projekten) Ideen bekommen hat, welche bei diesem Problem helfen (bei mir sind es ja eher Tools als Spiele, aber auch dort gibt es schwierige Probleme).

Mit Erfahrung hat man viele der Probleme schon einmal gesehen und sich Lösungen bereit gelegt, das hilft.

Früher (pre-Internet) muss es noch schwieriger gewesen sein, so ohne Kontakte und einfachen Informationsquellen.

[LarsImNetz]

Hi all,

auch mir geht es häufig so. Kollisionserkennung ist nicht einfach. Gerade, wenn ich an Night Knight denke und daran, das dort ja etliche Sprites dargestellt werden, wo man nicht mehr weiß, welcher Sprite war das jetzt mit dem ich zusammengestoßen bin. Da hilft nur, einmal über alle Gegner iterieren und dessen Positionen prüfen.

Was mir sehr stark hilft ist dann mehr Abstraktionsebenen einzuziehen.
Als Beispiel trenne ich grundsätzlich die Position meiner Figur im Raum von dessen Sprite-Darstellung.
Wenn meine Figure an Position 10,10 steht, muss ich für dessen Darstellung immer wieder berechnen, wo der Sprite dann genau erscheinen muss. (x+48, y+32).
Auch gibt es eigene Zähler, welche Animation gerade dran ist. Der wird einfach hochgezählt, in einer eigenen Tabelle steht dann drin, welcher Sprite gerade dargestellt werden soll. Ist die Tabelle am Ende, wird der Zähler einfach auf 0 zurückgestellt. Für jede Richtung gibt es eigene Tabellen.

Bei der Kontrolle des Hintergrunds muss ich die X-Position der Figure durch 4 teilen (Antic - 3 Farben Display) und die Y-Position mit der Breite des Schirms multiplizieren (kommt aus Tabelle) dann noch die Screen-Adresse addieren und schon weiß ich, welche Bytes unter meiner Figure liegen. Das klingt aufwendig, ist aber eigentlich nur eine Berechnung pro 1/50s und damit verschmerzbar.

Bei der Kollisionsabfrage muss ich über alle Gegner iterieren und nur noch die genauer betrachten, die von der Y-Position in meiner Nähe sind, erst dann kommt die Kontrolle der X-Position dran. Meist versuche ich auch die Hardware Register für die Kollisionskontrolle zu prüfen. Wenn es denn geht. Auch die Gegner haben eine Position unabhängig von dessen Darstellung. Die paar Additionen für dessen spätere Darstellung sind verschmerzbar.

Ok, der Atari ist eine echt lahme Krücke im Gegensatz zu Rechnern von heute, aber die paar Berechnungen schafft er trotzdem.

Ein Tipp: Baue das Programm/Spiel immer erstmal so, wie es am leichtesten verständlich ist. Optimierungen kommen später oder gar nicht, ggf ein TODO als Kommentar dran schreiben, wo viel Optimierungs-Potential liegen könnte. Erst wenn das Spiel fast fertig ist, nochmal gucken, wo die meiste Zeit verbracht wird und ob es dort Optimierungsmöglichkeiten gibt.
Routinen, die etwas laden (von Disk) oder ein Level-Wechsel brauchen nicht unbedingt optimiert werden.
Meine am häufigsten genutzten Optimierungen sind "unroll loops" und Tabellen mit Additionen statt Multiplikationen.

Auch Spielfeld-Animationen sind relativ aufwendig. Man muss den Hintergrund retten, neues Objekt dort reinschreiben, dann später Hintergrund wieder herstellen. Positionen/Adressen liegen in Tabellen. Da kommt man dann irgendwann auch mal durcheinander oder mir gehen die Ideen aus...

Du siehst, Du bist nicht allein.

LG
Lars

[patjomki]

Also geht mir auch so, aber das ist doch gerade der Spaß dabei.

Der ATARI hat dabei eine schöne Lernkurve. Es ist nicht alles einfach vorgegeben, s. C64, einfach mal beim SID ein paar Register setzen oder 8 Sprites horizontal oder vertikal mit einem simplen Poke neusetzen (klar, da gibt es auch ordentlich Tricksereien, aber beim ATARI fängt es schon viel früher an).

Also mir bereitet es über die Jahre bis heute viel Freude, immer wieder was Neues zu lernen. Was war da nicht alles dabei:

Vertikales Player-Verschieben
DLIs
Horizontales und vertikales Scrolling
Overscan
Midline-Colorchange
Sprite-Multiplexen
Hüllkurvensimulation per Lautstärkebit
Sampleausgabe

Und ja, das alles hat selten auf Anhieb funktioniert, aber das Tüfteln bringt den Spaß. Mit den Produktionen von damals sollte man das nicht vergleichen. Entweder es waren ganze Teams (LucasArts) oder Programmierer, die in Vollzeit über einen längeren Zeitraum an einem Titel gearbeitet haben.

Also, wünsche weiterhin viel Spaß beim Tüfteln.

[Sleeπ]

Ich probiere mich ab und an an einem Turbo-BASIC-Programm; dort ist es aber genau so. Manchmal stolpere ich über Dinge, die eigentlich gehen sollten - zumindest meiner Meinung nach , wo es aber irgendwo eine Stolperfalle gibt, die noch nicht kenne / nicht direkt erkenne.

So veruche ich z. B. aktuell ein animiertes Spielfeld in Zeichensatzgrafik anzulegen, was auch grundsätzlich funktioniert. Das Spielfeld ist größer als der Bildschirm -> ich kann das Feld in alle vier Richtungen hin- und herscrollen. Funktioniert auch. Aber an einer Stelle (zwei oder drei nebeneinanderliegende Zeichen) stehen allerdings nicht die Zeichen, die dort sein sollten, sondern irgendein "Müll"... Da suche ich momentan noch die Ursache.

Wenn alles auf Anhieb klappen würde, wäre es vermutlich schnell langweilig. Der Reiz liegt ja gerade darin die Probleme mit den zur Verfügung stehenden (begrenzten) technischen Mitteln zu lösen und ein brauchbares Programm aus dem Machinchen herauszukitzeln.

Auch dürfte das intensive Nachdenken über ein Problem der "Grund" dafür sein, daß findige Programmierer immer wieder neues aus dem Rechner rauskitzeln, was bisher keiner gesehen oder gehört hat. Vergleiche nur mal die in den 70ger/80ger übliche Grafik mit dem, was man heute mit dem Rechner anstellen kann. Die relevanten Chips, die den ATARI ausmachen, haben sich in den 40+ Jahren nicht geändert, aber die Programmiertechniken... und das dürfte unter Anderem daran liegen daß nicht immer alles auf Anhieb klappt und man nach Lösungen sucht.

Das ist aber vermutlich grundsätzlich auf jeder Platform so - bei den aktuellen wahrscheinlich noch häufiger, da sie viel komplexer und schwerer überschaubar sind wie ein ATARI oder ein anderer 8-Bitter.

Dabei fällt mir noch eine Anekdote aus der Schulzeit ein: Ich habe, parallel mit einem Kumpel zusammen, der einen Amiga 4000 hatte, versucht ein (vermeidlich) einfaches Spiel "nachzuschreiben". Wir hatten dann, aufgrund der einfachen Grafik, Qix gewählt. Gescheitert sind wir daran, daß wir keine 100% zuverlässige UND schnelle Routine gefunden haben die entscheidet WELCHE Hälfte des Spielfeldes zu füllen ist...

Was uns damals aber schon aufgefallen ist: Wie ähnlich sich der Amiga und der XL sind. Daß die wichtigen Chips vom selben Entwickler stammten und der Amiga quasi der Nachfolger des XLs ist, wußten wir zu dieser Zeit allerdings noch nicht.

[pps]

...
Aber an einer Stelle (zwei oder drei nebeneinanderliegende Zeichen) stehen allerdings nicht die Zeichen, die dort sein sollten, sondern irgendein "Müll"... Da suche ich momentan noch die Ursache.
...

Schau mal nach, ob Dein Bildschirmbereich eine 4kB Grenze überschneidet. Wenn ja, haben wir die Ursache gefunden.

[pps]

Gerade als "einsamer Coder" ohne direkten Kontakt zu jemandem, der mal kurz über den Code schaut oder anders eine Idee hat, ist es manchmal schon schwer voran zu kommen.

Jeder hängt irgendwann an einer Sache fest. Ein anderer schaut keine 5 Minuten rein und sagt: Warum machst Du dass denn nicht so? Und schon wäre das Problem gelöst.

Alleine hat man das halt nicht. Dank dem Netz, gibt es aber wenigstens heutzutage die Möglichkeit aus der Ferne zu helfen.

Egal, was ich persönlich schon alles am A8 kann, es sind noch sooooo viele Dinge da, wo ich neidisch schaue, was andere scheinbar mit links schaffen. Alleine das ist so reizvoll weiter was zu tüfteln.

[patjomki]

Egal, was ich persönlich schon alles am A8 kann, es sind noch sooooo viele Dinge da, wo ich neidisch schaue, was andere scheinbar mit links schaffen. Alleine das ist so reizvoll weiter was zu tüfteln.

Was leider am ATARI fehlt jst sowas wie codebase64. Es gibt zwar hier und da etwas, speziell bei den polnischen Kollegen, aber so eine zentrale Anlaufstelle wäre was.

Naja, im nächsten Leben vielleicht, nachdem ich das Tutorial von Erhard zum RMT ergänzt habe.

P.S.: Manche Sachen kann man sogar von codebase64 für unsere Zwecke nutzen.

[Dr. Irata]

was ist codebase64?

[wosch]

Alzheimer , zu viel auf Atari-Treffen, zu viel anderes um die Ohren
Guckst Du: viewtopic.php?f=7&t=2374
Gruß
Wolfgang

[pps]

Egal, was ich persönlich schon alles am A8 kann, es sind noch sooooo viele Dinge da, wo ich neidisch schaue, was andere scheinbar mit links schaffen. Alleine das ist so reizvoll weiter was zu tüfteln.

Was leider am ATARI fehlt jst sowas wie codebase64. Es gibt zwar hier und da etwas, speziell bei den polnischen Kollegen, aber so eine zentrale Anlaufstelle wäre was.

Naja, im nächsten Leben vielleicht, nachdem ich das Tutorial von Erhard zum RMT ergänzt habe.

P.S.: Manche Sachen kann man sogar von codebase64 für unsere Zwecke nutzen.

Ich könnte dazu eine url sponsern (xl-project habe ich als com, org und de, auf der com ist ja der atari++, a8bit habe ich auch als de).

[cas]

https://AtariWiki.org war ursprünglich als Quelle für Infos von Entwickler für Entwickler gedacht.

Das könnt ihr gerne nutzen, da gibt es auch schon einige Inhalte, die aber noch gut erweitert werden können.

[Erhard]

Hi,

Naja, im nächsten Leben vielleicht, nachdem ich das Tutorial von Erhard zum RMT ergänzt habe.

echt? Das wäre toll, wenn das mal weiter gedeihen würde. Da fehlt auf jeden Fall alles zum Erstellen eines Instruments.

Außerdem hat mir jemand einmal Zusatzmaterial als Einführung geschickt, wie Noten zu lesen sind.

Aber irgendwie komme ich zu kaum was ...

Willst Du das Rohmaterial zum RMT haben (Open Office Datei, Bilder)?

-> Bitte über WhoIsWho an Floppydoc und dann geht es weiter per echter eMail - ist für mich handlicher.

CU, Erhard

[Currock]

Ja, damals (1983 - 1989) habe ich auf dem Atari 800XL zuerst in Basic und dann in Assembler programmiert. Alles mit ein paar Büchern und Listen selbst beigebracht, Kurse, Videos, Tutorials oder Foren zum Fragen gab es damals nicht.
Da ging es genau so. An einigen Stellen bleibt man hängen, und je nachdem, wie ich drauf war, entweder ein oder mehrere Programme geschrieben, die nur zur Lösung des Problems und zum Experimentieren da waren. Oder alles zu geklappt, was anderes gemacht und später wieder dran gesetzt. Einige Lösungen sind auch auf dem Papier entstanden und dann umgesetzt worden.

[LarsImNetz]

https://AtariWiki.org war ursprünglich als Quelle für Infos von Entwickler für Entwickler gedacht.

Das könnt ihr gerne nutzen, da gibt es auch schon einige Inhalte, die aber noch gut erweitert werden können.

Etwas, was wir unbedingt überarbeiten, übersetzen und dann hier ablegen sollten: http://atariki.krap.pl/index.php/Katego ... nik_kodera

[wosch]

Die Seite ist sehr gut. Eine Übersetzung wäre nicht schlecht. Der Online-Google-Übersetzer macht das zwar ganz gut, aber manche Sachen sind doch sehr spezifisch und müssten überarbeitet werden.
Z.B. Polnische Zeichen werden in der Überschrift als Polnische Schilder übersetzt Im Rest der übersetzen Seite dann richtigerweise Zeichen.
Gruß
Wolfgang

[Dr. Irata]

... im Grunde brauchen wir genau so etwas... eine Seite, wo man Assembler Codes als Stichwort nachschlagen kann. Natürlich ständig erweiterbar... und dazu einen, der das pflegt und verwaltet!!

[patjomki]

echt? Das wäre toll, wenn das mal weiter gedeihen würde. Da fehlt auf jeden Fall alles zum Erstellen eines Instruments.

Außerdem hat mir jemand einmal Zusatzmaterial als Einführung geschickt, wie Noten zu lesen sind.

Aber irgendwie komme ich zu kaum was ...

Hi Erhard,

das mit dem Zusatzmaterial war ich

Habe so viele Atari-8-Bit-Ideen, aber komme leider auch zu nix. Hatte ja schon extra geschrieben, dass ich im nächsten Leben als erstes die Doku zum RMT angehen würde. In diesem wird das wohl leider nichts mehr.

Und seit ich vor ein paar Wochen einen leichten Herzinfarkt hatte, ist es erst recht nicht besser geworden.

[patjomki]

... im Grunde brauchen wir genau so etwas... eine Seite, wo man Assembler Codes als Stichwort nachschlagen kann. Natürlich ständig erweiterbar... und dazu einen, der das pflegt und verwaltet!!

Leider ist unsere Gemeinschaft im Verhältnis zum C64 viel zu klein. Sowas wie codebase64 wäre super, aber ich befürchte, es wird niemanden geben, der genug Zeit (und Know-How) hat, das zu pflegen und zu verwalten.

[Dr. Irata]

... ich könnte das in die Hand nehmen, bräuchte aber Hilfe...

[Mathy]

.
Hallo patjomki

... einen leichten Herzinfarkt hatte ...

Gute Besserung!

Tschüß

Mathy

[Erhard]

Hi,

ist es erst recht nicht besser geworden

seit bei mir die 6 vorne steht ist das mit dem "einigermaßen fit bleiben" schon ein größeres Vorhaben. An "Fitness steigern" brauche ich kaum zu denken.

Wenn ich nicht im Vorhof zur Hölle wohnen würde (das besagte Wetter in England ist im Vergleich zu hier (Bergisches Land) wohl eine Dürreperiode), dann käme ich sicher dazu, einige male pro Woche nach Feierabend eine kleine aerobe Runde mit dem Bike zu drehen. So gehe ich zombimäßig zur Arbeit und trete gleichermaßen ausgelutscht den Rückweg an. Gesund ist da nix. Eine Valium 500 ist im Vergleich zu mir ein "Zero-Point-Modul"

Das AtariWiki ist schon eine gute Anlaufstelle für Doku und es hat sicher ziemlich viel Arbeit gemacht, das so zusammenzutragen.

Aber wenn es um Programmiertechniken geht sind die ursprünglichen Bücher wie DeRe Atari für heutige Verhältnisse immer nur eine kleine Andeutung. Sie zeigen das auf, was in den 80er Jahren auf dem A8 gemacht wurde aber sie können für das, was heutzutage auf dem A8 gemacht wird, nur sehr wenig Lernanhaltspunkte geben.

CU, Erhard

[Dr. Irata]

... mir schwebt aus eigenem Interesse schon länger vor, die ganzen kleinen Routinen, die wir zum Teil im Forum entwickelt haben zusammenzustellen. Am liebsten hätte ich hier unter dem Abbuc die Möglichkeit das zu implementieren.
Quasi ein eigener Bereich, wo es ein Inhaltsverzeichnis gibt, wo dann unter jeden Stichpunkt entsprechende Anleitungen mit kleinen Routinen zu finden sind. Diese Routinen baut man dann einfach in sein Programm je nach Bedarf ein.

Was braucht es dazu?
1. Die entsprechende Oberfläche
2. Jemanden, der die Zugangsrechte für diese Oberfläche hat und dann entsprechend Inhalte einstellen kann
3. Jemand, der die ganzen schon vorhandenen Programme zusammenstellt und aufarbeitet und dann in den "Baum" einstellt.
4. Jemand, der neue Inhalte koordiniert oder selber kreiert
5. "Freie" Mitarbeiter, die gerne auch mal bestimmte Ideen als Code umsetzen oder verbessern
6. .......

Zu den Punkten 2-4 : Das würde ich machen können
Punkt 1: Müsste vom Webmaster erstellt werden
Punkt 5: Wer Bock und Zeit hat, bringt sich ein

Die Assembler-Routinen werden von mir entweder selber erstellt oder so bearbeitet, daß sie primär unter MADS laufen, aber auch einfach in einem ganz nativen Assembler laufen - im besten Fall mit Maschinencode in Basic eingebunden werden können.
Das Projekt ist fortlaufend über etliche Jahre, aufwendig und lohnt nur, wenn es eine breite Zustimmung hier im Forum erhält, daher rufe ich jeden auf mal seine Meinung kundzutun:

a) cool
b) egal
c) blöd

[Sleeπ]

Eine Sammlung von Routinen / Tricks / Wie-geht-das / Worauf ist zu achten fände ich, auch wenn ich selber noch nicht wirklich Assembler "spreche" (habe ich mir für die Rente vorgenommen - da habe ich viel Zeit am Stück und nerve dann meine Frau nicht ) sicher hilfreich. Der größte Teil der Bücher dürfte, wie das DeReATARI, auf dem Stand der 80ger sein. Wenn man sich die Programme und Grafiken so anschaut, hat sich da ja einiges getan.

Ich frage mich immer die Entwickler schon geahnt haben was man aus ihren Chips so alles rauskitzeln kann...

Um also auf die Einstufung a/b/c zurückzukommen:

a

[edelro]

a) cool .....Es müssen mindestens 5 Zeichen verwendet werden.

[DjayBee]

a) cool - aber auf atariwiki.org, wie von Carsten bereits angemerkt.

[Kveldulfur]

Hallo!

Ich tendiere auch zu a) aber nur wenn die Wiki auf deutsch ist.

Grüße
Janko

[Dr. Irata]

... das AtariWiki habe ich mir angeschaut, hat auch Sinn und Berechtigung, für dieses Projekt würde ich es aber nicht nutzen wollen aus folgenden Gründen:
1. Ist auf englisch und ich würde es sehr gerne incl. Kommentare und Erklärungen auf deutsch halten! Fällt mir und fast allen anderen deutlich leichter. Wer es aus dem Ausland nutzen will, kann es ja selber übersetzen. Es soll primär für uns sein und also warum sollten wir uns dann die Mühe machen es auf englisch zu halten - machen ja die Polen oder Engländer auch nicht.
2. Das Wiki ist schon mit sehr vielen anderen Themen voll - ich würde das gerne ganz bewußt nur auf dieses eine Thema beschränken: Programmcodes als Subroutinen verwendbar als Nachschlagwerk.
3. Alle Rechte der Routinen sollen beim ABBUC sein und bleiben und sollten dann auch direkt in der Homepage eingebunden sein und fest verwoben sein. Dann ist gewährleistet, daß das Projekt weitergeführt wird, wenn mal einer aussteigt.

[cas]

Das Wordpress auf der Atari Webseite ist denkbar schlecht fuer eine Informationssammlung geeignet. Ich würde mir das nicht antun wollen.
Zumal die Gefahr bestelt das bei einem Update Inhalte nicht (korrekt) übernommen werden können und daher neu eingegeben werden müssen.

Das AtariWiki habe ich explizit so aufgebaut, das es recht einfach benutzbar und auch administrierbar ist (und die Daten einfach in neue Systeme uebernommen werden koennen). Es ist wichtig das die Inhalte nicht durch ein Problem mit der Software sterben. Wir hatten das Problem schon einmal mit dem AtariWiki Version 1 (TWiki) und Version 2 (XWiki). Das JSPWiki ist sehr stabil seit über 10 Jahren.

Das AtariWiki ist generell mehrsprachlich, man kann auch Seiten mit mehreren Sprachen erstellen (Roland hat das fuer einige Seiten schon einmal gemacht, ich muss die Seiten mal wieder finden, dann koennt ihr euch das anschauen). Einige Inhalte im AtariWiki sind auch nur in Deutsch verfuegbar.

Ich kann anbieten unter "NNN.abbuc.de" eine Subdomain einzurichten (was NNN muessen wir uns dann ueberlegen), welche die Inhalte eine Index-Seite im AtariWiki verlinkt. Nachteil: eine neue (Sub-)Domain braucht einige Jahre, bis die Reputation in den Suchmaschinen hoch geht. Das AtariWiki ist seit > 10 Jahren stabil und hat ein sehr gutes Ranking in den Suchmaschinen (ist bei Google und Co. oft in den ersten 5 Antworten). Bei einer neue Seite muss man 4-5 Jahre rechnen, bis die Seite durch eine Suchmaschine gut gefunden wird (denn es muessen sich erst die einkommenden Links ansammeln).

Im AtariWiki gibt es ja schon einige Assembler-Code-Sammlungen:
https://atariwiki.org/wiki/Wiki.jsp?pag ... bly%20Code

Wollen wir vielleicht im Januar eine kleine Online-Sitzung machen? Dann lassen sich die Ideen schneller besprechen.

[Dr. Irata]

... wir können gerne im Januar über das "Projekt" quatschen - ich finde dein Wiki gut und es erfüllt sicher seinen Zweck, für dieses spezielle Projekt würde ich es anders machen wollen....

[Mathy]

.
Hallo Leute

Man könnte die Routinen nicht nur online sammeln, sondern, wenn sich online genug gesammelt hat, daraus ein Büchlein erstellen. Und dieses Buchlein als Jahresgabe herausgeben.

Eventuell könnte man zu dieses Buchlein alle Paar Jahre einen Ergänzung herausgeben. (Nachdem sich online genug Material angesammelt hat)

Und vielleicht könnte man dieses Büchlein herausgeben als kleinen erweiterbaren Ordner, damit man die gesammelten Routinen nach Thema ordnen kann.

Tschüß

Mathy

PS so, das sollte reichen um an das 5 Zeichenminimum zu kommen, jetzt kann ich Peters Frage beantworten: "A"

[patjomki]

So gehe ich zombimäßig zur Arbeit und trete gleichermaßen ausgelutscht den Rückweg an. Gesund ist da nix.

Gibt ja leider immer auch genug Zwänge, dass es nicht anders geht, aber ich drücke die Daumen, dass Du Möglichkeiten findest.

So ein Infarkt kommt tatsächlich ziemlich aus heiterem Himmel.

[wosch]

Hi,
seit bei mir die 6 vorne steht ist das mit dem "einigermaßen fit bleiben" schon ein größeres Vorhaben. An "Fitness steigern" brauche ich kaum zu denken.

Hi Erhard.
Kenn ich. Laboriere gerade mit den Wachwehen einer Erkältung. Total platt, keine Kondition mehr. Und die Erhohlungsphasen werden immer länger.
Im Sommer versuche ich mit dem E-Bike ins Geschäft zu fahren. Die Hügel sind mir doch zu anstrengend geworden.
Wir werden alle nicht jünger
Gruß und gute Besserung allen hier. Bleibt Gesund
Wolfgang

[patjomki]

Also ich bin für

a) cool

Den Vorschlag von Mathy mit dem Buch finde ich gut, sozusagen ein aktualisiertes DeRe ATARI oder wovon ich immer geträumt habe ein Buch: "Fortgeschrittene Assemblerprogrammierung auf dem Atari 8-Bit" inkl. Tutorial zur Einrichtung von WUDSN, mads etc. + Grafik und Soundtools (RMT).

Dabei sollte es auf dem Atari Wiki liegen, sich erstmal nur auf Mads-Assembler beschränken und eben möglichst viel Neues enthalten. Da wir uns dabei aus quelloffenen Sourcen bedienen würden (z.B. Stereo-Pokeyerkennung, Hardbass etc.) dürfen die Rechte aber meiner Meinung nach nicht exklusiv beim ABBUC liegen.

[wosch]

Wenn wir schon dabei sind:
Es gibt ja viele Bücher für unsere Rechner, aber die sind ja alle 30 Jahre oder älter.
Inzwischen gibt es ja viel neue Hardware, Speichermöglichkeiten, Dateiformate.....
Die Infos dazu sind überall verstreut. Suche ich was über .XEX, ist das meiste Englisch oder für die XBox.
Oder wie richte und bediene ich ein SDrive richtig. Das FujiNet hat ja auch megaviele Möglichkeiten. Dazu gibt es eine schöne, leider englische Anleitung.
So ein Atari (Wiki?) für (Wieder)Einsteiger fände ich jetzt auch nicht so verkehrt.
Ist bei den Atari 16-Bitter genau so.
Aber wie schon hier erwähnt, kleine (deutsche) Gemeinde. Die wahrscheinlich meisten hier sind Berufstätig und haben Familie. Also eingeschränkte Freizeit.
Aber vielleicht lässt sich das eine oder andere ja doch umsetzen.
Gruß
Wolfgang

[FlorianD]

ich habe einen Haufen Arbeit in das ATARI WIKI gesteckt und würde mich sehr freuen, wenn andere es erweitern würden. Es ist wirklich einfach zu bedienen, man kann alles thematisch zu allem verlinken und auch ATRs und Bilder als Dateianhänge anfügen.
Schaut doch mal hier:
https://atariwiki.org/wiki/Wiki.jsp?page=Topic%20list
und klickt euch etwas durch.

Thematisch neue Einträge erstellen, z.B. Scrolling. Codebeispiele, verlinken zu den Speicheradressen, verlinken zu Webseiten, alles leicht möglich.
Und SCHNELL ist das ganze. Und EINFACH, das hatte ich glaube ich schon erwähnt.

[cas]

Ich werde Ende des Jahres die Wiki-Software des AtariWiki aktualisieren. Die neue Version unterstuetzt auch Markdown als Auszeichnungssprache (zusaetzlich zu JSPWiki Format).

[cas]

Hier ist eine Seite im AtariWiki mit mehreren Sprachen:

https://atariwiki.org/wiki/Wiki.jsp?page=DOS

Es kann eingestellt werden, welche Sprache als "default" angezeigt werden soll.

[LarsImNetz]

A) cool

Ich würde auch jede Menge Code/Seiten beisteuern.

Wenn Carsten das Wiki in der Art erweitert, das ich Dokumente in Markdown schreiben kann, perfekt. Alles andere ist IMHO murks.
Wenn das nicht ins Atari-Wiki sollte, würde ich glatt https://github.com vorschlagen, da gäbe es dann auch noch ein VCS (Version Controll System) dazu.

@patjomki Gute Besserung.

[Erhard]

Hi,

Dann könnten die Codebeispiele für Scrolling in Assembler und Action!, die hier in der letzten Zeit durchgegangen sind vielleicht direkt da hin.
Dann wäre der Anfang gemacht.
Ich hätte auch kein Problem, meine paar Action! Quellen dort einzustellen (wenn das thematisch paßt), wobei ich nicht behaupten will, daß es sich um ausgereiften Programmcode handelt.

CU, Erhard