Hello, Guest the thread was viewed2k times and contains 24 replies

last post from LogicDeLuxe at the

In the beginning there was JMP ($FFFC), aber warum eigentlich?

    Wenn man den C64 einschaltet, dann beginnt der Prozessor ja damit, in $FFFC und $FFFD die Startadresse des ersten Befehls auszulesen und dann dort Assembler-Befehle auszuführen. Technisch gesehen ist das einfach ein JMP ($FFFC) und wenn man VICE glauben darf, dauert das auch ganze fünf Taktzyklen (genauer: Der erste Befehl beginnt im VICE in Taktzyklus 6), also genau so lange, wie so ein indirekter Jump dauert.


    Jetzt ist nur die Frage: Woher weiß der 6510, dass er da anfangen soll? Ist das auf dem Chip irgendwo hardcodiert? Mir wäre nichts dergleichen bekannt, aber das heißt nichts, komplett hab' ich mir den Schaltplan dazu noch nicht angeschaut.


    Oder kommt das irgendwie von außen? Hat da etwa der VIC schon wieder seine Hände im Spiel?!?


    Kann da jemand sachdienliche Hinweise liefern?

    Intern hat der 6510/6502 eine State Machine (deren Transitionsmatrix intern durch die "PLA" realisiert ist, nicht zu verwechseln mit dem PLA-Chip des C64, der was ganz anderes macht). Der PLA-Teil ist mehr oder weniger der Mikrocode der CPU, und nach dem Einschalten läuft die "bei Null" los. Dort bzw. in den angesteuerten anderen Teilen der CPU ist dann $FFFC hartkodiert. Es wird eher so eine Art BRK-Variante ausgeführt beim Start.


    Der VIC hat damit nichts zu tun, der hat nichtmal eine Reset-Leitung. Abseits vom RAM-Refresh, Taktgenerierung und CAS/RAS-Handling würde ein C64 auch ohne VIC-II funktionieren.


    Zum Abgleich:

    VHDL: https://github.com/Steve-Teal/mx65/blob/main/mx65.vhd (siehe "reset_reg" und "ir")

    C-Code: https://github.com/floooh/chip…9cdfbf/chips/m6502.h#L772

    Quote from 1570

    Dort bzw. in den angesteuerten anderen Teilen der CPU ist dann $FFFC hartkodiert. Es wird eher so eine Art BRK-Variante ausgeführt beim Start.

    Wenn ich das jetzt richtig verstehe ist es ein BRK ohne den ersten Taktzyklus, weil der Befehlscode (#$00) ja schon da ist. Und der wird auch noch ein bissl anders ausgeführt, aus Gründen, die ich noch nicht ganz verstanden habe, aber vermutlich, weil irgendwelche externen Leitungen (RESET?) einen anderen Wert haben, als sonst.


    Das sind dann also 6 statt der oben vermuteten 5 Taktzyklen. Aber das passt mit dem VICE auch gut zusammen, weil der dann halt bei 0 und nicht bei 1 mit dem Zählen anfängt.


    Muss mir also beim Prozessor mal im Detail angucken, was bei BRK so passiert. Vielleicht finde ich die $FFFC dort ja irgendwo. :)

    Quote from Thunderblade

    Der VIC hat keine Reset-Leitung, trotzdem macht der Kernal sehr früh einen STA $D016, angeblich um per VIC den RAM-Refresh zu aktivieren. Habe ich noch nie verstanden und ist mir bis heute ein Rätsel warum der Kernal das tut...

    Der Kernal macht da auch noch andere Sachen, die seltsam erscheinen. Beispielsweise wird $2A6 (PAL/NTSC) ausgelesen, bevor es geschrieben wird. Das sollte meiner Ansicht nach bei einem NTSC-C64 zu einer falsch gehenden Jiffy-Clock führen. (Und wie der den Wert später durch das VIC-Register ermittelt ist mir auch noch ein Rätsel.)

    Quote from Thunderblade

    Der VIC hat keine Reset-Leitung, trotzdem macht der Kernal sehr früh einen STA $D016, angeblich um per VIC den RAM-Refresh zu aktivieren. Habe ich noch nie verstanden und ist mir bis heute ein Rätsel warum der Kernal das tut...

    Man könnte ja mal ein ROM machen, wo das ausgelassen wird und mit den verschiedenen VIC-Revisions testen, ob es dann zu echten Problemen kommt, oder ob das doch nur ein Placebobefehl ist.

    Wird das denn in sämtlichen Ultimax-Modulen auch gemacht, weil die per Design C64-tauglich sein sollen?

    Es geht um FCEF 8E 16 D0 STX $D016? Das wird ja schon bei normalen Modulen (bei $8000) nicht mehr ausgeführt.


    Also das Gold Quest 6-Cartridge beschreibt D016 erst ziemlich spät nach Dekomprimieren von einigem Krams (rund 240ms nach CPU-Start) und hat kein Problem. FCEF wird wohl irgendein Artefakt sein. Da wird u.a. der Offset, bei dem die Modulkennung nicht mehr stimmt, in das X-Scroll-Register geschrieben - vielleicht hat das jemand zum Debugging benutzt...

    Der Originalkommentar laut C64 BASIC & KERNAL ROM Disassembly lautet "SET UP REFRESH (.X=<5)".


    Der Programmierer war sich also im Klaren darüber, dass X<=5 ist (und nicht unbedingt exakt bekannt). Das "set up refresh" klingt ja schon auch ein bisschen so, als würde damit versucht, den RAM-Refresh anzuschieben. Oder könnte es ein anderes Refresh sein?!? :huh:


    Vielleicht war es ja auch einfach so, dass man damals geglaubt hat, dass man einen RAM-Refresh anschieben muss, das in Wirklichkeit aber gar nicht nötig ist? Ich glaube, dazu müsste man sich die Innereien des VIC genauer anschauen.

    Der VIC-Artikel sagt dazu "The RES bit (bit 5) of register $d016 has no function on the VIC 6567/6569 examined as yet. On the 6566, this bit is used to stop the VIC". Der 6566 (NTSC) wurde in der MAX Machine verbaut. Vermutlich wollte man so sicherstellen, dass der 6566 nach dem Reset auch überhaupt läuft - bzw. am Bus lauscht er offensichtlich sowieso immer, aber die (simple) State Machine im 6566 kann wohl angehalten werden, und die kümmert sich auch um RAM Refresh.


    Gibt auch eine Diskussion in der CSDb zu.

    Zwischen Max Machine und C64-Kernal sehe ich eigentlich keinen Zusammenhang.

    Evtl. muß man zum Prototyp VIC-40 zurück schauen, denn der wird im Original-Quelltext zur Revision 1 erwähnt:

    Code
    1. ;***************************************
    2. ;* PET KERNAL *
    3. ;* MEMORY AND I/O DEPENDENT ROUTINES *
    4. ;* DRIVING THE HARDWARE OF THE *
    5. ;* FOLLOWING CBM MODELS: *
    6. ;* COMMODORE 64 OR MODIFED VIC-40 *
    7. ;* COPYRIGHT (C) 1982 BY *
    8. ;* COMMODORE BUSINESS MACHINES (CBM) *
    9. ;***************************************

    Höchstwahrscheinlich ist dieses Bit nicht nur beim 6566 sondern auch beim 6562/3 relevant.

    Quote from 1570

    Gibt auch eine Diskussion in der CSDb zu.

    Dort auch der Einwand, daß der Stack bereits beim Modultest verwendet wird. Ich frage mich, warum das überhaupt eine Unterroutine ist, insbesondere, wenn man doch von einer RAM-Problematik ausgeht. Die Modulabfrage hätte man doch direkt hinter das CLD setzen können.

    Quote from berni

    Beispielsweise wird $2A6 (PAL/NTSC) ausgelesen, bevor es geschrieben wird. Das sollte meiner Ansicht nach bei einem NTSC-C64 zu einer falsch gehenden Jiffy-Clock führen.

    Schau es dir genauer an: Er greift zweimal darauf zu, einmal vor dem Setzen, einmal danach.



    Quote from berni

    Und wie der den Wert später durch das VIC-Register ermittelt ist mir auch noch ein Rätsel.

    Beim Initialisieren des VIC-II (durch eine Tabelle im ROM) wird die Zeile, bei der ein Interrupt ausgelöst werden soll, auf 311 gesetzt.

    Hintergrund: Ein PAL-VIC-II (6569) hat 312 Rasterzeilen, ein NTSC-VIC-II (6566/6567) nur 262 bzw. 263, je nach Revision.


    Zum Testen wartet die Routine per busy-waiting, bis die Rasterzeile 0 im VIC-II erreicht ist. Dann wird getestet, ob das IRQ-Flag für die Rasterzeile ausgelöst wurde. Falls ja, dann gibt es eine Zeile 311, also ist es ein PAL-VIC-II. Falls nein, dann muss es ein NTSC-VIC-II sein.

    Quote from berni

    Oder kommt das irgendwie von außen? Hat da etwa der VIC schon wieder seine Hände im Spiel?!?

    Wieso sollte der VIC da maßgebend sein, in einem System, das prima auch ohne auskommt?

    Das Reset-Verhalten ist rein CPU-intern und funktioniert ja in einer 1541 auch, und da ist kein VIC verbaut.

    Kann man durch reines Überlegen ganz einfach rausfinden.


    Nein, der 6510 "macht das nicht anders", das ist ein 6502-Kern mit ein paar Gattern angeflanscht.

    Quote from Thunderblade

    Der VIC hat keine Reset-Leitung, trotzdem macht der Kernal sehr früh einen STA $D016, angeblich um per VIC den RAM-Refresh zu aktivieren. Habe ich noch nie verstanden und ist mir bis heute ein Rätsel warum der Kernal das tut...

    Der VIC macht die RAM-Zugriffe hardcodiert. Die Refresh-Zyklen haben nichts mit den normalen RAM-Zugriffen zu tun, die abgeschaltet sind, wenn DEN nicht gesetzt ist, die Refresh-Zyklen finden in einem ganz anderen Bereich der Zeile statt, und zwar immer, in jeder Zeile, egal vom Betriebsmodus.


    Einfach mal den "VIC Article" von vorne bis hinten durchlesen, dann wird das klar.

    "Where all think alike, no one thinks very much." - "Wo alle dasselbe denken, denkt keiner viel."

    (Walter Lippmann, "The Stakes of Diplomacy", 1915)


    "Steve Jobs hat User hervorgebracht, Jack Tramiel Experten." - Quelle unbekannt.

    "Mein Herr, ich teile Ihre Meinung nicht, aber ich würde mein Leben dafür einsetzen, dass Sie sie äußern dürfen." - Voltaire.

    "Diskutiere nie mit einem Idioten - er zieht dich auf sein Niveau hinunter und schlägt dich dort mit seiner Erfahrung!" - Volksweisheit.


    Quote from 1570

    die (simple) State Machine im 6566 kann wohl angehalten werden, und die kümmert sich auch um RAM Refresh.

    Der 6566 ist für statisches RAM gemacht, nicht für DRAM. Der hat keinen Refrresh.

    "Where all think alike, no one thinks very much." - "Wo alle dasselbe denken, denkt keiner viel."

    (Walter Lippmann, "The Stakes of Diplomacy", 1915)


    "Steve Jobs hat User hervorgebracht, Jack Tramiel Experten." - Quelle unbekannt.

    "Mein Herr, ich teile Ihre Meinung nicht, aber ich würde mein Leben dafür einsetzen, dass Sie sie äußern dürfen." - Voltaire.

    "Diskutiere nie mit einem Idioten - er zieht dich auf sein Niveau hinunter und schlägt dich dort mit seiner Erfahrung!" - Volksweisheit.


    Quote from kinzi
    Quote from berni

    Oder kommt das irgendwie von außen? Hat da etwa der VIC schon wieder seine Hände im Spiel?!?

    Wieso sollte der VIC da maßgebend sein, in einem System, das prima auch ohne auskommt?

    Das Reset-Verhalten ist rein CPU-intern und funktioniert ja in einer 1541 auch, und da ist kein VIC verbaut.

    Kann man durch reines Überlegen ganz einfach rausfinden.

    Naja, der VIC gibt ja dem 6510 auch den Systemtakt vor, wer weiß, was er da sonst noch alles macht. Und mit den Floppies habe ich mich bislang kaum auseinander gesetzt - wer da den Takt vorgibt (ein VIC macht dort natürlich keinen Sinn) - weiß ich nicht.

    Quote from berni

    Naja, der VIC gibt ja dem 6510 auch den Systemtakt vor, wer weiß, was er da sonst noch alles macht.

    Er macht genau NICHTS sonst. Das ist seit Jahrzehnten dokumentiert. Einfach mal lesen:


    https://www.zimmers.net/cbmpics/cbm/c64/vic-ii.txt


    Da braucht man auch nicht Rätselraten und reininterpretieren.


    Und der zweite wichtige Link wurde bereits in #2 gepostet, wo erklärt wird, wie das mit de Reset des 6502 funktioniert: Dann bleiben auch keine Fragen offen.


    [EDIT]

    Quote from berni

    Und mit den Floppies habe ich mich bislang kaum auseinander gesetzt - wer da den Takt vorgibt (ein VIC macht dort natürlich keinen Sinn) - weiß ich nicht.

    Der Takt wird von einem Taktoszillator vorgegeben. Fertig. Wie bei jeder CPU.

    Dass im C64 der Takt noch durch den VIC durch acht geteilt wird, hat mit dem VIC selbst gar nichts zu tun. Das ist auch völlig hartcodiert und kann durch keinerlei Register "beeinflusst" werden.


    Bitte hör einfach mit dieser Spekulierei und Kaffeesatzleserei auf.

    Es wurde alles auf dem Silbertablett serviert - lesen bildet.


    (SCNR)


    [/EDIT]

    "Where all think alike, no one thinks very much." - "Wo alle dasselbe denken, denkt keiner viel."

    (Walter Lippmann, "The Stakes of Diplomacy", 1915)


    "Steve Jobs hat User hervorgebracht, Jack Tramiel Experten." - Quelle unbekannt.

    "Mein Herr, ich teile Ihre Meinung nicht, aber ich würde mein Leben dafür einsetzen, dass Sie sie äußern dürfen." - Voltaire.

    "Diskutiere nie mit einem Idioten - er zieht dich auf sein Niveau hinunter und schlägt dich dort mit seiner Erfahrung!" - Volksweisheit.


    Quote from kinzi
    Quote from 1570

    die (simple) State Machine im 6566 kann wohl angehalten werden, und die kümmert sich auch um RAM Refresh.

    Der 6566 ist für statisches RAM gemacht, nicht für DRAM. Der hat keinen Refrresh.

    Irgendwas ist auch immer ;).


    Vielleicht ging's um den impliziten Refresh der internen Register? Wer weiß.