Hallo Besucher, der Thread wurde 36k mal aufgerufen und enthält 195 Antworten

letzter Beitrag von C=Mac am

MP3 Patch und Laufwerksverwaltung

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



    Um was für Partitionen handelt es sich da (81, Native, ....)?

    Natürlich Native (16 MB) ^^
    Was soll ich mit dem Kleinkram ;)



    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.

  • 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,

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



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



    Ö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)?



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

    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.



    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?



    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 http://c64.webgrimm.de/ .



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


    Gruß
    Werner

  • 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



    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.



    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.



    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.



    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.



    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.



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

    Kommt Zeit, kommt Rat :D
    Wie gesagt, eilt nicht.


    Gruss C=Mac.

  • Hallo C=Mac,

    Mit welchem Programm erstellst Du die Unterverzeichnisse?

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

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



    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



    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.



    Welche Version von GeoDOS benutzt Du?

    V2.951, sollte die letzte Version sein.



    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.



    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:



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



    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.

  • V2.951, sollte die letzte Version sein.

    Jep ;-) .



    Es funktioniert einfach.

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



    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

  • 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,

    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

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



    was Du getan hast....

    Wenn ich das immer wüsste :rolleyes:



    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.

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

    Also funktioniert, funktioniert nicht, funktioniert .......

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



    möglichst genau beschreiben, was Du getan hast.

    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

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



    Dann weiss ich jetzt, welche Informationen Du genau benötigst.
    Werd beim nächsten Problem darauf achten.



    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,

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

    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

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