Hallo Besucher, der Thread wurde 47k mal aufgerufen und enthält 204 Antworten

letzter Beitrag von Krill am

Schneller Trackloader

    Ich habe hier ein Update des Fastloaders.


    Neu ist, dass er kein RAM im Bereich $C000-$D000 mehr benutzt. Außerdem wird der decodierte Track ab $E000 in der einfachen Reihenfolge: Sektor0 ab $E000, Sektor1 ab $E100 und so weiter bis Sektor20 ab $F400 abgelegt. Die Bytes sind in der richtigen Reihenfolge, so dass man relativ leicht debuggen kann.


    Der einzige Nachteil, der neu hinzugekommen ist, ist, dass ein indirekter jmp ($DD00) benutzt wird. Die Adresse $DD01 wird dabei gelesen. Normalerweise steht dort $FF drin, weil alle Portbits auf Eingang gesetzt sind. Es könnte sein, dass irgendwelche Erweiterungen am Userport diese Eingänge setzen. Ich habe leider keine Userporterweiterungen zum testen.


    Viel Spaß beim Ausprobieren!

    Hi Mafiosino,


    man kann wirklich noch substantiell viel Geschwindigkeit aus dem Loader rausholen, wenn man den ganzen ROM-Code-Overhead spart und auch die langsamen KERNAL-IEC-Routinen durch schnelle eigene Kommunikationsroutinen ersetzt. Also Faktor 25 ist durchaus drinne, denk ich.


    Aber schnell zu optimieren ist das hier:


    lda #$e0
    sta $02
    .waitjob lda $02
    bmi .waitjob


    Wenn man das durch


    lda #$e0
    sta $02
    .waitjob brk
    brk; ja, zweimal brk
    lda $02
    bmi .waitjob


    ersetzt, dürften einige unnötige Wartezyklen gespart werden, da man den IRQ-Handler direkt aufruft, statt auf den Timer zu warten, der das tut. Das sind im Mittel immerhin 7424 Zyklen pro Spur der zu ladenden Datei.


    Ansonsten würde ich Deine Ideen nutzen wollen, um meinem IRQ-Loader (http://noname.c64.org/csdb/release/?id=78348) irgendwann eine Superturbo-Funktionalität zum Booten hinzuzufügen, natürlich mit ordentlichen Credits. Okay? :)


    Grüße,


    gunnar.

    Hallo Krill,


    ich finde es super, dass du dir Gedanken machst, wie man den loader noch schneller machen kann. Ich muss den Trick mit dem BRK wirklich mal ausprobieren.


    Gibt es eigentlich Source-Code von selbstgeschriebenen Floppy-Routinen, die die Betriebssystemroutinen ersetzen, um diese zu beschleunigen? Ich sehe bei meinem Loader so ein bisschen das Problem, dass nicht genug Floppy-Speicher für eigene Routinen übrig ist.


    Ich habe mir selbst auch schon mal Gedanken gemacht, wie man den Loader weiter beschleunigt. Man könnte zum Beispiel im ersten Durchlauf die Track- und Sektornummer des Folgetracks zwischenspeichern und nach dem Sektor an den Computer übertragen. Dann könnte der Computer ausrechnen, wo die Bytes hingeschrieben werden müssen, und im zweiten Durchgang die Bytes direkt, also ohne Zwischenspeicher bei $E000, an die Stellen schreiben, wo sie hingehören.


    Zu deiner lezten Frage: Du kannst selbstverständlich Teile meines loaders oder auch bloß meine Ideen in deinen IRQ-Loader einbauen, um den zu verbessern, dafür habe ich meine Sourcen ja hier abgelegt. Mich würde es natürlich sehr freuen, wenn ich dazu beitragen kann, dass sich die Progamme auf dem c64 weiterentwickeln.

    Das mit dem BRK würd ich nich wirklich als Trick bezeichnen, genau für sowas is der Opcode ja da :) Das is ja sowas wie n primitiver TRAP-Opcode, wobei die Trapnummer als Byte hinter dem Opcode übergeben wird - nach dem RTI ist der PC zwei Bytes weiter und nicht nur eins, daher zwei BRK an der Stelle. Das hier ist aus dem 1581-ROM:


    959E: 58 CLI i-Flag loeschen
    959F: 95 02 STA $02,X Jobcode fuer Puffer x setzen


    Einsprung von $959A:


    95A1: 00 BRK Jobschleife aufrufen
    95A2: EA NOP [BRK ist ein 2-Byte-Befehl!]


    Einsprung von $95A5:


    95A3: B5 02 LDA $02,X warten, bis Controller fertig ist
    95A5: 30 FC BMI $95A3


    In meinem Loader (siehe Link oben) wird das KERNAL bei 1541/71 nur zum Upload des laufwerksseitigen Codes benutzt und für ein paar GCR-Tabellen, der Rest sind eigene Routinen, inklusive komplettem Disk-Zugriff mit Sync-Suche, Spurwechsel usw. - siehe Quelltext.


    Genug Speicher sollte eigentlich da sein - im Grunde sollte es reichen, eigene serielle Routinen zu benutzen, um den Loader ausreichend zu beschleunigen - den Sync- und Header-Kram kann man weiterhin vom ROM machen lassen, wenn man nicht gerade die Spuren 35 und aufwärts nutzen will. Und wenn man entschieden hat, gar keine ROM-Routinen mehr zu nutzen, hat man ja auch die vollen $0800 Bytes zur Verfügung. Unschön ist dabei nur, daß man nach getaner Arbeit das Laufwerk resetten muß - das ist aber auf der 1541/71 nicht weiter schlimm, weil es ja keine Unterverzeichnisse gibt.


    Deine Idee mit dem Scan der Verlinkung im ersten Durchlauf sollte klappen, aber Du mußt dann immer noch ne Menge Bytes beim Spurwechsel kopieren. Ganz abgesehen davon, daß die Checksummen ignoriert werden, was unschön ist. Schon mal an ein eigenes Format gedacht?


    Grüße,


    gunnar.

    So, ich habe einen Teil meiner beschriebenen Ideen umgesetzt und den Trackloader weiter verbessert.


    Ein kompletter Track wird in zwei Diskettenumdrehungen in den C64-Speicher gelesen. Dabei wird jetzt während der ersten Umdrehung eine Tabelle mit allen Tracks und Sektoren für den jeweils nächten Block erstellt. Dadurch kann in der zweiten Umdrehung jedes gelesene Byte sofort an die richtige Stelle im Speicher geschrieben werden.


    Das ganze ergibt einen Geschwindigkeitsgewinn von 0.3-0.4 Sekunden bei langen Dateien.


    Das .prg-file meines Loaders ist länger geworden, da ich zwischendurch eine Art Speed-Code benutzen muss, um die richtigen Adressen für den zweiten Durchlauf bestimmen zu können. Ich habe die Schleife entpackt, sonst wäre der Code nicht schnell genug.


    Ein Nachteil der Weiterentwicklung darf hier auch nicht unterschlagen werden: Der letzte Block des zu ladenden Programms wird im zweiten Durchgang immer komplett geladen. Es werden also im Speicher Bytes überschieben, die eigentlich nicht verändert werden sollten.


    Das Programm läuft bei mir auf VICE 2.0 in der C64+1541 Emulation und auf einem echten C128D Blech.


    Viel Spaß beim Ausprobieren!

    Zitat von Mafiosino

    Ich sehe bei meinem Loader so ein bisschen das Problem, dass nicht genug Floppy-Speicher für eigene Routinen übrig ist.


    Dazu gibt es die RAMboards für 1541 und 1571 die 8KB zusätzliches RAM einblenden ab $6000 (1571) oder $8000 (1541). Manche Speeder wie Dolphin DOS nutzen den RAM.



    Wir (Nils und ich) basteln gerade an einer Erweiterung wo die Floppy dann eine ganze Diskette im RAM Platz hat: David-65

    Gab eben eine Diskussion in #c64 auf freenode, daher habe ich es mal getestet: Die letzte und die vorletzte Version läuft auf einem meiner C64C mit einer 1541-II, auf einem anderen C64C läuft es nicht, aber da ist auch schon ziemlich dran herumgebaut worden, custom ROM glaube ich (will es nicht aufmachen). Die erste Version läuft auf keinem meiner C64.


    Wirklich ziemlich schnell: 107 blocks in weniger als 5 Sekunden.

    C64 (251715-01 PLA) + 1541 assy #250446.
    Mine drive is almost the oldest version of 1541 (the oldest one assy is #250442, and before that were 1540 drives).
    This has a board with #250442 inscription, but components are of #250446.
    'LDA #$40 STA $1c0b' makes this drive not being able to read anything on the drive with its native subroutines, this fastloader stucks before it actually enters the own subroutines on drive side.
    (bit 0 set to 0 is necessary for disable the latch of port A, which is being read through $1c01, what makes the bits of those inputs to be visible as they are shifted by the hardware, and thus allows to get only few of them, rather than get whole byte at once)
    So that is the moment where my drive begins to mess, until it is reset.
    If disable that STA, then everything "works", but the loaded data is not adequate.

    Danke für die Rückmeldungen.


    gartenzwerg: Hängt bei dem zweiten C64C irgendetwas am Userport? Das Programm erwartet $FF in $DD01 und deshalb darf nichts an den entsprechenden Userport-Eingängen hängen. Ich könnte die Userportpinne auch auf Ausgang schalten und manuell $FF reinschreiben. Vielleicht ist das kompatibler. Aber vielleicht liegt es auch an etwas anderem.


    alexi: I will check the schematics where the differences between the drives are and if it is possible to write a workaround.

    Zitat von Mafiosino

    Danke für die Rückmeldungen.


    gartenzwerg: Hängt bei dem zweiten C64C irgendetwas am Userport? Das Programm erwartet $FF in $DD01 und deshalb darf nichts an den entsprechenden Userport-Eingängen hängen. Ich könnte die Userportpinne auch auf Ausgang schalten und manuell $FF reinschreiben. Vielleicht ist das kompatibler. Aber vielleicht liegt es auch an etwas anderem.


    Am Userport war nichts dran. Habe mir den Computer auch nochmal genauer angesehen und scheint sogar noch das Garantiesiegel ganz zu sein, nur außen sind ein paar Beschriftungen per Marker dran und eine Art Brandeisenmarkierung "Eigentum der Stat Dortmund" (habe den ganz normal bei eBay gekauft, keine Ahnung wo der Verkäufer den her hat :) )


    Wenn du aber noch an dem Turboloader am arbeiten bist und den auf möglichst vielen C64ern laufen lassen willst, kann ich den Rechner mal aufmachen und auch versuchen das Problem zu debuggen, und ggf. auch per Oszilloskop die IEC-Signale messen, falls das nötig sein sollte. Hattest du die IEC-Routinen auch beschleunigt? Muß ja irgendwo dran liegen. Vielleicht mag gerade der verbaute Prozessor nicht die illegalen Opcodes. Kann man den Turboloader nicht auch ohne diese programmieren?

    @ Mafiosino


    Hallo, dein Schnelllade Routine funtoniert nicht, einfach nur laden und warten, ist doch so, oder ?


    Also geladen, von einer Ultimate 1541 II, dan steht dort RUN, und das wars. Nehme an der C64 hat sich aufgehängt. Es handelt sich bei meinen C64 weiß, nach hinten abgesetzt, gabs mal in den 90er Jahren beim Aldi. Liegt es an den "iilegalen Opcodes" ?


    Brotscheibe

    Das ist ein Schnelllader den du in dein eigenes (ASM) Programm einbinden kannst und keiner den man einfach so lädt und dann schneller laden kann ;)

    Ich habe auf csdb noch einen Hinweis von Krill gefunden:


    Zitat

    This is kinda broken. The code relies on $dd01 being set to $ff, but this is never done, so it crashes.


    After loading the loader, enter POKE 56577,255: POKE 56579,255, then run, then load the desired program.


    Also gartenzwerg, probier mal print peek(56577) aus. Wenn da nicht 255 herauskommt, dann tipp die beiden pokes von oben nach dem Laden des Fastloaders ein.


    Der Fastloader benutzt meines Wissens nach keine illegalen Codes auf der Computerseite. Könntest du sonst nochmal überprüfen, ob der Computer ein geändertes Betriebssystem installiert hat? Vielleicht haben sich im ROM Einsprungadressen geändert oder ich überschreibe irgendwelche wichtigen Parameter.



    Das andere Problem, das von alexi gemeldet wurde, scheint dagegen klar zu sein. Ich habe extra die Latchkontrolle von Port A in $1c0b abgeschaltet, damit ich ich mir einen Zugriff auf $1c01 sparen kann. Ich lese von 5 Bytes eigentlich nur 4. Aber jetzt wird mir langsam klar, warum das in der Floppy so umständlich mit einem Zwischenspeicher von Port A gelöst ist: Weil es in den allerersten Geräten nicht anders ging. Es ist leider nicht so einfach möglich, die Routinen so einfach umzuschreiben, aber vielleicht fällt mir nochwas ein.

    Ich habe es eben nochmal ausprobiert auf dem C64 wo es nicht lief, und jetzt lief es merkwürdigerweise. Kann das Testprogramm was letztens nicht lief, so oft laden wie ich will, läuft immer. Ist definitiv in derselben Konfiguration letztens immer beim Laden hängengeblieben, mit Bildschirm aus und alles hellblau. Vielleicht sind noch irgendwelchen anderen Speicherstellen nicht initialisiert?


    Mit den Pokes sollte man übrigens vorsichtig sein, falls am Userport noch Hardware hängt, da das die Pins PB0-PB7 auf 5V schaltet.

    Zitat

    Mit den Pokes sollte man übrigens vorsichtig sein, falls am Userport noch Hardware hängt, da das die Pins PB0-PB7 auf 5V schaltet.


    jein. aktiv low und so. da kann eigentlich nix passieren. also zumindest dem c64 nicht, ob die hardware dann evtl unsinn macht ist ne andre sache =)