Posts by BIF

Mit Tricks kann das BasicV2 ja sogar Unterprogramme in Funktionen ausführen.

:sysfng(10): rem goto10
:sysfnp(10.20):rem setcursor10.20

Das wäre dann natürlich für den Anfänger 100% unverständlich.

Schönen Gruß.

Ja, es gibt natürlich Syntax-Varianten, die selten benutzt werden und daher auch vielen unbekannt sind.

z.B. :cont: im Programmmodus

oder loading$,8
oder saver$,8

oder forum=0 torum

oder leter=1

Schönen Gruß.

Z10: 2x2 ZEICHENSATZ-GENERATOR:

Hier kommt der 2x2-Zeichensatz-Generator der 2x2 Schriftzeichen aus dem Orginal-Zeichensatz erzeugt.

Die Grundlage bildet dabei wieder ROM-RAM, dabei ist noch ein kleines Sting-Ausgabe-Demo.

Schönen Gruß.

Token und Basic-Befehle:_

Hier habe ich mal einen kleinen Zweizeiler geschrieben, der passend zum Thema, die Token und die Basic-Befehle auf den Schirm bringt.

Schönen Gruß.

Die Realisierung mit dem BRK(0) -Befehl.

Man hätte dann im Basic-Quelltext:
0,Basic-Token,Basic-Parameter
Im Listing:
:print"hallo"

Damit hätte man dann die vollständige Kommpatibilität von Basic und Maschinencode.

Schönen Gruß.

Wäre es auch auf dem jetzigen C64-Prozessor möglich ein Maschinensprache-kompatibles Basic zu programmieren ?
Meiner Meinung nach ja.

Und zwar mit dem Break-Befehl/Vektor.

Eine Basic-Zeile beginnt ja bekanntlich mit einem Null-Byte.
Und der Null-Code in Maschinensprache ist bekanntlich der BRK-Befehl.
Das heißt natürlich, daß man mit dem 0-BRK-Befehl den Basic-Programmzeiger mit dem Maschiensprache-ProgrammCounter synchronisieren kann.
Und über den Break-Vektor dann zur Basic-Interpreterschleife verzweigt.
So könnte man dann natürlich auch Basic-Zeilen/Befehle direkt in den Assemblercode einfügen.

Schönen Gruß.

Eine Vergrößerung des ROM-Codes ist für viele Optimierungen nicht notwendig.

Sieh z.B. RAM-Basic/1
Version 2 hat natürlich noch mehr Optimierungen wie z.B.
Kettenpoke, String-Adresse, Load.Adresse, usw. ohne Rom-Vergrößerung.

Die Verbessung des ROM-Codes ist aber natürlich ein Zeitfrage und eine Frage die richtigen Ideen umzusetzen.

Schönen Gruß.

Rein theretisch könnte man statt 5 Bytes pro Zeile auch auf 4 Bytes pro Zeile umorganisieren, das spart dann sogar das Unterprogramm zur Zeilenverlinkung.

Und theoretisch sind auch 3 Byte pro Zeilenanfang denkbar.
5B : 0,L1,L2,Z1,Z2
4B : 0,ZL,Z1,Z2 (ZL=Zeilenlänge)
3B : ZL,Z1,Z2

Und auch das 0Byte am Zeilenanfang, könnte theoretisch ein Token für Zeilenanfang sein.

Außerdem könnte man das Basic theoretisch gleich nach Maschinencode kompilieren.

Der Doppelpunkt vor einem Befehl könnte einem SYS entsprechen.
:Befehl wäre dann sys-Token und der Sys Befehl ruft dann die Basic-Befehle über eine Tabelle auf.

Da wären wir wieder beim Thema, dem Doppelpunkt am Anfang gehört meiner Meinung nach die Zukunft und es gibt keinen Unterschied mehr zwischen Basic und Assembler Quelltext.

Das heißt Basic-Programme können direkt in Assembler-Programme und Assembler-Programme direkt in Basic-Programme eingefügt werden.

Schönen Gruß.

Schnelle Basic-Versionen ?
Grundsätzlich sind alle Basic-Versionen, die zusätzliche Befehle in Maschinensprache zur Verfügung stellen diesbezüglich schneller.

Die Frage müßte wohl spezifischer gestellt werden.
Schneller beim Laden/Speichern, Grafik, Zeichensatz, Cursorsetzen, Rechnen, usw.

Auch wenn man z.B. Fehler des Basics korrigiert, ist das Basic atomatisch schneller, da man sich dann die Fehlerbehandlung, die meist einigen Code erfordert, sparen kann.

Schönen Gruß.

ROM-RAM-TRICK
TASTENBELEGUNG ÄNDERN:

Die Felder für die Tastendekodierung befinden sich natürlich im ROM-Code und haben eine Länge von 65 Byte:

Tastenfeld-Adressen: 60281,60283,60285,60287

Norm-Tasten : 60289

Shift-Tasten : 60354

CBM-Taste : 60419

CTRL-Tasten : 60536

peek(203): Tastencode der gedrückten Taste

