Turbo Rascal Syntax error, “;” expected but “BEGIN”

Es gibt 104 Antworten in diesem Thema, welches 21.254 mal aufgerufen wurde. Der letzte Beitrag (13. Juni 2024 um 10:20) ist von Fraburm.

  • Nimm nicht meine $100 als erhöhung sondern immer $ff dann geht es.

    Code
    memcpy(^$2000,0,^$400,255);
    memcpy(^$20ff,0,^$4ff,255);
    memcpy(^$21ff,0,^$5ff,255);
    memcpy(^$22ff,0,^$6ff,255);

    Jetzt wird zwar $20ff kopiert, dafür fehlen aber $21fe und $22fe.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Dann nimm mal die Hexzahlen raus und setzt einmal die Decimalzahlen und addiere mal, sind übersichtlicher.
    Vielleicht ist meine Rechnung falsch.

    Ich sehe auf den Screen nicht, welche Zeichen das jetzt sind.

    Gruss

  • Gute Idee, die haben mehr ausführliche Daten drin.

    Bitte melde dich an, um diesen Link zu sehen.

    GRuss

  • Bitte melde dich an, um diesen Link zu sehen. könntest du mir das mit dem Abzählen etwas näher bringen?

    Geht das so?
    0.............255(FF)/0...............255(FF)/0.................255(FF)/0...................255(FF)
    ||||||Datei|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||EOF (1000 Byte's groß)
    |...................... ||............................ ||............................||.............................|
    $2000...... $20FF/$2100............$21FF/$2200............$22FF/$2300................$23FF

    Oder fängt der bei 1 erst an zu kopieren, anstatt bei 0?
    Deswegen fehlen $21fe und $22fe?

  • Load und Save hat der TRSE nicht drin.

    Vielleicht gibt es mal einen Spezialisten der eine funktionsfähige LOAD/SAVE dafür konstruieren kann in ASM?

    Gruss

  • Bitte melde dich an, um diesen Link zu sehen. ich habs jetzt rausgespielt.

    Code
    memcpy(^$2000,0,^$400,255);
    memcpy(^$20FF,0,^$4FF,255);
    memcpy(^$21FE,0,^$5FE,255);
    memcpy(^$22FD,0,^$6FD,255);

    Ist immer wieder um einen nach vorne geschoben.

  • Das wars , habe ich jetzt auch erkannt wo ich meine Decimalzahlen reingesetzt hatte.
    Mit Hex-Zahlen war mir dieses Hochzählen nicht so erkennbar.

    Gruss

  • Bitte melde dich an, um diesen Link zu sehen. könnte der 4. Befehl "memcpy(^$22FD,0,^$6FD,255);" nicht etwas kürzer gemacht werden? Also nicht 255 groß, sondern etwas kleiner. (20 weniger?)

    Ja, geht. Hab es gerade ausprobiert. Der Bildschirm ist nur 1000 Byte's groß. Spart ein paar Kopierereien.
    TRSE zeigt aber immer noch 17 Cycles für alle memcpy Zeilen an, obwohl die 4. ja jetzt etwas schneller sein müsste, oder?

  • Du kannst da von 0-255 reinsetzen.

    Schau dir mal bei beiden den ASM-Code an mit den Durchläufen.
    Ich weiss jetzt nicht welchen Disassembler man nehmen kann.

    Gruss

  • Nach "Cycles" gemessen ist deine die Schnellere. CopyFullScreen nimmt 114 Cycles und deine nur 77 Cycles.

    Wenn ich die Doku zu copyfullscreen richtig verstehe kopiert es exakt 1000 bytes, und nicht 1024 (bzw 1020 bei 4 mal memcpy mit 255). Das macht es vermutlich in einer geschachtelten schleife um codegröße zu sparen, klar ist das ein bisschen langsamer als 4 kopierschleifen nacheinander.

  • Bitte melde dich an, um diesen Link zu sehen. könntest du mir das mit dem Abzählen etwas näher bringen?

    Geht das so?
    0.............255(FF)/0...............255(FF)/0.................255(FF)/0...................255(FF)
    ||||||Datei|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||EOF (1000 Byte's groß)
    |...................... ||............................ ||............................||.............................|
    $2000...... $20FF/$2100............$21FF/$2200............$22FF/$2300................$23FF

    Oder fängt der bei 1 erst an zu kopieren, anstatt bei 0?

    Das Kopieren beginnt ganz normal bei Offset 0.

    Dass man mit dem Aufruf keine komplette Page kopieren kann, liegt einfach an der Bedeutung des vierten Parameters:

    Damit wird in diesem Fall die Anzahl zu kopierender Bytes angegeben. Der Wert Null müsste also dazu führen, dass die Funktion überhaupt nichts kopiert. Der Maximalwert 255 kopiert also 255 Bytes, und eine komplette Page von 256 Bytes kann diese Funktion dann eben nicht kopieren.

    Man hätte die Funktion durchaus auch so schreiben können, dass der vierte Parameter den Offset des letzten zu kopierenden Bytes angibt: Dann könnte man mit dem Wert 255 tatsächlich eine komplette Page von 256 Bytes kopieren. Dafür würde beim Wert Null aber auch ein Byte kopiert (eben das erste, das mit dem Offset Null).

    Das ist einfach eine Designentscheidung dessen, der die Funktion geschrieben bzw. das Interface definiert hat. Daher war meine erste Frage, was denn die Dokumentation dazu sagt. Das Problem ist ja nicht auf diese Sprache beschränkt, sondern tritt überall auf, wo mit Speicherblöcken hantiert wird, also z.B. auch im Speichermonitor oder bei Kernal-Save etc.: Definiert man den Block per "Startadresse und Länge"?
    Oder per "Startadresse und Endadresse"?
    Oder per "Startadresse und Endadresse+1"?
    Kernal-Save tut z.B. letzteres, was dazu führt, dass man damit nicht ohne weiteres das Kernal-ROM abspeichern kann - denn das endet ja bei $ffff, und "Endadresse+1" würde dann überlaufen zu $0000.

    Nur der Vollständigkeit halber: Es gäbe noch eine dritte Möglichkeit für die memcpy-Funktion, man könnte auch einfach definieren: "Der Wert 0 steht für 256 Bytes". So macht es z.B. das Zählregister für den Block-Copy/Write-Befehl im VDC des 128ers. Bei entsprechend maschinennaher Programmierung ist das ok, aber in einer Hochsprache wie Pascal wäre so ein Mechanismus fehl am Platz: Denn da will man sich darauf verlassen können, dass ein Ausdruck wie "variable_a - variable_b" immer das richtige Ergebnis ausspuckt, und nicht plötzlich Null zu 256 mutiert.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Bitte melde dich an, um diesen Link zu sehen., danke für die Erklärung. Ich hätte da noch eine Frage, und zwar auf der Internetseite von TRSE wird $3200 durch 64 geteilt und das soll $C8 ergeben. Bitte melde dich an, um diesen Link zu sehen. So ab der Mitte der Seite beim part3.

    Also eine Spritedatei soll 64 Byte lang sein, oder auch länger wenn mehrere Sprites vorhanden sind. Sie wird im Speicher ab der Stelle $3200 abgelegt. Um jetzt die Stelle für den Start des ersten Sprites zu ermitteln wird diese Rechnung aufgemacht.
    $3200/64=$C8
    Das verstehe ich nicht.

    Ist der Start nicht von Anfang ab (plus ein bischen offset, oder so) an? Also bei $3200? Und dann $3200+64Byte+64Byte usw. je nachdem, wie viele Sprites sich in der Datei befinden?

    Bitte melde dich an, um diesen Link zu sehen. schade das TRSE kein "CASE OF" hat ....

  • Die Rechnung stimmt.

    Der 1. Spriteblock fängt hier bei $C8 an. Sprite 2 bei $c9 oder auch bei $cf oder im anderen Speicherbereich der durch 64 Teilbar ist soweit er das System nicht stört.

    Gruss

  • Die Rechnung stimmt.

    Ich kann nicht erkennen, wie das zustande kommt. Das $C8 der Beginn ist, ist unumstritten, es funktioniert ja. Nur wieso? Was ist da noch alles davor? Ist das wichtig, was sich noch davor befindet, oder ist das Platzverschwendung?

    Ich habe auch ein Problem mit den Angaben. Denn im Speicher ist die Adresse $C8 der "Zeiger für die Zeilenlänge bei Eingabe", $C9 der "Zeiger auf den Eingabecursor (Zeile), $CA ist "Zeiger auf Eingabecursor (Spalte). $CF ist "Blinkflag".

    Oder lasst ihr immer die Hälfte weg? Ist vielmehr z.B. $C800 mit $C8 gemeint? Wieso sind dann die Abstände so riesen groß zum Nächsten? Also bei $3200 ist der Erste bei $C800, der Zweite bei $C900, der Dritte bei $CA00, $CB00, $CC00, $CD00, $CE00, $CF00.
    Was passiert da eigentlich?
    Wieso beginnt es dann nicht schon bei $C000? Ist doch ein freier Basic-Ram bereich.

  • Ist der Start nicht von Anfang ab (plus ein bischen offset, oder so) an? Also bei $3200? Und dann $3200+64Byte+64Byte usw. je nachdem, wie viele Sprites sich in der Datei befinden?

    Ja, korrekt. Das wären die Startadressen der Sprites. Die Erklärung auf der verlinkten Seite ist da ein bisschen unglücklich, denn "$c8" ist eben nicht "die Startadresse", sondern "die Startadresse in dem Format, das der VIC für seine Sprite-Zeiger benutzt".
    Da ein Sprite immer nur an einer durch 64 teilbaren Adresse liegen kann, gibt man dem VIC nicht die komplette Adresse an, sondern nur die Nummer des 64-Byte-Blocks. Daher wird $3200 durch 64 geteilt, und der Wert $c8 ist korrekt. Benutzt man diesen Wert dann für den Spritezeiger, wird bei VIC-Zugriffen auf den Speicher dann wieder "64*Wert plus Basisadresse der VIC-Bank" gerechnet, und heraus kommt die Adresse $3200.

    ...dabei ist das Wort "gerechnet" jetzt nicht wörtlich zu nehmen: Die Hauptspeicheradresse ist ja ein 16 Bit-Wert, und die "Rechnung" besteht einfach nur daraus, den Wert aus Bits aus unterschiedlichen Quellen zusammenzusetzen:
    Geschrieben als %bbpp pppp ppoo oooo sind "b" die Bits der VIC-Bank, "p" die Bits des Spritezeigers und "o" die Offset-Bits innerhalb des 64-Byte-Spriteblocks.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

    Einmal editiert, zuletzt von Mac Bacon (29. März 2019 um 13:29)

  • Du kannst auch einpaar Spriteblöcke unter den Screen setzen der ja bei normal bei $400 anfängt.

    Du musst halt schauen, wie weit dein Programmcode geht und dann schauen wo welches Sytem liegt und der Rest vom Speicher des c64 ghört dir.
    Du musst mal sein Demoprogramm anschauen. Es sind da nicht nur Sprites am Werk. Das es dort anfängt hat in seinem Programm schon einen Sinn.

    Es gibt auch noch eine Eigenart beim diesem Rascal.


    Diese kleine Demo hat ca 10kb weil die Sprites bei $3200 liegen.
    Wenn du ein Spriteblockplatz findest so bei $1000 , dann hast du nur ca 4kb.

    Die Eigenart bei Rascal ist , das bei jeder Datei die ab einer bestimmten Addresse eingeladen wird dieses zum Programm gehört
    und nicht ein Platz der außerhalb vom Programm liegt.

    mem: array[8] of byte = (1,2,3,4,5,6,7,8) at $2000;

    Da mem bei $2000 liegt , hat dieses Programm PRG schon ca 6kb.

    Gruss

  • Bitte melde dich an, um diesen Link zu sehen. ja interessante Merkwürdigkeit. Das was mich noch etwas weiter bei meinem Verständnisproblem gebracht hat, kann man Bitte melde dich an, um diesen Link zu sehen. nachlesen ... Ab der Überschrift "Storing and fetching sprites from memory"...

    Also $3200 ist dezimal 12800.
    12800/64=200

    dezimal 200 umgewandelt in eine Hexadezimale Zahl ist C8. Das ergibt den Wert $C8.
    Insofern stimmt die Rechnung...

    Jetzt schreibt man $C8 in $07F8 hinein und der VIC II weis jetzt, wo die Anfangsadresse dieses ersten Sprites im Speicher ist, nämlich bei $3200. Er kann sie jetzt irgendwie so für sich selbst bestimmen, da er selber ja nur seine eigene 16K Sichtweise hat. Wie er das auch immer macht.

  • Wieso können ab $0800 eigentlich keine Spritedaten platziert werden. Mit $20 in den Spritepointer. Dies funktioniert aber mit TRSE nicht. Erst ab $0880 läßt er dies zu, mit $22? Merkwürdigerweise ließ er dieses unterfangen nur ein mal zu. Jetzt bin ich bei $1600 angelangt, mit $58. Nur sieht hier die Sprite nicht mehr so aus, wie sie einmal gemalt wurde.

  • Ich habe jetzt mal "Load...,8" und "Load...8,1" umgesetzt in ASM.

    Bei "Load....,8" ist die Datendatei ohne die beiden Addressbyte und die Ladeaddresse muss im Programm erscheinen.
    Bei "Load....,8,1" ist die Addresse in der Datendatei und nicht im Programm.

    Jetzt kann ich mir selber den Speicherbereich festlegen und laden und es wird kein Speicher Blockiert vom Rascal.
    Das Programm beträgt jetzt ca 40 Byte wenn ich sprite.bin reinlade, weil ich dieses zb nicht mehr mache:
    charset1: incbin("daten/sprite.bin", $2000);

    Natürlich stehe ich wie du auch am Anfang mit meinen 70 Jahren.
    Ich habe den Namen und die Länge der Datei erstmal mit Poke reingebracht um zu sehen ob es funktioniert.
    Die Buchstaben/Zahlen müssen zum Laden/Speichern als Wert den ASCII-Zeichen -Code haben, habe 2 Stunden gebraucht, weil
    ich die Character vom C64 genommen habe : C64 : "A" = 1 , ASCII: "A",= 65.

    Aber es mach mir große Freude das zu machen und man sieht wie schnell man den RAScal andere Befehle beibringen kann.
    Jetzt muss ich suchen wie ich meine Poke-daten eleganter übergeben kann.


    Hier ist die Adresse in den Daten mit drin


    Hier habe ich die Adresse im Programm , nach $0600 werden die Daten geladen.


    Hier ist es gut beschrieben :
    Bitte melde dich an, um diesen Link zu sehen.

    Gruss