Видео

06:30: Ich hab's bei mir mal in BASIC durchlaufen lassen. Hat bei mir 7 Minuten 41 Sekunden gebraucht.

Sieht ganz gut aus und erinnert mich an die Grafik von Ultima IV und DDD.

Bevor ich es mir anschaue, einen Kritikpunkt. Der Ton ist übel, wenn bestimmte Töne kommen. Es knackt und knistert ... Nimmst du auf Schallplatte auf?

Klasse Video! Ist es mit TASM auch möglich, den eigegebenen Code disassemblieren zu lassen? Das ist wohl kurz über die Ausgabe Pfeil nach links + 4 und dann über den Stern in der Anzeige sichtbar. Das läuft aber alles durch und lässt sich wohl nicht stoppen.

Hab mir ne komplette C64 Anlage aufgebaut, jetzt fehlt mir noch der Drucker. Ich bin ein Kind der 70'er Jahre, und bin damit aufgewachsen. Habe früher den Präsident 6313 gehabt, eigentlich hieß er Robotron, der in der ehemaligen DDR gefertigt wurde. Oh mein Gott, was dieser Drucker an Schalter hatte, und was man da alles einstellen konnte, der Wahnsinn. Jetzt überlege ich mir den 801 zu holen. Ich hoffe ich bekomme irgendwo einen vernünftiges und gut aussehendes Modell. Denn Optik ist mir wichtig, meine Geräte haben nicht die kleinste Macke. Viele Grüße Ralf

echt Nostalgisch. Vor 30 Jahren etwa mit dem ZX 80 angefangen. Ich finde es cool, sowas wider mal zu sehen.

Tolles Video. Ganz nach meinem Stil

Noch ein Tipp, wenn du am Ende einer Routine mittels "jsr" noch in eine Subroutine springst und danach gleich mit "rts" zurück springst, kannst du die Subroutine auch mit "jmp" anspringen. Das "rts" der Subroutine übernimmt dann den Rücksprung. Aber übersichtlicher ist es mit jsr/rts ... ... jsr Subroutine rts wir zu ... ... jmp Subroutine

Danke für das Video. Leider ist ein großer Spaß mit dem automatisch erzeugten Untertitel verschwunden. Hat RUclips das selbst raus genommen?

Bitte nichts aufblitzen lassen! Das stört extrem und kann bei manchen einen Anfall auslösen. Wenn du das im fertigen Spiel haben willst, dann mache es ausschaltbar. Liebe Grüße.

Interessante Lösung. Das einzige was mir auffällt: Du beschreibst am Anfang deine Variablen, nutzt sie aber im Code direkt. Normalerweise definiert man alle verwendeten Variablen als Konstanten am Anfang und lagert die sogar bei größeren Projekten in eine eigene Datei aus. Das erhöht die Lesbarkeit des Codes enorm und verhindert Fehler. In einem Jahr, oder wenn es mal 50+ Konstanten werden, weist du die Nummern nicht mehr auswendig. z.B. PLAYER_LO = 251 PLAYER_HI = 252 PLAYER_SICHT = 828 usw. Auf eine Schreibweise einigt man sich vorher. Aber früher hat man Konstanten groß geschrieben.

Nice. Das Spiel nimmt langsam Gestalt an. So eine Kopierroutine kannst du dir aber auch selber schreiben. Das ist kürzer als die Parameter in die richtige Form für die Systemroutine zu bringen.

...man sagt dazu auch, es sind die verschiedenen Adressierungsarten eines Befehls.

