Hello, Guest the thread was called5.3k times and contains 100 replays

last post from spacer at the

GEOS-Programme selber schreiben ?

  • Du kannst ja mal 64Copy probieren.
    bekommst Du hier: https://ist.uwaterloo.ca/~schepers/personal.html
    oder auch hier: https://csdb.dk/release/?id=129971


    Zumindest benutze ich das hier auf meinem Schleppi eigentlich recht zuverlässig als "Schiebeprogramm".


    Hoffe geholfen zu haben.

  • Du kannst ja mal 64Copy probieren.

    64Copy kann nicht wirklich mit Geos-Dateien umgehen. Das sagt der Autor selber in der Anleitung und empfiehlt dafür selbst StarCommander. Man kann sich die Info anzeigen lassen (Datei - Info) in Geos. Das wars.


    Mit Geos-Dateien umgehen kann StarCommander (http://sta.c64.org/sc.html) . Er kann auch Dateien zwischen D64, D71 und D81-Images kopieren. Das funktioniert perfekt. Image öffnen, Geos-Datei auf PC ablegen (ein korrektes .CVT wird erstellt). Dann ein anderes Image öffnen und die .CVT da rein kopieren. Die Geos-Datei wird automatisch nach Geos zurück konvertiert.
    StarCommander kann auch direkt auf Disketten schreiben. Allerdings wohl nur unter MS-DOS bzw. bis maximal WindowsXP 32 bit


    Nachteil beider Programme: Sie sind MS-DOS- basierent. Deshalb funktionieren sie nicht auf 64bit Windows-Systemen.


    Zum Kopieren von Geos-Dateien zwischen verschiedenen Dxx-Images nutze ich heute noch StarCommander auf Windows 10 Home 32bit.


    DirMaster ist leider keine Alternative. Macht zuviele schwerwiegende Fehler.....


    Gruß
    Werner

  • Welche Adresse hat bitte das erste Byte im Grundscreen von GEOS64 oben links?

    Falls Du sowas meinst wie Poke "A", Adresse (oben links), das gibt es in Geos nicht.
    Geos bedeutet: Graphic Environment Operation System


    Da wird in Punkten (Pixel) gerechnet. Das erste (sichtbare) Pixel liegt an Adresse $a000. Das geht bis Adresse $bfff.


    Wenn Du z.B. obiges Basic-Beispiel in Geos realisieren willst, dann enthält das Geos-Kernal Routinen, die das realisieren, hier PutChar. Du mußt eine x-Koordinate und eine y-Koordinate und den Code des Zeichens angeben, welches ausgegeben werden soll. Beachte: Geos arbeitet mit ASCII-Code und nicht Pet-Ascii.


    Es gibt in Geos noch einen weiteren Bereich: Hintergrund-Bildschirm. Der wird dafür benutzte, wenn z.B eine Dialogbox aufgebaut werden soll. Geos speichert den Bildschirmbereich den die Dialogbox benutzt in den Hintergrundbildschirm und zeichnet dann die Dialogbox. Wird die Dialogbox verlassen, wird der Bereich aus dem Hintergrundbildschirm einfach in den Vordergrund-Bildschirm zurückgeschrieben. Der Hintergrund-Bildschirm liegt von $6000-$7f3f. Einzelheiten im MegaAssembler-Handbuch

    Bleibt das immer gleich?

    Ja. Der sichbare Bildschirm liegt immer von $a000-$bfff.


    Gruß
    Werner

  • Hallo, danke.
    Klappt schon wunderbar.
    Ist schon ein großer Meilenstein um etwas zu schaffen in Grafik mit einem cc65 Programm.


    Es klappt schon, ob es Sicherheitskonform ist sehe ich nicht.
    1000x die 129 geschrieben mit POKE in cc65
    und 1000x die 255 geschrieben mit einem zeiger in cc65.


    Die Geschwindigkeit ist super.


    Das compilierte Programm hat 894 Byte und das umgewandelte Compilierte als cvt hat 891 Byte.


    pokee.c


    pokeezei.c

  • Einzelheiten im MegaAssembler-Handbuch, was du mir empfohlen hast ?

    Ja.


    Im Teil A des Buches werden einige Programme erstellt. Die Quell-Texte dazu sind auch auf der Diskette, die das Programm MegaAssembler enthält. Hinweis: Im Buch gibt es auch ein paar Druckfehler in den abgedruckten Quelltexten. Die Quelltexte auf der Programm-Disk sind aber i.O.
    Im Teil B werden alle wichtigen Speicherstellen und alle Geos-Routinen erläutert.


    Gruß
    Werner

  • Habe jetzt mal eine ASM aus deinem Buch (Kapitel 4.5)umgesetzt um zu sehen...wie funktioniert das mit dem cc65.
    Es wurde 1zu1 umgesetzt
    Habe aber zur Übersicht die einfache ASM-Variante vom cc65 geommen. Später kommt das ohne asm(...).


    Gruss


  • Es wurde 1zu1 umgesetzt

    Glückwunsch.


    Anmerkung:
    Das Beispiel aus Kapitel 4.5 enthält noch keine MegaAssembler-Syntax. Das würde so auch mit jedem anderen Assembler funktionieren.


    Wenn man MegaAssembler-Syntax mit dem MegaAssembler benutzt, dann würden die Zeilen 11-23 Deines Quelltextes folgendermaßen aussehen:


    LoadW r3,50 ; linke x-Koordinate
    LoadB r11l,100 ; y-Koordinate
    LoadW r4,300 ; rechte x-Koordinate
    lda #255 ; Linienmuster
    jsr HorizontalLine ; Linie zeichnen
    rts


    (Erklärung der Rountine im MegaAssembler-Handbuch Seite 226 oben)


    Auf jeden Fall ist die MegaAssembler-Syntax leichter les- und verstehbar, als das Listing aus dem MegaAssembler-Handbuch. In den späteren Beispiel-Listings des MegaAssembler-Buches (ab Kapitel 5) wird auch konsequent die MegaAssembler-Syntax benutzt.


    Der MegaAssembler macht dann daraus den Code, wie er in Deinem Beispiel Zeilen 11-23 zu finden ist und wie er vom C64 unter Geos verstanden wird.


    Wie man das mit cc65 macht, kann ich nicht sagen. Habe mich über die Jahre an die Schreibweise (Syntax) von MegaAssembler gewöhnt und keine Lust und Zeit noch eine neue Schreibweise (Syntax) zu lernen ;-) .


    Was Du am Ende benutzt (MegaAssembler, cc64 oder was auch immer), bleibt natürlich Dir überlassen.


    Gruß
    Werner

  • Habe mich über die Jahre an die Schreibweise (Syntax) von MegaAssembler gewöhnt und keine Lust und Zeit noch eine neue Schreibweise (Syntax) zu lernen .

    Gute Entscheidung.


    Ich finde es zwar toll das man in C(?) Code für GEOS schreiben kann, und ich hab das eben auch mal mit dem Code aus Post#48 mit dem cl65 getestet, aber ich bin mir da nicht so sicher wie effizient der generierte Code ist. Ich hab das CVT mal in VICE geladen und disassembliert.

    Wenn ich das richtig vestanden hab sollte das Programm den Bildschirm löschen und dann 1000 Bytes im Grafikspeicher schreiben. Ich hoffe mal der C-Code ist nicht optimal, denn der generierte Code scheint mir mehr als nur überdimensioniert.


    Ich hoffe mal das ich den cl65 nicht richtig verwendet habe und der Code noch optimierbar ist. Für mich wäre ansonsten der generierte Code nur für kleinere Programme sinnvoll nutzbar wenn man C kann aber kein Assembler.


    Ich halte es da wie wweicht und bleibe beim MegaAss. Aber cool das man unter Linux ein GEOS-Programm compilieren kann. Auch wenn da vermutlich nur GEOS 1.x/2.x und nicht MP3 unterstützt wird.

  • Ich habe als Neuling mit meinem 70 jahren ausgelotet mit was man es besser machen kann. Seit mehren Tagen suche ich und bin dann auf cc65 umgestiegen. Beim Optimieren kommt noch etwas raus aber nicht viel , der wird dann von 800 Byte auf ca 600 Byte runtergehen.


    Da ich nicht meinen ASM-Code auf dem GEOS2.5 schreiben möchte unter einem GEOS-Editor habe ich mich zu diesen Ziel mit Cross entschlossen.
    Es gibt leider keinen ASM der unter Cross genutzt werden kann für GEOS-Code.


    Ich brauche Math-Befehle für meine Grafik mit Bewegung und FLOAT (geht auch mit dem cc65 unter GEOS2.5).
    Da kann der Mega leider nur die internen langsamen von GEOS anbieten.


    Ich würde mich freuen wenn ich mal schöne Grafikbeispiele usw von den Usern mit MegaAss hier sehen könnte , habe mir schon im Internet einen
    Wolf gelaufen. Es fehlen so wie bei mir mit cc65 mal schöne kleine Teste vom MegaAss....
    Es wird hier nur etwas geschrieben wenn hier etwas gemacht wurde...schade.


    Ich habe festgestellt das der cc65 für große Programme optimal ist.


    Gruss

  • cc65 ist für größere Programme optimal , beim MegaAss würde bald der Texteditor vom GEOS platzen und die Langsamkeit beim Compilieren habe ich festgestellt.

    Das sehe ich anders. Für größere Programme wird bei dem ineffizienten Code ganz schnell der Speicher knapp.


    Und was größere Programme mit dem MegaAss angeht, ich glaube ich darf sagen das GeoDOS und MegaPatch zu den größten GEOS-Projekten gehören und auch nach 20Jahren arbeite ich noch mit GeoWrite/MegaAss. Man kann da nänmlich den Code auf viele kleine Textdateien aufteilen und die dann assemblieren, genau wie unter C/cc65. MegaPatch besteht aus über 400 einzelnen Quelltext-Dateien.


    Das assemblieren unter GEOS langsamer ist, das stimmt. Bitte aber nicht vergessen das dies unter VICE kein Thema ist (WARP-Modus) und am C64 mit SCPU oder TC64 auch Möglichkeiten existieren das zu beschleunigen. Mal davon abgesehen das die mit dem MegaAss erstellten Programme direkt getestet werden können, nix mit CVT und kopieren auf D64 usw...


    Jeder so wie er kann.

    Hab ich ja geschrieben... wenn jemand C kann ist das doch OK... aber optimaler Code sieht eben anders aus. Schau Dir mal die Routine bei $052d in meinem Post an: Die soll genau 0(!) Bytes ab $056f löschen. kein Assembler-Programmierer käme auf die Idee so etwas zu schreiben.

  • -------------------
    GeoDOS und MegaPatch zu den größten GEOS-Projekten gehören
    -------------------
    Leider sehe ich keine Resultate in irgendein Forum wo ich mal viele funktionelle Tätigkeiten sehen kann zum lernen in Deutsch.


    ---------------
    Bytes ab $056f löschen
    ---------------
    Das ist für mich Kinderkram....das noch zu beurteilen.


    Ich nehme den cc65 , weil ich zur Zeit gute Erfolge habe.
    Es macht Spaß, das das GEOS2.5 jetzt FLOAT-Zahlen ausgeben kann mit dem cc65 , sogar aus den Basic-ROM raus.
    Das ist mein Hobby, wer macht so etwas verrücktes schon und tüftelt so.


    Gruss

  • Leider sehe ich keine Resultate in irgendein Forum wo ich mal auf viele funktionelle Tätigkeiten sehen kann.

    Was meinst Du damit?
    Den Code von GeoDOS kannst Du hier einsehen, den von MegaPatch findest Du hier. Mehr GEOS Code in Assembler geht fast nicht (gibt ja noch mehr Programme dort zu finden... geoDirSelect, geoCham64RTC). Der Code ist weitestgehend auch gut dokumentiert.


    Aber ich will Dich ja nicht von C abbringen. Wie gesagt finde ich es cool das es überhaupt funktioniert. Hab den cc65 extra aus dem github heruntergeladen und compilliert weil es mich schon immer interresiert hat wie C-Code gegen Assembler abschneidet. Das ist jetzt das erste mal das ich das beurteilen kann. Am PC fehlt mir da der Background.



    Das ist für mich Kinderkram....das noch zu beurteilen.

    Ich kann kein C... kann nur den Code zumindest halbwegs lesen. Schreib doch einen C-Code zu dem Beispiel von oben der optimiert ist. Mich würde das wirklich interessieren wie das aussieht im Vergleich zu einer reinen ASM-Routine. Ein paar Bytes Verlust sind kein Thema. Aber es sollte kein Code enthalten sein der absolut nichts macht.


    P.S. Hab gerade noch etwas Feedback bekommen, der Code lässt sich wohl noch etwas optimieren, aber nie so effizient wie Assembler. Macht nix. Jeder wie er kann ;)

  • Quote


    Schreib doch einen C-Code zu dem Beispiel von oben der optimiert ist.


    Ich nehme an das dieser Code:


    SetPattern(0);
    InitDrawWindow(&wholeScreen);
    Rectangle();


    Einiges verbraucht. Und anders durch eigene Routinen ersetzt werden kann.


    Ich hatte ja oben einmal nachgefragt ob alle Macros aus MegaAss mal lesbar umgesetzt werden im normalen Textformat, das wäre eine große Hilfe.


    Danke.
    Gruss