Posts by JeeK

Anreiz war für mich immer etwas, was sonst (unter BASIC) wirklich lange dauert schnell hinzu bekommen oder wo sich am Bildschirm etwas tut.

Klassiker:

* ROM ins RAM kopieren - hier lernt man mit Zeiger und Adressen, Zähler und Schleifen zu hantieren, sei es fürs BASIC-ROM oder Character-ROM ...

* Bildschirm und/oder Bildschirmfarbe füllen - auch hier Zeigermanipulation im Bereich von 0 bis 999, also Umgang mit 16-Bit-Adressen.

* Hires-Grafik: da kommen schon etwas komplexere Zeigeroperationen und Adressberechnungen vor und Bit-Manipulationen. Schon alleine das Löschen der Grafik (oder generell von Speicherbereichen) kann einen schon ein kleines Wow heraus locken (wenn man weiß, wie sich BASIC hier plagt).

* Scrollen (kein Finescrolling, ganz einfach), um das Kopieren von Speicherbereichen zu verinnerlichen und gleichzeitig einen optischen Effekt bekommt.

* Spritedatenfinder: Daten per Tastensteuerung aus verschiedenen Speicherbereichen in ein dargestelltes Sprite kopieren (um Spritedaten zu suchen). Hier kann man den Umgang mit der Tastatur und das Speicherkopieren aneignen.

Das aber immer wieder im Abgleich mit bestehenden Lösungen. Diese Art von Reverse-Engineering und Analysen anderer Programme sind immer sehr aufschlussreich.

Man kann es auch vorsichtig angehen lassen, indem man bestehende kleine Programme nimmt und diese (etwa mit einem Monitor) ändert und die Effekte beobachtet.

Quote from goloMAK

Da haben wir es wieder: Schönheit und Speed vertragen sich bei V2-BASIC leider nicht. Das mit dem "get#1,a$,a$,a$...." finde ich ja noch ok, aber die SYS-Aufrufe gehen mir persönlich zu weit.

Hihi, wenn es nicht wirklich um etwas sonst Unüberwindbares geht, dann ist mir SYSeln auch ein bisserl zu BIFig.

Quote from detlef

Naja, wenn man weiß, wie der GET# Befehl funktioniert und wie lahm der ist, dann weiß man wie vollkommen sinnlos dieser Optimierungsversuch ist.

Hast du mal gemessen, wieviel schneller deine Ooptimierung ist?

Ja, ist merkbar schneller. Schon alleine der Parsing-Aufwand ist hier geringer und der ausschlaggebende Punkt. Ich weiß nicht, warum sich dadurch einige so getriggert fühlen und Ratschläge Richtung Assembler zu geben oder die Optimierung überhaupt in Frage stellen? Meinetwegen, aber diese Optimierung kostet kaum Aufwand und es bringt auf jeden Fall etwas. Das bisserl mehr Tippen ist doch zu verschmerzen oder um was geht es wirklich? Wenn jemand Assembler kann, warum dann auch nicht, wenn die Geschwindigkeit wirklich essentiell ist. Aber es ist doch auch so recht interessant aus dem Interpreter ohne jeden weiteren Aufwand, mehr rauszuholen. Ich glaub es besteht da kein Grund, das jetzt schlechtreden zu müssen.

Quote from Krill

Oder einfach mal Assembler lernen, statt gegen einen langsamen Interpreter zu optimieren.

Das eine schließt das andere nicht aus. Jeder soll seinen Spaß haben.

Quote from goloMAK

Quote from Mike

Schau mal was passiert, wenn eine Datei 34 Blocks hat (oder 290, 546 ... alles darüber wird auf einer 1541 wohl nicht vorkommen).

Oh *hust* - guter Punkt!

Ich habe mir jetzt zum Testen eine Kraut-und-Rüben-Diskette erstellt:

Letztlich bin ich damit bei folgendem Programm gelandet:

Code

1. 10 q$=chr$(34)
2. 20 open1,8,0,"$"
3. 30 forx=1to35:get#1,a$:next
4. 40 get#1,a$:ifstthen100
5. 50 ifa$<>q$then40
6. 60 fori=1to16:get#1,a$:ifa$<>q$thenprinta$;
7. 65 next:print
8. 70 forx=1to12:get#1,a$:next
9. 80 goto40
10. 100 close1

