Posts by Mac Bacon

    Wenn ich als Wert für parameter strtext nur ein char ("a") übergeben, dann gibt es keine Fehlermeldung. Ab zwei Zeichen kommt dann der Fehler...

    Bei ACME war das früher auch so: Man konnte zwar bei vielen Pseudo Opcodes Strings verwenden, aber man konnte einem Symbol keinen String zuweisen. Ein String, der nur aus einem einzigen Zeichen besteht, wurde intern in seinen Zeichencode umgewandelt und wurde dann als Zahl weiterverarbeitet, deshalb geht das. Bei längeren Strings funktioniert das natürlich nicht.

    Erst seit Version 0.97 vom vorigen Jahr kennt ACME String-Symbole, und seitdem kann man Strings auch an Makros übergeben.

    Da Endurion sich bei seinem Assembler ursprünglich an ACME orientiert hat, ist hier wohl derzeit noch die gleiche Einschränkung vorhanden.

    Erklärst du es vielleicht auch noch für die langsameren unter uns? Ich kann mit der Andeutung jedenfalls nicht anfangen

    Beitrag #74: Auf dem PC braucht "Hello World" 100 KByte.

    Beitrag #75: Unsinn, nur 1,5 KByte.

    Beitrag #76: Aber das ist das 70fache von der C64-Version!

    Beitrag #77: Und trotzdem nur ein 70stel von 100 KByte.

    Das heißt, falls es nach Erläuterung immer noch so lustig ist, wie es im ersten Moment schien...

    Du bist noch nicht so lang im Forum, das kommt noch... :whistling:

    Beim C64 ist print"Hello World" etwa 20 Bytes und beim C-Compiller wohl 1488 Bytes.
    Das wäre in dem Falle dann etwa 70 mal größer

    Lustig: Mit Deiner Vermutung aus Beitrag #74 liegst Du noch mal um ziemlich genau den gleichen Faktor daneben. Aber dafür gibt es bestimmt eine ganz tolle Erklärung.

    ich habe eine Funktion geschrieben die mir die Keyboardmatrix am C128 abfragt, und für jede Zeile die gedrückte Taste ermittelt. [...]


    Die Tastatur ist ja in einer 8x8 Matrix aufgebaut.

    Das gilt für den C64. Der 128er hat mehr Tasten und daher hat seine Matrix drei zusätzliche Spalten. Adressiert werden diese drei Spalten über die drei unteren Bits von $d02f. Wenn man eines der dortigen Bits löscht, sollte in Port A von CIA1 natürlich $ff stehen, und anders herum: Wenn man den C64-kompatiblen Teil der Tastatur abfragt, sollten die unteren drei Bits von $d02f gesetzt sein.

    Ich habe leider auch keinen echten C128

    Das ist für diese Art von Test natürlich suboptimal. Du weißt aber schon, dass der C128 vier separate Cursortasten zusätzlich zu den beiden des C64 hat? Ich wüsste jetzt z.B. nicht auswendig, welche(n) Tastendruck/drücke x128 emuliert, wenn man am PC Cursor-Up drückt.

    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.

    warum möchtest du das überhaupt machen so? Was soll für ein Sinn dahinterstecken? :gruebel

    Ich wollte nur wissen, ob es vom Protokoll her möglich ist. Ob man mit dem erlangten Wissen je etwas wird anfangen können, steht auf einem anderen Blatt.

    Listen+Talk-Status werden beide zurückgesetzt wenn ATN aktiv wird, siehe EBFF und E85B im 1541-ROM.

    Vielen Dank für den Hinweis.

    Die zweite genannte Stelle hatte ich mir gestern tatsächlich im ROM-Listing angesehen, bevor ich das Programm geschrieben habe - und dennoch nicht gemerkt, dass es so nicht gehen kann. 8|

    ...das wird wohl Verkalkung sein...


    Für andere Interessierte noch der Vollständigkeit halber: Es wird auch nichts nützen, TALK und LISTEN gemeinsam in einer einzigen ATN-Sequenz zu senden, denn wenn das erste Byte ein fremdes Laufwerk adressiert, ignoriert das Laufwerk alle Folgebytes. Es geht also wohl wirklich nur mit Extracode im Laufwerk.

    ...ich behaupte nicht, dass es geht - mir fällt nur kein Grund ein, warum es nicht gehen sollte. Es ist ja relativ schnell getestet (eine Datei auf Device 8 zum Lesen öffnen, eine Datei auf Device 9 zum Schreiben öffnen, und dann ein TALK an 8 und ein LISTEN an 9 senden), aber wenn Du nen Grund nennen kannst, spare ich mir die Zeit.

    [...]


    Ob das bei einzelnen Dateien funktioniert, darüber habe ich mir noch keine Gedanken gemacht. Könnte funktionieren.

    Der "schnelle Test" war ein Fehlschlag. Falls jemand weiter herumbasteln möchte, ich hab es so probiert:

    Zeile 100 war dafür gedacht, dass man das Ende der Übertragung "sehen" kann. Aber es passiert nichts; nach dem Ende von ATN scheinen Listener und Talker keine Kommunikation zu starten. Hat noch jemand ne Idee?

    Übrigens konnte der ursprüngliche IEEE-Bus genau das. Man konnte einen Drucker als Listener adressieren und ein Messgerät als Talker und dann sendete das Messgerät an den Drucker ohne dass der Rechner beteiligt war. Aber das klappt natürlich nicht mit einer Commodore-Floppy.

    Bist Du sicher, dass das nicht geht?

    Nicht mit der Standard Talker- und Listener-Funktionalität.

    Warum nicht?


    ...ich behaupte nicht, dass es geht - mir fällt nur kein Grund ein, warum es nicht gehen sollte. Es ist ja relativ schnell getestet (eine Datei auf Device 8 zum Lesen öffnen, eine Datei auf Device 9 zum Schreiben öffnen, und dann ein TALK an 8 und ein LISTEN an 9 senden), aber wenn Du nen Grund nennen kannst, spare ich mir die Zeit.

    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.

    BTW: Als ich nur ein Zeichen an die erste Stelle geschrieben habe, ist es zweimal erschienen, was mich etwas irritiert hat.

    Das wird daran gelegen haben, dass Du eine 1 ins BlockWrite-Register geschrieben hast, wodurch ein weiterer Schreibzugriff forciert wurde.

    Ich habe jetzt gestern Abend noch etwas rumprobiert und ein HelloWorld geschrieben das einen Text auf den 40 und 80 Zeichen Bildschirm ausgibt. Den VDC zu programmieren ist schon etwas mühselig. :)

    Kommt darauf an, wieviel unnötige Arbeit man sich macht. :D

    Register 12/13 brauchst Du nicht zu nullen, das ist eh der vom Kernal gesetzte Standardwert.

    Register 30 kannst Du auch komplett ignorieren, das braucht man nur für BlockCopy/BlockWrite.

    Und um reine Screencodes ohne Attribute zu schreiben, kannst Du sie einfach direkt hintereinander in Register 31 schreiben, ohne jedes Mal die Update-Adresse einzustellen - die wird nämlich intern automatisch bei jedem Lesen oder Schreiben inkrementiert.

    Man kann sogar darauf verzichten, vor jedem Zeichen Register 31 auszuwählen, einmal reicht.

    Dummerweise enthält JMPFAR diesen blöden "JSR $ff6b"-Aufruf. Da JSRFAR auf JMPFAR zurückgreift, ist es ebenfalls von diesem Problem betroffen.

    Und das Problem war jetzt was nochmal genau?

    Dass dmantione gesagt hat, man könne mit diesen Routinen aus einer Konfiguration ohne Kernal ins Kernal springen. Genau das geht aber eben nicht, da die Routine erst die Kernalfunktion $ff6b aufruft, um die Bank-Nummer in den Wert für das Konfigurationsregister zu konvertieren. Man kann JSRFAR und JMPFAR also nur aufrufen, wenn der Kernal eingeblendet ist.


    ...natürlich könnte man in der Konfiguration ohne Kernal eine eigene Fake-Routine bei $ff6b ablegen, aber wenn man das tut, könnte man auch einfach eigene Alternativen zu JSRFAR/JMPFAR bauen...

    Das Schöne daran ist, dass diese Routinen im shared RAM in der Page $0200 zur Verfügung stehen, so dass man von jeder Bank aus auf jede andere Bank zugreifen kannst. Der Aufruf des KERNAL aus RAM, wo er nicht sichtbar ist, ist eine der Hauptanwendungen dieser Routinen!

    Dummerweise enthält JMPFAR diesen blöden "JSR $ff6b"-Aufruf. Da JSRFAR auf JMPFAR zurückgreift, ist es ebenfalls von diesem Problem betroffen.

    Bei $D000 liegt RAM, wenn man ein Assembler-Programm startet.

    Ähhh... nein. Genau wie beim C64 ist der Default "ROMs und I/O aktiv". Beim 128er heißt diese Konfiguration "BANK 15". Wenn man allerdings "BANK 0:SYS wasauchimmer" eingibt, oder im eingebauten Monitor eine Adresse ohne führendes F (für Bank 15) anspringt, ja, dann ist "BANK 0" aktiv und dann sind die I/O-Chips ausgeschaltet.

    Das ist aber keinen Deut schwieriger als beim C64, nur schaltet man eben die Konfiguration nicht über Speicherstelle $01, sondern über Speicherstelle $ff00 um.