Posts by awsm


    Dachte vom Äußeren passt es gut auf einen Thompson MO5, aber das integrierte BASIC kennt auch keinen EDIT Befehl. Es gab wohl noch spezielle BASIC Varianten (BASIC 128 und 512) mit erweitertem Befehlssatz, aber da endet man bei einer einzigen Ergebnisseite in Google...

    Hahaha, da kommen auf jeden Fall Erinnerungen hoch, danke schonmal dafür :)

    Sowas hab ich als Kind auch ständig gemacht, besonders die Doppelpunkte waren wichtig für's Timing und ich kam mir unglaublich smart vor. Ob sinnvoll oder effizient ist eigentlich egal, wichtig ist, dass man mit wenigen Zeilen Code was auf den Schirm zaubern konnte, was so sonst nicht ging. Ich wünschte, es gäbe heute noch so einfache Möglichkeiten, die Magie von Programmierung den eigenen Kindern nahe zu bringen.

    Das Programm zu starten ist kein Problem. Ich habe unter https://github.com/skeetor/c64-src ein Beispiel gemacht, wo ich das gleiche Programm für den VC20 und den C64 assemblieren kann, und der Teil der den Basicstart macht, der ist eben relativ unkompliziert in einem Macro. :D


    Hatte vermutet, dass ich es missverständlich formuliert hatte... Ghost Town hat auch nur eine Codebase für C16 und C64 und kompiliert je nach Target Platform ein dediziertes PRG. Meine Frage war, ob es möglich ist, wirklich nur ein einziges Binary File zu kompilieren, welches durch interne Codeweichen erkennt, auf welcher Plattform es läuft?

    Spannende Diskussion. Mein zweiter Computer nach dem C16 war ein C128d und für mich war das Upgrade von BASIC 3.5 zu BASIC 7.0 grandios, besonders die Sprite Routinen haben mir bei meinen ersten eigenen Spielen enorm geholfen.


    Vor einiger Zeit hatte ich eines meiner Lieblingsspiele vom C16, Ghost Town, auf den C64 portiert:

    http://www.kingsoft.de (ja ich weiss und nein, ich habe keine Sorge vor Abmahnung :) )


    Dabei habe ich auch über das Für und Wider einer C128 Version nachgedacht und kam zu dem Schluss, dass es sich in diesem Fall (Single File) nicht lohnt, was wirklich schade ist, weil sich für mich so ein Kreis geschlossen hätte.


    Vielleicht hat ja jemand Lust, Ghost Town auf den C128 zu portieren?

    https://github.com/Esshahn/Ghost-Town


    Ich glaube was wir brauchen, ist eine Datenbank/Übersicht von interessanten Code Snippets und Konzepten, die eine dedizierte C128 Version aufwerten würden. Dabei muss es nicht immer ein Hardwarefeature sein.


    * Durch den Fast Mode im Border spart man z.B. Rasterzeit, welche man in der Folge z.B. für aufwändigere Effekte nutzen könnte, z.B. bessere Gegner-KI, Rasterbars statt einfarbigem Himmel, Digi-Drums usw.


    * Den größeren Speicher könnte man nutzen, um zeitkritische Loops auszurollen, was zumindest bei Demo-Effekten nicht unrelevant ist.


    * Das Double Buffered Color RAM ist ebenfalls eine feine Sache und beschleunigt Scrolling-Routinen oder erlaubt nette Demo-Effekte, die so deutlich zeitsparender arbeiten (und schon wieder ist weitere Rasterzeit gespart).


    Ich glaube man kann schon eine Menge herausholen, nicht mit neuen Features, sondern mehr von dem, was vorher möglich war. Toll wären auch Code Snippets, die zuverlässig einen C128 detektieren und man so andere Subroutinen aufrufen kann. Wenn ich mich recht erinnere, ist der BASIC Start beim C128 nicht bei $0801, daher vermute ich es ist nicht trivial, _ein_ PRG für beide Plattformen zu compilen, aber es wäre natürlich extrem cool, wenn man sich entscheiden könnte, ob man das PRG im C64 oder C128 Modus startet.

    Dann würde ich das gleich mit React oder Angular oder sowas machen. Damit kann man dann richtig programmieren und vor allem dank JSX direkt Html in den Code reinschreiben. Und dann noch Typescript nehmen statt Javascript. Dann hat man insgesamt eine brauchbare Programmierumgebung.

    +1

    Geht übrigens alles auch mit Electron, weil die Build Tools, die Du verwendest, TypeScript nach Vanilla JavaScript transpilen. React harmoniert auch gut mit Electron.


    Man ist ja jeweils von seiner eigenen Bubble beeinflusst, bei mir (Web & App) sehe ich inzwischen am häufigsten Macs im Einsatz, dann Linux. Windows ist kaum vertreten. Damit will ich mich auf keine Seite schlagen, denke nur, dass es immer wichtiger wird, Cross-Plattform zu entwickeln. In der Retro-Szene sind die Verhältnisse sicherlich noch deutlich Richtung Windows verschoben, aber es wäre schade, wenn andere Nutzer per se ausgeschlossen werden.

    Maniac Mansion und Zak in 640x400, war für mich eine willkommene Abwechslung :)

    Gab es die beiden wirklich in hoher Auflösung? Youtube scheint dazu nichts zu haben und an Screenshots finde ich nur alte Scans, die mir nicht nach echtem 640x400 aussehen. Wer weiß mehr? Welche Adventures sind hochlauflösend erschienen?


    Hey aitsch, das ist ja schon eine Weile her, aber ich erinnere mich, dass ich die Sache nicht weiterverfolgt habe. Bin gespannt, ob Du eine Lösung findest, vielleicht krame ich dann mein Gerät auch wieder heraus :)

    Beim disassemblieren von Programmen stosse ich oft vor die erste Hürde - das Programm wurde mit Exomizer, PuCrunch oder ähnlichen Tools gepackt. Bisher versuche ich, die Entpackroutine nachzuvollziehen und nach dem Entpackvorgang den Code so zu verändern, dass das eigentlich Programm nicht gestartet wird. So kann ich den entpackten Code aus dem Speicher auslesen und abspeichern.


    Gibt es ein gutes Vorgehen, um bei einem gepackten Programm zu identifizieren, welcher Packer/Cruncher verwendet wurde? Gibt es vielleicht sogar Tools, die den obigen Prozess erleichtern?


    Vielen Dank für Eure Hilfe.

    Ich spiele ein wenig mit dem disassemblieren von Code herum.

    Dabei stolpere ich über ein Problem, bei dem ich nicht weiss, wie ich es lösen kann.


    Beispiel (den Sinn des Code bitte ignorieren.)

    Der Maschinencode dafür


    Code
    1. ad 17 08 4c 18 08 10 8d 21 d0 60

    Beim disassemblieren gehe ich so vor, dass ich eine mnemonic Tabelle habe, in der ich nachschaue, aus wie vielen bytes eine Anweisung besteht,


    Code
    1. "ad":{
    2. "ins": "lda $hhll"        <- hh und ll durch die nächsten 2 folgenden bytes ersetzen
    3. },


    So wird also "AD 17 08" also LDA $0817


    Für einfache Listings, in denen sich Code und Daten nicht mischen, funktioniert das schon sehr gut. Nicht aber im obigen Fall, wo Daten mitten im Code stehen.


    Das !byte $10 wird hier nämlich durch das mnemonic BPL ersetzt, welches ein weiteres Byte erwartet für die relative Adressierung


    Code
    1. "10": {
    2. "ins": "bpl $hh",
    3. "rel": 1
    4. },


    Dadurch stimmt dann der folgende Code nicht mehr.

    Der obige Bytecode wird daher zu diesem Code disassembliert:


    Code
    1. * = $0811
    2. lda x0817
    3. jmp x0818
    4. x0817
    5. bpl 8d
    6. and ($d0,x)
    7. rts


    Ich vermute daher, dass ich mit dem aktuellen Ansatz, Code zu erkennen, in einer Sackgasse stecke.

    Ich wüsste aber auch nicht, wie man mit Sicherheit Code von Daten unterscheiden könnte. Wäre der obige Datenbereich statt $10 (für BPL) zum Beispiel $EA (NOP) gewesen, dann würde es zwar codeseitig keinen Sinn ergeben, aber durchaus wieder korrekt kompilieren.


    Ich rufe an dieser Stelle direkt mal Assembler-Gott Mac Bacon herbei :)

    Freue mich über Hinweise, Tipps und Denkanstösse :)