Auf
http://www.c64-wiki.com/index.php/SJLOAD
findet sich eine grundsätzlich funktionierende Version von SJLOAD, einem Software-Schnelllader für Jiffy-Laufwerke. Das Programm ist für die Leute gedacht, die einen C64 und eine Jiffy-Floppy haben, aber im C64 kein Jiffy eingebaut ist, oder z.B. die, die einen C64(DTV) mit SD2IEC benutzen.
SJLOAD: Software-Schnelllader für Jiffy-Laufwerke
- 1570
- Thread is marked as Resolved.
-
-
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)
-
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.
Die Routinen funktionieren so, wie sie im Moment sind, ausschließlich mit Jiffy-Laufwerken. Wenn ihr sie fest in eure Programme einbauen wollt, müsstet ihr noch eine Jiffy-Erkennung einbauen (ist im Code markiert) bzw. den Code manuell abschaltbar machen.
-
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.
-
Aber ich befürchte das Timing wird am VC-20 nicht stimmen und daher problematisch sein?
Für den VC-20 müsste man wohl einiges an SJLOAD anpassen, wobei die Timingsachen nicht soo kritisch sein sollten, muss man halt hier und da ein NOP (für die PAL-Version) einfügen
. Die relevanten Stellen sollten im Quelltext recht schnell erkennbar sein.
-
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.
-
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.
-
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. -
Und, hast Du was geklärt?
Also JB jedenfalls hat seinen Segen zu gegeben, insofern ist das denke ich unproblematisch. Davon abgesehen ist bei sowas auch fraglich, inwiefern man Clean Room überhaupt braucht: Sony vs. Connectix
.
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.
Ich hatte auch eine zeitlang überlegt, ein eigenes Protokoll zu basteln. Vorher hatte ich schonmal zum Spaß eine Mischung aus Action Replay und Turbo Disk für das SD2IEC gebaut, die etwa 15 KByte/Sek schaffte. Aber Jiffy-kompatibel fand ich's am Schluss sinnvoller, weil dann auch andere Leute (SD2IEC, CMD, inzwischen auch 1541-III) potentiell was davon haben.
-
Ö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.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? -
Heißt das, ich könnte das einfach in mein Programm (open source, zlib-Lizenz) einbauen und einfach keinen Lizenztext drüberschreiben?
Von mir aus klar.
-
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.
-
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.
-
Auf
http://picobay.com/dtv_wiki/index.php?title=SJLOAD
findet sich eine grundsätzlich funktionierende Version von SJLOAD, einem Software-Schnelllader für Jiffy-Laufwerke. Das Programm ist für die Leute gedacht, die einen C64 und eine Jiffy-Floppy haben, aber im C64 kein Jiffy eingebaut ist, oder z.B. die, die einen C64(DTV) mit SD2IEC benutzen.Ich hab' doch tatsächlich noch was dran gemacht. In SJLOAD 0.96 funktionieren die von VDOS "geerbten" Features wieder richtig (Anzeige Verzeichnis, Senden von Kommandos, Auslesen des Fehlerkanals, Save von SJLOAD auf neue Diskette). Dateien größer 195 Blöcke lädt's leider immer noch nicht.