schneller Trackloader

  • Hi Ulli,

    ich nehme den aktuellen Source und starte dann quasi "Hauptprogram Computer" , also ist der Floppy code in der 1541 und der Init ist auch gelaufen.

    wenn ich jetzt "von Hand" etwas Lade funzt einwandfrei.

    Ich hingegen möchte z.b. Track 1 laden mittels asm

    daher hatte ich mir gedacht $01 auf $35 setzen, und dann ldy #1 , jsr cloadtrack

    aber pustekuchen, screen schaltet wohl d018 um und hängt sich komplett auf
  • mario schrieb:

    daher hatte ich mir gedacht $01 auf $35 setzen, und dann ldy #1 , jsr cloadtrack
    Also in der Original-Routine wird vor dem jsr cloadtrack wird noch einiges nach $dd08, $dd09 und $dd0b geschrieben.
    Außerdem kommt vorher auch noch ein jsr cfloppycmd.

    Bau mal einige/alle dieser "Inits" in Deinen Code mit ein, dann sollte auch jsr cloadtrack funzen.
    Achso, die Laufwerksnummer haste auch in $BA schon rein geschrieben ?

    Quellcode

    1. loadfile
    2. lda $d011
    3. pha
    4. and #%11101111
    5. sta $d011
    6. ldx #"4"
    7. jsr cfloppycmd
    8. lda $dd0b
    9. lda $dd09
    10. lsr
    11. lsr
    12. lsr
    13. lsr
    14. clc
    15. adc #48
    16. sta $0400
    17. lda $dd09
    18. and #$0f
    19. adc #48
    20. sta $0401
    21. lda $dd08
    22. adc #48
    23. sta $0403
    24. lda #$01
    25. sta .target+1
    26. lda #$07
    27. sta .target+2
    28. lda $dd00
    29. pha
    30. ldy tracknum
    31. beq .ende
    32. .loop jsr cloadtrack
    33. jsr nexttrack
    Alles anzeigen
  • Anscheinend Pack ich das vollkommen falsch an.

    Ja , in BA ist 08 weil ich das prg von drive8 geladen habe, zur Sicherheit aber nochmal gesetzt

    Zum test habe ich direkt hinter die originale startroutine anstatt des rts den loadmytrack code geschrieben mit dem gleichen ergebnis. Stürtzt ab.

    Muss ich denn nicht den originalen Hauptcode starten und danach den loadtrack ? Ich bekomm das gerade nicht in den Schädel was ich falsch mache.




    Quellcode

    1. loadmytrack
    2. lda #$08
    3. sta $ba
    4. sta tracknum
    5. lda $d011
    6. pha
    7. and #%11101111
    8. sta $d011
    9. ldx #"4"
    10. jsr cfloppycmd
    11. lda $dd0b
    12. lda $dd09
    13. lsr
    14. lsr
    15. lsr
    16. lsr
    17. clc
    18. adc #48
    19. sta $0400
    20. lda $dd09
    21. and #$0f
    22. adc #48
    23. sta $0401
    24. lda $dd08
    25. adc #48
    26. sta $0403
    27. lda $dd00
    28. pha
    29. ldy tracknum
    30. ; beq .ende
    31. jsr cloadtrack
    32. inc $d020
    33. rts
    Alles anzeigen
  • mario schrieb:

    Muss ich denn nicht den originalen Hauptcode starten und danach den loadtrack ? Ich bekomm das gerade nicht in den Schädel was ich falsch mache.
    Du musst auch vorher schon noch definieren, WOHIN der Track geladen wird.
    Das passiert ja über die normale LOAD"FILE",8 - Eingabe sozusagen "automatisch".
    machst Du es manuell, solltest Du zumindest die entspr. Parameter in der Zeropage setzen (ggf. sind die FileNameParameter ja nicht nötig).

    Quellcode

    1. ### Kernal-snipped .... ###
    2. ; initalise file name parameters
    3. FDF9 85 B7 STA $B7
    4. FDFB 86 BB STX $BB
    5. FDFD 84 BC STY $BC
    6. FDFF 60 RTS
    7. ; inatalise file parameters
    8. FE00 85 B8 STA $B8
    9. FE02 86 BA STX $BA
    10. FE04 84 B9 STY $B9
    11. FE06 60 RTS
    Alles anzeigen
    Wenn Dein Track bei ungesetzten/falsch gesetzten Parametern z.B. in die ZeroPage, den Stack oder gar in den LoaderCode selbst reingeschaufelt wird, wundern mich die Abstürze jetzt gerade nicht.

    Achso: der zu ladene Track sollte natürlich in den Sektoren gültige Links zu den nächsten Sektoren haben.
    Zum Debuggen/Testen empfehle ich ein gültiges File auf der Disk, wo die Links in den Sektoren stimmen.
    Das muss ja der Loader alles wieder richtig zusammensetzen, bevor es hintereinander in den Speicher geschrieben wird.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von GI-Joe ()

  • Die Trackloadadresse ist im im Original Source ja auf $e000 gelegt, das hab ich umgestellt auf $8000. Daher bin ich davon ausgegangen das ich das jetzt nicht noch einmal alles neu definieren muss. Ich dachte ich springe einfach die funktion cloadtrack an und dann passt das.

    offensichtlich ist dem nicht so.

    Kannst Du mir bitte (basierend auf dem Original Source) bitte einmal ein Beispiel zeige was ich genau machen muss um sagen wir mal von mir aus Track 18 zu laden ?

    Das wäre echt ne geile Aktion.
  • ich möchte track 1 laden und in die reu schieben. Danach track 2 -》reu. Track 3..... usw.

    quasi ein diskimage erstellen.

    Ja gibt's alles schon für d64 aber ich spiele gerade mit etwas ganz anderem rum.

    Alles soweit kein Ding, den rest hab ich auch zu 90 % fertig. Nur an dem trckloader beiß ich mir die Zähne aus. Und ich möchte das schon gerne mit dem loader machen anstatt mit den lahmen kernal routinen
  • ein Image ? Mit GCR Daten oder fertig ausdekodiert (also wie ein D64)?

    also ich denke, für dieses Vorhaben müsstest Du den Trackloader-Code schon entsprechend modifizieren, weil der Trackloader ist ja so aufgebaut, dass ein File mit dem Loader "on the fly" Trackweise geladen, GCR decodiert und dann Sektorweise (außer den ersten 2 Sector-Bytes) entspr. der Sektoren-Links im Speicher hintereinander abgelegt wird.

    Du wirst bei Deinem Vorhaben dann ja byteweise in die REU schreiben müssen statt in den Speicher - hoffentlich versaut Dir der ganze Mehrcode für das REU-Bank-geswitche nicht das Timing des Loaders - das ist nämlich relativ kritisch ! Außerdem müsstest Du die Sectoren inklusive der ersten beiden Sectorbyes in die REU schreiben, nur dann wird daraus ein DiskImage.

    Also: TrackLoader-code anpassen und hoffen dass es dann funzt !

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von GI-Joe ()

  • Das erklärt einiges, und hilft mir in meinem Vorhaben nicht wirklich weiter da es bei Byteweise lesen effektiv zu langssm wird.

    Das mit dem Timing ist relativ unkritisch zu sehen weil ich in das dadurch umgehen möchte, durch erst in den Speicher , und dann Blockweise von $8000-$9fff in die Reu schreiben, und nach dem Reutransfer erst weiter einlesen.

    Muss icb mir also was anderes überlegen bzw nach einer anderen mögligkeit suchen wie ich die Sektoren in einer akzeptablen Geschwindigkeit einlese.

    Trotzdem schonmal Danke für die Hilfe bisher.
  • Noch ein Gedanke:
    Du sagst ja, dass das Laden "von Hand" funktioniert. Das klingt, als hättest Du den Floppy-Teil 1:1 übernommen.
    Ich hab nun nicht in den Quelltext gesehen: Was für ein Protokoll hat Mafiosino denn entwickelt? ALso welche Kommandos und Zustände versteht die Floppy nach dem Start?

    Ist der Floppyteil nur eine einfache Toolbox zum Laden eines Tracks? Ist das Programm in der FLoppy nur eine große Schleife, die am Anfang auf 1 Tracknummer vom C64 wartet und dann den Track überträgt? Findet sich auf der Seite des C64 der Code, der Track 18 lädt, nach Dateinamen sucht usw.?

    Oder steckt im Floppy-Teil ein bisschen mehr, erwartet er das Übermitteln eines Dateinamens? Dann musst Du erst Intelligenz wegnehmen und den Floppy-Teil "verdummen", und dann können auch schonmal die Zustände auf dem Bus mehr Aufmerksamkeit brauchen.
    Vollmond war gestern!
  • Ja , den Trackloader hab ich 1:1 genommen und hatte gehofft daraus einen Trackloader für meine zwecke bauen zu können.

    Gute Frage, nächste :)

    Ich hab ehrlich gesagt zu wenig Ahnung von Floppycode um das aus dem Source zu identifizieren. Alles was sich auf reiner C64 Basis abspielt bekomm ich hin, aber wenn es dann um Floppyprogrammieren geht bin ich komplett aufgeschmissen sry.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von mario ()

  • moin.

    ich versuche den fastloader in meinem demo zu verwenden... im prinzip funktioniert er ja fast ganz gut ;)

    in vice is alles toll geht super... auf richtiger hardware hängt der loader bei einer floppy von mir (1541-II)
    bei einer anderen geht er einwandfrei (auch 1541-II aber hat anscheinend nen anderes laufwerk).

    nach einigen tests habe ich festgestellt das alles was > track 18 geht... alles was darunter ist nicht.
    bei files wo es nicht geht... er läd vielleicht 1 oder 2 tracks dann hängt er... motor geht aus und endlosschleife...
    auf comp seite hängt er im cloadtrack (tiefer hab ich noch nicht geschaut)

    das passiert auch wenn ich den fastloader im basic lade und run denn das file welches ich laden möchte.
    also vom demo kommt es nicht...

    das steppen hab ich schon auf original geschwindigkeit gesetzt hat aber nix gebracht...

    hat irgendjemand ne idee?

    ultra

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von ultra__ ()

  • Zwei mögliche Tipps hätte ich auch noch: Ist die Umdrehungsgeschwindigkeit der Floppylaufwerke ok? Außerdem (vielleicht blöd, aber ich hatte das Problem mal): benutzt Du das selbe serielle Kabel für beide Laufwerke? Ich hatte mal ein Kabel, das zuverlässig NICHT mit Schnellladern funktioniert hat, obwohl es sonst nie Probleme gemacht hat. Aber da das Problem wohl nur für bestimmte Tracks auftritt, halte ich den ersten Tipp für wahrscheinlicher.
    ────────────────────────────────────────────────────────────
    Time of Silence - Time of Silence 2 Development Blog
    ────────────────────────────────────────────────────────────
  • Claus schrieb:

    Zwei mögliche Tipps hätte ich auch noch: Ist die Umdrehungsgeschwindigkeit der Floppylaufwerke ok? Außerdem (vielleicht blöd, aber ich hatte das Problem mal): benutzt Du das selbe serielle Kabel
    Das mit dem seriellen Kaben hatte ich auch mal. Nach langem Suchen stellte ich fest, das der Zeilentrafo vom Monitor Störungen ins Kaben induziert hatte.
  • ahso (dachte du hättest dich vertippt d64->g64) das g64 hatte ich jetzt nicht auf dem zettel... gute idee... probier ich mal...

    hab mir mal den schaltplan der floppy angesehen...
    ich werd mal an der floppy an VIA1 Data Port A ne kleines lcd hängen... denn kann man wenn das g64 zu nix führt besser debuggen...
  • andere demos gehen einwanfrei auf den floppys... und ist das gleiche kabel...

    die bitrate ist ja höheren in den tracks ne andere... was vielleicht bei den höheren tracks nicht auffällt weil die dort ja kleiner ist. bei 1-17 ist ja eine höhere bitrate sprich die daten kommen schneller rein vielleicht ist die toleranz nicht ok
    was wieder für eine nicht korrekte umdrehungsgeschwindigkeit sprechen würde.. wobei mafiosino sicher krills text wann welche bytes save sind gelesen hat...
    aber wie gesagt andere demos gehen... und andere demos checken ja auch nicht jedes mal ob das byte da ist (via bvc)
  • Benutzer online 1

    1 Besucher