welche neuen DOS-Befehle haben SD2IEC, MMC, Ultimate etc.?

Hi!

Hat jemand eine Übersicht, welche neue Hardware welche DOS-Befehle unterstützt bzw. inwiefern neue Befehle zwischen den Geräten kompatibel sind?
Ich bin gerade darüber gestolpert, als ich in einem Programm mit "cd" ins übergeordnete Verzeichnis wechseln wollte.
Laut Docs aus dem Netz benutzen die CMD-Geräte die Syntax "cd:{LEFTARROW}". Ich bin naiv davon ausgegangen, dass CMD damit den Standard für die Nachfolger gesetzt hat. Zumindest VICE mit Lokaldateisystem-"Laufwerk" scheint diese Syntax aber nicht zu kennen, so dass dort nur "cd:.." funktioniert.

Wie sieht es in dieser Hinsicht mit den diversen SD-Karten-Lösungen aus?
Und inwiefern sind deren d64-Mount-Befehle kompatibel?
Ich habe keinen dieser Massenspeicher (nur meine eigene PC-Slave-Lösung, deren Syntax ich jederzeit anpassen könnte) und fände technische Informationen zu deren Unterstützung daher sehr nützlich.
Also, hat vielleicht schon mal jemand sowas vorbereitet?

Zitat von Unseen

Versuch mal in VICE "cd{LEFTARROW}" ohne Doppelpunkt, das wird ebenfalls von den CMD-Laufwerken akzeptiert.

Danke, das funktioniert. Ich würde es allerdings durchaus als Bug in VICE bezeichnen.

Vor langer, langer Zeit habe ich eine DOS-Befehls-Liste mal auf der GO64-Mailingliste angefangen, das Ergebnis ist immer noch auf meiner alten Homepage verfügbar (hier). Wäre schade wenn sich in den letzten zehn Jahren nichts an der Dokumentationsfront getan hat...

Zitat von Unseen

Wieso? Die Ohne-Doppelpunkt-Syntax ist bei CMD dokumentiert

Sorry, mein Fehler. Die HD-Doku führt die Möglichkeit tatsächlich als Beispiel auf, die FD-Doku (welche ich vor dem Schreiben des Betrags konsultiert hatte) erwähnt sie zumindest im Fließtext als mögliche Alternative. Wäre schön gewesen, wenn CMD für die Erweiterungen eine strikte Syntax definiert hätte, anstatt in dieser Hinsicht Commodore nachzueifern: Da die erhältliche Dokumentation in den wenigsten Fällen eine exakt zu nennende Spezifikation enthält, muss man beim Nachbauen des DOS-Befehls-Interface zwangsläufig das ROM-Listing konsultieren.
Ich merke mir mal vor, einen VICE-Patch einzuschicken...

Zitat von 1st1

Deine eigene PC-Slave-Lösung wäre sicher auch für die Allgemeinheit interessant...

Jein. Vielleicht. Ich hab kein verstärktes Interesse daran, das Programm für mich zu behalten (deshalb erwähne ich auch es immer dann, wenn ich eine potentielle Nutzung sehe), bin mir aber darüber im klaren, dass gewisse Eckpunkte für viele eher abschreckend sind - ich hab das Programm halt in erster Linie für meine Bedürfnisse gemacht: Es hat die Features bekommen, die ich haben wollte, und wenn mich eine Beschränkung nicht störte, hab ich sie nicht entfernt. Hinzu kommt, dass mit 64hdd und 64net bereits Programme existieren, die quasi den gleichen "Markt" abdecken. Aber wenn es jemand ausprobieren/benutzen/mitentwickeln will, nur zu! Bisher schien mir dies aber hinreichend unwahrscheinlich, dass ich mich nicht um eine Download-Webseite oder eigene F64-Rubrik gekümmert habe.

