C-Kurs, Abend 4 - Verbesserungsvorschläge

Es gibt 59 Antworten in diesem Thema, welches 18.165 mal aufgerufen wurde. Der letzte Beitrag (21. Februar 2009 um 15:13) ist von Fröhn.

  • Übrigens: Tab ist in PETSCII vorhanden, nur im C64 nicht implementiert. Schaut euch mal den C128 an.

    Rein interessehalber: Wo liegt es denn? In der Bitte melde dich an, um diesen Link zu sehen. im C64-Wiki ist es nämlich nicht. Die ist eh' eher suboptimal, so ohne Hex-Werte, als Bild und so. Vielleicht könnte man die mal nach Vorbild der Wikipedia-Zeichensatz-Tabellen anpassen. ...

  • ?ASC("<TAB>")
    9

    READY.

    Danke! Das ist interessant. Da liegt beim C64 ja "entriegele Shift-C=". Hab' das gleich mal im Emulator ausprobiert (ich habe keinen echten C128 und sowieso nur einen einzigen C64, und das auch noch ein Aldi :rotwerd:): Beim C128 kann man "Schift-C=" (also die Groß/Klein-Umschaltung) gar nicht sperren.

    Den Unterschied könnte man vielleicht mal in den PetSCII-Artikel im Wiki einbauen. Muss mich da vielleicht doch mal anmelden. ...

  • Beim C128 gibt es übrigens noch einige andere PETSCII-Geschichten, die beim C64 nicht vorhanden sind. Z.B. "Bell" oder auch "ESC". Leider hab ich hier kein C128 Handbuch, darin findet sich eine entsprechende PETSCII-Tabelle.

  • Beim C128 gibt es übrigens noch einige andere PETSCII-Geschichten, die beim C64 nicht vorhanden sind. Z.B. "Bell" oder auch "ESC". Leider hab ich hier kein C128 Handbuch, darin findet sich eine entsprechende PETSCII-Tabelle.

    Tatsächlich: "PRINT CHR$(7)" gibt einen wunderschönen Pieps aus. OK, das sollte irgendwie noch in den Absatz über \a und \t rein, dass die (Nicht-)Konvertierung für den 128 durchaus Sinn ergibt, für den CeVi aber leider nicht, also nicht sehr plattformunabhängig. ...

    Und um die C64-Wiki-Seite sollte man sich wirklich bei Gelegenheit mal kümmern. ...

  • ...
    - deutsch variablen- oder funktionsnamen. ihbähpfui. auch das sollte man garnicht erst zeigen, denn sonst wird das zur gewohnheit. es gibt nichts schlimmeres als in einem source rumguckn zu müssen wo die funktionen nach irgendeiner landessprache benannt sind die man nicht beherrscht. darum von anfang an: englisch.
    - gleiches gilt für kommentare, vielleicht sogar noch wichtiger. auch da tut man sich nur selber einen gefallen wenn man die einfach konsequent immer in englisch macht.
    ...

    Sprechende Funktions-, Variablennamen sowie Kommentare sind wichtig, doch warum sollte man in einem Kurs, der in einer Landessprache gehalten wird, nicht auch den Code in eben dieser welchen gestalten?
    Bei internationalen Projekten macht es sicher Sinn, sich auf Hochchinesisch, Hindi oder Englisch zu einigen (Reihenfolge der meistgesprochenen Sprachen), hat man aber 100 Entwickler, die sich alle in einer Sprache austauschen, nur Code in einer anderen Sprache, klingt das doch ein wenig albern, oder?
    Also wenn englische Variablen, dann auch englischer Kurs. Else ist albern. :wink:

  • (...) warum sollte man in einem Kurs, der in einer Landessprache gehalten wird, nicht auch den Code in eben dieser welchen gestalten? (...)
    Also wenn englische Variablen, dann auch englischer Kurs. Else ist albern. :wink:


    das sehe ich ähnlich.

    ausserdem sollte in diesem kurs der *spass* im vordergrund stehen. ohne natürlich falsches wissen zu vermittlen. langweilige bücher, die alle (un)tiefen der programmiersprache c ausloten, gibt es doch in hülle und fülle ...

  • Hallo, da bin ich wieder.

    @heptasean: Danke für den Exkurs und die anderen Korrekturen. Baue ich bei Gelegenheit ein.

    Wg. Deutsch vs. Englisch für Variablen und Kommentare scheint es ja unterschiedliche Meinungen zu geben.

    In Zukunft werde ich in dem Kurs die Variablen Englisch benennen, damit der Code nicht zu murksig aussieht. Die Kommentare lass ich aber Deutsch, um das Verständnis so einfach wie möglich zu machen. Das ist wahrscheinlich ein guter Kompromis zwischen Ästhetik und Verständlichkeit.

    Gruß,
    Thomas

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

  • Hi,

    ich würde mir zur Auflockerung der ganzen harten Themen die jetzt folgen, das Ansprechen des Bildschirmspeichers wünschen. Wir haben jetzt gelernt einzelne Zeichen auszugeben, sogar Zahlen in Zeichen umzuwandeln und auszugeben. Laßt uns mal Bildschirmadressen anspringen und Zeichen irgendwo gezielt ausgeben. Das reicht doch fast schon für Pong, was meint Ihr?

    Gruß, Worf

  • Hi,

    ich würde mir zur Auflockerung der ganzen harten Themen die jetzt folgen, das Ansprechen des Bildschirmspeichers wünschen. Wir haben jetzt gelernt einzelne Zeichen auszugeben, sogar Zahlen in Zeichen umzuwandeln und auszugeben. Laßt uns mal Bildschirmadressen anspringen und Zeichen irgendwo gezielt ausgeben. Das reicht doch fast schon für Pong, was meint Ihr?

    Gruß, Worf

    Guter Einwurf, aber dafür brauchen wir Pointer. Das halte ich didaktisch für zu früh. Wir sollten auf jeden Fall zuerst die Kontrollstrukturen abschliessen, das Casting abhandeln und auf Pointer eingehen. Gerade die letzten beiden Punkte sind meiner Meinung nach wichtig, um die Besonderheiten der hardwarenahen Programmierung richtig verstehen zu können. Da passen dann auch IMHO Pokereien im Bildschirmspeicher. Meine 2 Cent...

    P.S. Wenn Du allerdings die Funktionen der conio.h meinst, habe ich nix gesagt. Die könnten den Spieltrieb animieren. :weg:

  • sowas wie "pong" geht noch prima mit conio zeug (mein tetris benutzt auch ausschliesslich das)... sollte man auch erstmal damit machen bevor man die leute mit pointern erschreckt :)

  • Jup, so ist es. Die conio steht auch sehr bald auf dem Plan. In der Lektion, die gerade in Arbeit ist, geht es erstmal um was anderes.

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

  • bevor man die leute mit pointern erschreckt :)

    Sind harmlose Tierchen, die nicht beissen.
    Die Aufklärung macher Klavierspieler, die den Pointerapparat erklären wollen ist schrecklich. :winke:

    Ansonsten nichts als reine Pokerei und Peekerei im cc65 mit einer vernünfigen Adressenvergebung. :bia

    Sind langsamer als die vordefiniertne POKE/PEEK im cc65, womit man reservierte Speicherbereiche vollmüllen kann.

  • so viel unsinn in einer einzigen post... herrlich :)

  • Ansonsten nichts als reine Pokerei und Peekerei im cc65 mit einer vernünfigen Adressenvergebung. :bia

    Sind langsamer als die vordefiniertne POKE/PEEK im cc65, womit man reservierte Speicherbereiche vollmüllen kann.


    Bitte melde dich an, um diesen Link zu sehen. POKE(addr,val) (*(unsigned char*) (addr) = (val))
    Bitte melde dich an, um diesen Link zu sehen. PEEK(addr) (*(unsigned char*) (addr))

    Was das wohl ist: "(unsigned char *)"

    :D

  • Bitte melde dich an, um diesen Link zu sehen. POKE(addr,val) (*(unsigned char*) (addr) = (val))
    Bitte melde dich an, um diesen Link zu sehen. PEEK(addr) (*(unsigned char*) (addr))

    Oh Gott, was hat Uz dann geritten, das zur Verfügung zu stellen?

    Ich hoffen, das wird im Kurs weggelassen. ...

  • Oh Gott, was hat Uz dann geritten, das zur Verfügung zu stellen?

    die tatsache das eine zeitlang ca jede zweite frage auf der mailingliste "wie geht denn peek und poke?" war =P

  • die tatsache das eine zeitlang ca jede zweite frage auf der mailingliste "wie geht denn peek und poke?" war =P

    :biglach: OK, das ist ein Argument.

  • die tatsache das eine zeitlang ca jede zweite frage auf der mailingliste "wie geht denn peek und poke?" war =P

    Eben, daran erkennt man den c64-user. Der will keine Zeiger. :nixwiss:

    Der Kunde ist König. :roll2:

    Alles klaro? :winke:

  • Dir ist schon klar, dass PEEK, POKE und SYS als ersten Parameter einen Zeiger haben?