Als Spieleentwickler weiß man ja aus leidvoller Erfahrung, dass die Frage "Was habe ich mir denn dabei gedacht?" nicht selten eher optimistischer Natur ist... Leider ist Basic die maximalst undankbarste Sprache, um so ein Textadventure zu bauen. Hast du mal darüber nachgedacht, das ganze einfach mit dem CC65 zu machen? Da geht das Inline-Assembling auch deutlich einfacher. Ich nutze den inzwischen für die Entwicklung für den Commander X16 und wenn man eh cross-entwickelt, eigentlich der angenehmbere und flexiblere Workflow. Tools und Workflows implementiere ich dabei in der Regel in Python, da kann man dann mittels PyGame auch schnell kleine visuelle Tools bauen. Edit: Ok, um 1:42 war das dann sogar Thema. Ja, CC65 ist ein recht ordentlicher C-Compiler für alle 8 Bitter. Sehr einfach in der Anwendung und man ist einfach so viel schneller am Ziel. Und in Assembler optimieren kann man per Inline dann ja auch jederzeit, aber strukturelles geht halt viel leichter von der Hand.

Ein klein wenig schneller kriegt man es so hin (man spart damit den Overhead des SYS Befehls): POKECY,Y:PRINT:POKECX,X:PRINT"A"; Ich war aber noch erstaunt, wie langsam die TAB() Funktion ist. Der zusätzliche Poke ist schneller als ein PRINTTAB(X)"A";

Mutmaßlich noch schneller geht es, wenn man die Bildschirmadresse gleich in Assembler ausrechnet. Ich hab das mal in SMON gemacht. Die Syntax lautet: SYS 49152, X, Y, CODE Da man im Assembler nicht direkt die Y-Koordinate mit 40 multiplizieren kann rechne ich stattdessen die Bildschirmposition so aus: P = 32*Y + 8*Y + X + 1024 Quellcode: jsr aefd ; Komma einlesen jsr b79e ; Bytewert einlesen (steht im X-Register) stx fb ; X-Koordinate zwischenspeichern ; Bildschirmposition berechnen jsr aefd jsr b79e ; Y-Koordinate einlesen lda #00 sta fd txa asl asl asl tay ; Y-Koordinate * 2 * 2 * 2 im Y-Register sichern asl rol fd ; etwaigen Übertrag im High-Byte sichern asl rol fd sta fc ; FC/FD hat nun das Ergebnis aus Y-Koordinate * 32 tya ; Vorherige Sicherung zurückholen ... clc adc fc ; ... und aufaddieren sta fc lda fd adc #04 ; 1024 aufaddieren sta fd jsr aefd jsr b79e ; Bildschirmcode einlesen txa ldy fb ; X-Koordinate wieder auslesen sta (fc),y ; Code in den Bildschirm schreiben rts

integer variablen verwenden, also cx%, cy% und cp%, usw, dann fällt die fließkomma wandlung zur laufzeit weg

Wenn du hinter den Printbefehl in Zeile 320 und Zeile 420 ein ";" packst, so müsste dies schneller gehen, weil der Basic-Interpreter dann kein "Enter" auführen muss.

So ein kleines Kindheitstrauma von mir: mich würde interessieren, wie man das richtige Timing für left/right borderless hinbekommt. Oben/Unten ist durch den vertical blanking IRQ ja recht simpel gewesen, aber ich habe mich damals sehr schwer getan, den Rand links und rechts zu entfernen. Klar - habe ich heute den Assembler Code nicht mehr zur Hand, kann mich aber gut erinnern wie ich versucht habe, das Timing mit einer Anzahl NOP's zu treffen. Das funktionierte in meinem Fall leider nur teilweise und fransig. Stellenweise war der Rand weg, stellenweise nicht. Vielleicht hat hier jemand einen Source oder einen kleinen Technik-Guide wie der Trick funktioniert - damit ich heute mit dem Thema abschließen kann xD ;)

Basic auf dem C64. hab ich ja schon ewig nicht mehr gesehen. Und jetzt das ganze mal in Assembler.