Damit wird die obige Diskette korrekt verarbeitet!

Ich hoffe, dass ich damit an alles gedacht habe...

Display More

Rein vom Optimierungsstandpunkt aus könnte man noch bisschen beschleunigen, indem man

Kann man beliebig, sogar im Extremfall komplett ausrollen.

Wenn man das als Subroutine und dann auch nicht unbedingt am Programmanfang hat, dann würde ich noch zu einer FOR-NEXT-Schleife statt dem "goto40" raten.

Man könnte aber auch "brutal" auf wie gehabt auf 100 rausspringen. Ein etwaiges RETURN, falls es ein Subroutine ist, räumt den FOR-NEXT-Stackframe ohnehin sauber weg.

Quote from Endurion

Neeneenee, ist es noch nicht! Das Datumsformat ist so ein veraltetes, man nimmt heutzutage DD/MM/YYYY oder YYYY/MM/DD, aber nicht so ein verkorkstes.

Ich votiere im Falle von "heutzutage" für YYYY-MM-DD , also ISO 8601 ... perfekt fürs Sortieren. Man darf das Datum beim Schreiben aber nicht vor sich hersagen, sonst schweift man immer in ein anderes Format ab ...

Der Preis ist ja schon ein recht stolzer für sooo ein Foto. Und das nur schwarzweiß ... und dann auch noch von der Größe abhängig (gut, ich bin nicht wirklich mit Gettyimage vertraut). Wie man auf so eine Preisgestaltung kommt, erschließt sich mir nicht ganz.

Quote from eisdielenbiker

Das liegt wohl an der unübersichtlichen Lizenzsituation rings um die Commodore-Restfirmenhüllen.

An dem soll das liegen?

Super finde ich, dass hier endlich die Farbgebung in Ruhe gelassen wird. Dieses zurückstellen der Farbe auf die Ur-C64-Farbgebung hat genervt (was ich auch rausgepatcht habe) ...

Quote from JeeK

Wie schon bei anderen Adressierungsarten und Konstruktionen kann ich hier als Beispiel immer wieder auf Forth-Implementierungen verweisen, wo man gerne alles ausnutzt (oder ausnutzen muss), was man zur vom Prozessor zur Verfügung hat. Der "Inner Interpreter" ...

Das hat zwar in dem Fall auch einen Forth-Bezug, aber ist generell anwendbar. Manch Implementierungen verwenden als Abschluss eines Wortes nicht ein JMP NEXT um den erwähnten Inner Interpreter aufzurufen und somit die Forth-Maschine in Schwung zu halten, sondern ein JMP (DO_NEXT). Kostet paar Takte mehr, aber man kann auf einen Schlag den Interpreter "austauschen". Ist billiger als im Interpreter im einen Hook-Code zu haben (das bekommt man nicht für 2 Takte). Etwa um bei Bedarf eine Tracing Funktion zu erhalten oder um IRQ-Abarbeitung durch Forth-Wörter zu ermöglichen. Noch interessanter, wenn das Forth-Basissystem etwa im ROM liegt.

Wie schon bei anderen Adressierungsarten und Konstruktionen kann ich hier als Beispiel immer wieder auf Forth-Implementierungen verweisen, wo man gerne alles ausnutzt (oder ausnutzen muss), was man zur vom Prozessor zur Verfügung hat. Der "Inner Interpreter", der die verkettete Liste von Forth-Words abarbeitet (bildet gewissermaßen eine virtuelle Maschine), verwendet in der "Standard-Implementierung" üblicherweise das JMP () um noch eine Stufe der Indirektion dazu zu bekommen. Der Code selbst liegt in der Zeropage und modifiziert sich deshalb mehr oder weniger selbst. Da das dort der absolut zeikritischste Code überhaupt ist, kann man damit ganz gut leben, Ästhetik bzw. Kritik bezüglich selbstmodifziertem Code hin oder her.
Schaut in etwas so aus (falls ich es aus dem Gedächtnis so halbwegs richtig wiedergebe) - alles in der ZP:

