SJLOAD: Software-Schnelllader für Jiffy-Laufwerke

Genial, hast du was dagegen, wenn ich dein SJLOAD in der Final Expansion v3 integriere?

Und ich in das EasyProg? Beim Flashen dauert das Laden von Disk im Moment immer am längsten.

Wenn es Dich nicht stört, könntest Du ja irgendeinen Lizenztext rüberklatschen, dann hat das was definiertes.... zlib wäre schön, ist auch GPL-kompatibel

Gruß,

Thomas (der Lizenzen meistens beachtet)

SJLOAD wäre die ideale Lösung, weil im gegnsatz zu EasyLoad oder Dreamload benötigt man hier keinen code upload in die "Floppy", das beim SD2IEC eh nur proforma erfolgt. Aber ich befürchte das Timing wird am VC-20 nicht stimmen und daher problematisch sein?

edit: Sorry, die Frage hat sich geklärt. (Lesen müsste man können....)

Easyload wäre (für mich) die Ideallösung, weil die ist fix und fertig im Sourcecode verfügbar für den VC-20.

Easyload ist genial, basiert auf Code von Marko Mäkelä, funktioniert mit PAL und NTSC, mit 1541, 1571 und 1581 und ist zudem sauschnell. Für mich sieht der Disk Code am 0x300 ziemlich ähnlich zu dem OpenCBM Code aus.

Quote from Diddl

SJLOAD wäre die ideale Lösung, weil im gegnsatz zu EasyLoad oder Dreamload benötigt man hier keinen code upload in die "Floppy", das beim SD2IEC eh nur proforma erfolgt. Aber ich befürchte das Timing wird am VC-20 nicht stimmen und daher problematisch sein?

Jiffy ist relativ Timing-unkritisch, auf dem C64 läuft es ohne Änderungen auf PAL- und NTSC-Maschinen. NTSC-VC20 und NTSC-C64 haben den gleichen Takt, allerdings ist der PAL-VC20 etwas schneller als der NTSC-VC20 (1108405Hz statt 1022727Hz). Ich würde spontan vermuten, dass das keine oder nur eine geringfügige Anpassung (1 eingeschobener Takt) erfordert.

Als Gegenstelle zum Testen empfiehlt sich eine 1541 weil die am ungenauesten mit dem Computer synchronisiert, ausserdem ist die Einzelbyteübertragung anfälliger als das LOAD-Protokoll.

Nur mal so am Rande. Jiffydos auf C64-PAL ist doch etwas knapp vom Timing. Am C128DCR fällt es regelmässig auf die Nase mit der internen 1571 (C64+1541 Modus wohlgemerkt), aufgrund der geringen Leitungslänge und fehlenden Kabelkapazität. Man bekommt es erst wieder stabil durch Last auf dem Bus, durch externe angeschlossene Geräte oder einen Steckerdongle mit eingelöteten Kondensatoren ...

Genauer...ATN, Clock, und Data mit ein paar nF auf GND ziehen?

Das erklärt ein paar Phänomene hier.

So in der Art. Finde aber den Stecker gerade nicht. Nur an ATN muss nix dran, da werden ja keine Daten übertragen. Das Signal ist unkritisch.

Quote from 1570

Von mir aus geht das natürlich in Ordnung. Lizenztechnisch habe ich nichts drübergeschrieben, weil es sich nicht um eine "Clean Room"-Neuimplementierung handelt und einige (triviale) Teile mit dem normalen C64-ROM bzw. Jiffy identisch sind. Ich kläre das mal.

Und, hast Du was geklärt? Oder gibt es jemand, der nach einer Protokollbeschreibung eine Clean-Room-Implementierung machen kann? Eine kleine Lib, die mit dem Jiffy-Protokoll zurechtkommt, wäre eine echte Bereicherung.

Zufällig lade ich die Tage immer sehr große Dateien vom sd2iec. Jiffy ist das einzige Protokoll, das man momentan außerhalb von Disk-Images mit dem sd2iec benutzen könnte.

Quote from skoe

Jiffy ist das einzige Protokoll, das man momentan außerhalb von Disk-Images mit dem sd2iec benutzen könnte.

Öh, hattest du das FC3-Protokoll nicht selbst implementiert? Das funktioniert auch prima ohne Diskimage.

Quote from Unseen

Öh, hattest du das FC3-Protokoll nicht selbst implementiert? Das funktioniert auch prima ohne Diskimage.

Ich brauche kein Datei-Load, sondern häppchenweises Lesen. Stimmt, Du hast trotzdem recht, ich könnte ja die C64-Seite des Protokolls "nachimplementieren" und in mein Programm einbauen. Dann hätte ich selbst in der Hand, wieviel ich auf einmal lese.

Quote from 1570

Also JB jedenfalls hat seinen Segen zu gegeben, insofern ist das denke ich unproblematisch.

Heißt das, ich könnte das einfach in mein Programm (open source, zlib-Lizenz) einbauen und einfach keinen Lizenztext drüberschreiben? Oder möchtest Du Dir noch überlegen, was drüberstehen soll?

Quote from skoe

Ich brauche kein Datei-Load, sondern häppchenweises Lesen. Stimmt, Du hast trotzdem recht, ich könnte ja die C64-Seite des Protokolls "nachimplementieren" und in mein Programm einbauen. Dann hätte ich selbst in der Hand, wieviel ich auf einmal lese.

Genau sowas würde ich auch brauchen. Es sind zwar nur 8KB Häppchen oder 2x8, trotzdem wär ein SD2IEC Turbo genial für das Final Expansion. Mir egal ob es Jiffy oder AR3 kompatibel ist, hauptsache es kann mit dem SD2IEC.

Quote from 1570

Von mir aus klar.

Danke für die SJLOAD Inspiration und den Sourcecode!

Ohne dein SJLOAD gäbe es kein VC-20 SJLOAD und damit auch keine FE3 Jiffy Unterstützung.