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...
There are 19 replies in this Thread which has previously been viewed 1,776 times. The latest Post (
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...
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.
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
Oh ja, die 1541/2031 waren schon immer der Schlüssel zur echten Geschwindigkeit.
Wie meinen? ![]()
Oh ja, die 1541/2031 waren schon immer der Schlüssel zur echten Geschwindigkeit.
Wie meinen?
Nasentroll reloaded.
Die Demo ist wirklich beeindruckend. Ich frage mich, welche tollen Spiele mit so einem Wissen möglich wären?
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.
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.
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...
Krill: Ist das dann eine Umdrehung pro Track ? Also das Maximum ?
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. ![]()