Meine Ziele waren:
-Es muss unter Linux laufen (das zu ändern ist möglich, aber nicht ganz trivial, da ich inzwischen recht viele POSIX-Calls benutze).
-Ich will vom CBM aus Zugriff auf das Dateisystem des PC haben (also wenn hier im Forum eine Datei namens "downfall.prg" angeboten wird, speichere ich sie mit dem Browser in ein bestimmtes Verzeichnis, setze mich an den CBM, schalte ihn ein und kann sofort die Datei laden. Genau so funktioniert es auch in der Praxis)
-Es muss den 64er und den 128er-Modus unterstützen (tut es).
-Da CMD einen Befehlsstandard für Verzeichnisse, Partitionen etc. geschaffen hat, soll es diesen unterstützen (tut es auch - meine "Partitionen" sind derzeit einfach Symlinks auf bestimmte Verzeichnisse)
-Es soll schnell sein (Load schafft ca. 14 KiB/s, Save immerhin ca. 8KiB/s - real von der Server-Software gemessene Werte)
-Es soll ein möglichst einfach gestricktes Kabel ohne weitere Hardware benutzt werden (neunpolig zwischen Userport und Parallelport)

Die von mir akzeptierten Beschränkungen sind:
-Im CBM wird ein Wedge benötigt, da das System nicht den seriellen Bus benutzt (tatsächlich wird dieses Wedge ebenfalls bei jedem Start vom Server geholt, der Bootstrap-Code im CBM ist nur 47 Byte lang und sitzt im U36 meines 128ers. Dort sitzt auch eine Funktion, die so in den 64er-Modus geht, dass dort per Druck auf Restore das 64er-Wedge gestartet wird), daher funktioniert das System auch nicht mit Nachladern. Das ist ein klarer Nachteil, aber mit dem kranken IEC-Protokoll wollte ich mich nun wirklich nicht rumärgern (davon hab ich die Nase voll, seit ich es für das RISC OS-Programm "!AccessIEC" in ARM-Assembler implementiert habe). Eventuellstens mache ich irgendwann mal einen Kernalpatch mit diesem Wedge und flashe einen Alternativkernel, aber im Augenblick stört mich die Inkompatibilität mit Nachladern wirklich nicht sehr.
-Im PC wird ein echter Parallelport benötigt, unidirektional reicht aus (im Grunde genommen braucht das Programm nur fünf Inputpins und drei Outputpins, ließe sich also vermutlich auch recht schnell auf GPIOs z.B. eines RasPi umstricken - abgesehen von einer möglichen Anpassung der Spannungen, das überlasse ich den Hardwaregurus).

Zeug, das ich nicht brauche, aber implementiert habe, "weil es geht":
-Das Programm emuliert gleichzeitig mehrere Geräte am Bus. Das Wedge im CBM fragt erst den PC, und wenn dort kein Gerät mit dieser Nummer konfiguriert ist. sieht es auf dem echten IEC-Bus nach.
-Eine Drucker-Emulation ist angefangen. Zumindest das reine Mitloggen der Daten ist sehr einfach möglich.
-Sequentielle und User-Dateien, Append-Modus, Save-with-Replace und son Kram hab ich nachgebaut. REL-Files sind nur vorbereitet, weil ich keine exakte Spezifikation habe und zu faul war, deswegen das ROM-Listing zu dechiffrieren.

Tja, mehr fällt mir erstmal nicht ein. Meinst Du immer noch, dass das Projekt sicher auch für die Allgemeinheit recht interessant ist?
Ach ja, falls die ZoomFloppy auch einen Betrieb am 64er erlaubt (als ATN nicht nur senden, sondern auch empfangen kann), wäre diese Hardware evtl. eine Möglichkeit, mein Programm kompatibel zum IEC-Bus zu bekommen. Man müsste halt den Bitbanging-Teil durch ein entsprechendes USB-Interface ersetzen.

So, beim finalen Durchlesen dieses Texts ist mir prompt noch aufgefallen, dass ich den Namen des Programms noch gar nicht genannt habe.
Es heißt "TrapThem", hat keine Bugs, zeichnet sich durch perfekt nachvollziehbare Spielmechanik aus, und erfahrene Puzzlespieler haben es als Meisterwerk bezeichnet.
Es heißt "Slave2CBM", ich hab es vielleicht hie und da schon mal erwähnt.