Die zusätzliche Indirektion braucht man, weil ein Forth-Wort nicht nur aus einer Aneinanderreihung von Sprungadressen besteht, sondern die Adressen, auf ein Wort zeigen, das in den ersten 2 Bytes den Verweis auf den tatsächlich abzuarbeitetenden Code enthält. Das ist das Herz von Forth. Objektorientiert betrachtet (wer damit mehr anfangen kann) ist das wie eine Art Klassenbezug, der mit den ersten beiden Bytes eines Wortes gegeben ist. Jeder Code ist somit ein "Objekt", dessen einzige "Init-Methode" aufgerufen wird, die dann etwas mit dem Objekt macht (als Maschinencode ausführt, oder wieder als Forth-Word-Liste abarbeitet, oder schlicht als Daten verwendet).

Quote from detlef

EIne typische Anwendung ist, den Sprungvektor aus eine Tabelle zu holen, nach $hhll und $hhll+1 zu schreiben und dann JMP($hhll) auszuführen. Zum Beispiel bei einem Interpreter.

Im Commodore-Basic wird es aber anders gemacht und der Sprungvektor auf den Stack geschoben und dann mit RTS angesprungen. Keine Ahnung warum das so gemacht wurde. Ist vielleicht etwas schneller.

Vor allem braucht man keine 2 Speicherstellen, in denen man die Adresse zusammen bauen muss. Schaut halt wilder und undurchsichtiger aus. Wer aber das 6502-Paradigma lebt, kennt und schätzt das, da gehört da einfach dazu. Da ist es auch egal ob man den Code nach einem Tag, 1 Monat oder 10 Jahren wieder vors Gesicht bekommt.

Quote from Mike

Hier zur Abwechslung ein Auswahlmenü, in dem einfach mal keine Fehleingaben möglich sind. Es gibt meines Erachtens nämlich kaum eine nervigere Rückmeldung als etwas in der Art von "Nur die Tasten 1 bis 6 drücken!" ...

Gefällt mir gut. Ich möchte die Idee nicht wirklich schmälern, aber ich bin letztlich bei meinen Projekten davon abgekommen, die Menüführung ausschließlich cursorbasiert zu machen. Wenn das das einzige Menü in einem Programm ist, dann ist es ja gut. Wenn man mehrere Ebenen hat, dann kann es nach einer Zeit ein bisserl lästig bzw. mühseelig werden. Das merkt man umso schneller, wenn man Tests macht, beispielsweise immer in gewisse Menüpunkte einer 2. Ebene möchte und sich dann durch die Menüpunkten "durchbewegen" muss. Da sind Schortcut-Tasten (für die versierte Bedienung eines Programms) schon ein Segen. Üblicherweise ohne nervigen Hinweis (vielleicht sogar noch mit einer Back-off-Time, wo gar nichts geht), was denn nun wirklich zu drücken ist. Einfach unzulässige Eingabe ignorieren (und gleich einen kleinen Hinweis auf die erwarteten Eingaben machen, wie es hier im Beispiel ja auch der Fall ist).

Quote from TheRyk

INPUT sollte man nie nicht verwenden.

Und mit GETX$/VAL combo statt GETX erspart man sich auch den Fall des Syntax Errors

Dem pflichte ich voll uns ganz bei (also so ungefähr, wenn man "nie nicht" verstärkend und nicht doppeltverneinend auffasst ).
INPUT ist wegen Verlust der Kontrolle über die Cursorposition und das Bildschirmlayout ziemlich unpraktisch - einige würden sicherlich unbrauchbar sagen. Selbst wenn man eine Variable vom Typ String einliest, so hat man noch mit etwaigen Kommas zu kämpfen (?EXTRA IGNORED Meldung) oder Hochkommas die eine Quotierung vornehmen ...

Quote from Mike

A$<>"1" AND A$<>"2" AND A$<>"3" AND A$<>"4" AND A$<>"5" AND A$<>"6"

Oder wer's so lieber mag die logisch äquivalente Form NOT(A$="1" OR A$="2" OR A$="3" OR A$="4" OR A$="5" OR A$= "6").

Nur so zum Schmöckern, da mag das eine oder andere ja für den geneigten Leser dabei sein ...

• C64 Basic: Directory auslesen und als Stringarray speichern
• Directory anzeigen

