Lightning VME - USB für den MegaSTE und TT

[Lukas Frank]

Ich hatte am Anfang einen trunk mit USB support aus 2015 und das machte Probleme. Habe dann was aktuelles aus 2018 aufgespielt und keine Probleme.

[Gaga]

Ich habe bei mir die 1-19er Version von Mint und HDDriver nutze ich in irgendeiner 10.xx Version.

@czietz tüftelt an dem Mediachange-Problem.

Das mit der Version R120 behobene Problem, dass SD/CF-Karten nun auch einzeln eingesetzt angesprochen werden können, war zuvorderst zu lösen. Das ist ja nun erfolgt.

Ich mache an dieser Stelle noch einmal Werbung für das TEAC FD-CR7.

[RealLarry]

Ich mache an dieser Stelle noch einmal Werbung für das TEAC FD-CR7.

Interessantes Teil. Wie würde denn dann die Floppy angesprochen werden? Einfach als G: (beispielsweise)?

[Gaga]

Selbstverständlich als Laufwerk A:, bootfähig.

Als Ersatz für ein vorhandenes Floppy.

Nachteil: Man müsste das Gehäuse bearbeiten. Ich stelle nachher mal ein Bild hier ein. Habe es bei mir gemacht.

[RealLarry]

Ja, habe jetzt ein paar Bilder zu dem Teil gefunden. Daran kann man sehen, dass es ein Kombi-Laufwerk mit Floppy-Anschluss ist. Dann ist es klar Ich dachte schon, es wäre eine reine USB-Lösung.
Mit kommt aber dazu gerade die Idee, was passiert, wenn ich ein echtes USB-Floppy-Drive an die Lightning anschließe?
Aber mein TT-Gehäuse werde ich nicht bearbeiten...der sieht noch aus wie neu und rennt auch so.

Ich kann bedingt auch das Kombi-Laufwerk von CSL empfehlen. Bedingt deshalb, weil es relativ einfach (ich will nicht sagen "billig") verarbeitet ist und gelegentlich bei Billig-Disketten wählerisch ist. Ich besitze eines in einem ollen PC und da tut es brav seinen Dienst.

[Gaga]

Wie ihr wisst, bietet der Lightning VME Treiber seit einiger Zeit dank @czietz auch eine USB-Floppylaufwerksunterstützung (1.44MB). Mediachange im laufenden Betrieb wird dort noch nicht unterstützt.

Die Diskette wird dann im System an nächstfreier Stelle eingebunden, also als Laufwerk G: oder so.

Funktioniert gut, wenn man zum Beispiel Disketten kopieren will vom Systemfloppy A: auf USB-Floppy G:
Ich nutze das zur Erstellung der Treiberdisketten. Bisher ohne Probleme. Meine Masterdiskette belasse ich im USB Laufwerk, so dass ich dort keinen Mediachange benötige. Den mache ich an Laufwerk A.

[RealLarry]

Gut zu wissen! Denn ich wusste es noch nicht (aber das kann in meinem Alter schonmal passieren)
Super Arbeit!

[czietz]

Vielen Dank ...

Gerade mal mit einem alten CardReader probiert und jetzt kann ich gleichzeitig CF und SD im Reader benutzen. das ging zuvor nicht, da lief immer nur die CF. Schade das ein Wechsel on the Fly nicht erkannt wird. Kommt das noch irgendwann mal und geht das garnicht mit TOS?

Mediachange steht auf der Todo-Liste, ist aber kein einfach zu lösendes Problem, weil sich auch noch die Laufwerksbuchstaben verschieben können. Nimm an, Du hättest eine CF-Karte mit einer Partition im Reader und die wäre z.B. Laufwerk G:. Dann steckt eine SD-Karte im Reader und die bekommt Laufwerk H:. Nun wechselst Du im Betrieb die CF-Karte zu einer mit zwei Partitionen. Die müssten dann G: und I: heißen (und H: ist weiterhin die SD-Karte)?

Es ist im Treiber (den wir bekanntlich übernommen haben) weder vorgesehen, überhaupt auf Mediachange zu reagieren, noch die Laufwerksbuchstaben so dynamisch umzuordnen. Das bedarf eines gigantischen Umbaus des bestehenden Treibers.

Ist doch so ähnlich wie die LUNs bei SCSI, oder? Mein Reader hat 4 Slots, werden alle unterstützt oder auch mehr ...

Probier es doch bitte aus. Grundsätzlich werden maximal 8 LUNs unterstützt.

[mfro]

Mediachange steht auf der Todo-Liste, ist aber kein einfach zu lösendes Problem, weil sich auch noch die Laufwerksbuchstaben verschieben können. Nimm an, Du hättest eine CF-Karte mit einer Partition im Reader und die wäre z.B. Laufwerk G:. Dann steckt eine SD-Karte im Reader und die bekommt Laufwerk H:. Nun wechselst Du im Betrieb die CF-Karte zu einer mit zwei Partitionen. Die müssten dann G: und I: heißen (und H: ist weiterhin die SD-Karte)?

