Nachdem starten von Denise wähle ich Softwareladen, dann wird ein X-beliebiges File ausgewählt, nachdem Doppelklick auf das File wird einfach nur ein Reset ausgeführt.
Und das passiert dann aber nicht mit dem Standard Kernel ?
Es gibt 2.909 Antworten in diesem Thema, welches 469.192 mal aufgerufen wurde. Der letzte Beitrag (
Nachdem starten von Denise wähle ich Softwareladen, dann wird ein X-beliebiges File ausgewählt, nachdem Doppelklick auf das File wird einfach nur ein Reset ausgeführt.
Und das passiert dann aber nicht mit dem Standard Kernel ?
Hier mal ein Bild davon.
Bitte melde dich an, um diesen Anhang zu sehen.
Überschneidung der Antwort ja mit dem Standard-Kernal und meinen Kernal ohne DEC/INC passiert das nicht.
Ok nachgestellt. Es ist ein Autostart Problem im Zusammenhang mit deinem Kernal. Beim normalen Start und manuellem Load + Play Tape funktioniert es. (also mit deinem Kernal)
Ich vermute die Warte Zeit im Bootvorgang ist anders als beim Standard Kernel und ich habe es sehr knapp eingestellt. Ich teste kurz durch.
Beim normalen Start und manuellem Load + Play Tape funktioniert es.
Ja die Routine ist etwas langsamer durch DEC/INC und bestätigt meine Vermutung, da es ohne DEC/INC keine Probleme gibt mit dem Kernal.
Die für den Autostart nötigen Check Routinen funktionieren mit diesem Kernel nicht, z.B.
wird im Bildschirmspeicher nach 2.2 Sekunden 'R', 'E', 'A', 'D', 'Y', '.' gesucht. spielt keine Rolle ob ich es nach z.B. 3 Sekunden versuche, gleiches Problem
Wenn beim Standard Kernel der erwartete Buchstabe z.b. der erste Buchstabe von Ready, also R noch nicht gefunden wurde, ist das ok (wartet also länger) aber es muss 32 an der Position stehen.
Bei diesem Kernal ist das nicht so. Sobald ich diese Prüfung rausnehme, funktioniert es. Jetzt ist die Frage, ob ich damit was kaputt mache.
Bei diesem Kernal ist das nicht so. Sobald ich diese Prüfung rausnehme, funktioniert es. Jetzt ist die Frage, ob ich damit was kaputt mache.
Kann man evtl. was machen mit Prüfung: IRQ enabled und PEEK($CC)=0 (Flag für Cursor blinkt)?
Kann man evtl. was machen mit Prüfung: IRQ enabled und PEEK($CC)=0 (Flag für Cursor blinkt)?
Blinking Cursor Check an/aus macht keinen Unterschied.
for( int i = 0; i < buffer.size(); i++) {
if (ram[adr + i] != (buffer[i] & 63) ) {
if (ram[adr + i] != 32) {
// return Found::No;
}
return Found::NotYet;
}
}
Ich werde wohl den Check deaktivieren, siehe auskommentierte Zeile. Ich muss nur alle Autostart Varianten durchtesten, die ganzen Freezer Carts und Fast Load Carts. ... stöhn
Ich werde wohl den Check deaktivieren, siehe auskommentierte Zeile. Ich muss nur alle Autostart Varianten durchtesten, die ganzen Freezer Carts und Fast Load Carts. ... stöhn
Eben. Beim Freezer, wo der Cursor nicht blinkt, könnte das einen Unterschied machen. Denke gerade an AR/RR, wo man einen Startbildschirm mit Menü hat ohne blinkenden Cursor, aber dem Anschein nach einen IRQ (die Tastaturabfrage wird wohl auch da im IRQ sein?!).
Aber kann schon sein, dass es am Ende keinen Unterschied macht.
Beim Prüfen ist mir aufgefallen, dass dein Kernel nicht mit Retro Replay zurecht kommt. F7 Fastload crasht.
Ich werde wohl den Check deaktivieren, siehe auskommentierte Zeile. Ich muss nur alle Autostart Varianten durchtesten, die ganzen Freezer Carts und Fast Load Carts. ... stöhn
Ist das nicht riskant, wegen eventuell dadurch wieder hineinkommender Inkompatibilitäten? Und das nur für einen Fremd-Kernel? Jetzt läuft alles super und wurde auch vieles getestet, da weiss man jetzt, dass alles klappt.
Vielleicht dann lieber einmal eine gemoddete Version, speziell für ihn damit er seinen Kernel damit nehmen kann und die offizielle Version so belassen?
Solang dieser Kernal nicht aus sinnvoll nutzbaren Gründen der Öffentlichkeit bereitgestellt wird, würde ich in diesem Fall AW182 beipflichten.
Ist das nicht riskant, wegen eventuell dadurch wieder hineinkommender Inkompatibilitäten? Und das nur für einen Fremd-Kernel? Jetzt läuft alles super und wurde auch vieles getestet, da weiss man jetzt, dass alles klappt.
Erstmal ist dies unabhängig von der geladenen Software, nur vom Kernal Verhalten.
Ich muss also den Standard Kernal, diesen Kernal und ein paar Speeder Kernals darauf testen, dass diese mit Disks, Tapes, Carts korrekt auto starten.
Die ersten Tests liefen problemlos.
Ist das nicht riskant, wegen eventuell dadurch wieder hineinkommender Inkompatibilitäten?
Da liegt ein kleines Missverständnis vor, der Kernal ist nicht als Ersatz gedacht. Es geht allein darum, das dieser nicht mit Denise läuft, das liegt aber nicht am Kernal. Wobei das nicht ganz stimmt, der Kernal läuft eigentlich ganz normal, solange man die Emulation nicht verlässt.
Es geht allein darum, das dieser nicht mit Denise läuft, das liegt aber nicht am Kernal.
Du meinst er lässt sich nicht in Kombination mit Autostart verwenden ? Mit Autostart führt der Kernal keinen zusätzlichen Reset aus, es werden lediglich die Autostart Kommandos nicht ausgeführt oder hast du was anderes im Sinn ?
Ich meine mit Autostart, Doppelklick auf ein File, dann macht Denise nur einen Reset. Wähle ich stattdessen Einlegen und drücke auf ″Ausgewähltes Programm in den Speicher übertragen″, startet das Programm.
Ich meine mit Autostart, Doppelklick auf ein File, dann macht Denise nur einen Reset. Wähle ich stattdessen Einlegen und drücke auf ″Ausgewähltes Programm in den Speicher übertragen″, startet das Programm.
Ok, ich dachte für einen Moment du meinst was anderes.
Ist im neuesten nightly gefixt. Einfach das jüngste nightly verwenden, unabhängig von der Benennung. Dort ist noch ein anderer Commit enthalten, der einen Anzeige Bug fixt.
Ich habe viele Autostart Situationen getestet ohne ein neues Problem zu entdecken, Freezer, Floppy Speeder, Modul Speeder.
Da liegt ein kleines Missverständnis vor, der Kernal ist nicht als Ersatz gedacht. Es geht allein darum, das dieser nicht mit Denise läuft, das liegt aber nicht am Kernal. Wobei das nicht ganz stimmt, der Kernal läuft eigentlich ganz normal, solange man die Emulation nicht verlässt.
Das war von mir so gemeint, dass es riskant sein könnte, wenn PiCiJi nun, nur damit dein Fremdkernel auf dem Denise läuft, etliches dort ändert, was ja nie ein Problem gemacht hatte und sich ja immer bewährt hatte. Er schrieb ja, er müsse nun dann alle Autostart Varianten erneut wieder durchtesten, dann die ganzen Freezer Cartridges und Fastload Carts usw und schauen, ob alles noch fehlerfrei funktioniert, weil er diesen Check im Denise nun deaktivieren muss, der mit allen anderen Kernels aber ganz normal funktioniert. Da frage ich mich, ob sich das lohnt und man das Risiko eingehen soll, oder ob es nicht besser wäre, dir eine gepatchte Version des Denise zur Verfügung zu stellen für deinen Kernel und die normale Denise Version so zu belassen wie sie ist, um sich eventuelle Inkompatibilitäten zu ersparen?
Kernal läuft jetzt, aber woran lag es denn jetzt genau.
Kernal läuft jetzt, aber woran lag es denn jetzt genau.
Beim Autostart wird der Bildschirmspeicher überwacht, z.B. geprüft wann READY. enthalten ist. Daraufhin werden die Load Kommandos in den Speicher injiziert.
Im alten Code wurde an den Positionen im C64 Arbeitsspeicher wo Byte für Byte nach READY gesucht wird, erwartet das zumindest der Platzhalter 32 (Leerzeichen) enthalten ist.
R oder Leerzeichen, E oder Leerzeichen, usw. Alle anderen von mir getesteten Kernels tun dies.
Dein Kernal setzt dort aber kein Leerzeichen als Platzhalter. Ich habe nicht geschaut, was dort steht. Das soll auch nicht davon abhängig sein. Aus diesem Grund wird nun kein Platzhalter Zeichen mehr erwartet.
Es wird also so lange geprüft, bis die gesuchte Zeichenkette im Speicher erscheint oder ein timeout erreicht wird.