peek(654): Shift/CBM/CTRL-Taste

peek(655)ßpeek(656)*256: Adresse der Tastendekodier-Routine

z.B. poke655,118: Dekodierung aus.

Mit den oben angeführten Adressen kann die Tastenbelegung im RAM direkt geändert werden oder man verbiegt die Vektoren für die Tastenfelder ab 60281.
Man kann aber auch mit dem Vektor(655/656) eine anderes Tastendecodierprogramm einbinden.

Schönen Gruß.

Die Felder für die Tastendekodierung befinden sich natürlich im ROM-Code und haben eine Länge von 65 Byte:

Tastenfeld-Adressen: 60281,60283,60285,60287
Norm-Tasten : 60289
Shift-Tasten : 60354
CBM-Taste : 60419
CTRL-Tasten : 60536

peek(203): Tastencode der gedrückten Taste
peek(654): Shift/CBM/CTRL-Taste

peek(655)ßpeek(656)*256: Adresse der Tastendekodier-Routine

z.B. poke655,118: Dekodierung aus.

Schönen Gruß.

Ja, die Tastatur-Auswertung ist natürlich ein weites Feld für sich.
Ich glaube, es gibt sogar einen Poke, wie man nur das Tasten-Feld-1 benutzt.

Man kann auch die Tasten-Felder des ROM´s in den Kassentenpuffer kopieren und dann dort auslesen.

z.B. mit :if peek(653)=4then:c=peek(a+peek(203)):c$=chr$(c)

Schönen Gruß.

Ja, das Füllen mit Nullen, ist für die Kopier-Routine.
Damit wird der Startzeiger auf 0=65536 gesetzt.
Ansonsten kann der Nuzter die Konfig mit poke :1,48: bis :poke1,53:poke1,54 oder poke1,55: frei wählen.
Bei poke1,53 kann man auch das Kernal-ROM ändern.
Mit poke1,54 werden nur die Änderungen im BASIC-ROM benutzt/angeschaltet.
Daher kann man die obernen 16 kB dann auch für Grafik oder sonstiges nutzen.
Bei poke1,53 kann man nur die ersten 3kB ab 49152 frei nutzen. z.B. für einen Zeichensatz oder Sprites.

Schönen Gruß.

Kosmas:
Danke, ich denke mal, daß mir damit eine kompakte Lösungs des Punktsetzens gelungen ist, die zudem auch noch relativ leicht verständlich sein sollte.
Damit ist es z.B. für die 10-Zeiler-Programmierung optimal, da man dann 7 Zeilen für die Grafik-Darstellung zur Verfügung hat.

Schönen Gruß.

Also, also, also:
-Das ROM kannst du bei jedem C64, EMU oder THEC64 auslesen.
mit :printpeek(40960):
-Gibt es so etwas wie Alt-Gr auf dem C64 ?
Natürlich ja: CBM=AltGR, STRG=CTRL, Hochstelltaste=SHIFT
Beim C64 ist auch eine Kombination von Steuertasten möglich.
Und damit könnte man weitere Tastaturblöcke einfügen.
Normal=0, Shift= 1, CBM=2, CTRL=4: z.B. Shift+CBM=3
Damit kann man also theoretisch 8 Tastaturblöcke programmieren.

Schönen Gruß.

Ja, am Anfang war der Doppelpunkt.
Eine These, die von Verschwörungstheoretikern oft bestritten wird.

Ich wollte nur mal die Frage stellen, ob meine Prg´s tatsächlich mehr Doppelpunkte enthalten, als andere Programme.
Das könnte man ja mal zählen.
Oder ?????

Einen Allgorithmus schreiben, der die Doppelpunkte zählt.

Schönen Gruß.

Also hier noch mal das Prg als 4-Zeiler.
Damit hätte man dann wohl die kürzeste Abtipp-Zeit, die kürzeste Speicherzeit und die kürzeste Ladezeit. Und die Arbeits-Geschwindigkeit ist auch nicht schlecht.
Dazu kommt natürlich noch die gute Lesbarkeit, wegen der Doppelpunkte.

0 :rem--80x50 pixel-demo

1 :dima(255):print"[clr]80 x 50:":fori=.to15:readb:a(b)=i:a(i)=b:next

2 :data32,126,124,226,123,97,255,236,108,127,225,251,98,252,254,160

3 :y=11:forx=.to79:gosub4:next::x=21:fory=.to49:gosub4:next:end

4 :i=1024+x/2+20*(yand62):pokei,a(a(peek(i))or(1+(xand1))*(1+3*(yand1))):return

Schönen Gruß.

Hallo, ich denke mal, daß mein Prg trotzt Doppelpunkten das kürzeste ist.

Oder täusche ich mich?

Also von Doppelbelastung kann wohl keine Rede sein.

Schönen Gruß.

detlef: Klingt schon sehr gut.

Schönen Gruß.

80 x 50 Pixel:

Hier hab ich noch mal eine gekürzte Poke-Version.
Man kann das Problem also in circa 4-5 Zeilen und mit einem Feld lösen.

Schönen Gruß.