Hallo Besucher, der Thread wurde 6,3k mal aufgerufen und enthält 16 Antworten

letzter Beitrag von strik am

an alle die mit VICE arbeiten, oder sonst einem Emulator

    Hallo zusammen,


    Ich nehme unter Linux den VICE-Emulator für den VC-20 + C64 her, ich habe einen Joystickadapter mir selbst gebaut, wo ich die alten Joysticks anstecken kann, dieser funzt prima.
    Damals unter MS-DOS, nahm ich den Star Commander her mit dem Kabel für die 1541'er Disk, hat unter DOS supi funktioniert, nun meine Frage, welches Kabel brauche ich, um mit dem ?
    VICE ein oder mehrere Dick-Laufwerke (diese hätte ich dann am Floppy durchgeschleift ) zu betreiben, bzw. ich will auch noch meinen alten Commodore Plotter und nen 2 Farbdrucker für den VC-20 anschließen.


    a) Gibt es da überhaupt ein Kabel ?
    b) funktioniert das überhaupt ?


    Einen USB-Serial bzw USB-Parallel Adapter habe ich genügend.


    um D64 Images zu machen da nehme ich nach wie vor unter DOS-BOX den Star Command her, jedoch wird unter diesem Emulator keine Schnittstellen COM1-4, bzw. Printer-Port unterstützt.
    Ne andere Soft unter Linux wie den Star Commander habe ich leider nicht zum laufen bekommen auf meinem System.


    Also für alle Infos wäre ich sehr dankbar.


    Lg. Toni


    PS: die Anleitung zum VICE habe ich mir so halbwegs ein paar Mal durchgelesen, aber bin ned gerade schlau geworden, grins :)

    Starcommander wird mit Dosbox nicht funktionieren, da Starcommander sehr empfindlich mit den Timing der Schnittstellen ist, soweit ich mich richtig erinnere ! Zur not geht Msdos über VMware oder auch einer Bootdiskette mit Starcommander drauf, ist aber beides sehr langsam ;)
    Das Kabel muss glaube ich zumindest ein XE Kabel sein wenn ich mich nicht irre.

    Zitat von Bazong

    Starcommander wird mit Dosbox nicht funktionieren, da Starcommander sehr empfindlich mit den Timing der Schnittstellen ist, soweit ich mich richtig erinnere

    Auf einem 32-Bit-Windows kann SC sehr wohl auf das Laufwerk zugreifen, wenn OpenCBM ("cbm4linux" oder, in dem Falle, "cbm4win") installiert ist. Dann nutzt es eben OpenCBM zum Zugriff auf die Hardware. Dafür hat OpenCBM extra einen VDD ("virtual device driver") installiert.


    Das funktioniert unter 64-Bit-Windows aber leider nicht mehr, weil MS den Support für VDD rausgeworfen hat.

    Haha, dann noch eine 1541U anschließen und man hat eine emulierte Floppy an einem emulierten Bus auf einer emulierten Maschine die auf einem virtuellen PC läuft :thumbsup:

    Zitat von GenerationCBM

    Liefe das eigentlich aus einer VM heraus, auf der ein 32Bit-Windows installiert ist? Wenn ja, welche VM?

    Da könnte man was bauen, zur Zeit ist das allerdings nicht funktionsfähig.


    Allerdings stellt sich dann doch so langsam die Sinn-Frage? Nimm doch OpenCBM für den Transfer und dann SC (oder andere Tools) für die Manipulation der Images, was spricht dagegen?

    Zitat von strik

    Nimm doch OpenCBM für den Transfer und dann SC (oder andere Tools) für die Manipulation der Images, was spricht dagegen?

    Nichts, mache ich ja schon. :)
    Ich bin allerdings mit den existierenden GUI-basierten Transfertools nicht so recht zufrieden, ich denke da ist noch so einiges an Luft nach oben. Star Commander z.B. aus der Windows-eigenen "XP Mode"-VM heraus nutzen zu können wäre zumindest eine erwägenswerte Alternative, wenn es ginge.


    Allerdings gibt's auch bei den Kommandozeilen-Tools (die ich üblicherweise bevorzuge) so ein-zwei Sachen, die ich vermisse bzw. gerne hätte. Von daher - was ist schon perfekt...

    Zitat von GenerationCBM

    Star Commander z.B. aus der Windows-eigenen "XP Mode"-VM heraus nutzen zu können wäre zumindest eine erwägenswerte Alternative, wenn es ginge.

    Letztendlich bedarf es da nicht allzu viel für: Ein VDD, der die Aufrufe annimmt der einen (z.B. TCP-) Client hat, und einen Server "draussen", der die Anfragen annimmt.


    Zitat von GenerationCBM

    Allerdings gibt's auch bei den Kommandozeilen-Tools (die ich üblicherweise bevorzuge) so ein-zwei Sachen, die ich vermisse bzw. gerne hätte.

    Was denn zum Beispiel?

    Zitat von strik

    Was denn zum Beispiel?

    So aus'm Kopf, in d64copy z.B. sektorweises Einlesen. Es gibt mitunter schwachbrüstige Disketten, bei denen man sich mit mehreren Fehlern pro Track rumschlägt, und wenn man dann mühsam durch Retries usw. den einen oder anderen Fehler ausgemerzt und einen Sektor mal hinreichend sauber gelesen bekommen hat, dann ist die Wahrscheinlichkeit gross dass beim nächsten Lesen des Tracks der alte Fehler gelesen wird und prompt wieder im Image drin ist. Das liesse sich vermeiden wenn man entweder gezielt einzelne Sektoren lesen könnte (bzw. einen Track lesen und dabei alle übrigen Sektoren ignorieren), oder wenn es einen Switch gäbe im Sinne von "beim Lesen in ein schon bestehendes Image hinein: 'gute' Sektoren behalten".


    Die Fehlerbehandlung könnte auch ein wenig robuster sein. Ich weiss, USB ist frickelig mit XU1541-basierten Adaptern, aber wenn einem das ganze dann schon bei einem simplen Diskettenfehler 21 oder 23 oder so komplett abraucht, wäre es schön, wenn nicht sofort der Rest des Kommandozeilenbefehls mit je einem USB-Fehler pro Sektor durch die Konsole liefe und dabei Windows-Treiberkram ins D64 geschrieben würden.

    Zitat von GenerationCBM

    So aus'm Kopf, in d64copy z.B. sektorweises Einlesen. Es gibt mitunter schwachbrüstige Disketten, bei denen man sich mit mehreren Fehlern pro Track rumschlägt, und wenn man dann mühsam durch Retries usw. den einen oder anderen Fehler ausgemerzt und einen Sektor mal hinreichend sauber gelesen bekommen hat, dann ist die Wahrscheinlichkeit gross dass beim nächsten Lesen des Tracks der alte Fehler gelesen wird und prompt wieder im Image drin ist. Das liesse sich vermeiden wenn man entweder gezielt einzelne Sektoren lesen könnte (bzw. einen Track lesen und dabei alle übrigen Sektoren ignorieren), oder wenn es einen Switch gäbe im Sinne von "beim Lesen in ein schon bestehendes Image hinein: 'gute' Sektoren behalten".

    Ich habe dies mal ins Bug-Tracking als Feature Requests eingetragen:
    https://sourceforge.net/p/opencbm/feature-requests/24/
    https://sourceforge.net/p/opencbm/feature-requests/25/

    Zitat von GenerationCBM

    Die Fehlerbehandlung könnte auch ein wenig robuster sein. Ich weiss, USB ist frickelig mit XU1541-basierten Adaptern, aber wenn einem das ganze dann schon bei einem simplen Diskettenfehler 21 oder 23 oder so komplett abraucht, wäre es schön, wenn nicht sofort der Rest des Kommandozeilenbefehls mit je einem USB-Fehler pro Sektor durch die Konsole liefe und dabei Windows-Treiberkram ins D64 geschrieben würden.

    Den Effekt kenne ich noch nicht. Kannst du mir ein Beispiel-D64 liefern, bei dem das passiert ist?


    Ach ja: Nutzt du Windows oder Linux?

    Okay:


    Der Screenshot ist ein typisches/häufiges Fehlerbild bei Lesefehlern, besonders wenn eine Diskette schwer zu lesen ist bzw. mehrere Fehler hat (einzelne Lesefehler werden eher korrekt ohne Absturz mitgenommen). Dieser Leseversuch (ganz normales "d64copy 8 image.d64") hing bei T29S0 fest, immerhin hat er dann noch ein Asterisk draus gemacht, ist dann aber - wie man sieht - abgeraucht. Das scrollt dann abrupt so durch. Überall da wo hier noch ein Fehler angegeben wird (1e/01, 1f/01, 20/01 etc.) steht im Image ein Block mit Müll, d64copy hat dann also weiter ins Image geschrieben, vom Absturz-Track bis Image-Ende. Hat man die Retries erhöht, multipliziert sich diese Ausgabe entsprechend (Warning-Zeile x Retries). Gerne weist der Ur-Fehler auch noch (sync) aus anstatt nur _read() und _write().


    Rein gefühlt würde ich sagen, die Hardware kommt mit gehäuften oder auch bestimmten Lesefehlern nicht klar, schmiert ab und gibt irgendwas unresolved an den USB-Treiber weiter, und irgendwo in der Kette Treiber->d64copy wird das nicht abgefangen. Hier hilft üblicherweise auch nur Floppy aus, USB-Adapter abziehen, wieder reinstecken, Floppy wieder an, denn cbmctrl.exe findet die Hardware dann auch nicht mehr.


    Das angehängt D64 ist ein anderer Leseversuch/andere Diskette als der Screenshot (Originaldiskette von Gunship die ich als "schwierig" kenne, irgendwie muss man die Fehler ja provozieren... :) ). Dieser Versuch ist so erstmal an Track 1 abgeraucht. Dann habe ich pro forma nochmal ab Track 18 gelesen (für's Directory, ist IIRC gleich ab T19 prompt wieder gescheitert), und dann nur noch Track 35, wo er wieder abgeschmiert ist. Man beachte wieder den identischen Müll in jeweils Sektor 1 pro Track quer durch's Image, und bei Track 35 war er dann so freundlich mir tatsächlich mal den gewünschten Treiberkram zu geben (siehe die Trümmer von "C:\Windows\INF" dort).


    Ob und wie das zu fixen ist, keine Ahnung. Sie sind der Doc, Doc.

    Zitat von GenerationCBM

    Ob und wie das zu fixen ist, keine Ahnung. Sie sind der Doc, Doc.

    Ich muss mir das mal in Ruhe anschauen. Wahrscheinlich muss ich erst einmal eine entsprechend präparierte defekte Diskette erzeugen, es könnte also etwas dauern.


    Ich bin zumindest zufrieden, dass nicht Müll wie die Fehlermeldungen im D64 landen. Das war meine erste Befürchtung. ;)


    Zumindest habe ich erst einmal einen Bug-Report erzeugt, siehe https://sourceforge.net/p/opencbm/bugs/62/.