Quote from Lutz G

Warst Du in der Zeit auch schon online unterwegs? Die BBS Szene half daaamals™ enorm - sowohl beim Erstkontakt - siehe...

Die erste digitale Nachricht Eurer IT-Geschichte...

Ich kann mich nur an einige wenige Begebenheiten erinnern, als jemand im besagen Computerclub einen Akustikkoppler mit hatte und eine BBS-Session ablief.

Das hat mich aber damals überhaupt nicht begeistert. Das war zumindest für mich eher abschreckend, wie immer die Nebengeräusche der anderen den Akkustikkoppler störten und das so fehleranfällig und langsam war. Gut, ein Clubraum ist sicher nicht der ideal Ort ... Und der Vereinschef war da später etwas empfindlich auf bestimmte Leute, weil das horrende Telefonkosten verursacht hat. Es hat sogar einen Vorfall gegeben, dass dann Leute in Abwesenheit der Vereinsleitung sich massiv über die Vereinstelefonleitung in Mailboxen herumgetrieben hatten und das regelrecht wissentlich missbraucht hatten. Dass hat dann zum Wegsperren des Telefons etc. geführt ... wenn man es halt nicht immer übertreiben würde....

Das Interesse für die Online-Welt hat sich erst kurz darauf im Studium geändert, als es schon das Internet gab, wo ich dann ab 1989 intensiver in Berührung kam. Aber zu Hause kam dann auch die Modem-Technologie in Schwung, aber auch hier die BBS-Ausflüge zwar intensiv (vor allem auch kostenintensiv) waren. Durch den Uni-Zugang, hat sich das dann alles über diesen Weg abgespielt.

Quote from Lutz G

BTW: Ich kann mich nicht erinnern jemals auf nem größeren C64 "Club" Treffen gewesen zu sein. Ok ich war in den 1980s mal beim CCC Kongress in Hamburg (sehr cool), und auch bei der Gründung der M.A.G. dabei (Schweinske, Mundsburg oder so?) - aber das wars eigentlich. Ansonsten bevorzugte ich schon immer Kleingruppen (max 3 Leute *g*). Besonders klasse sind 1 zu 1 Treffen, wie jüngst gerade mit Retro-Rentner, weil man so viel intensiver schnacken kann

Ich war nie so der Vereinsmeierei Typ - C64 Groups daaamals™ waren IMO immer was völlig anderes.

Tatsächlich nahm das im Computer-Club überhand. Wir hatten einen Gönner, die einstige Firma IWW (aus Wien, die eigentlich AS400 und IBM-Distributor war) hat uns auf der damals größten IT-Messe, der IFABO 1985 ein bisschen Platz auf dem Stand zur Verfügung gestellt, was zu einem enormen Zulauf und explosionsartigen Mitgliederzuwachs geführt hat. Die Wochen drauf war im Clublokal die Hölle los. Da war es in einer Sardinenbüchse gemütlicher ...

Wirklich interessant (und amüsant) waren ja dann nur die spät bis in die Früh gehenden "Diskussionen" um Techniken, Programmierung und "das beste" System, oder was Hersteller hätten alles besser machen sollen ...
Aber stimmt, kleine Gruppen und vor allem mit gleichen Interessen (aus dem gleichen Systemlager) sind am interessantesten. Von so paar "Originalen" aus den alten Tagen würde ich schon gerne Wissen, wie es denen so ergangen ist. Das war der Nachteil damals in den 80ern und 90ern: Ein Kontakt ist ziemlich schnell abgerissen.

Seit 2012 bin ich wieder an die alte Wirkungsstätte, den Computerclub Freaks in Wien, zurück gekehrt (nach meiner Abwendung 1987). Einige Veteranen ließen sich es nicht nehmen, all die Jahre den Clubraum weiter zu betreiben. Von den Hardcore-C64-Liebhabern bin ich allerdings alleine unter den ca. halben dutzend der Verbliebenen.
Treffen gibt es unregelmäßig im Abstand von 1 bis 6 Wochen.

