Ich hab noch ein paar Platinen fürs Pluggy Reloaded da (Tastaturadapter plus SD-Karten-Leser), wenn jemand welche will, PM.
Posts by 1570
-
-
Die Umwandlungsroutine ist übrigens auch nur aus dem 6502-ASM von hier screencodes vs. PetASCII übernommen.
-
Ein PRG-nach-HTML-Printer mit dem Style-Font ist in Crank the PRINT schon integriert:
https://github.com/c1570/Crank…a4e7e4/cranktheprint#L177
PETSCII-nach-Screencode passiert dort in Zeile 239.
Das Ergebnis davon sieht dann zum Beispiel so aus:
-
Naja ohne Speichererweiterung bekommt man ein brauchbares Entwicklungssystem, das die gleiche Plattform als Ziel hat, ja schlecht hin. (oder man kompiliert halt wie damals von Disk zu Disk. Brrrr!)
-
-
-
An anderer Stelle meinte ich ja schon, dass es schon reichen würde, irgendeinen Compiler für TSB fit zu machen, dann passt das schon weitgehend. Compiler außer acht gelassen ist wohl das TSB-IF ein Problem da deutlich langsamer als das BASIC V2-IF.
Aber grundsätzlich sind BASIC und Sprites kein "Perfect Match", weil kaum saubere Bewegungen möglich sind (wobei man natürlich Helper implementieren könnte, die z.B. per Rasterinterrupt die Sprites ruckelfrei bewegen könnten).
Persönlich würde ich eher komplett bei Zeichensatz bleiben, das gibt dem Ganzen auch ein passendes Feeling und hat z.B. bei Gold Quest 6 dem Spaß keinerlei Abbruch getan, eher im Gegenteil.
Deswegen ja auch mein mehrfacher Hinweis, das das MAPPRINT so wie's jetzt ist wenig bringt, weil alles andere (Charaktere, UI) dann doch wieder mit dem langsamen PRINT gemacht werden muss.
-
Ich verstehe auch nach wie vor nicht, wieso MERGE und D! nicht einfach im Programmmodus bleiben, wenn sie aus dem Programmmodus heraus aufgerufen wurden (im Zweifelsfall einfach analog wie bei LOAD ein implizites RUN ausführen). Dann würde man sich die ganzen POKEs sparen, oder...?
-
Ein klein wenig frickelig ist das mit den Variablen behalten schon, weil a) der Speicherplatz evtl. mit Variablen behalten nicht ausreicht (geschenkt, gibt man halt ggf. Out of memory aus), aber vor allem b) Konstantenstrings direkt im Code liegen, die Stringdeskriptoren also potenziell bei MERGE/DELETE ungültig werden bzw. aktualisiert werden müssen.
Wobei das die BASIC-Autoren bei LOAD auch nicht geschert hat und da ggf. Variablen großflächig zu Müll werden.
-
Bei C geht sowas wie #include, weil der Precompiler das noch vor dem Kompilieren einfach alles zusammenkopiert. BASIC V2 hat aber weder Precompiler noch Compiler. Und vom Sprachdesign her ("alles irgendwie dynamisch zurechtpfuschen") würde merge/delete viel besser zu BASIC V2 passen.
Wann sollte TSB denn ein #include tatsächlich ausführen?
Würde MERGE bei TSB im Programmmodus automatisch wie LOAD das Programm neu starten, bräuchte man die POKEs nicht, siehe #1772.
-
Eigentlich würde es ja auch reichen, wenn MERGE analog zu LOAD im Programmmodus nach getaner Arbeit das Programm wieder von vorne starten oder gar direkt nach dem MERGE weitermachen würde... (und das Gleiche für D!)
-
Sofern sich die levelspezifische Logik nicht wirklich elegant in Strings abbilden (abstrahieren) lässt, baut man sich ja auch nur eine Art "BASIC in Strings", und dafür gibt's einen Begriff: https://en.m.wikipedia.org/wiki/Inner-platform_effect
Delete und Merge hielte ich da für die bessere Option, zumal man so das Spiel sozusagen unbegrenzt groß machen und es perspektivisch auch dynamisch aus z.B. einem CRT "nachladen" lassen kann. Gleichzeitig ist man nicht auf relativ gleichförmige Level festgelegt bzw. kann ziemlich frei entwickeln.
-
...oder einfach ein funktionierendes merge und ein aus dem Programm heraus aufrufbares variablenerhaltendes D!?
-
Wenn man es beim Umstecken irgendwie schafft, Pin 7 (5V) mit irgendeinem der Pins 1-4/6 (Richtungen/Feuerknopf) zu brücken, fließt wegen des entstehenden Kurzschlusses recht viel Strom durch die CIA.
Dafür muss man sich aber schon etwas anstrengen, also z.B. einen Joystickstecker mit Metallkragen irgendwie schräg dranhalten, und wenigstens unter BASIC ist auch nur Joyport 2 "gefährdet" (da Port 1/CIA1 PB vom normalen KERNAL-Keyscan als Eingang geschaltet ist).
Mit etwas Glück bekommt man entsprechende Fehler auch repariert, wenn man den betroffenen Leitungen einen separaten Pullup-Widerstand (3k3 oder so) spendiert, der den durchgebrannten in der CIA ersetzt.
Siehe auch C64-Wiki:
-
-
Das ist nur beim ROM der 1541-I wirklich kritisch und lässt sich auch dort einfach umgehen ("@0:"-Syntax oder Laufwerk vorher per "UI" zurücksetzen):
Laut diesem Beitrag von 2014 ist das Ganze etwas komplizierter. Dort steht auch, wie man den Bug angeblich auf einer neueren 1541 reproduzieren kann.
Ja lies den Beitrag (der im Wiki übrigens verlinkt ist) doch auch ganz durch (insbesondere das OPEN3,8,3 mittendrin nicht übersehen, ohne das tritt der Bug nicht auf!). Tipp: "UI vor dem SAVE" wie im Wiki geschrieben schließt offene Dateien und gibt Buffer frei.
Ich hab mit einer 1570 (nomen est omen) den Fehler trotz ausführlicher Nutzung von @: auch ohne UI übrigens nie gesehen. Aber wer hat auch schon weitere Dateien während eines SAVEs offen...
-
Allerdings soll diese Funktion bei der 1541 nicht benutzt werden, da sie nach zahlreichen Berichten buggy ist.
Das ist nur beim ROM der 1541-I wirklich kritisch und lässt sich auch dort einfach umgehen ("@0:"-Syntax oder Laufwerk vorher per "UI" zurücksetzen):
-
Dann ist das nicht richtig implementiert. PRINT ist so langsam, weil es intern bei jedem Zeichen bei Adam und Eva anfängt (z.B. bei jedem Zeichen einzeln alle Register auf den Stack sichert und danach wieder zurückholt; auf alle möglichen Spezialfälle wie Überlauf der logischen Zeile testet und so weiter). Ein optimiertes PRINT kann in etwa ähnlich schnell werden wie der Ansatz von https://github.com/c1570/CrankThePRINT .
-
Oder halt so wie in Simons’ Basic/TSB: Farben, Zeichensätze, Sprites & Co. (1673) beschrieben einfach Strings inkl. Cursor-Steuercodes und Farbcodes ausgeben. Dann spart man sich das Gefrickel mit einem separaten Farbarray und kann den Befehl auch gleich noch wesentlich vielseitiger benutzen. Im Moment ist das ja eher ein GHOSTVIEWMAPPRINT.
-
Dafür würde sich wohl Autostart anbieten (mit ,8,1 laden => lädt sich nach oben in den Speicher, setzt eigene Vektoren, setzt BASIC-Vektoren wieder korrekt). Ist aber etwas frickelig, das dann so zu machen, dass auch ,8 noch funktioniert, plus Autostart ist etwas nervig, weil alternative naive LOAD-Implementierungen (die einfach immer linear in den Speicher "laden", siehe diverse Module) damit nicht funktionieren.
