Evtl. ist die "Unterschiedliche Phasenlage" auch eine Ursache für
Ich denke, das ist das Problem mit der Invertierung des Signals, das Bitte melde dich an, um diesen Link zu sehen. schon angesprochen hatte.
Evtl. ist die "Unterschiedliche Phasenlage" auch eine Ursache für
Ich denke, das ist das Problem mit der Invertierung des Signals, das Bitte melde dich an, um diesen Link zu sehen. schon angesprochen hatte.
Der Adapter zum kopieren mit 2 Datasetten am C64 schimpft sich Copy2000.
Mehr Infos habe ich aber bisher nicht gefunden.
Luigi di Fraia hat hier einiges an Hardware gebaut:
Bitte melde dich an, um diesen Link zu sehen.
Man könnte das symmetrisch machen und beiden Halbwellen den gleichen Platz gönnen: 1100 für Kurz, 111000 für Lang.
Oder man macht es unsymmetrisch und macht die obere Halbwelle immer gleich breit: 1100 für Kurz, 110000 für Lang. Die könnte auch invertiert gelesen werden.
Ich weiß nicht, wie Commodore es macht, und wie es TurboTapes machen habe ich inzwischen vergessen.
Jetzt verstehe ich, was du meinst. Also Commodore macht das auf jeden Fall symmetrisch und die FastLoader auch (soweit ich weiss).
Und ich weiß auch nicht, ob so eine unsymmetrische Welle noch komische Effekte im Analogen hat.
Das können uns vielleicht die Audioexperten sagen. ![]()
Die Frequenz für die kürzere Halbwelle würde sich erhöhen und ich denke mal, das stellt erhöhte Anforderungen an die Analogtechnik. Was man ja eigentlich nicht will.
Das ist aber jetzt meine persönliche Theorie dazu.
Ergänzung: Lugia de Fraia verwendet in seinen DC2N-Modulen ein Backup-Format, dass anscheinend bei Halbwellen speichert (ist in der Beschreibung erwähnt).
Anscheinend gibt es doch Formate, die unsymmetrisch aufzeichnen.
Bitte melde dich an, um diesen Link zu sehen.
Ergänzung2: Nö, stimmt nicht, Er speichert auch nur die Periodenlänge (wie TAP auch). Aber bei der Auswertung des Signals schaut er sich wohl beide Halbwellen an, vermutlich um die Erkennung zu verbessern.
Aber er schrieb doch gerade von Turboloadern.
Dann habe ich den Zusammenhang nicht mitbekommen.
Aber auch Turbo-Lader nutzen immer eine ganze Periode. Sonst könnte man die nicht in TAP-Files umwandeln, denn im TAP-File gibt es auch nur einen Wert für eine Periode und nicht getrennt für jede Halbwellen.
Ich denke, der Lader hat für beide Halbwellen die Längen variiert.
Wäre interessant zu sehen, wie ein Rechtecksignal mit gleicher Länge der oberen Halbwellen analog aussieht.
Diese beiden Sätze verstehe ich nicht. Was meinst du mit "Längen" und "Rechtecksignal mit gleicher Länge der oberen Halbwellen"?
Das Commodore-Aufzeichnungsformat ist ja ausführlich dokumentiert. Die Länge eines Pulses wird immer durch die Länge einer kompletten Periode bestmmt (also eine positive Halbwelle + eine negative Halbwelle). Man misst also einfach die Zeiten zwischen den positiven Nulldurchgängen.
Ich habe mal ein wenig weiter experimentiert. Das Wav ist aufjedenfall NTSC, damit (und normalize off) erstellt er mit zumindest ein TAp bei dem der Novaload geladen wird. Da gehts aber jetzt nicht weiter.....
Ich habe auch noch mal ein paar Tests gemacht, weil mir das keine Ruhe gelassen hat, dass UberCassette das File zumindest teilweise gelesen bekommt und meine Routinen überhaupt nicht. ![]()
Das WAV-File ist tatsächlich invertiert. Wenn ich in meinem WAV-Reader die Logik umdrehe und auf negative Flanken reagiere statt auf positive, dann komme ich zum gleichen Ergebnis wie UberCassette.
UberCassette analysiert das komplette WAV-File und wertet den Sync-Header aus, bevor es das TAP-File erzeugt. Dabei wird wohl auch die Invertierung automatisch erkannt.
Fragt mich nicht
Jedenfalls haben aus den ersten 4 Tools dieser Liste bereits 2 eine Option, das Signal wieder zu invertieren, und das Tool auf der Hauptseite ebenfalls. In den Beschreibungen wurde das Invertieren aber auf komische Soundkarten geschoben oder gar nicht erklärt.
Ach ja, ich erinnere mich. Es soll Soundkarten geben, die bei der Aufnahme das Signal invertieren.
Das sieht im Moment noch nicht so gut aus. Nach den Sync-Impulsen ist die Aufnahme schon mal um den Faktor 1,7 zu schnell.
Aber selbst wenn ich das anpasse, wird nichts vernünftiges gelesen.
Also das war kompletter Quatsch, was ich da geschrieben habe. Das Problem ist, dass mein WAV-TAP-Konverter noch ziemlich buggy ist.
Ich habe dein WAV-File jetzt mal mit UberCassette_V004 nach TAP konvertiert und dann werden zumindest schon mal die Header gelesen.
WAVPRG 4.2.1 liest übrigens auch nichts. UberCassette scheint da etwas ausgefeilter zu sein.
Dem Programm liegen die C-Sourcen bei. Mal schauen wie das Programm das hinbekommt.
Mein Softwarefilter nutzt in diesem Fall wenig. Das Ergebnis ist das Gleiche.
Also so sieht das TAP-File jetzt aus. Es werden die beiden Header und ein 176 Byte großes Programms mit Anfangsadresse $CC49 gefunden. Das war's dann aber auch schon.
Bitte melde dich an, um diesen Anhang zu sehen.
Mir wurde zugeflüstert, dass es an einem invertierten Signal liegen dürfte.
Verstehe ich auch gerade nicht, wer da das Signal invertiert haben sollte.
Bitte melde dich an, um diesen Link zu sehen.: Ok, danke für die Infos.
Bias ist in der Magnetbandtechnik generell, also herstellerunabhängig der Englische Terminus für die Vormagnetisierung.
Ok, das ist dann aber nichts, was als Frequenz auf dem Band landet oder Probleme beim Überspielen von Programmkassetten mit dem Kassettendeck bereiten sollte.
Also kann man das doch in diesem Zusammenhang vernachlässigen?
Ist das der Vorspann der Datei? Ich sehe überall die gleiche Wellenlänge, bei echten Bits sollten irgendwie verschiedene zu sehen sein.
Ein Oszi am Lesekopf der Datasette sollte aber bei einer Musikkassette "irgendwas" zeigen, was nach Bias aussieht.
Richtig, das ist der Sync-Header. Unter Bias verstehe ich einfach einen Gleichspannungs-Offset. Was einige Hersteller unter dem Begriff verstehen, weiß ich nicht.
Mit dem Oszi am Lesekopf muss man froh sein, wenn man überhaupt was sieht. Das geht überhaupt nur mit Tastkopf 1:10 und Signal ist winzig. Und da die Datasette, wie du schon sagtest, sowas nicht nutzt, wird man es sowieso nicht sehen.
Bitteschön, "echte" Bits.
Bitte melde dich an, um diesen Anhang zu sehen.
Naja, ich schaue mal. Die Intention meines Programms war ja, genau solchen kaputten WAV-Files zu analysieren und zu lesen. ![]()
Ich schicke dir erstmal eins (sind im ganzen vier)....
Das sieht im Moment noch nicht so gut aus. Nach den Sync-Impulsen ist die Aufnahme schon mal um den Faktor 1,7 zu schnell.
Aber selbst wenn ich das anpasse, wird nichts vernünftiges gelesen.
Die Amplitutenschwankungen, von denen ich oben geschrieben hatte, dürfen eigentlich nichts ausmachen, weil ja nur die Nulldurchgänge ausgewertet werden. Das war ein Denkfehler.
Die Nulldurchgänge ändern sich nur bei Bias- und Gleichlaufschwankungen.
Wie sind denn diese WAV-Dateien aufgenommen worden? Bzw. mit welchem Gerät?
Den Screenshots nach wirkt das Tool wie ein Hochpassfilter mit sehr niedriger Grenzfrequenz, das könnte man ja mal in einem Audioeditor ausprobieren. Als Frequenz würde ich mal was im Bereich von 10 bis 100Hz raten, das entfernt solche Offsets wie in den Screenshots, sollte aber das eigentliche Signal in Ruhe lassen.
Ich habe gerade mal in die WAV Datei von ADAC reingeschaut. Da gibt es zusätzlich auch noch Amplitudenschwankungen.
Ich schaue mal, ob ich die mit CoolEdit wegbekommen. Ansonsten versuche ich das auch noch im mein Tool einzubauen.
Ich melde mal leise Interesse an dem Tool an. Ich habe hier WAV-Dateien, die ich ums verrecken nicht zu TAP gewandelt bekomme. Auch mit echter Datasette lassen die sich nicht mehr lesen (keine Ahnung was da los ist)
Das ist im Moment nicht standalone (in einem anderen Programm mit eingebaut) und die WAV-Parameter sind hardcoded - war ja nur ein Experiment.
Ich müsste da noch mal einiges umbauen, damit das universell einsetzbar ist.
Du könntest mir aber die WAV-Files schicken und wenn ich Zeit habe, würde ich mir die mal anschauen.
Tape-zu-Tape habe ich früher mal gemacht. Das Ergebnis hing sehr stark von der Qualität der Kassettenrekorder ab. Mit manchen ging es gut, mit manchen gar nicht.
Damals hatte ich aber noch keine Möglichkeit, mir das Signal anzuschauen.
Für die Reparaturen habe ich kein Testprogramm geschrieben sondern einfach ein längeres Programm vom PET (der PET ist in Bezug auf das Kassetteninterface absolut identisch zum C64) auf Datasette gespeichert habe. Und dann habe ich das Signal durch die Analogstufen der Datasette bis zum Tonkopf verfolgt. Für die andere Richtung habe ich eine Testkassette mit einem längeren Programm.
Was ich in letzter Zeit häufiger gemacht habe, ist aus TAP-Files WAV-Files zu erzeugen und die über den Soundausgang des PCs auf einem Kassettendeck (Yamaha - etwas bessere Qualität) aufzunehmen. Die Kassetten lassen sich problemlos am PET und C64 lesen.
Ich habe auch mal testweise ein Programm geschrieben, das von Kassette auf den PC überspielte Programme (im WAV-Format) nachbearbeitet.
Im Anhang zwei Ausschnitte aus einer WAV-Datei die von einer Programmkassette erstellt wurde (mit einem Kassettendeck per Audio auf den PC überspielt). Ich Kassette ließ sich am C64 nicht mehr lesen.
Der oberer Kanal zeigt das Originalsignal und der untere das, was mein Programm daraus macht. Nach dieser Bearbeitung konnte ich die WAV-Datei wieder in eine TAP/PRG-Datei wandeln.
Das ist ja vermutlich eine Bias-Korrektur? ![]()
Bitte melde dich an, um diesen Anhang zu sehen.
Bitte melde dich an, um diesen Anhang zu sehen.
EDIT: Noch eine Ergänzung. Das hier ist so eine Adapter, der die analoge Aufbereitung der Datasette übernimmt.
Ich denke, jemandem mit Oszi dürfte es nicht zu schwer fallen, gelesene Signale vom Schreib-Lesekopf abzugreifen und darzustellen. Damit sollten die Unterschiede in den Signalen doch schnell genauer zu benennen sein?
In dem von die angehängten Schaltplan sind doch die Signal eingezeichnet. So sehen die aus, wenn man sich die mit dem Oszi anschaut.
Weiß ich zufällig, weil ich in den letzten Monaten einige Datasetten repariert habe.
Habe gerade mal das Service Manual fuer die 1530 angeschaut. Die Datasette schreibt tatsaechlich PWM-moduliertes Rechteck-Gedoehns.
Das eroeffnet natuerlich eine weitere Fehler-Moeglichkeit: Die Tapedecks sind ja fuer Audio ausgelegt. Es koennte sein, dass die relativ steilen Flanken eines Rechtecksignals im Audiopfad des Tapedecks so verschliffen werden, dass sich effektiv die Pulsbreite aendern koennte und dadurch moeglicherweise Bits falsch interpretiert/uebersehen werden. Ich weiss da jetzt aber auch nicht so genau, welche Toleranzen in der Pulsbreite bei welchen (Turbo)Ladern vertretbar sind, und ob das demzufolge ueberhaupt ein Problem darstellen koennte...
Das ist nicht korrekt. Die Datasette bekommt zwar vom C64 ein Rechtecksignal. In der Datasette wird das Signal aber analog aufbereitet, bevor es geschrieben wird. Wenn man sich das mit dem Oszi anschaut, ähnelt das schon eher einem Sinussignal.
Aus diesem Grund kann auch nicht einfach einen x-beliebigen Kassettenrekorder anschließen.
Außerdem habe einige Leute schon erfolgreich Programme im MP3 Format vom Handy über einen entsprechenden Analogadapter auf dem C64 geladen.Wenn das Signal MP3 überlebt, dann überlebt das auch das Kopieren von Kassette auf Kassette.
Zu dem Thema gibt mehrere Threads hier im Forum (müsste ich jetzt suchen).