Posts by GI-Joe

    Das liegt wahrscheinlich daran, dass GI-Joes Generierungsroutinen eine Ultimax-Cartridge erzeugen.

    nö, meine Routinen erzeugen ein UNIPROM64-CRT (Supergames-kompatibel (sg) )

    Hab heute mal ne große Wartung an meinem geliebten Technics - Tapedeck RS-B965 gemacht.

    Meiner Meinung nach eines der besten DualCapstan-Tapedecks auf dem Markt.


    folgende Arbeiten hab ich gemacht:

    Riemenwechsel vom DualCapstan-Antieb und vom Klappenmechanik,

    2 neue Andruckrollen eingebaut,

    Bandlauf eingestellt - dazu eine Kassette vorher gut mir dem Dremel bearbeitet..

    4 prellende Tasten erneuert (weitere Tasten nachbestellt für einen vollständigen Tausch)

    def. Schalter für Tape-Erkennung (Type1, II, IV) instand gesetzt.

    von innen und aussen entstaubt.

    Probelauf - löppt wie neu *freu*


    Die neue CRT liegt auch auf $df00, stimmt's?

    stimmt.

    aber nach dem Kopieren vom CRT wird die Cartridge komplett abgeschaltet und ist somit nicht mehr präsent...


    Modulcode_cbm80_32KB-Cartridge.asm - Zeile 278:

    Code
    1. LDA #%00001100 ; "SUPER GAMES" - Platine: Set Bit 2 -> EXROM+GAME auf HIGH, Set Bit 3 -> WriteProtect_Latch(Kein EXROM=LOW mehr möglich !)
    2. STA $DF00 ; Modulhardware abschalten (EXROM+GAME auf HIGH)

    was mir noch aufgefallen ist: die Abkürzungen funzen nicht mehr ....

    Also z.B. for LOAD L [shift-o] oder für LIST L[shift-I]


    Ist das so auch beim SimonsBasic so ?

    Nich dass es schlimm wäre - ist mir nur aufgefallen ..... ;)

    Sehe gerade, dass dafür reicht, in "starter.asm" die richtige (!) Einsprungadresse zu setzen, nämlich "jmp $8170" (statt jmp $8171). Sorry, im File "TSB" von der TSB-Demodisk war das noch falsch (33137 statt 33136!). In der Startdatei im geZIPpten D64 ist das aber richtig! Tut mir leid! Kann man das irgendwie noch nachträglich ins CRT friemeln?


    jo, ist passiert und läuft prima :)


    Danke für die Erwähnung, aber du meintest markusC64 :)

    ups - kleine Verwechselung - sind aber auch zu ähnlich Eure beiden Nicknames 8o

    Hier meine bulidchain für das UNIPROM64 - Modul - funzt nun alles.....

    einfach das D64 file in den ./bin/ Ordner kopieren und eines der make-files ausführen.


    make_32kb_UNIPROM-CRT.sh macht aus den files tsb.hsg und tsb.obj aus dem D64 ein UNIPROM64-CRT

    tsb.hsg und tsb.obj liegen beide nach dem Init im Speicher


    Der Quellcode des Modulheaders kann bei Bedarf gern noch erweitert werden mit - wie Markus64 schon erwähnte - Nachladefiles aus dem CRT o.ä.


    Fertig gebaute files liegen schonmal mit bei :)

    Fehler gefunden! War kein Problem der Cartridge, sondern ein (aus Simons' Basic übriggebliebenes) TSB-Problem! Im COLD-Befehl, der eigentlich einen vollständigen Reset machen sollte (und danach die SB-typischen Sachen), wurde der Interrupt zu früh freigegeben (bevor alle Pointer gesetzt waren), was zum ersten Hänger führte. Außerdem wurde der Tastaturpuffer nicht initialisiert, was beim Start zur fälschlichen Annahme von 255 gedrückten Tasten führte, die dann alle ab $0277 auch eingetragen wurden (was die soeben gesetzten Pointer ab $0300 weder zerstörte) und den zweiten Hänger verursachten.


    Behoben!

    könntest Du mal ein "latest D64" hochladen - daraus könnte ich dann ein fertiges Cartrige-File fürs UNIPROM64 machen.

    Ich habe heraus gefunden, dass TSB nicht im ROM von 8000-BFFF läuft, sondern nur im darunter liegenden RAM.

    Hab mir mal eine build-chain für das UNIPROM64 gebaut.

    make.sh macht nur ein PRG-File was executable ist - das läuft !

    make_UNIPROM64-CRT.sh macht ein UNIPROM64 - File, wo der Code 8000-BFFF im ROM verbleibt. - das läuft so nicht.

    Files

    • TSB.tar.gz

      (654.08 kB, downloaded 2 times, last: )

    Ich habe das File tsb.obj.prg mal mit exomizer gepackt:

    Code
    1. exomizer sfx '$8171' -n tsb.obj.prg -o tsb.obj_exomized.prg

    und.... es startet nicht.X(

    Solch ein Phänomän hab ich so noch nicht gehabt.


    OK, dann hab ich über den VICE-Monitor über un 8171 gefreezed und davon auch einen 64k-MemoryDump gemacht (all_8171_from_exofile.bin)

    Danach 1x von dem D64 geladen und auch mit un 8171 gefreezed und einen 64kb MemoryDump gemacht (all_8171_from_disk.bin).


    nun habe ich beide Files über einen HEX-Dump - Vergleich miteinander verglichen.....

    Code
    1. xxd all_8171_from_disk.bin >all_8171_from_disk.txt # wandelt das Binärfile in einen textbasierten HEX-Dump um
    2. xxd all_8171_from_exofile.bin >all_8171_from_exofile.txt # das Gleich mit dem anderen Memory-Dump
    3. vimdiff all_8171_from_disk.txt all_8171_from_exofile.txt # beide miteinander vergleichen ....

    vielleicht hilft das ja weiter - einige Adressen (ZP und 2nd-ZP) sind ja schon verschieden ....

    [OFFTOPIC]

    Interessant finde ich, dass an diversen Stellen im Memory-Dump Werte voneinander abweichen, wo es nicht sein kann ...

    z.B. $7c45 (siehe Screenshot#3 oder auch Screenshot#4)

    [/OFFTOPIC]

    Files

    • diff.tar.gz

      (280.21 kB, downloaded 2 times, last: )

    hast Du die Pokes mit im Modulcode drin, bevor Du TSB startest ?


    Ich poste hier mal meinen Code:

    öhm, kommt nach dem RESET nicht erstmal ein Hardware-INIT ?

    und ich bin mir nicht sicher, ob sich nach dem Ausschalten des MagicDesk-Moduls es sich wieder einschalten lässt ....

    tsb.ext.prg und tsb.mem.prg liegen beide bei $CC00 .

    Wäre es nicht möglich, beides gleichzeitig im RAM zu lagern ab $C900 ?

    Der Basic-Speicher ist davon doch eh nicht betroffen ....


    Wenn das ginge könnte ich DIr ein UNIPROM64-CRT machen (Supergames)

    Habe gerade mal in die vice-sourcen geschaut - die MagicDesk-Karte lässt sich doch abschalten mit BIT7 von $DE00:


    Ich nehme an, ich muss irgendwie die Cartridge abgeschaltet kriegen, da sie "hardwaremäßig" noch da ist und sich mit TSB streitet. Kann man eine Cartridge per Software abschalten?

    Wenn es die Cartridge nicht kann (ist wohl bei MagicDesk so), dann kannst Du die auch über den Prozessorport abschalten:

    LDA$01

    AND #%11111110

    STA$01


    siehe auch die hier angehängten Auszüge aus dem Manual des UNIPROM64-Moduls.... (CPU-READ ist entscheidend !)


    Wenn Du /exrom UND /game auf low ziehst, wird ja bekanntlich das C64-Basic mit ausgeblendet.

    Dann funzen die normalen 8k - Cartridge - Routinen aber nicht mehr, weil irgendwann in der Reset-Routine indirekt nach $A000 (glaub ich ;) ) und auch an andere Adressen im BASIC-Rom gesprungen wird.

    Ich habe die in den >8Kb - Modulgeneratoren vom UNIRPROM64 so geregelt, dass ich einfach Teile des Codes aus dem Kernal und dem BASIC übernommen und optimiert hab.

    Ist ganz gut dokumentiert ....


    Allerdings: wenn Du 3x 8kb - Bänke brauchst, dann sollte eigentlich /game auf HIGH bleiben und Du kannst (im MagicDesk-CRT) die Bänke mit LDA#$00 (| 01 | 02) , STA $DE00 anwählen können.

    Dein ProgrammCounter muss sich dafür natürlich ausserhalb von $8000-9FFF befinden aber da sist Dir bestimmt schon klar denke ich :)

    Gar nicht. Das Ansprechen eines IEEE 488 Geräts benötigt komplett eigenen Code, da kann nichts von den seriellen Kernalroutinen verwendet werden.

    Doch, es geht ...

    sofern in der Cartridge gleich noch ein entsprechender Kernal-Ersatz drin ist (a la EasyFlash), bei dem alle seriellen Routinen auf IEEE gepatched sind.

    Muss nur noch jemand coden und groß kompatibel wird es auch nicht sein ..... :D