Posts by ZeroZero

    Lieber Endurion, lieber Georg, vielen herzlichen Dank für Dein weiterhin grandioses Engaement. Dass Wünsche nach Abweichung von Industriestandard-Code an Dich herangetragen werden, tut mir persönlich sehr leid!


    Mit einer Plug-In Schnittstelle könnten die daran interessierten Menschen Dein ganzes Studio de-standardisieren und sogar ein Basic V2.1 schaffen o. ä.


    Wie weit Du auf solche Wünsche eingehst, liegt da bei Dir :) Schönes Wochenende!

    @ZeroZero >"Vielleicht geht das ja gar nicht"


    Gehen täte das sicherlich schon in PHP. Es müsste sich nur jemand finden, der das macht. Allerdings habe ich noch nicht mal hier irgendwo eine Auflistung der verbreitetsten Assembler gefunden, um dafür Konvertierungsregeln zu ermitteln.
    Für mich wäre es allerdings wichtiger, meine beiden Projekte weiter zu stricken, sonst wird das ja nie was. Meine eigenen Quellcodes muss ich nun von Hand ins ACME-Format umschreiben, und dann geht's weiter. Spaß macht's mehr denn je.

    Danke für den Zuspruch! Auch ich würde stets dem Industriestandard folgen, aber evtl. einen Pseudo-OP zufügen, der abweichend meinen geliebten 6502 statt des standardisierten 65X02 generieren kann, wenn es einzelne Verbraucher glücklich macht, vielleicht in der Form "* 6502 ASL" akzeptiert, also JEDEM Assembler die Ausnahmegenerirung durch Plug-In ODER Macro-Code ermöglicht. Mehr wollte ich ja gar nicht.


    Danke nochmals für Deine Unterstützung, dass ich kein Vollnerd bin :)

    ALLERDINGS: Aus Deiner Reaktion und Ausführungen geht für mich jetzt hervor, dass es wahrscheinlich um ein "PlugIn System" handeln soll, welches Assembler Mnemonics also ASL A oder B oder C "the right way" einfügen soll?

    Allerdings hatte ich eher ein allgemeineres Plug-In im Sinn, dass mit den vorhandenen Codes für ASM korrekte, wie hier gewünscht, Optimierungen bzw. ASM-Codes bereitstellt, dass genau die benötigten Einflüsse auf den Code ausüben, also, wenn ich es Recht verstanden habe, den ASM-Codemit Regeln versieht, die gewisse Restriktionen beugen kann im Sinne, dass der ASM-Editor Anpassungen an die Compilerregeln bereitstellt, damit gewisse Anforderungen gesetzt werden, aber andere nicht einfließen. Vielleicht geht das ja gar nicht, aber das war mein Hintergedanke, und um Entschuldigung habe ich auch gebeten für meine harsche Antwort. Wenn mein Vorschlag "für'n Arsch" war, dann packt ihn OT und vergesst es einfach.
    Ich Blödie: eigentlich gehört das hier in Definitionen und Standards zu ASM Adressierungen, Syntax und Mnemonics [OT aus 'Assembler Tricks']
    Schon wieder ein neues Topic? Ich bin ja artig und versuche den Regeln zu folgen :)

    @ZeroZero Das war ja auch nicht auf Dich bezogen, sondern auf die Definitionssache weiter oben.
    Ich find's einfach immer wieder mühsam, wie hier im Forum interessante Themen und Threads kaputt geofftopiced werden, bis einem die Lust vergeht weiterzulesen oder was Konstruktives beizutragen.

    Dann bitte ich um Entschuldigung und werde nur dann etwas sagen, wenn mir direkt ASM-mäßigetwas einfällt!

    Was hier an emotionaler Disonanz wegen einer einfachen Definitionssache erzeugt wird, ist einfach Kindergarten-Niveau.
    Soll der Thread gleich in Laberecke-->Kindergartenecke?


    Koennen wir hier also bitte zurueck zum Topic - Assembler Tricks und Optimierungen - kommen.

    Ich weeiß ja nicht, auf wen Du Dich genau beziehst, aber das Bashen auf Flaming-Niveau ist bei einem ernst gemeinsten Post extrem kontraproduktiv. Daher doch bitte vorher genau nachdenken, ob ein Post ein Trolling oder ernst gemeint ist. DAS hilt dem Thread weiter, der keineswegs OT lauft. Ein solcher Plug-In entspräche a) dem Topic "Tricks und Optimierungen" als auch hier speziell dem ASM-Gedanken. Ich bin hier UNTERSTÜTZER und kein HAUSTROLL!

    Musst du ja auch nicht das ganze Studio neu schreiben.Du musst "nur" eine PlugIn Schnittstelle spezifizieren, in den Code einbauen, auf GitHub zum Mergen schicken und hoffen, dass Endurion das mit in das reguläre Release miteinbindet.

    Dir ist aber schon klar, dass das bereits schwer genug wird :D

    Ich habe bereits in der Vergangenheit entsprechende Software mit Plug-Ins erstellt, allerdings alles auf unserem eigenen Code. Es handelte sich um einen Fat Client für eine Spielewebsite, die es ermöglichte, bekannte Brett- und Kartenspiele über Plug-Ins in den Client zur Auswahl durch den Anwender zu implementieren, z:B. ab sofort kann ich mich auch an einen Tisch für Poker setzen, das gibt es jetzt, programmiert von einem Game-Entwickler über died efinierte Plug-In-Schnittstelle.


    Insofern war es ja leicht, weil aller Code in unserer Hand war. Und ja, aus genau diesem Grunde sage ich immer wieder, es hängt von Endurion ab, wie tief er uns in den Studio-Code eingreifen läßt - das möchte ich nämlich nicht neu schreiben.... :D


    Zur Erläuterung: bis zu meiner Lungenkrebserkrankung, die mich gerade umbringt (bitte kein Mitleid!!!!) habe ich 25 Jahre im professionellen Softwareentwicklungsumfeld gearbeitet und als Hobby 25% von Renaissance Games gehalten, und den Nachfolger Safari Games noch eine Weile begleitet und unterstützt.

    Ich sehe hier Gottseidank eine Entwicklung, die endlich die richtige Richtung nimmt. Die User wollen "Ihr" Studio komplett haben, und dazu sind einfach Plug-Ins notwendig, die das Studio korrekt erweitern. Eine Schnittstelle für Plug-Ins existiert zur Zeit nicht, so daß kenntnisreiche und willige User das C64Studio tatsächlich erweitern konnen. Meiner Meinung nach muss dass sehr zeitnah geschehen, sonst bleibt alles wie es ist. Auch mein eher schwaches Plug-In einer Snippet-Bibliothek ist da notwendig.


    Aber es ist Endurions Programm, und wie tief er uns in seinen Code eindringen läßt, wird nur er entscheiden.




    <EDIT MOD>Posting hierher verschoben, weil Thematik mit Wunschliste zu tun hat

    So, wie tief würde Endurion jetzt eine Schnittstelle für Plug-Ins in das C64StudioRelease eindringen lassen? Wie sieht das erste Modul aus? Wie Syshack treffend angemerkt hat, wäre mir hierzu ein Modul, dass eine Snippetsammlung verwaltet schon sehr recht, da mein Schwerpunkt z. Zt. nunmal auf BASIC liegt. Aber auch die ganze ASM-Diskussion hier verfolge ich sehr interessiert. Bin aber gerne bereit, nach Vorgabe einer .NET Sprache ein Modul selbst zu entwickeln und per Endurion im Basic-Editor oder Studio-Kern einsinken zu lassen :)

    Na, Endurion, habe ich da insgesamt was losgetreten? Tut mir leid, wenns Dir Arbeit macht... Meine Wünsche wurden ja durch sinnvolle und umfangreiche Verbesserungsvorschläge verschiedener User äußerst kreativ ergänzt, modifiziert, variiert und sehr brauchbar angepasst!


    Danke an alle hierfür!

    Mal davon abgesehen, was wir wollen:
    Das C64 Studio ist in C# mit WinForms programmiert, hat also einen.NET CLS/CTS Unterbau.
    Da ist es am Einfachsten, eine .NET Sprache wie C# oder VB.NET zu nehmen (es gibt auch COBOL .NET :bgdev ), die eben solche Anbindungen einfacher machen

    Gibt´s da nicht inzwischen auch pythonnet, für die richtige Unterplattform und python für den, ders braucht? Auch das sollte gehen.

    Bis jetzt im Browser nicht zum Laufen gebracht.... hängt seit Ewigkeiten. Ach ich Trottel - muss ja direkt ans Studio ran....

    Ich glaube, wir reden aneinander vorbei.Ich meinte Funktions-Erweiterungen für das C64 Studio als IDE, Du wohl eher eine BASIC V2 Snippets Bibliothek, die man ab Cursor-Position einfügen kann.

    Nein, ich rede von sowohl als auch. Ja, snippets zum komplettieren von existierenden Basic-Codes, und ja auch Funktionserweiterungen, die direkt in das Studio eingreifen, aber was und wie sollen die denn machen ausser mit asm oder bas zu erweitern? Das Studio komplett umkrempeln mit Zusatzcode? Aber selbst hier stimme ich Dir gerne zu, und zu den Sprachen habe ich mich ja geäußert, meinetwegen gerne PYTHON für den, ders braucht. Keine Probleme meinerseits, ernsthaft! Die Frage ist, wie tiefe Eingriffe Endurion zulassen möchte.


    Ich bin aber grundsätzlich auf Deiner Seite!

    Mal davon abgesehen, was wir wollen:
    Das C64 Studio ist in C# mit WinForms programmiert, hat also einen.NET CLS/CTS Unterbau.
    Da ist es am Einfachsten, eine .NET Sprache wie C# oder VB.NET zu nehmen (es gibt auch COBOL .NET :bgdev ), die eben solche Anbindungen einfacher machen.

    Basic V2.0 ist doch plain text im C64StudioRelease??? Als *.bas code??? Gleiches gilt für *.asm code. Verstehe daher den erneuten Einwurf nicht direkt, außer jemand möchte weitergehende Dateien erstellen, wie *.prgs, *.d64 oder Spezialformate der Umgebung.....


    Ich kann aber manchmal auch etwas schwerfällig sein, bin aber ansonsten gerne beletrbar.

    Das mit dem PlugIn Interface hatte ich schon mal angeregt.
    Das muss aber genau designed/definiert werden.


    Python ist nicht "Scheisse", es entspricht nur nicht Deinen Anforderungen :D
    Dabei wäre Python wohl das "Closest possible" to BASIC.

    Widerspruch: PYTHON mal beiseite gelassen und unbewertet, die native Lösung ist CBM Basic V2 Code, nicht "closest possible" zu Basic V2, sondern nativ Basic V2.0


    Und nein, PYTHON ist prima für die, die es brauchen, kein Angriff / Flame geplant.

    Ich finde Deine Idee sehr gut, sie erfordert aber, dass Endurion eine Schnittstelle in den Basic Editor packt, der dass Uploaden von Tools, Moduln, Plug-Ins usw erlaubt, und dass gute Basic-Entwickler (gerne auch ich) solche gemäß der Schnittstellenvorschrift entwickeln und einstellen.


    Sobald so eine Schnittstelle bereitsteht, bin ich auch bereit, Plug-Ins zu entwickeln.


    Aber grundsätzlich eine Bombenidee, die Endurion bis auf die Schnittstellenentwicklung komplett entlastet!


    Gut so, Zaadii


    ACH SO: die Schnittstelle sollte Abstand nehmen von Scheiß wie Python und lieber eine gängigere Skript- oder eine Hochsprache verwenden. Ich biete gerne VBA, C, C++, Java und ein paar mehr an, nur kein Python, kann sogar plain text in Commodore Basic V2.0 sein, wäre sogar mMn das Vernünftigste!


    Gleichartige Hilfsschnittstelle wäre sogar für den ASM-Editor fantastisch, Hilfe von Wissenderen!


    Insgesamt nochmal, Zaadii: super klasse Idee!!!

    Wichtig wäre aber tatsächlich, dass der Charset Editor vollständigen Basic Code inklusive Basic READ/DATA starters liefert.... Falls das schon existiert, finde ich keine Anleitung, wie ich das mache, außer Data-Zeilen bekomme ich nix, also auch keinen in Basic verwendbaren Zeichensatz...

    Hier könnte ich mir auch vorstellen, dass die erstellten Charset-Daten als Speicherdatei gespeichert werden und die Funktion die Basic-Nachladerzeilen stellt, wäre sogar viel eleganter und ist möglicherweise bereits in Deinem Code teilweise enthalten?!?!