Die PRINT-Version kannst du effizienter gestalten: 1. Das Home-Zeichen muss natürlich das erste Zeichen der PX$-Zeichenkette sein, heißt natürlich auch, dass die erste Spalte dann 1 ist. 2. Mehrere Ausgaben in einer einzelnen PRINT-Anweisungen sollten nicht durch unnötige Zeichen wie + oder ; verlangsamt werden, direkt hintereinander schreiben. 3. Das letzte Zeichen einer PRINT-Anweisung sollte ein ; sein, sonst wird noch eine Zeilenumbruch ausgeführt, was Zeit benötigt. 4. Spar dir PX$ sondern nutze TAB(X) zur direkten Positionierung Resultat: 49 Jiffys bei 60 Durchgängen und x=15, y=6 statt deinen 70. PRINTLEFT$(PY$,Y)TAB(X)"B"; und PY$="{home}.." Beim Poken in den Bildschirmspeicher musst du natürlich noch berücksichtigen, dass du die Zeit verdoppelst, wenn du auch die Farbe setzen musst, außerdem bist du auf ein einzelnes Zeichen beschränkt. Du kannst kein Zeichen an die letzte Bildschirmposition printen, da dann ein automastischer Zeilenvorschub stattfindet.

6:40 Ich habe hier einen Fehler gemacht und ein Steuerzeichen für die X-Positionierung zu wenig in den String gepackt. Das führt später zu dem Ausgabefehler... 😅🙈

Bin ich blöd weil ich Assembler immer noch nicht verstehe? Irgendjemand hat sogar mal behauptet das man Assembler in einer Stunde lernen kann, da glaube ich aber nicht!

What impresses me about this printer is the simplicity and robustness of the mechanism. There is very little to go wrong with it. Quite a clever design.

Ich bin Baujahr 67 und habe den C64 live erlebt. Mit ihm zu arbeiten und zu spielen war einfach unglaublich. Fliegende Buchstaben mit Musik war schon was ganz besonderes und gefühlt war es damals wahnsinnig schnell.

Clevere Idee, das mit der Hintergrundfarbe zu lösen. Die fehlende Initialisierung des Y-Registers wurde bereits erwähnt. Aber bei 6:20 hast du auch noch einen kleinen Fehler in deiner Erklärung: Zuerst wird per SEC ("Set Carry-Bit") das Carry-Bit gesetzt. Wenn du nach der Subtraktion des Low-Bytes (251) unter 0 kommst, wird das Carry-Bit gelöscht und das *gelöschte* Carry-Bit wird bei der zweiten Subtraktion vom High-Byte (252) abgezogen.

Nach gut 30 Jahren kann ich mich tatsächlich immer noch an die grundlegenden Assemblerbefehle erinnern. :-) Ich hatte damals ein Buch mit einem kompletten, kommentierten ROM-Listing, das hatte ich quasi unter dem Kopfkissen. Nun dann: SYS 64738 ;-)

2:22 Das ist wirklich egal. Ich habe zB. für $ffd2 eben Print als Label genommen. Schön wieder was in Ass zu lesen 🙂

Aber Andreas im C64 Studio gibt es doch dafür einen Umrechner den Calculator. Zu finden im Rider Windows. Dort braucht du dann nur die Dezimal eingeben und er spuckt dir den Hex-Zahl auf. Ansonsten ein schöne Routine.

Es triggerte schon wirklich leute, wenn du assembler dezimal eingibst? 😅

WAS? Keine Hex-Zahlen? SOFORT DEABONIERT!!1!11!!1!!!1!11!!

Tja, bis die ganzen Bits so übertragen sind, das dauert halt.

Hallo, könntest Du die Stellenwertvariable SW nicht weglassen und stattdessen in Zeile 1050 schreiben: tw$=0:if (bw and 2^i) > 0 then tw$="1" ?

Coole kleine Routine! Ich mag das sehr, das Basic mit kleinen Routinen zu pimpen :). Eine Anmerkung: ich bin mir nicht sicher, aber kann es sein, dass du das Y Register nicht initial einmal (wenigstens) auf 0 setzt? Du nutzt es bei der Ausgabe. Es könnte allerdings sein, dass, ohne Initialisierung, das Register noch andere Werte als 0 enthält. Aber vielleicht habe ich dein Listing auch nicht ganz sehen können.

