sd2iec 0.8.0pre1 (Firmware-Prerelease)

  • sd2iec 0.8.0pre1 (Firmware-Prerelease)

    Hi!

    Da ich derzeit kaum dazu komme am Code weiterzubasteln und es bis zur Fertigstellung einiger fehlender Features so noch ziemlich lange dauern würde gibts als Abwechslung mal ein schlecht getestetes Pre-Release. Backups werden dringend empfohlen.

    Neues in sd2iec 0.8.0pre1 "Feeping Creaturitis":
    • Dreamload-Support (Dank an skoe)
    • RTC-Support (nicht eincompiliert)
    • Dataflash-Support (nicht eincompiliert)
    • Diskmapper (nicht eincompiliert)
    • Multi-File-Scratch (d.h. S:foo,bar - * und ? gingen auch vorher schon)
    • Copy-Befehl ("C:ziel=quelle", auch mit mehreren Quelldateien zum Aneinanderhängen)
    • Support für grosse Buffer
    • Fastloader von FC3-gefreezten Programmen wird unterstützt
    • D71/D81-Images
    • Auswertung des FSINFO-Sektors
    • teilweiser REL-Supprt

    Als RTC kann entweder ein PCF8583 oder eine reine Software-Implementierung verwendet werden - letztere verliert die Zeit bei jedem AVR-Reset und geht schnell ein wenig nach wenn Fastloader verwendet werden da diese die Interrupts häufiger abschalten. Die Befehle dafür sind CMD-kompatibel (T-R und T-W in allen drei Formaten), werden aber nur akzeptiert wenn RTC-Support eincompiliert ist und im Fall von T-R nur dann wenn die RTC auch ein gültiges Datum enthält.

    Dataflashes sind kleine 8-Pin-Chips mit bis zu 16MB Flash-Speicher, unterstützt wird im Augenblick nur ein AT45DB161D mit 2MByte der als zusätzliche Partition eingebunden wird. Dummerweise gibts keinen einfachen Weg den Chip mit einem Filesystem zu versehen, es ist geplant das mit einem C64-Programm zu machen welches ein leeres Filesystem mit den noch nicht implementierten Befehlen zum direkten Beschreiben der angeschlossenen Medien auf den Chip schreibt.

    Der Diskmapper ist nur interessant wenn mehr als ein Speichertyp angeschlossen ist und erlaubt es die physischen Laufwerke (d.h. zwei SD-Slots, vier ATA-Geräte, ein Dataflash) in beliebiger Reihenfolge einzubinden oder auszulassen (nach nicht angeschlossenen ATA-Geräten zu suchen kann bis zu 30 Sekunden dauern). Die Einstellung wird schon jetzt aus dem EEPROM gelesen bzw. darin gespeichert, aber es gibt noch keinen Befehl um das Mapping zu ändern.

    Multi-File-Scratch rüstet nur ein Feature nach das die 1541 schon lange bot, obwohl mir bisher nichts begegnet ist was es ausnutzt.

    Das Copy-Kommando war dringend nötig um den Dataflash-Support testen zu können. =) Wildcard-Kopien mehrerer Dateien zwischen verschiedenen Partitionen/Verzeichnissen geht leider nicht, aber meines Wissens können die CMD-Laufwerke das auch nicht.

    Grosse Puffer sind im Augenblick total nutzlos weil es keine Kommandos gibt die einen solchen benötigen, das ist erst für den noch zu implementierenden Medien-Direktzugriff notwendig weil die Sektoren dort 512 Byte gross sind. Wenn jemand anderes das implementieren möchte habe ich ein paar Codeschnippsel rumliegen für ein Identify-Kommando mit dem C64-Software die Mediengrösse abfragen könnte, incl. einer Routine die die Sektoranzahl einer MMC/SD/SDHC-Karte ermitteln kann.

    Zum FC3-F.DISK-Fastloader muss ich vermutlich nicht viel schreiben - er ist dem normalen ziemlich aber nicht komplett ähnlich.

    D71/D81-Images funktionierten bei meinen Tests einwandfrei (u.a. mit Software auf .d81 die direkte Sektorzugriffe macht), sind aber nicht besonders intensiv getestet. Durch die Änderungen kann es evtl. auch zu Problemen bei D64 kommen.

    Die FSINFO-Sektor-Auswertung ist etwas problematisch - ich bin mir sicher das ich mir mal den Inhalt einer Karte mit Datenmüll an ungünstigen Stellen vernichtet habe als ich zuletzt in der FAT-Library das Feature eingeschaltet habe, andererseits musste ich da erstmal einen Bugfix vornehmen damit der Sektor überhaupt gefunden werden konnte. Bei kleineren Tests gabs bisher keine Probleme mehr, aber evtl. betrifft es nur bestimmte ungünstige Situationen. Wenn es funktioniert sollte die Anzeige der freien Blöcke bei FAT32-Karten deutlich schneller erfolgen, diese könnte dafür aber gelegentlich fehlerhaft sein.

    REL-Support ist (IIRC, Jim hats implementiert) bisher nur teilweise funktionsfähig, das Anlegen neuer Dateien und das Erweitern einer bestehenden verhält sich IIRC nicht ganz so wie es sollte (Löschen neuer Datensätze fehlt?). Auf jeden Fall funktioniert es derzeit nur mit .R00/.REL-Dateien und nicht in Disk-Images, aber das genügt zB um Castle Wolfenstein nach Wandlung in .x00-Dateien zu spielen. Bei .REL-Dateien ist das erste Byte der Datei die Record-Länge, das Parsen von .Lxx-Suffixen wie es cbmconvert verwendet war dann doch zu blöd. Vorsicht: IIRC kopiert der Star Commander nur die Inhalte von .REL-Dateien aber wirft die Recordlänge komplett weg.

    Als netter Seiteneffekt des REL-Supports funktioniert das P(osition)-Kommando auch für nicht-REL-Dateien die im FAT-Filesystem liegen, aber zwecks kompatiblem Kommandoformat (drei Byte die den Offset angeben) nur bis Offset 2^24-1 (1 Byte unter 16MB).

    Sonstige Kleinigkeiten: Die LarsP-Konfiguration wird jetzt zusätzlich als .bin-File für den Bootloader compiliert, die ID ist 0x5053524c; beide Compilate sind im gleichen Archiv.

    Dazu noch ein Stapel kleinerer Bugfixes für deren Auflistung ich gerade zu faul bin, bei Interesse ist alles im Commit-Log nachzulesen.

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

    Oh, einen habe ich noch: Wenn beim Einschalten die NEXT-Taste gedrückt ist werden die Daten im EEPROM ignoriert (aber nicht überschrieben).

    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

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Unseen ()

  • Benutzer online 1

    1 Besucher