sd2iec (Firmware) 0.8.0 und 0.6.7

  • sd2iec (Firmware) 0.8.0 und 0.6.7

    Hi!

    Nachdem das mit dem Feedback zu Version 0.8.0pre1 ja so hervorragend geklappt hat (ein Kommentar per Mail) kann ich wohl bedenkenlos 0.8.0 veröffentlichen ohne nennenswert zu testen. ;-)

    Die Unterschiede von 0.7.3 zu 0.8.0pre1 gibts im alten Posting, in der 0.8.0 gibts zusätzlich noch:
    • Direkten Sektorzugriff auf die SD-Karte
    • DEL-Dateien werden bei der Wildcardsuche ignoriert
    • Kommando zum Einstellen des Diskmappers (weiterhin nur bei uIEC eincompiliert)
    • Support für den Fastloader im EXOS-Kernal
    • Öffnen einer Datei auf einem schon offenen Kanal schliesst die vorherige Datei

    Der direkte Schreibzugriff sollte besonders für die intensiven PC-Verweigerer interessant sein, die jetzt die Möglichkeit haben ein Partitionierungs- und Formatiertool auf dem C64 zu schreiben. ;-) Sollte mal jemand eine Hardware mit integriertem Dataflash bauen wollen wäre das sogar recht praxisnah um den Chip überhaupt mit einem Filesystem füllen zu können.

    Das Ignorieren von DEL-Dateien bei Wildcard-Suche ist zwar inkompatibel zu den 15xx-Laufwerken, ich wüsste aber keinen Grund wieso das bei irgendeinem Programm Probleme machen würde. Es ist immer dann praktisch wenn man ein "dekoriertes" D64 hat bei dem der erste Eintrag ein zur Deko gehörendes DEL-File ist - in dem Fall funktioniert LOAD":*",8 jetzt trotzdem.

    Das Kommando zum Einstellen des Diskmappers ist XD, weitere Details bitte dem Quellcode entnehmen oder Jim Brain freundlich fragen ob er nicht einen Abschnitt fürs README schreiben will - ist immerhin sein Code und seine Hardware die davon profitiert.

    Der EXOS-Fastloader war bemerkenswert einfach zu implementieren, das Protokoll ist nämlich identisch zu dem des Final Cartridge III. Allerdings ist die EXOS-C64-Seite etwas langsamer, daher mussten zwei Verzögerungen minimal erhöht werden. Meiner Meinung nach stammen beide Loader aus einer gemeinsamen Quelle - der vom FC3 hat einige platzsparende Optimierungen eingebaut (zB andere Codeanordnung damit der Jobcode am Anfang liegt) die in EXOS fehlen, andererseits benutzt der von EXOS intensiv die Zeropage für seine temporären Daten die der vom FC3 IIRC irgendwo bei $6xx ablegt.

    "Öffnen einer Datei auf einem schon offenen Kanal schliesst die vorherige Datei" klingt evtl. erstmal komisch, aber ich kenne inzwischen zwei Spiele die genau diesen Bugfix brauchen (Castle Wolfenstein und Weird Dreams).

    Die Neuerungen in sd2iec 0.6.7 beschränken sich genau auf letzteres plus zwei kleinere Timingfixes.

    Am REL-Support hat sich in 0.8.0 im Vergleich zur pre1 nichts geändert, ebensowenig am Code der FAT-Library - die Warnung bezüglich des FSINFO-Supports bei FAT32-Karten gilt also weiterhin.

    Download wie üblich unter sd2iec.de, git-Repository-Webinterface unter sd2iec.de/cgi-bin/gitweb.cgi?p=sd2iec.git;a=summary

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • Muss ich doch endlich mal mein Arbeitszimmer fertig einräumen, damit ich mein Zeug wieder aufbauen kann... Vielen Dank auch im Namen der schweigenden Mehrheit, dass Du so unermüdlich an der Software arbeitest!

    Wenn man die Vorgänge hier im Forum und bei NKC verfolgt, sieht man, wie verbreitet die Hardware inzwischen ist. Das wäre sie sicher nicht ohne die lebendige Software.

    Weiter so!

    Thomas
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Bau Dir ein eigenes Modul! EasyFlash
  • skoe schrieb:

    Wenn man die Vorgänge hier im Forum und bei NKC verfolgt, sieht man, wie verbreitet die Hardware inzwischen ist.

    Für die englischsprachigen Leute ist evtl. noch die uIEC-Googlegroup interessant - man kann die auch als klassische Mailingliste lesen, Anmeldeadresse dafür ist uIEC-users+subscribe@googlegroups.com.

    Das wäre sie sicher nicht ohne die lebendige Software.

    Na ja, wenn ich mir so anschaue wie viel Zeit zwischen einigen Commits vergangen ist...

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • Ich werde den 2ten mal bei Gelegeheit in die Exos Kiste reinbasteln.

    Irgenwie deucht es mich als das des sd2iec mit jiffy ähnlich schnell wie das NeoRam ist. Rennt wie hulle. :hammer:
    DrZarkov: Die ersten in Serie produzierten Androiden für den Privatgebrauch werden keine Androiden, sondern Gynoide sein (vermutlich im Aussehen einer asiatischen Teenagerin). Und die geistige Fähigkeit wird aureichen "oh toll, Schatz" (oder auch ああ、本当に素晴らしい、蜂蜜!) zu stöhnen, und sich selbst sauber zu halten....
  • jackdaniels schrieb:

    zum d81 support aus dem anderen thread:

    wenn der doch so inkompatibel ist, wieso kommt der dann überhaupt rein?

    Warum wurde D64-Support implementiert, obwohl der so inkompatibel ist?

    und wird er auch in der 1.6er version sein, also der mit mega32 ? eher nicht oder?

    Die derzeit neueste Version von sd2iec, die noch auf einem ATmega32 läuft ist 0.6.7. Ich kann nicht ausschliessen, dass dafür noch weitere Versionen folgen bei denen Bugs beseitigt werden, ich werde jedoch keine Features aus neueren Versionen übernehmen.

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • Unseen schrieb:

    Warum wurde D64-Support implementiert, obwohl der so inkompatibel ist?


    naja weil d64 nun wohl wesentlich verbreiteter ist als d81
    zudem die meisten programme/spiele auf d64 aufsetzen

    d64 gibts massenhaft, aber ich wüsste jetzt keinen einzigen fall wo ich eine d81 emulation/unterstützung brauchen würde

    das war ja auch nur ne frage... erklär es mir dann bin ich schlauer :D
    zudem ein feature mehr freut mich.... solange es nit auf kosten von anderen sachen implementiert wird


    das für 0.6.7 nicht mehr viel kommt ist klar... dachte nur, daß das für da auch geplant wäre.
    dann is ok

    danke dir
  • jackdaniels schrieb:

    d64 gibts massenhaft, aber ich wüsste jetzt keinen einzigen fall wo ich eine d81 emulation/unterstützung brauchen würde
    Wie von mir dummerweise im anderen Thread geschrieben ist ein Containerformat, das bei ordentlicher Kapazität sektorweisen Zugriff erlaubt, recht praktisch. Ansonsten lässt sich (ohne speziellen Treiber) mit z.B. GEOS nicht wirklich arbeiten, wobei dafür auch noch Unterstützung für den GEOS-Fastloader bei sd2iec fehlt.
  • jackdaniels schrieb:

    d64 gibts massenhaft, aber ich wüsste jetzt keinen einzigen fall wo ich eine d81 emulation/unterstützung brauchen würde

    Wie 1570 schon schrieb ist das zB für GEOS ziemlich hilfreich, ausserdem muss ich dann meine alten 1581-Diskimages nicht umwandeln um sie zu verwenden.

    das für 0.6.7 nicht mehr viel kommt ist klar... dachte nur, daß das für da auch geplant wäre.

    IIRC sind da weniger als 200 Byte frei.

    1570 schrieb:

    wobei dafür auch noch Unterstützung für den GEOS-Fastloader bei sd2iec fehlt.

    Du wolle Drivecode-Binaries habe?

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • jackdaniels schrieb:

    d64 gibts massenhaft, aber ich wüsste jetzt keinen einzigen fall wo ich eine d81 emulation/unterstützung brauchen würde

    Nicht wirklich ein wichtiges Argument, aber wenigstens ein Hinweis: Dreamload kann auch mit einer 1581 umgehen. Manche Demos, die Dreamload benutzen, gibt's deshalb auch auf d81 (ohne Disk umdrehen). Die könnten mit der 0.8 funktionieren. Hab leider im Moment keine Möglichkeit, das auszuprobieren.
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Bau Dir ein eigenes Modul! EasyFlash
  • skoe schrieb:

    Nicht wirklich ein wichtiges Argument, aber wenigstens ein Hinweis: Dreamload kann auch mit einer 1581 umgehen. Manche Demos, die Dreamload benutzen, gibt's deshalb auch auf d81 (ohne Disk umdrehen). Die könnten mit der 0.8 funktionieren. Hab leider im Moment keine Möglichkeit, das auszuprobieren.

    69 Positions meldet auf dem Startbildschirm eine 1541 und funktioniert aus dem D81-Image wie zu erwarten einwandfrei. =)

    Ich frage mich nur gerade, wieso ich die 1571-Version davon nicht getestet habe...

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • Unseen schrieb:

    69 Positions meldet auf dem Startbildschirm eine 1541 und funktioniert aus dem D81-Image wie zu erwarten einwandfrei. =)

    Da haben sich Ninja und DocBacardi ein schönes generisches Protokoll einfallen lassen. Obwohl sie damals nie ahnen konnten, dass jemand eine 3,5" Disk in eine 1541 stopft :hammer:
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Bau Dir ein eigenes Modul! EasyFlash
  • WTE schrieb:

    Gibt es auch REL-Support?

    Niemand liest Changelogs oder Release-Announcements...

    Ja, aber nur für R00-Dateien und kaum getestet. REL in einem Diskimage wird bisher nicht unterstützt.

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • Unseen schrieb:

    Niemand liest Changelogs oder Release-Announcements...

    Ja, aber nur für R00-Dateien und kaum getestet. REL in einem Diskimage wird bisher nicht unterstützt.

    Asche auf mein Haupt, aber da mein SD2IEC immer noch nicht vom Lötknecht zurückgekomen ist, ist der Leidensdruck die READMEs zu lesen einfach zu gering :bgdev

    Ich werde erstmal R00-Files im Emu testen, ob da überhaupt 3600-Block-lange REL-Files (wie auf eine 1581) möglich sind.

    Gruß WTE
  • @FXXS: Lass einfach beide, was solls.

    @Unseen: Ich habe gestern (mangels SD2IEC, s.o.) die R00-Files auf Vice ausprobieren wollen und dazu ein Programmpaket aus einem D81 in PC64-Files umgewandelt. Es war nicht einmal möglich R00-Files unter VICE zu erstellen! Entweder wird R00 nicht unterstützt oder es bedarf einer speziellen (mir unbekannten) Einstellung.

    Die Probleme begannen allerdings schon vorher. In Vice scheint ein BUG bei der P00-Erstellung zu existieren. Wenn man zwei CBM-Files mit sehr ähnlichem Filenamen hat z.B. "Dateiname.._.ext" und "Dateiname....ext" und die in VICE mit einem File-Kopierprogramm von einem Image in ein PC-Directory auf die Platte als PC64-Datei kopiert, werden vom System (in manchen Fällen und ich hatte einen solchen) identische Namen für die PC-Files erzeugt - das ist an sich nichts ungewöhnliches. Lauf Definition der PC64-Files werden die Dateien dann durch das Suffix unterschieden. Die erste Datei bekommt das bekannte "p00" die zweite "p01"; bis "p99" ist möglich.

    Und jetzt der Hammer: VICE zählt nicht hoch! Die zweite Datei bekommt auch die Endung "p00" und überschreibt die erste. Da das auf PC-Ebene passiert und die Filenamen auf CBM-Ebene unterschiedlich sind, erfolgt das ohne jede Rückfrage. Ich habe eine halbe Stunde gebraucht bis ich das bei meinen 200 Dateieinträgen im Directory gepeilt habe.

    Leider kann ich das nun beim SD2IEC nicht selber testen, aber vielleicht kann ja jemand anderes versuchen die Erzeugung von "p01" zu erzwingen. Ich nehme mal an, das SD2IEC ist da besser als Vice...

    Gruß WTE
  • WTE schrieb:

    @Unseen: Ich habe gestern (mangels SD2IEC, s.o.) die R00-Files auf Vice ausprobieren wollen und dazu ein Programmpaket aus einem D81 in PC64-Files umgewandelt. Es war nicht einmal möglich R00-Files unter VICE zu erstellen! Entweder wird R00 nicht unterstützt oder es bedarf einer speziellen (mir unbekannten) Einstellung.

    Ich weiss, VICE hat ein paar Bugs bei R00. Das Problem mit überschriebenen Dateien ist mir aber bisher noch nicht aufgefallen, trags am besten mal in deren Bugtracker bei Sourceforge ein.

    Mit PC64 funktionierts...

    Leider kann ich das nun beim SD2IEC nicht selber testen, aber vielleicht kann ja jemand anderes versuchen die Erzeugung von "p01" zu erzwingen. Ich nehme mal an, das SD2IEC ist da besser als Vice...

    Aber natürlich. Nicht implementiert ist allerdings das Erzwingen des PC64-Fileformats, wenn das Format eigentlich abgeschaltet ist aber der Name nicht in FAT darstellbar ist. Ist evtl. auch besser so, sonst fragt bestimmt irgendwann jemand wieso sein vom C64 aus erstelltes D64-Diskimage einen PC64-Header hat...

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • Benutzer online 1

    1 Besucher