Wie bekommen man eigenlich die Größe eines Programms raus? z.B ein Basic Programm, wenn es im Speicher liegt?
PRINT38911-FRE(.)-65536
Oder so.
Stimmt das überhaupt? Mein Gehirn ist noch immer nicht entschnupft...
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
letzter Beitrag von Haubitze am
Wie bekommen man eigenlich die Größe eines Programms raus? z.B ein Basic Programm, wenn es im Speicher liegt?
PRINT38911-FRE(.)-65536
Oder so.
Stimmt das überhaupt? Mein Gehirn ist noch immer nicht entschnupft...
Im VICE kann man das mit dem Monitor eh halbwegs sehen. Aber das mit FRE geht natürlich auch.
Interessant wie die BASIC Tokens aufgelöst werden.
So dass man ein neues Sprite in den Block 13 kopiert und das Programm einfach nochmal laufen lässt.
Wie sieht es mit selbstmodifizierendem Code aus?
Kann sich mein Programm während des Ablaufes ändern/zerlegen, so dass ich es vor einem zweiten Start nochmal laden muss?
"Programm einfach nochmal laufen lassen." könnte ich interpretieren als "nochmal laden und dann einfach nochmal laufen lassen."
Gruß,
Thomas
Oob, vielleicht ist es so besser verständlich:
Die linken 21 Bits von ZEILE 1 (also 8 Bits vom ersten und zweiten Byte und 5 Bits vom dritten Byte):
10101010 11001100 11111xxx
Werden zu SPALTE 1 (also jeweils Bit#7 des ersten Bytes der Zeile):
1
1
1
1
1
0
0
1
1
0
0
1
1
0
1
0
1
0
1
0
1
Die restliche 3 Bits entfallen. Im Ziel-Sprite müssen die Bits #0-2 der dritten Byte-Spalte mit 0 befüllt werden.
Oob, vielleicht ist es so besser verständlich:
Nö, im ersten Moment nicht. Erst mit Hilfe vom 64er Wiki bin ich dahinter gekommen.
Das lag daran, das ich den Aufbau eines Sprites im 64er nicht gedacht hatte.
ZitatKann sich mein Programm während des Ablaufes ändern/zerlegen, so dass ich es vor einem zweiten Start nochmal laden muss?
Das Programm darf sich zerlegen. Ich werde eine Kopie im Bereich ab $c000 Zum Testen ablegen.
Wenn das Programm ab dort nicht mehr hinpasst, hat man wahrscheinlich eh keine Siegchancen mehr
Noch eine Frage:
das Sprite in Block 13 muss ja erhalten bleiben. Gilt das auch für die Laufzeit des Programms? Reicht es also wenn mach Programmende das Sprite wieder so wie vorher ist oder darf auf Block 13 nur lesend zugegriffen werden ?
Gruß, Gerd
PRINT38911-FRE(.)-65536
Oder so.
Stimmt das überhaupt? Mein Gehirn ist noch immer nicht entschnupft...
Gilt allerdings nur solange der FRE()-Wert < 0 ist. Ab einer Programmgröße von rund 6144 Bytes stimmen dann die FRE()-Werte und müssten nicht mehr korrigiert werden. Abgesehen davon werden hier immer eventuell noch angelegte Variablen und Arrays mitgezählt.
Korrekt wäre etwa
also eine Funktion f(x). Auch wenn recht elegant, so hat dies leider die Nebenwirkung, dass hier implizit die Garbage-Collection 2 mal aufgerufen wird und es speziell bei vielen vorhandenen Strings dann auch (unangenehm spürbar) doppelt so lange dauert.
Aber nur die BASIC-Programmlänge (Textlänge) geht auch ohne FRE():
Also BASIC-Text-Ende+1 (=Variablenanfang) minus BASIC-Text-Beginn (siehe Zeropage Liefert bei einem leeren Programm 2 bzw. einen um 2 erhöhten Wert für ergänzten BASIC-Code. Ob man nun die 2 mitrechnet oder herausrechnet ist egal, aber im Vergleich sollte man sich auf eine Variante einigen.
Man kann auch vorher den Speicher mit irgendwas <>0 füllen, Programm laden und dann nach 00,00,00 suchen.
Zitatdas Sprite in Block 13 muss ja erhalten bleiben. Gilt das auch für die Laufzeit des Programms? Reicht es also wenn mach Programmende das Sprite wieder so wie vorher ist oder darf auf Block 13 nur lesend zugegriffen werden ?
Wenn das Sprite wieder danach restauriert wird, ist das auch in Ordnung.
Spriteblock 14 soll unbestimmt sein. So dass man ein neues Sprite in den Block 13 kopiert und das Programm einfach nochmal laufen lässt.
Muss dann wohl auch noch ins Regelwerk rein ...
- Daten im Spriteblock 14 sind vor dem Anstarten des Programmes als zufällig zu betrachten.
Ergänzt im OP.
Uiuiui, ist schon haarsträubend kompliziert, das erstmal überhaupt ans Laufen zu kriegen.
Danach quetsche ich nochmal drei Bytes raus, dann kommt Roland und macht's in 26.5 Bytes und BASIC
Wenn das Sprite wieder danach restauriert wird, ist das auch in Ordnung.
Hmm, vielleicht innerhalb des Programms mit einer kleinen Routine, die das Ziel-Sprite 90 Grad im Uhrzeigersinn dreht...
Gruß,
Thomas
dann kommt Roland und macht's in 26.5 Bytes und BASIC
Egal, dabei ist alles.
Hab' jetzt schon mit Vorgeplänkel 32 Bytes verbraten und da rotiert noch gar nix. Muss ich jetzt aufhören ?
Rein aus dem Bauch raus, schätze ich jetzt schon mal das beste Ergebnis knapp unter 100 Bytes. Und ich werde wohl 169 brauchen (mal schauen...).
Ich hab' auch noch null Idee .
Und?
Wer hat schon fertig?
Klingt simpel, aber ist doch irre...
Mein Gehirn macht da heute nicht mehr mit. Ich mache morgen weiter.....
Aber einen Ansatz habe ich mir nun notiert.
Testcode für Sprites habe ich auch schon.
peiselulli,
schreib bitte noch hinzu, dass es nur um monocolor Sprites geht.
peiselulli,
schreib bitte noch hinzu, dass es nur um monocolor Sprites geht.
Steht ja:
Im Spriteblock 13 (also ab Adresse $0340, dezimal 832) liegt ein
Hires-Sprite, dass in den Spritelblock 14 (also ab Adresse $0380,
dezimal 896) gedreht kopiert werden soll.
Mir ist noch eine Sache eingefallen, die bei den Regeln noch ergänzt werden sollte:
Ich nehme an, daß illegale Assembler-Opcodes nicht erlaubt sind. (Soll ja bestimmt auf jedem C64 laufen.)
Wie soll man Dir ( peiselulli) das fertige Programm eigentlich am Besten zuschicken (E-Mail oder lieber PN oder als Bit-Code per Rauch-Zeichen )
Danach quetsche ich nochmal drei Bytes raus, dann kommt Roland und macht's in 26.5 Bytes und BASIC
Ich schätze, ich bin noch nicht lange genug hier im Forum (wieder) angemeldet, um das zu verstehen.
Wer hat schon fertig?
Klingt simpel, aber ist doch irre...
Ja, ich hatt's mir erst auch einfacher vorgestellt...
Ist auf jeden Fall 'ne interessante Aufgabe.
Naja, jetzt hab ich's aber fast.
Mir ist noch eine Sache eingefallen, die bei den Regeln noch ergänzt werden sollte:
Ich nehme an, daß illegale Assembler-Opcodes nicht erlaubt sind. (Soll ja bestimmt auf jedem C64 laufen.)
Ich gehe ganz stark davon aus, dass diese erlaubt und erwuenscht sind. Tatsaechlich koennten sie am Ende den Ausschlag geben.
Inzwischen ist sehr gut bekannt welche opcodes verwendbar sind und welche nicht (und dann auch auf allen C64s laufen).