Hallo Besucher, der Thread wurde 4,9k mal aufgerufen und enthält 22 Antworten

letzter Beitrag von wweicht am

uIEC-Switch V1.2 (uiecSwitch)

    Hallo,


    hat schon jemand die neue Version 1.2 von uiecSwitch von Glenn Holmer ( https://www.lyonlabs.org/commo…eos/index.html#uIecSwitch ) ausprobiert? Ich hänge das D64 hier mal an.


    Folgende Verbesserungen gibt es laut seiner Internetseite:

    • uIEC detection fix
    • not necessary to start uIecSwitch from a drive that's a uIEC
    • returns to originally selected drive at end of program
    • checks for D64, D71, D81, and DNP images
    • warns on exit if selected image incompatible with GEOS drive

    Ich bekomme es mit meinem uIEC (aktuelle Firmaware von Unseen) unter MegaPatch 64 und 128 nicht zum laufen. Entweder es meldet, das kein uIEC/Sd2IEC gefunden wird, oder mein Rechner hängt sich auf. Bei mir ist das uIEC Laufwerk 11 und auf 1581 (D81) eingestellt.


    Kann das jemand bestätigen?



    Zum Durchsehen des beigefügten Quelltextes werde ich in absehbarer Zeit wohl leider nicht kommen....


    Gruß
    Werner

    Hab's mal ausprobiert.


    Verwendeter Computer: C128D


    Laufwerke:


    A (8): SD2IEC
    B (9): REU (Emuliert von der Ultimate 4 MB)
    C (10): Ultimate bzw. 1541
    D (11): Interne 1571


    MP3 128 (es werden D81-Images verwendet)


    Programm aus der REU gestartet, wechseln in den 40 Zeichenmodus :|
    Rote LED des SD2IEC fängt an zu blinken
    Ich sehe zwar eine Oberfläche (Auswahlbox) aber ohne Inhalt, es passiert auch nichts wenn ich auf "Open" oder "Parent" klicke.
    Nach dem verlassen von uiecSwitch erhalte ich nur noch einen Diskfehler ($20) wenn ich auf LW A klicke, erst wenn ich mit dem uIEC_Man 128 eine Partition auswähle habe ich wieder Zugriff auf das SD2IEC.


    Wheels 128 (es werden DNP-Images verwendet)
    Programm aus der REU gestartet, wechseln in den 40 Zeichenmodus
    Rote LED des SD2IEC fängt an zu blinken
    Ich sehe zwar eine Oberfläche (Auswahlbox) aber ohne Inhalt, es passiert auch nichts wenn ich auf "Open" oder "Parent" klicke.
    Nach dem verlassen von uiecSwitch erhalte ich nur noch einen Diskfehler ($20) wenn ich auf LW A klicke.
    Danach hängt sich Wheels auf (80 Zeichenmodus).
    Im 40 Zeichenmodus wird immer wieder Re-Insert Disk verlangt, es ist auch nicht mehr möglich mit dem uIEC_Man 128 eine funktionierende Partition auf zu rufen.
    Wheels bleibt bei "Re-Insert Disk".



    MP3 64 (es werden D81-Images verwendet)
    Funktioniert.
    Kann mich auf der SD-Karte bewegen.
    Wähle ich D81-Images aus werden sie auch von MP3 64 erkannt.
    Hab nur mit den D81-Images aus dem Ordner GEOSD81 probiert :rolleyes:


    Wheels 64 (es werden DNP-Images verwendet)
    Hier ist es gleich wie bei Wheels 128, es kommen noch Grafikfehler im Dashboard dazu.



    Da es eine funktionierende Alternative (uIEC_Man 64/128) gibt ist es auch nicht wirklich tragisch, dass uiecSwitch nicht funktioniert :rolleyes:


    Wie es mit dem Standard GEOS oder GateWay aussieht habe ich nicht probiert.


    Gruss C=Mac.

    Hallo C=Mac,

    Zitat von C=Mac

    MP3 128 (es werden D81-Images verwendet)

    Zitat von C=Mac

    Wheels 128 (es werden DNP-Images verwendet)

    also auf 128er Systemen wird das Programm sehr wahrscheinlich sowieso nicht laufen. War bei der V1.1 auch schon so. Diese Version liegt übrigens auf der F64-Wolke. Sie konnte aber nur D81 und musste direkt vom uIEC/Sd2IEC gestartet werden. Aus diesem Grund habe ich die neue Version heute mal schnell angetestet, da sie dann für 64er-Systeme besser wäre (frei auf der SD-Karte navigieren).


    Zitat von C=Mac

    MP3 64 (es werden D81-Images verwendet)
    Funktioniert.

    Mmmhh ... ;-) . Muss ich mal demnächst nochmal probieren. Vielleicht ligt es daran, dass mein uIEC Lfw. D ist....



    Zitat von C=Mac

    Wheels 64 (es werden DNP-Images verwendet)
    Hier ist es gleich wie bei Wheels 128, es kommen noch Grafikfehler im Dashboard dazu.

    Grafikfehler bei Wheels64 gibt es auch bei anderen Programmen. Das scheint an Wheels 64 zu liegen....


    Aber: Hast Du beim Wechsel von MP3-64 auf Wheels 64 daran gedacht, dass die "file based ROM emulation" von D81 zu DNP zu ändern? Möglicherweise (hatte noch nicht die Zeit nachzuschauen) löst das die Probleme in Wheels64 aus.


    Gruß
    Werner

    Zitat von wweicht

    also auf 128er Systemen wird das Programm sehr wahrscheinlich sowieso nicht laufen.

    Sieht so aus.
    Lässt sich zwar als 40 Zeichenprogramm starten, aber ist funktionslos (wie oben beschrieben).
    Wenn es als reines 64'er Programm gedacht ist, soll der Programmiere es als 64'er Programm kennzeichnen.
    Es gibt doch die Möglichkeit ein Programm als 64'er-PRG zu kennzeichnen, dass es im 128'er Modus gar nicht gestartet werden kann, oder irre ich mich da?



    Zitat von wweicht

    da sie dann für 64er-Systeme besser wäre (frei auf der SD-Karte navigieren).

    Dies ist wäre der einzige Vorteil gegenüber dem uIec_Man, wobei ich den Sinn nicht sehe.
    Da weder MP3 noch Wheels mit den anderen Daten umgehen können.



    Zitat von wweicht

    Grafikfehler bei Wheels64 gibt es auch bei anderen Programmen. Das scheint an Wheels 64 zu liegen....

    Ist mir einfach aufgefallen ;)



    Zitat von wweicht

    Aber: Hast Du beim Wechsel von MP3-64 auf Wheels 64 daran gedacht, dass die "file based ROM emulation" von D81 zu DNP zu ändern? Möglicherweise (hatte noch nicht die Zeit nachzuschauen) löst das die Probleme in Wheels64 aus.

    Jap, Rechner Reset und Reset des SD2IEC, danach Start der passende ROM-Emulation.


    Gruss C=Mac.

    Hallo C=Mac,

    Zitat von C=Mac

    Wenn es als reines 64'er Programm gedacht ist, soll der Programmiere es als 64'er Programm kennzeichnen.
    Es gibt doch die Möglichkeit ein Programm als 64'er-PRG zu kennzeichnen, dass es im 128'er Modus gar nicht gestartet werden kann, oder irre ich mich da?

    Nein, da irrst Du nicht ;-) .
    Es gibt da im Infoblock ein Byte, das nur richtig eingestellt werden muss . Das ist Byte $60, das auf $00 (für nur 40 Zeichen) steht. Ändert man das auf $80 (nur Geos 64) dann startet das Programm nicht mehr auf 128er Systemen.


    Das vergessen "nur 64er-Programmierer" gerne mal. Sie merken davon ja nichts ......



    uiecSwitch V1.2 funktioniert jetzt auch bei mir unter MP3-64. Allerdings geht es nur, wenn das uIEC/SD2IEC Laufwerk 8 - 10 ist. Laufwerk 11 wird nicht unterstützt, was ein Blick in den Quellcode bestätigt hat. Der Programmierer geht wohl vom Ur-Geos mit originalem "DESK TOP" aus ....


    Gruß
    Werner

    Zitat von wweicht

    Nein, da irrst Du nicht .

    Uff, endlich hatte ich mal was noch richtig im Kopf 8)



    Zitat von wweicht

    uiecSwitch V1.2 funktioniert jetzt auch bei mir unter MP3-64. Allerdings geht es nur, wenn das uIEC/SD2IEC Laufwerk 8 - 10 ist. Laufwerk 11 wird nicht unterstützt, was ein Blick in den Quellcode bestätigt hat. Der Programmierer geht wohl vom Ur-Geos mit originalem "DESK TOP" aus ....

    Gut zu hören.
    Dann muss ich dies schon nicht ausprobieren :rolleyes:



    Hab noch einmal einwenig rum experimentiert ;)


    MP3 64 mit D81-Images


    Es können auch D81-Images ausserhalb des GEOSD81-Ordner erreicht und benutzt werden, im Gegensatz zum uIec-Man 64.
    Andere Images funktionieren natürlich nicht, erstens stimmt die ROM-Emulation nicht und zweitens ist es der falsche LW-Treiber.
    Aber ich konnte einem Versuch nicht widerstehen :whistling:



    Wheels 64 mit DNP-Images


    uIec-Man 64 funktioniert ohne Probleme :thumbup: (War halt ein fähiger Programmierer :rolleyes: )


    uIecSwitch meldet beim Wechseln des Images:


    "The partition or disk image selected on you uIec/SD2IEC does not match the GEOS drive type for that device."

    Danach erhalte ich beim Versuch auf die SD-Karte zu zugreifen nur noch immer den Hinweis "Re-Insert Disk xxxxx".



    Wheels 64 mit D81-Images


    Wechseln des Images funktioniert ohne Fehlermeldung.
    Beim Versuch die "Diskette" zu öffnen, hängt sich Wheels auf.
    Eventuell kollidiert die Programmierung von uIecSwitch mit der von Wheels.


    Keine Ahnung.


    Gruss C=Mac.

    Zitat von C=Mac

    Dies ist wäre der einzige Vorteil gegenüber dem uIec_Man, wobei ich den Sinn nicht sehe.

    Der Sinn wäre, dass man von der "starren" von mir festgelegten Ordner-Struktur wegkommen könnte (obwohl die wohl für ein wenig Ordnung auf der SD-Karte sorgt :winke: ).


    Man kann innerhalb von Geos/Wheels/MegaPatch schon auf das "Native Filesystem" der SD-Karte zugreifen. Sonst würde ja selbst mein uIEC-Manager nicht funktionieren. Er liest die Dxx ja auch von dort. Das Problem ist nur: die normale Geos/Wheels/MegaPatch-Dateiauswahl und die entsprechenden Oberflächen (Desktops) können das nicht.
    Also müßten Geos/Wheels/MegaPatch mindestens teilweise neu geschrieben und entsprechende Desktops entwickelt werden. Und es müßte ein Treiber her, der das "Native Filesystem" unterstützt...


    Das Hauptproblem von uiecSwitch V1.2 scheint zu sein, dass vergessen wurde, vor dem Wechsel des Image-Types die M-R-Emulation zu ändern und auch der Laufwerkstreiber entsprechend geändert werden müsste...


    Gruß
    Werner

    Zitat von wweicht

    Der Sinn wäre, dass man von der "starren" von mir festgelegten Ordner-Struktur wegkommen könnte

    So schlimm ist diese Struktur auch nicht, man muss nur daran denken :rolleyes:
    Hat mich zwar auch schon beschiessen, als ich die HD kopieren wollte.
    Schön einen Ordner "HD Backup" auf der SD-Karte erstellt -> geht nicht.
    O.K. Ordner im Ordner "GEOSDNP" erstellt -> geht auch nicht.
    Jetzt sind die HD-Partitionen direkt im Ordner "GEOSDNP" -> funktioniert :D



    Zitat von wweicht

    Also müßten Geos/Wheels/MegaPatch mindestens teilweise neu geschrieben und entsprechende Desktops entwickelt werden. Und es müßte ein Treiber her, der das "Native Filesystem" unterstützt...

    Wäre es möglich SD-15xx/DNP-Treiber zu entwickeln, ähnlich den HD-15xx/DNP-Treiber?


    Ist mir klar, das diese Treiber keinen vollständigen Zugriff auf die SD-Karte ermöglichen.
    Aber es wäre immerhin möglich die Image mit dem Bordbefehl (C=J (MP3); C=S (Wheels)) zu wechseln.
    Auch wenn die jetzige Ordnerstruktur beibehalten werden müsste.


    Und nein, ich habe keine Ahnung wie aufwändig sowas ist und wie man dies Programmieren müsste :saint:


    Gruss C=Mac.

    Zitat von C=Mac

    Wäre es möglich SD-15xx/DNP-Treiber zu entwickeln, ähnlich den HD-15xx/DNP-Treiber?

    irgendwie drehen wir uns im Kreis .... :streichel:


    Es ist immer das selbe, was ich da antworten kann:


    Möglich ist vieles, nur wer kümmert sich drum?
    Ich habe keine Ahnung von den internen Sachen der HD, habe ja nicht mal eine .....


    Ich kann mir vorstellen, dass das interne CMD-HD-Native-Format (für C64/128) eben doch vom "normalen" Format auf der Festplatte in der HD abweicht. Sonst hätte ja CMD auf die Idee kommen können, das Native-Format für C64/128 größer zu machen als die 16 MB, die jetzt maximal möglich sind.
    Ich meine mal irgendwo etwas von "Foreign-Mode" oder so gelesen zu haben, wo Daten von/auf der CMD-HD von anderen Systemen gelesen/geschrieben werden können. Aber wenn mich nicht alles täuscht, sind diese Daten von anderen Rechnern (PC/Mac/was immer) für C64/128 nicht schtbar. Wie schon gesagt, ich habe keine Ahnung davon .......


    Gruß
    Werner

    Zitat von wweicht

    irgendwie drehen wir uns im Kreis ....


    Es ist immer das selbe, was ich da antworten kann:


    Möglich ist vieles, nur wer kümmert sich drum?
    Ich habe keine Ahnung von den internen Sachen der HD, habe ja nicht mal eine .....

    War ein wenig ungenau ausgedrückt von mir.


    Bei CMD-Geräten (egal ob HD, RL, FD) kann man ja Floppy-Emulation-Partitionen einrichten (1541, 1571, 1581).
    Mit dem jeweiligen Treiber (bei MP3 alle, bei Wheels nur 1581) kann die Partition über den "Dienstbefehl" (C=J bzw. C=S) gewechselt werden.
    Meine Frage war/ist: Ob dies auch mit dem SD2IEC möglich wäre, somit müsste ein Imagewechsel nicht mehr über Zusatzprogramme erfolgen.


    Das man zuerst jemand finden müsste, der das Programmieren kann und will ist mir klar.



    Zitat von wweicht

    das Native-Format für C64/128 größer zu machen als die 16 MB, die jetzt maximal möglich sind.

    In einer 64'er war's glaub mal beschrieben, warum es 16 MB sind, aber ich weiss den Grund nicht mehr :(



    Zitat von wweicht

    Ich meine mal irgendwo etwas von "Foreign-Mode" oder so gelesen zu haben, wo Daten von/auf der CMD-HD von anderen Systemen gelesen/geschrieben werden können. Aber wenn mich nicht alles täuscht, sind diese Daten von anderen Rechnern (PC/Mac/was immer) für C64/128 nicht schtbar. Wie schon gesagt, ich habe keine Ahnung davon .......

    Ja es ist möglich die HD zu splitten, so das ein Bereich von anderen Systemen benutz werden kann und ein Anderen vom C64/128.
    Die Bereiche sind aber getrennt, so das die Systeme nicht auf den jeweiligen anderen Bereich zugreifen können.
    Ob's funktioniert, keine Ahnung, die HD ist exklusive C64/128 ^^


    Gruss C=Mac.

    Zitat von C=Mac

    Die Bereiche sind aber getrennt, so das die Systeme nicht auf den jeweiligen anderen Bereich zugreifen können.

    Allein daran sieht man schon, dass eben nicht so einfach ist, auf das Native-Filesystem hier auf der CMD-HD zuzugreifen. Ich meine, dass M. Randall da was mit seinem nie erschienden neuen HD-DOS machen wollte .......



    Zitat von C=Mac

    Mit dem jeweiligen Treiber (bei MP3 alle, bei Wheels nur 1581) kann die Partition über den "Dienstbefehl" (C=J bzw. C=S) gewechselt werden.

    Bei Wheels sollte das auch auf Native Mode gehen. Aber auch das hatten wir schonmal :D


    Das Problem:
    diese Dienstbefehle sind auf die Struktur der CMD-Geräte ausgerichtet (OK, bei MegaPatch auch 64NET, das aber einen eigenen externen Treiber hat). Nun ist aber die Organisation der Daten auf dem CMD-Geräten völlig anders als beim SD2IEC. Bei CMD sind es Partiitionen und beim SD2IEC Dxx-Dateien. Das ist nicht das Gleiche! Keine Ahnung wie das Format auf den CMD-Geräten direkt aussieht. Beim SD2IEC ist es FAT16/FAT32. Das kann niciht funktionieren.....


    Als Beispeil:
    Starte doch mal "CMD Move V1.1" (das Programm für Partitionswechsel unter Geos von CMD) auf einem CMD-Gerät und schaue mal was es Dir anzeigt: Die vorhandenen Partitionen des entsprechenden Types oder meinetwegen auch alle Partitionen.
    Jetzt starte "CMD Nove" mal auf dem SD2IEC. Du siehst 2 Einträge: SYSTEM und das aktuell gemountete Image. Die anderen Dxx-Dateien sind nicht sichtbar. Die Strucktur ist eben eine völlig andere (auch wenn das SD2IEC die CMD-Struktur etwas "simuliert"). Wenn das nicht der Fall wäre, wurde "CMD Move" hier gar nichts anzeigen oder sagen, dass kein CMD-Gerät gefunden wurde.


    Als Fazit bleibt wieder nur:

    Zitat von wweicht

    Also müßten Geos/Wheels/MegaPatch mindestens teilweise neu geschrieben und entsprechende Desktops entwickelt werden. Und es müßte ein Treiber her, der das "Native Filesystem" unterstützt...

    Man müßte konkret die Dienstbefehle im jeweiligen Desktop so umschrieben, dass sie jeweils mit dem einen oder anderen Format oder eben mit beiden zurecht kommen...


    Gruß
    Werner

    kleiner Nachtrag zu den Treibern:


    Das würde wohl nur unter MegaPatch funktionieren. Da funktionieren externe Treiber. Bei Wheels sehe ich da keine Change. Da sich z.B. der 64NET-Treiber (egal ob der für Geos oder der für Geos und MegaPatch)nicht unter Wheels installieren lässt (Wheels stürzt gnadenlos ab) , ist irgend etwas im Treiber-Handling von Wheels geändert worden. Was genau ist unbekannt....


    Es gibt zwar den SourceCode des 1581-Treibers von Wheels (und einen Hinweis wo er gespeichert ist) aber das hilft nicht wirklich. Habe echt keine Lust und vor allem keine Zeit das auch noch herauszutüfteln.


    Gruß
    Werner

    Zitat von wweicht

    Das Problem:
    diese Dienstbefehle sind auf die Struktur der CMD-Geräte ausgerichtet (OK, bei MegaPatch auch 64NET, das aber einen eigenen externen Treiber hat). Nun ist aber die Organisation der Daten auf dem CMD-Geräten völlig anders als beim SD2IEC. Bei CMD sind es Partiitionen und beim SD2IEC Dxx-Dateien.

    Zitat von wweicht

    Man müßte konkret die Dienstbefehle im jeweiligen Desktop so umschrieben, dass sie jeweils mit dem einen oder anderen Format oder eben mit beiden zurecht kommen...

    Mal sehen ob ich es jetzt richtig interpretiere.


    Wenn ich bei MP3 ein CMD-Gerät und denn dazugehörenden Treiber eingerichtet habe.
    Kann ich ja, unteranderem, mit dem Befehl C=J die Partitionen-Liste anzeigenlassen.


    Wenn ich es richtig interpretiere ist es nicht der Treiber selber welcher die Partitionen-Liste anzeigt/zu verfügung stellt, sondern andere Teile des OS.


    Gruss C=Mac.

    Zitat von C=Mac

    Kann ich ja, unteranderem, mit dem Befehl C=J die Partitionen-Liste anzeigenlassen.


    Wenn ich es richtig interpretiere ist es nicht der Treiber selber welcher die Partitionen-Liste anzeigt/zu verfügung stellt, sondern andere Teile des OS.

    Genau so ist es.


    Der Treiber ist nur für die direkte Kommunikation zwischen MegaPatch (Topdesk) und dem Laufwerk zuständig. Er sendet einen Befehl an das Laufwerk und die Antwort des Befehls zurück zu Megapatch. Was Megapatch mit der Antwort macht (z.B. die Partitionen in einer Dialogbox anzeigen) ist einzig und allein die Sache von Megapatch.
    Erst wenn jetzt eine Partition ausgewählt wird, geht das Ganze von vorne los: Partitions-Wechsel-Befehl ans Laufwerk senden, Rückmeldung an MegaPatch senden (OK oder Fehlermeldung). Megapatch öffnet/aktualisiert dann das entsprechende Fenster des Laufwerks.


    Gruß
    Werner

    Zitat von C=Mac

    warum man nicht einfach mal einen SD-1581-Treiber schreiben kann

    :hae:
    Wieso SD-1581-Treiber????


    Es geht um HD-Native-Treiber für MegaPatch. Dieses prüft vor der Installation, ob da wirklich eine CMD-HD ist oder nicht.... Wheels prüft nur mehr oder weniger "einfach" ob der M-R-Befehl "HD" zurück sendet. Deshalb steht in dem Fake-HD-DOS nur diese 2 Zeichen an der richtigen Stelle. MegaPatch gibt sich damit nicht zufrieden und hängt .............


    Gruß
    Werner

    Ups, hab ich doch glatt vergessen.
    Und wie ich sehe auch einiges an Verwirrung gestiftet.


    Probier's mal zu entwirren ;)


    Bei den CMD-Geräten (egal ob HD, RL, FD) können verschiedene Partitionsarten (41/71/81/Nat.) eigerichtet werden.
    Diese Partitionen können, unter MP3, einfach mit dem Befehl C=J gewechselt werden.
    Natürlich muss dazu der jeweilige Treiber Installiert sein.
    Ist ein 1581-Treiber installiert können nur 1581-Partitionen benutzt werden; ist ein Nat.-Treiber installiert können nur Nat.-Partitionen benutzt werden usw. dies dürfte aber klar sein.


    Von daher bin ich auf die Idee gekommen, ob das selbe auch mit dem SD2IEC möglich ist.
    Also das Wechseln der Partitionen, hier Images genannt, direkt ohne das Verwenden von Zusatzprogrammen (wie uIEC-Manager oder das hier erwähnte uIEC-Switch).


    Also eine Art:


    - SD-1541
    - SD-1571
    - SD-1581
    - SD-DNP
    Treiber, welches das direkte Wechseln der Image über den Systembefehl ermöglicht.



    Zitat von C=Mac

    Mal sehen ob ich es jetzt richtig interpretiere.
    Wenn ich bei MP3 ein CMD-Gerät und denn dazugehörenden Treiber eingerichtet habe.
    Kann ich ja, unteranderem, mit dem Befehl C=J die Partitionen-Liste anzeigenlassen.


    Wenn ich es richtig interpretiere ist es nicht der Treiber selber welcher die Partitionen-Liste anzeigt/zu verfügung stellt, sondern andere Teile des OS.


    Gruss C=Mac.

    Zitat von wweicht

    Genau so ist es.
    Der Treiber ist nur für die direkte Kommunikation zwischen MegaPatch (Topdesk) und dem Laufwerk zuständig. Er sendet einen Befehl an das Laufwerk und die Antwort des Befehls zurück zu Megapatch. Was Megapatch mit der Antwort macht (z.B. die Partitionen in einer Dialogbox anzeigen) ist einzig und allein die Sache von Megapatch.
    Erst wenn jetzt eine Partition ausgewählt wird, geht das Ganze von vorne los: Partitions-Wechsel-Befehl ans Laufwerk senden, Rückmeldung an MegaPatch senden (OK oder Fehlermeldung). Megapatch öffnet/aktualisiert dann das entsprechende Fenster des Laufwerks.


    Gruß
    Werner

    Wenn ich die oberen Aussagen richtig verstanden hab.
    Wäre es aber nicht einfach möglich SD2IEC-Treiber zu schreiben, welche den direkten Images-Wechsel ermöglichen.
    Sondern das OS selber müsste dafür angepasst werden.


    Hoffe ich hab's jetzt einigermassen entwirrt :D
    Oder die Verwirrung ist jetzt komplett.




    Gruss C=Mac.

    Hallo C=Mac,


    Zitat von C=Mac

    Bei den CMD-Geräten (egal ob HD, RL, FD) können verschiedene Partitionsarten (41/71/81/Nat.) eigerichtet werden.
    Diese Partitionen können, unter MP3, einfach mit dem Befehl C=J gewechselt werden.
    Natürlich muss dazu der jeweilige Treiber Installiert sein.

    Das C=J ist eine Tasten-Kombination die nur im Topdesk von MegaPatch/Geos existiert.


    Was passiert bei dieser Tastenkombination?
    Zunächst schaut TD ob ein unterstütztes Gerät das aktuelle Laufwerk ist. Das sind die CMD-Geräte und 64Net. Ist das nicht Fall wird nichts getan.
    Ist das der Fall, wird die Befehlskette für CMD-Geräte oder die Befehlskette für 64NET in Gang gesetzt.
    Da müßte jetzt die Befehlskette für SD2IEC zusätzlich in Topdesk eingefügt werden (ist da überhaupt ein SD2IEC, welcher Type (41, 71,81, DNP) ist es, Image-Daten holen, Image-Namen anzeigen, und so weiter.



    ;) Mir scheint, Du willst die eierlegende Wollmilch-Sau ;)


    Läuft unter allen Systemen, kann alle Partitionstypen und kann direkt zwischen den einzelnen Partitionstypen wechseln.



    Externe Treiber sind blöd ;) . Wheels fällt dann raus, weil es keine externen Treiber akzeptiert. Unter Geos und MegaPatch geht es theoretisch, ist aber ein riesen Aufwand. Da ist es einfacher das mit einem externen Programm zu machen und die vorhandenen MP3-Treiber (1541/1571/1581) zu nutzen....


    Es gab/gibt ein System, dass das unter Geos und MegaPatch konnte. Das hatte einen eigenen Treiber und konnte im laufenden Betrieb den Laufwerkstype ändern: 64NET. Wurde da ein D64 gemountet, zeigte TopDesk ein 64NET-1541-Icon, wurde ein D71 gemountet, das 64NET-1571-Icon und beim D81 eben ein 64NET-1581-Icon. Wie das genau funktionierte, habe ich nie untersucht.


    Für das SD2IEC bedeutet das:


    - prüfe bei C=J, ob da ein SD2IEC das aktuelle Laufwerk ist
    - prüfe welchen Laufwerkstype hat das SD2IEC momentan
    - prüfe was ist der neue Laufwerkstyp
    - suche den entsprechenden Treiber
    - installiere den entsprechenden Treiber an der richtigen Stelle
    - ändere die M-R Geschichte
    ...


    Ich müsste das alles irgendwie in Topdesk unterbringen. Der wird dadurch ziemlich sicher (TD 128) Größer als 64 kB . Und damit habe ich das nächste Problem an der Backe: Ram-Topdesk funktioniert nicht mehr, da es jetzt 2 RAM-Bänke braucht. Also muss hier auch noch geändert werden.


    Ne, vergiss es.



    Was ich mir vorstellen kann:


    uIEC-Manager so umzugestalten, dass er alle Laufwerkstypen auch untereinander wechseln kann. Dazu muss aber zunächst erstmal die DNP Geschichte unter MegaPatch gelöst werden. Das wird irgendwann in der Zukunft geschehen. Dann sehen wir weiter.....


    Das Problem beim aktuellen uIEC-Switch ist ja: es wechselt NICHT den Laufwerkstreiber und ändert NICHT die M-R Geschichte. Deshalb funktioniert das ändern des Laufwerkstype hier auch nicht......


    Gruß
    Werner