Hallo Besucher, der Thread wurde 14k mal aufgerufen und enthält 106 Antworten
letzter Beitrag von WTE am
-
-
Na, da wäre es aber einfacher, das 2MHz-Bit auf Null zu POKEn und sofort per PEEK nachzusehen, ob es dann wirklich auf Null steht. Nicht-vorhandene VIC-Register sollten meines Wissens auf $ff stehen.
Das kapier ich sogar ! Also in der Adresse 53296 ?
Ich schalte eh mit Poke53296,0 oder Poke53296,1 um...Danke das ist gut !! Ich habe garade festgestellt, dass ich die Unterscheidung, ob es ein "Solo" C64 ist, eigentlich gar nicht brauche,
da der POKE 53296,1 oder 0 bei einem C64 (ohne 128er Modus) gar nichts schlimmes anrichtet, wenn nicht vorhanden, aber
natürlich andersrum, wenn ein C128 im Spiel ist , funktioniert...!Daher klappt nun alles.
Vielen Dank Euch !!
LG Cat
-
Aber unter welchen Vorbedingungen kann denn der obige Test in die Hose gehen?
- kurz vorher wurde etwas in den SID geschrieben
- bei $d600 ist etwas reingemapped das kein SID ist
Aber ein SID gibt doch bei Lesezugriffen auf Register Null immer Null zurück - für die "lda $d600"-Unterscheidung ist das sogar eine Grundvoraussetzung; sollte also daher kein Problem sein.
nö, probier mal:
der wert bleibt dafür das es ein "floating" register ist erstaunlich lange erhalten... so lange und so zuverlässig das es sogar diversen code gibt der sich darauf verlässt.
Aber wenn man jede nur denkbare obskure Hardwarebastelei berücksichtigen wollte, dürfte man eh keine brauchbare Software-Unterscheidung mehr hinbekommen.
prinzipiell richtig - wenn es allerdings eine möglichkeit gibt die funktioniert auch wenn obskure hardware verbastelt wurde, kann man die schon nehmen finde ich
Na, da wäre es aber einfacher, das 2MHz-Bit auf Null zu POKEn und sofort per PEEK nachzusehen, ob es dann wirklich auf Null steht. Nicht-vorhandene VIC-Register sollten meines Wissens auf $ff stehen.
jau, zb so -
der wert bleibt dafür das es ein "floating" register ist erstaunlich lange erhalten... so lange und so zuverlässig das es sogar diversen code gibt der sich darauf verlässt.
Vielen Dank für die Info. Ich wollte es natürlich schnell mal testen und hab mir ein bisschen Speedcode generiert, um möglichst schnell hintereinander das Register auszulesen (und eine Page mit den Ergebnissen vollzuschreiben).
Ergebnis: 2048 Zyklen reicht es locker. Ich musste das Testprogramm dann mehrfach ändern, weil es nie lange genug lief.
Insgesamt kam heraus: Der Inhalt bleibt vier bis fünf Frames lang erhalten!
-
hier ist das dazugehörige testprogramm: http://sourceforge.net/p/vice-…ee/testprogs/SID/bitfade/
-
den Cassettenpuffer (die ersten drei Bytes oder so werden vom DOS mißbraucht; $0b04-$0bff)
Achtung bei einigen DOS-Befehlen, da werden die ersten paar Bytes überschrieben.
Ist mir früher nie aufgefallen (mehrere eigene Programme nutzen diesen Speicher), daher hab ich eben noch mal kurz das ROM-Listing durchgescannt, sowohl nach $0bXX als auch nach der Adresse des Kassettenpuffer-Zeigers. Aber abgesehen vom BOOT-Befehl und den Kassettenroutinen habe ich nichts gefunden. Woher hast Du die Info mit den DOS-Befehlen?Der einzige mir bekannte Schreibzugriff des Systems - abgesehen vom Laden des Bootblocks natürlich - ist das Schreiben von "0:" vor den im Bootblock angegebenen Dateinamen. Da das aber vom BOOT-Befehl gemacht wird, und dieser ja eh erst den Bootblock lädt, sehe ich es nicht als Problem an.
-
Ich weiß es jetzt auch nicht mehr genau. Vielleicht DLOAD oder RUN mit Dateiname. Jedenfalls hatte ich die "Zerstörung" bei meinen MySoft-Programmen beobachtet. Entweder beim Nachladen (Overlay) oder beim Programmwechsel. Danach waren die ersten Bytes der Routine bei $b00 perdü. Vielleicht nur ein Verhalten des ersten ROMs im 128D Plastik, das später korrigiert wurde? Ist schon alles lange her. Müsste man mal prüfen, aber nicht heute.
