C-Kurs, Abend 6 - Verbesserungsvorschläge

    • Tach,

      schön, dass immer noch Leute darüber stolpern. Durch die viele Arbeit am EF3, mit dem PLA-reversen und der realPLA (plus die 23 unvollendeten Projekte) bin ich zu dem C-Kurs nicht mehr gekommen. Der Aufwand dahinter hat sich bei der doch mäßigen Resonanz auch nicht wirklich gelohnt. Immerhin kann man damit einen Anfang machen. Die ersten Schritte sind da. Wer das wirklich lernen will, kommt schon irgendwie weiter.

      Na dann viel Erfolg :)
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Bau Dir ein eigenes Modul! EasyFlash

    • Der Aufwand dahinter hat sich bei der doch mäßigen Resonanz auch nicht wirklich gelohnt.


      Da hast du vollkommen recht. Es lohnt sich nicht. Ich war damals fast der einzige der da noch viele Fragen gestellt hatte und auch noch einpaar interessante Dinge progammiert hatte. Aber alleine hat es kein spass gemacht.

      Gruss
      peter
    • Das Können ich WILL!

      nunja, was genau hält dich denn davon ab? das du kein C kannst? oder kein assembler? oder fehlt einfach das wissen das eine mit dem andren zu kombinieren? (letzteres kann man sich eigentlich gut von den sourcen zur c-library abschauen, die sind zum grossteil in assembler geschrieben)
      Ich war damals fast der einzige der da noch viele Fragen gestellt hatte und auch noch einpaar interessante Dinge progammiert hatte.

      "interessant" ja - für jemanden der die brutalst fieseste lösung suchte sicherlich :o)
    • Mich würde der Zugriff auf die C64-Ressourcen interessieren. Wie man Farben setzt und wie man mit Sprites umgeht. Falls das überhaupt möglich ist.

      Aber auch andere Grafikzugriffe (Linien, Boxen) oder Musik über C wäre doch toll....

      Gruß!
      ThomBraxton

      DoReCo #55 am Sa. 16.12.2017 :dafuer:
    • ThomBraxton schrieb:

      Aber auch andere Grafikzugriffe (Linien, Boxen) oder Musik über C wäre doch toll....

      Ich will nicht noergeln ;)
      Aber Linien und Boxen sind klassische sehr einfache 'Algorithmen' fuer C.
      Wenn Du danach suchst findest Du sogar C-Implementierungen:
      de.wikipedia.org/wiki/Bresenham-Algorithmus
      Was das reine C angeht, ist das extrem harmlos (lediglich Schleifen).

      Was fehlt ist dann das C64-spezifische. Das ist beliebig kompliziert. Aber alles was man fuer das oben genannte braucht steht im Benutzerhandbuch und hat mit C dann ueberhaupt gar nichts zu tun.

      Aehnliches gilt fuer Musik. Welche Register es gibt, steht u.a. im Handbuch. Wie man die in etwa zu setzen hat ebenso.
      Sie dann auch zu setzen ist wiederum in C denkbar, wenn auch kein allzu klassisches Beispiel.

      Ich moechte damit fragen: moechtest Du C lernen? Dinge am C64 erschaffen mit moeglichst wenig/keinem Aufwand? C64-programmieren lernen? Den c64 als solches kennenlernen?
      Fuer all das ist das Grundgeruest ja schon laengst da.

      Frisch ans Werk!
      Tatsaechlich waere es eine feine Uebung Linien zu zeichnen.
      Was an Wissen dazu fehlt: wie setzte ich Grafik-modi und dann auch Punkte am C64.
      Da hilft aber ohnehin kein C-Tutorial weiter, sondern Handbuecher, Foren oder immer gerne codebase64.org

      Viel Erfolg und vor allem Spass dabei
    • Gibts eigentlich irgendwo weiterführende Tips wie man cc65 code optimiert?

      Ich kenne die Tips aus der cc65 Doku, die sind schon enorm hilfrech, aber alles decken sie halt auch nicht ab.

      Worüber ich z.B. oft stolpere, wie kopiert man schnell bytes?
      for (x=0;x<40;++x) nach[x]=von[x];
      oder doch lieber mit...
      for (x=40;x;--x) *nach++=*von++;

      In 6510-assembler würde ich wohl Variante 1 nehmen, bei 68000 Assembler variante 2, aber wer weiss welchen code der cc65 letztendlich ausspuckt... (vielleicht hat ja jemand mal Tests gemacht?)
      C64c, 1541U2, easyflash, sd2iec
    • Wenn es schnell gehen soll, implementier den Teil in Assembler. Nimm C nur für das Drumherum.

      Zum Thema "Unterstützung von Sprites, Grafik etc.":
      Abgesehen von der Geschwindigkeit ist einer der größten Vorteile von C gegenüber Basic der, dass man sich brauchbare Funktionen schreiben kann. Wenn man statt

      Quellcode

      1. pa$="*=p":x=8:gosub1234
      nun

      Quellcode

      1. display_directory("*=p", 8);
      schreiben kann, erleichtert dies das Verstehen und Bearbeiten eines Programms enorm.
      Supportfunktionen wie z.B "position_sprite(num, x, y)" kann man sich also sehr einfach selber schreiben.
      Yes, I'm the guy responsible for the ACME cross assembler
    • ThomBraxton schrieb:

      Aber auch andere Grafikzugriffe (Linien, Boxen) oder Musik über C wäre doch toll....
      Für einfache Grafiken gibt es doch schon das TGI Interface für den cc65. Habe es mir mal vor langer Zeit mal kurz angeschaut. Allerdings habe ich es nicht hin bekommen Text im Grafikmodus auszugeben. Anscheinend ist das für den C64 noch nicht implementiert, oder ich habe etwas total verpeilt.

      Hier der Link zu meinem kleinen Beispiel.
    • Ja, genau. Grafikroutinen in C programmieren für Laufschriften oder um Objekte zu bewegen. Spritekollisionen abfragen. Mausdaten umsetzen. Das stelle ich mir mit den passenden Routinen einfacher vor als in Assembler. Obwohl ich auch Assembler gerade ein wenig übe. Ich komme aber von Fortran, VisualBasic, VisualC# und Co und dachte, mit einem guten C-Compiler könnte man vielleicht die ganzen tollen Seiten des C64 etwas komfortabler ansprechen und nutzen.

      Gruß!
      ThomBraxton

      DoReCo #55 am Sa. 16.12.2017 :dafuer:
    • Mac Bacon schrieb:

      Wenn es schnell gehen soll, implementier den Teil in Assembler. Nimm C nur für das Drumherum.
      Nagut, deine Antwort ist jetzt nicht direkt falsch, aber in einem Betrag mit dem Titel "C-Kurs Verbesserungsvorschläge" da hätte ich jetzt nicht eine "freflerische" Antwort erwartet. ;)

      Dass es in Assembler schneller geht weiss ich auch, aber offensichtlich will ich hier kein Assembler nehmen, sondern mein Glück beim Speicherkopieren in C versuchen. (ja, ich bin mutig genug und verwende "C" und "Glück" im selben Satz)

      Und es gibt noch mehr, kann man mit cc65 schnellen Zugriff auf structs bekommen oder geht das einfach nicht? Selbst ein "x=structpointer->tag;" braucht ewig. :evil:
      C64c, 1541U2, easyflash, sd2iec
    • Meine Antwort war auch nicht als generelle "Nimm-lieber-Assembler-als-C"-Weisheit gemeint. Du hattest ja selbst bereits 6510-Assembler erwähnt, und darauf bezog ich mich. cc65 mag inzwischen relativ brauchbaren Code erzeugen, aber in die Nähe von handgeklöppeltem Assembler kommt er halt nicht. Insbesondere Zeigerarithmetik ist halt relativ schwierig, da die CPU keine echten Zeigerregister kennt und man die Zeropage nicht auf dem Stack sichern kann/will.
      Für das nicht ganz so zeitkritische "Drumherum" eines Programms ist C aber eine gute Idee.
      Yes, I'm the guy responsible for the ACME cross assembler
    • Kein Interesse vorhanden und schon auf Seite 2? - Komisch!

      Das kein Interesse vorhanden ist, kann man hier wohl nicht gerade sagen.

      Ich stelle fest, dass wir mittlerweile auf Seite 2 angekommen sind und es findet noch immer rege Beteiligung hier statt. Super!

      Wenn ich wieder mehr Luft habe, werde ich mich auch tiefer in C einarbeiten. Zeiger?!? Ja, davon habe ich auch schon gehört. Aber noch nie damit gearbeitet. Muss mal meine alten C-Bücher heraus kramen.

      Gruß!
      ThomBraxton

      DoReCo #55 am Sa. 16.12.2017 :dafuer:
    • Mich würde der Zugriff auf die C64-Ressourcen interessieren. Wie man Farben setzt und wie man mit Sprites umgeht. Falls das überhaupt möglich ist. Aber auch andere Grafikzugriffe (Linien, Boxen) oder Musik über C wäre doch toll....

      generell ist alles was in asm möglich ist auch in C möglich...mal von fiesem timinggetrickse abgesehen.

      eine der wichtigsten dinge bei cc65 ist dieses:
      Wenn es schnell gehen soll, implementier den Teil in Assembler. Nimm C nur für das Drumherum.

      - was nicht nur heisst das man sich nicht scheuen soll auch selber mal ein asm file zu schreiben, sondern vor allem das man ausgiebig die (in assembler geschriebene) standard bibliothek benutzen soll. also statt
      for (x=0;x<40;++x) nach[x]=von[x];

      schreibt man einfach
      memcpy(nach, von, 40);

      - das ist nicht nur schneller, sondern resultiert auch in kürzerem code und ist am ende auch noch lesbar. an der stelle zahlt sich ungemein aus die standard bibliotheken zu kennen und anwenden zu können - ich würde daher empfehlen C auch erstmal auf einem "grossen" system zu lernen

      Zeiger?!? Ja, davon habe ich auch schon gehört. Aber noch nie damit gearbeitet. Muss mal meine alten C-Bücher heraus kramen.

      zeiger werden schon im c64 handbuch ausgiebig benutzt, selbst mit basic v2 kommt man ohne jene ja kaum einen meter weit =)

      Quellcode

      1. 10 SI=54272
      2. 20 POKE SI+24,15:POKE SI+24,0
      3. 30 GOTO 20

      ist nichts anderes als

      Quellcode

      1. unsigned char *SI = 0xd400;
      2. while (1) {
      3. *(SI + 0x18) = 15;
      4. *(SI + 0x18) = 0;
      5. }


      auch das empfehle ich aber eher erstmal an was "grossem" zu üben, vor allem weil moderne compiler einem durch ihre warnings viel eher klarmachen das das was man sich ausgedacht hat murks ist =)
    • sauhund schrieb:

      memcpy(nach, von, 40);
      Hm... ok, guter Tip!

      Mehr davon! :thumbsup:

      Wobei das ja nur ein Beispiel war. Was mich mal interessieren würde, wäre ein Test (evlt. mit timer), wie man bestimmte Programmstrukturen in C für den cc65 "formen" sollte. (siehe Beispiel mit Speicher kopieren, oder auch Zugriff auf structs, u. a.) Ich gebe ja zu, ich bin im Augenblick einfach zu faul das zu machen (siehe Name meines Avatars) und werde wohl einfach andere Stellen in Assembler schreiben und dann ist das Programm auch schnell genug.

      Nichts desto trotz würde das schon Sinn machen, denn alleine mit den Tips aus dem cc65 Handbuch konnte ich meinen code 3x schneller machen. Und da ist bestimmt noch mehr drin.
      C64c, 1541U2, easyflash, sd2iec