C128 Erkennung (im C64 Modus)

Es gibt 19 Antworten in diesem Thema, welches 4.125 mal aufgerufen wurde. Der letzte Beitrag (28. April 2016 um 19:20) ist von LogicDeLuxe.

  • Hallo!

    Zur Zeit bastele ich an einer Erkennungsroutine für verschiedene CPU-Beschleuniger als da wären C128, SuperCPU und TC64, um z. B. im Interrupt außerhalb der Bilddarstellung die jeweilige Beschleunigung zu aktivieren. Für die SuperCPU und das TC64 existieren bereits Erkennungsroutinen, doch wie sieht es aus mit dem C128? Wie läßt sich ein C128 im C64-Modus erkennen? Mein erster Gedanke war, das Bit 6 in $1 (normal #$37 beim C64, aber #$77 beim C128) dafür heranzuziehen, doch meine ich mich zu erinnern, daß dieses Bit nicht immer gesetzt ist (Tastendruck o. ä. ?). Gibt es vielleicht noch ein anderes, sicheres Verfahren (z. B. Taktzyklenzählen bei abgeschaltetem IRQ und Bildschirm)?

    Und noch eine andere Frage nebenbei für die Besitzer eines TC64 (sorry): Was wäre die beste (sauberste) Möglichkeit, die Turbomöglichkeit des TC64 auszunutzen? a) Den Benutzer entscheiden lassen, welche Geschwindigkeit er will, oder b) den Turbomodus per $d030 im IRQ ein- und ausschalten wie beim C128, oder c) ???

  • nimm $d030. (bit 0)
    Das sollte beim c64 immer gesetzt sein. Beim c128 ist es normalerweise 0. Zumind. kannst du es löschen und setzen. (für 1mhz und 2mhz modus)

  • nimm $d030. (bit 0)
    Das sollte beim c64 immer gesetzt sein. Beim c128 ist es normalerweise 0. Zumind. kannst du es löschen und setzen. (für 1mhz und 2mhz modus)

    Ah, coole und einfache Möglichkeit. :thnks: Hatte früher nur einen C128, und da ist mir nie aufgefallen, daß das Bit auf dem C64 einen anderen Wert haben könnte. ^^

  • Aber das 2MHz-Bit kann doch auch vom TC64 emuliert werden, oder?
    Als C128-Erkennung gäbe es noch $d600 im I/O-Bereich: Beim 128er steht da nie Null drin, beim C64 normalerweise immer (Ausnahme: nach Schreibzugriff auf $d400 bleibt der Wert vier bis fünf Frames lang lesbar, und im 64er auch zu $d600 gespiegelt).

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Ah, die nicht vorhandenen gespiegelten Register müssten doch auch generell zur Detektion taugen, oder? Wenn man z.B. am C64 durch bepoken von $d50e ff. SID Stimme Bitte melde dich an, um diesen Link zu sehen. mit ner brauchbaren Wellenform/Hüllkurve startet, sollte sich das in Oscillator/Envelope Readoutregistern $d41b/$d41c irgendwie bemerkbar machen, beim C128 dagegen nicht.

  • Ich denke der VDC Chip bietet die sicherste Möglichkeit. Man kann da eine Zeichenfolge ins VDC-Ram schreiben und anschließend auslesen. Beim C128 sind die geschriebenen und gelesenen Byte Identisch, beim C64 nicht. Der VDC läßt sich nämlich auch im C64 Modus nutzen.

    Wem es beim Bit zählen schwindelig wird, der hat zuviel davon.

    Alt werden ist schön, das Altern nicht.

  • Gedöns.

    Code
    lda #0
            sta $d600
            lda $d600
            bne found_shiny_cool_c128
            ;found_plain_old_boring_64


    Dat schickt, Jung! :picard:

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Vielen Dank für die vielen Tips!

    Hab zunächst Rolands Variante ausgetestet, und sie scheint (zumindest in Vice) zu funktionieren, vorausgesetzt, man testet als erstes auf das TC64.
    Bleibt danm noch die Frage, wie man das TC64 am besten beschleunigt...

  • Bleibt danm noch die Frage, wie man das TC64 am besten beschleunigt...

    Wenn eine Beschleunigung auf etwa 600% völlig ausreicht, wie das z.B. bei Test Drive 2 der Fall ist, dann würde ich einfach die gleiche Routine wie für den C128 nehmen, und mit d030 im Rahmen beschleunigen. Das vereinfacht auf jeden Fall den Programmieraufwand, da man weniger Systeme unterscheiden muß.

  • Wenn eine Beschleunigung auf etwa 600% völlig ausreicht, wie das z.B. bei Test Drive 2 der Fall ist, dann würde ich einfach die gleiche Routine wie für den C128 nehmen, und mit d030 im Rahmen beschleunigen. Das vereinfacht auf jeden Fall den Programmieraufwand, da man weniger Systeme unterscheiden muß.


    Ah, okay... Wenn ich die Sache richtig verstehe, ist die Situation also wie folgt:

    1.) Das Register $d030 verhält sich beim TC64 genauso wie beim C128, d. h. das Bit 0 kann man setzen und löschen. Es wäre daher möglich, allein dieses Bit abzutesten, wie Roland es empfohlen hat, um sowohl die Beschleunigungsmöglichkeit für den C128 als auch für das TC64 zu erkennen.

    2.) Vorausgesetzt, der Benutzer des TC64 hat es vorab so eingestellt, läßt sich die Beschleunigung des TC64 wie beim C128 über die gleiche Routine gezielt ein- und ausschalten. (Der dadurch erzielte Geschwindigkeitszuwachs sollte ausreichen.)

    3.) Ist die Beschleunigung des TC64 während des Bildschirmaufbaus aktiviert, könnte es ähnlich wie bei der SuperCPU zum Flackern bei Splitscreens o. ä. kommen, da die Raster-IRQs im Verhältnis zum 1Mhz-Modus weniger Taktzyklen verbrauchen und dadurch z. B. VIC-Register zu früh gesetzt werden.

    Sollten diese Annahmen stimmen, wäre die Angelegenheit ja wirklich einfach. :rolleyes:

    Für den Fall, daß es hier Spezialisten gibt für das TC64:
    Im Programmierhandbuch zum TC64 habe ich nichts gefunden über die Registeradresse $d0bc, anhand derer man über Bit 7 eine SuperCPU erkennen kann. Dieses Register scheint vom TC64 gar nicht verwendet zu werden. Heißt das also, daß das Register wie beim normalen C64 stets ein gesetztes Bit liefert bzw. ist es sicher, zunächst mittels $d0bc auf das Vorhandensein der SuperCPU zu testen und anschließend $d030 abzufragen? Etwa so:

  • Es könnte auch interessant sein, das tc64 als tc64 über $d0fe und nicht über $d030 zu erkennen.

    Vorteile:
    - bei Erkennung muss nicht weiter geprüft werden, ob ein 128er vorhanden ist, da das tc64 nicht am 128er läuft.
    - man kann über den Konfigurationsmodus (Wert 42 8o in $d0fe schreiben) des tc64 über bestimmte Register den Turbo per Software einschalten und die Geschwindigkeit einstellen ($d0f3).

    Wenn der Konfigurationsmodus eingeschaltet ist, werden die Adressen von $d0f0 bis $d0ff als Register für die Konfiguration der Funktionen des tc64 eingeblendet. Insoweit sollte deine Frage bzgl $d0bc beantwortet sein (wird nicht vom tc64 verwendet).
    Bitte melde dich an, um diesen Link zu sehen.

    D.h., wenn das tc64 nicht über $d0fe erkannt wird, kann ein 128er über $d030 erkannt werden.

    ____________________________________
    Bitte melde dich an, um diesen Link zu sehen.

    Einmal editiert, zuletzt von TheRealWanderer (27. April 2016 um 23:02)

  • Hi TRW!

    Genau so eine Erkennungsroutine hatte ich im Code vorgeschaltet:

    Meine Überlegung war nun, daß ich die Beschleunigung auch beim TC64 allein über das Register $d030 steuern lasse, da ich dem Benutzer die Wahl lassen wollte, wie stark und ob überhaupt er eine Beschleunigung möchte. Daher wollte ich die Register $d0f0..$d0ff absichtlich unangetastet lassen. Und wie es aussieht, wäre der reine Erkennungscode für eine Beschleunigungsmöglichkeit für das TC64 identisch mit dem für den C128. Eine weitere Erkennung des TC64 (s.o.) bzw. eine weitere getrennte Behandlung im Programm könnte man dann sparen.

  • 1.) Das Register $d030 verhält sich beim TC64 genauso wie beim C128, d. h. das Bit 0 kann man setzen und löschen. Es wäre daher möglich, allein dieses Bit abzutesten, wie Roland es empfohlen hat, um sowohl die Beschleunigungsmöglichkeit für den C128 als auch für das TC64 zu erkennen.

    Für eine TC64-Erkennung ist diese Methode nicht geeignet, da man sich nicht darauf verlassen sollte, daß die d030-Funktion auch eingeschaltet ist. Man kann sie sowohl im Chameleon-Menü einschalten und auch als Default speichern, wie auch per Software konfigurieren. Von der Softwarekonfigurierung sollte man Gebrauch machen, nachdem man ein Chameleon mit der offiziellen Methode erkannt hat. Der Rest vom Programm kann sich den Code über d030 mit dem C128-Teilen. Prinzipiell ist eine spezielle C128-Abfrage gar nicht nötig, da man das Schreiben nach d030 nicht an Bedingungen knüpfen muß.

    3.) Ist die Beschleunigung des TC64 während des Bildschirmaufbaus aktiviert, könnte es ähnlich wie bei der SuperCPU zum Flackern bei Splitscreens o. ä. kommen, da die Raster-IRQs im Verhältnis zum 1Mhz-Modus weniger Taktzyklen verbrauchen und dadurch z. B. VIC-Register zu früh gesetzt werden.

    Register, die zu früh gesetzt werden, treten auch beim Chameleon auf. Wenn man den Turbo nur im Rahmenbereich aktiviert, hat man das Problem natürlich nicht, beschränkt aber halt die Geschwindigkeit auf ca. 600%, was je nach Verwendungszweck ausreichen kann.


    Den C64DTV hast Du bei den verfügbaren Turbos noch vergessen.

  • Für eine TC64-Erkennung ist diese Methode nicht geeignet, da man sich nicht darauf verlassen sollte, daß die d030-Funktion auch eingeschaltet ist. Man kann sie sowohl im Chameleon-Menü einschalten und auch als Default speichern, wie auch per Software konfigurieren. Von der Softwarekonfigurierung sollte man Gebrauch machen, nachdem man ein Chameleon mit der offiziellen Methode erkannt hat. Der Rest vom Programm kann sich den Code über d030 mit dem C128-Teilen. Prinzipiell ist eine spezielle C128-Abfrage gar nicht nötig, da man das Schreiben nach d030 nicht an Bedingungen knüpfen muß.

    Hmm... Also sollte das Programm am Benutzer vorbei selber die Beschleunigung aktivieren? Kann man natülich einbauen. jedoch hatte ich eigentlich nicht geplant, den Benutzer zu bevormunden, d. h. wenn der Benutzer sagt: Nö, ich will jetzt keine Beschleunigung, dann sollte die auch ausbleiben. Allerdings muß man dann auch irgendwie deutlich machen, daß er die Regelung über $d030 einschalten muß, wenn er Beschleunigung will.

    Wenn man den Turbo nur im Rahmenbereich aktiviert, hat man das Problem natürlich nicht, beschränkt aber halt die Geschwindigkeit auf ca. 600%, was je nach Verwendungszweck ausreichen kann.

    Genau das hatte ich vor. Sollte aber auch genügen. Bereits auf dem C128 (mit "nur" 2Mhz im Rahmen) bringt dies schon eine deutliche Beschleunigung.

    Den C64DTV hast Du bei den verfügbaren Turbos noch vergessen.

    Oh jemine... Noch so ein Gerät, von dem ich nur mal was gehört, aber keine Ahnung habe, wie es funktioniert. Ist das denn so weit verbreitet, daß sich eine gesonderte Behandlung lohnen würde (bei einem Disk-orientierten Spiel)?

  • Hmm... Also sollte das Programm am Benutzer vorbei selber die Beschleunigung aktivieren? Kann man natülich einbauen. jedoch hatte ich eigentlich nicht geplant, den Benutzer zu bevormunden, d. h. wenn der Benutzer sagt: Nö, ich will jetzt keine Beschleunigung, dann sollte die auch ausbleiben.

    Beim Chameleon kann man ja das d030-Bit einfach deaktivieren, und man muß den Code, der nach d030 schreibt, nicht ändern. Beim C128 läßt sich das allerdings nicht deaktivieren.
    Ich kenne allerdings kein Spiel, welches danach fragt, ob es d030 zwecks Beschleunigung nutzen soll. Die, die das können, machen es einfach.

    Allerdings muß man dann auch irgendwie deutlich machen, daß er die Regelung über $d030 einschalten muß, wenn er Beschleunigung will.

    Muß man nicht. Wie gesagt, kann man das direkt im Programm selbst machen, nachdem man ein Chameleon erkannt hat. Auch die Maximalbeschleunigung und "IEC sensitiv" kann man bei der Gelegenheit nach Bedarf einstellen, ohne daß sich der Anwender darum kümmern muß.


    Ist das denn so weit verbreitet, daß sich eine gesonderte Behandlung lohnen würde (bei einem Disk-orientierten Spiel)?

    Das ist auch wieder wahr. Obwohl es vom DTV schätzungsweise mehr gibt als TC64, wissen wohl die meisten nichtmal, daß man da Tastatur und Diskettenlaufwerke anschließen kann. Andererseits, wie viele haben wohl eine SCPU in Gebrauch?
    Zählt man Emulatoren mit, geht beides mittlerweile auch mit VICE.

  • Freaks, Ihr seit Freaks! :sm:


    Spectrum 128+, Disciple+3,5"
    Amiga500, 1200, 2000
    VIC 20, C-64. C-128, 1541, SD2IEC

    C64 Mini, C64Maxi, VIC20 Maxi,

    C64 Reload MK2

    Atari ST, Schneider CPC,

    MEGA65

    und über die diversen Spielekonsolen reden wir nicht!!! :rolleyes:


  • Ich kenne allerdings kein Spiel, welches danach fragt, ob es d030 zwecks Beschleunigung nutzen soll. Die, die das können, machen es einfach.

    Gutes Argument. ^^
    Okay, habe jetzt die Erkennung für das TC64, die SuperCPU und den C128. Und nun DTV... Tja... Was ich bislang herausgefunden habe, ist, wie man den Turbomodus beim DTV aktiviert:

    Code
    .byte	$32, $99		;	Akkumulator auf Register 9 setzen
    		lda	#3			;	Register 9 laden
    		.byte	$32, $00		;	Zurückschalten auf Standardakkumulator

    Aber gibt es auch eine kurze Möglichkeit, ein DTV zu erkennen? Alles, was ich bislang gefunden habe, war eine etwas aufwendige Routine von TLR: Bitte melde dich an, um diesen Link zu sehen.. Könnte bitte für den Fall, daß es doch viele Benutzer eines DTVs da draußen gibt, mir einer sagen, wie das möglichst kurz und schmerzlos funktioniert (DTV-Typ egal, Vorhandensein reicht)? Danke im voraus.

    Freaks, Ihr seit Freaks! :sm:

    Häh? Wieso? :gruebel

  • Super! Danke! :thnks: Dann hab ich jetzt (hoffentlich) alle Beschleunigungsmöglichkeiten beisammen. Jetzt gilt es, die passenden Routinen zur Aktivierung und Deaktivierung zu schreiben...

  • Und dran denken, $d03f wieder zurück zu setzen, wenn man die VIC-Register für normale C64-Farben nutzen will.
    Auch wichtig: bevor Du .byte $32, $99 machst, ist sicher zu stellen, daß dieser Teil nicht von einem Interrupt gestört wird.