Hallo PiCiJi,
ich habe den Thread verfolgt un auch nochmals überflogen. Auch in der Wiki habe schon nachgelesen, aber nichts über Kommandozeilenparameter gefunden. Habe ich diese übersehen oder gibt es noch keine Anleitung / Übersicht hierfür?
Grüße DMHas
Denise --help
Es sind jedoch nicht wirklich viele Parameter aber zum Starten einer Datei reicht es.
Danke für deine Antwort!
Ich (vielleicht auch andere) fände es praktisch Denise mit unterschiedlichen Konfigurationsdateien per Kommandozeilenparameter starten zu können.
So starte ich (mit WinVice) aus einem kleinen Pythonprogramm heraus verschiedene Konfigurationen für GEOS / mit Modulen / JiffyDOS / SuperCPU.
Vielleicht kommt diese Möglichkeit später mal?
Grüße DMHas
ok ich setze es auf die Liste. Im Moment sind sämtliche Optionen dezentral im Emulator verwendet. Irgendwann stelle ich das um, soll heißen alle Optionen sind an einer Stelle fest definiert und daraus werden dann die Kommandozeilen Parameter abgeglichen und die geladene Settings Datei ebenso, wobei gesteuert wird was Priorität hat.
Vollbild Auflösung und Wiederholrate können nun auch auf Linux und macOS geändert werden. Bei Linux dauert es ein paar Sekunden bis das System wieder bedienbar ist. Man sieht das gut am nicht blinkenden C64 Cursor.
Auflösungen im Zeilensprungverfahren (interlace) filtere ich raus. Bei macOS scheint das grundsätzlich kein Thema zu sein, zumindest gibt es da nichts zum Rausfiltern. Unter Windows bietet aber der selbe Monitor das interlace Verfahren an.
neues nightly
Im Menu 'Sonstiges' gibt es nun die Möglichkeit den automatischen Warp Modus zu aktivieren. Dieser springt an, wenn der Motor eines Floppys oder Datasette aktiviert wird.
Diskette:
Disk Emulation bei Bedarf spielt hier mit rein, im Fall von Problemen erstmal umschalten.
Kassette:
Der Motor kann durch Software deaktiviert werden, obwohl Play/FastForward/Rewind/Record gedrückt ist. Dies wird berücksichtigt, soll heißen deaktiviert die Software den Motor geht der Warp Modus ebenso aus, wie wenn die Stop-Taste gedrückt wird.
EF³: bisher wurde der Datei Name im EasyFlash Menu eingeblendet, wenn im Cart Header der Name VICE oder EasyFlash steht. Ergänzt habe ich noch 'EASYFLASH'.
Nachtrag: In der Statusbar erkennt man ob die Software den Motor der Datasette gestoppt hat. In dem Fall werden die Icons mit einem Hintergrund belegt, soll heißen die Taste ist zwar gedrückt, führt die Funktion aber nicht aus. Die Software entscheidet wann es weitergeht.
neues nightly
Im Menu 'Sonstiges' gibt es nun die Möglichkeit den automatischen Warp Modus zu aktivieren. Dieser springt an, wenn der Motor eines Floppys oder Datasette aktiviert wird.
Funktioniert gut, hab etwas damit herumprobiert mit verschiedenen Games und auch ein paar Demos. Prima Sache.
Ein Vorschlag dazu noch. Könnte man eventuell bei der Funktion eine Auswahl anbieten zwischen Diskettenbetrieb (laden von d64 Images) und Kassettenbetrieb (laden von Tapes), also beides voneinander trennen. So hatte ich das eigentlich auch im Sinn gehabt bei meinem damaligen Vorschlag.
Ich (und ich denke da bin ich nicht der Einzige) würde nämlich gerne für Tapes immer dauerhaft den aggressiven Warp-Modus eingeschaltet lassen, aber für Disketten vorerst den normalen Warp-Modus nutzen.
Vorerst deshalb, weil man dies dann, wenn eine "erstes File direkt in den Speicher setzen" Funktion kommt, für den Diskbetrieb dann eigentlich nicht mehr braucht, während es für Tapes natürlich super ist und total Sinn macht. Ist es getrennt einstellbar mit dem "automatischen Warp", ist man darauf dann gleich vorbereitet.
Und noch dazu, weil ein paar wenige Demos den aggressiven Warp nicht vertragen, ein Grund mehr, im Diskbetrieb vorerst 'nur' den normalen Warp zu nutzen. Bei Diskfiles macht es, wenn Jiffy-DOS auch noch mitlädt, nicht viel Unterschied, ob man normalen oder aggressiven Warp nimmt. Da wartet man dann vielleicht zwei Sekunden länger beim normalen Warp. Aber beim Laden von Tapes macht es schon was aus, weil das ja generell viel länger dauert. Hier lohnt sich der aggressive Warp auf jeden Fall und bringt schon einen nicht unerheblichen Zeitvorteil gegenüber dem normalen Warp beim Laden. Ausserdem gibt es mit Sicherheit auch keine Tape-Files, welche den aggressiven Warp nicht vertragen. Hier muss man also keine Bedenken haben.
Daher wäre eine getrennte Einstellmöglichkeit Disk/Tape wirklich prima.
Und noch ein weiterer Vorschlag. Wegen der Inkompatibilität von JiffyDOS und anderen Beschleuniger-Kernals zum Tape-Loading hatte ich damals (Eintrag #1451) solch eine Funktion
"beim Laden von Tapes auf Voreinstellung switchen im Firmware Menue"
genannt, was in der Tat zu Verwirrung bei den Usern führen könnte, weil man sich fragen könnte, wofür das überhaupt sein soll.
Aber wie wäre es, wenn man die Funktion direkt nach ihrem eigentlichen Sinn benennt, also etwa:
"automatisch immer den normalen Kernal benutzen, wenn von Tapes geladen wird"
oder eventuell auch
"aus Kompatibilitätsgründen immer normalen Kernal nutzen für das Laden von Tapes".
Dann wäre doch eigentlich jedem User gleich klar, wofür die Funktion ist und der Zusatz "aus Kompatibilitätsgründen" deutet auch gleich an, dass einige Beschleuniger-Kernals mit dem Tape-Loading wohl ein Problem haben. Und dass die Funktion selbst einen Sinn macht, ist ja sowieso unbestritten, weil man sich damit das jedesmal anfallende, händische Umschalten der Kernals erspart, wenn man von Tape laden will und sonst dauerhaft Jiffy nutzt.
Ich denke, solch eine Funktion würde selbst dann noch Sinn machen, wenn die mehrfach erwähnte "erstes File direkt in den Speicher laden" Funktion kommen sollte, denn vielleicht wollen ja dennoch manche User weiterhin auch ihr JiffyDOS noch benutzen, etwa wegen der F-Tasten Befehle usw?
Ach ja, hatte ich noch vergessen zu erwähnen und jetzt kann ich den vorigen Eintrag nicht mehr ändern. Deshalb jetzt hier.
Aber wie wäre es, wenn man die Funktion direkt nach ihrem eigentlichen Sinn benennt, also etwa:
...
...
"aus Kompatibilitätsgründen immer normalen Kernal nutzen für das Laden von Tapes".
Man könnte es dann eventuell so gestalten, dass es vollkommen egal wäre, was der User dann in seinem "Firmware" Menue eingestellt hat und Denise dann, wenn diese Funktion aktiviert wäre, zum Tape-Loading immer diejenigen Kernal-Files nimmt, welche sich im Denise/Data Ordner befinden. Dann wäre nämlich auch keine weitere Konfiguration des Users im "Firmware" Menue mehr notwendig, damit diese Funktion richtig arbeitet.
Und inzwischen konnte ich auch ein paar Probleme feststellen mit der neuen automatischen WARP Funktion. Im Demo "Edge of Disgrace" etwa, schaltet sich dann auch im laufenden Demo der automatische WARP manchmal zu, was dann zu kurzen Aussetzern im Sound führt. Da wird dieses Demo bestimmt nicht das Einzige sein, bei dem das so passiert.
Hier müsste man bei dieser neuen Funktion irgendwie sicherstellen, daß, nachdem sich das Floppy zum ersten Mal wieder ausschaltet (also nachdem das erste File geladen wurde), der WARP sich dann solange nicht mehr von selbst wieder zuschaltet, bis der User entweder das nächste File lädt oder einen Reset (Hard/Soft) macht. Für Zwischenlade-Sequenzen eines Games oder Demos, soll der WARP sich ja nicht aktivieren, weil dies zu etlichen Problemen führen würde (game-eigener Loader / Musik während des Ladens bei Demos ... usw usw), sondern nur beim ersten geladenen File.
Für Demos ist der automatische Warp eher nicht gedacht.
Schau mal du hast zahlreiche Kombinationen aufgezählt, wo ein bestimmtes Verhalten greifen soll. Ich verstehe den Wunsch ein Setting von Einstellungen zu treffen und alles geht. Nur dann bräuchten wir die ganzen Einstellungen nicht. Unterm Strich würde ich mir die Finger wund programmieren um alles zu erfassen und mit jeder Änderung wieder was anderes kaputt gehen, was wiederum erst später auffällt. Der C64 ist nun mal keine Spielkonsole und ich will nicht alles mit Spezial Einstellungen überfrachten.
Ich denke hier sollte unbedingt die Möglichkeit der custom Settings zum Tragen kommen. Man kann ja verschiedene Konfigurationen für Spiele und Demos erstellen und diese dann laden.
Spiele 1: automatischer Warp (aggressiv), Scanline basierter renderer
Spiele 2: Jiffy Dos, Zyklen basierter renderer
Demo 1: automatischer Warp (normal), Zyklen basierter renderer
...
...
Ich (und ich denke da bin ich nicht der Einzige) würde nämlich gerne für Tapes immer dauerhaft den aggressiven Warp-Modus eingeschaltet lassen, aber für Disketten vorerst den normalen Warp-Modus nutzen.
Technisch gibt es überhaupt keinen Grund, warum Tape Spiele weniger kompatibel zum aggressiven Warp sind als Disk Spiele. Der wirkliche Grund ist, du kennst ein Demo wo der aggressive Warp nicht funktioniert und willst keine bösen Überraschungen erleben. Ich wette, wenn du ein Tape Spiel entdeckst, wo der aggressive Warp nicht funktioniert, könnte ich die Funktion direkt ausbauen, weil du diesen nicht mehr verwenden würdest. Dann habe ich die Option zum Trennen umsonst eingebaut.
Es ist einfach, wenn man 100% sicher gehen will, dass der aggressive Warp keine böse Überraschung bringt, darf man diesen nicht verwenden.
Ist man allerdings bereit im Fehlerfall (extrem unwahrscheinlich oder wie viele Beispiele kennst du noch ?) mal den Setting zu ändern und ein 2. Mal zu laden mit dem Wissen wieviel Zeit man nach hunderten geladenen Spielen durch den aggressiven Warp gespart hat ...
Es reicht ja schon aus nur für Demos auf den aggressiven Warp zu verzichten.
Und inzwischen konnte ich auch ein paar Probleme feststellen mit der neuen automatischen WARP Funktion. Im Demo "Edge of Disgrace" etwa, schaltet sich dann auch im laufenden Demo der automatische WARP manchmal zu, was dann zu kurzen Aussetzern im Sound führt. Da wird dieses Demo bestimmt nicht das Einzige sein, bei dem das so passiert.
Ich könnte mir eine Option vorstellen, die steuert wie lange der automatische Warp abgeschaltet sein muss um wieder aktiviert werden zu können. Unterm Strich wird es auch hier keine Möglichkeit geben, das mit einer Einstellung alles perfekt läuft. Erhöht man den Delay wird sich der Warp beim kurzen Laden innerhalb der Demos nicht einmischen. Ein zu hoher Delay bewirkt aber z.B. in Spielen, dass man Zeit verschenkt.
Auch hierfür würde ich mir multiple Settings erstellen mit dieser neuen Option. Ok ich versuche hier mal was, so ne Art Slider für die Mindest Zeit die vergehen muss.
automatisch immer den normalen Kernal benutzen, wenn von Tapes geladen wird
multiple Settings verwenden, genau dafür ist die Funktion da. Andernfalls erstelle ich einen Emulator, dessen Optionen nur auf wenige Leute zugeschnitten sind und andere sich nicht mehr durchfinden.
Ich könnte mir eine Option vorstellen, die steuert wie lange der automatische Warp abgeschaltet sein muss um wieder aktiviert werden zu können. Unterm Strich wird es auch hier keine Möglichkeit geben, das mit einer Einstellung alles perfekt läuft. Erhöht man den Delay wird sich der Warp beim kurzen Laden innerhalb der Demos nicht einmischen. Ein zu hoher Delay bewirkt aber z.B. in Spielen, dass man Zeit verschenkt.
Auch hierfür würde ich mir multiple Settings erstellen mit dieser neuen Option. Ok ich versuche hier mal was, so ne Art Slider für die Mindest Zeit die vergehen muss.
Ich merke gerade, dass das keinen Sinn macht. Mit so einer Einstellung verhindert man den Warp im gesamten Demo, was ja beabsichtigt ist. Nur dann kann man den Warp auch direkt deaktivieren.
Ich baue jetzt noch eine Option (zuschaltbar) rein, die den automatischen Warp deaktiviert, sobald man den Warp per Hotkey ansteuert. Auf diese Weise kann der automatische Warp bei bestimmten Demo Loadern oder Spielen, wo man den eigentlichen Ladevorgang z.B. aufgrund von Sound erleben will, temporär deaktivieren.
Für Demos ist der automatische Warp eher nicht gedacht.
Schau mal du hast zahlreiche Kombinationen aufgezählt, wo ein bestimmtes Verhalten greifen soll. Ich verstehe den Wunsch ein Setting von Einstellungen zu treffen und alles geht. Nur dann bräuchten wir die ganzen Einstellungen nicht.
Verstehe ich nicht so ganz. Der automatische WARP war doch, so hatte ich ihn zumindest verstanden, grundlegend dafür gedacht, den Ladevorgang des ERSTEN Files welches geladen wird, zu beschleunigen (so ist es ja auch im VICE) und nicht dafür, auch Zwischenlade-Sequenzen von Demos oder Spielen zu verringern.
Denn will man das, dann ist die Inkompatibilitätsquote ja riesig, weil es dann bei jedem zweiten oder dritten Spiel Probleme gibt und bei Demos sowieso, weil man dort ja so gut wie immer Musik hört, während das Floppy schon den nächsten Part lädt. Hier hätte man dann überall Probleme, wenn der automatische WARP sich wieder aktiviert.
Man bräuchte auch keine zahlreichen Kombinationen, sondern nur eine generelle Regel, daß der automatische WARP, sobald das Floppy sich zum ERSTEN MAL wieder abschaltet (also das erste File geladen ist) solange nicht mehr von selbst wieder aktiviert, bis der User entweder das nächste File lädt oder einen Reset macht. Dann würden solche Zwischenlade-Probleme nicht mehr anfallen. Ich denke, den WARP auch zum Zwischenladen aktiviert zu lassen, verursacht bei soviel Software Probleme, dass man das als User nicht sinnvoll nutzen kann.
Ich wette, wenn du ein Tape Spiel entdeckst, wo der aggressive Warp nicht funktioniert, könnte ich die Funktion direkt ausbauen, weil du diesen nicht mehr verwenden würdest.
Kommt mir sehr unwahrscheinlich vor. Diejenige Software, die Probleme mit dem aggressiven WARP hat, waren bislang ausschließlich Demos. Spiele scheinen davon überhaupt nicht betroffen zu sein, das ist fast wie beim scanlinebasierten Renderer, wo ja auch nur Demos Probleme machen. Und da es keine technisch aufwändigen Tape-Demos gibt, wird man bei Tapes wohl nie auf Probleme stoßen mit dem aggressiven WARP.
Ich könnte mir eine Option vorstellen, die steuert wie lange der automatische Warp abgeschaltet sein muss um wieder aktiviert werden zu können. Unterm Strich wird es auch hier keine Möglichkeit geben, das mit einer Einstellung alles perfekt läuft. Erhöht man den Delay wird sich der Warp beim kurzen Laden innerhalb der Demos nicht einmischen. Ein zu hoher Delay bewirkt aber z.B. in Spielen, dass man Zeit verschenkt.
Auch hierfür würde ich mir multiple Settings erstellen mit dieser neuen Option. Ok ich versuche hier mal was, so ne Art Slider für die Mindest Zeit die vergehen muss.
Ich merke gerade, dass das keinen Sinn macht. Mit so einer Einstellung verhindert man den Warp im gesamten Demo, was ja beabsichtigt ist. Nur dann kann man den Warp auch direkt deaktivieren.
Ich baue jetzt noch eine Option (zuschaltbar) rein, die den automatischen Warp deaktiviert, sobald man den Warp per Hotkey ansteuert. Auf diese Weise kann der automatische Warp bei bestimmten Demo Loadern oder Spielen, wo man den eigentlichen Ladevorgang z.B. aufgrund von Sound erleben will, temporär deaktivieren.
Wie oben schon erwähnt - wenn programmiertechnisch umsetzbar, soll nur diese oben beschriebene generelle Regel gelten, daß sich WARP nie mehr einschaltet, nachdem das Floppy zum ersten Mal wieder stoppt. WARP zum zwischenladen kann man ja notfalls auch händisch immer zuschalten, nur beim ersten geladenen File soll er automatisiert von selbst einschalten. Auch im VICE schaltet sich der WARP nie mehr ein, wenn das erste File einmal fertig geladen wurde.
Das hat auch nichts mit persönlichen Wünschen zu tun, es ist nur so, dass es anders wohl keinen richtigen Mehrwert darstellt. Auch bei Tapes stieß ich inzwischen schon auf Probleme, das klappt auch bei vielen nicht richtig mit dem automatischen WARP. Auch deshalb wäre eine getrennte Einstellung nicht schlecht gewesen. Aber gut, alles nur Vorschläge, ob das dann reinkommt oder nicht, ist ja nicht meine Sache.
Es gibt mehrere Möglichkeiten den Ladevorgang zu beschleunigen.
- automatischer Warp Modus
Hierbei wird die Geschwindigkeit der gesamten Emulation erhöht. Normalerweise sieht der User, dass geladen wird, drückt den Warp Modus und wenn er merkt, dass z.B. das Titelbild sichtbar wird, deaktiviert der User den Warp Modus wieder. Der automatische Warp Modus (wir ignorieren an der Stelle mal den aggressiven aus Gründen der Veranschaulichung) versucht nun zu erkennen, wann der Motor läuft um daraufhin den Warp zu aktivieren. (gleichbedeutend als würde der User den Hotkey dafür drücken). In der Regel wird der Motor am Ende des Ladevorganges von der Software abgeschaltet. Dies erkennt der automatische Warp und deaktiviert sich. Im Grunde erspart man dem User die Verwendung des Hotkeys.
Der Vorteil dieser Methode ist, dass es nahezu (aggressiver Warp) keine Inkompatibilitäten gibt. Deswegen eignet sich diese Methode auch gut für Spiele, welche später nachladen.
Der Nachteil dieser Methode ist, dass bei Loadern, die z.B. Sound oder Grafiken präsentieren, dies optisch zu schnell abläuft oder beim Umschalten des Warp der Sound hörbar synchronisiert.
Aus dem Grund ist diese Methode weniger gut für Demos geeignet.
Diese Technik ist aktuell in Denise realisiert. Ich würde hier noch ergänzen, dass durch Drücken des Warp Hotkeys ein eventuell aktiver automatischer Warp überschrieben wird und erst wieder beim nächsten Neustart aktiv ist. Z.b. weil man bemerkt, dass das Programm häufig und kurz zwischendurch lädt und der automatische Warp keinen wirklichen Nutzen mehr bringt sondern durch das ständige Umschalten permanent die Synchronisation kaputt macht.
- Virtual Device Traps
Diese Technik gibt es noch nicht in Denise, ist aber fest eingeplant. Hierbei wird die Geschwindigkeit der "Gesamt Emulation" nicht erhöht. Im Grunde wird das Floppy Laufwerk gegen eine virtuelle Bereitstellung der Daten ersetzt. Diese Technik kann die Daten viel schneller in den C64 Speicher schaufeln als das echte Laufwerk.
Der Vorteil dieser Methode ist, das Audio und Video nicht neu synchronisiert werden müssen.
Der Nachteil ist, dass spezielle Loader damit nicht kompatibel sind. Deswegen eignet sich diese Methode eher für den ersten Standard Ladevorgang, welche durch den C64 Kernal durchgeführt wird. Beim Nachladen (also wenn die Software übernimmt) sollte dann besser auf das Original Laufwerk zurück geschalten werden. (noch keine Erfahrung)
Da ich mich hiermit noch nicht beschäftigt habe, kann ich keine weiteren Details darüber nennen.
- IEEE 488 (nur am Rande bemerkt)
Im Gegensatz zu den beiden oberen Varianten ist dies ein reales Vorgehen am echten Gerät. Für den C64 gibt es Cartridges, welche das Anschließen der schnelleren PET Laufwerke ermöglichen.
Diese übertragen die Daten parallel also Byte weise, anstatt seriell (Bit weise) wie beim normalen C64 Laufwerk.
Wie hoch die Kompatibilität ist, weiß ich derzeit nicht.
- Schnelllader
Jiffy Dos, Speed Dos, ...
Echt krass, was es da alles noch geben kann - aber man sollte den Emulator auch irgendwie nicht überfrachten.
Finde er hat jetzt schon irre viele Einstellmöglichkeiten, wo man manchmal schon nicht weiss, was sich wie gegenseitig beeinflussen könnte.
Das ist alles soweit schon klar, vielleicht haben wir etwas aneinander vorbei geredet. Was ich meinte und was noch zu ergänzen wäre - VICE hat ja ebenfalls, zusätzlich zur "Virtual Device Traps" Funktion, auch noch einen zuschaltbaren automatischen WARP, den der User im Autostart-Menue aktivieren kann, diese Funktion nennt sich dort "WARP on Autostart" (im älteren WinVICE heisst sie "Autostart WARP").
Dort arbeitet diese Funktion so, dass sie sich nur beim Laden des ersten Files zuschaltet und bei einem späteren Nachladen eines Spiels/Demos dann nicht mehr. Finde ich so auch sinnvoll. Wahrscheinlich wurde das aus Kompatibilitätsgründen so gemacht, weil man ja in vielen Spielen/Demos mit Problemen rechnen kann, wenn sich auch bei Zwischenlade-Sequenzen, plötzlich dieser automatische WARP wieder von selbst einschaltet. Plötzlich geht das Spiel sofort schon wieder weiter an einer Stelle wo man sonst eine kleine Ruhepause hat (etwa zwischen den Levels), oder der Loader-Sound setzt aus undsoweiter. Damit rechnet man dann ja nicht unbedingt im laufenden Game und es verwirrt auch.
Daher wäre zu überlegen, ob es wirklich Sinn macht, wenn sich der automatische WARP auch bei einem späteren Nachladen in einem Spiel/Demo dann jedesmal wieder von selbst zuschaltet, oder ob das nicht mehr Verwirrung bei den Usern als Vorteile bringt. Bei Demos wird das sowieso nicht gut funktionieren, weil dort dann so gut wie immer der Sound aussetzen würde, was bedeutet, dass der User dann diese automatische WARP Funktion nie dauerhaft aktiviert lassen kann, oder sich, wie von dir schon erwähnt, dann verschiedene Settings im Emulator abspeichern müsste, zwischen denen er dann hin und her springt. Aber ist das so sinnvoll? Vor allem, da zwischenladen/nachladen eh nie wirklich lange dauert in den Spielen, weil ja oftmals auch noch game-eigene Loader mit involviert sind.
Bei einem WARP, der sich nur anfangs beim ersten File zuschaltet und danach dann nicht mehr, würde man sich einiges an Problemen ersparen und der User könnte dies für alles aktiviert lassen, egal ob er nun Spiele oder Demos lädt. Kommt allerdings in absehbarer Zukunft eine "setze das erste geladene File direkt in den Speicher und lade dann normal weiter" Funktion kommt, dann wäre das eine Alternative dazu.
Wobei da aber ja auch noch nicht ganz klar ist, ob es sich technisch so wie gedacht umsetzen lässt, ohne dass Probleme beim weiteren (normalen) Nachladen, eines direkt in den Speicher gesetzten Files, entstehen. Daher wäre ein automatischer WARP, selbst wenn er nur für das erste File aktiv wäre, trotzdem immernoch eine sinnvolle Alternative. Im WinVICE hat man beispielsweise auch beide Möglichkeiten, um das erste File schneller laden zu können und danach normal weiterzuladen, sprich
- "Warp on Autoload" aktiviert
oder
- "Virtual Device Traps" aktiv, dazu "True Drive Emulation" aktiv und "Handle True Drive Em" eingeschaltet
Echt krass, was es da alles noch geben kann - aber man sollte den Emulator auch irgendwie nicht überfrachten.
Finde er hat jetzt schon irre viele Einstellmöglichkeiten, wo man manchmal schon nicht weiss, was sich wie gegenseitig beeinflussen könnte.
Schau dir Emulatoren wie den WinUAE an, dagegen ist das noch harmlos im Denise.
Klar, neue Funktionen müssen einen Mehrwert haben und Sinn machen, sonst kann man sie sich natürlich sparen. Aber wenn sie das tun, sollte man sie auch mit reinnehmen und sie so gestalten, dass sie für die meiste Software gut anwendbar sind. Hier in dem Fall mit dem "automatischen WARP" geht es ja darum, wie eine Funktion arbeiten soll und nicht, ob man sie integriert oder nicht, denn sie ist ja eh schon da.
Für Neuanfänger können manche Emu's, wie eben WinUAE mit all seinen Einstellmöglichieiten, in der Anfangszeit dann natürlich etwas abschreckend wirken. Aber durch eigenes Rumprobieren und Lesen im Manual, kommt man dann auch recht schnell klar mit den ganzen Funktionen und später ist man froh, die Möglichkeiten zu haben. Und man muss ja auch nicht unbedingt alle Funktionen nutzen.
Daher wäre zu überlegen, ob es wirklich Sinn macht, wenn sich der automatische WARP auch bei einem späteren Nachladen in einem Spiel/Demo dann jedesmal wieder von selbst zuschaltet, oder ob das nicht mehr Verwirrung bei den Usern als Vorteile bringt.
Bei Demos ist das unstrittig, bei Spielen jedoch ist das sehr subjektiv und abhängig vom Nachlade-Verhalten. Beim ersten Spiel will ich nichts verpassen, später will ich schnell vorankommen und habe auch kein Problem wenn der Warp ein kurzes Knacksen am Level Anfang verursacht, wenn der Sound synchronisiert.
Ich ergänze eine Option, die den automatischen Warp nur ein einziges Mal aktiviert/deaktiviert und dann nie wieder. Zudem (ohne Option) wird der automatische Warp sofort deaktiviert, sobald der User den Warp Hotkey während der Emulation benutzt. Der automatische Warp steht dann erst nach einem Neustart wieder zur Verfügung.
Und natürlich kann man später den automatischen Warp mit den Device Traps kombinieren. Beide Techniken sind unabhängig von einander.
Ich ergänze eine Option, die den automatischen Warp nur ein einziges Mal aktiviert/deaktiviert und dann nie wieder.
Super, das wäre perfekt.
Den Warp abschalten, wenn game geladen ist...
geht erstmal nur um Tapes
In VICE funktioniert das gut mit simplen Kernal Load aber bei komplexen Loadern schaltet sich der Warp viel zu zeitig ab.
Vermutlich sobald der Motor das erste mal (nach dem searching/found) angehalten wird. Nur machen das einige Loader mehrfach für sehr kurze Zeit. Das bringt so nix.
Nun könnte man ziemlich aufwendige Tests fahren ob das Spiel noch lädt. Z.B. prüfen wieviel Zeit seit dem letzten Daten Eingang vergangen ist ... Aufwand/Nutzen
Meine Tendenz für Tapes ist, das jetzige Verhalten zu lassen und hierfür kein Warp on Autostart anzubieten. Soll heißen ist der automatische Warp aktiv, bestimmt die Motor Aktivität ob Warp an/aus.
Zudem sind Nachlade Aktionen bei Tapes nicht gerade kurz und sollte das Spiel nie nachladen, gibt es keinen Unterschied zu 'Warp on Autostart'.... aber den Vorteil, dass es immer funktioniert.
Auch bei Tapes stieß ich inzwischen schon auf Probleme, das klappt auch bei vielen nicht richtig mit dem automatischen WARP.
Welche ?
Den Warp abschalten, wenn game geladen ist...
geht erstmal nur um Tapes
Bei dem, was ich im Eintrag #1494 beschrieb, ging es mir jetzt vorwiegend erstmal um das Laden von Disks, weil ich damit schon im WinVICE meine Erfahrungen gesammelt habe in den letzten Jahren mit dessen automatischen WARP.
Da ich Tapes wesentlich seltener nutze und auch in der Vergangenheit immer viel seltener genutzt habe, kann ich nicht viel sagen im Bezug auf den Motor der Datasette und wie man dort dann den automatischen WARP am besten gestaltet, dass es für die meisten Tape Loader gut nutzbar ist. Hier habe ich fast überhaupt keine Erfahrungswerte wegen der seltenen Nutzung und hier kann man auch nicht so einfach sagen, wie bei Disks, wann der WARP sich genau von selbst wieder abschalten soll (wenn erstes File geladen). Bei Tapes passiert im Ladevorgang scheinbar mehr, bevor das erste File startet. Manchmal hält das Laden kurz an, dann gehts wieder weiter, dann kommt teils ein Bild des Spiels und er hält manchmal wieder an, dann gehts wieder weiter. Hier scheint alles komplexer als beim Laden von Disks und ein automatischer WARP viel schwerer anpassbar zu sein. Kommt mir zumindest so vor, nachdem ich heute mit circa 30 verschiedenen Tapes im Denise rumgetestet habe und den WARP beobachtete.
In VICE funktioniert das gut mit simplen Kernal Load aber bei komplexen Loadern schaltet sich der Warp viel zu zeitig ab.
Vermutlich sobald der Motor das erste mal (nach dem searching/found) angehalten wird. Nur machen das einige Loader mehrfach für sehr kurze Zeit.
Diese Problematik kann ich mir gut vorstellen. Das sind ja Sachen, die beim Laden von Disks so in der Form nicht anfallen. Daher auch mein Vorschlag, eventuell Disks und Tapes, im Bezug auf den automatischen WARP, getrennt einstellbar zu gestalten für den User, dann könnte notfalls individuell angepasst werden und unterschiedliche Einstellungen verwendet werden.
Meine Tendenz für Tapes ist, das jetzige Verhalten zu lassen und hierfür kein Warp on Autostart anzubieten. Soll heißen ist der automatische Warp aktiv, bestimmt die Motor Aktivität ob Warp an/aus.
Zudem sind Nachlade Aktionen bei Tapes nicht gerade kurz und sollte das Spiel nie nachladen, gibt es keinen Unterschied zu 'Warp on Autostart'.... aber den Vorteil, dass es immer funktioniert.
Klingt sinnvoll. Mangels jeglicher Erfahrung mit Sachen wie etwa der Motor-Aktivität einer Datasette (hatte selbst nie eine in real) und wie sich dazu der automatische WARP im VICE verhält oder sich am besten verhalten sollte, kann ich dazu überhaupt nichts sagen. Hab da im VICE bislang nie wirklich rumgetestet mit mehreren Tapes bislang und dabei den WARP beobachtet. Damit fing ich erst heute im Denise jetzt an. Wenn ich früher ab und an mal ein Spiel von Tape gespielt habe im VICE, kümmerte ich mich zumeist händisch per Hotkey selbst um den WARP, obwohl ich mir schon damals immer dachte, wäre ja cool wenn das auch perfekt automatisiet ablaufen würde. Scheinbar ist man hier aber bei Tapes mit mehr Problematiken konfrontiert, als ich es vorher erwartet hätte.
Auch bei Tapes stieß ich inzwischen schon auf Probleme, das klappt auch bei vielen nicht richtig mit dem automatischen WARP.
Welche ?
Zum Beispiel beim "Commando" Tape im Anhang. Der automatische WARP schaltet sich hier an Stellen des Ladevorgangs aus, wo man sich wundert, warum er das tut, denn man wartet dann lange, bevor es weitergeht. Vielleicht hat es auch mit der Art des Laders (Novaload) zu tun? Dieses Novaload verwenden einige Tapes, wie mir auffiel, die Problematik des automatischen WARP damit, ist dann scheinbar immer dieselbe.
Dann zum anderen Tape im Anhang, "Arkanoid". Hier steht nichts von Novaload, ich vermute es ist wieder eine andere Problematik. Auch hier schaltet sich anfangs der WARP kurz automatisch zu, dann gleich wieder ab, während die BASIC-Meldung "press play on tape / found Arkanoid" undsoweiter kommt. Dann schaltet er sich nach circa 15 Sekunden kurz wieder zu, dann aber gleich wieder ab und er bleibt dann aus, während sich ganz langsam das Intro-Bild aufbaut und langsam weitergeladen wird. Bis das Spiel dann letztendlich vollständig geladen ist, wartet man dann recht lange, es sei denn, man schaltet den WARP dann händisch per Hotkey wieder zu während das Introbild sich aufbaut.
Ich fand noch mehr Beispiele, wo es Probleme gibt, das waren jetzt erstmal zwei.
Hab eben nochmal genau geschaut, wie sich diese beiden Tapes im WinVICE verhalten, wenn dort "Autostart WARP" aktiviert ist. Dort laufen sie anfangs, wenn im BASIC die Meldungen "press play on tape / found ..." kommen, noch mit WARP-Speed durch, halten an der Stelle also den WARP nicht eine zeitlang an (im Gegensatz zu Denise). Aber dann, wenn bei dem einen Tape scheinbar das Novaload einsetzt und beim anderen das Intro-Bild erscheint, brechen sie dort ebenfalls den automatischen WARP ab, obwohl es besser wäre, an der Stelle schnell weiterzuladen. Scheint bei Tapes eine sehr komplexe Sache zu sein, das gut umzusetzen mit dem Auto-Warp, wann dieser immer anhalten soll und wann nicht. Wahrscheinlich lässt sich das auch nicht besser umsetzen beim Laden von Kassetten?
