Posts by JeeK

  • CTRL + Cursortaste abfangen

    Ich hab bei dem "Problem" noch nicht verstanden, warum ein Ctrl unbedingt im Tasturpuffer landen oder unbedingt via GET gelesen werden muss? Was spricht dagegen den Zustand einer gedrückten Ctrl-Taste aus einer Speicherstelle abzufragen?

    Der Aufwand die Tastaturdekodierung zu "hacken" ist ja auch nicht gerade unbeträchtlich. ;)

    Quote from WebFritzi

    P.S. Wusstet ihr, dass CTRL+M das gleiche ist wie RETURN?

    P.P.S. Ja, vor allem Leute, die mit Terminals, Modems etc. zu tun haben, wissen so allerlei Ctrl-Sequenzen und werden eher nicht überrascht sein. Beim C64 tut sich eh verhältnismäßig wenig. So Commodore-spezifisches wie etwa Ctrl-T für Backspace (das sonst bei Terminals Ctrl-H ist), Ctrl-N Zeichensatz umschalten, Ctrl-S Cursor-Home, ... das reagiert ein Ctrl-M so gesehen noch "normal". ;)

  • 80 x 50 Pixel im Textmodus malen

    Es geht (hier) weder ums Eintippen, noch um die Programmkürze. Der Doppelpunkt am Zeilenanfang ist schlicht sinnlos, es sei denn, man möchte per Einrückungen mit Leerzeichen die Struktur im Progamm hervorheben. Davon kann man aber in der hier präsentierten Spaghettischreibweise wohl nicht ausgehen. ;)

  • 80 x 50 Pixel im Textmodus malen

    Quote from Neptun

    Es geht noch schneller:

    Stimmt, mit der Tabelle für die Zeilenanfänge. Kam noch nicht dazu "nachzulegen". Wunderbar, passt! :)


    Apropos Nachlegen: Man kann noch x/2 als Tabelle realisieren. Ein früh definiertes Array sollte auch noch flotter sein, als eine FP-Division. ;)

  • 80 x 50 Pixel im Textmodus malen

    Quote from Kosmas

    Ist doch in 2 Minuten abgetippt: (sogar mit den Doppelpunkten, deren Sinn ich immer noch nicht begreife, ist aber der Stil von BIF )

    Ja eh, es geht ums Prinzip.

    Das sind da 2 Minuten bei *allen*, die es Abtippen und in Summe dann ein Zeitaufwand, der uns allen quasi aufgezwungen wird. Es war ja auch nur eine Bitte, doch den Lesern entgegenkommender zu sein, speziell wenn man eine Lösung der Leserschaft schmackhaft machen möchte und damit den Zugang dazu möglichst einfach zu gestalten.

  • 80 x 50 Pixel im Textmodus malen

    Quote from BIF

    80 x 50 Pixel:


    Hier hab ich noch mal eine gekürzte Poke-Version.
    Man kann das Problem also in circa 4-5 Zeilen und mit einem Feld lösen.

    Für jene, die das überhaupt ausprobieren wollen, wäre es den Forumsteilnehmern nett gegebenüber, solche Programme in einem Code-Abschnitt (Copy und Paste geht auch aus einem VICE-Screen) oder in einem txt-Anhang textuell anzugeben. ;)

  • 80 x 50 Pixel im Textmodus malen

    Quote from Kosmas

    Gerne kann man noch eine challenge draus machen, aber ich glaube, der Code von Neptun ganz ohne if ist der schnellste. Ich kann mir nicht vorstellen, dass es in Basic wesentlich besser geht.

    Ein bisschen schon. Da springt mein Optimierungsdrang schon etwas an ...

    Die Punkte im Einzelnen:

    • Array H(3) als Array H(1,1). Dann kann muss man den Index nicht umständlich mit Multiplikation errechnen, sondern kann direkt nur mittels AND 1 aus X oder Y ableiten. Der Interpreter kann mit den zwei Indizes schneller rechnen.
    • Die Errechnung von N kann zumindest bei der Y-Komponente mit AND MK (blendet Bit 0 aus) und halbiert den Wert nicht, weil er ohnehin mit C multipliziert wird, welcher dann nicht mehr 40 sein muss, sondern auf 20 reduziert werden kann. Man spart eine Division.
    • Die Initialisierung der Variablen wird mit den häufigst genutzten begonnen. DIM N,X,Y,... legt diese mehrfach in GOSUB 2 etc. verwendeten Variablen zuerst an und ergibt damit auch den schnellsten Zugriff.
    • Ein Array XR(15,15) hat die XOR-Funktion, die in Z 4 gebraucht wird als Tabelle abgebildet. Es braucht die Initialisierung dann halt länger, weil 256 Werte vorberechnet werden müssen. Ist halt nur notwendig, wenn die XOR-Funktion wirklich gebraucht wird.
    • Die Test-Funktion in Z 6 vermeidet die Variable N1 und macht alles in einer Zeile. Das Ergebnis (in Variable N) ist -1 (statt 1), wenn gesetzt und 0 wenn nicht. Das ist ist konsistent mit der sonstigen Konvention in BASIC für logische Ausdrücke (True/False).

    Es ist noch eine Zeitmessung fürs das Zeichnen des Koordinatenkreuzes inkludiert, um etwaige Verbesserungen zu messen.

    Die Laufzeit (fürs Kreuzzeichnen) reduziert sich von 5,27 s auf 4,63 s, das sind 12 % Ersparnis. Immerhin. Es ist gerade so viel, dass man "merkt", dass es schneller ist, wenn auch nicht bahnbrechend. ;)

  • Wochentage und Zeitumstellung ermitteln

    Gefällt mir sehr gut. Für meine Projektdokumentation hab ich das erst jetzt fertig "aufgearbeitet". :D
    Dabei hab ich mir nur erlaubt es BASIC-technisch auch noch etwas zu überarbeiten (die Reihenabfragen waren mir zu unelegant, auf Formel oder Array ausgelagert).

    Das Ergebnis ist nun nicht mehr explizit der Variable WT$ zugewiesen, sondern kann per Tabelle gleich mit WT$(X0) ermittelt werden (mit nummerischem Wochentag als Index im Bereich von 0 bis 6).

    Auch die Abfrage auf gültige Werte erfolgt gleich bei der Eingabe. Die Abfrage später während der Auswertung hab ich aber gelassen (falls man die Routine in einem anderen Kontext verwenden sollte).


    wota-4.prg

    wota-4.bas.txt

  • Commodore in Film und Fernsehen

    Quote from warlord

    Moin, vielleicht hat es ja jemand von euch gestern schon gesehen auf 3sat. Hier noch mal der link zur Mediathek.


    https://www.zdf.de/kultur/kult…deutschedebatten-102.html


    Handelt um C64 und die Verbreitung in der DDR in den 80ziger Jahren.

    Gute Doku, in der Tat.
    Hatten wir hier übrigens schon am 23. März, Post #1.958. Aber es schadet m. M. n. nicht, Gutes hin und wieder erneut zu erwähnen, weil es hier doch ziemlich unübersichtlich ist und man leicht etwas übersehen kann. ;)

  • BASIC 4.5 für den C64 (BASIC 3.5 + EIGENE BEFEHLE)

    Quote from EgonOlsen71

    Außerdem ist das XOR, anders als AND und OR in BASIC, auf den Bereich von 0-255 begrenzt. Natürlich ist das effizienter zu implementieren, aber es passt halt so gar nicht zum Rest.

    Dem muss ich leider zustimmen. Das mit der Funktionsimplementierung ist besonders hier eine leidige Geschichte. Konnte man da beim MEM (als Alternative zu FRE()) noch darüber hinwegsehen, so ist XOR auf dieser Basis leider komplett aus jeglicher Norm und Konvention.

    Wir wir schon hier bzw. in Nachbar-Threads erörtert haben, muss man, um eine neue Funktion zu ergänzen auch den Tokenizer umschreiben (als erweiterte Kopie - Ich glaub, das bleibt einem hier nicht erspart - anlegen).

    Ich hab schon in Posting #32 darauf hingewiesen (auf Assembler: VAR$=MEINE_FUNC$(INTEGER) in BASIC Erweiterung. Aber wie?). Ob es eine elegantere Variante, die nicht so viel Code aus dem ROM wiederholen muss. Das wär' der dort im Posting erwähnte 2-Pass-Ansatz, den ich aber noch nicht probiert habe (ob der wirklich so funktionieren könnte, wie gedacht).

  • Converting a 32 bits word to decimal

    Quote from DutchGuy

    I am wondering what I am going to do if I want to compare the score with the high-score or want to add bonus point at the end of a level.

    Do you than convert it to HEX or do you keep calculating in the decimal form as it is in memory?

    High-Scores, I think that's what Mac Bacon has meant, could be compared like strings. Assuming the score values have all the same length, just walk through position 0 to length-1 (from higher significant to lower significant digits) of the score string and skip as long the values are equal, otherwise the decision is derived from last compare.


    For adding some bonus value take the score value as BCD value (probably transformable on the fly) and add the bonus as BCD value in decimal mode and transform it back to screen codes.

  • Automatisches Einfügen einer Longbranch-Konstruktion bei ca65-Assemblierung

    Vielleicht mit einem Makro, das abhängig von der Sprungweite ein Bxx oder Byy+JMP erzeugt.

    Z. B. wie in ACME im C64-Wiki als Beispiel angeführt.

    Das kann freilich auch noch zu uneindeutigen Zuständen führen. ACME macht da ja ergänzende Durchläufe, um zu einer Auflösung zu kommen. Das könnte natürlich zu einer Kettenreaktion führen, wo kaskadierte Makros im Dominoeffekt alle der Reihe nach von kurz auf lang umkippen. Fraglich, inwieweit hier ein Assembler hier Schritt halten kann.

    Theoretisch wäre ein Fehlerbehandlungsmechanismus im Assembler praktisch, wo man benutzerdefiniert Assembler-Fehler abfangen könnte ...

  • Converting a 32 bits word to decimal

    For my directory routine without BASIC interpreter routines I developed a binary to string routine based on BCD conversion.

    See explanation inline ...


  • Leerzeichen in Strings

    Quote from oobdoo

    Version 1:

    B$ hat zwischen 1-20 Leerzeichen. Dann könntest Du B$ mit mit 20 Leerzeichen fest definieren und dann mit MID$ arbeiten.

    Dann würde Dein A$+B$+C$ so ausehen: A$+MID$(B$,0, Länge)+C$

    Ein bisschen geschickter ist es gleich mit LEFT$(B$,Länge) zu arbeiten ... ;)

  • Bytes aus Dateien schneller auslesen

    Quote from WebFritzi
    Quote from JeeK
    Quote from WebFritzi

    dass ich N statt S für numerische Werte verwenden kann, war geraten.

    "N" wird ignoriert. Es gibt im Wesentlichen nur die Dateitypen U(SR), S(EQ), R(EL), P(PRG). Das hieße, dass standardmäßig ein PRG hier zur Anwendung kommt. Wenn man byte-weise oder Zeilen in eine Datei hineinschreibt, ist es im Grunde egal, ob S, U oder P verwendet wird. Als PRG kann es halt passieren, dass es "versehentlich" als Programm geladen werden könnte bzw. von LOAD/SAVE "gesehen" wird.

    Du hast mich missverstanden. Ich dachte, das S steht für "String". Also habe ich N für "Numerisch" verwendet. Habe erst vorhin gemerkt, dass das Quatsch war. Es werden wohl immer Strings abgespeichert. Übrigens erfolgt die Konvertierung in Zahlen automatisch. Bei INPUT#8,A bekomme ich eine Zahl in A, obwohl ich die Zahl ja (offenbar) als String abgespeichert hatte.

    Keine Angst, ich hab das schon verstanden. Ich hab halt nur die Hintergrundinformation geliefert. ;)

    Es ist eigentlich umgekehrt: PRINT konvertiert implizit eine Zahl in einen String und schreibt ihn als String auch in die Datei.

    INPUT macht dann das umgekehrte, liest den String ein und wandelt diesen im Zuge der Zuweisung zu einer numerischen Variable wieder in eine (Floating-Point-)Zahl.

  • Bytes aus Dateien schneller auslesen

    Quote from WebFritzi

    Es ist ca. 1 KB. Warum die SEQ-Datei 14 Blocks verschlingt, weiß ich nicht.


    Quote from detlef

    Weil du die Daten im Textformat speicherst. Das sind dann 1-3 Zeichen pro Byte + Trennzeichen.

    Ist damit beantwortet.

    Man kann die Daten freilich auch "binär" speichern:


    OPEN 1,8,2,"DATA,S,W"

    FOR I=A TO E: PRINT CHR$(PEEK(I));: NEXT

    CLOSE 1


    Beim Einlesen muss man nur aufpassen, dass man CHR$(0) richtig behandelt.


    Z$=CHR$(0)

    OPEN1,8,2,"DATA,S,R"

    FOR I=A TO E: GET A$: POKE I, ASC(A$+Z$):IF ST=. THEN NEXT

    IF ST<>64 THEN PRINT "READ ERROR, STATUS:" S

    CLOSE 1


    So ungefähr (die Zeilennummern hab ich mir mal gespart), ich hab es jedoch nicht ausgetestet.

    Wichtig, wenn man sich schon byte-weise durchquält, dann ja GOTO-Eskapaden vermeiden und das Inkrementieren dem FOR-NEXT überlassen.

  • Bytes aus Dateien schneller auslesen

    Quote from WebFritzi

    dass ich N statt S für numerische Werte verwenden kann, war geraten.

    "N" wird ignoriert. Es gibt im Wesentlichen nur die Dateitypen U(SR), S(EQ), R(EL), P(PRG). Das hieße, dass standardmäßig ein PRG hier zur Anwendung kommt. Wenn man byte-weise oder Zeilen in eine Datei hineinschreibt, ist es im Grunde egal, ob S, U oder P verwendet wird. Als PRG kann es halt passieren, dass es "versehentlich" als Programm geladen werden könnte bzw. von LOAD/SAVE "gesehen" wird.