Forum64

@Sauhund:
Genaugenommen wollte ich nie so viel Arbeit in diese ganze Petcat-Geschichte stecken, das hat sich irgendwie verselbstständigt... Eigentlich wollte ich nur irgendwelche kurzen Codeschnipsel mit ein paar <PRINT"{down}{down}HALLO"> einfach einfügen können, ohne hinterher die {down} von Hand ersetzen zu müssen.
Zur "Wirkungsweise" nochmal eine Erklärung: Im gewählten blablabla-tokens.txt File stehen jeweils {code}=Wert. Bei der Umwandlung von ASCII in Programmcode wird alles außerhalb von Anführungszeichen 1:1 übernommen, bei allem in Anführungszeichen wird diese Liste abgeklappert und bei einem passenden Code das entsprechende Ersatzzeichen genommen. d.h. man kann durchaus für ein und denselben Zielcode verschiedene Quellcodes haben:

Beim umgekehrten Weg wird der erste passende Code in die Zieldatei gesetzt, in diesem Falle würden alle Leerplätze durch {space} ersetzt werden.
Dann kann man noch einstellen, ob die {blabla} Codes case-sensitive sind, weil BasText wohl {a} für ein ungeshiftetes a erzeugt und {A} für ein geshiftetes. Da ist das dann blöd, wenn beim Einlesen erstmal alles in Uppercase umgewandelt wird. Andererseits its PetCat nicht case-sensitive, manchmal hat man Listings mit {clr} und manchmal {CLR}. Naja, usw, usw,... allein dieses Thema könnte ein ganzes Buch füllen, hab ich das Gefühl.
Da alles über die einstellbaren und frei editierbaren ASCII-Tokenfiles steuerbar ist, kann sich da jeder austoben. Wenn also irgendwer ein neues solches File erzeugt, darf er mir das gerne zukommen lassen, das wird dann in die Release-Suite mit aufgenommen :-)

@Endurion:
Komisch dass das bei Dir so langsam ist, ich entwickle auf einem ollen Core2Duo 2.1 GHz mit einer ATI 4350, sowie einem 2 GHz Celeron(!) mit einer uralten NVIDIA 7500LE, also alles beileibe keine Boliden. Und ich habe immer Aufbauzeiten von 3-4ms pro Zeile bzw. ca. 30-40ms für eine komplette Bildschirmseite.
Irgendwie scheint da BasEdit nicht mit Deiner Graphikkarte/Treiber zu harmonieren

Das Invalidate hab ich wieder rausgeschmissen, das sorgt nämlich für ein unerträgliches Flackern weil dabei das Fenster automtisch ge-cleared wird, das ging gar nicht. Ich mache kein PutPixel, sondern ein DrawImageUnstretched, das funzt eigentlich sonst überall ganz prima.
Im MainWindow hab ich tatsächlich einen Timer, der sich um den Bildschirmaufbau kümmert. Das hat sich so ergeben, weil das Invalidate unbrauchbar war und ich einen anderen Weg gesucht habe. Insgesamt ist das GDI+ nicht das schnellste, allerdings bist Du bisher der Einzige, der solche Probleme hat.
Das Flackern und mehrfach Aufbauen habe ich immer dann, wenn ein anderes Programm/Fenster in den Vordergrund kommt bzw. mein MainWindow überlappt. Da kollidieren dann meine Timer-Aufrufe und das System-bedingte Invalidate.

Wenn Du in Programm im Label-Mode bearbeitest, speicherst Du das am Besten als PETSCII. Das kannst Du dann auch wieder laden und alles ist gut. Wenn Du das dann auf der echten Maschine bzw. im Emulator laufen lassen willst, speicherst Du es einfach als PRG-File, das wird dann automatisch wieder in den Zeilennummern-Mode zurückgewandelt. Bei F5 (Save&Run) sogar vollautomatisch im Hintergrund.

Control-Links und Rechts schaue ich mir mal an, eigentlich benutze ich die auch ständig und die sollten auch funktionieren... Da fehlt wieder irgendwo eine Abfrage auf "Nicht am Anfang der Zeile" oder so, .NET mit seiner Stringbehandlung ist da extrem pingelig, nicht so vergebend wie Basic V2.

Kurz und bündig: Ja.

Momentan hab ich auch einfach zu viele andere Baustellen, als dass mich das reizen würde Sorry für alle, die deswegen außen vor bleiben müssen...

Nana, jetzt keinen OS-Streit hier in meinem schönen Thread

Wie ich weiter oben schonmal erwähnte, war eine frühe Version wohl unter Mono lauffähig, falls jemand Zeit und Lust hat, kann er gerne mal probieren, ob das immer noch gilt. Wenn das geht wäre es natürlich prima

Neue Version 1.28 hochgeladen:


