sd2iec 0.6

  • So, um alx zu ärgern weil ich gerade keinen Bug mehr finde gibts ein neues sd2iec-Release.

    Es sieht im Augenblick danach aus, als ob es das letzte Release wäre was auf dem ATmega32 lauffähig ist - es sind noch 866 Byte Flash frei (plus 2K für den Bootloader wenn man direkt programmiert) und beim Ram müsste mal jemand eine genaue Analyse machen wie gross der Stackverbrauch maximal werden kann. Ein paar Tests mit Protokollfunktionen lieferte eine maximale Belegung von 254 Byte, allerdings mit aktiven UART-Debugging (ist im Release nicht drin) und auf einem mega644 (weil der Code mit Instrumentierung >32K ist). Solche Tests sind allerdings bestenfalls ein Indiz, der tatsächliche Maximalverbrauch könnte höher liegen - sofern das nicht mehr als ca. 40 Byte sind passt es aber noch.

    Die Archive haben ein neues Namensschema, da ich mein Makefile umgebaut habe - larsp sollte klar sein, sw1 sind Shadowolfs MMC2IEC 1.x-Platinen, sw2 sind seine sd2iec 1.x-Platinen. Von allen drei Varianten gibts im Augenblick nur Compilate für die typischerweise verwendeten CPUs, sollte jemand Bedarf für ein mega644-Binary für sw1- oder larsp-Hardware haben bitte selber bauen oder freundlich fragen.

    Bugfixes in 0.6:
    • B-R und B-W funktionieren jetzt so wie von Commodore dokumentiert - damit funktioniert jetzt Pirates einwandfrei. Interessanterweise behauptet fast jede Sekundärliteratur zu den Laufwerken, dass B-R/B-W defekt und/oder nutzlos wären... Ein wenig mehr Details zu dem Thema gibts hier.
    • I schliesst alle offenen Kanäle - Drazpaint verlässt sich auf dieses Verhalten
    • Beim Schliessen von Kanal 15 wird eine neue Fehlermeldung generiert - keine Ahnung ob irgendeine Software sich darauf verlässt, aber da das nötig ist um nur den numerischen Fehlercode auslesen zu können wird es bestimmt Kandidaten geben.
    • Ungültige Track-/Sektornummern bei D64-Behandlung werden angemeckert - auf vielfache Bitte eines Einzelnen. ;-)


    Neue Features in 0.6:
    • Einige Umstrukturierungen im Quellcode (die wirklich grossen kommen aber noch)
    • M-R liefert Daten zurück - damit stimmt der Faktor beim 64'er Speed Test in diesem Punkt jetzt auch, leider nur 0.97x weil mein IEC-Code einen Tick langsamer als das Orginal ist
    • Geräteadresse ist via U0> änderbar, wie bei der 1571/1581 auch
    • Geräteadresse wird bei XW im EEPROM gespeichert - dadurch ändert sich das EEPROM-Format und mit 0.5 erstellte Einträge werden nicht mehr erkannt. Erkennung alter Configeinträge ist für Version 1.1 geplant.
    • E-R/E-W: Jemand aus dem VicePlus-Team fragte, ob er Zugriff auf das EEPROM des Atmels bekommen könnte, um darin die Konfiguration seines (unfertigen) Filebrowsers ablegen zu können. Die Syntax beider Befehle ist identisch zu M-R und M-W, die Länge beim Lesen ist allerdings durch die Grösse des Fehlerpuffers (35 Byte) beschränkt. Ich empfehle die Einrichtung einer Arbeitsgruppe um ein Protokoll auszuarbeiten damit sich mehrere Programme dieses Features bedienen können ohne ihre Daten gegenseitig zu überschreiben. Es sind zur Zeit 512 Byte Speicher verfügbar, die sd2iec-Konfiguration ist über diese Befehle nicht erreichbar.
    • FAT-Verzeichnisse die mit . anfangen werden ausgeblendet, sind aber noch sichtbar wenn man versteckte Dateien (*=H) anzeigen lässt
    • Lange Dateinamen auf FAT - M2Is sind teilweise obsolet. =) Dank Jim Brain kennt die FatFs-Library jetzt auch lange Dateinamen und nach einigen Tagen Fehlersuche hoffe ich, dass diese Version von FatFs auch keinen Karteninhalt mehr shreddert. Aus Speicherplatzgründen werden Dateien mit Namen länger als 16 Zeichen trotzdem mit ihrem 8.3-Filenamen angezeigt, ausserdem ist die Zeichenkonvertierung (VFAT verwendet Unicode) gemogelt, so dass Sonderzeichen komisch aussehen können.

    Wegen der neuen Fat-Library empfehle ich bei dieser Version besonders darauf zu achten, dass von allen wichtigen Daten auf der Karte Backups existieren - wenn ein Schreibzugriff danebengeht können auch Daten beschädigt werden die man eigentlich gar nicht angerührt hat!

    JiffyDos ist in dieser Version per Default abgeschaltet weil mir gerade aufgefallen ist, dass ich vergessen habe das noch vor dem Release zu ändern. ^^; Einfach mit @"XJ+" einschalten und mit @"XW" die Einstellungen speichern.

    Eine im EEPROM gespeicherte Geräteadresse wird nur verwendet, wenn die Adressen-Jumper genauso eingestellt sind wie zum Speicherzeitpunkt - es besteht also kein Risiko, dass man auf einmal einen Satz auf 8 konfigurierter Platinen hat und die einzeln an den Rechner hängen muss um die Adresse ändern zu können. Man kann sich das Feature im Prinzip auch so vorstellen, dass es die Bedeutung der aktuellen Adressen-Jumper-Einstellung ändert falls diese Beschreibung nicht zu "unhandlich" ist.

    Ach ja, sd2iec ist jetzt auch in einer uIEC-Konfiguration (uIEC v2, mit mega128) compilierbar und da Jim keinen Patch nachgeschoben hat ist die vermutlich sogar lauffähig - wegen sehr
    geringer Verbreitung gibts aber erstmal kein Binary dafür.

    Juhu, mal wieder die URLs vergessen:

    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
  • DrCreep schrieb:

    Noch ne Neuigkeit ist mir grad aufgefallen :

    Man kommt jetzt auch mit CD:/ aus D64s und M2Is raus (also zurück) - ging vorher nicht

    Huch? Verwendest du die gleiche Software die ich verwende? Dem Code nach sollte das nicht gehen und einem kurzen Test nach geht das tatsächlich nicht.

    Imagedateien als echtes Verzeichnis zu behandeln ist eh erst für 0.7 geplant, sofern dann alle potentiellen Probleme gelöst sind (zB: Was soll CD// machen wenn es in einem Imagefile aufgerufen wird, welches selbst Support für Unterverzeichnisse hat? Vom potentiellen Spass mit mehreren offenen Dateien in unterschiedlichen Images ganz zu schweigen.)

    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:


    Huch? Verwendest du die gleiche Software die ich verwende? Dem Code nach sollte das nicht gehen und einem kurzen Test nach geht das tatsächlich nicht.


    Stimmt, hab die falsche Taste gedrückt.
    Sorry, mein Fehler - ich nehm's zurück :D


    Und ja - Pirates! läuft jetzt ENDLICH !! Danke !!
  • Muß ich der Binärdatei einen besonderen NAmen verpassen damit der Bootloader sie updatet ?
    Ich habe einfach sdc2iec.bin auf die SD Card kopiert, aber es wird kein Update durchgeführt.
    Beim ersten Start nur mit Bootloder hat alles funktioniert.

    Grüße

    Dirk
  • Der Name ist egal.

    Hast Du den Bootloader mal aktualisiert?
    Deine beiden Geräte gehören noch zur ersten Welle der 1.6'er und da war der Bootloader noch nicht
    ganz so schlau - der kann nur Versionen grösser als der bereits vorhandenen laden.

    Die erste Änderung im Bootloader war, dass der Version.Revision = 0.0 immer lädt.
    Und so ist die sd2iec Software auch momentan kodiert.
  • Nabend.

    Unseen schrieb:

    So, um alx zu ärgern weil ich gerade keinen Bug mehr finde gibts ein neues sd2iec-Release.
    ich finde das sooo ruehrend, wie du dich um mich kuemmerst.


    Also nun zum ernst der lage:
    • das update konnte ich (mal wieder, nicht immer) nur nach einer neuformatierung der karte machen...
    • schoen die langen und grossen namen...
    • aber haetten es denn nicht ein paar mehr seien konnen? (z.B. 16 zeichen name + "." + extension = 20?) [dies ist natuerlich nur ein vorschlag]
    • irgendwie kann ich nicht in m2i's reingehen, wenn die m2i datei als LFN angezeigt wird. bei 8+3 gehts. weiss nicht, ob es an der laenge, oder den anderen zeichen liegt.
    • natuerlich gibt es ab sofort eine neue fibr version, die die neuen grossen buchstaben korrekt darstellt.
    • ansonsten:
    • feine sache!

    Es sieht im Augenblick danach aus, als ob es das letzte Release wäre was auf dem ATmega32 lauffähig ist
    also brauche ich eine neue hardware wenn ich neuere firmwares nuzten will??

    Ciao, ALeX.
  • Super, Support für lange Dateinamen und noch einige Verbesserungen mehr. Merci.

    Unseen schrieb:

    Aus Speicherplatzgründen werden Dateien mit Namen länger als 16 Zeichen trotzdem mit ihrem 8.3-Filenamen angezeigt, ausserdem ist die Zeichenkonvertierung (VFAT verwendet Unicode) gemogelt, so dass Sonderzeichen komisch aussehen können.

    Das sind jetzt wahrscheinlich 16 Zeichen inkl. Suffix, oder? Könnte man das auch auf 16 Zeichen zzgl. Suffix erweitern = 20 Zeichen? Dann könnte man lange C64-Namen aus D64-Images, die man in ein Verzeichnis kopiert beibehalten und trotzdem noch ein Suffix (.PRG) anhängen, damit das System (Win/Mac/Lin), auf dem man die SD-Karte zusammenstellt, erkennen kann, dass es sich um C64-Dateien handelt. Oder ist der Aufwand oder der Speicherverbrauch dafür zu hoch?
  • alx schrieb:

    das update konnte ich (mal wieder, nicht immer) nur nach einer neuformatierung der karte machen...

    Der Bootloader ist nicht mein Problem. =)

    aber haetten es denn nicht ein paar mehr seien konnen? (z.B. 16 zeichen name + "." + extension = 20?) [dies ist natuerlich nur ein vorschlag]

    Dann wird das Directoryformat inkompatibel und das Feature um das skern schon lange bettelt unmöglich. Letzteres wäre eigentlich ein tolles Argument dafür... ;-)

    irgendwie kann ich nicht in m2i's reingehen, wenn die m2i datei als LFN angezeigt wird. bei 8+3 gehts. weiss nicht, ob es an der laenge, oder den anderen zeichen liegt.

    Ist die Dateiendung (auf dem PC) gross oder klein geschrieben? Im Augenblick erkennt der Code nur kleingeschriebene Endungen.

    Es sieht im Augenblick danach aus, als ob es das letzte Release wäre was auf dem ATmega32 lauffähig ist
    also brauche ich eine neue hardware wenn ich neuere firmwares nuzten will??

    Wahrscheinlich ja, es ist einfach kein Platz mehr da und ich bin mir nicht sicher ob die geplanten grossen Umbauten an der Struktur den Platzbedarf erhöhen oder verringern. Im Prinzip würde es aber schon reichen auf der Platine den vorhandenen ATmega32 durch einen ATmega644 zu ersetzen - aber das werden vermutlich nur Leute machen wollen die sich ihr MMC2IEC selbst aus DIL-Chips gebastelt haben weil das bei SMD nicht ganz einfach 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
  • jackdaniels schrieb:

    wie kompliziert wäre es denn bei smd? ich hab meine atmega selbst aufgelötet und programmiert... würde ich den umbau auch schaffen?

    Gute Frage... Am einfachsten sind SMD-Chips wohl auszulöten, indem man einfach eine Heissluft-SMD-Lötstation verwendet. =) Für Chips die nur auf zwei Seiten bepinnt sind gibts auch noch den Tip, diese komplett in Lötzinn zu "ertränken" um über das Zinn alle Pins gleichzeitig erhitzen zu können - aber das dürfte beim ATmega eher schlecht klappen weil der dann immer noch auf drei weiteren Seiten festgehalten wird.

    Im Prinzip geht natürlich immer die Radikallösung: Pins vom Chip trennen und einzeln ablöten. Dabei muss man "nur" aufpassen, dass die Leiterbahnen nicht beschädigt werden.

    Falls du irgendeine dieser Varianten versuchen willst erwähne das besser vorher hier im Forum, sonst hast du eine tolle Platine mit neuem Chip drauf aber keine Software die darauf laufen würde (der Bootloader ist bisher nur für den mega32 compiliert hier im Forum zu finden und das m644-Binary von sd2iec 0.6 ist für die inkompatiblen neuen Platinen).

    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
  • mhhh ich hatte (nicht schlagen) bei einer shadowolf platine den atmega falschrum eingelötet LOL, irgendwie falsch auf die vorlage gesehn und schon wars passiert....

    hab das teil einfach mit entlötlitze ausgelötet, war kein ding...

    heißluftfön hab ich auch dazu da... würde aber litze bevorzugen!

    also sehe ich das richtig, daß man dann auch bei jeder version die neu rauskommt dann einmal zusätzlich compilieren müsste nur für "meine" variante?


    noch ein paar fragen... ist in der 0.6er version das jiffy nur aus, weil du es vergessen hast? einfach einschalten und speichern und das wars wieder? das mit der laufwerksnummer ist für mich uninteressant , das werde ich per schalter lösen. sonst noch lange dateinamen, aber viel mehr hat sich unterm strich nicht geändert oder? blick bei eurem "fachchinesisch" manchmal nit ganz durch :D
  • jackdaniels schrieb:

    hab das teil einfach mit entlötlitze ausgelötet, war kein ding...

    Die würde natürlich auch funktionieren. Ich habe die wohl einfach vergessen zu erwähnen weil ich zu den Leuten gehöre die mit Entlötlitze keine vernünftigen Resultate hinbekommen. ^^;

    also sehe ich das richtig, daß man dann auch bei jeder version die neu rauskommt dann einmal zusätzlich compilieren müsste nur für "meine" variante?

    Im Prinzip ja, aber das ist auf meiner Seite kein Aufwand (eine Zeile mehr im Script das alle Archive für ein Release baut), ausserdem habe ich selbst zwei Platinen die so bestückt sind.

    noch ein paar fragen... ist in der 0.6er version das jiffy nur aus, weil du es vergessen hast? einfach einschalten und speichern und das wars wieder?

    Genau.

    das mit der laufwerksnummer ist für mich uninteressant , das werde ich per schalter lösen.

    Och, per Schalter gibts nur 8-11, per Software sind 8-30 möglich...

    sonst noch lange dateinamen, aber viel mehr hat sich unterm strich nicht geändert oder?

    Wenn man mal von den Bugfixes und den Sachen absieht die für Endnutzer noch nicht interessant sind: Ja, mehr ist das nicht.

    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:

    Och, per Schalter gibts nur 8-11, per Software sind 8-30 möglich...

    Entschuldigt, dass ich noch einmal nachfrage: Heißt das (erstens), dass ich den Laufwerksadressen-Schalter bei meinem jetzigen Einbauprojekt einfach weglassen kann, da ich es genauso gut per Software tun kann? Und (zweitens) dass wir in FIBR eine Laufwerksnummern-Umschaltung per Menü für das sd2iec integrieren könnten?

    Und ehe ich lange suche: Wie lautet der Wechsel-Befehl?
  • Retrofan schrieb:

    Entschuldigt, dass ich noch einmal nachfrage: Heißt das (erstens), dass ich den Laufwerksadressen-Schalter bei meinem jetzigen Einbauprojekt einfach weglassen kann, da ich es genauso gut per Software tun kann?

    Wenn es für deine Zwecke ausreicht, ausschliesslich per Software umschalten zu können: Ja.

    Und (zweitens) dass wir in FIBR eine Laufwerksnummern-Umschaltung per Menü für das sd2iec integrieren könnten?

    Wenn ihr wollt... Ich wüsste allerdings keinen Grund wieso man das auf sd2iec beschränken sollte.

    Und ehe ich lange suche: Wie lautet der Wechsel-Befehl?

    Wahlweise mit "U0>"+chr$(adresse) (klappt mit 1570/1571/1581/CMD/sd2iec ab 0.6) oder mit "M-W"+chr$(119)+chr$(0)+chr$(2)+chr$(32+adresse)+chr$(64+adresse) (klappt mit 1540/1541/1570/1571/sd2iec ab 0.5 und evtl. noch anderen Laufwerken).

    Permanent speichern geht bei sd2iec mit "XW", andere Laufwerke können das meines Wissens nur über ihre Jumper/Dipschalter.

    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
  • jo, nur werde ich nie im leben 30 laufwerke besitzten :D

    ist diese softwareumschaltung resetresistent?

    auch wenn ich das sd2iec mal abklemme und zb an meinen vc20 hänge ist dann zb noch die adresse 23 eingestellt?

    zum atmega:
    werde wohl mal eine platine testweise neu bestücken. was kostet der neue atmel denn? damit wird die platine dann quasi zu einer sd1.0 platine?
  • jackdaniels schrieb:

    jo, nur werde ich nie im leben 30 laufwerke besitzten :D

    Mit so vielen Laufwerken würde der Bus auch nicht mehr funktionieren, weil jedes davon einen Pullup-Widerstand auf die Leitungen legt und das dann definitiv mehr ist als die Platinchen treiben können.

    ist diese softwareumschaltung resetresistent?

    Nur wenn sie mit XW gespeichert wurde.

    werde wohl mal eine platine testweise neu bestücken. was kostet der neue atmel denn? damit wird die platine dann quasi zu einer sd1.0 platine?

    Der Chip kostet in Einzelstückzahlen IIRC zwischen 6 und 9 Euro je nach genauer Version (für die Platinen egal sofern das Gehäuse passt) und Lieferant (zB Reichelt oder csd-electronics.de). Die Platine wird damit allerdings nicht zu einer sd2iec1.0-Platine, dafür wären noch deutlich mehr Änderungen notwendig.

    Retrofan schrieb:

    Welche Zwecke wären das denn, wo eine Softwareumschaltung gegenüber einer Hardwareumschaltung ungünstig wäre?

    Der einzige, zugegebenermassen etwas konstruierte Fall der mir einfällt wäre ein C128D und eine auf Adresse 8 eingestelltes sd2iec. Ansonsten wüsste ich nichts wo man ein Laufwerk das gerade einen Adresskonflikt hervorruft nicht problemlos abklemmen könnte um das sd2iec umzustellen.

    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