uIEC-Switch V1.2 (uiecSwitch)

  • uIEC-Switch V1.2 (uiecSwitch)

    Hallo,

    hat schon jemand die neue Version 1.2 von uiecSwitch von Glenn Holmer ( lyonlabs.org/commodore/onrequest/geos/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
    Dateien
  • 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,

    C=Mac schrieb:

    MP3 128 (es werden D81-Images verwendet)

    C=Mac schrieb:

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

    C=Mac schrieb:

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


    C=Mac schrieb:

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

    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?


    wweicht schrieb:

    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.


    wweicht schrieb:

    Grafikfehler bei Wheels64 gibt es auch bei anderen Programmen. Das scheint an Wheels 64 zu liegen....
    Ist mir einfach aufgefallen ;)


    wweicht schrieb:

    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,

    C=Mac schrieb:

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

    Nein, da irrst Du nicht .
    Uff, endlich hatte ich mal was noch richtig im Kopf 8)


    wweicht schrieb:

    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.
  • C=Mac schrieb:

    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

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von wweicht ()

  • wweicht schrieb:

    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


    wweicht schrieb:

    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.
  • C=Mac schrieb:

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

    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.


    wweicht schrieb:

    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 :(


    wweicht schrieb:

    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.
  • C=Mac schrieb:

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


    C=Mac schrieb:

    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:

    wweicht schrieb:

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

    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.

    wweicht schrieb:

    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.
  • C=Mac schrieb:

    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
  • :thnks:
    Jetzt leuchtet es auch mir ein, warum man nicht einfach mal einen SD-1581-Treiber schreiben kann und es funktioniert wie gewünscht.
    Megapasch könnte mit der Antwort vom Treiber nix anfangen bzw. der Treiber nix mit der Anfrage.

    Gruss C=Mac.
  • Neu

    C=Mac schrieb:

    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