Hello, Guest the thread was called3.7k times and contains 91 replays

last post from JeeK at the

Umsetzung von Basic-Befehlen in Maschinensprache

  • Mit dem Heft habe ich auch damals angefangen. Ist schon sehr empfehlenswert. Die Beispiele sind gut, und sogar die KERNAL-API ist dort dokumentiert. So mancher Fachbuchverlag hätte allein dafür ein Extraband verkaufen wollen.

    Ich würde da mal stark empfehlen, geduldig weiter zu lesen. Schleifenprogrammierungen sind da auch gut erklärt.

    Es hat natürlich Gründe, daß X und Y Indexregister genannt werden, und A Akkumulator. Mit einem Blick in den Befehlssatz sollte das offensichtlich sein.

    Statt SMON habe ich allerdings damals schon den Action-Replay-Monitor verwendet. Der macht im Prinzip das gleiche, aber ohne den C64-Speicher zu belegen. Und Freezepoints sind zudem auch beim Debuggen sehr nützlich.

    Mit Macro-Assembler auf C64-Seite habe ich mich auch nicht aufgehalten. Damit habe ich erst angefangen, als der PC meine Rechnersammlung ergänzt hatte.

    LogicDeLuxe Danke für Deinen Kommentar. Ja, ich bin noch ganz am Anfang - wahrscheinlich bin ich einfach zu ungeduldig. Aber ich werde es so machen, wie Du sagtest. Weiterlesen und probieren.

    Ich habe übrigens das TC64. Da ist ja auch ein Monitor drin. Den verstehe ich aber noch nicht so gut. Daher bin ich auf SMON gegangen. Ja, stimmt den AR MK IV hab ich ja auch noch.

    thx and greez

    Michael

  • So wie im obigen Beispiel.

    Ist für den ACME und wird mit SYS4096 gestartet.

    Oder eine Kernal-Routine dafür nutzen. Dan funktionieren auch Steuerzeichen z.B. ganz easy.

    Klar kann ich auch ein:

    lda #$41

    jsr $ffd2

    machen, um ein A auf dem Bildschirm zu bekommen.

    Es geht doch darum den TE an die Hand zu nehmen, um ihm zu zeigen, wie man simple Textausgaben selber macht.

    :)

  • Ich würde Dir dieses Buch

    https://archive.org/details/maschienensprache-fur-einsteiger

    empfehlen, das habe ich als besten Kurs für Einsteiger mit Basic-Kenntnissen empfunden - sogar (meiner Meinung nach) besser noch, als die Kurse im 64'er-Magazin, aber das ist natürlich Geschmackssache, jeder lernt auf seine Art ^^...

    Weiterhin viel Spaß und Erfolg mit Assembler!

  • Hast du den Monitor als Basic-Listing zum Download?

  • Nein, ich habe immer den Monitor vom Commodore Macro Assembler - siehe auch hier für mehr infos

    https://archive.org/details/Co…System_The_1982_Commodore

    verwendet, und bin damit gut zurecht gekommen. Generell scheinen die meisten Monitore fast immer die gleichen bzw. kaum abweichende commandos zu verwenden.


    p.s. @Foren-admins - ich habe die Disk dazu in der Wolke vermutet (z. B. unter software - c64- anwenderprogramme - assembler), aber nichts gefunden. Habe daher ein d64 image von der original Disk gerade als

    CBMASS.D64

    hochgeladen... könntet Ihr das nach Prüfung bitte gelegentlich in das entsprechende Verzeichnis verschieben, danke!

  • ASSEMBLER TUTOR AST 6440 (diskette) AST 6420 (cassette)


    The ASSEMBLER TUTOR package is a must for all would-be machine code

    programmers. It can also be valuable to those programmers who already

    know something about assembly language programming but wish to expand

    their knowledge of 6502 machine code. The ASSEMBLER TUTOR is divided into

    three modules. Each module covers one aspect of assembly-language

    programming and contains an introduction, a self-test and discussion of

    various aspects of assembly-language programming.


    ASSEMBLER DEVELOPMENT ASM 6440 (diskette)


    The ASSEMBLER DEVELOPMENT package allows you to program in assembler

    directly onto your COMMODORE 64. It provides all the tools the assembler

    programmer needs to create, assemble load and execute 6510 assembly

    language code.


    PROGRAMMER'S UTILITIES UTL 6440 (diskette)


    The PROGRAMMER'S UTILITIES package contains many useful routines to

    help both the new and experienced programmer to get the most from his

    COMMODORE 64. These include Disk-Handling routines for changing the

    device number of a disk drive and copying disks using a single disk

    drive, graphics utilities such as a sprite and character editor, sound

    commands and BASIC programming aids for easier screen formatting and

    control operations.

  • Thema KERNAL/BASIC-Output von Assembler aus benutzen - also WENN man schon was in Assembler schreibt, dann doch auch vermutlich, weil man Geschwindigkeit will? Dann das gähnend langsame Umfeld von PRINT im ROM zu benutzen wäre schon seltsam, ganz abgesehen davon, dass man natürlich relativ wenig über die Maschine lernt. Die 39-Zeichen-Schleife in den Bildschirmspeicher schreiben da braucht was, vielleicht um die 500 Takte? PRINT braucht um die 15000 Takte dafür. Jajaja, dafür ist PRINT "komfortabel", aber für "komfortabel" geht man nicht zu Assembler.


  • Thema KERNAL/BASIC-Output von Assembler aus benutzen - also WENN man schon was in Assembler schreibt, dann doch auch vermutlich, weil man Geschwindigkeit will? Dann das gähnend langsame Umfeld von PRINT im ROM zu benutzen wäre schon seltsam, ganz abgesehen davon, dass man natürlich relativ wenig über die Maschine lernt. Die 39-Zeichen-Schleife in den Bildschirmspeicher schreiben da braucht was, vielleicht um die 500 Takte? PRINT braucht um die 15000 Takte dafür. Jajaja, dafür ist PRINT "komfortabel", aber für "komfortabel" geht man nicht zu Assembler.

    Ist ja alles richtig. Die Frage ist doch aber auch: brauche ich zum Assembler lernen eine eigene Textausgaberoutine? Ist sich su3686 bewusst, dass nicht immer das Rad neu erfunden werden muss? Als Anfänger wird man z.B. auch nicht gleich eine Routine zum Laden von Disk selbst schreiben, sondern auf die Kernalfunktion zurückgreifen. In der Regel wird es auf ein paar Zyklen mehr für Textausgabe nicht ankommen, da Kernalroutinen von Assembler aus genutzt nun mal immer noch deutlich schneller sind als von BASIC aus. Mir ging es nur darum zu zeigen, was _auch_ gemacht werden kann.

  • PRINT ist eben nicht schneller, wenn es von Assembler aus aufgerufen wird. Die 15000 erwähnten Zyklen sind entsprechend gemessen. Auch ein Assemblerprogramm braucht zum Beschreiben des kompletten Bildschirms per PRINT beinahe eine halbe Sekunde: Effizienz, wie man sie von Microsoft gewohnt ist.


    Da das im Ursprungsposting erwähnte BASIC-Programm auch schon direkt auf den Bildschirmspeicher zugreift und nicht etwa PRINT benutzt, gehe ich auch mal davon aus, dass der OP weiß, wovon er redet bzw. was er will.


    IEC-Routinen sind was völlig anderes, schließlich schreibt man da letztendlich nicht nur ein paar Bytes irgendwo ins RAM.

  • 1570 Danke für Deinen Kommentar. Vielleicht muss ich auch nochmal meine Frage präzisieren: Meine Frage bezog sich auf die Situation, dass ich ein Scroller programmieren möchte und einen kleinen Text zeigen will. Hier frage ich mich, wie es die Demo-Coder so gemacht haben. Also wo und wie haben die Ihren Scrollertext im Code hinterlegt? Wahrscheinlich wird es viele verschiedene Varianten geben. Ich wollte mal in die Runde fragen, was ihr am sinnvollsten findet. Soweit ich verstehe (sorry für mein begrenztes Wissen), plädierst Du für eine zeichenweise Kodierung, während in retro-programming etc. eine Variable erzeugt wird, wo der Text drin steckt. Klar, je länger der Text, desto "unpraktischer" wird das Zeichenweise-Codieren - wobei man natürlich eine kleine Routine schreiben kann, die dann den Assembler-Code auf dem zu zeigenden Text herstellt. Wäre das auf jeden Fall, die timing-effizienteste Variante?

  • PRINT ist eben nicht schneller, wenn es von Assembler aus aufgerufen wird.

    Es ist insofern schneller als von BASIC aus, weil nicht erst der BASIC-Code geparst werden muss.



    Da das im Ursprungsposting erwähnte BASIC-Programm auch schon direkt auf den Bildschirmspeicher zugreift und nicht etwa PRINT benutzt, gehe ich auch mal davon aus, dass der OP weiß, wovon er redet bzw. was er will.

    Vielleicht ja, vielleicht auch nicht. Ein Hinweis auf Kernalroutinen schadet jedenfalls nicht. Aber dazu kann nur su3686 selbst etwas sagen.



    Edit: Da war der Browsertab zu lange offen hier, denn die Antwort von su3686 hatte ich noch nicht gesehen.



    Also wo und wie haben die Ihren Scrollertext im Code hinterlegt?

    Als Screencode, der direkt ins Videoram geschrieben wird.

  • Es ist insofern schneller als von BASIC aus, weil nicht erst der BASIC-Code geparst werden muss.

    Nochmal: Die 15000 Zyklen (bei einer 39-Zeichen-Konstante) beziehen sich auf die reine PRINT-Routine, nicht (auch) auf den Interpreter-Loop. Selbst wenn man den einbezieht, spielt der (natürlich) in dem Fall kaum eine Rolle: das Parsen eines einfachen Befehls wie PRINT (für eine Konstante) dauert "nur" etwa 500 Takte, würde in dem Fall also den Kohl auch nicht mehr fett machen. Ich hab mir das alles letztens gerade erst im Zusammenhang mit Optimierungen bei Gold Quest und muffis Compilertests zyklengenau im Emulator angesehen... :)

  • Hier eine kleine Demo eines Scrollers. Das must du nur noch in Assembler umsetzen. Es gibt natürlich auch andere Varianten, die zum Teil einen erheblich längeren Quellcode haben.


    PS: Warum nutzt du nicht einen Texteditor und ACME? Das ist bedeutend einfacher.:)


    Quelle: C64-Wiki

    Code
    1. 9 print chr$(147)chr$(14): poke 53280,peek(53281)
    2. 10 lf$=" "
    3. 11 lf$=lf$+" * * * das c64-wiki ist super ! * * * created by jodigi "
    4. 12 lf$=lf$+" copyright 2016 abbruch mit run/stop !!! "
    5. 13 for x=1 to len(lf$)
    6. 14 poke 781,11:poke 782,5:poke 783,0:sys 65520:print mid$(lf$,x,30)
    7. 15 for y=55741 to 55771:poke y,x: next y,x
    8. 16 goto 13
  • Gaanz quick and dirty, könntest Du den text...

    * * * das c64-wiki ist super ! * * *

    in der ersten Zeile scrollen lassen, in dem Du ihn irgendwo speicherst, z. B. ab c100 als screen codes...

    .m c100 c120


    .:c100 20 20 20 20 2a 20 2a 20

    .:c108 2a 20 04 01 13 20 03 36

    .:c110 34 2d 17 09 11 09 20 09

    .:c118 13 14 20 13 15 10 05 12

    .:c120 20 21 20 2a 20 2a 20 2a


    und dann einfach mit ein paar Schleifen (inklusive einer Verzögerungsschleife, sonst sieht man gar nichts) über den Bildschirm laufen lassen...

    ., c000 a2 00 ldx #$00

    ., c002 bd 00 c1 lda $c100,x

    ., c005 9d 00 04 sta $0400,x

    ., c008 e8 inx

    ., c009 e0 28 cpx #$28

    ., c00b d0 f5 bne $c002 ;; bis hierher die erste zeile mit den screencodes aus c100 befüllen

    ., c00d ac 00 04 ldy $0400

    ., c010 a2 01 ldx #$01

    ., c012 bd 00 04 lda $0400,x

    ., c015 ca dex

    ., c016 9d 00 04 sta $0400,x

    ., c019 e8 inx

    ., c01a e8 inx

    ., c01b e0 28 cpx #$28

    ., c01d d0 f3 bne $c012

    ., c01f 8c 27 04 sty $0427

    ., c022 a2 40 ldx #$40

    ., c024 a0 00 ldy #$00

    ., c026 c8 iny

    ., c027 d0 fd bne $c026

    ., c029 ca dex

    ., c02a d0 f8 bne $c024

    ., c02c e6 fb inc $fb

    ., c02e d0 dd bne $c00d

    ., c030 60 rts