Posts by TheRyk

ATTENTION: The mail system is currently not fully configured, so no e-mail notifications (subscribed forums, etc.) will be sent until the final setup. New registrations, password changes, etc. are also currently not possible.


    Na, das wirst du im Simons'-Basic-Teil nicht erleben. Da ist jedes einzelne Wort von mir. Auch die Herkunft der Beipiele ist genau ausgewiesen (wie sich das gehört).


    Ansonsten: Wenn du weiterführendes Wissen hast, dann verstehe ich nicht, warum du dich nicht im C64-Wiki einbringst. Nölen, dass alles nur für Einsteiger sei, ist leicht... Und seine Kenntnisse mit anderen zu teilen - was hast du dagegen? Freut sich doch jeder!


    Arndt

    Habe ich gar nix gegen und verwehre mich nochmals ausdrücklich "genölt" zu haben. ;) In den Simon's Basic-Teil habe ich bisher nur flüchtig reingeschaut. Ansonsten habe ich ja bereits feierlich versprochen, das nächste mal, wo mir etwas verbesserungs-/ergänzungsfähig erscheint und ich was Passendes parat habe, mich konstruktiv im Wiki einzubringen.


    Der Fred-Eröffner fragte ja ausdrücklich nach Einsteiger-geeignetem Material. Vielleicht rührt daher das Missverständnis, ich würde das Wiki irgendwie herabwürdigen wollen. War nicht meine Absicht. Fand es zur Auffrischung eigener (einstmals fortgeschrittener) Kenntnisse (aus den 80ern...) auch nützlich.


    So, gegen weitere Nackenhiebe wegen angeblicher Nölerei werde ich mich jetzt hier nicht mehr wehren, da ich eigentlich meine, ich habe nun alles klar gestellt. Peace, Brothers & Sisters. :winke:

    Jodigi: Na gut, ich will dann mal nix gesagt haben.


    Dass das mit Copy&Paste nicht der Regelfall ist, ist klar.
    Kommt aber vor und fiel gerade auf, wenn ein Wiki-Eintrag nur begrenzt taugt
    (als Einstieg sind sie so oder so fast alle gut,
    aber manchmal will man halt mehr wissen)
    und man beim Googlen dann einigermaßen enttäuscht ist,
    anderswo wortwörtlich das Gleiche zu finden.


    Wenn ich das nächste Mal 1:1-identische und verbesserungswürdige Sachen finde,
    werde ich Dir dann einfach mal per Forum-PM oder e-Mail Bescheid sagen,
    vielleicht auch im Wiki gleich ein besseres Beispiel bringen.


    Nochmal: Das C64-Wiki ist was ganz Feines und der Basic-Befehls-Teil als Einstieg in Basic sehr gut geeignet!
    Sonst hätte ich ihn ja auch nicht empfohlen...



    Nix für Ungut also,
    n8i
    Ryk

    @Sauhund: Er nun wieder :D


    Jodigi: Jou, da hast ja Recht. Eigentlich sollte man in den Artikeln sofort was ändern, wenn einen was stört bzw. bessere Beispiele bringen. Nur so kann das C64-WIKI besser werden.


    Wollte es aber auch gar nicht madig machen, sonst hätte ich es ja nicht empfohlen. Im Großen und Ganzen finde ich die Artikel zu den Basic-Befehlen wie gesagt brauchbar, auch wenn da teilweise seitenlang mit Copy&Paste von anderen Seiten abgekupfert wurde, gerade bei den Beispielen. Wenn mir was grob Falsches aufgefallen wäre, hätte ich sicher auch korrigiert. Steuere vielleicht gelegentlich mal selber Beispiele bei. Meistens fehlt schlichtweg die Zeit bzw. man schaut ins WIKI, findet das Beispiel doof, und bis man selber ein besseres hat, hat man den WIKI-Eintrag längst wieder vergessen bzw. ist zu faul.

    Standard-Antwort ist natürlich das Handbuch (s.o., Link in Dracos Post).


    Mittlerweile kann man Dir aber auch (wie mein Vorredner Jodigi sagte) das C64-Wiki (Programmiersprachen-->Basic-->Basic-Befehle) empfehlen. Schließlich sind es ja doch gerade mal je nach Zählweise knapp über 70 Befehle, die man Stück für Stück dort abarbeiten kann. Die Beispiele sind zwar z.T. aus allen möglichen C64-Homepages und -Büchern zusammengeklaut und die Artikel unterschiedlich ausführlich/knapp/gut, aber überwiegend als Einstieg recht brauchbar.


    Je nachdem, wie weit fortgeschritten Du bist, könntest Du vielleicht ungefähr nach dieser Reihenfolge vorgehen bzw. dort im C64-Wiki einsteigen, wo Du meinst, es besteht noch Nachholbedarf:


    1. PRINT/INPUT/GET(evtl. +LET, auch wenn man es nie benutzt)
    2. LOAD/SAVE/VERIFY
    3. VAL/STR$ (etwas später mal intensivieren: ASC/CHR$/LEN/LEFT$/RIGHT$/MID$)
    4. INT/RND
    5. IF (+AND/OR/THEN/evtl. NOT)
    6. GOTO(+ON)/GOSUB(+RETURN)
    7. FOR(+NEXT/TO/STEP)
    8. POKE/PEEK/SYS/WAIT
    9. DATA/READ/DIM/CLR/RESTORE
    10. OPEN/CLOSE/PRINT#/INPUT#/GET#
    11. DEF (+FN)
    (12. ruhig auch die übrigen knapp 30 Befehle mal sichten)


    Über die Reihenfolge kann man sicher streiten. Aber gerade weil es so wenig Befehle sind, ist es auch nicht so kriegsentscheidend, womit man beginnt. Ganz banale Sachen wie RUN und LIST habe ich mal vorausgesetzt. Ansonsten sind das aber mehr als die Hälfte aller Befehle. Meines Erachtens wirst Du das im C64-Wiki an einem Nachmittag/Abend mal durchgehen können und hättest danach schon einiges drauf. Parallel kann man ja mit dem Emulator das Gelernte gleich ausprobieren. Sicher wird nicht alles sofort sitzen, aber dafür kann man ja jederzeit nachschlagen.

    Du kannst dann jedenfalls schon
    Schreiben, Eingabeaufforderungen, Laden, Speichern, einige Opertionen mit Strings (Zeichenketten) durchführen, IF(="wenn")-Verzweigungen, die verschiedenen Programmsprünge, FOR-NEXT-Schleifen, einige Datenoperationen inklusive Speichern und Laden von Daten in Programme sowie einiges an mathematischen Operationen. Der Umgang mit Sound/Sprites/Grafik zählt m.E. nicht unbedingt zum Grundwissen, von daher kannst Du dann schon fast alles in BASIC!


    Die POKE- und PEEK-Adressen muss man halt hier und dort zusammensammeln bzw. im Internet nachschlagen, sei es auf einer der zahlreichen guten C64-Nerd-Seiten wie emu-ecke.de, in diesem Forum, im Handbuch, bei Wiki oder per Google. Je nachdem wie häufig man die Pokes braucht (Farben, Joystick usw.), werden sie sich dann schneller oder weniger schnell ins Hirn brennen.


    Aber mit diesem Grundstock kann man wie gesagt schon beinahe alles machen. Wie man das Wissen dann möglichst sinnvoll und speichersparend einsetzt (meines Erachtens gerade die Herausforderung, die es so reizvoll macht, sich heutzutage noch mit C64-BASIC zu befassen), das kommt dann erst mit der Zeit von selbst durch Learning-by-Doing oder durch das - mit diesem Grundwissen mögliche - Analysieren größerer Basicprogramme (Beispiele siehe entsprechende Freds "Listings" oder "Große Basicprogramme" in diesem Forum.)

    Geil. Danke, nun läuft es! :thumbup:


    Hin und Her-Übertragen ist echt Fummelkram, mir ist ja auch prompt ein Fehler passiert, und das bei einem Einzeiler ;) Es lebe Copy&Paste...

    Ahhh.... Danke. Also der Pfeil nach oben für "x HOCH y"? Das wäre dann Entf., das hatte ich auch probiert...


    EDIT: :rotwerd: Fehler war ein anderer, hatte mal wieder die QWERTY-Tastatur nicht bedacht und daher SYS mit Shift+Z abgekürzt... So konnte es ja nicht funzen.


    Jetzt läuft es zwar bis zum "GO", bricht aber dann nach dem Losrütteln immer mit "?ILLEGAL QUANTITY ERROR IN 0" ab... So richtig geht es immer noch nicht. Habe keinen weiteren Tippfehler mehr gefunden...

    Code
    1. 0F{shift+o]A=1TO3:?4-A:S{shift+y}64863:N{shift+e}:?"GO":D=TI:F{shift+o}A=0TO99:W{shift+A}56320,A^(AA{shift+n}3),15:N{shift+e}:?(TI-D)/60

    :help:
    Wie kriege ich denn das Zeichen ^ hinter dem WAIT und vor dem AND in VICE hin...?

    :zustimm: Naja... Wenn man mit einem C64 als Bordcomuter ins All reist,
    wäre man ja technisch doch weitaus besser dran als die Raumfahrtpioniere aus den 1960ern. Und wenn man dann noch über die Systemuhr den Monat herauskriegt, bekommt man zumindest immer als Mini-Text angezeigt, welcher Monat gerade auf der Erde ist, wenn man die besagte Zeile kennt.


    Ansonsten klar: Zahlen unter 1 bzw. über 85 führen zum "Absturz"/IQ-Error. Und daher muss ich aus dem selben Grund, aus dem Micro-Saft vor der Verwendung von Java warnt, sagen: Für Raketenabstürze durch die Anwendung des Einzeilers übernimmt TheRyk keine Haftung. Zumal ich die Zeile zu über 90% aus Pirates übernommen habe, verweise ich sämtliche Schadensersatzforderungen an die Fa. Microprose Software bzw. Sid Meier... :P

    Es fehlt der Oktober...

    Skandal! :rotwerd: Okay, hier haben wir ihn:


    Code
    1. INPUTM:M$=MID$("JANFEBMARAPRMAIJUNJULAUGSEPOKTNOVDEZ",(M-1)*3+1,3):?M$:GOTO1

    Sollte die Zeile nun zu lamg werden für einen Einzeiler (glaube ich eigentlich nicht), kann man das GOTO ja auch noch als G[shift+O] abkürzen. ;)


    Quote

    Kann man eigentlich irgendwie vom Vice aus .d64 Files erstellen?

    Kein Problem.
    File-->Attach Diskimage--> Neuen .d64 Dateinamen vergeben, Rechts unten bei "New Image" den Disk-Titel eintragen (Shift Gedrückt halten, wenn der Disk-Titel lesbar sein sollt) auf "Create Image" mousen und Feuer...

    @Bastet: :thumbup: Stimmt, hasse Räscht. Das würde das Verfahren auch bei unterschiedlich langen Strings mit vertretbarem Aufwand ermöglichen. Wie gesagt, hatte auch keinen Anspruch auf Genialität (habe ja zugegeben, wo ich es her hatte) oder supererstaunliche Effekte. Fand das einfach für eine Zeile bemerkenswert in Sachen Speicherökonimie.


    @ Rolands Einzeiler: Habe ich natürlich auch ausprobiert. Ganz klar ist mir das Prinzip zwar nicht. Aber irgendwie manipuliert er wohl die Systemuhr, an der ja der Pseudo-Random hängt... Praktischer Nutzen
    strebt gegen Null, aber: :D witzisch is es.

    Nix fürs Auge, und kein Anspruch auf Genialität.


    Aber ich habe gerade mal was sehr Praktisches wieder entdeckt.
    Es handelt sich um eine Zeile, die ich so oder so ähnlich
    mal aus einem der besten z.T. basic-basierten Games ever
    "geklaut" habe, nämlich Pirates!


    Code
    1. INPUTM:M$=MID$("JANFEBMARAPRMAIJUNJULAUGSEPNOVDEZ",(M-1)*3+1,3):?M$:GOTO1
    2. REM ### BELIEBIGE ZAHL ZWISCHEN 1 UND 12 EINGEBEN ###
    3. REM #### MIT EINER NULL FLIEGT MAN RAUS --> ENDE ####


    Tieferer Sinn: Anstatt 12 Strings/Zeichenketten einzeln zu speichern oder gar zu dimensionieren (was ja bei 12 Monatsnamen dummerweise gerade eben nötig wäre, denn nur M$(0) bis M$(10) sind vom Interpreter vordimensioniert), schneidet man sich hier je nach Monat aus einer einzigen Zeichenkette das benötigte Element heraus.

    Trotz mehr als 11 Strings also kein DIM, kein READ, kein DATA, kein INPUT#
    (aus einer .SEQ-Datei), kein (M) hinter M$ erforderlich.
    --> sehr ökonomisch.


    Auch Anwendungen in anderen Bereichen als Datum sind denkbar, vor allem wenn man die Zeichenketten ansonsten so gut wie nie braucht. So wurden bei Pirates z.B. auch die 4 Nationalitätsnamen zusammengepackt in einer Zeichenkette in Anführungszeichen einschließlich Nationalfarben, in etwa so: "[ROT]ENGLISH[TÜRKIS]SPANISH[GRÜN]DUTCH[2SPACE][BLAU]FRENCH[1SPACE]"
    Daraus wird dann wie oben beschrieben über eine numerische Variable wie N=3 der gewünschte Teil als N$ herausgesägt und schon erhält man über


    PRINTC$(C) : PRINTN$ das übliche
    CURACAO
    (DUTCH)
    in dem Stadt-Info-Fenster
    bzw. im Begrüßungs-Fenster
    YOU HAVE ARRIVED AT THE LOVELY SEASIDE OF CURACAO.
    THE DUTCH FLAG FLIES OVER THE TOWN.

    (Ohne Gewähr auf exakten Wortlaut, habe es ewig nicht mehr gespielt,
    aber ich denke, es ist klar, was gemeint ist)


    Theoretisch könnte man sogar relevantere, unterschiedlich lange Strings auf diese Weise zusammenpacken, nur müsste man sie dann wieder einigermaßen aufwändig auseinanderfriemeln, indem man in numerischen Variablen die Grenzen festlegt, so dass fraglich scheint, ob eine nennenswerte Speicherplatz-/Ladezeit-Ersparnis zu erreichen wäre.

    Habe genau diese Lösung gerade bei http://www.emu-ecke.de gefunden und nun doch mal ausprobiert, weil die andere Lösung mir doch etwas zu "sperrig" war, auch wenn sie funktioniert hat.


    Klappt tatsächlich wie hier von Chainsaw beschrieben: Wenn im nachgeladenen Programm die erste Zeile


    Code
    1. POKE45,PEEK(174):POKE46,PEEK(175):CLR


    lautet, kann man im ladenden Programm ganz primitiv mit


    Code
    1. LOAD"TEIL2",8,1


    arbeiten. Das geladene Programm startet fehlerfrei.


    Sämtliche im ladenden Programm dimensionierte Variablen müssen wie von Chainsaw angedeutet mit DIM neu dimensioniert werden, wenn man sie in TEIL2 noch braucht, etwa beim Laden der logischerweise ebenfalls nicht mehr im Speicher befindlichen Daten aus dem ersten Programm aus einer .SEQ-Datei. Sonst kann es "BAD SUBSCRIPT ERROR" geben.


    Ich habe es getestet, es funktioniert tatsächlich und ist doch viel weniger umständlich als das zuvor beschriebene Verfahren, allein schon weil man viel weniger Schreibaufwand betreiben bzw. viel weniger der knappen Bytes verschwenden muss.


    Von daher ganz klar mein Favorit unter den Lösungen :thumbsup:

    Das Spiel "Computershop"...
    Vorteil: Keinerlei SYS-Schutz.
    Findest Du auf vielen einschlägigen Download-Plattformen.


    Ist zwar schon 'ne ziemliche "Printorgie",
    Game ist doch recht flach,
    enthält aber doch auch ein paar brauchbare Code-Schnipsel.


    Noch flacher und print-orgiastischer: Das "Spiel"
    (eher 'ne ziemliche Verarsche) "Dealer".


    Bessere Sachen:
    Pirates!, Fugger, Kaiser wurden schon genannt.
    Ich meine, auch "Vermeer" ist in Basic.

    Danke, aber die Lösung läuft nun dank Metal's Variante wunderbar,
    genau wie ich es mir vorgestellt hatte.


    Daten rette ich in der Tat mit SEQs. Vorteil der POKE-Variante gegenüber anderen ist auch, dass man die "DIM"-Sachen generell einfach im jeweiligen Programmteil so regeln kann, wie man es - je nach den im Programmteil verwendeten SEQs - braucht, während bei anderen Varianten Vorsicht bzw. vor den LOADs CLR geboten ist, damit man nicht "REDIM'D ERROR"s bekommt, falls man die Sachen mal in anderer Reihenfolge lädt.

    TheRyk:
    Das ist seltsam. Ich hab's hier nochmal getestet... funzt wie's soll. Wenn das Programm beendet wird, ist der Cursor auf "L" von LOAD (in der dritten Zeile, direkt unter "READY"), was sofort ausgeführt wird (wegen dem gefüllten Tastaturpuffer). Hast Du "[3 x Down]" direkt nach "[Clear]" auch nicht vergessen einzugeben?


    Ansonsten ist das was Roland sagt schon richtig und auch wirklich eleganter. Und: der Bildschirminhalt bleibt dabei unberührt.

    YEEHAW! :thumbup: Danke, Du hast es erfasst, es lag an den fehlenden 3 Downs. Da habe ich wohl nach dem Zeile ändern vergessen, ENTER zu drücken. :rotwerd:


    Nun funzt es also endlich!

    Sehe gerade, dass ich mich wohl etwas unklar ausgedrückt habe.


    Also, alle 3 Parts sind Basic. Das "ladende" Prog soll aus dem Speicher verschwinden, das "nachgeladene" Prog soll hinein und ausgeführt werden.


    Das funktioniert aber eben nur, wenn das "nachgeladene" kleiner als das "ladende" ist. Warum dem so ist, das wissen die Poster aus 2003. Es ist aber leider tatsächlich so, wenn man mit

    Code
    1. 10 LOAD"PROG",8,1

    arbeitet. Und in den hier vorgeschlagenen Lösungen muss irgendwo noch der Wurm drin sein. Entweder stimmt der Ausführungspoke nicht oder die Cursor-Pokes. Jedenfalls passiert wie gesagt nix, außer dass die Zeilen hingeschrieben werden und der Cursor fröhlich blinkt. Keine der Zeilen wird ausgeführt.

    Hmmh. Schade, meine Screenshots werden aus irgendwelchen Gründen nicht mehr angezeigt.


    Naja, Metal, Dein Vorschlag liefert folgendes:
    Bildschirm wird gecleart,
    sieht so aus:

    Code
    1. LOAD"PART2",8
    2. READY.
    3. RUN

    Cursor blinkt auf dem "R" von RUN.


    Geladen wurde nix, gestartet wurde nix.


    Im Prinzip also keine Änderung.

    Hallo Basic-Freunde!


    Sorry, dass ich diesen etwas älteren Fred rauskrame, aber da ich mich auf einige hier vorgeschlagene (aber bei mir nicht funktionierende) Lösungswege beziehe, hielt ich es für sinnvoller zu antworten statt einen neuen Fred aufzumachen.


    Also nochmal ganz konkret mein Problem:
    Programm "START" (25 Blocks) kann Programm "PART1" (20 Blocks) fehlerfrei nachladen mittels

    Code
    1. LOAD"PART1",8,1


    Logisch, schließlich ist PART1 kleiner als START.
    Wenn ich von START aber PART2 (30 Blocks) nachladen will mittels LOAD,
    erhalte ich "UNDEF'D STATEMENT ERROR".
    Gebe ich LIST ein, stelle ich fest, dass tatsächlich unvollständig nachgeladen wurde.
    Die Zeilen, welche mittels "GOSUB" angesprochen werden, sind nicht im Speicher.
    Wie ich nun hier gelesen habe, ist auch das logisch, weil PART2 größer ist als START.
    Übrigens: Lade und starte ich statt "START" gleich den größten Teil "PART2", so kann ich nicht nur von "PART2" fehlerfrei "PART1" nachladen, sondern sogar zwischen "PART1" und "PART2" hin- und her-laden.


    Nun zu den hier beschriebenen Lösungswegen:
    1. OPEN-Variante (C64-Doc):
    Mag funktionieren, bringt mich aber nicht weiter.
    Denn ich will gar nicht, dass der Basic-Speicher gelöscht wird,
    sondern dass PART2 geladen und gestartet wird.


    2. POKE-Variante A (Metalmorphosis)

    Quote
    Code
    1. ...
    2. 30 PRINT"[Clear]LOAD"CHR$(34)"TEST"CHR$(34)",8"
    3. 40 PRINT"[5 x Down]RUN[Home]"
    4. 50 POKE198,2:POKExxx,13:POKExxx,13:END
    5. ...

    Hmmh. Also so:

    Ergebnis aber leider:

    Nix passiert, nix wurde geladen, es ist immer noch das Programm "START" im Speicher und sonst nix.
    :nixwiss:


    3. POKE-Variante B (Bingo-Baron)

    Quote
    Code
    1. 10 PRINT "LOAD"CHR$(34)"TEST"CHR$(34)",8"
    2. 20 PRINT "(4mal runter)RUN(8mal hoch)"
    3. 30 POKE 631,13:POKE 632,13:POKE 198,2

    Okay:


    Ergebnis aber leider:

    Naja. Etwas andere Cursor-Position, aber sonst auch nicht anders als die vorige Variante.


    Und nun? ?(
    Wer kann mir helfen?
    Taugen die Vorschläge überhaupt für mein Problem?
    Ist beim Poken des Cursors noch was im Argen?


    Danke im Voraus!