Hallo Besucher, der Thread wurde 82k mal aufgerufen und enthält 735 Antworten

letzter Beitrag von skern am

DT128-Native-Copy Test für MegaPatch128

    Zitat von Pusti64

    Ich versuche das mit dem UV mal bei mir nachzustellen (wenn meine 1571 nur nicht kaputt wäre ).

    Betrifft nicht nur die 1571, wie auch darkvision schon erwähnt hat.


    Ob man sich deswegen jetzt einen Aufwand antun will?
    Ist ja eher ein Schönheitsfehler.



    Zitat von Pusti64

    Beim Umformatieren einer 1571 hast Du aber schon vorher den 1571 Treiber aktiviert? Wenn ja, dann mal kurz eine andere 1571 Disk einlesen. Dann die 1541 Disk einlegen und sofort ohne erneutes einlesen der Disk Formatieren. Funktioniert das dann wenigstens?

    Ja der 1571-Treiber ist aktiviert, es wird auch gefragt: "Doppelseitig"/"Einseitig".
    Einseitiges formatieren klappt immer, beim Doppelseitigen kommt es zum beschriebenen Fehler, leider nicht immer.
    Meist hilft es die Disk zuerst einseitig zu formatieren und dann gleich Doppelseitig.
    Oder ich nehme einfach GeoDOS. ^^


    Gruss C=Mac.

    Zitat von C=Mac

    Ja der 1571-Treiber ist aktiviert, es wird auch gefragt: "Doppelseitig"/"Einseitig".Einseitiges formatieren klappt immer, beim Doppelseitigen kommt es zum beschriebenen Fehler, leider nicht immer.
    Meist hilft es die Disk zuerst einseitig zu formatieren und dann gleich Doppelseitig.
    Oder ich nehme einfach GeoDOS. ^^


    Gruss C=Mac.

    Fehler $10 ist gar nicht im MegaAss-Handbuch beschrieben :gruebel


    Pusti64

    Zitat von Pusti64

    Fehler $10 ist gar nicht im MegaAss-Handbuch beschrieben

    Den gibts eigentlich auch nicht, im 128 Programmers Reference Guide steht das man alle Meldungen unterhalb von 20 (bis auf 01) ignorieren soll... Aber evtl. kommt der Fehler von woanders und es wird dann nur ein falscher Wert im XReg zurückgegeben.


    Unter GeoDOS wechsle ich vorher bei der 1571 in den 1541-Modus (einseitig) oder 1571-Modus (doppelseitig). Die Routinen Set1541/71Mode finden sich hier. Unter GeoDOS wählt man aber vorher ob ein- oder doppelseitig.

    Zitat von darkvision

    Den gibts eigentlich auch nicht, im 128 Programmers Reference Guide steht das man alle Meldungen unterhalb von 20 (bis auf 01) ignorieren soll... Aber evtl. kommt der Fehler von woanders und es wird dann nur ein falscher Wert im XReg zurückgegeben.
    Unter GeoDOS wechsle ich vorher bei der 1571 in den 1541-Modus (einseitig) oder 1571-Modus (doppelseitig). Die Routinen Set1541/71Mode finden sich hier. Unter GeoDOS wählt man aber vorher ob ein- oder doppelseitig.

    Wenn das mit der 1571 noch jemand bestätigen könnte, dann schau ich mir das mal mit an. Kann es selbst leider nicht testen, weil meine 1571 nur noch tierische Streifen auf den Disketten zieht.
    Bin aber gerade damit beschäftigt auch den Sourcecode für Desk Top 4.1 zu erstellen. Aufgrund der ständigen Neuerungen habe das nun endlich mit in Angriff genommen. Sind halt zig, zig Seiten Quellcode und dauert halt noch und möchte es auch selber einfach fertig haben :puhh:


    Pusti64

    Ich hab eben meine 1571 ausgemottet und nachdem ich da ein Stromkabel gefunden hab auch mal getestet (man ist das Teil Laut!!! =O )


    Also am C64 zuerst einseitige Disk eingelegt und geöffnet.
    Formatieren ausgewählt.
    Doppelseitig,
    Klappt.


    Einseitige Disk eingelegt und geöffnet.
    Fenster geschlossen.
    Neue Disk (2-seitig-formatiert) eingelegt
    Formatieren gewählt
    Doppelseitig,
    Klappt.


    Was aber echt seltsam klingt ist wenn man von eine zweiseitigen Disk zuerst die eine Seite einseitig formatiert und dann die Disk dreht und die zweite Seite auch einseitig formatieren will. Das Laufwerk rödelt da mehrfach rum, so als würde TopDesk versuchen die Disk zu lesen/zu öffnen...


    @C=Mac: Am C64 konnte ich da jetzt nichts feststellen. Wenn Du das etwas besser beschreiben bzw. reproduzierbar wiederholen kannst dann teste ich das nochmal.

    Ich hab mir den Code mal angeschaut... evtl verstehe ich da was falsch:


    Ab Zeile #1 wird der Laufwerktyp getestet.
    Falls keine 1571 wird in Zeile #4 der folgende Code übersprungen (bne :2).
    Bei einer 1571 wird abhängig von a1L(Einseitig=$00, Doppelseitig=$01) der U0>Mx-Befehl angepasst.


    Ab Zeile #24 wird dann nochmal auf die 1571 getestet, vermutlich nachdem der N0:-Format-Befehl gesendet wurde.
    Wenn a1L=$01(Doppelseitig) dann wird der folgende Code übersprungen (bne :3).
    Jetzt wird der U0>Mx-Befehl nochmals angepasst, diesmal aber auf den 1571-Modus/Doppelseitig obwohl man einseitig formatieren will.


    Wenn man einseitg wählt (a1L=$00) dann wird einmal auf die 1541 umgeschaltet und später dann auf die 1571???


    Oder versteh ich das nur einfach nicht (C128 + 1571 sind nicht so meins...)

    Zitat von Pusti64

    Mal schauen, wie weit ich da mit den 5 gewonnenen Bytes komme
    Wie gewonnenen so zerronnen

    Ach, dass ist nicht so schlimm ;-) . Ich würde fast eine Wette eingehen, solche unsinnigen Befehle finden sich bestimmt an mehreren Stellen im TD :bgdev .


    Gruß
    Werner


    PS:


    Zitat von C=Mac

    So langsam wird das noch was mit dem TD.

    Man muss als Anwender aber dringend auf 2 Dinge erstmal selbst achten:


    1. CMD-UVs in TD-Ordnern sind auf jeden Fall tödlich ;-) . Es ist also generell zumindest gefählich, sie auf Native-Mode-Lfw. mit UVs einzusetzen.


    2. Auf Native-Mode-Laufwerken mit CMD-UVs darf auf KEINEM FALL die TD-Funktion "Directory sortieren" (C= T) verwendet werden.
    Jedes UV speichert in seinem Header den Track und Sektor des Directory-Blocks wo es steht und die genaue Position in diesem Block. Wird durch "Directory sortieren" da was geändert (das ist ja der eigentliche Sinn dieser Funktion ;-) ), ist das UV nicht mehr brauchbar und sehr wahrscheinlich auch die Datei kaputt, die jetzt auf dieser Position steht....

    Zitat von Pusti64

    eine neue Testversion mit Trackanzeige (rückwärtslaufend) beim Diskcopy und UV-Patch

    Funktioniert hier ohne Probleme. Echt gut gemacht. :thnks:



    Vorschlag zur Einsparung von ein paar Bytes:


    Schreibe doch in die Menü-Zeile nur noch "Kopiere Disk". Die Übernahme des Disk-Namens ist doch theoretisch nicht nötig, da das Quell-Fenster doch auf dem Bildschirm geöffnet ist und der Diskname dort zu sehen ist ..... ;-)


    Gruß
    Werner

    Zitat von Pusti64

    Fehler $10 ist gar nicht im MegaAss-Handbuch beschrieben

    Leider zeigt TD nichts genaueres an? :nixwiss:



    Hab es noch einmal probiert.


    Diskette im 64'er-Modus des C128D formatiert (1541 Format).


    Wechsel in den C128'er-Modus, MP3-128 booten.


    Unter TD versucht die Diskette zu formatieren (Doppelseitig, 1571 Format) = Abbruch Fehler $10.
    Rein akustisch klingt es normal, zuerst die einte Seite und dann die Zweite, dann Abbruch mit der Fehlermeldung.


    Versuche ich die "nicht" formatierte Diskette zu öffnen erhalte ich: Ungültiger Track; Fehlercode $02 (was ja klar ist).


    Es spielt keine Rolle ob ich die "1541-Diskette" zu erst öffne oder direkt formatieren will.


    Und es betrifft auch MP3/TD-64, jedenfalls am C128D.


    GeoDOS konnte alle Disketten - bis auf eine - formatieren, egal ob einseitig, doppelseitig , oder von einseitig auf doppelseitig.


    Bei der Diskette welche GD nicht formatieren konnte (Format egal) hab ich als Fehler: Falsche Disketten-ID; Code 42 erhalten.
    Komischerweise zeigte Basic eine formatierte Diskette an und die Diskette konnte unter Basic (1571 Format) problemlos formatiert werden.


    Vielleicht stirb auch langsam meine 1571, wer weiss schon.
    Wird ja auch nicht mehr so oft gebraucht, dank SD2IEC und Ultimate 2+.



    Zitat von wweicht

    Man muss als Anwender aber dringend auf 2 Dinge erstmal selbst achten:


    1. CMD-UVs in TD-Ordnern sind auf jeden Fall tödlich . Es ist also generell zumindest gefählich, sie auf Native-Mode-Lfw. mit UVs einzusetzen.


    2. Auf Native-Mode-Laufwerken mit CMD-UVs darf auf KEINEM FALL die TD-Funktion "Directory sortieren" (C= T) verwendet werden.
    Jedes UV speichert in seinem Header den Track und Sektor des Directory-Blocks wo es steht und die genaue Position in diesem Block. Wird durch "Directory sortieren" da was geändert (das ist ja der eigentliche Sinn dieser Funktion ), ist das UV nicht mehr brauchbar und sehr wahrscheinlich auch die Datei kaputt, die jetzt auf dieser Position steht....

    Danke für die Tipps.


    1. Ich benutze zwar TD-Ordner in Native Partitionen/Image, aber nicht innerhalb von UV's und schon gar nicht UV's in TD-Ordner.


    2. Der Sortierfunktion bin ich schon immer misstrauisch gegenüber gestanden.
    Wollt zwar auch schon eine HD-Native-Partition - inkl. UV's - "sortieren" aber hab es sein lassen, zum Glück.


    Gruss C=Mac.

    Zitat von C=Mac

    2. Der Sortierfunktion bin ich schon immer misstrauisch gegenüber gestanden.

    Sie hat aber auch einen Sinn.


    Bsp.: Geowrite oder GeoPaint und Fonts. Das Programm kann ja nur 8 Fonts. Hat man mehr und will die benutzen: Einfach die Fonts auf Disk nach vorne holen.


    Oder man will auf einer Disk Dateien sortieren: Einfach in der richtigen Reihenfolge anklicken und C= T. Erledigt. ......


    Gruß
    Werner

    Zitat von wweicht

    Funktioniert hier ohne Probleme. Echt gut gemacht. :thnks:
    Gruß
    Werner

    Vielen Dank ;-)


    Dafür habe ich noch keinen blassen Schimmer, wie ich das neue Problem mit dem schließen vom Quelllaufwerk nach dem Kopieren in ein UV lösen kann. :gruebel
    Gut möglich, dass W.Grimm genau aus diesem Grund damals die Routine aus Post 32 so konstruiert hat.


    Pusti64

    Stimmt, ist schon etwas verwirrend. Kann mich aber auch nicht großartig daran erinnern, dass meine 1571 (als sie noch funktionierte) unter MP3 nicht gefunzt hat.


    @Werner
    Ist Dir da jemals was aufgefallen?


    Pusti64

    Zitat von Pusti64

    Stimmt, ist schon etwas verwirrend. Kann mich aber auch nicht großartig daran erinnern, dass meine 1571 (als sie noch funktionierte) unter MP3 nicht gefunzt hat.

    Wenn ich mir das so nochmal durchlese schaltet man nach dem einseitigen formatieren wieder zurück in den 1571-Modus. Sonst würde die 1571 ja im 1541-Modus verbleiben. Wäre also gar nicht so falsch... Oder tritt das nur bei TD128 auf? :gruebel

    Zitat von C=Mac

    1541-Disk können nicht auf 1571 umformatiert werden = Diskfehler $10, dies betrifft auch falsch formatierte Disketten.

    Zitat von Pusti64

    @Werner
    Ist Dir da jemals was aufgefallen?

    @Pusti64 bitte pass auf was Du hier schreibst. Mein Name hier lautet etwas anders ;-) . Jetzt bekommt der User "Werner" hier eine Nachricht, dass Du ihn hier erwähnt hast und das bin nicht ich ..... ;-) .


    Das Problem scheint noch etwas größer zu sein. Habe hier eine 1571-Diskette im Normalmode des C128 formatiert. Meine 1571 (mit JiffyDos; interne Floppy des C128DCR) steht im Normalmode und in MP3 fest auf Adresse 10. Geht anstandslos. MP3 geladen und die Diskette angeschaut. Alles i.O.
    Jetzt habe ich diese Diskette unter MP3-128 mit TD erneut formatiert. Fehler hier: Diskfehler $1D und nicht $10, wie @C=Mac erwähnt hat.
    Diskette nicht brauchbar. Das gleiche gleich nochmal, wieder Fehler $1D.


    Dann in MP3-128 diese Diskette als 1541 formatiert (beide Seiten der Disk): bei der 1. Seite alles normal, bei der 2. Seite dauert es etwas, bis das Laufwerk mit dem Formatieren beginnt. Scheint irgendeine Sync-Marke oder was auch immer zu suchen. Aber auch diese Seite ist jetzt OK.


    Jetzt gleich wieder (Seite 1) als 1571 formatiert.: Wieder Fehler $1D. Beim 2. Versuch (Seite 1) läuft das Formatieren durch. Disk OK.


    Scheint irgendwie vom Zufall abzuhängen, ob bei 1571-Format korrekt formatiert wird oder nicht.....


    Gruß
    Werner

    Zitat von Pusti64

    Dafür habe ich noch keinen blassen Schimmer, wie ich das neue Problem mit dem schließen vom Quelllaufwerk nach dem Kopieren in ein UV lösen kann.

    Ist ja nicht so tragisch, 2x klicken oder einmal lange.
    Wie gesagt, eher ein Schönheitsfehler.
    Wenigstens funktioniert das Schliessen von UV's richtig. :thumbsup:



    Zitat von wweicht

    Diskfehler $1D und nicht $10, wie @C=Mac erwähnt hat.

    O.K.
    Ich schau mir das nochmal, mit der Lupe, an.
    Kann sein das ich es falsch gelesen habe und es $1D heisst und nicht $10. :S



    Zitat von wweicht

    Scheint irgendwie vom Zufall abzuhängen, ob bei 1571-Format korrekt formatiert wird oder nicht.....

    Schön das der Fehler nicht exklusiv für mich ist. ;)
    Das mit dem Zufall hab ich auch schon gedacht, mal geht's, mal doch nicht.
    Übrigens in meinem C128D (Plastik) ist auch JD verbaut.


    Gruss C=Mac.

    Zitat von wweicht

    2. Auf Native-Mode-Laufwerken mit CMD-UVs darf auf KEINEM FALL die TD-Funktion "Directory sortieren" (C= T) verwendet werden.

    Von mir ein :thnks: für den Hinweis. Das betrifft ja alle Programme die das Directory durcheinanderwürfeln...


    @Pusti64: Falls Du darüber nachdenken solltest da was anzupassen:
    GeoDOS kann ja auch Verzeichnisse sortieren. Ich hab jetzt am Ende den Aufruf einer Sub-Routine ergänzt der dann bei NativeMode die Verzeichnis-Sektoren des aktuellen Verzeichnisses einließt und die Header anpasst. Die Routine arbeitet bis auf die Hinweis-Dialoge nur mit GEOS-Routinen und ist überschaubar, ca. 60 Zeiilen Code., wäre also leicht zu portieren. Nur falls Du Bedarf hast.

    Zitat von darkvision

    @Pusti64: Falls Du darüber nachdenken solltest da was anzupassen:
    GeoDOS kann ja auch Verzeichnisse sortieren. Ich hab jetzt am Ende den Aufruf einer Sub-Routine ergänzt der dann bei NativeMode die Verzeichnis-Sektoren des aktuellen Verzeichnisses einließt und die Header anpasst. Die Routine arbeitet bis auf die Hinweis-Dialoge nur mit GEOS-Routinen und ist überschaubar, ca. 60 Zeiilen Code., wäre also leicht zu portieren. Nur falls Du Bedarf hast.

    Selbstverständlich hätte ich Bedarf ;-)


    Hänge hier aber irgendwie fest. Ich habe jetzt mal Testweise in der Routine aus Post 32 vor bzw. auch nach jsr Tst_dblClick bcc .... folgenden Code eingefügt.


    ldx $042f
    lda $0502,x
    jsr SetDevice


    Wenn ich damit das betreffende Lfw-Fenster schließen möchte, "schmiert" mir TD128 einfach nur mit Fehler bei $01ff ab. :-(


    Pusti64

    Zitat von Pusti64

    ldx $042f
    lda $0502,x
    jsr SetDevice

    Versuchs mal mit folgendem Code... der ersetzt den LDA CURTYPE-Befehl aus Post#32:

    Code
    1. .C:52d0 AC 2F 04 LDY $042F ;Aktuelles Fenster
    2. .C:52d3 B9 02 05 LDA $0502,Y ;Laufwerk für aktuelles Fenster
    3. .C:52d6 A8 TAY
    4. .C:52d7 B9 86 84 LDA $8486,Y ;Typ für aktuelles Fenster aus driveType-8


    Nicht über die Adressen wundern... ich hab das irgendwo im Speicher kurz als Unterprogramm eingebaut damit ich nicht nach freiem Speicher suchen muss ;)


    Sieht dann im ganzen so aus:


    Bei mir scheint es zu funktionieren...


    P.S. Wobei man da noch was optimieren könnte... LDY $042F ist unnötig. im XReg ist ja der Wert schon vorhanden. LDA $0502,y -> LDA $0502,x. Der Rest muss so bleiben. Dann wären das nur 4 extra Bytes... vorher 5 eingespart. Passt :)

    Ach herrje, da habe ich mich aber wieder kompliziert angestellt. Habe noch richtig viel zu lernen.


    Dankeschön Pusti64

    Zitat von Pusti64

    Ach herrje, da habe ich mich aber wieder kompliziert angestellt. Habe noch richtig viel zu lernen.

    Kein Problem, hatte das ja auch überlegt mit SetDevice. Aber nachdem es bei Dir nicht funktioniert hat (ich hab gar nicht erst versucht das Problem zu finden...) hab ich doch den indirekten Weg über driveType getestet... Wenn man jetzt einfach den überflüssigen CMD-Test direkt durch die beiden Befehle+1NOP ersetzt und curType durch driveType-8,y ersetzt, dann dürfte alles schon erledigt sein...