Posts by Endurion

    Boah, ist ja pervers :)

    Compilieren ja, die %% gehen beim Renumber verschütt, muss ich reparieren.


    Ist eingebaut, neue WIP-Version 7.3.5. Da bleiben auch mal Prozente übrig. Jetzt kommt ihr bestimmt mit @ für Dodecal-Zahlen um die Ecke oder sowas.

    Ha, sehr gut, danke! Ich wusste nicht, dass TSB die $-Notation für Hex-Werte erlaubt. Im Dialekt-File muss ein Eintrag


    HexPrefix=$


    eingefügt werden, das angepasste File sieht so aus (siehe Anhang). Wird die Datei getauscht/geändert, muss C64Studio einmal neu gestartet werden, damit die Änderung eingelesen wird.

    Dann sind auch gleich die Warnungen wegen der Variablennamen weg.


    Danke für's dranbleiben!

    Also sowohl das mit dem Lowercase als auch mit dem Leerzeichen $c000 kann ich nicht nachvollziehen, das ist längst behoben.


    Welche Version zeigt es dir an?

    Die letzte Version sollte die 7.3.3 sein, ich habe grade sicherheitshalber nochmal neu erstellt und die Version auf 7.3.4 hochgesetzt.


    Falls das immer noch auftritt, wie öffnest du die .bas-Datei?


    Wie sieht die Zeile bei dem $c000 aus?

    Ich habe ein Mega65-BASIC-Listing genommen mit u.A. einem PRINT$c000.

    @Zirias: Sowas kann man machen, habe ich bei einigen Projekten (Soulless 2, etc.) so gemacht.


    Man macht mehrere Projekte, setzt als Abhängigkeit die anderen Projekte, und im Post-Build-Event kann man dann einen exomizer-Aufruf einsetzen, der die anderen Teile alle packt.

    Irgendwo eine Änderung, wird alles relevante neu gebaut und dein fertig gepacktes Programm kann gestartet werden.


    petrus:

    Das müsste eigentlich mit der WIP-Version klappen, da habe ich den Status Groß/Klein mit im BASIC-File abgespeichert. Du kannst mal im Text-Editor nachsehen, in der ersten Zeile ist eine Info da drüber.

    Falls du die alte Solution noch hast, evtl. hat die Assembler-Erkennung wieder durchgedreht. In den Eigenschaften der Datei (Rechtsklick im Solution Explorer, Properties) gibt es einen Reiter "Assembler".


    Wenn dort "Auto" steht, und beim Klick auf "Detect" "C64Studio" erkannt wird, sollte es eigentlich klappen.

    Ggf. ist dort ein anderer Assembler eingestellt, dann erkennt C64Studio * = ... nicht mehr als Start-Anweisung.


    Du kannst mir sonst gerne mal deine Solution (den ganzen Ordner gezippt) zusenden, dann gucke ich mal rein, woran es liegt.

    Ohne die $01 bekomme ich immer einen Fehler zurück (!0). Ich habe das jetzt im PHP gelöst, da wird einfach das erste Byte weggeschnippelt. Das PHP sieht jetzt so aus:


    Code
    1. <?php
    2. $target_dir = "uploads/";
    3. $requestBody = file_get_contents( 'php://input', false, null, 1 );
    4. file_put_contents( $target_dir . "/result.dat", $requestBody );
    5. echo "OK";
    6. ?>


    Dabei wird natürlich kein Dateiname übergeben, aber das wäre sowieso noch ein anderes Thema. Mein Ziel vom Online-Level-Editor kommt näher!


    Edit: Welcher Blindfisch hat denn die Farben für PHP hier eingestellt. Im echten Theme (dem blauen) kann man da nix lesen.

    Jein, also nicht temporär, es wird einfach ein Build ausgelöst.

    Der schreibt auch alle Dateien und durchläuft alle Pre/Post-Build-Steps. Da kann man sich ja alles mögliche zurechtdrehen mit einem Projekt, wo dann auch unbedingt eine erzeugte Datei auf der Platte sein muss, damit das davon abhängige Projekt auch gebaut werden kann. Insofern klingt es erstmal simpel, einfach nur eine temporäre Datei zu nehmen.


    Aber grade wenn es auch um Punkt 2 geht, sollte ich das Vorgehen bei Renumber evtl. nochmal umbauen.

    Aktuell kann es auch mit includes in BASIC nicht richtig umgehen, ei ei ei.

    Der Haken ist, C64Studio macht dass Renumber auf der Grundlage eines geparsten BASIC-Programmes. Da geht nur ganz oder gar nicht :)


    Punkt 1 ist in WIP schon korrigiert, sollte das Programm noch nie gebaut worden zu sein, wird es im Hintergrund einmal gebaut. Das Bauen muss aber erfolgreich sein => keine Fehler (wie 2)


    Punkt 2 ist natürlich schon etwas kniffliger. Sollte man das Renumber dann trotzdem zulassen? Im Grunde müsste ich in dem Fall einige "Fehler" zulassen.

    Im unglücklichsten Fall kommt eine Zeilennummer mehrfach vor, dann hätte ich Probleme bei der Zuordnung.



    Hättest du einen Vorschlag, wie man die Meldung besser macht?

    Ich hänge mal das Beispiel an, das hatte ich meine ich von KiWi bekommen. Da geht es darum, dass einfach ein beliebiger Speicherbereich hochgeladen werden kann.


    Ich meine, das klappt in dem Beispiel deswegen gut, weil es $2002 Bytes sind ($2000 plus 2 Bytes Ladeadresse).

    Mir fehlt einfach mehr oder weniger das Detail, wie das Ende der URL gekennzeichnet wird. Das muss das WiC64 ja wissen, da die eigentlichen Daten ja im AFAIK im Body übertragen werden, nicht als Teil der URL.

    Das Ende muss es daher geben, da die 2 Längenbytes im Kommando auch die Länge der Daten beinhaltet.


    Natürlich könnte man die Daten auch mit in die URL packen, aber dann muss man ja auf Hex-Darstellung oder Base64 ausweichen.

    Hallo zusammen,


    KiWi scheint wohl derzeit ausgelastet, oder hat meine PN übersehen. Vielleicht kann mir jemand helfen:


    Ich bastle nach längerer Zeit wieder an dem Upload-Teil (HTTP-Push) und habe Probleme, einen beliebigen Speicherbereich hochzuladen.

    Entweder wird mir ein Byte mehr hochgeladen (eine 0 vorne dran) als ich möchte oder überhaupt etwas Anderes.

    Ich habe mich an dem httppush.asm-Beispiel orientiert und teste mit dem Kernal64-Emulator. Vielleicht fehlt mir auch nur etwas an den Details:


    Gesendet wird

    "W", zwei Längen-Bytes, Kommando (36)

    Danach kommt die URL, und am Ende der URL ist ihr im Beispiel eine 1 und eine 0. Was hat es mit den beiden auf sich?

    Die 0 scheint als Ende der URL benutzt zu werden, aber die 1??

    Wird die 0 mitgesendet?


    Danach auf jeden Fall einfach die Daten hinterher.

    Die Gesamtanzahl Bytes im Kommando entspricht die 4 für's Kommando, die Länge der URL (einschliesslich der 1) plus den Daten.


    Ich habe versucht, einfach 20 Bytes an Daten anzuhängen, aber wenn ich das nach dem Beispiel mache, sendet der mir die 20 Bytes im Anhang an die URL mit.

    Ich glaube, das Beispiel ist evtl. etwas unglücklich, da es mit einem Lo-Byte-Wert, der nicht sehr klein ist, das Kommando länger macht, als es sollte.


    Vielleicht hilft es, noch einmal ein Beispiel der Gesamt-Nachricht aufzuschlüsseln. Ist es so richtig?


    4 Bytes: "W", zwei Längen-Bytes, Kommando (36)

    x Bytes URL: Wie wird das Ende der URL gekennzeichnet? Mit einem 0-Byte? Das WiC64 muss ja erkennen, wo die URL fertig ist und die Daten anfangen

    y Bytes Daten: Einfach die Bytes der Daten hinterher

    Die Längenbytes sind die Summe von 4 + x + y


    Bin für jeden Tipp dankbar!


    PS: Klar könnte ich das eine Null-Byte im PHP wegschnippeln, aber ich bin kein Web-Entwickler, daher versuche ich, überflüssige Daten gar nicht erst durch die Landschaft zu schieben.:bgdev



    Mein Code sieht so aus:

    Autsch, da hilft kein Kompatiblitätsmodus. Ich befürchte, da wurde Hardware-Unterstütztes DirectDraw verwendet, das war zu der Zeit beliebt. Leider ist die HW-Unterstützung davon eigentlich bei keinen Grafikkarten mehr gegeben. D.h. das läuft dann alles im Softwaremodus. Ich wüsste nicht, ob und wie man da was machen kann, ohne tief einzusteigen.

    Aufpassen mit Leerzeichen in Pfaden.


    Ich hab die k64.bat so angepasst:


    echo off

    cd C:\Users\Georg\Desktop\C64\kernal64\jdk-17.0.2\bin

    set path=%path%;C:\Users\Georg\Desktop\C64\kernal64\jdk-17.0.2\bin

    set HOME=%~dp0

    set LIB=%HOME%lib

    set CP=%LIB%\kernal64.jar;%LIB%\jinput.jar;%LIB%\scala-library.jar;%LIB%\scala-parser-combinators_2.13-1.1.2.jar;%LIB%\commons-net-3.3.jar;%LIB%\jsoup-1.13.1.jar;%LIB%\rsyntaxtextarea-3.1.1.jar

    echo %HOME%

    start javaw -server -Xms64M -Xmx128M -cp %CP% -Djava.library.path=%LIB% ucesoft.cbm.c64.C64 %*



    In jdk-17.0.2 befindet sich das nicht installierte (ich versau mir doch nicht den Rechner) Java SDK, möglicherweise die 17.0.2.