Es ist im Treiber (den wir bekanntlich übernommen haben) weder vorgesehen, überhaupt auf Mediachange zu reagieren, noch die Laufwerksbuchstaben so dynamisch umzuordnen. Das bedarf eines gigantischen Umbaus des bestehenden Treibers.

Atari hat das m.W. bei den Syquests so gemacht, dass immer vier Partitionen angemeldet und dann halt nur die verwendet werden, die wirklich da sind.

[czietz]

Atari hat das m.W. bei den Syquests so gemacht, dass immer vier Partitionen angemeldet und dann halt nur die verwendet werden, die wirklich da sind.

Über solch ein Verfahren habe ich auch schon nachgedacht, habe es aber wieder verworfen, aus zwei Gründen:
1. Der Treiber unterstützt derzeit auch erweiterte Partitionen und damit mehr als vier Partitionen pro Medium. Ich müsste ihn also künstlich beschränken -- und das ist bestimmt auch wieder jemandem nicht recht.
2. Ein Kartenleser mit zwei Slots würde so gleich acht (2 x 4) Laufwerksbuchstaben dauerhaft belegen. Da man unter TOS (ohne MetaDOS) ja insgesamt nur 16 Laufwerksbuchstaben zur Verfügung hat, fände ich das eine große Verschwendung.

[Lukas Frank]

Kann man da nicht Uwe Seimet überzeugen/einbinden mit seinem HDDriver ?

[1ST1]

Wenn du HDDRIVER und (?) BIGDOS verwendest, hast du auch unter normalem TOS, auch ganz ohne MetaDOS 36 Laufwerke. (a: - z: + 0: - 9: )

[ari.tao]

^^-- Laut Doku 32 Laufwerke A..Z1..6 genau wie auch für MiNT.
Die Laufwerke jenseits von P stehen aber in beiden Fällen erst zur Verfügung, wenn das entsprechende Prg. im AUTO\ gelaufen ist.

[Gaga]

Laufwerksbuchstaben im Großpack zu reservieren, finde ich mit czietz ebenfalls nicht sinnvoll. Vielleicht und hoffentlich hat er noch eine Idee, wie man den Mediachange realisieren kann. Das würde sich sicherlich auch positiv auf das USB-Floppylaufwerk auswirken.

[mfro]

... Vielleicht und hoffentlich hat er noch eine Idee, wie man den Mediachange realisieren kann...

Bleibt noch die Microsoft-Methode: auf wechselbaren Medien einfach nur eine einzige Partition zulassen.

[Gaga]

Wäre eine Überlegung, was meinst Du @czietz

Beim USB Floppy wäre ohnehin nur 1 Partition.

Bei CF/SD Karten wäre es etwas, womit man eventuell leben könnte.

[ari.tao]

... Vielleicht und hoffentlich hat er noch eine Idee, wie man den Mediachange realisieren kann...

Bleibt noch die Microsoft-Methode: auf wechselbaren Medien einfach nur eine einzige Partition zulassen.

Oder vielleicht nur das letzte Laufwerk als wechselbar zulassen?

[RealLarry]

Bei CF/SD Karten wäre es etwas, womit man eventuell leben könnte.

+1 von mir. Da ich vorzugsweise unter MiNT arbeite und fast ausschließlich von dort aus Daten hin und her schiebe, verwende ich dazu ext2 Partitionen. Dabei ist mir die Partitionsgröße eh Wurscht und das läuft ganz ausgezeichnet.

[czietz]

Bleibt noch die Microsoft-Methode: auf wechselbaren Medien einfach nur eine einzige Partition zulassen.

Ich bin ja froh, dass Microsoft das mit Windows 10 (endlich) abgeschafft hat -- und möchte nicht stattdessen den Atari-USB-Treiber künstlich beschränken.

[mfro]

-1 auch von mir. Weil ich die Microsoft-Lösung schlicht nicht als solche betrachte. Die haben das Problem einfach als nicht vorhanden erklärt. Mit max. FAT16 im "normalen" TOS würde man mit den heutzutage erhältlichen Medien gewaltige Speicherplatzverschwendung verursachen.

M.E. nach richtig (aber nicht gerade trivial zu implementieren) wäre, dem Anwender eine Möglichkeit zur Verfügung zu stellen, per Konfigurationsdatei bestimmte Partitionen von bestimmten Devices auf bestimmte Laufwerksbuchstaben zu mappen (so ähnlich, wie "richtige" OSse per uuid-Mapping dafür sorgen, dass wechselbare Medien immer an die gleiche Stelle gemountet werden).

Dazu müsste der Mount-Prozess das Filesystem auswerten, das da gemountet werden soll (also bei einem FAT-FS den Medien-Name oder bei einem ext2-Filesystem die UUID) auslesen und (z.B.) mit einer Konfigurationsdatei ein Mapping UUID/Medienname <-> Laufwerksbuchstabe herstellen.
Ist das betreffende Laufwerk schon belegt, gibt es eine Fehlermeldung und es passiert nichts weiter.