Ok, das ist jetzt hoffentlich meine letzte Änderung zum ASCII-Export... Upper-/Lowercase Characters werden jetzt erwartungsgemäß umgesetzt, sowohl innerhalb als auch außerhalb von Anführungszeichen. Ebenso werden "unübersetzbare" Zeichen, also diese ganzen Graphik-Sonderzeichen etc. außerhalb von Anführungszeichen einfach 1:1 weggeschrieben, innerhalb von Anführungszeichen wird erst nach einer Übersetzung {blabla} gesucht. Falls gefunden, wird die genommen, falls nicht, wird das Zeichen wieder 1:1 weggeschrieben. Und damit mir das .NET Framework nicht wieder dazwischenpfuscht, schreibe ich das jetzt alles byteweise in eine Datei, dann erhält man auch nicht mehr lauter ? für unbekannte Zeichen. Klappe zu, Affe tot.
Falls Ihr einfach nur einen Quelltext im Label-Mode sichern udn später wieder laden wollt, bitte nicht als ASCII, sondern als PETSCII-Datei speichern! Die speichert die Datei 1:1 ohne irgendwelche Schickimickis ab, da geht nix verloren...

bei der Übergabe einer aus einem Diskimage zu ladenden Datei direkt bei Programmstart wird jetzt der Name dieser Datei auf die gleiche Weise umgesetzt, wie ich das auch beim Laden von Basic-Quellcodes mache. Das bedeutet eine datei, die auf der Disk im Standard-zeichensatz "FILE01" heißt wird als "file01" übergeben - ungeshiftete Zeichen. Über Großbuchstaben in Dateinamen in Diskimages lass ich mich hier nicht weiter aus, die sehen als ASCII-Zeichen wüst aus. Mein Tipp: Macht Euch ein Arbeits-Diskimage, benennt die Dateien streng nach der Regel das nur die Zeichen "a"-"z" und "0"-"9" drin vorkommen und alles wird gut. Ein hübsches Directory könnt Ihr ja später mit beliebigen Tools basteln

@Endurion: Na da bin ich aber froh, dass das wohl eher ein Einzelfall zu sein scheint. bei PCs ist das mit der Eingrenzung ja immer schwierig, da können Virenscanner, irgendwelche anderen Hintergrundprogramme, ein unglücklicher Graphiktreiber oder sonstwas Schuld sein. Wahrscheinlich fühlt sich mein 8-Bit-Basic-Editor auf Deiner Monstermaschine einfach unwohl
Falls mir mal 'ne coole Testsuite dafür einfällt, um meinen BasEdit auf diversen Rechnern zu checken, komme ich gern auf Dich zurück, momentan bin ich allerdings eher ratlos.

Ach ja, hab vorhin nochmal eine neue Version 1.29 hochgeladen:


Das war auch so ein Drama, Vice macht merkwürdige Bit-Shiftereien mit Dateinamen, die man an ein Diskimage ranhängt, um aus einem ASCII-Dateinamen einen CBM-kompatiblen Dateinamen zu machen. Aber mein Tester hat mir jetzt versichert, dass das mit normalen, geshifteten und gecommodorten Zeichen geht, sogar ein Farbcode in einem Dateinamen wurde korrekt durchgereicht. Das Thema schließe ich hiermit auch ab.

Nachtrag: Hab jetzt auch den Fehler beim wortweisen Springen nach links mittels Strg-Links gefunden. Passiert nur im Label-Mode bzw. wenn man vor der Zeilennummer noch Spaces hat, da gerate ich dann in eine Fast-Endlosschleife, die irgendwann in einem Integer-Überlauf bei -2 Mrd und ein paar Zerquetschte endet. Zum Glück sind die PCs heutzutage schnell genug, dass das tatsächlich auftritt. Ab der nächsten Version (1.30) behoben.

Naja, benutzen kannst Du sie schon, sie werden nur nicht automatisch gekürzt -> verschwendeter Basic-Speicherplatz...
Außerdem, um das Feature sinnvoll zu unterstützen, müsste man auf doppelte Namen prüfen um bei sowas wie TEST=5 und IF TEIL=3 THEN... warnen zu können, dass TEST und TEIL beide zu TE werden. Da steckt noch ein bisschen mehr dahinter, ansonsten ist das Ganze fehlerträchtiger als nützlich, weil sich jeder darauf verlässt, dass die Variablen ja schön zurückgekürzt werden. Aber dran gedacht hab ich auch schon

Aber in dem Zusammenhang schwebt mir auch noch sowas wie IF..THEN..ELSE vor, oder DO..LOOP oder WHILE...WEND, d.h. ein paar Konstrukte, die sich beim Zurückwandeln vom Label in den Line# Mode auch noch sehr schon durch ein paar clever zusammengebaute Basic V2 Befehle ersetzen lassen.

So viele Ideen, so wenig Zeit...

Zuerst dachte ich: "Ist doch blöd, dann kann man den Basic-Code gar nicht mehr verstehen." Aber nach ein bisschen Nachdenken stimme ich Euch zu, der Basic-Quelltext, der dann rauskommt ist eigentlich egal, weil in dem eh niemand mehr rumändern soll. Und wenn ich meine anderen Ideen auch noch verwirkliche, haben wir eh keine 1:1 Hin- und Rückübersetzungen mehr...

Ok, ist auf meiner wachsenden ToDo-Liste