Fastloader für PET

There are 19 replies in this Thread which has previously been viewed 1,776 times. The latest Post (January 9, 2026 at 8:42 AM) was by Krill.

  • Leider sind auch die großen Laufwerke unnötig langsam.

    Gab es jemals Fastloader für den PET?

    Habe da nach schneller Websuche nichts zu gefunden.

    Sonst muss man wohl doch wieder alles selber machen...

  • 4040/8050 und Konsorten langsam? Wirklich?

    Ich finde, dass die gerade zum Vergleich mit ner 1541 am IEC Bus turboschnell sind...

    Die 1541 schafft 20 KB/s trotz seriellem Nadelöhr. =)

    Please login to see this link.

    Die PET-Laufwerke machen out of the box vielleicht 1,5 KB/s. Lame.

  • Die 1541 schafft out of the box aber auch niemals ihre 20kb. ;)

    Wenn, muss man schon 1:1 vergleichen.

    Es gab Speedos (ja, so geschrieben). Ich hab ne 8250 mit dieser Erweiterung. Ob/wieviel die schneller ist, weiß ich nicht.

  • Die 1541 schafft out of the box aber auch niemals ihre 20kb. ;)

    Wenn, muss man schon 1:1 vergleichen.

    Es gab Speedos (ja, so geschrieben). Ich hab ne 8250 mit dieser Erweiterung. Ob/wieviel die schneller ist, weiß ich nicht.

    Ich rede ja auch genau von Fastloadern.

    Also dem, was das Laufwerk eigentlichschaffen kann, wenn nicht alles über ineffiziente DOS-Befehle, -Protokolle und/oder -Encodings geht.

    Insbesondere meinte ich Software-Fastloader, also ohne Umbauten. =)

    Weil ich sowas eben gerade brauche.

  • Es gab einen Hardware "Speeder": Speedos für die 8250. Allerdings hat der die Busübertragung nicht oder wenig beschleunigt, aber das DOS selbst etwas flotter gemacht.

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    10 open1,8,15                   : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    RUN
  • Ich schätze, der Bedarf war verschwindend gering, weil die Programme noch nicht so groß waren. Auch am VC20 spielte das kaum eine Rolle. Erst am C64 hatte sich die Situation derart verschärft, daß man da dringenden Handlungsbedarf sah.

  • Ich schätze, der Bedarf war verschwindend gering, weil die Programme noch nicht so groß waren. Auch am VC20 spielte das kaum eine Rolle. Erst am C64 hatte sich die Situation derart verschärft, daß man da dringenden Handlungsbedarf sah.

    Ja, habe ich auch schon vermutet.

    Na gut... dann tipp ich mal eben was ein.

  • So, das klappt schon mal ganz gut.

    Please login to see this link.

    Please login to see this link.

    Please login to see this media element.

    Da geht aber deutlich mehr, wenn der zweite 6502 (der Diskcontroller) auch noch mit Customcode bespaßt wird.

  • Oh ja, die 1541/2031 waren schon immer der Schlüssel zur echten Geschwindigkeit. Danke fürs Teilen der Links

    Stargazer & Spin-Lover | Auf der Suche nach Please login to see this link.

  • Die Demo ist wirklich beeindruckend. Ich frage mich, welche tollen Spiele mit so einem Wissen möglich wären?

    Ich vermute, dass gerade bei den Grafiktricks nicht mehr viele Zyklen für irgendwas übrigbleiben. Vermutlich würde man ebi Spielen deutlich abspecken müssen.

    C64C mit 8580, C64 mit 6581 und C64G mit ARMSID,

    C16, VC20, PET3016+32K, 3x1541, 2x1541-II, Pi1541, Philips CM8833-II, 1084S

    Please login to see this link.

  • Ich vermute, dass gerade bei den Grafiktricks nicht mehr viele Zyklen für irgendwas übrigbleiben. Vermutlich würde man ebi Spielen deutlich abspecken müssen.

    Kommt ganz drauf an.

    Die Standbilder vor den Parts sind 8KB-Bitmaps (512x128 Pixel) und brauchen so gut wie keine Extra-CPU-Zeit (nur ein paar strategische Interrupts für CRTC-Register-Updates).

    Das Hauptproblem ist dann aber, mit roher CPU-Power in einer Bitmap rumzumalen (inklusive Lookup von Bytepattern nach Char).
    Das hat bei 8-Bit-Rechnern noch nie so wirklich fluffig funktioniert, aber es gibt sicher Spielkonzepte, die das verkraften. =)

  • Was cool wäre: so was wie King‘s Quest oder andere AGI Games. Da werden nur kleine Teile des Bildschirms aktualisiert.

    C64C mit 8580, C64 mit 6581 und C64G mit ARMSID,

    C16, VC20, PET3016+32K, 3x1541, 2x1541-II, Pi1541, Philips CM8833-II, 1084S

    Please login to see this link.

  • Der Fastloader lädt jetzt 240 Blöcke (ca. 60 KB) in ca. 2 Sekunden auf der 8250. :)

    Please login to see this media element.

  • Krill Saucool. Das könnte eventuell doch ganz nützlich für den Infocom Interpreter sein, wenn der den Scan durch das SEQ File macht... Im laufenden Betrieb wo vor allem Random Access gemacht wird ist das nicht so hilfreich, aber der initiale Scan könnte davon profitieren...

    C64C mit 8580, C64 mit 6581 und C64G mit ARMSID,

    C16, VC20, PET3016+32K, 3x1541, 2x1541-II, Pi1541, Philips CM8833-II, 1084S

    Please login to see this link.

  • Krill Saucool. Das könnte eventuell doch ganz nützlich für den Infocom Interpreter sein, wenn der den Scan durch das SEQ File macht... Im laufenden Betrieb wo vor allem Random Access gemacht wird ist das nicht so hilfreich, aber der initiale Scan könnte davon profitieren...

    Eigentlich sollte so ein ordentlicher Random-Access-Loader Please login to see this link. (und die Übertragung der Daten fällt ja auch weg).

    Krill: Ist das dann eine Umdrehung pro Track ? Also das Maximum ?

    Genau. Tatsächlicher maximaler "sustained throughput" dürfte etwas höher sein, wenn man die Dateiöffnungspauschale (wird mit DOS-Calls gemacht) und das Übertragen des laufwerksseitigen Codes abzieht.

    Auf 4040 und Co. (also bei 170 KB pro Seite) dürfte der Durchsatz so gegen 22 KB/s gehen und auf der 2031... na ja, deutlich weniger. =)