Programm rückwärtes erkennen

  • Programm rückwärtes erkennen

    Hallo,
    angenommen ich habe irgend ein Listing, welches aus sagen wir 3 Teilen besteht, die ersten 2. Teile sind Data Programme und der 3. Teil ist das Hauptprogramm.
    Gibt es nun irgend eine Möglichkeit, wie ich erkennen kann, welches der Dataprogramme für a) Graphik b) Joystickroutine c) Maschinencode ect. ist.
    Gibt es da einen Trick, das ich anhand wo was hingepoked wird es schon weiß, oder gibt es ne andere Möglichkeit.
    Weil ich habe was da, wo eine super Joystickroutine in den Data's drin ist und noch was anderes, tja und da bräuchte ich nur die Joystickroutine, somit kann ich das irgendwie feststellen ?

    danke
    :cry: ......42, what else ?? :cry:
  • aturnwald schrieb:

    Ja, danke, mit dem Thema habe ich mich bereits voll Vertraut gemacht, ich meinte nur, wie ich es erkennen kann, anhand der DATA-Zeilen, für was diese sind.
    Diese Daten muß Du durch einen Disassembler jagen oder im Vice mit einem Monitor anschauen.
    Mitwäre das nicht passiert! :prof:
    :syshack: Meine 3D-Drucker Teile auf thingiverse.com/oobdoo/designs :strom:
    Sammlung | 91 Bücher bzw. 25.261 Buchseiten mit Z80/8080 Power
  • Wenn ich Dich richtig verstehe, hast du ein BASIC Listing mit DATA Teilen, die diverse Komponenten beinhalten und irgendwo hingeschrieben werden (POKEs).
    Wohin sie geschrieben werden, kannst du anhand des Listings ja sehen, sonst würde es ja nicht funktionieren.
    Das müssten laut deiner Beschreibung wohl mindestens 3 FOR Schleifen sein.

    Wenn es einen Teil Maschinencode hat, wird dieser irgendwo per SYS aufgerufen. So kannst du diesen Teil isolieren.
    Daraus aber was Verständliches zu machen, müsstest Du einen Disassembler an der entsprechenden Speicherstelle starten.
    VICE kann das AFAIK, sonst gibt es andere Tools z.B. für Windows.

    Die Grafikdaten werden wohl in einem Bereich gepoket, wo der VIC diese sieht (wenn das ähnlich wie beim C64 ist).

    Die Joystick Routine ist in BASIC oder in ASM in den DATA-Zeilen? Wenn in BASIC, solltest du anhand der Joy-Speicherstellen, den entsprechen Bereich im Listung auch isolieren können.
    ___________________________________________________________
    Meine Kreationen: Deviant Art | Toonsup | Flickr | Youtube
    | Twitter
    Avatar: Copyright 2017 by Saiki
  • also z.B. das Listing besteht aus 3 Teilen 1. Teil Data für Graphic, 2: Teil Maschinensprache für Joystick, Steuerung der Figuren ect. 3. Teil reines Basic für das Spiel selbst.
    und ich dachte ich kann halt anhand der Data sehen wo die Joysticksteuerung liegt, bzw. die Steuerung der div. Figuren usw.
    So, habe ich es gemeint.

    danke für die Beschreibung hilft mir weiter
    :cry: ......42, what else ?? :cry:
  • Einem Hexdump kann man mit ein bisschen Erfahrung durchaus sofort ansehen, ob es sich um ein BASIC-Programm, Maschinencode, Zeichensätze, Sprites oder ungepackte Grafiken handelt. Wer soviel Erfahrung hat, macht aber nicht mehr mit DATAs oder dezimalen Bytewerten rum. :D
    Yes, I'm the guy responsible for the ACME cross assembler
  • aturnwald schrieb:


    ich dachte ich kann halt anhand der Data sehen wo die Joysticksteuerung liegt, bzw. die Steuerung der div. Figuren usw.
    Anhand der (Hex)Zahlen in den Datas kann man schon ein Programm erkennen, das ist aber extrem schwer.
    Mitwäre das nicht passiert! :prof:
    :syshack: Meine 3D-Drucker Teile auf thingiverse.com/oobdoo/designs :strom:
    Sammlung | 91 Bücher bzw. 25.261 Buchseiten mit Z80/8080 Power
  • Irgendwo in den DATAs dürfte wohl die Folge "17, 145" vorkommen. Das wäre zumindest der Teil mit der Joystickabfrage. Wobei neu schreiben vermutlich eh einfacher/besser wäre.

    Liegt das Programm irgendwo im Netz?
    Read'n'Blast my jump'n'stop-text-sprite-scroller Select A Move

    Ex-TLI (The Level 99 Industries) & Ex-TNP (The New Patriots) & Ex-TEA (The East Agents) & ?
  • Mac Bacon schrieb:

    Einem Hexdump kann man mit ein bisschen Erfahrung durchaus sofort ansehen, ob es sich um ein BASIC-Programm, Maschinencode, Zeichensätze, Sprites oder ungepackte Grafiken handelt. Wer soviel Erfahrung hat, macht aber nicht mehr mit DATAs oder dezimalen Bytewerten rum. :D
    Och, das gelegentlich aber immer noch Spaß! :D

    Ernsthaft, wenn ein relativ kleines Maschinenprogramm zusammen mit dem Hauptprogramm in BASIC immer noch eine Datei bleiben soll, tut so eine DATA-Wüste nicht wirklich weh.

    Wenn man sich dann die alten Programme zum Abtippen anschaut, kriegt man mit der Zeit auch den Blick dafür, wo die Grafik-Daten stehen. Zeichensatzdaten stehen gerne mal in DATA 8er-Blöcken, in Maschinenprogrammen kommt ewig häufig "169,0" (von LDA #0), "141" (von STA $....) vor, etc.

    Ansonsten gilt ohnehin, erstmal schauen wo die Daten hingehen, die FOR-Schleifen sind ja meistens genauso angeordnet wie die DATA-Zeilen. Alles außerhalb des BASIC-Bereichs ist mit hoher Wahrscheinlichkeit Maschinencode (schauen, welcher SYS zum Einsatz kommt), POKEs in den Bereich ab 7168 schreiben beim VC-20 mit hoher Wahrscheinlichkeit Zeichensatzdaten weg.

    Und das binäre Äquivalent zu allen Bytes von 0 bis 255 sollte man als Programmierer ohnehin im Kopf haben. Dann kann man die umdefinierten Zeichen (oder beim C64 auch die Sprites) direkt aus den dezimalen Zahlen lesen. ^^

    Allerdings kann es sich bei den DATA-Zeilen auch um was ganz anderes als Grafikdaten oder Maschinensprache handeln. Ein Spiel auf dem VC-20 ("FRESSMANN"), hatte in einer DATA-Zeilen-Wüste für einen der Geister den kompletten Weg durchs Labyrinth abgelegt, so daß jede Position auf jeden Fall so ca. alle 60 Sekunden besucht wurde und es keinen sicheren Ort zum Verstecken gab. 8|
  • tausend Dank, so ungefähr habe ich es mir auch gedacht, nur leider liegen meine Maschinensprache, also die Kenntnisse sehr lang zurück, dazu brauche ich wieder ne Weile bis alles im Hirn drin ist, werde aber ohnehin nicht darum rumkommen, für das geplante Game manche Maschinenroutinen zu benutzen bzw. zu schreiben. Jedoch wart Ihr mir alle eine sehr
    große Hilfe heute gewesen. Ich bin mir sicher, dass wenn noch Fragen auftauchen werden, ich mich wieder zu Wort melde, auch werde ich den Fortschritt des Games euch mitteilen.

    Das Programm was ich meinte welches aus 3 Teilen bestand war Ghost Manor, und soweit mir bekannt ist ist im 1. Teil die Graphic drin, und im 2. Teil die Joystickabfrage und noch ein paar Dinge zur Steuerung von div. Monstern, da dieser Teil jedoch wirklich clever gemacht ist, dachte ich mir, dass ich eben diesen benutzte.

    Sorry, aber ich muss nochmals kurz weg, den Bubio abholen, melde mich dann nochmal.

    Lg. Toni
    :cry: ......42, what else ?? :cry:
  • aturnwald schrieb:

    tausend Dank, so ungefähr habe ich es mir auch gedacht, nur leider liegen meine Maschinensprache, also die Kenntnisse sehr lang zurück,
    Wenn Du über die Jahre weiterhin irgendwas programmiert hast, dann bist Du da ganz schnell wieder drin und sogar besser als damals.
    War bei mir zumindest so.
    Mitwäre das nicht passiert! :prof:
    :syshack: Meine 3D-Drucker Teile auf thingiverse.com/oobdoo/designs :strom:
    Sammlung | 91 Bücher bzw. 25.261 Buchseiten mit Z80/8080 Power
  • Ahahaha, ausgerechnet Ghost Manor a.k.a. Castle of Dr. Creep!

    Da steckt praktisch die komplette Animation im Maschinenprogramm drin, pro Schritt werden auf dem Bildschirm gut und gerne 20 Objekte nach Art eines Fließbands bewegt.

    Die Joystickroutine macht da nur einen winzig kleinen Teil aus. Und so prall ist die Joystickabfrage nun auch wieder nicht - sie faßt nur die Werte aus 2 VIA-Registern in ein Byte zusammen. Nichts, was man nicht auch selbst in 5 Minuten (besser) hinbekommt, wenn man weiß wie die Zuordnung von Richtungen/Feuer zu den Register-Bits ist.

    Außerdem haben viele Listings aus der Zeit das Problem, daß sie komplette Register-Inhalte abfragen, anstatt sauber die Bits auszumaskieren. Darum funktionieren die Joystickroutinen dann auf einmal nicht mehr, wenn von Floppy (nach-)geladen wird.

    ...

    Dino-Eggs (auch in meiner Spielesammlung drin) macht die Animation übrigens auch sehr ähnlich. :)
  • danke für den Hinweis, ich wäre da nie im Leben darauf gekommen, das es evtl. Probleme mit der Abfrage geben könnte, aber ich war halt der Ansicht, dass wenn ich die Routinen aus diesen Prg nehme, dann spare ich mir was Zeit, klar komme ich mit der Zeit wieder darauf und werde besser werden als zuvor, weil nur so lernt man, kein Problem, jedoch bzgl. der Programme, die Abfrage und incl. der Animation hätte mir es halt schon angetan, weil es einfach gewesen wäre, denn ich habe immer noch vor, einige Routinen in Maschinensprache zu schreiben, bei der Komplexität des Spieles was mir vorschwebt und da wäre mir halt Ghost Manor grad recht gekommen, aber egal mich hätte eh nur interessiert, ob mein Gedankengang überhaupt funktioniert hätte, da ich eben in Maschinensprache nicht allzu gut bin, aber ich werde es lernen, grins. Denn seit 2 Tagen mache ich bereits einen Online-Aufbaukurs in Maschinensprache für Commodore Rechner mit, was ziemlich lustig, frustrierend und gleichzeitig witzig ist, denn ich habe gespannt, dass ich eine Menge vergessen hatte, jedoch ist mir auch wieder viel eingefallen, so das es passt.

    In Basic habe ich überhaupt (fast) keine Probleme etwas zu schreiben, nur bei Maschinensprache happerts gescheit und diese ist für das Projekt arg von Nöten ist, außerdem, wird die Maschinensprache nicht beim Nachladen gelöscht, so dass dann zumindest div. Steuerroutinen ect. erhalten bleiben, welche ich dann mit SYS bzw. USR aufrufe und übergebe.
    Naja wird scho werden.

    Ich danke euch beiden auf jeden Fall für die Hilfe und melde mich mit Sicherheit bald wieder.

    Lg. euer Toni
    :cry: ......42, what else ?? :cry: