Die Versionsnummer beim Retrace stimmt auch nicht. 
Hallo Besucher, der Thread wurde 305k mal aufgerufen und enthält 2322 Antworten
letzter Beitrag von Omega am
TSB Info
- GoDot
- Unerledigt
-
-
Mir ist aufgefallen, das auf der TSB Disk im Programm "check-detect.dmo" Zeile 760 einen Syntax Error wirft
Da fehlen hinter Color die Parameter.
-
Da fehlen hinter Color die Parameter.
Stimmt. Das war früher möglich (erzeugte einen schwarzen Bildschirm). Ist aber rausgefallen, da muss jetzt COLOR 0,0 hin. Werde ich korrigieren!
Arndt
-
Die Entdeckung von dmantione ist hier sicher gut zur weiteren Verfolgung aufgehoben.
Ich habe herausgefunden, warum Pupu nicht ist kompatibel mit dem Final Cartridge III. Ich untersuche das gerne, um eventuelle Fehler dan in der FC3 101%-firmware zu beheben. Die sache hier kann leider nicht von Seiten des FC3 gelöst werden.
Die Ursache für die Inkompatibilität ist die Lokation der Tuned Simons BASIC IRQ-handler: $847B. Wenn das ROM des FC3 sichtbar ist ($8000..$BFFF) und ein Interrupt auftritt, stürzt der C64 ab. Es ist für den FC3 untunlich, Interrupts immer zu deaktivieren, wenn das ROM sichtbar ist, so dass die Position des IRQ-handlers zu Problemen führt.
Das deaktivieren der BASIC-erweiterungen des FC3 reicht nicht, der Fastloader und die Druckerinterface bleiben aktiv und machen das ROM sichtbar. Der Fastloader arbeitet größtenteils mit ausgeschalteten Interrupts, so dass die Chance, das LOAD/SAVE zu stören, gering ist. Die Druckerinterface hingegen hat BSOUT umgeleitet, und das FC3-ROM bleibt sichtbar, während das KERNAL das BSOUT ausführt. Die Chance dass während der Bildschirmausgabe ein IRQ auftritt, ist also hoch und führt dann sofort zum Absturz.
Ich rechne damit, daß noch mehr Cartridges Probleme haben werden, das ist nicht nur bei der FC3 der Fall, obwohl eine reine Fastloader-Cartridge eher dazu neigt, Interrupts zu deaktivieren, wenn sie aktiv wird.
Da Simons BASIC als Cartridge konzipiert ist, ist die Wahl von $847B für den IRQ-handler verstehbar. Wie es bei Pupu als RAM-basierte BASIC-erweiterung eingesetzt wird, ist diese Platz keine glückliche Wahl. -
Die Entdeckung von dmantione ist hier sicher gut zur weiteren Verfolgung aufgehoben.
Hatte ich schon gelesen. Bin mir aber nicht ganz sicher, was er damit sagen will. Das Problem ist nicht TSB (bzw. irgendeine Basic-Erweiterung), sondern der Freezer. Wenn dort (vielleicht wahlweise) sinnvoll mit einem vorhandenen IRQ umgegangen würde, gäbe es nämlich kein Problem. Leider übernimmt so ein Freezer das System bruteforcemäßig eben komplett, ohne sich um die Feinheiten zu bemühen (ist ja auch der eigentliche Sinn eines Freezers). Warum es allerdings "untunlich ist, den IRQ im FC3 abzuschalten", weiß ich nicht. Wenn es doch geht, warum macht man es nicht? TSB jedenfalls steht fest auf dem Boden des Commodore-IO-Handlings, es verwendet nur Kernalroutinen, eben wegen der Kompatibilität.
Arndt
(Bitte keine Diskussion über Sinn oder Unsinn eines Freezers lostreten!)
-
-
Hatte ich schon gelesen. Bin mir aber nicht ganz sicher, was er damit sagen will. Das Problem ist nicht TSB (bzw. irgendeine Basic-Erweiterung), sondern der Freezer. Wenn dort (vielleicht wahlweise) sinnvoll mit einem vorhandenen IRQ umgegangen würde, gäbe es nämlich kein Problem. Leider übernimmt so ein Freezer das System bruteforcemäßig eben komplett, ohne sich um die Feinheiten zu bemühen (ist ja auch der eigentliche Sinn eines Freezers). Warum es allerdings "untunlich ist, den IRQ im FC3 abzuschalten", weiß ich nicht. Wenn es doch geht, warum macht man es nicht? TSB jedenfalls steht fest auf dem Boden des Commodore-IO-Handlings, es verwendet nur Kernalroutinen, eben wegen der Kompatibilität.
Das hat nichts mit dem Freezer und nichts mit Bruteforce zu tun. Die KERNAL-Vektoren in $0300 verweisen einfach auf den IO-Bereich in $DE00. Einschließlich LOAD/SAVE/BASIN/BASOUT. Interrupts sollten nur für kurze Zeit deaktiviert werden. Wenn Interrupts für längere Zeit deaktiviert werden, führt dies zu Problemen, z.B. das Einschalten des Kassettenmotors, sobald man PLAY drückt, erfolgt über den Interrupt-Handler auf $EA31. Wenn du dann einen Interruptvektor bei $847B habt, während der Tapespeeder PRESS PLAY ON TAPE auf dem Bildschirm anzeigt, kann man Probleme erwarten.
-
Ich dachte jetzt primär nur an den Nutzen des Fastloaders bei der FC3, der ja bei so Kloppern wie PUPU was bringen würde.
Ich hab Simons' Basic auf Modul und wir haben damals gut mit "rumgespielt" - ein Fastloader war uns da wohl noch nicht soo wichtig gewesen. Bei größeren Programmen hatte ich in frühen Tagen "Megafast" reingeladen und als ich dann SpeedDOS hatte, war SB nicht mehr ganz so angesagt, aber das läuft ja eh zusammen.
Wie wäre es, wenn du bei TSBneo ein Fastload nachrüstest?
-
Wie wäre es, wenn du bei TSBneo ein Fastload nachrüstest?
Ich verstehe ja eigentlich nichts davon. Aber ich kenne die Antwort: Kein Platz!
-
-
Ich würde in Erwägung ziehen, während der TSB-Initialisierung mit einem JSR $FF8A eine möglich anwesige Schnellladecartridge zu deaktivieren. Ich denke das eine Koexistenz machbar ist, aber dann muss der IRQ doch verschoben werden, und dann scheint mir der $C000-Bereich am naheliegendsten zu sein.
-
Wenn die FC3 das System übernimmt (ROM einblendet), sollte sie auch dafür sorgen dass das kompatibel abläuft.
Wenn es um diese Stelle im ROM geht
Die könnte man doch auch im ROM unterbringen und dann mit abgeschaltetem IRQ das machen was auch immer das FC3 macht und am Ende wieder den IRQ freigeben, wenn er
-
Wenn die FC3 das System übernimmt (ROM einblendet), sollte sie auch dafür sorgen dass das kompatibel abläuft.
Ich stimme das im Prinzip zu, aber die C64-Architektur zeigt hier ihre Grenzen auf. Dies ist kein FC3-spezifisches Problem, alle Utility-Cartridges funktionieren auf diese Weise. Letztlich sind zwei Parteien erforderlich, um Software kompatibel zu machen. Leider, aber wahr.
Wenn es um diese Stelle im ROM geht
Die könnte man doch auch im ROM unterbringen und dann mit abgeschaltetem IRQ das machen was auch immer das FC3 macht und am Ende wieder den IRQ freigeben, wenn er
Wenn das das einzige Problem wäre, würde ich diese wenigen Bytes allerdings in den Cartridge-Speicher verschieben. Bedenken aber auch, dass PRESS PLAY ON TAPE durch RUN/STOP unterbrochen werden kann. Werden wir auch die Tastaturscan nach Cartridgespeicher verschieben und umschreiben ohne IRQs zu funktionieren?
Und das ist nur das Beispiel von PRESS PLAY ON TAPE, der FC3 hat viel mehr Funktionalität. All diese Funktionen ohne Interrupts zum Laufen zu bringen ist untunlich, abgesehen von der Tatsache, dass ich gerne einige Kompatibilitätskorrekturen einfüge, die Änderung des gesamten Designs wird eine andere Sache werden.
-
Wenn die FC3 das System übernimmt (ROM einblendet), sollte sie auch dafür sorgen dass das kompatibel abläuft.
Ich stimme das im Prinzip zu, aber die C64-Architektur zeigt hier ihre Grenzen auf. Dies ist kein FC3-spezifisches Problem, alle Utility-Cartridges funktionieren auf diese Weise. Letztlich sind zwei Parteien erforderlich, um Software kompatibel zu machen. Leider, aber wahr.
Dann bedeutet das, das die FC3 zu Programmen inkompatibel ist die einen IRQ zwischen $8000 - $BFFF haben oder umgekehrt.
Alles anzeigen
Wenn es um diese Stelle im ROM geht
Die könnte man doch auch im ROM unterbringen und dann mit abgeschaltetem IRQ das machen was auch immer das FC3 macht und am Ende wieder den IRQ freigeben, wenn er
Wenn das das einzige Problem wäre, würde ich diese wenigen Bytes allerdings in den Cartridge-Speicher verschieben. Bedenken aber auch, dass PRESS PLAY ON TAPE durch RUN/STOP unterbrochen werden kann. Werden wir auch die Tastaturscan nach Cartridgespeicher verschieben und umschreiben ohne IRQs zu funktionieren?
Und das ist nur das Beispiel von PRESS PLAY ON TAPE, der FC3 hat viel mehr Funktionalität. All diese Funktionen ohne Interrupts zum Laufen zu bringen ist untunlich, abgesehen von der Tatsache, dass ich gerne einige Kompatibilitätskorrekturen einfüge, die Änderung des gesamten Designs wird eine andere Sache werden.
Ich verstehe, dass ich nicht genug weiss was das FC3 macht und zur Verfügung stellt.
Aber das Action Replay6, das nutze ich gerne, hat keinerlei Probleme mit Pupu. Eben nochmal getestet. Irgendwie handhaben die das anders.
Das AR6 ist doch vergleichbar mit FC3 oder nicht?
-
und dann scheint mir der $C000-Bereich am naheliegendsten zu sein.
Dort liegen Grafik-Videoram, eine Tabelle der PROC-Adressen, TSB-Variablen, die F-Tastebelegung und jede Menge Code. Nicht machbar.
Arndt -
Dann bedeutet das, das die FC3 zu Programmen inkompatibel ist die einen IRQ zwischen $8000 - $BFFF haben oder umgekehrt.
Ich weiß nicht was du mit "umgekehrt" meint, aber eine Kombination aus einem Interrupt bei $8000..$bfff und der Verwendung von KERNAL für I/O erscheint mir hier problematisch. In dieser Hinsicht ist diese Sitzung auch ein Lernprozess für mich, da ich das selbst noch nicht wusste.
Aber das Action Replay6, das nutze ich gerne, hat keinerlei Probleme mit Pupu. Eben nochmal getestet. Irgendwie handhaben die das anders.
Das AR6 ist doch vergleichbar mit FC3 oder nicht?
So wie ich das sehe, ist der AR6 auch nicht kompatibel, aber... der AR6 hat keine Druckerschnittstelle und während des Ladens selbst sind Interrupts deaktiviert. Damit ist die Wahrscheinlichkeit, dass der AR6 einen Interrupt zur falschen Zeit bekommt, viel geringer, und sobald Pupu gestartet ist... wird der Fastloader nicht mehr benutzt.
Beim FC3 sorgt die Druckerschnittstelle dafür, dass das Cartridge-ROM bei viel mehr Aufrufen sichtbar gemacht wird. Nicht nur während des Ladens, sondern auch während des laufenden Spiels.
Beim AR6 besteht also die Möglichkeit eines Absturzes, beim FC3 die Gewissheit eines Absturzes.
-
Dort liegen Grafik-Videoram, eine Tabelle der PROC-Adressen, TSB-Variablen, die F-Tastebelegung und jede Menge Code. Nicht machbar.
OK, gut, das ist ein Teil des Lebens mit dem C64. Nicht alles ist möglich.
-
Dann bedeutet das, das die FC3 zu Programmen inkompatibel ist die einen IRQ zwischen $8000 - $BFFF haben oder umgekehrt.
Ich weiß nicht was du mit "umgekehrt" meint
Mit "umgekehrt" meinte ich, das die FC3 zu solchen Programmen (mit IRQ im ROM Bereich) inkompatibel ist oder man sieht es von der anderen Seite. Solche Programme sind inkompatibel zur FC3.
Ist der Quellcode der FC3 frei einsehbar? Ich bin nur neugierig.
-
Ist der Quellcode der FC3 frei einsehbar? Ich bin nur neugierig.
Jasicher:
https://github.com/dmantione/final_cartridge/
Der Originalcode befindet sich im Master-branch, meine verbesserte FC3 101%-Firmware im Development-branch. Die Handler für die $0300-Vektoren, die auf $DE00 zeigen, finden sich in persisent.s. Diese machen das ROM sichtbar und springen dann in die richtige Routine. Der Fastloader in speeder.s, die Druckerschnittstelle in printer.s und die BASIC-Erweiterungen in basic.s.
