Ich mache das immer mit einem Semikolon.
Semikolon [ print"..."; ] benutze ich nach jeder ge-print-eten Zeile sogar auch schon. Für die allerletzte Zeile hilft das dann aber scheinbar nicht mehr.
Später am Tag probiere ich mit der Thematik noch 'mal herum (zuletzt war's gestern).
Wenn man mit dem Print Befehl etwas in die letzte (25.) Zeile schreibt, springt das Bild bekanntlich immer um eine Zeile hoch. So als ob man Return drücken würde.
Kann man das Verhalten irgendwie simpel umgehen und dennoch das Print weiterverwenden ?
Hab' schon versucht, es mit einem Cursorreset, Print"S" (invertiertes "S"), zu umgehen. Es half aber nicht.
Die Cursorposition zu poken, habe ich dagegen noch nicht probiert. -- Hat ggf. eh nichts damit zu tun, das Verhalten.
Eine U2+ Cartridge ist nun auch nicht viel weiter vom C64 entfernt, das nimmt sich ja wohl nix.
Für mich schon, der speaker"schall" kommt vergleichsweise offen durch die U1541II+ dafür gemachten Gehäuseschlitze hindurch, so dass das schon recht eindeutig für das Ohr zu orten ist (dass es genau dort her kommt,
spätestens sobald man sich dessen bewusst ist).
Zumindest, wenn sie laut eingestellt sind wie bei mir neulich. 
Aus (großen) Lautsprechern wirkt das Lesekopf Geschrubbe eher fremdartiger(..)
Das verstehe ich. So gesehen sind kleine speaker, die nur und einzig knackig Laufwerksgeräusche von sich geben und sonst nix, besser.
Mir wäre und ist Drivesound auch über die (TV- etc.)Lautsprecher recht. Sehe da keinen Unterschied, oder warum das unbedingt vom U64 kommen müsste. Ein org. C64 hat ja auch keine LW-Geräusche, die aus dem Brotkasten stammen.. .
Finde daher eher doof, wenn sie aus dem C64 Gehäuse des U64 her kämen. 
Beim U1541II+ (einer Steck-Cartridge) ist das dann wiederum 'was anderes, denn da und dann kommen die LW-Geräusche ja auch per speaker vom realen Verursacher.
Da aber schon nach der Intitialisierung per "z.B." Sys 4096 sich nichts mehr normal verhält (Cursor springt hin und her, kein Ausfüjren von Programmen mehr möglich, etc.) ist dass dann dennoch
nicht sehr geeingnet, um das in seine Programme einzubauen. Denn die sollen danach ja schliesslich auch noch laufen.. .
Korrektur: Wenn man es im Programm selbst ausführt, z.B. (für einen "1-Raster-Tracker" Tune, relocated ab $c200)...
10 sys $c200 : rem player initzialisieren
20 for t=1to4000
20 sys $c203 : rem abspielen
30 for i=1to7 : next i : rem Warteschleife, da sonst mehrere Ausrufe von Zeile 20 pro Frame = Absturz / muss mindestens 7 betragen ; höhere Werte machen den tune langsamer
40 next t : print"Nun ist Ende" : end
...geht das wohl doch (weiter). Nachdem der Zähler mit Variable t durch ist, wird nämlich normal das "Nun ist Ende" samt dem end dargestellt und ausgeführt.
Sich mit diesen Trackern vertraut zu machen, um einen eigenen Tune zu schreiben, steht dann aber wieder auf einem eigenen Blatt... .
Ganz so simpel wie mit dem Fasttracker 2 am PC (Dos) ist das dann nämlich doch nicht. Bei dem ganzen abstrakt wirkenden Zahlenwerten für Instrumenterstellung und weiteres... .
Müsste man halt das jeweilige Manual vorher und währenddessen gut studieren.
Habe' 'mal mit dem "1-Raster-Tracker" herumprobiert. Die Tunes kann man dort ja einfach relocaten, wie man es braucht, und auch selbst über einen Basic Vieerzeiler wiedergeben.
Da aber schon nach der Intitialisierung per "z.B." Sys 4096 sich nichts mehr normal verhält (Cursor springt hin und her, kein Ausfüjren von Programmen mehr möglich, etc.) ist dass dann dennoch
nicht sehr geeingnet, um das in seine Programme einzubauen. Denn die sollen danach ja schliesslich auch noch laufen.. . .
Der o.g. "Musikprofessor" ist btw. eine Public Domain (PD) Software. Kennt daher sicherlich keiner. Wenn man sie einmal braucht, findet man sie nicht wieder. Auch auf csdb nicht, da gibt's scheinbar prinzipiell gar nichts an PD Disks.
Aber damit konnte man jedes Tune einfach per Sys 49152, wie beim Hülsbeck Musiceditor aus der 64er in '86 samt seinen tunes, aufrufen und danach beliebig weitermachen / es einfach im Hintwergrund im IRQ spielen lassen.
So etwas bräuchte man doch, aber zusätzlich mit einer Routine zum Abschalten des tunes und des IRQ Inhalts - so dass wieder alles gesäubert wäre. Das heisst, das eigentliche Programm danach wieder im Originalspeed läuft.
Egal, mein Programm bleibt jetzt eh erstmal so wie es ist (unverbastelt).
Wie oben schon beschrieben ,alles läuft wieder perfekt, es war doch das Kabel.
Ja, ich schrieb noch am Posting und begann es, noch bevor dein nächstes Posting da war. (Also wir beide gleichzeitig)
Für das Kabel muss der Monitor natürlich hinten per Druckkonpof auf S-Video stehen. Das 'mal prüfen = testweise auch 'mal daran herumswitchen.
Am Monitor selbst kann natürlich u.U. auch immer 'was defekt sein bzw. zufällig die letzte Zeit seit der DoReCo defekt gegengen sein, also bloß die Umschaltung / der Druckknopf z.B. .
(Mein C= Monitor konnte von einem auf dem anderen Moment kein CVBS von jedweder Quelle mehr -also gegenteiliges-, S-Video und auch RGB ging und geht aber wie immer.)
---
Dass das Bild nach dem Einschalten des U64 aufeinmal schwarz-weiß war, das hatte ich übrigens auch schon 'mal. Aber nur 2-3x in mehreren Jahren. Nach einem erneuten Aus- und Einschalten war's dann wieder in Farbe.
Das wunderte mich auch und befürchtete schon einen Defekt am U64. Ist jetzt aber schon ca. 3 Jahre nicht mehr aufgetreten.
Kennst du, oder auch jmd. anderes, einen guten und simplen music tracker für C64, den man auch wieder beliebig per Sys Aufruf im Spiel abschalten könnte, so dass er bei Nichtwiedergabe gar keine Rasterzeit mehr klauen würde ?
Nur für den Titelbildschirm und dann wieder abschalten, alles wieder in den Ursprungszusatand, damit es (die Playroutine) das Spiel selbst nicht verlangsamt.
Bisher habe ich da noch fast gar nichts getestet, bis auf den sogenannten "Musikprofessor" vor 20 Jahren ;).
Weiß also nur, dass es da eine init und eine play adresse gibt oder bestenfalls geben sollte, u. was das bedeutet weiß ich auch.
Eigentlich soll das Spiel ruhig bewusst so "basic" bleiben, aber ein wenig experimentieren kann man ja 'mal. Der Track würde dann genauso basic sein, er soll das Spiel ja nicht vom Intellekt her überlagern, sondern soll dazu passen / nur das
Spielethema an sich im Titel untermalen.
Ok, danke für den Tipp, werde ich dann und wann 'mal ausprobieren / mich mit beschäftigen.
Die jetztige Rate von 74,64% , die exomizer erreicht, so dass gar en Programm knapp unter 15KB herausspringt, ist aber auch schon erstaunlich u. mir gut genug.
Da erinnere ich mich an einen Satz von einem RGCD-ler, sinngemäß: "Man wundert sich / würde nicht unterschätzen, was eoxomizer alles so klein bekommt."
Wenn ich ein paar mehr KB einsparen hätte wollen, dann würde ich a) all die ungenutzten Sprites weglassen. Die waren 'mal für eine Abbaler "2Pl-Duel" Version des Spiels + einen 1-Player Mode gedacht. So gibt's für den Anwender mehr
zu gucken und erforschen, wer er 'mal den Spriteeditor einer Freezercartridge ala NordicPower, etc., bemüht, um sich die Sprites anzusehen. Deshalb habe ich die drin gelassen (und vorgestern nur noch in die exakte Mitte des
jeweiligen Spriteausschnitts verschoben).
Und b) würde es ein halber statt ein gesamter Zeichensatz mit Groß- UND Kleinschrift bis auf ein Gimmick-Detail am Ende des infotexts rein theoretisch auch tun. Bzw. andere Methode: Ein echter Bytehunter/-saver-Mensch würde den
Zeichensatz vom Programmcode vom Rom ins Ram nach in meinem Fall $E000 kopieren, und würde sich dann damit die gesamten 17 Blocks eines kompletten Zeichensatzes einsparen.
Gut, seine Daten für die ganzen Zeichen-Neudefinitionen müsste man davon noch abziehen, welche er ja dann natürlich immernoch irgendwo in seinem Code unterbringen muss.
Habe jetzt noch im Titlescreen das "utilies" in "utilities" korrigiert, hatte ich zuletzt vergessen aber sets vorgehabt.
Die Vokabel vor mehr als 20 Jahren 'mal als "utilies" im Kopf abgespeichert, aber das Wort tut's ja so nicht geben (wie ich vor ein paar Jahren feststellte).
Ausserdem 2x ein "/" Zeichen mit einem "," Zeichen ersetzt. Ich musste vorher das "/" als Kommazeichenersatz nehmen, weil ich das Komma im Zeichensatz mit meinem Eigenzeichen eines nach unten zeigenden Pfeils überschrieben habe.
Vorhin habe ich aber das originale Komma nachgezeichnet und im Zeichensatz unter dem Kleeblattzeichen (das unter Shift + X), also jenes überschreibend, wieder hergestellt. Habe es somit endlich wieder zur Verfügung.. .
Das macht Spaß, "all" diese selbstgeschriebenen* Basic ZS-Änderungsprogramme von vor 20 Jahren wiederzubenutzen. Oldskool Do-It-Yourself-Method wie in '82/'83, anstatt jetzt irgendeinen ZS Editor Tool aus dem Net zu bemühen.
Zeichnen tue ich die einfach immer im Spriteeditor eines Nordic Power Moduls in einem umrahmten 8x8 Feld, um sie mir optisch in Originalgröße u. ggf. Passgenauigkeit zueinander genauer anzusehen.
Die Data Werte je Zeile (8 Werte pro Zeichen) errechne ich dann selbst und schreibe sie mir auf, um sie danach iin die Datazeile des o.g. Vierzeiler ZS-Änderungsprogramms, mit dem man jeden hereingeladenen ZS abändern kann
(Änderung der darin per Poke bemühten Anfangsadresse des jeweligen ZS vorrausgesetzt), einzufügen / zu übertragen. Dann kann man immer so schön live zugucken, wie ein Zeichen geändert/überschrieben wird, wenn man es
vorher im Bild eingegeben hat :). *Ok, das könnte genaugenommen noch auf dem Grafikkbuch von Data Becker herrühren, die kl. Grundformel dazu.
Du wirfst Ladeadresse mit Einsprungadresse durcheinander.
Ja, war mir indirekt auch annähernd klar. Das davor, von mir, war nur so allgemein erstmal sich umgangsprachlich und grob ans Problem herangetastet. Später wurd's ja, auch von meiner Seite, noch präziser und korrekter.
Plus: Hab' den exomizer heute auch zum allerersten Mal verwendet und bedient.
Ja, danke ! Das wäre bereits so wie gewünscht. Eben im neuesten VICE getestet.
(Der Micro64 gibt für den 2. Spieler Dauergas nach links-oben. Hat aber mit dem Emu zu tun, ganz sicher.)
Ist $081c die direkte Startadresse zum Ausführen eines jeden Blitz! Compilats ? Bin ich da richtig mit dieser Annahme ?
Morgen versuche ich die exomizer-outputdatei von dir zu reproduzieren. Erstmal Feierabend für heute.. .
P.S.: Im .d64 zum Spiel, welches ich später noch hier oder woanders veröffentliche, steht dann noch mehr drin: Und zwar zwei Bildschirme eines kleinen one screen noters (4 Blocks je Bildschirm und Datei)
miit mehr "techn." und "future plans" Info'gesülz' zum Spielchen. (Der längere Infotext im Spiel selbst ist ja schliesslich noch nicht genug.. . )
Meinetwegen... . Ist als .zip im Anhang, inkl. der leatest version of exomizer.
P.S. Ja, als Startadresse des Entpackers sollte man vlt. nicht gerade 2049 ($0801), sondern 2080 ($0820) eingeben wie auch im wiki. Oder noch eher deine o.g. Idee, k.A. .
Jetzt versuche ich nur noch einen Onefiler mittels exomizer von einer angepassten Version, die dann natürlich nichts nachlädt, zu erstellen. (Eingabeaufforderung: 'exomizer sfx 2049 main.prg sounds.prg sprites.prg zs.prg -o output.prg')
Das packen klappt auch alles samt den Zusatzdateien an nicht übeschneidenen höheren Speicherstrellen [ab $c000 (sounds), $c800 (sprites), $e000 (zs = Zeichensatz)], nur geht nach dem Entpackvorgang am C64 nichts weiter.
Ist ja auch kein reiner Maschinencode, sondern will mit RUN gestartet werden, das Compilat "main.prg". Also nach dem Entpacken nochmal ein RUN (Baisczeile), sowas erwartet ecomizer ja nicht gerade als mainfile.prg (startadr. 2049).
Zufällig eine Ahnung wie ich es als nächstes 'mal probieren sollte ? Vorgeben es sei ein Basicprogramm (siehe wiki zu exomizer) ? Andere Startadresse bzw. Loadadresse der gepackten Datei ?
[Mache ich ggf. nochmal einen extra Thread zu auf. Aber wenn jmd. eine Idee hat, wie man ein Blitz! Compilat am besten mit exomizer zu packen bzw. danach zum Laufen oder Ausführen bekommt, kann er seine Ideen gerne schonmal
hier äußern.]
Das ist für ein RT-Code nicht wirklich viel. Multiplikationen oder die Sqr-Funktion sind richtige Taktzyklen Fresser.
Die Bilder unten sind Ausschnitte aus meinem Decompiler. Da kannst du sehen, wie viele Versionen es gibt. Die Runtime hat immer eine unterschiedliche Größe. Da reicht schon ein TAX weiniger in dem ML-Code,
und schon hat du andere Messwerte.
Nutze den Austrospeed 5E. Das ist die Final-Version der Austro Serie.
Jetzt weiß ich btw. endlich auch, was du mit 1E, 5E usw. meintest. Das sind also die Bezeichnungen aus den Einzelfiles aus deinen .d64 uploads zum Austeo-Comp + Austrospeed hier im Thread. Dachte es wäre 'was komplizierteres.. .
Den Austrospeed 5E, also die letzte und neuseste Version des Austrospeed, habe ich gestern auch einmal getestet. Es lief aber nichts merkbar und auch nicht messbar schneller damit. Eher langsamer, ich war zumindest mit dem
Stoppuhrergebnis bei der längeren Messstrecke "b)" nicht überragend zufrieden.* Den Wert hatte ich auch schonmal ein paar Hunderstel bis hin zu einem Zenhntel besser hingekriegt. Daher bleibe ich aus Tradition beim
Blitz! v1 von skyles (der mit blauem C64 Originaleinschaltfarben Hintergrund).
* Die Werte bei der kürzeren Messstrecke "a)" waren aber ganz ok bis gut. (Bei flinkem Stopp-Finger zumindest.) Soll aber nicht heissen, dass es dabei einen neuen Rekord gab.
--- ---
wenn du das mit weniger Text und quasi tabellarisch nochmal für Doofe aufschreibst.
die sich eigentlich auf den Halbsatz davor beziehen müssten, die sich aber, glaube ich, auf irgendwas davor beziehen.
Für "Doofe" ist schon richtig ausgedrückt, denn bei mir wurde tatsächlich 'mal Tendenz zur Hochbegabung festgestellt. Das resultiert dann u.a. auch in solchen "zu schlau" oder kompliziert gestrickten Sätzen .
Will mich da aber nicht aus dem Fenster lehnen mit, denn das ist wenn dann nur so knapp dran (an der Anfangsgrenze zu selbiger..), als nun jetzt so wirklich ständig im Zustand einer Hochbagabung drin/drinne :).
Eben oben drauf die FC3 nun auch noch interessehalber getestet:
Mit aktivem (= nicht per 'Final Kill' deaktivertem) Final Cartridge III verlangsamt sich der Spielablauf ebenfalls etwas, nur nicht ganz so stark wie beim Nordic Power (und wohl sicher auch Action Replay), Werte:
a) Mit allen derer vier genannten komme ich auf 12,03 Sek .
b) Mit allen derer vier genannten komme ich auf 18,77 Sek. .
[Was ich da stoppe, steht ja schon in Post #7, nur falls jmd. gerade neu in den Thread einsteigen sollte.]
Die längere Messstrecke bei b) dauert mit der FC 3 also zufällig sehr genau eine Sekunde länger.. und mit dem Nordic Power knappe drei Sekunden länger.. .
Das Nordic Power Modul hat soweit ich weiß, im aktivierten Zustand einen Schnelllader. Es werden fast alle Dateitypen, wie PRG, SEQ, REL ect. schneller geladen.
Das bedeuted, dass die Daten dem Programm früher zur Verfügung stehen.
Den kann man mirt dem Befehl "DT-" (für Disk Turbo minus = aus) abschalten. Und wieder zusdchalten mit "DT+" (für Disk Turbo an).
Der hat damit aber überhaupt gar nichts zu tun, schon probehalber 'mal probiert. (Nachgeladen wird eh nur ganz am Anfang im group Titel, vor dem eigentlcihen Spieletitelbild, und danach nix mehr.)
Vielmehr läuft das Modul an sich im Hintergrund ja immer mit, per IRQ oder sowas (irgendwas für sich im Vgl. zu einem vanilla C64 beanspruchend),und verlangsamt den Programmablauf einfach etwas.
Könnte bei einer Final Cartridge ähnlich sein. Werde ich 'mal testen, ob die auch verlangsamend wirkt u. wenn ja wieviel.
-Es empfielt sich vy the way den abzuschalten, denn manchmal kommt der nicht hinterher. So schnell wie er lädt. UI. bleibt dann beim Sprung zum nächsten File hängen.
Auch bei so gut wie allen offiziellen games, z.T. . Egal ob v8.2 oder v9.1 des Nordic Power. Ob mit echtem C64 oder per U64 macht auch keinen Unterschied, bleibt ab und zu 'mal hängen der Schnellader.-
Hat bis jetzt, ohne dass er es genau weiß, nur Hucky.
Blitz! [v2] von c64-online.com / Reblitz64 / Austrospeed / Sauron - Blitz wäre jeweils nochmal um ein Mü schneller gewesen, wie ich aber nach der DoReCo erst feststellte.
(Meine Blitz! [v2], die ich zwar u.a. auf der DoReCo auch schon mit dabei hatte, war faktisch noch eine ältere Blitz! Version. Auch wenndie optisch in allen Belangen genau identsich zu der auf c64-online.com aussieht.)
Nee, (Korrektur) : Hucky hat doch keine langsamere Version des Spiels. Alle Blitz! Compiler "Versionen" bringen die gleichen Ergebnisse.
Das Langsamere kam nur dadurch zustande, dass das Nordic Power Modul im C64 steckte / im U64 lief, und ich es bei ein paar der Messungen also vorher nicht mit der Option und Taste F3 am Startup des C64 gekillt habe.
Hab' jetzt noch nichts gelesen, was zuletzt seit meinem letzten Post hier los war.
Wollte mich jetzt nur korrigieren und mich für widerum meine Beharrlichkeit 'entschuldigen', denn mir ist jetzt aufgefallen, wie die unterchleidlichen Werte (z.B. wiederholt in Post #31)
zustande kamen. Und zwar war bei den langsamerern Messungen das Nordic Power Modul noch aktiv. Bei den schnelleren Messungen dagegen habe ich es per F3 am Cevi-Startup gekillt / deaktivert,
Begründung: weil ich die mir neuen Compiler wie Reblitz64, Austrospeed, etc. ja extra vanilla und clean bzgl. des C64-Zustands (und meinen natürlich auch) testen wollte. -U. damit dann auch bessere Ergebnisse bekam.-
Das heisst nun also, alle erdenklichen Blitz! "Versionen" (Blitz! v1 von skyles, Blitz! v2 von skyles, Blitz! von Bladerunner, Blitz v2 von skyles von c64-online.com, Sauron - Blitz, Reblitz64, Austrospeed) kommen nun doch auf
den selben game-speed von:
a) Mit allen derer vier genannten komme ich auf 11,23 Sek .
b) Mit allen derer vier genannten komme ich auf 17,72 Sek. .
[Was ich da stoppe, steht ja schon in Post #7, nur falls jmd. gerade neu in den Thread einsteigen sollte.]
Das ist mir eigentlich schon immer aufgefallen, auch am echten Brotkasten damals vor 20 Jahren, dass der Code (und nicht nur der im speziellen) mit nicht deaktivertem / nicht abgezogenen Nordic Power Modul,
langsamer abläuft. Allein der Speilename aus Chars rel. ganz am Anfang scrollt bereits merkbar langsmer herein, wenn das Modul vorher nicht deaktivert wurde.
Gut ok.. :\, ab dem zweiten Abschnitt deines Posts wirds ja doch noch interessant. Das interessiert mich jetzt aber nicht. Da brauche ich ja Jahre, bei deiner Hochsprache, um heruaszufinden, welche Version ich nun vom Austrospeed
habe oder nicht. Mich interessieren nur meine Messwerte / also Praxis. Und für irgendeinen der vier o.g. schnellsten, soweit identischen, entscheide ich mich dann für den Release.
Der Basic-Sourcecode liegt dem Spiel später eh dabei. Sobald ich das also released habe, kannst du ja mit meinen Blitz! Varianten und weiteren beliebigen das selber nochmal compilieren.
Dann würden eben u.a. diese, in Post #31 genannten, Ablaufgeschwindigkeiten u.a. dir in der Praxis auffallen, genau wie mir.
