Ankündigung: cbm4win 0.1.0

Es gibt 102 Antworten in diesem Thema, welches 17.716 mal aufgerufen wurde. Der letzte Beitrag (23. April 2005 um 19:54) ist von strik.

  • Zitat

    Original von strik
    Ah so. Ja, das ist richtig, das geht in der derzeitigen Fassung nicht. Dafür kann man allerdings beispielsweise c1541 aus dem VICE Paket benutzen, welches in der nächsten Version 1.16 sogar cbm4win unterstützen wird. Allerdings ist c1541 auch ein Kommandozeilen-Tool.


    Nun ist sie ja da - die VICE Version 1.16 !
    Aber wie genau funzt denn das jetzt mit der Unterstützung ?( ?( ?(

  • Hat denn wirklich keiner eine Idee/Lösung parat ???

  • Zitat

    Original von Sid


    Nun ist sie ja da - die VICE Version 1.16 !
    Aber wie genau funzt denn das jetzt mit der Unterstützung ?( ?( ?(

    Meinst du VICE allgemein, oder c1541?

    VICE (z.B. x64): Settings/Peripheral Settings. Dann z.B. Laufwerk 8, "Use IEC device" wählen, und dann "Real IEC device" wählen.

    c1541: starte es mit "c1541 /dev/cbm"

    Ich wollte ja ursprünglich auf die VICE Knowledge Base verweisen, mußte aber feststellen, dass dafür noch gar kein Eintrag besteht. Es wird mit Sicherheit einer ergänzt.

    Gruß,
    Spiro.

  • Ahhh ja - Danke !!! :P
    Das war genau das, was ich wissen wollte... :]

  • strik:
    Aber kann es sein, das die "Zusammenarbeit" zwischen CBM4WIN und VICE nur bei dem C64- und dem C128-Emulator funktioniert ???
    CBM2 und PET sind klar, aber beim Plus/4 und beim VIC20 scheint es ja nicht zu funzen... :( ;(

  • Zitat

    Original von Sid
    strik:
    Aber kann es sein, das die "Zusammenarbeit" zwischen CBM4WIN und VICE nur bei dem C64- und dem C128-Emulator funktioniert ???
    CBM2 und PET sind klar, aber beim Plus/4 und beim VIC20 scheint es ja nicht zu funzen... :( ;(

    Eine gute Frage. Ich bin leider bislang noch nicht dazu gekommen es zu testen. Dies ist nur eine kurze Rückmeldung, dass ich das schon gelesen habe. :wink:

    Ich melde mich, wenn ich dazu gekommen bin. Sollte es länger dauern, dann erinnere mich ruhig noch einmal daran. :wink:

    Gruß,
    Spiro.

  • Zitat

    Original von strik
    ...Sollte es länger dauern, dann erinnere mich ruhig noch einmal daran. :wink:


    Gut, werde ich bestimmt machen...! ;) :P

  • Ich habe mir das Programm mit der GUI zusammen auf XP Prof. installiert. Soweit keine Probleme.
    Nun nutze ich das Programm in der GUI mit einer 1541-2 und einem XA1541 und stelle folgendes fest:
    Installtion und Bedienung sind einfach, den Programmierern sei Dank.
    Die Übertragungsarten (Datei oder Disk nach Image) die bei mir funktionieren sind 'Serial1' und 'Serial2' mit und ohne 'Warp'.
    'Original' funktioniert nicht - Fenster geht kurz auf, schliesst, keine Reaktion, keine Funktion.
    'Parallel' kann ich nicht testen, da ich keinen Speeder in der Floppy und kein XAP Kabel habe.
    Bei 'Serial1' dauert eine Übertragung von 448 Blocks in ein D64 File 3,5 min, mit 'Serial2' 1,5 min (mit 'Warp').
    Das Directory einlesen funktioniert in allen Varianten der Übertragung, dauert ca. 30 sec (31 Einträge), das erscheint mir sehr langsam.
    Formatieren geht blitzschnell, ca 18 sec.
    Disk von D64 Image dauert ca. 5,5 min bei 'Serial1' und ca. 2 min bei 'Serial2'.

    Fragen:
    Hat jemand ähnliche oder andere Ergebnisse? Das Directory einlesen scheint mir sehr langsam.
    Beschleunigt ein Jiffy Dos in der Floppy das Kopieren?

    Heute Abend werde ich nochmal das Ganze über die DOS Ebene testen.

  • Hallo,

    Zitat

    Original von rp-64
    Die Übertragungsarten (Datei oder Disk nach Image) die bei mir funktionieren sind 'Serial1' und 'Serial2' mit und ohne 'Warp'.
    'Original' funktioniert nicht - Fenster geht kurz auf, schliesst, keine Reaktion, keine Funktion.

    Das ist sehr komisch und sollte so gar nicht auftreten. Es wäre gut, wenn du das mal von der Kommandozeile aus testen könntest.

    Zitat

    Bei 'Serial1' dauert eine Übertragung von 448 Blocks in ein D64 File 3,5 min, mit 'Serial2' 1,5 min (mit 'Warp').

    Die Werte scheinen im normalen Bereich zu liegen. Nutzt du dafür den Warp-Modus, oder sind das Werte ohne Warp?

    Zitat

    Das Directory einlesen funktioniert in allen Varianten der Übertragung, dauert ca. 30 sec (31 Einträge), das erscheint mir sehr langsam.

    Ja, das ist deutlich zu lange und könnte auf ein Übertragungsproblem hindeuten. Das könnte mit Bitte melde dich an, um diesen Link zu sehen. zu tun haben, wofür es allerdings noch keine endgültige Lösung gibt.

    Zitat

    Formatieren geht blitzschnell, ca 18 sec.

    Ist die Diskette danach problemlos lesbar? Es gibt da ein Problem mit cbmformat (Bitte melde dich an, um diesen Link zu sehen.), welches bei Laufwerken auftritt, bei denen sich das Laufwerk besonders schnell dreht. Auch dafür gibt es noch keinen Fix.

    Zitat

    Disk von D64 Image dauert ca. 5,5 min bei 'Serial1' und ca. 2 min bei 'Serial2'.

    Es ist meistens so, dass das Beschreiben länger dauert. Dies liegt insbesondere daran, dass der Warp-Modus da nicht so effektiv sein kann.

    Zitat

    Hat jemand ähnliche oder andere Ergebnisse? Das Directory einlesen scheint mir sehr langsam.

    Bis auf den oben beschriebenen Bug-Report kenne ich keinen weiteren Fall, wo dass Directory einlesen (welches auf jeden Fall mit dem Original-Protokoll ausgeführt wird!) so lange dauert.

    Was für einen Rechner hast du denn? Irgend etwas mit Hyperthreading oder eine Doppel-CPU-Maschine?

    Zitat

    Beschleunigt ein Jiffy Dos in der Floppy das Kopieren?

    Nein, JiffyDos kann nicht genutzt werden. JiffyDos benötigt ein sehr exaktes Timing, welches ich unter einem nicht-echtzeitfähigen Multitasking-System wohl unmöglich herstellen kann.

    Zitat

    Heute Abend werde ich nochmal das Ganze über die DOS Ebene testen.

    Das wäre auf jeden Fall hilfreich, da so ausgeschlossen werden könnte, dass die Probleme von gui4cbm4win erzeugt werden.

    Gruß,
    Spiro.

  • strik

    Vielen Dank für die raschen Antworten.

    Habe nochmal etwas getestet.
    Die Übertragung mit 'Original' geht in der DOS Oberfläche, komischerweise ging sie eben auch in der GUI. Hat sich also erledigt.

    Das Anzeigen des DIR dauert im DOS Modus fast genau so lange.
    Der DOS Modus ist aber insgesamt bei allen Funktionen etwas schneller.

    Die Lesbarkeit einer formatierten Disk habe ich noch nicht ausgiebig getestet, jedoch funktioniert eine aus einem D64 erstellte Disk einwandfrei.

    Mein Rechner ist ein P4 3,20 mit HT und XP Prof.

    Beim Formatieren mit 'cbmctrl command 8 n0:test,21' fängt die Led des Floppy an zu blinken, status 31,syntax error,00,00
    'cbmctrl open 8 15 n0:test,21' geht auch nicht.

    Mach ich hier was falsch?

    Formatieren mit cbmformat geht einwandfrei.

    Achja nochwas, es ist ärgerlich Funktionen aus der GUI mit dem Taskmanager abzubrechen, hier wäre ein 'Abbrechen Buttun' hilfreich, wenn sowas geht.

  • Zitat

    Original von rp-64
    Das Anzeigen des DIR dauert im DOS Modus fast genau so lange.

    Hm... Im Zusammenhang mit

    Zitat

    Mein Rechner ist ein P4 3,20 mit HT und XP Prof.

    vermute ich, dass es tatsächlich ein Problem mit dem HT ist. Der Bug-Report Bitte melde dich an, um diesen Link zu sehen. stammt nämlich von jemandem, der eine SMP-Maschine einsetzt.

    Hast du auf deinem Rechner cygwin installiert? Falls ja, kannst du ja einen der beiden Befehle

    Code
    sleep 100000000000

    oder

    Code
    tail -f somefiletowatch.log

    probieren, wie er im obigen Bug-Report als work-around genannt wurde (wobei "somefiletowatch.log" durch irgendeine Text-Datei ersetzt werden muß!).


    Zitat

    Beim Formatieren mit 'cbmctrl command 8 n0:test,21' fängt die Led des Floppy an zu blinken, status 31,syntax error,00,00
    'cbmctrl open 8 15 n0:test,21' geht auch nicht.

    Du mußt das "N" groß schreiben, also:

    Code
    cbmctrl command 8 N0:test,21

    .


    Zitat

    Achja nochwas, es ist ärgerlich Funktionen aus der GUI mit dem Taskmanager abzubrechen, hier wäre ein 'Abbrechen Buttun' hilfreich, wenn sowas geht.

    Ich bin ja nicht der Programmierer der GUI, sondern "nur" des unterliegenden cbm4win. Das Problem bei der jetzigen Implementierung ist wohl, dass die GUI komplett die Kontrolle abgibt, wenn ein cbm4win Programm ausgeführt wird. Das heißt, dass auf Buttons gar nicht mehr reagiert werden kann, wodurch sich das ganze etwas schwer gestaltet.

    Möglicherweise gibt es da in einer der nächsten Versionen eine Lösung für, zur Zeit ist das aber leider noch nicht möglich - es sei denn du überredest Leif Bloomquist, den Autor der GUI, mit Multitasking anzufangen. :wink:

    Gruß,
    Spiro.

  • Zitat

    Original von strik
    Hast du auf deinem Rechner cygwin installiert? Falls ja, kannst du ja einen der beiden Befehle

    Code
    sleep 100000000000

    ...

    Falls nicht: Ich habe unter Bitte melde dich an, um diesen Link zu sehen. ein ZIP-File abgelegt, welches den Sleep-Befehl von cygwin und alle notwendigen DLLs enthält (etwa 1,2 MB groß!). Wenn du das auspackst, kannst du von dort den oben genannten sleep-Befehl ausführen. Es wäre interessant, ob damit das Einlesen des Directories schneller geht, wenn "daneben" der sleep-Befehl ausgeführt wird.

    Gruß,
    Spiro.

  • strik

    Hallo, nein ich habe cygwin nicht installiert, ich weiss gar nicht was das ist. :rotwerd:
    Werde mich aber mal drum kümmern und melde mich dann wieder.
    Das Formatieren geht auch mit großem N nicht.
    Ich werde versuchsweise cbm4win mal auf einem P3 installieren, mal sehen wie es da reagiert.

  • Auf dem PIII (Notebook) läuft es wohl einwandfrei.
    Hab hier allerdings ein XM1541 Kabel.
    Formatieren mit cbmctrl in 1,5 min, mit cbmformat 15sec.
    D64copy D64 -> Disk 2,25 min.
    DIR 15 sec.
    In der GUI wieder unwesentlich langsamer.
    FASZINIEREND das Ganze. Ein HOCH auf die Programmierer.
    Zeit fürn Frühschoppen. Prost.

    :bia:party:


    Ich traue es mich gar nicht zu sagen: :rotwerd::rotwerd::rotwerd:

    Das mit dem Formatieren lag an einer defekten Diskette. :baby:

    Die defekte Disk hat dann auch den DIR Befehl gebremst, dauert jetzt ca. 20 sec.

  • Zitat

    Original von rp-64
    Das mit dem Formatieren lag an einer defekten Diskette. :baby:

    Die defekte Disk hat dann auch den DIR Befehl gebremst, dauert jetzt ca. 20 sec.

    Nur um es richtig zu verstehen: Damit gibt es nun keine Probleme mehr, weder mit dem "großen" Rechner, noch mit dem Laptop?

    Und, bezüglich "defekte Diskette": Bedenke bitte, dass der Fehler von cbmformat - so du denn ein schneller Diskettenlaufwerk hast, d.h., die Diskette dreht sich schneller als etwa 305 Umdrehungen/Sekunde - dafür sorgt, dass die Diskette danach "scheinbar" defekt ist. Ein Formatieren mit N0:NAME,ID behebt das Problem aber.

    Das war bei dir nicht der Fall, oder?

    Gruß,
    Spiro.

  • strik

    Nein, die Disk war wohl eindeutig defekt.
    Hatte das Problem ja auch beim langsamen Formatieren.

    Habe an dem Notebook eine andere 1541-2 wie an dem P4 dran, an der Geschwindigkeit der Floppydrehzahl kann es dann wohl nicht liegen, habe auch unterschiedliche Disketten genommen.

    Eine Disk mit dem schnellen cbmformat lässt sich auch beschreiben und lesen - zumindest in den beiden 1541ern.

    Probleme mit dem "großen" Rechner sehe ich erst, wenn andere erheblich schnellere Zugriffszeiten melden.

    Aber ich habe soeben ein Phänomen an dem "großen" P4 festgestellt:

    Ich nutze hier eine TV-Software für eine TV-Karte (Cinergy 600) um meine 64er und 20er Lieblinge an einen 17" Sony anzuschliessen.
    Wenn ich diese Software starte, beschleunigt das den DIR Befehl auf 7! sec in der GUI. Kann mir nicht erklären warum.

  • Zitat

    Original von rp-64
    Eine Disk mit dem schnellen cbmformat lässt sich auch beschreiben und lesen - zumindest in den beiden 1541ern.

    Wenn sie sich lesen läßt, dann ist alles in Ordnung.

    Das Problem mit dem Format ist, dass es bei schneller Floppies einen Teil dessen, was es schon geschrieben hat, am Ende überschreibt. Entweder gehen solche Disketten danach also bei allen Laufwerken (weil nichts überschrieben wurde), oder bei keinem einzigen.

    Zitat


    Aber ich habe soeben ein Phänomen an dem "großen" P4 festgestellt:

    Ich nutze hier eine TV-Software für eine TV-Karte (Cinergy 600) um meine 64er und 20er Lieblinge an einen 17" Sony anzuschliessen.
    Wenn ich diese Software starte, beschleunigt das den DIR Befehl auf 7! sec in der GUI. Kann mir nicht erklären warum.

    Genau das ist das Phänomen, was auch in dem oben angesprochenen Bugreport berichtet wurde und welches sich durch das "sleep" von cygwin beheben lassen soll. Jetzt würde es mich wirklich interessieren: Kannst du das sleep von meiner Webseite runterladen und auf der Kommandozeile starten, während die mit cbm4win arbeitet? Es wäre interessant, ob danach der dir-Befehl auch um so viel schneller ist?

    Wenn das geht, könnte ich da eventuell etwas in cbm4win einbauen, was den gleichen Effekt hat. Dazu müßte ich aber wissen, ob sleep das Problem wirklich löst.

    Gruß,
    Spiro.

  • strik

    Werde ich machen, wird aber etwas dauern. Melde mich heute nachmittag.

  • strik

    Jetzt flutscht es.
    Sleep bringt nichts aber tail -f .... erreicht, dass das DIR in 5 sec angezeigt wird, disk to image dauert 1min35, image to disk 1min40, in der GUI ist die Geschwindigkeit fast gleich.

    Das nenne ich jetzt problemlos.