letzter Beitrag von sparhawk am
Und um reine Screencodes ohne Attribute zu schreiben, kannst Du sie einfach direkt hintereinander in Register 31 schreiben
Gab's da nicht eine Begrenzung (abhängig von anderen Registern) von ca. 8x direkt hintereinander bevor er sich doch verschluckt?
Das klingt nach dem, was passiert, wenn man sich auch noch die Abfrage des Ready-Flags spart - so weit würde ich dann aber doch nicht gehen.
die Abfrage des Ready-Flags spart
Ja, genau das meinte ich. Die kann man sich mindestens 8x sparen (mit Tricks bezgl. des RAM-Refreshs wohl auch öfter). Dachte das wäre damit gemeint mit: "mehrfach hintereinander beschreiben."
Das Ready-Flag braucht man eigentlich nur bei Blockoperationen und wenn man mehr als 8x fix hintereinander schreibt (und ggf. um es SuperCPU kompatibel zu halten, da die wohl manchmal zu schnell ist 
).
C128toSCART von Tilo Dettling. Letzerer ist jetzt bei mir in Betrieb und hat den BIT-C128 abgelöst.
Danke! Den kannte ich noch gar nicht. Sehr elegant, dass der seine Betriebsspannung vom DIN8-Port bezieht. Gekauft!
Jetzt fehlt nur noch ein Scart-to-HDMI-Converter, der sowohl RGB als auch SVideo auf Scart abgreifen kann.
Der xRGB Mini kann das nämlich leider nicht.
An diversen Stellen sind Fehler und das merkte man auch, z.B. wenn die angegebenen Beispiele mal wieder nicht funktionierten.
Das im C128 intern war nur Traditionspflege wegen wechselnder Fehler im 64 intern über die diversen Auflagen hinweg.
Schau mal http://www.willcox.de/intern.htm bzw. im Wiki https://www.c64-wiki.de/wiki/D…ore_64_Intern_Buch#Fehler
Beispiel: Am C128 kann man nicht mehr einfach mit Pokes die Sprites so rumschieben, weil die vom Kernel kontrolliert werden. Man muss also die IRQ Routine deaktivieren bevor das funktioniert. Bei Data Becker steht da nichtmal der kleinste Hinweis dazu.
Auf Seite 33 und nochmal ausführlicher auf Seite 792f.
Zitat
Auf Seite 33 und nochmal ausführlicher auf Seite 792f.
Interessant. Ja, wenn ich unter Sprites nachsehe, dann würde ich halt einen Hinweis dort erwarten. Da komme ich nicht auf die Idee unter der Beschreibung des VIC oder BASIC was zu finden.
Interessant finde ich jetzt allerdings, wie viele Stellen gibts da beim 128er um das auszuschalten?
Bei Data Becker steht 216/$d8 bei M&T steht $12fd (was auch funktioniert). 
Beispiel: Am C128 kann man nicht mehr einfach mit Pokes die Sprites so rumschieben, weil die vom Kernel kontrolliert werden. Man muss also die IRQ Routine deaktivieren bevor das funktioniert.
Die Kritik an der Doku teile ich, aber ist das ein echtes Praxisbeispiel?
Meinst Du mit "einfach mit Pokes" jetzt wirklich von BASIC aus? Da nimmt man MOVSPR und gut is, das hat drei Vorteile:
a) es ist lesbar
b) man braucht sich nicht um das MSB-Gefuddel zu kümmern
c) x-, y-, und x-msb-Register werden gemeinsam geändert: MOVSPR sperrt den Interrupt, aktualisiert die Pseudoregister bei $11d6 und gibt dann den Interrupt wieder frei. Der nächste Interrupt kopiert die Pseudoregister in den echten VIC. Denn so nervig diese Pseudoregister auch sein können, sie haben einen echten Vorteil: Der Interrupt, der ihre Werte in den echten VIC kopiert, ist ein Rasterinterrupt und findet immer am unteren Bildschirmrand statt, d.h. die Register werden niemals während der Sprite-Darstellung aktualisiert. Ohne diesen Mechanismus kann es passieren, dass zwischen den Updates der drei Register die Sprite-Darstellung beginnt, und dann ist das Sprite einen Frame lang an einer komplett falschen Position sichtbar.
Will man, dass der gleiche Basic-V2-Code auf C64 und C128 läuft, kann man einfach eine Variable als Basisadresse der Sprite-Register nutzen, auf dem 128er wäre es dann $11d6 statt $d000.
Die Kritik an der Doku teile ich, aber ist das ein echtes Praxisbeispiel?
Ja. Denn POKEs sind ja 1:1 in Maschinensprache zu übersetzen.
ZitatMeinst Du mit "einfach mit Pokes" jetzt wirklich von BASIC aus? Da nimmt man MOVSPR und gut is, das hat drei Vorteile:
Ich schreibe Assembler und da will ich keine BASIC Routinen aufrufen, sonst könnte ich es auch in BASIC schreiben. Das Beispiel war halt nur weil ich den Eindruck hatte dass Data Becker zu wenig Infos hatte. OK. Hatten sie nicht, nur blöd verteilt.
Schau mal http://www.willcox.de/intern.htm bzw. im Wiki https://www.c64-wiki.de/wiki/D…ore_64_Intern_Buch#Fehler
Ich bin da ganz bei Willcox: Data Becker ist Schrott!
Da ich beschlossen hatte mehr auf dem C128 zu machen (statt auf dem C64) habe ich jetzt unter https://github.com/skeetor/c64-src/tree/master/C128 zwei Projekte eingestellt. Das eine ist einfach ein Hello World welches auf dem 40 und 80 Zeichen Schirm Text ausgibt.
Das zweite Projekt ist ein KeyScanner. Damit wird die Matrix der Tastaturleitungen angezeigt und man kann Tasten drücken (auch mehrere gleichzeitig) und die werden dann angezeigt. Die Tasten werden direkt über die CIA Ports abgefragt und brauchen keine ROM Routinen. Das schöne daran ist, dass das Programm auch auf dem C64 ohne Änderung läuft.
Ich habe sogar noch einen kleinen Hack eingebaut, so dass man das fertige Binary sowohl auf dem C128 als auch auf dem C64 starten kann, wenn man es mit LOAD"KEYSCAN",8 lädt (nicht mit ,8,1).
Das Tool ist sogar recht praktisch, weil ich jetzt unterm Emulator alle Tasten drücken kann um herauszufinden wo was hingemappt ist. 
Man kann es auch verwenden um zu prüfen ob eine Tastatur funktioniert falls das wer brauchen kann, vermutlich gibts da aber eh schon tausend Tools. Falls es jemand haben will und es nicht selbst assemblieren kann habe ich das keyscan.D64 angehängt.
So! Hat knapp 30 Jahre gedauert bis ich es endlich geschafft habe was ich eigentlich früher schon machen wollte. Endlich mal ein komplettes Programm und das auch noch native auf dem C128.
Durch den Hack damit es auch auf dem C64 startbar wird, musste ich einen zusätzlichen 4KB Block einbauen. Das eigentlich Programm ist wesentlich kleiner.
Super! Da werde ich bei Gelegenheit mal vorbeischauen.
Für Tastendinge gibt es in verschiedenen Varianten (c64,c128, c16...) auch Anykey - neues Tool zum Überprüfen des Keyboards - da liegt auch der Sourcecode der Entwickler bei github.
Super! Da werde ich bei Gelegenheit mal vorbeischauen.
ZitatFür Tastendinge gibt es in verschiedenen Varianten (c64,c128, c16...) auch Anykey - neues Tool zum Überprüfen des Keyboards - da liegt auch der Sourcecode der Entwickler bei github.
Habe ich schon vermutet, aber mir gings auch eher drum das mal zu verstehen.
Also nachdem ich mich ja jetzt seit knapp zwei Wochen ausführlicher mit dem C128 beschäftige muss ich sagen, der gefällt mir immer besser. Als ich den damals bekommen habe, habe ich mich (nur sehr) kurz mit dem Bnking beschäftigt, nichts kapiert und dann nichts mehr drauf gemacht.
Als ich jetzt angefangen habe, habe ich mir die Speicherkonfiguration angesehen und gedacht, wie wenig man da eigentlich zur Verfügung hat, wenn man nicht gleich wieder mit der MMU loslegen will. Nachdem ich aber bereits an diese knappe Grenze gestossen bin, habe ich mir heute zum ersten Mal ernsthaft angesehen wie ich vollen Zugriff aufs RAM bekomme und festgestellt: das ist jagar nicht so kompliziert wie anfangs gedacht. Jetzt habe ich mir einen Konfiguration eingestellt wo ich auf den IO Bereich Zugriff habe, das KERNAL damit ich Laden und Speicher kann und BASIC habe ich weggeschalten. Damit habe ich erstmal wieder mehr als genug Speicher zur Verfügung.
Und wenn ich mehr brauche, weiss ich jetzt auch, wie ich problemlos auf die zweite Bank zugreifen kann.
Je mehr ich mich da einlese, desto mehr finde ich dass der eigentlich recht gut durchdacht ist und auch in ASM relativ einfach zu programmieren ist. Und durch die grosse Nähe zum C64 kann ich das Meiste, das ich noch weiss, auch sofort weiter nutzen.
finde ich dass der eigentlich recht gut durchdacht ist
Bil Herd würde das freuen zu lesen.
Sein Buch "Back into the Storm" liegt hier noch ungelesen rum, muss ich jetzt endlich mal anfangen.
HIROM an, MIDROM und LOROM aus ist in der Tat eine sehr nützliche Speicherkonfiguration für Maschinensprachprogramme, und ein C64-Programmierer wird sich in dieser Konfiguration sofort zu Hause fühlen, aber weniger wahrscheinlich an die Grenzen der Maschine stoßen, da der zusätzliche Speicher immer noch relativ leicht zugänglich ist.
HIROM an, MIDROM und LOROM aus ist in der Tat eine sehr nützliche Speicherkonfiguration für Maschinensprachprogramme, und ein C64-Programmierer wird sich in dieser Konfiguration sofort zu Hause fühlen, aber weniger wahrscheinlich an die Grenzen der Maschine stoßen, da der zusätzliche Speicher immer noch relativ leicht zugänglich ist.
Richtig! Wenn man das geschnallt hat (so wie ich jetzt) dann fühlt man sich wie zu Hause. Mein LIeblingsspeicherbereich ist imer $C000 gewesen. Gut, der fällt weg wenn man das KERNEL ROM haben will, aber dafür gibts ja dann die zweite Bank. Das Kernel brauche ich eigentlich nur wegen der Floppy. Das ist mir dann zu kompliziert, da auch noch meinen eigenen Code zu schreiben. Die Tastaturabfrage ist relativ einfach und kurz und bietet mir mehr Möglichkeiten, da brauche ich das ROM jetzt nicht mehr dafür.
Es gibt noch eine. Gebt in Monitor ein:
m f63f5 f640b
