Ankündigung: cbm4win 0.1.0

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

  • strik

    ... doch noch nicht ganz.
    Wenn ich zu "tail -f ... " auch zusätzlich meine Cinergy Software starte, wird das Ganze wieder langsam.
    Falls du es schaffst, anstatt des "Speed" das "tail -f ... " einzubauen, dann wäre es besser als "Schalter" den man bei Bedarf betätigt.

  • Zitat

    Original von rp-64

    Das nenne ich jetzt problemlos.


    Jetzt fehlt bloß noch die Unterstützung des Plus/4 und VC20 unter VICE...! ;) :P

  • Zitat

    Original von rp-64
    Jetzt flutscht es.
    Sleep bringt nichts aber tail -f .... erreicht, dass das DIR in 5 sec angezeigt wird [...]

    und

    Zitat


    ... doch noch nicht ganz.
    Wenn ich zu "tail -f ... " auch zusätzlich meine Cinergy Software starte, wird das Ganze wieder langsam.

    Hm... Interessant. Ich weiß zwar noch nicht ganz, was da genau schief geht, aber es ist wirklich interessant. :wink:

    Dann habe ich jetzt mal eine ganze spezielle Bitte an dich, folgendes auszuführen und mir die sich ergebenden Dateien zuzuschicken:

    1. Erstelle ein Verzeichnis c:\opencbm\timing . Der Pfad muss genau so sein, also bitte nicht auf ein anderes Laufwerk, noch irgendeinen Namen ändern!

    2. Nun mache einen Transfer ("cbmctrl dir 8"), der schnell ist. Falls also tail -f hilft, nutze das. Falls Cinergy hilft, nutze das.

    3. Benenne die Datei c:\opencbm\timing\timing.dat um, z.B. timing_fast.dat

    4. Nun machen einen Transfer ("cbmctrl dir 8"), der langsam ist. Also ohne Cinergy, ohne tail.

    5. Benenne die Datei c:\opencbm\timing\timing.dat um, z.B. timing_slow.dat

    6. ZIPpe timing_fast.dat und timing_slow.dat (die können sehr groß werden, also bitte wirklich nicht mehr als ein "cbmctrl dir 8" ausführen!) und schicke mir die beiden Dateien zu.

    7. Löschen das Verzeichnis c:\opencbm\timing wieder komplett, damit keine weiteren timing.dat-Dateien mehr erzeugt werden.


    Hierdurch erhalte ich Einblick in deinen Rechner in dem Sinne, dass ich weiß, welche Teile von cbm4win wann aufgerufen werden. Vielleicht kann ich damit das Problem etwas besser identifizieren.

    Ich hoffe, dass du mir glaubst, dass ich keine privaten Daten von deinem Rechner auslese. Ansonsten: Der Quelltext liegt ja offen. :wink:

    Gruß,
    Spiro.

  • Hallo Sid,

    Zitat

    Original von Sid
    Jetzt fehlt bloß noch die Unterstützung des Plus/4 und VC20 unter VICE...! ;) :P

    Ach ja, da war ja was. :wink:

    Ich habe es gerade bei mir getestet: WinVICE 1.16 (von der Homepage), opencbm 0.1.0.15 und der offiziellen 0.1.0. Funktioniert einwandfrei und gleichermassen mit x64, x128 (64 und 128 Modus), xvic, xplus4.

    Hat sonst noch jemand ein Problem mit xvic oder xplus4?

    Gruß,
    Spiro.

  • Hi rp-64,

    Zitat

    Original von rp-64
    ... du hast Mail ...

    Da stellt sich mir die Frage: Wohin hast du sie geschickt? Bislang ist hier gar nichts angekommen. :(

    Probiere es sonst mal auf die ml-f64 .at. trikaliotis.net.

    Gruß,
    Spiro.

  • Hallo,

    Zitat

    Original von Sid
    Jetzt fehlt bloß noch die Unterstützung des Plus/4 und VC20 unter VICE...! ;) :P

    @Sid:
    hast du das noch einmal probiert? Tritt das Problem noch auf? Falls ja, müssen wir dem wohl mal gemeinsam (per PM?) auf den Zahn fühlen...

    @All:
    Hat hier sonst noch jemand das gleiche Problem wie rp-64, dass cbm4win extrem langsam ist?

    Ich bräuchte insbesondere Aussagen von Leuten mit SMP-Maschinen oder Maschinen mit HT: Tritt dieser Effekt bei euch auf oder nicht?

    Für alle Hinweise bin ich dankbar. Damit das Forum hier nicht mit tausenden Einzeilern voll wird, bitte per Mail an ml-f64@trikaliotis.net schicken, ich poste dann die Eingänge.

    Danke!

    Gruß,
    Spiro.

  • Hallo,

    ich habe entlich mein XM-Kabel bekommen und auch gleich ausprobiert. Zuerst hatte ich Probleme und die Floppy ist öfters hängen geblieben oder wollte gar nichts machen.
    Das lag anscheinend am Parallelport. ECP und Normal wollten nicht funktionieren aber EPP tut es jetzt super. Dabei ist noch zu sagen das man zu jeden Typwechsel auch jedesmal den cbm4win Treiber deinstallieren und wieder installieren sollte, da sonst der Treiber den "neuen" Parallelport nicht mehr richtig ansprechen kann.

    Das Speedproblem von rp-64 tritt bei mir auch auf. Wenn ich mit cbm4win ein Directory einlese, wenn nix anderes läuft, dann dauert das 15 Sekunden. Wenn ich aber meine TV-Kartensoftware "WinTV" starte dann wird das Directory in 4 Sekunden eingelesen.
    CPU ist XP3000 und OS Win2k

    Eine Frage noch: Wird beim Formatieren und schreiben auf Fehler geprüft?

  • Hallo Terror,

    Zitat

    Original von terror
    ich habe entlich mein XM-Kabel bekommen und auch gleich ausprobiert. Zuerst hatte ich Probleme und die Floppy ist öfters hängen geblieben oder wollte gar nichts machen.
    Das lag anscheinend am Parallelport. ECP und Normal wollten nicht funktionieren aber EPP tut es jetzt super. Dabei ist noch zu sagen das man zu jeden Typwechsel auch jedesmal den cbm4win Treiber deinstallieren und wieder installieren sollte, da sonst der Treiber den "neuen" Parallelport nicht mehr richtig ansprechen kann.

    Hm, beides ist komisch. Ich selbst benutze und entwickle cbm4win hauptsächlich auf einem Rechner mit ECP. Die meisten, die sich bei mir melden, nutzen ebenfalls ECP. Sehr komisch.

    Beim Wechsel des Porttyps mußt du doch bestimmt den Rechner neu starten, oder? Beim Neustart sucht sich cbm4win selb(st)ständig den Port, daher sollte eine Neuinstallation nicht notwendig sein.

    Oder kann dein Rechner den Typ auch im laufenden Betrieb wechseln? In diesem Fall müßte cbm4win tatsächlich neu gestartet werden.

    Zitat


    Das Speedproblem von rp-64 tritt bei mir auch auf. Wenn ich mit cbm4win ein Directory einlese, wenn nix anderes läuft, dann dauert das 15 Sekunden. Wenn ich aber meine TV-Kartensoftware "WinTV" starte dann wird das Directory in 4 Sekunden eingelesen.
    CPU ist XP3000 und OS Win2k

    XP3000 soll AMD XP heissen, richtig? Du hast aber nur einen Prozessor, oder ist dein Rechner ein Mehr-Prozessor-System?

    Falls du willst könnte ich dir eine spezielle Version von cbm4win zur Verfügung stellen mit der wir versuchen könnten, dem Problem auf die Spur zu kommen. Dafür müßtest du allerdings ein paar Versuche machen und ein paar Minuten deiner Zeit investieren.

    Zitat

    Eine Frage noch: Wird beim Formatieren und schreiben auf Fehler geprüft?

    Nein, beim Formatieren mit cbmformat und dem Kopieren mit d64copy oder cbmcopy wird nicht auf Fehler überprüft. cbmformat kann ich zur Zeit eh nicht empfehlen: Falls du ein schnelles Diskettenlaufwerk hast, d.h., die Diskette dreht sich schneller als etwa 305 Umdrehungen/Sekunde, dann ist die Diskette nach dem Formatieren mit cbmformat nicht korrekt formatiert. Siehe auch Bitte melde dich an, um diesen Link zu sehen.. Daran arbeite ich zur Zeit. Ein Formatieren mit N0:NAME,ID behebt das Problem aber. Bei der Gelegenheit will ich auch noch einen Test der Floppy ergänzen, sofern der Platz in der Floppy dafür ausreicht (es ist schon verdammt eng).

    Für das Beschreiben ist ein Verify auf meiner TODO-Liste, aber da ist auch noch vieles anderes. :wink:

    Gruß,
    - Spiro.

  • Welche Port Adressen verwendet CBM4WIN wirklich?

    Bekanntlich gibt es für die LPT-Ports die Standard Adressen 3BC, 278 und 378.
    Welche nun für welchen Port gilt, ist aber eine reine Einstellungssache am PC, bzw. lässt sich konfigurieren.

    Ich habe gerade bei XCTEST festgestellt, dass die Zuordnung wie folgt ist:
    LPT1 : 3BC
    LPT2 : 378
    LPT3 : 278

    Und deswegen funktioniert es bei mir auch nicht. Ich habe nur einen LPT Port, und auf 3BC ist der nur eingeschränkt funktionsfähig, daher habe ich ihn auf 378 eingestellt.

    Nun stellt sich die Frage, ob CBM4WIN sich die richtige Adresse holt, oder von einer festen Zuordnung ausgeht.

    Computer:C64, VC20 Monitor:1702, 1084S Floppy:1541, 1541-II Speicher/Datenübertragung:MMC Replay, 1541U-II, Chameleon, C64TPC, sd2iec, EasyFlash, NeoRAM, XA1541, XU1541 Sprachausgabe:Magic Voice, Voice Messenger, HearSay 1000, Adman Speech Maker, VoiceBox AlienGroup, Covox Voice Master Sonst:Robotarm SVI-2000, Kemtec AMS 64, HardSID4u se, SammichSID, SIDstation, SFX Sound Expander, SFX Sound Sampler

  • Zitat

    Nein, beim Formatieren mit cbmformat und dem Kopieren mit d64copy oder cbmcopy wird nicht auf Fehler überprüft.
    <schnipp>
    Bei der Gelegenheit will ich auch noch einen Test der Floppy ergänzen, sofern der Platz in der Floppy dafür ausreicht (es ist schon verdammt eng).

    Mach doch eine zweistufige Lösung:
    1. Formatierroutine in die Floppy laden.
    2. Formatierroutine knallt den Kopf gegen den Anschlag
    3. Formatierroutine formatiert Spuren 1-35
    4. CBM4WIN stellt fest, dass die Formatierung abgeschlossen ist
    Bis hierhin sollte es etwa 9 oder 10 Sekunden gedauert haben.
    5. An Stelle der Formatierroutine wird jetz die Verifyroutine in die Floppy geladen.
    4. Verifyroutine testet Spuren 35-1 (ja, rückwärts...um unnötiges Steppen zu vermeiden)
    5. Verifyroutine stellt Fehler auf Spur 34 fest :baby:
    6. Formatierung inkl. Frustration des Users in 11 Sekunden beendet. 8)

    Wenn die Diskette noch funktioniert, dauert's natürlich ein paar Sekunden länger.

    - Klaus

  • Stefan67:

    Zitat

    Original von Stefan67
    Welche Port Adressen verwendet CBM4WIN wirklich?

    cbm4win nutzt die Port-Adressen, die Windows für den Parallelport erkannt hat. Es fragt beim Windows-Treiber für den Parallel-Port (parport.sys) nach, welche Adressen es benutzen soll. Es sperrt auch den Port für die Dauer des Zugriffs, indem parport.sys mitgeteilt wird, dass der Port benutzt wird. Mit der Erkennung sollte es demnach keine Probleme geben.


    @Klaws:

    Zitat

    Original von Klaws
    Mach doch eine zweistufige Lösung:

    Ja, das wäre die Lösung, falls der Platz nicht reicht. So ist das auch geplant. :wink:

    Zitat

    3. Formatierroutine formatiert Spuren 1-35
    4. CBM4WIN stellt fest, dass die Formatierung abgeschlossen ist
    Bis hierhin sollte es etwa 9 oder 10 Sekunden gedauert haben.

    Nun ja, da alleine das Zurückfahren des Lesekopfes von Spur 18 auf 1 je nach Laufwerk 3 bis 5 Sekunden dauert, dürften die 8 bis 10 Sekunden kaum machbar sein.


    Gruß,
    - Spiro.

  • Zitat

    Original von strik

    Nun ja, da alleine das Zurückfahren des Lesekopfes von Spur 18 auf 1 je nach Laufwerk 3 bis 5 Sekunden dauert, dürften die 8 bis 10 Sekunden kaum machbar sein.

    Naja, es gab doch damals das "9-Sekunden-Format"-Programm (ohne Verify). Ich weiss noch, dass das Stepping beschleunigt war (auch das Kopfknallen ging zügiger). Wie Spur 18 gehandhabt wurde, weiss ich nicht mehr; es kann sein, dass die in einem Rutsch direkt mit den richtigen Daten beschrieben wurde.

    Ich schätze mal grob, dass ein komplettes Formatieren mit Verify in 30 Sekunden oder etwas weniger zu machen sein müsste (das Lesen dauert ja etwas länger als das Schreiben, weil man ja auf einen Sync warten muss...). Ob das "9-Sekunden-Format" wirklich nur 9 Sekunden gebraucht hat, hat damals ja auch keienr nachgemessen. 9 Sekunden sind auf jeden Fall ziemlich nah am theoretischen Maximum...war auf jeden Fall viel schneller als pR1,"n:dingens,AB" (man beachte die kreative Anwendung von Sonderzeichen als ID...auf sowas war man damals stolz...ROFL).

    - Klaus

  • Zitat

    Original von Klaws
    Ich schätze mal grob, dass ein komplettes Formatieren mit Verify in 30 Sekunden oder etwas weniger zu machen sein müsste (das Lesen dauert ja etwas länger als das Schreiben, weil man ja auf einen Sync warten muss...).

    Nun ja, da bin ich ja zur Zeit (etwa 16 Sekunden ohne Verify auf einer 1571, dafür aber mit einer gleichmäßigen Ausrichtung der Sektoren - ich arbeite nämlich gerade am Format) gar nicht mal so schlecht, oder? :wink:

    Eine Extra-Runde für das Lesen fällt da wahrscheinlich noch mal mit 7 Sekunden ins Gewicht.


    Wie soll aber 9-Sekunden-Format *mit* Verify das geschafft haben? Die Floppy schafft 5 Umdrehungen/Sekunde. Bei 35 Spuren macht alleine das schon (*ohne* Verify) 7 Sekunden aus; mit Verify liegt das theoretische Minimum schon bei 14 Sekunden.

    Gruß,
    - Spiro.

  • Zitat

    Original von strik
    Wie soll aber 9-Sekunden-Format *mit* Verify das geschafft haben?

    Äh, habe ich vergessaen, das zu sagen? Das "9-Sekunden-Format" arbeitet natürlich OHNE Verify. Und wie die Sektoren danach ausgerichetet sind, weiss ich auch nicht. Klar dürfte sein, dass es pro Track "eine" Umdrehung braucht (wahrscheinlich etwas mehr, will ich hoffen, damit es überlappt und kein Müll zwischen Trackende und Trackanfang übrigbleiben kann).

    Habe grade mal gesucht, aber in meinem Bestand scheint dieses "9-Sekunden-Format" nicht mehr vorhanden zu sein ;(

    Die Existenz solch eines Produkts wird aber hier bestätigt: Bitte melde dich an, um diesen Link zu sehen..

    Hatte nicht "Duplicator III" auch eine Fastformat-Routine drin? Wie schnell war die denn? (Habe grad kein C64 zur Hand)

    - Klaus

  • Zitat

    Original von Klaws
    Äh, habe ich vergessaen, das zu sagen? Das "9-Sekunden-Format" arbeitet natürlich OHNE Verify.

    Äh... Mea culpa. Ich habe das doch glatt falsch gelesen. Ich mußte gerade noch einmal neu nachschauen weil ich fest davon überzeugt war, dass du "mit" Verify gesagt hättest.

    Zitat

    Und wie die Sektoren danach ausgerichetet sind, weiss ich auch nicht. Klar dürfte sein, dass es pro Track "eine" Umdrehung braucht (wahrscheinlich etwas mehr, will ich hoffen, damit es überlappt und kein Müll zwischen Trackende und Trackanfang übrigbleiben kann).

    Nun ja, das kann man mit ein paar wenigen Bytes am Anfang erreichen (ich nutze zur Zeit 256 Byte vorneweg). Das ist also gar nicht so kritisch.


    Zitat

    Hatte nicht "Duplicator III" auch eine Fastformat-Routine drin? Wie schnell war die denn? (Habe grad kein C64 zur Hand)

    Keine Ahnung, ich kenne weder das eine, noch das andere Produkt.

    Gruß,
    - Spiro.

  • Zitat

    Original von strik
    Keine Ahnung, ich kenne weder das eine, noch das andere Produkt.

    So, endlich, ich habe das "9 SECOND FORMAT" im Internet gefunden. Na und wo?

    Bitte melde dich an, um diesen Link zu sehen.

    Dummerweise ist der Downladlink tot. Also mal Hucky fragen!

    Das Tool ist auch nicht für den C64. Aber für's Reveerse Enginieering könnte es ja schon mal reichen....

    Es gibt auch für den Amiga eine 9 Sek. Formatierroutine für die 1541.

    - Klaus

  • Zitat

    Original von Klaws
    So, endlich, ich habe das "9 SECOND FORMAT" im Internet gefunden. Na und wo?

    Bitte melde dich an, um diesen Link zu sehen.

    Dank dir. Da werde ich mal hineinschauen, falls Hucky das noch irgendwo anders hat.

    Gruß,
    - Spiro.

  • Tach !

    Birger hats gerichtet...

    mfG Hucky

    Bitte melde dich an, um diesen Link zu sehen.

    Arcade: Twinliner, Fashion Vision,
    "Cosmic Guerilla" cocktail table
    Pins: Scared Stiff + Getaway
    C64, C65, C66, Gammel+Mist...