C64 Studio - Entwicklungsumgebung


  • Endurion
  • 127423 Aufrufe 1803 Antworten

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • @atomcode:
    Ahhh!!! Das erklärt es vermutlich.

    Es kompiliert beim ersten Parsen nicht (ein Fehler oder unfertiger Code?), dann werden offenbar die Werte nicht in die IntelliSense gefüllt. Danke! Sehe ich mir an!

    @Acorn: Das war wohl mein Versuch, die Cycles und Byte-Anzahl von mehrfach verwendeten Zeilen aufzuaddieren. So ist's natürlich Murks. Kommt auch auf die Liste, danke für den Code-Schnipsel!
  • Moin,

    beim exportieren von Map-Daten, funktioniert der wrap m.E. nicht richtig. Zumindest bei den Tiles werden die nicht wie gewünscht "gewrappt". ;) Bei der Map hingegen klappt es. Ist das so gewollt?

    EDIT:
    Da scheint irgendwie noch mehr nicht zu klappen. Die Tiles sind 8x8 Chars groß...demnach also 64 Bytes. Nach 41 Bytes ist aber Schluß...die restlichen 23 Bytes fehlen.



    EDIT2:
    Und noch eine Frage: Kann ich irgendiwie über das Find/Replace-Tool nach einem Wert "$**" (wobei * tatsächlich Platzhalter sind), zu diesem Wert dann $40 addieren und den dann ersetzen? Also aus $18 würde dann $58 werden, aus $04 dann $44 usw...

    Gruß
    Markus

    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von Courage ()

  • Ich hab mich jetzt mal daran versucht das ganze unter monodevelop auf Linux zum laufen zu bekommen. Außer einigen copy/cp unterschieden im Post build, welche ich lokal gelöst habe, habe ich einen ersten pr an @Endurion geschickt.
    Jetzt baut es zwar, aber das Modul fastcoloredtextbox wirft eine exception. Mal weitersehen. Wäre toll wenn ich es zum Laufen bekomme.
  • 1. Das mit den Schriftarten hab ich ausprobiert. Es funktioniert auch wohl, aber ich hab es dann für totalen Quatsch mit Soße befunden und als netten Versuch in die Tonne geworfen. Denn, sofern das ganze monospace bleiben soll, nehmen die Courier- oder Consolas-Buchstaben trotz geringerer Nutzbreite genau so viel Platz ein wie die PETSCII-Zeichen, und man hat nichts gewonnen; es sieht nur sperrig aus. Man müsste dann die PETSCII-Grafikzeichen kleiner machen als die Buchstaben, aber um sie noch erkennen zu können, dann den ganzen Font größer, und das sieht alles aus wie Knüppel auf Kopp; kann man vergessen.

    Ich nutze den (installierten) C64-Pro-Mono-Font nun je nach Übersichtsbedarf mit 12pt oder 6pt. Damit haben die Zeichen ihre korrekte Form. Mit anderen Größen wirken sie etwas distorted.


    2. Die Sache mit dem Intellisense/AutoComplete: Ich habe eben vorhin ..

    • ein frisches Windows 7 SP1 in einer VM installiert,
    • dann das C64Studio dort auf den Desktop gezogen,
    • gestartet und nichts verstellt,
    • ASM-Dateien aus den Sample Projects geladen
    • ein paar Befehle hinzugefügt und festgestellt, dass ..

    sich das da nicht anders verhält. Intellisense bzw. AutoComplete gibt es immer erst nach dem Compilieren oder nach dem Versuch, einen noch nicht bekannten Wert zu ermitteln.
    Darum kann ich mir beim besten Willen nicht vorstellen, dass das bei dir oder anderen anders ist.

    Dass die Label, deren Adressen durch Assemblieren erst ermittelt werden müssen, vorm Compilieren noch nicht angezeigt werden können, ist klar, aber die explizit belegten Label und die Mnemonics könnten ja von Beginn an aufgeführt werden.
    Ich würde nur gern wissen, ob das so, wie sich das bei mir verhält, normal ist, oder ob über meinen PC ein teuflischer Fluch herrscht. :bgdev


    3. Giga-Ass hatte ich seinerzeit aus dem Sonderheft 21 ABGETIPPT! :chuck:

    Wer findet den Fehler auf dem Cover? ;)

    Das, was Mac Bacon da hat, muss ich mir mal ansehen. Allerdings tippe ich in diesem Fall tatsächlich lieber ab, weil ich den Code auch im Kopf haben muss und nicht nur im Editor. Ich brauche dazu lediglich den Quellcode als ASCII-Text, und den bekomme ich, indem ich mit VICE aus Giga-Ass heraus in eine Datei drucke.
  • Ahhh, jetzt komme ich langsam dahinter, was du meinst. Dann habe ich dich wohl immer falsch verstanden.

    Wenn man ein bestehendes Projekt öffnet, wird der Code dort schon mal pre-parsed, damit IntelliSense etwas hat. Das mache ich aber nicht, wenn man einfach nur asm-Dateien öffnet. Das ist tatsächlich so, wie du beschreibst.

    Mit der Info müsste ich da was machen können, kommt auf die Liste, danke!
  • Ich habe gerade versucht das aktuelle C64Studio unter LINUX mit einer MONO Installation ans Laufen zu bekommen.
    In der SuFu habe außer einem Treffer zu diesem 90 seitigen Threat nichts gefunden.

    1. Versuch mit "MONO C64Studio.exe" schlug fehlt weil System.Windows.Forms nicht gefunden wurde.
    Hmmm... also per apt install libmono-system-windows-forms4.0-cil nachinstalliert und
    2. Versuch... Aha es erscheint schon mal ein Fenster mit zig Fehlermeldungen. Die erste meckert, dass FastColoredTextBox nicht gefunden wurde. Das ist als .DLL im Archiv mitgeliefert, LINUX sucht aber nach einer .so. Also die Datei frech umbenannt mit .so dahinter und
    3. Versuch..... Ahhh weniger Fehler, d.h. es bleibt eine Meldung übrig: System.TypeLoadExecution: Could not load type 'C64Studio.Output.Display' from Assembly C64Studio. Version=1.0.0.0. etc. pp.
    Hmmm da sind ja noch 2 weitere DLLs im Verzeichnis. Also diese auch umbenannt mit .so dahinter und
    4. Versuch.... jetzt erscheint kein Fenster mehr mit einer Fehlermeldung, dafür bekomme ich das hier als Fehler in der Console:

    Quellcode

    1. Using default runtime: v4.0.30319
    2. Unhandled Exception:
    3. System.TypeLoadException: Could not load type 'C64Studio.MainForm' from assembly 'C64Studio, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
    Gibt's eine Chance hier irgendwie weiter zu kommen ?
    #######################
    Raveolution BBS
    raveolution.hopto.org:64128
  • Neu

    Egal, ob ich mit PSEUDOPC oder *= $02 arbeite, erzeugt der immer falschen Code.
    Ich hätte in Zeile 7 ein STA $04 erwartet, aber erhalte STA $0005

    Quellcode

    1. !to "bin\test.prg",cbm
    2. * = $1000
    3. !PSEUDOPC $02
    4. sta savea
    5. savea = *+1
    6. lda #$00
    7. !REALPC
    Alles anzeigen

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Soulstealer ()

  • Neu

    Soulstealer schrieb:

    Ich hätte in Zeile 7 ein STA $04 erwartet, aber erhalte STA $0005
    Bei Vorwärtsreferenzen geht der Assembler natürlich erst einmal von einer 16-Bit-Adresse aus, da er den genauen Wert nicht kennt. Das in späteren Passes zu korrigieren, ist nicht trivial, weil sich dadurch ja wieder andere Werte ändern könnten (man kann sich da in der Theorie sehr fiese Zwickmühlen konstruieren :D ).

    ACME schmeißt bei sowas eine Warnung ("Using oversized addressing mode"), damit man wenigstens manuell gegensteuern kann:
    Eine Möglichkeit ist, durch ein "+1"-Postfix explizit nur ein Argumentbyte zu erzeugen, also die ZP-Adressierung zu erzwingen:sta+1 savea. Alternativ ginge auch sta <savea, aber das geht natürlich schief, falls man den Code woanders weiterverwendet und der Wert wirklich mal 16 Bit benötigt (die erste Variante erzeugt dann wenigstens einen Fehler, weist also darauf hin).
    Yes, I'm the guy responsible for the ACME cross assembler
  • Neu

    gonzoMD schrieb:

    Es sind momentan noch viele Aufrufe implementiert, mit denen Mono nicht oder zumindest nicht direkt arbeiten kann, daher die exceptions. Ich bin noch dran diese zu umgehen bzw. Alternativen zu suchen und es werden weitere PRs folgen. Kann aber dauern.
    Faszinierend, während sowas wie z.B. Qt für das "olle" C++ richtig schön "cross-platform" funktioniert, schlägt man sich bei .NET Framework (was ja auf einer virtuellen Ausführungsumgebung, der CLR, aufbaut, also EIGENTLICH beste Voraussetzungen für Plattformunabhängigkeit bietet) mit solchem Mist herum :D

    Ja, mit .NET Core wird das endlich besser. Habe mich jetzt noch nicht eingehend damit beschäftigt, aber eine Windows.Forms Implementierung würde MICH da eher wundern -- ist ja auch nicht gerade der tollste Wurf (auch wenn sicher die mit Abstand komfortabelste Möglichkeit, ein klassisches win32 GUI zu bauen), und vor allem recht kompliziert in der "Emulation" für andere Plattformen als win32 (auch wenn Mono natürlich genau das tut).

    Trotzdem, finde ich super, dass jemand versucht, das ganze zu Mono kompatibel zu machen :thumbsup: Dann könnte ich auch endlich mal einen Blick wagen, Mono sollte ja auch auf meinem FreeBSD einwandfrei laufen ;)
  • Neu

    Hi Endurion

    Ich habe da mal eine Frage.
    Wenn ich ein Maschinenprogramm in Datazeilen umwandeln will, gehe ich ja bei dir über den Binary Editor. Dann dort auf Modfy - Import. Das alles klapp ja wunderbar. Nur ist mir auf gefallen das dein Programm immer zwei Bytes am Anfang mit anhängt. Reihe 0000 Spalte 00 und 01 siehe Bild.


    Ist das so gewollt?
    Dann hätte ich noch einen Wunsch. Es wäre nicht schlecht wenn man einstellen könnte wieviel Zahlen in einer Datazeile enthalten sind.

    Ach noch was, wenn ich
    !source <Vic-Label.asm> schreibe,findet er die Datei nicht. Obwohl ich in den Einstellung beim Library Paths mein Verzeichnis eingetragen habe. Was mache ich da falsch.Gruß Drachen
    :D :D Ich liebe den Sound vom C64ér :thumbsup: :thumbsup: :thumbsup:
  • Benutzer online 1

    1 Besucher

  • Tags