MP3 Patch und Laufwerksverwaltung

  • wweicht schrieb:

    Betreffen die Probleme nur MegaPatch 64 oder auch MegaPatch 128?
    Wäre deshalb interessant, um endlich mal herauszubekommen, was da schief läuft. Könnte ja theoretisch sein, das meine Patches (hier sind das Prg. MP3-Patch, das Topdesk-Patch und die gepatchten Laufwerks-Treiber gemeint) eine Rolle spielen. Also bitte mal ein System damit und ein System ohne (original MP3) ausprobieren. Ich habe ja keine HD, um selber zu probieren ....
    Hatte ich eigentlich heute Abend vor, wird wohl nix mehr :(

    Aber es gibt ja noch das Wochenende :D

    Will nämlich auch noch testen was bei Verwendung eines ZIP-LW passiert.


    wweicht schrieb:

    Um was für Partitionen handelt es sich da (81, Native, ....)?
    Natürlich Native (16 MB) ^^
    Was soll ich mit dem Kleinkram ;)


    wweicht schrieb:

    So ganz nebenbei, eine Festplatte ist ein mechanisches Laufwerk (Schreib-/Lesekopf "fliegt" über die Platte). Da kann es schonmal vorkommen, dass eine Partition kaputt geht...
    Kennen ich aus eigener Erfahrung.
    Bei der original 20 MB-Platte hat sich der Kopf als Hobel betätigt.

    Wie war das noch im PM-Magazin erklärt:
    Ne HD ist wie, wenn eine 747 mit vollem Speed über ein Weizenfeld fliegt, dies in einem Meter Abstand und dabei noch alle Halme zählt; oder so :D

    Also eine diffizile Sache.

    Gruss C=Mac.
  • wweicht schrieb:

    Betreffen die Probleme nur MegaPatch 64 oder auch MegaPatch 128?
    Hab heute ein wenig experimentiert.

    Verwendet wurde hauptsächlich MP3 128 (inkl. allen Patch)

    LW A: 1581 (SD)
    LW B: REU 4MB (Ultimate)
    LW C: HD
    LW D: 1571

    Fehlverhalten:
    HD hängt sich auf, oder besser gesagt der Lese-/Schreibkopf weiss nicht mehr wohin.
    Klingt jedenfalls so, es klickt nur noch.

    Nach einigem hin und her, hab ich festgestellt.
    Das ganze Problem tritt nur auf bei Native-Partitionen und nur wenn Unter-Verzeichnis beteiligt sind.

    Öffne ich zwei HD-Fenster, eins ist Partition 35, das andere Partition 36 (jeweils im Root-Verzeichnis).
    Kann ich ohne Probleme die Fenster aktivieren, also mit der Maus anklicken.
    Ebenfalls ist das Kopieren zwischen den Partitionen ohne Probleme möglich.

    Bin ich in einem Unterverzeichnis (egal ob Quell-/Zielpartition oder beide) treten die Probleme auf.

    Es ist nicht möglich aus oder in ein Unterverzeichnis zu kopieren, solange man nur im Root-Verzeichnis bleibt ist es ohne Probleme möglich.

    Hab das ganze noch mit GeoDos (MP3 64) probiert, tritt genau das selbe auf.
    Kein Problem Root-Verzeichnis <-> Root-Verzeichnis, nicht möglich wenn ein Unterverzeichnis beteiligt ist

    GeoDos bricht den Vorgang aber hab und gibt eine Fehlermeldung aus:
    "Diskettenfehler Datei nicht gefunden; GeoDos Fehlercode 5"

    Keine Probleme gibt es mit 1581-Partitionen, die haben aber auch keine Unterverzeichnise ^^

    Es gibt auch kein Unterschied ob neue MP3 (mit allen Patch) oder alte Version.

    Komischerweise erkennt GeoDos auf dem C128 die HD-Native-Partitionen nicht -> Type ??? und es blinkt die Error-LED der HD.
    Auf dem C64 unter MP3-64 kein Erkennungsproblem.
    Mit 1581-Partitionen gibt es auf beiden Systemen keine Probleme.

    Irgendwie scheint es mit Unterverzeichnise nicht so ganz zu funktionieren.
    Es wird auch immer das Fenster ganz geschlossen und nicht nur in die höhere Ebene gewechselt.

    Gruss C=Mac.
  • Hallo C=Mac,

    C=Mac schrieb:

    Hab heute ein wenig experimentiert.
    Sorry, hat etwas länger gedauert...

    Aber so ungefähr sollte eine Fehlerbericht aussehen, damit man (hoffentlich) wirklich helfen kann. ;)


    C=Mac schrieb:

    Verwendet wurde hauptsächlich MP3 128 (inkl. allen Patch)

    LW A: 1581 (SD)
    LW B: REU 4MB (Ultimate)
    LW C: HD
    LW D: 1571

    Fehlverhalten:
    HD hängt sich auf, oder besser gesagt der Lese-/Schreibkopf weiss nicht mehr wohin.
    Klingt jedenfalls so, es klickt nur noch.
    Ok, hier gleich der 1 Punkt. Ich will ja das Ultimate nicht schlecht machen, aber: Als MegaPatch entwickelt wurde, gab es eine CBM-REU nur mit 2 MB. Es ist also theoretisch möglich, dass das Probleme verursacht. Versuche alles nochmal und stelle dafür die REU des Ultimate mal auf 2 MB ein.
    Ändert sich irgendwas?
    Ich arbeite unter WinVICE (in X128; C128 und C64 MegaPatch) mit 200% Geschwindigkeit und auch mit einer 4 MB REU und konnte bisher keine Probleme feststellen. Aber Emulator und echte Hardware müssen da nicht unbedingt gleich reagieren.

    Als MegaPatch geschrieben wurde, gabe es aber nur 2 MB CBM-REUs ....


    C=Mac schrieb:

    Öffne ich zwei HD-Fenster, eins ist Partition 35, das andere Partition 36 (jeweils im Root-Verzeichnis)
    Kannst Du das Gleiche auch mal auf der CMD-FD versuchen (eine Disk mit 2 Native Partitionen anlegen und dort mit dem gleichen Programm Unterverzeichnisse erstellen, wie es auch auf der HD benutzt wurde)?


    C=Mac schrieb:

    Hab das ganze noch mit GeoDos (MP3 64) probiert, tritt genau das selbe auf.

    C=Mac schrieb:

    GeoDos bricht den Vorgang aber hab und gibt eine Fehlermeldung aus
    Welche Version von GeoDOS benutzt Du? Da ist der originale Dateiname des Programms GeoDOS und die Klasse unter Datei - Info interessant.


    C=Mac schrieb:

    Irgendwie scheint es mit Unterverzeichnise nicht so ganz zu funktionieren.
    Es wird auch immer das Fenster ganz geschlossen und nicht nur in die höhere Ebene gewechselt.
    Auch das kann mehrere Ursachen haben. Einmal die Bedienung mit der Maus. Ist mir auch schon passiert, dass beim Klicken auf das "Schliessen"-Icon mehr geschlossen wird, als ich eigentlich will. Versuche mal sofort nach dem Klicken die Maus schnell vom "Schließen"-Icon wegzubewegen. Manchmal passiert es, wenn ich die Maus auf dem Symbol stehen lasse, dass irgendwie mehrere Schließ-Vorgänge ausgeführt werden.

    Zum anderen: Mit welchem Programm erstellst Du die Unterverzeichnisse? Nutzt Du das kleine Programm von mir? Möglicherweise löst das auch die Probleme aus :( .

    Kannst Du mal testen, ob sich irgendwas ändert, wenn Du ein anderes Programm zum Erstellen der Unterverzeichnisse (z.B. GeoDOS) dafür benutzt?


    C=Mac schrieb:

    Komischerweise erkennt GeoDos auf dem C128 die HD-Native-Partitionen nicht -> Type ??? und es blinkt die Error-LED der HD
    Deshalb die Frage zu GeoDOS weiter oben. Die neueste Version liegt auf der F64-Wolke und hier c64.webgrimm.de/ .


    Antwort kann wieder etwas länger dauern ....

    Gruß
    Werner
  • wweicht schrieb:

    Sorry, hat etwas länger gedauert...
    Keine Sorge, macht nichts.
    Ist ja schliesslich ein Forum und keine 24h-Sorglos-Hotline für 5.50/min :D


    wweicht schrieb:

    Ok, hier gleich der 1 Punkt. Ich will ja das Ultimate nicht schlecht machen, aber: Als MegaPatch entwickelt wurde, gab es eine CBM-REU nur mit 2 MB. Es ist also theoretisch möglich, dass das Probleme verursacht. Versuche alles nochmal und stelle dafür die REU des Ultimate mal auf 2 MB ein.
    Kann ich mal probieren.

    Der Fehler tritt auch auf der 64'er-Anlage auf.

    LW A: RL Nat.
    LW B: FD 2000
    LW C: HD
    LW D: 1541-II

    Als RAM für MP3-64 wird die SuperCard benutzt, keine RAM-Disk eingerichtet.


    wweicht schrieb:

    Kannst Du das Gleiche auch mal auf der CMD-FD versuchen (eine Disk mit 2 Native Partitionen anlegen und dort mit dem gleichen Programm Unterverzeichnisse erstellen, wie es auch auf der HD benutzt wurde)?
    Muss ich mal ausprobieren.
    Wusste gar nicht das das geht, dachte immer Native (1x), oder 1581 (2x) bei HD-Disk.

    Hab's heute mal auf der RL probiert, hier hat es funktioniert.


    wweicht schrieb:

    Welche Version von GeoDOS benutzt Du? Da ist der originale Dateiname des Programms GeoDOS und die Klasse unter Datei - Info interessant.
    Müsste ich nochmal explizit nachsehen, aber es müsste die letzte Version sein.


    wweicht schrieb:

    Zum anderen: Mit welchem Programm erstellst Du die Unterverzeichnisse? Nutzt Du das kleine Programm von mir?
    Meistens Wheels, hab's aber auch mit Deinem Program probiert, merke unter MP3 keinen Unterschied.


    wweicht schrieb:

    Möglicherweise löst das auch die Probleme aus .
    Nicht Möglich ^^
    Der "Ordner" wird zwar unter Wheels anders benannt (DIR anstelle von CMD) und im Info-Text steht was anderes, sonst kann ich nichts feststellen.
    Es ist einzig aufwändiger als mit Wheels.


    wweicht schrieb:

    Antwort kann wieder etwas länger dauern ....
    Kommt Zeit, kommt Rat :D
    Wie gesagt, eilt nicht.

    Gruss C=Mac.
  • Hallo C=Mac,

    wweicht schrieb:

    Mit welchem Programm erstellst Du die Unterverzeichnisse?

    C=Mac schrieb:

    Meistens Wheels, hab's aber auch mit Deinem Program probiert, merke unter MP3 keinen Unterschied.

    C=Mac schrieb:

    Der "Ordner" wird zwar unter Wheels anders benannt (DIR anstelle von CMD) und im Info-Text steht was anderes
    OK, mein Programm nutzt momentan ausschließlich Geos-(MP3)-Routinen. Deshalb hat es z.B. einen eigenen Info-Block und ein eigenes Icon. Werde mal sehen (wird aber wohl noch etwas dauern) ob ich die UVs auch "anders" erstellen kann......


    C=Mac schrieb:

    Hab's heute mal auf der RL probiert, hier hat es funktioniert.
    Mal was ganz anderes ;) , funktioniert das (mit möglichst gleicher Konfiguration und den gleichen Partitionen (Quelle/Ziel , UVs) unter Wheels?

    Gruß
    Werner
  • So mal wieder etwas von mir :D


    wweicht schrieb:

    Kannst Du das Gleiche auch mal auf der CMD-FD versuchen (eine Disk mit 2 Native Partitionen anlegen und dort mit dem gleichen Programm Unterverzeichnisse erstellen, wie es auch auf der HD benutzt wurde)?
    Erledigt und zwar auf der C64-Anlage.
    Funktioniert ohne Probleme.


    wweicht schrieb:

    Welche Version von GeoDOS benutzt Du?
    V2.951, sollte die letzte Version sein.


    wweicht schrieb:

    Zum anderen: Mit welchem Programm erstellst Du die Unterverzeichnisse? Nutzt Du das kleine Programm von mir? Möglicherweise löst das auch die Probleme aus .

    Kannst Du mal testen, ob sich irgendwas ändert, wenn Du ein anderes Programm zum Erstellen der Unterverzeichnisse (z.B. GeoDOS) dafür benutzt?
    Hab jetzt mal Ordner mit allen mir zur Verfügung stehenden Programmen erstellt.
    Wheels, TD-COM und GeoDos.
    Alle können ohne Probleme Native-Unterverzeichnise erstellen, welche auch ohne Probleme von beiden OS (Wheels/MP3) benutzt werden.


    wweicht schrieb:

    OK, mein Programm nutzt momentan ausschließlich Geos-(MP3)-Routinen. Deshalb hat es z.B. einen eigenen Info-Block und ein eigenes Icon. Werde mal sehen (wird aber wohl noch etwas dauern) ob ich die UVs auch "anders" erstellen kann......
    Wie schon gesagt ist nicht relevant.
    Kleiner Fehler von mir, bei Wheels werden die TD-COM-Order ohne Bezeichnung angegeben, dass erwähnte "DIR" ist von MP3.
    Manchmal bin ich einfach verwirrt ;)
    Hab man eine Übersicht der verschiedenen Infobox angehängt.



    Und damit meine Verwirrung komplett wird, komm ich zum eigentlichen Problem:


    C=Mac schrieb:

    Verwendet wurde hauptsächlich MP3 128 (inkl. allen Patch)

    LW A: 1581 (SD)
    LW B: REU 4MB (Ultimate)
    LW C: HD
    LW D: 1571

    Fehlverhalten:
    HD hängt sich auf, oder besser gesagt der Lese-/Schreibkopf weiss nicht mehr wohin.
    Klingt jedenfalls so, es klickt nur noch.

    Nach einigem hin und her, hab ich festgestellt.
    Das ganze Problem tritt nur auf bei Native-Partitionen und nur wenn Unter-Verzeichnis beteiligt sind.

    Öffne ich zwei HD-Fenster, eins ist Partition 35, das andere Partition 36 (jeweils im Root-Verzeichnis).
    Kann ich ohne Probleme die Fenster aktivieren, also mit der Maus anklicken.
    Ebenfalls ist das Kopieren zwischen den Partitionen ohne Probleme möglich.

    Bin ich in einem Unterverzeichnis (egal ob Quell-/Zielpartition oder beide) treten die Probleme auf.

    Es ist nicht möglich aus oder in ein Unterverzeichnis zu kopieren, solange man nur im Root-Verzeichnis bleibt ist es ohne Probleme möglich.

    Hab das ganze noch mit GeoDos (MP3 64) probiert, tritt genau das selbe auf.
    Kein Problem Root-Verzeichnis <-> Root-Verzeichnis, nicht möglich wenn ein Unterverzeichnis beteiligt ist
    Hab's heute wieder ausprobiert, weil ich eh noch ein paar Sachen ausprobieren musste.

    Verwendet wurden beide Anlagen:

    C64'er:

    LW A: RL Nat.
    LW B: FD 2000
    LW C: HD Nat
    LW D: 1541-II

    C 128'er

    LW A: 1581 (SD)
    LW B: REU 4MB (Ultimate)
    LW C: HD
    LW D: 1571

    Kurz und einfach.
    Es funktioniert einfach.
    Egal ob ich in ein Unterverzeichnis, oder aus einem Unterverzeichnis kopiere.
    Es spielt auch keine Rolle ob das Unterverzeichnis mit Wheels, GeoDos oder TD-COM erstellt wurde.

    Nix, nada, es funktioniert jetzt einfach ohne Murren; keine Ahnung warum ?(
    Das einzige was ich mir noch vorstellen könnte, ist ein beginnender Festplattendefekt. Auf welchen MP3 reagiert, aber Wheels nicht.
    Ausser natürlich Erdrotation, Sonnenaktivität oder Mondstand ^^


    wweicht schrieb:

    Mal was ganz anderes , funktioniert das (mit möglichst gleicher Konfiguration und den gleichen Partitionen (Quelle/Ziel , UVs) unter Wheels?
    Ja, war nie ein Problem.

    Gruss C=Mac.
  • C=Mac schrieb:

    V2.951, sollte die letzte Version sein.
    Jep ;) .


    C=Mac schrieb:

    Es funktioniert einfach.
    Seltsam, seltsam, .... Aber dann können wir das Thema ja erstmal abhaken ^^ .


    C=Mac schrieb:

    ist ein beginnender Festplattendefekt. Auf welchen MP3 reagiert, aber Wheels nicht.
    Ausser natürlich Erdrotation, Sonnenaktivität oder Mondstand
    Wir wollen ja nicht gleich das Schlimmste annehmen ;) .

    Eins fällt mir da noch ein: Du hattest ja mal erwähnt, dass Du auch ein ZIP-Laufwerk an der HD hängen hast. War da nicht irgendwie was, dass das letzte Laufwerk "terminiert" werden muss? Kenne mich mit dem SCSI-Zeugs nicht so aus. Vielleicht löst das das Problem aus???

    Gruß
    Werner
  • wweicht schrieb:

    Eins fällt mir da noch ein: Du hattest ja mal erwähnt, dass Du auch ein ZIP-Laufwerk an der HD hängen hast. War da nicht irgendwie was, dass das letzte Laufwerk "terminiert" werden muss? Kenne mich mit dem SCSI-Zeugs nicht so aus. Vielleicht löst das das Problem aus???

    Jep, letztes Gerät in der SCSI-Kette muss terminiert sein, sonst gibts Probleme.
    Bei mir ist es das ZIP-LW und der Schalter steht auf Terminierung ON.

    Steck ich das ZIP-LW ab, wird glaub die HD gar nicht mehr erkannt, da nicht terminiert.
    Müsste einen externen Terminierungsstecker (25 Sub-D) haben, sowas gibt es heute sicherlich nicht mehr.
    Oder die HD öffnen und den Jumper setzten.

    Gruss C=Mac.
  • Hallo C=Mac,

    C=Mac schrieb:

    Kurz und einfach.
    Es funktioniert einfach.
    Egal ob ich in ein Unterverzeichnis, oder aus einem Unterverzeichnis kopiere.
    Es spielt auch keine Rolle ob das Unterverzeichnis mit Wheels, GeoDos oder TD-COM erstellt wurde.
    Bitte beobachte das Problem mit den UVs weiterhin. Mir hat heute ein andere Anwender bestätigt, dass da wohl ein Problem existiert. Also wenn es wieder auftritt möglichst genau beschreiben, was Du getan hast....

    Habe mir jetzt nochmal die MP3-TopDesk-Anleitung (ist auf der F64-Wolke) durchgelesen. Da steht nur, dass das Kopieren von kompletten UVs (ich denke das meint, UV-Symbol mit der Maus in ein anderes Fenster schieben) nicht möglich ist....

    Gruß
    Werner
  • wweicht schrieb:

    Mir hat heute ein andere Anwender bestätigt, dass da wohl ein Problem existiert.
    Jupi, bin doch noch nicht paranoid :D
    Hab's nämlich irgendwie im Hinterkopf, dass die auch schon funktioniert hat.
    Also funktioniert, funktioniert nicht, funktioniert .......

    Ist aber auch nichts, was wirklich absolut oberwichtig wäre.


    wweicht schrieb:

    was Du getan hast....
    Wenn ich das immer wüsste :rolleyes:


    wweicht schrieb:

    Da steht nur, dass das Kopieren von kompletten UVs (ich denke das meint, UV-Symbol mit der Maus in ein anderes Fenster schieben) nicht möglich ist....
    Ja, das ist so.
    Man kann ein UV nicht per UV-Symbol Verschiebung kopieren.
    Sondern muss das Quell-UV öffnen, das Ziel-UV öffnen oder erstellen und dann den Hinhalt kopieren.
    Ist aber bei Wheels nicht anders.

    Gruss C=Mac.
  • wweicht schrieb:

    Bitte beobachte das Problem mit den UVs weiterhin. Mir hat heute ein andere Anwender bestätigt, dass da wohl ein Problem existiert.

    C=Mac schrieb:

    Also funktioniert, funktioniert nicht, funktioniert .......
    Da ich selbst keine CMD-HD habe, kann ich da nicht viel herausfinden ....


    wweicht schrieb:

    möglichst genau beschreiben, was Du getan hast.

    C=Mac schrieb:

    Wenn ich das immer wüsste
    Was ich damit meine:

    - Nummer der Quell- und Ziel-Partition
    - Name der Quell- und Ziel-Partition
    - Größe der Quell- und Zielpartition
    - freier Platz auf Quell- und Ziel-Partition
    - Name des UVs auf Quell- und/oder Ziel-Partition

    Gerade der letzte Punkt klingt interessant. Unter Geos durfte man nie in 2 Laufwerken gleichen Types eine Diskette mit identischen Diskettennamen benutzen. Dann kam Geos völlig durcheinander, da anhand des Disknamen die Disketten angesprochen werden. Wenn jetzt auf beiden Partitionen UVs mit identischen Namen vorhanden sind, wäre das eine mögliche Ursache......
    Aus diesem Grund erlaubt Topdesk z.B. keine 1:1 Disketten-Kopie. Hier wird immer etwas geändert....

    Ohne konkretere Hinweise, kann ich da nicht viel machen. Das Problem müsste entweder in Topdesk oder in den 2 HD-Treibern (seriell und parallel) liegen .

    Gruß
    Werner
  • wweicht schrieb:

    Da ich selbst keine CMD-HD habe, kann ich da nicht viel herausfinden ....
    Ist mir bekannt, dass Du keine CMD-HD hast, macht auch nichts.
    Du bemühst Dich schon mehr, als man verlange kann/darf, um die Probleme der User :thumbup:


    wweicht schrieb:

    Was ich damit meine:

    - Nummer der Quell- und Ziel-Partition
    - Name der Quell- und Ziel-Partition
    - Größe der Quell- und Zielpartition
    - freier Platz auf Quell- und Ziel-Partition
    - Name des UVs auf Quell- und/oder Ziel-Partition
    Dann weiss ich jetzt, welche Informationen Du genau benötigst.
    Werd beim nächsten Problem darauf achten.


    wweicht schrieb:

    Gerade der letzte Punkt klingt interessant. Unter Geos durfte man nie in 2 Laufwerken gleichen Types eine Diskette mit identischen Diskettennamen benutzen. Dann kam Geos völlig durcheinander, da anhand des Disknamen die Disketten angesprochen werden. Wenn jetzt auf beiden Partitionen UVs mit identischen Namen vorhanden sind, wäre das eine mögliche Ursache......
    Beim letzten Versuch (27.08.17) hab ich definitiv unterschiedliche Namen bei den UV's benutzt.
    Dies war auch der Versuch, wo alles funktioniert hat.
    Bei den Versuchen, wo Probleme auftauchten, kann ich es nicht mehr mit 100%-iger Sicherheit sagen.
    Muss ich noch einmal probieren.

    Geb aber zu das ich , in der Zwischenzeit, nichts mehr mit MP3 gemacht habe :S

    Bin ja schon froh, dass das Problem nicht exklusiv für mich ist ;)

    Gruss C=Mac.
  • Bin endlich wieder dazu gekommen, mich mit MP3 (64) und den Unterverzeichnise zu beschäftigen :rolleyes:

    - Nummer der Quell- und Ziel-Partition: 35 / 36
    - Name der Quell- und Ziel-Partition: TEST MP3 EINS / TEST MP3 ZWEI
    - Größe der Quell- und Zielpartition: Je 65'024 Block's (laut Partitionsliste)
    - freier Platz auf Quell- und Ziel-Partition: Ups, hab ich jetzt nicht geschaut, aber > 15 MB
    - Name des UVs auf Quell- und/oder Ziel-Partition: TD COM 1 / TD COM 1

    Funktioniert nicht, die HD und/oder MP3 kriegt die Krise.
    Scheint Deine Annahme zu bestätigen :thumbup:

    - Nummer der Quell- und Ziel-Partition: 35 / 36
    - Name der Quell- und Ziel-Partition: TEST MP3 EINS / TEST MP3 ZWEI
    - Größe der Quell- und Zielpartition: Je 65'024 Block's (laut Partitionsliste)
    - freier Platz auf Quell- und Ziel-Partition: Ups, hab ich jetzt nicht geschaut, aber > 15 MB
    - Name des UVs auf Quell- und/oder Ziel-Partition: TD COM 1 / TD COM 2

    Funktioniert ohne Auffälligkeiten.

    Dies konnte ich immer wieder einwandfrei reproduzieren.

    Wird von einem UV in ein anderes kopier, dürfen die UV's nicht den gleichen Namen haben.

    Wieso ein kopieren von Partition zu Partition (Root-Verzeichnis) nicht funktioniert hat und auch das kopieren in und aus UV's unterschiedlicher Namens konnte ich bis jetzt nicht nachvollziehen.
    Im Moment funktioniert es ohne Probleme.

    Hab aber einen Verdacht:

    Und zwar das CMD-Gamepad, welches eigentlich immer in Port 2 steckte.
    Dies schein die analoge Eingänge des Joysticks-Port zu manipulieren/anzusprechen.
    Eventuell ist dieser Umstand auch für weitere (komische) Probleme verantwortlich, u.a. das schliessen des LW, anstelle des UV.
    Im Moment ist der einzige sichtbare Effekt das "zittern"/flackern des Mauszeigers, bis zum Geister-Mauszeiger.
    Hab dies bis jetzt immer der SCPU zu geschoben.
    Näheres zum Gamepad-Problem -> hier.

    Gruss C=Mac.
  • Hallo C=Mac,

    C=Mac schrieb:

    Bin endlich wieder dazu gekommen, mich mit MP3 (64) und den Unterverzeichnise zu beschäftigen

    C=Mac schrieb:

    Funktioniert ohne Auffälligkeiten.
    Dies konnte ich immer wieder einwandfrei reproduzieren.

    Wird von einem UV in ein anderes kopier, dürfen die UV's nicht den gleichen Namen haben.
    Danke für die Rückmeldung. Ein Problem weniger ... ;) .

    Gruß
    Werner
  • wweicht schrieb:

    Ein Problem weniger ... .
    Problem gelöst, ist immer gut :D

    Hab die UV-Sache in der Zwischenzeit auch auf dem C128D mit MP3-128 getestet.
    Genau gleiches Verhalten.


    Ebenfalls hab ich MP3-128 mit einem angeschlossenem CMD-Gamepad (Port 2) ausprobiert.
    Ergebnis -> unbedienbar. Der Mauszeiger flitzt unkontrollierbar über den Monitor.
    Keine Ahnung warum mir das früher nie aufgefallen ist.
    Entweder ich habe nie die Kombination MP3-128/CMD-Gamepad benutzt, oder irgendetwas hat sich verändert.

    Jedenfalls kann ich mir schon vorstellen, das dadurch MP3 beeinflusst wird und zu unerklärlichen Problemen führt.

    Wheels 64/128 zeigt sich vom CMD-Gamepad unbeeindruckt.

    Gruss C=Mac.
  • So mal ein paar kleine Hinweise :rolleyes:

    Wird bei MP3 64 der "64er Mover" als Bildschirmschoner verwendet.
    Darf der Hacken bei: "C=REU: Schnellen Speicher-Transfer aktivieren" nicht gesetzt sein, sonst stürzt MP3 beim verlassen des Bildschirmschoners ab.

    Zu finden im GEOS64.Editor -> Register "System" -> Movedata.

    Dies ist jedenfalls bei Verwendung der Ultimate REU der Fall, mit einer echten Commodore REU hab ich dies nicht getestet.


    Wird MP3 von einem SD2IEC (D81-Image) gestartet und es erscheint die Meldung: "Bitte eine Diskette einlegen die deskTop enthält", ist der Schreibschutz der SD-Karte aktiv.

    Gruss C=Mac.
  • Benutzer online 1

    1 Besucher