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:

• http://snowcat.de/sd2iec/ für Quellcode+Binaries
• http://snowcat.de/sd2iec/sd2iec.git zum Repository-Cloning via git
• http://snowcat.de/cgi-bin/gitweb.cgi/sd2iec.git um die Entwicklungskatastrophen via Browser zu begutachten
• "cvs -d :pserver:anonymous@snowcat.de:/sd2iec.git co master" für CVS-Fans

Zitat von DrCreep

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.)

Zitat von Shadowolf

Und so ist die sd2iec Software auch momentan kodiert.

Ich wusste doch das ich vergessen habe irgendwas im ersten Posting zu erwähnen: Diese Version hat eine echte Versionsnummer.

Zitat von alx

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

Der Bootloader ist nicht mein Problem.

Zitat

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...

Zitat

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.

Zitat

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.

Zitat von jackdaniels

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).

Zitat von jackdaniels

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. ^^;

Zitat

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.

Zitat

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.

Zitat

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...

Zitat

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.

Zitat von Retrofan

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.

Zitat

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.

Zitat

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.

Zitat von jackdaniels

jo, nur werde ich nie im leben 30 laufwerke besitzten

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.

Zitat

ist diese softwareumschaltung resetresistent?

Nur wenn sie mit XW gespeichert wurde.

Zitat

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.

Zitat von Retrofan

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.