Wir hatten für den "Computer-Club-Betrieb" die Liste der Programme mit dem Programm BIBLIO, Abkürzung für den Allerweltstitel "Programmbibliothek" (eine Eigenentwicklung). Die Datenbasis konnte auf einer Diskettenseite maximal rund 6400 Programme aufnehmen. Selbst das reichte dann auch im Laufe der Zeit nicht aus, sodass dann aufgeteilt wurde in Anwenderprogramme, Spiele (oder mehrere Spiele-Liste nach Ära des Auftretens).

Das Programm war zwar in BASIC, aber es hatte etliche Hilfsroutinen in Maschinencode (Sortieren, Directory einlesen, Centronics, Super Garbage-Collection), wobei dann letztlich der Flaschenhals die Floppy war.

Es wurde dann immer wöchentliche mit einem Epson (via Centronics-Anschluss) eine Liste ausgedruckt (im Condensed Mode), wo dann die Neueingänge abgeglichen wurden bzw. zu Wünschen und deren Erfüllbarkeit Auskunft gegeben werden konnte. Oder es wurde direkt im Programm abgefragt, ob ein Kandidat bereits bekannt war, wenn der "Aufnahmeprozess" gerade im Laufen war ...

Meine eigene "Sammlung" hab ich dann freilich auch damit organisiert ...

Die Bezeichnungskonvention war eigentlich immer 4-stellige Zahl (die Vorderseite war ungerade, die Rückseite gerade). Im Details war die dann auf dem sortierten Ausdruck der Liste. Auf den Labels hab ich eigentlich nur händisch beschriftet, entweder grob, ob es Spiele, Entwicklung, Anwendungsprog., Grafik, Musik, Tools, Programmiersprachen etc. drauf waren. Bei Spielen auch mal die Titel, wenn ich diese tatsächlich auch gespielt habe. Bei Anwendungen natürlich auch die unbedingt notwendigen Programme (Assembler, Monitore, Kopierprogramme, ...).

Quote from detlef

Quote from Mike

xxxx DS$="" : FOR P=-1 TO 0 : GET#15,Z$ : DS$=DS$+Z$ : P=ST=0 : NEXT : DS=VAL(DS$) : RETURN

Was soll das sein? Kryptografie?

Zum Ausklang des Threads, vielleicht noch die (Effizienz-Troll-)Anmerkung:

Das ABS(ST) ist noch um 13 % schneller im Vergleich zu der Schreibweise ST=. (statt ST=0). Das FOR ist dazu auch etwas anders geartet.
Speziell bei byte-orientierten Einlese-Aktionen, würde ich diesen kleinen Boost dennoch nicht missen wollen.

Quote from Mike

Derweil habe ich ungefähr die letzte halbe Stunde gesucht, um die Quelle wiederzufinden, wo ich aufgeschnappt hatte, daß "FILES SCRATCHED" wahlweise mit 3 oder 4 Komponenten zurückmeldet - und bin ebenfalls bei AAY64 fündig geworden:

http://unusedino.de/ec64/technical/aay/c1541/errormai.htm

Tja ...

Ich bin mir jetzt nicht sicher, ob ich diesbezüglich den Faden hier verloren habe, aber dort werden ja generell nur die relevanten Parameter, die einen Informationsgehalt aufweisen, angeführt. Damit ist das grundsätzliche Format, mit der Anzahl der Parameter nicht in Frage gestellt, würde ich meinen. Die Fehlermeldungen, die keine T/S-Information tragen, sind ja auch nicht nur auf 2 Werte reduziert, sondern die Werte für T und S können ignoriert werden.

Also so gesehen würde ich das nicht als Beleg für 3-parametrige Fehlermeldungen ansehen. Aber zu dem Schluss mag man hier ja ohnehin (zumindest implizit) gekommen zu sein.

Quote from strik

Daher ist die Lösung, die komplette Zeile auszulesen (und nicht mit A, B$, C, D selektiv die erwarteten Werte zu holen) durchaus sinnvoller.

Beim Einlesen von vorgeblich numerischen Werten werde ich ohnehin immer aus Fehlertoleranzsicht ein wenig nervös, speziell wenn INPUT hier so empfindlich ist.

Ist es vielleicht nicht generell besser vorsichtigerweise INPUT#15,E$,M$,T$,S$ zu verwenden und mit VAL(E$) dann numerisch mit dem Fehlercode zu arbeiten?