Hallo Besucher, der Thread wurde 9,1k mal aufgerufen und enthält 26 Antworten

letzter Beitrag von spacer am

Cartridgeheader und Struktur für C16 und Plus/4 ?

    Ich hatte mir heute einige der wenigen C16 CRTs mal angeschaut, um herauszufinden, wie die Header oder Aufbereitung dafür aussehen muss. Letztlich habe ich den Code aus dem Viduzzle-CRT kopiert und das wollte nicht funktionieren.
    Dann habe ich den Code anhand von Memory-Map und ROM-Listing nach meinem Gutdünken umgeschrieben und da funktionierte es sofort. :) Ich habe eine Überprüfung auf mehr als 16kb und dieses Jonglieren mit der Bankingeinstellung herausgeworfen.
    Das Banking stelle ich direkt ein (X-Register=#$02). Warum findet man in den Cartridges, die als C1L eingeblendet werden, immer wieder $00 oder $01 vor der CBM-Kennung ? - Das müsste doch das Konfigurationsbyte sein ?






    Warum blinkt da noch ein Cursor ?



    Gibt es irgendwo eine brauchbare Anleitung zu den Cartridges oder muss man das mit auffindbaren Unterlagen selbst herausfinden ?

    Ein kommentiertes ROM-Listing dürfte reichen, so wild isses ja nicht. Das besagte Byte kann IIRC entscheiden, ob das Cartridge vor oder nach der Initialisierung des Systems aufgerufen wird. Und zumindest der 3-plus-1-Header funktioniert auf jedem der drei Slots (intern, extern1, speech/extern2)- IIRC belegt er sogar jeweils eine andere F-Taste mit der Startsequenz.


    Irritierend ist eigentlich nur der überall ausgewiesene NMI-Vektor, den es im 264er-System ja gar nicht gibt...


    edit: Welcher Wert nach FDDx geschrieben wird ist völlig egal! Es zählt nur das low-Nibble der Adresse!

    Zitat von Mac Bacon

    Hat TED nicht einen Hardware-Cursor?

    Puh, keine Ahnung. Das muss ich dann wohl herausfinden.


    Zitat von mc71

    Das besagte Byte kann IIRC entscheiden, ob das Cartridge vor oder nach der Initialisierung des Systems aufgerufen wird.

    Ja, das könnte es sein. Da muss ich mich mal im ROM auf die Suche machen.


    So langsam klappt es, nur diesen Cursor werde ich (noch) nicht los. :) Habe mal Kikstart als bin eingefügt, das dann herauskopiert und per Trampolin-Code gestartet wird. Ist so echte Speicherverschwendung, passen zumindest zwei oder mehrere der kleinen C16-Spiele in eine Bank. War nur zum Üben.


    Hänge das crt an.


    Zitat von Gerrit

    Ja, hat er. Damit der weg ist muss man ihn ausserhalb des sichtbaren Bereichs 'parken'.

    Danke für die Info. Werde ich beim nächsten Mal versuchen.

    Ja, danke, funktioniert. Hatte es heute auch mit Google gefunden:


    Im Original http://www.pagetable.com/docs/…minary%20Data%20Sheet.pdf und die Übersetzung: http://www.c64-wiki.de/index.php/TED#Registerbelegung



    Ich muss mir mal einen Labelfile für den Assember anlegen. Hatte eben beim Überfliegen im "Commodore Sachbuch" gesehen, dass einige Adressen gleich wie bei anderen C=Rechnern liegen (getin, bsout, usw.). Dann muss ich das nicht immer wieder zusammensuchen.

    Die Tastaturabfrage per getin $ffe4 funktioniert im ROM scheinbar auch nicht (?) Musste kurz einen Scanner einbauen, um die Tastatur abfragen zu können. Habe mal zwei Spiele in ein Modul gestopft.
    Btw ... das obige Listing hat einige kleine Flüchtigkeitsfehler.


    Kikstart und Invaders:

    Zitat von cbmhardware

    Die Tastaturabfrage per getin $ffe4 funktioniert im ROM scheinbar auch nicht (?) Musste kurz einen Scanner einbauen, um die Tastatur abfragen zu können.

    GETIN liest ein Byte vom aktuellen Eingabekanal. Solange die Eingabe nicht per CHKIN auf ein anderes Gerät verbogen wurde, wird das Byte direkt aus dem Tastaturpuffer geholt (im Gegensatz zu CHRIN, welches aus dem Eingabepuffer ab $200 lesen würde). GETIN scannt also nicht die Tastatur, das muss weiter der Systeminterrupt machen. Wenn der nicht läuft, z.B. weil Dein Modulcode vor dem System-Init angesprungen wird, kann GETIN also nicht funktionieren.

    Zitat von Mac Bacon

    Wenn der nicht läuft, z.B. weil Dein Modulcode vor dem System-Init angesprungen wird, kann GETIN also nicht funktionieren.

    Ja, richtig, wird ja wie in der Reihenfolge des Source abgearbeitet. Daran hatte ich im Moment nicht gedacht.

    I don't see the issue ..?


    Attached SRAM Cartridge-Replacement and loaded from sd2iec to $8000. After reset it works:





    Kikstart worked also von Key 1.


    In Vice Xplus4 attached as "raw 16kb C1 Low"-Cartridge it worked also. It's no replacement for the internal function-rom ! - Only an ordinary C1L-Cart.



    Edit: added start-address l/h: $00,$80 and sent it by USB-wire:



    My digicam is old crap, but this worked also fine for me.

    CRT original file is corrupt. Yape emulator does not work.




    your code.


    • .80C6 A2 36 LDX #$36
      .80C8 BD 30 81 LDA $8130, X
      .80CB 9D 5E 06 STA $065E, X
      .80CE CA DEX
      .80CF D0 F7 BNE $80C8

    my code.

    • .80C6 A2 36 LDX #$36
      .80C8 BD 30 81 LDA $8130, X
      .80CB 9D 5E 06 STA $065E, X
      .80CE CA DEX
      .80CF 10 F7 BPL $80C8

    Ah, yes, one cycle too much. But this is no reason to go stuck for the yape:


    Code
    1. ldx #$35 ;<- also a fix
    2. lda $8130,x
    3. sta $065e,x
    4. dex
    5. bne -- ; or use bpl
    6. jmp $065e


    It writes 41 Bytes in the speech RAM-Aera and 19 Bytes in the following Basic Runtime-Stack. Maybe an error in the Yape-Emulation. Vice Xplus4 and the real machine worked well.