Posts by Mike

    Ich werf' mal Space Rogue von Origin in die Runde:


    - Raumflugsimulation mit gefüllter(!!!) Vektorgrafik,

    - acht (Spoiler: stimmt nicht ganz) unterschiedliche Sonnensysteme in einem Sternencluster, in Kartenansicht, zwischen denen man sich per "Wurmlöchern" bewegt,

    - ca. 1 bis 2 Raumstationen pro System, ebenfalls mit Karten, mit NPCs mit denen geredet werden kann, mit zu lösenden Rätseln,

    - Mini-Game (Hive!) im Spiel, welches (ebenfalls Spoiler) den Skill zur Lösung eins der knackigeren Rästel liefert (Stichwort: Bassruti Incident),

    - Story-Spielzeit ca. 12 Stunden, selbst wenn man alles weiß, oder mehrere Tage wenn man beim ersten Durchspielen alle relevanten Nüsse ohne Hilfe knacken will.


    Letztens wieder über mehrere Abende gemütlich verteilt mit einem Kumpel zusammen gespielt, der das Spiel noch nicht kannte. Am Ende haben wir dann als Hintergrundmusik die Siegeszeremonie von "Star Wars Episode IV: A New Hope" dazu genommen. :D

    Das geht auch mit DirMaster. Dafür musst du den Dateinamen mit einem " abschließen und dann noch ,8,1: anhängen:

    Das ist nicht die richtige Methode! Korrekterweise steht zwischen Dateinamen und "Ladehilfe" im Verzeichniseintrag ein Shift-Space, CHR$(160)!


    CBM DOS erkennt das Shift-Space als (vorzeitiges) Ende des Dateinamens und ersetzt es bei der Ausgabe im Directory durch das Anführungszeichen. Der Dateinamenvergleich bei "SEARCHING FOR ..." läuft auch nur bis zum Shift-Space, trotzdem gibt das Directory noch die nachfolgenden Zeichen (also ",8,1") mit aus. Bei ",8,1" ist es nicht nötig, noch einen Doppelpunkt mit anzuhängen, da der Eingabe-Parser von BASIC nach der 1 mit der Erkennung eines nicht-numerischen Zeichens (hier wahrscheinlich das "P" von "PRG") schon zufrieden ist und 1 als Sekundäradresse zurückgibt - nach dem LOAD aber ohnehin die weitere Ausführung der Eingabe im Direktmodus abbricht.


    Alternativ geht auch ",8:" als Ladehilfe für BASIC-Programme. Da muß dann ein Doppelpunkt hin, damit der Parser erkennt, daß die Eingabe hier zuende ist. Sonst wird noch auf ein Komma geprüft, da ja noch die Sekundäradresse kommen könnte.

    Denn nur eine Programmiersprache zu können lässt einem keine gute Software entwickeln. Das erkennt man gut wenn man alle Befehle einer Programmiersprache verstanden hat und sich dann fragt: "Ja, und nun?"

    Die Parallelen zum Schachspiel sind hier unübersehbar. Nur weil man alle Schachregeln kennt (hoffentlich auch die "en-passant"-Regel, Unterverwandlung, etc.) macht einen das noch lange nicht zu einem guten Schachspieler. Kenntnisse im Endspiel, in der Eröffnung und vom Zusammenwirken der Figuren im Mittelspiel sind unverzichtbar.


    In ähnlicher Weise kommt man nach einiger Zeit von der Sicht auf einzelne Befehle weg und betrachtet immer Gruppen von Befehlen auf ihre Gesamtwirkung. Diese Gruppen werden dann beim Programmieren "in Dienst" gestellt wobei es relativ unerheblich ist, ob sie als Makro (also effektiv "ausgeschrieben") oder als Unterprogramm im weiteren Zusammenhang geführt werden.


    Dann spielt es auf einmal auch keine so große Rolle mehr, daß der 65xx nur ein 8-Bit-Prozessor ist. Eine 32-Bit-Addition synthetisiert man sich einfach so:

    Code
    1. ; (C) = (A) + (B)
    2. CLC
    3. LDA A :ADC B :STA C
    4. LDA A+1:ADC B+1:STA C+1
    5. LDA A+2:ADC B+2:STA C+2
    6. LDA A+3:ADC B+3:STA C+3

    Den Befehl CLC habe ich hier mit Absicht vor die ganze restliche Befehlskette gestellt und nicht etwa dem ersten ADC zugeordnet. Damit wird betont, daß die einzelnen Schritte der 32-Bit-Addition im Grunde gleich sind, der Gesamtaufbau für andere Größen (8-Bit, 16-Bit, 24-Bit, 40-Bit, ...) angepaßt werden kann und die erste Addition in der Kette kein Sonderfall ist. Ein Assembler, der es zudem noch erlaubt, Befehle solcher Einzelkomponenten in eine Zeile zu schreiben (wie oben zu ersehen), läßt den Quellcode diesen Aspekt noch deutlicher zum Ausdruck bringen. Leider geht das nicht mit jedem Assembler.

    [...] Ein komplett fertiges "Zahlenraten" liegt zu Beginn natürlich in a galaxy far, far away, [...]

    Vor allem ist "Zahlenraten" (also, was ich hier vermute, von 1 bis 100 mit "zu hoch", "zu niedrig" und "genau richtig") nun gerade nicht das Spiel oder die "Anwendung", wo sich ein Geschwindigkeitsvorteil irgendwie ermessen ließe. Es macht nun mal keinen erkennbaren Unterschied, ob der Rechner eine 1/100 Sekunde (grob, in BASIC) oder eine 1/10000 Sekunde (in Maschinensprache) braucht um die Antwort zu bewerten. Den Rest der Zeit dreht der Rechner in der Eingabeschleife im KERNAL Däumchen. Stichwort "I/O-bound" vs. "compute-bound".


    Zu meinem Beitrag #61 möchte ich noch hinzufügen, daß man die ersten Experimente noch so, mit POKEreien auf Videochip-Register o.ä. machen kann, aber ab einem bestimmten Zeitpunkt sollte man sich doch sehr konkret mit dem Speicheraufbau der Zielmachine beschäftigen. Ansonsten geht das nämlich sehr schnell in ein Gestocher im Nebel über - bis hin zu dem Punkt, daß Leutz nicht wissen wo die Daten beim Laden von Floppy landen. Auch da hilft ein Monitor ungemein. Man bekommt eher einen Eindruck, wie viel 64 KB schon sein können, wenn man einfach mal M 0000 FFFF eingibt ...


    Ab einer gewissen Menge an Code im Kopf, bekomme ich einen Stack Overflow und dann benötige ich doch mal eine Pause. :)

    Man kann etwa das Äquivalent einer DIN-A4-Seite problemlos im eigenen Schmierzettel-Gedächtnis parat halten. Alles darüber hinaus erfordert beim Programmieren eine entsprechend vorbereitete Programmstruktur, so daß man sich zu jedem Zeitpunkt nur äußerstenfalls so viel wie gerade beschrieben merken muß.


    Daher ist es schon eine gute Sache, daß der nicht erweiterte VC-20 ohnehin nur 3,5 KB freien Speicher hat ... :D

    Danke, so habe ich heute schon wieder was dazugelernt und es ist noch nicht einmal Mittag! :D

    Gern geschehen! :) Der VC-20 hat in Bezug auf hochauflösende Grafik schon noch einiges in Reserve. :D


    [...] gab' es nicht was in der 64'er speziell für Statistiken, Balken & Co? ...hmm *such*

    In den 64'er Sonderheften sicher, ab und zu verteilt in den regulären Ausgaben. Die 64'er war da aber nicht allein, aus der RUN hatte ich z.B. mein erstes Kuchen-/Tortendiagramm abgetippt. Dieses kam dann immer zu irgendwelchen Wahlabenden zum Einsatz. :pumpkin:

    Im Charset für den U64 hab ich mir die zwei PETSCII Striche gefixt, aber das hilft ja nur dem eigenen Seelenfrieden. :)

    Alternativ täte es ja auch ein modifizierter Zeichensatz im RAM. Ein geändertes Zeichensatz-ROM hatte verschiedentlich schon mal für Überraschungen gesorgt, z.B. auf einer frühen Version des C128, wo dann das Titelbild von Koala-Painter "leicht" anders aussah: Character ROM used as data? - Lemon64. - danach bekam der C128 dann einen eigenen Zeichensatz und der C64 Modus wieder den originalen Zeichensatz.

    Hier mal der Stand 15.09.2022, 10:45 Uhr für den VC-20 mit mindestens 8K Speichererweiterung. :)



    Die Kohorte 2005-2009 paßte leider nicht mehr ins Diagramm.

    ... Tortendiagramm - gab's da nicht was für Simon's Basic ...[?]

    Tortendiagramme sind ein No-Go für Statistiken mit einer Zeitachse. :sonicht:

    Files

    • statistik.zip

      (1.99 kB, downloaded 3 times, last: )

    SYSeln [ist mir] auch ein bisserl zu BIFig. :rolleyes:

    Dabei handelt es sich noch nicht mal um wilde Sprünge in den KERNAL, sondern um 65478 = $FFC6 = CHKIN und 65484 = $FFCC = CLRCHN in der KERNAL-Sprungtabelle. Für 65481 = $FFC9 = CHKOUT gibt's sogar ein BASIC-Äquivalent, den Befehl CMD, welcher die Ausgabe im Anschluß umgelenkt läßt (mit PRINT# holt man sie dann wieder auf den Bildschirm zurück), die Entsprechung für die Eingabe hatten M$/C= wohl vergessen ...

    ... womit würdet ihr es lernen und programmieren?

    Das hier nicht ganz ernst gemeint: Ich würde so tun, als hätte ich gerade die VICMON-Cartridge für meinen VC-20 zu Weihnachten geschenkt bekommen und würde mich dransetzen, einige Beispielprogramme aus dem VC-20-Handbuch 1:1 von BASIC nach Assembler zu übersetzen, siehe auch A sample programming session in VICMON im Denial-Forum. :D Ist nur halt in Englisch geschrieben. Ich arbeite mich da von den "Bunten Vögeln" bis zum Spiel "Killer Comet" vor, welches ich zum Schluß auch noch grafisch aufpeppe.


    Ansonsten kann ich eben nur meine "Vorgehensweise" damals™ noch zum Besten geben: Ich hatte mich gewundert, daß einige Abtipp-Spiele offensichtlich mehr Objekte auf dem Schirm schnell bewegen konnten als ich in BASIC für ohne weiteres machbar hielt. Speziell der VC-20-Port von Dino-Eggs in der "Compute mit 8/85" war da ausschlaggebend: im Höhlensystem laufen/kriechen/flattern einige Dinos, Spinnen, Schlangen und Pteranodons daher. In den DATA-Zeilen war also nicht nur ein Zeichensatz drin, sondern auch eine Maschinenroutine, die hauptsächlich für die Animation verantwortlich war.


    Etwas später habe ich dann erst händisch die Mnemonics aus Tabellen in Opcodes übersetzt und Branch-Offsets ebenso von Hand ausgerechnet und das alles dann aus DATA-Zeilen in den Speicher geschrieben. Da war dann bei ca. 100 Bytes Größe einer Routine Schluß.


    Als nächstes dann der TEDMON auf dem C116 und kurze Zeit darauf auch dem C128. Damit entstanden dann immerhin größere Support-Routinen für BASIC-Programme in der Größenordnung von 1 KB. Mit Double-Ass kam dann ein symbolischer Assembler zum Werkzeugkasten dazu, ab da war die Programmgröße theoretisch unlimitiert. Auf dem PC hat man eben "nur" noch zusätzlich den Komfort einer besseren Übersicht über den Quelltext.


    Aber um noch mal auf meinen ersten Vorschlag oben zurück zu kommen: meinen 'tatsächlichen Start' darunter (also, händisch aus Tabellen den Code bauen) solltest Du nicht nachmachen und brauchst Du auch nicht nachzumachen. Mit einem Monitor erste kleine Beispiele ausprobieren macht aber schon eine Menge Spaß und gibt einen vergleichbar unmittelbaren Zugang wie das eingebaute BASIC. Danach kannst Du immer noch auf professionelle Werkzeuge, sprich (Cross-)Assembler umsteigen. Zum Debuggen wirst Du aber immer mal wieder auf die Fertigkeiten zurückgreifen, die Du dir mit dem Monitor erarbeitet hast.

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


    Es hat schon einen Grund, warum da bei meinem Beitrag #19 scheinbar überflüssige GET#-Anweisungen drin sind. ;)

    Das Beste am SMON fand ich von jeher (egal, welche Variante), dass nach JMPs, RTS und so weiter eine Trennlinie ausgegeben wurde. Verstehe nicht, dass kein anderer Monitor diese sinnvolle Anregung aufgenommen hat.

    Ist wahrscheinlich Geschmackssache. Bei einem Disassembly, welches in eine Datei oder auf den Drucker geht und zur Codeanalyse/Reengineering dient, mögen solche Trennlinien ja schon angehen und das habe ich bei einem eigenen solchen Programm auch mal so realisiert. Bei der interaktiven Arbeit im Monitor nehmen eine oder mehrere Trennlinien aber möglicherweise Bildschirmplatz weg. Da muß man dann abwägen, in meinem aktuellen Monitor-Projekt sind Trennlinien beim Disassembly nicht drin und kommen auch nicht rein.


    Ähnlich geht es mir mit bidirektionalem Scrolling beim Disassembly und Hexdump. Einige halten es für das beste seit geschnitten Brot, mich z.B. stört es schon ungemein, wenn unten bei Cursor Down unerwartet eine weitere Dump-Zeile auftaucht obwohl ich mir eigentlich nur Platz schaffen wollte ...

    Ich glaube da liegst du richtig. Wenn Linie N+1 einen Schnittpunkt mit Linie N hat, dann wird bei neu gezeichneter Linie N dieser Schnittpunkt gelöscht und es entsteht eine Lücke. Je nach Transformation müsste das auffallen oder eben überhaupt nicht, wenn es nach der Transformation keine Schnittpunkte gibt.

    auch @0xdeadbeef - der Linienziehalgorithmus von ELITE löscht/zeichnet nicht sondern er invertiert die betroffenen Bildpunkte!


    Damit kann man mit einem zweiten Aufruf und den gleichen Koordinaten eine zuvor gezogene Linie wieder "löschen". Schaut man genau hin, so fällt das auch auf: wo Linien im spitzen Winkel zusammenlaufen, löschen sie sich teilweise gegenseitig aus, laufen eine gerade Anzahl von Linien in einer Ecke zusammen, so "fehlt" dort dann der Eckpunkt.

    Heute beim Stöbern gefunden: Der schlaue Computer in einer Serie in den 80er-Jahre-Ausgaben der Micky Maus - Computer, der schlaue (seite42.de)


    Der Kasten hat drei Schieber, die man jeweils in zwei verschiedene Positionen setzen kann, oben wirft man eine Murmel rein und die kommt dann unten in einem von acht verschiedenen Fächern raus. Es gibt "Programmkarten" nach denen man die Schieber einstellt und "Antwortkarten" mit denen das Ergebnis ausgewertet wird.



    Heutzutage betrachtet ist das ein ganz einfacher 3-zu-8-Dekodierer (so wie ein 74LS138), das aber mal in mechanisch zu sehen macht schon Laune. :D

    [...] ich verstehe nur nicht, dass man da so stolz darauf sein kann.

    Für einen (relativen) Neuling sieht selbstmodifizierender Code einfach erstmal "cool" und "interessant" aus, so nach dem Motto: "Das geht echt?". Erfahrungsgemäß legt sich diese Begeisterung nach einiger Zeit, spätestens dann, wenn man einmal kräftig damit auf die Nase gefallen ist (dazu reicht es schon aus, daß man die (Re-)Initialisierung eines Operanden o.ä. vergißt) und dann setzt man diese Methode ggfs. noch da ein, wo sie am ehesten Sinn macht.


    aitsch: Dazu sei angemerkt, daß selbstmodifizierender Code in keiner Weise mehr Programmiermöglichkeiten eröffnet. Das kann alles auch mit statischem Code ausgedrückt werden.


    Selbstmodifizierenden Code nehme ich her, wenn ich z.B. Grafikroutinen für einen speziellen Anwendungsfall anpassen will. Eine von meinen Linienziehroutinen ( detlef: Du kennst das Beispiel ;)) zeichnet z.B. steigende bzw. fallende Linien, indem - überall da wo nötig - DEY bzw. INY eingesetzt wird. Gleichermaßen wird an passenden Stellen ORA/AND/EOR ausgetauscht, um zwischen Setzen, Löschen und Invertieren von Punkten hin und her zu schalten. Würde ich das nicht machen, bräuchte ich den betroffenen Code entweder in 6-facher Kopie oder würde ihn aufgrund zusätzlich notwendiger Tests was gemacht werden soll unverhältnismäßig ausbremsen.


    Die zugrundeliegende Bresenham-Routine ist 8-fach ausgerollt, für jede Bitposition einmal, hier ein Ausschnitt:

    Das ist für Steigungen |dy/dx|<=1, für Steigungen |dy/dx|>1 gibt es eine zweite ausgerollte Schleife, in der die o.g. Befehle geringfügig umsortiert sind.


    Der Einsprung in die richtige Bitposition erfolgt ebenfalls über einen JMP-Befehl mit modifiziertem Operanden - da ich ohnehin schon im Rest der Routine gut "rumschraube" tut's auch nicht mehr weh, wenn ich da dann auf JMP () verzichte. ;)

    Die Absprungmethode mit einem RTS auf dem Stack macht am ehesten Sinn, wenn vor Ausführung der verschiedenen Routinen noch ein gemeinsamer Anfang (z.B. zum Holen von Parametern) ausgeführt werden soll. Dann steht nicht direkt das RTS nach dem Pushen der Sprungadresse, sondern ein JMP zu dieser Vorbereitungsroutine. Das RTS am Ende der Vorbereitungsroutine erledigt dann den Job.


    KERNAL und BASIC-Interpreter nutzen aber genauso auch indirekte Sprünge, teilweise sogar "konstruierte" Absprungbefehle in der (erweiterten) Zeropage (u.a. bei USR() und allgemein zur Funktionsausführung):

    Code
    1. .AFD1 20 F1 AE JSR $AEF1 ; Ausdruck in Klammern auswerten
    2. .AFD4 68 PLA ; Nummer der Funktion vom Stack zurückholen
    3. .AFD5 A8 TAY
    4. .AFD6 B9 EA 9F LDA $9FEA,Y
    5. .AFD9 85 55 STA $55
    6. .AFEB B9 EB 9F LDA $9FEB,Y
    7. .AFDE 85 56 STA $56
    8. .AFE0 20 54 00 JSR $0054 ; JMP in Zeropage als Unterroutine anspringen
    9. .AFE3 4C 8D AD JMP $AD8D ; Typ des Resultats überprüfen und Resultat zurückgeben

    Wenn die USR()-Funktion über den JMP bei $0054 ausgeführt wird, gibt es gleich noch mal eine Stufe der Indirektion, da die Ausführung beim VC-20 über einen JMP bei Adresse $0000 (!) und beim C64 bei Adresse $0310 geleitet wird.


    An der vorgefundenen Vielfalt merkt man, daß sowohl BASIC als auch KERNAL nicht von einer Person geschrieben worden sind. :D

    Der Zeiger in der Klammer ist doch starr [...]

    Dafür ist der Zeiger, der bei $hhll und $hhll+1 (*) steht nicht starr, was vor allem dann von Belang ist, wenn der JMP-()-Befehl im ROM steht und man von dort zu verschiedenen Stellen hinspringen (können) möchte. $hhll und $hhll+1 sind natürlich im RAM.


    Ich habe den Befehl schon häufiger verwendet, wenn eine Auswahl von Routinen vorhanden war, von denen aber (nach vorherigem einmaligen Test) eine Zeitlang nur eine bestimmte Routine angesprungen werden sollte. Dann ist der indirekte Sprung billiger, als jedesmal wieder die Tests zu machen.


    Klar kann man bei einem normalen JMP-Befehl auch den Operanden ändern, das ist dann zwei Taktzyklen schneller, aber der Befehl muß dazu dann im RAM stehen und das ist dann selbstmodifizierender Code.



    (*) $hhFF als Operand in JMP() sollte man nicht nutzen. Ein NMOS 65xx (also das was üblicherweise im VC-20 oder C64 verbaut ist) holt sich dann das Sprungziel nicht aus $hhFF und $hhFF+1, sondern aus $hhFF und $hh00! Es ist empfehlenswert, den Operanden bzw. Sprungvektor nicht "frei" im Quellcode zu positionieren, sondern dessen Adresse gesondert als Symbol festzulegen.

    Mike: Einerseits offtopic anmahnen [...]

    Du hast die Diskussion hier nicht sorgfältig genug gelesen. Nachdem bereits in Beitrag #2 die Ausgangsfrage prinzipiell geklärt war, ergingen sich die Diskussionsteilnehmer zunächst mal in eine Sammlung von möglichen Lösungen und mein erster Beitrag war auch nicht ganz ernst gemeint (richtig erkannt von #11 und #21). Wenn das jemand nicht erkennt und mich anpflaumt, ist die Meta-Diskussion nicht weit.

    [...] und dann vom Titel "GET/INPUT" bzw. von der Aufgabe "Per Tastendruck [1]-[6] Sprungziele ansteuern" hinführen zu einer per F-Tasten oder Joystick gesteuerten Menuführung (bebildert) [...]

    Aus meiner Sicht ist das eine völlig legitime Diskussionsdrift, im Hinblick darauf, daß das Originalthema beantwortet ist und für den Themenstarter auch eine Weiterentwicklung des Menüs herauskommt.

    [...] ... nix für ungut, aber das unterschreitet ein bisschen meinen Datentransfer[.]

    Den Spruch lasse ich mit Absicht mal unkommentiert.

    Fehleingaben sollte in meinem Vorschlag auch unmöglich sein. Bei Wert VAL(X$)<1 oder >6 wird schlicht kein Sprung ausgelöst.

    Nichts für ungut, aber das grundsätzliche Problem war bereits mit Beitrag #2 gelöst. Das ein Programm damit zurechtkommen muß, wenn ein Scherzkeks trotz offenkundiger Angaben auf dem Bildschirm was anderes als die Tasten 1 bis 6 drückt, sollte klar sein. Wie der Fall dann gehandhabt wird, ist Geschmackssache.


    Das ändert aber auch nichts daran, das so ein Auswahlmenü über verschiedene Tasten einigermaßen altbacken ist und mit wenig mehr Aufwand das Menü so gestaltet werden kann, wie ich im Beitrag #27 geschrieben habe. Da braucht nichts durchnumeriert werden, anstelle der generischen Bezeichnungen können die Menüpunkte so drinstehen, wie sie heißen sollen. Was anderes als die genannten Menüpunkte kann der User nicht auswählen. Natürlich kann der User andere Tasten als f1, f7 oder Leertaste drücken und natürlich kommt das Menü in Beitrag #27 damit zurecht.


    Wenn schnell zwischen Betriebsarten umgeschaltet werden soll, macht eine direkte Eingabe per Tastaturbefehl durchaus Sinn (auch JeeK), aber dann gehört die Liste der Befehle in eine Hilfsseite. Steht die gesamte Befehlsliste ständig auf dem Bildschirm, dann nimmt sie permanent Platz weg, den man besser für was anderes gebrauchen kann. Es reicht völlig aus, irgendwo im Eck ein "? für Hilfe" anzuzeigen, das hab' ich z.B. in MINIPAINT für den VC-20 auch so gemacht:



    Die Statusanzeige rechts unten enthält den Hinweis auf die Hilfeseiten und sonst die Cursor-Koordinaten, die Palette (im Hires-Modus sind nur die Farben 1 und 2 verfügbar, im Multicolour-Modus kommen noch 3 und 4 dazu), den Hinweis, daß man mit Ctrl + Nummerntaste die Farben wechseln kann und auch den Hinweis, daß man mit H und M den Hires- bzw. Multicolour-Modus auswählt. "?" zeigt die Hilfeseiten:



    Die von mir anderweitig vorgeschlagene Menütechnik habe ich z.B. in einer Spielesammlung im Einsatz. Hier wird der Menüpunkt nicht invertiert, sondern andersfarbig dargestellt:



    Da steht jetzt zwar nicht die Bedienung bei, aber Cursor Up/Down gehen, f1/f7 für hoch/runter auch und sowohl Return als auch die Leertaste machen die Auswahl.

    Wir sollten jetzt so ziemlich alle Varianten eines durchnumerierten Menüs durch haben. :whistling:


    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!" ...

    In Zeile 21 ist ein Leerzeichen zwischen den Anführungszeichen.


    Mit ON M GOTO/GOSUB ... kann man dann den gewünschten Programmteil ausführen.

    Files

    • menue.prg

      (382 Byte, downloaded 4 times, last: )