Ach, was waren das noch für tolle Zeiten! Da waren noch die CPU's und deren Assembler so leicht verständlich, dass man einfache Programme tatsächlich nur in Zahlen eingeben konnte. Mit dem Amiga und dem MC68000 hatte die Assembler-Freude ihren Höhepunkt.😊

Der C64 war augenfreundlicher ;)

Ich glaube, ich schulde JSON eine Entschuldigung 🤪

Ich finds spannend wie Du das machst. Für mein Textadventure (Kellerabend - The Game) hab ich z.B. das mit dem Objekt wenn es schon mal betrachtet wurde gelöst indem ich beim Objekt eine "untersucht" Variable habe (also wenn untersucht setzt er die auf 1, beim nächsten mal schreibt er einen Default Text (das hast Du schon untersucht...) . Aber auch andere Variablen, also man eine Flasche z.B. auch "trinken" kann.

Jau, Games aus der Zeitung abtippern: langwierig, fehlerbehaftet aber günstiger als fertige Games kaufen - von denen es ja zu Beginn auch noch nicht so viele gab… 😂

Super Video. Damals ohne Internet und genug Taschengeld für bezahlbaren Input (Zeitschriften / Bücher) war das totales Herrschaftswissen und ich ärger mich ja das ich mir das früher verwehrt geblieben ist - gab halt keinen der einem da Helfen konnte ;-). Aber das denke ich mir auch manchmal wenn ich aktuelle Nachhilfevideos in Mathe sehe.

Ab 6:48. Sorry, es ist doch möglich, auf ein bestimmtes Datalelement nach einem Restore zuzugreifen. Ich hoffe, mein kleines Basicprogramm kann es dir verdeutlichen: __________________________________________________________________________ 10 l=8 20 printchr$(147);"register , data" 30 print"--------------------------" 40 fori=1to10: 50 ifi=lthen b1=peek(65):b2=peek(66) 60 y=peek(66)*256+peek(65) 70 print i;y;" , ";:read a$:print a$:nexti 80 print"--------------------------" 90 restore:rem setzt datalelement nach Basicstart 100 print"nach restorebefehl:";peek(66)*256+peek(65) 110 print"--------------------------" 120 print "poke 65,"b1":poke 66,"b2;" = {reverse on}";b2*256+b1;"{reverse off}" 130 poke65,b1:poke66,b2 140 read a$ 150 print "erster read nach restore: {reverse on}";a$;"{reverse off}" 160 input"welchen eintrag nun";l 170 if l >10 or l <1then160 180 restore:goto20 190 data "tuppes ", "alfons " , "heidi " , "petra " , "schnucki" 200 data "felix ", "saeuft " , "und ist" , "hacke " , "dicht " 210 rem ende des listing

Ich habe damals nichts von all dem gemacht und stattdessen mit dem Joystick in der Hand 10 Minuten gebannt auf den Bildschirm gestarrt! Und dann: Scheiße! Joystick am falschen Port! 😂

Interessant, danke! Wie kommt es eigentlich, dass der Computer (nach einem erfolgreichen LOAD) das Laufwerk anscheinend eigenhändig anhalten kann, zum Lesen aber das PLAY des Nutzers braucht?

Das Schöne an den alten Heimcomputern war, dass man das Ding noch komplett verstehen konnte. Grafikchipsatz, Soundchipsatz, Ports, Speicherverwaltung... oft sehr tricky und viele Kniffe, um mit den wenigen Ressourcen auszukommen, aber dafür überschaubar. Heute sind Programmierer immer spezialisierter und leider oft nicht so tief drin wie es für ein effizientes Programm sinnvoll wäre. 🙂

Sehr schönes kleines Spiel. Aber es fehlt noch ein Ziel wie z. B. eine Schatztruhe, die man durchs Labyrinth erreichen muß. Der Vorteil von Sprites wäre außerdem, daß sich bis zu 8 Ebenen/Sprites übereinander legen ließen. Das wäre dann sehr farbenfroh.