...warum probiert Ihr eigentlich nicht mal das "CBMTAPEPI"
Klingt auch interessant. Aber jetzt will ich einerseits selbst was machen an der stelle. Also nicht wegen dem Ziel sondern wegen dem weg. Und für die messe langts ja wenn die datasette funktioniert. Wobei wir da wieder beim ursprungsthema sind. Wir sollten 1-2 Hände voll spielchen/Demos dabei haben für den Fall dass die Hardware die zwei Tage durchhält.
Stimmt, das hatte ich auch nicht mehr präsent. Bei Programmen gibt es gar keine Einzelblöcke auf Band. Nach dem Header wird das ganze Programm am Stück geschrieben. Die Einzelblöcke gibt es nur beim Schreiben von Daten (mit OPEN und PRINT#).
Bei einem Load-Error ist das Programm im Speicher bereits überschrieben. Das geht ja nicht anders, denn wie du schon sagtest, wo sollten die bereits gelesenen Daten sonst zwischengespeichert werden.
Ich vermute mal, nur wenn der Load-Error bereits beim Lesen des Headers auftritt, bleibt das vorherige Programm erhalten. Denn der Header wird im Kassettenpuffer zwischengespeichert. Zu dem Zeitpunkt wurde noch nichts überschrieben.
Das sind jetzt aber auch nur Vermutungen. Die Laderoutinen im PET hatte ich mir ja noch nie angeschaut.
Ich vermute mal, nur wenn der Load-Error bereits beim Lesen des Headers auftritt, bleibt das vorherige Programm erhalten.
Ich denke auch so. Und nachdem allein die Einlaufrille ja schon ewig lang ist (10s) kommts einem subjektiv vor dass ganz sicher schon das halbe RAM überschrieben sein muss auch wenn erst der Header läuft.
Mei, jetzt paar Tage Urlaub.... das wärs....
OK, TAP verstanden. Hier ist eine schöne Beschreibung.
http://unusedino.de/ec64/technical/formats/tap.html
Es gibt einen Fileheader in dem v.a. steht ob es ein Typ/Version 0 oder 1 file ist und bei $14 gehen dann die Daten los.
Und die "Daten" sind nun zeitliche Längenangaben und zwar nicht in Zeit [s] sondern in Vielfachen des Prozessortakts. D.h. das TAP-Format normiert wahrscheinlich sogar die MHz-Unterschiede zwischen den verschiedenen Rechnern weg, es sei denn die ganzen Rechner kompensieren die Timingunterschiede bereits durch unterschiedliche Zeitkonstanten in ihrer Firmware.
Und dann ist die Idee, dass man als kleinste Einheit einen Rechteckpuls hat mit 1:1 duty cycle, und zwar die ersten 50% der Periodendauer high, dann zweite Hälfte low. Und grob gesprochen wird dann jedes Byte im TAP File beim Ausspielen zu einem unterschiedlich langen H/L-Rechteckpuls mit aber immer exakt 1:1 Tastverhältnis.
Und weil quasi jedes Byte eines PRG zu 10 solchen H/L-Pulsen übersetzt wird (Bytemarker + 8 Datenbits + Parität), ergo 10 Byte, sind TAP-Files mehr als 10x so groß als PRG. Es kommt ja dann noch 10s Einlaufrille hinzu und paar Pausen und der Header. Eigentlich für nicht-kopiergeschütztes Zeug kompletter nonsens. Ist halt quasi ein RAW-Format, deutlich datenreduziert gegenüber einem WAV, aber unnütz detailliert gegenüber einem PRG. Im Prinzip gehen da sogar die Gleichlaufschwankungen des Laufwerks mit ein. Und für Archivzwecke ist halt auch unschön, dass es quasi unendlich viele Varianten von eigentlich gleichen TAP-Files gibt. Man kann auch sagen, dass die ersten ~40 KiB jedes TAP-Files Einlaufrille+Header+Pause sind mit dem Informationsgehalt des Programmnamens.
Aber natürlich "interessant".
Und ich denke, wenn man ein TAP-File nach WAV wandelt um es dann auf ein echtes Band zu spielen um das dann auf einer echten Maschine wieder einzulesen würde es imho bei nicht kopiergeschütztem Zeug Sinn machen, dass das verwendete Tool das TAP erstmal zu cleant. Dahingehend, dass die ganzen quasi "analogen" Periodendauern mit ihrem Zeitrauschen/Jitter durch Quantisierung auf die 3 Grundpulse Short/Long/Mark bzw. Short/Medium/Long runtergebrochen werden. Dadurch wäre dann das WAV bzw. das Band besser als das TAP.
Jetzt haben wir uns nochmal so ein TAP-File statistisch angesehen, sprich ein Histogramm über die 255 sinnvollen Periodendauern plus die Extralangen (Klasse 256) gemacht. In dieser Darstellung müsste man bei einem real eingespielten TAP schön die Gleichlaufschwankungen sehen. Perfekter Gleichlauf wären 3 diskrete=einzelne Balken, alles andere breitere Gaußartige Gebilde.
Jaja und warum ist der rechteste Balken so kurz? Weil wir die drei Perioden Short/Medium/Long haben (S/M/L). Und die Datenbits und das Paritybit werden aus S+M ("SM" oder "MS") gebildet, das sind also die Häufigsten. Das "L" (der Längste) wird nur für den byte-mark verwendet "LM".
Auch ein interessantes Thema: Ein Kollege meinte bzw. fragte, dass er früher versucht hätte mit einem HiFi-Doppelkassettendeck Datasetten zu kopieren und zwar ohne Erfolg. Habe gegoogelt und diesen Forumstreffer gelandet.
https://www.forum64.de/index.p…datasette-games-kopieren/
Einer sagt so, einer so sag' ich mal. Ich würde annehmen, dass man sich vielleicht durchaus einen Kopierschutz einfallen lassen könnte, aber normalerweise würde ich nicht erwarten, dass es da Probleme geben sollte. Insbesondere kann ich mir kaum vorstellen, warum ein Type II Band Probleme machen sollte oder High-Speed Dubbing. Aussteuerung/AGC kann ich mir gut als Problemquelle vorstellen und wenn man sein Dolby oder HX Pro nicht abgeschaltet hat aber das sollte bei einem Doppeltapedeck gar nicht ins Gewicht fallen weil das nämlich fast immer eine 1:1 "raw"-Kopie zieht (glaube ich) also ohne gain/kompressorschaltungen im Signalweg. Ansonsten halt wieder 2x Azimuth und 2x Gleichlaufschwankungen.
Jetzt wäre mal interessant sich so ein Histogramm von einem TAP mit einem Tape-Schnelllader wie Turbo-Tape anzusehen. Da macht das TAP-Format dann auch auf einmal viel mehr Sinn. Weil es gab ja damals scheinbar unzählbar viele Schnelllader und solche "Aufzeichnungsformate" bekommt man ja gar nicht so leicht unter einen Hut. Und weiss man wie damals Kopierschütze funktioniert haben?
Ui, 64 Seiten zu "Datasette" im Data Becker "Das Anti-Cracker Buch", cool!
Jetzt haben wir uns nochmal so ein TAP-File statistisch angesehen, sprich ein Histogramm über die 255 sinnvollen Periodendauern plus die Extralangen (Klasse 256) gemacht. In dieser Darstellung müsste man bei einem real eingespielten TAP schön die Gleichlaufschwankungen sehen. Perfekter Gleichlauf wären 3 diskrete=einzelne Balken, alles andere breitere Gaußartige Gebilde.
Was für ein TAP-File hast du verwendet und woher weisst du, wie es erzeugt wurde?
Jetzt wäre mal interessant sich so ein Histogramm von einem TAP mit einem Tape-Schnelllader wie Turbo-Tape anzusehen. Da macht das TAP-Format dann auch auf einmal viel mehr Sinn. Weil es gab ja damals scheinbar unzählbar viele Schnelllader und solche "Aufzeichnungsformate" bekommt man ja gar nicht so leicht unter einen Hut. Und weiss man wie damals Kopierschütze funktioniert haben?
Kopierschutz oder Schnelllader? Das sind zwei unterschiedliche Themen.
Mit den Schnellladern bist du jetzt aber beim C64. Beim PET spielten die keine Rolle.
Hier noch mal der Link auf die ehemale c64tapes.org:
loaders:rom_loader - c64tapes.org
Am Ende der Seite die Liste der C64-Schnelllader. Habe ich zur Kenntnis genommen und beschlossen, dass ich mich damit nicht beschäftigen werden. 
Ja das ist ja auch mal eine geile Idee auf die ich vermutlich selbst nie gekommen wäre. Man modifiziere seine Datasette dergestalt, dass man seine Handy-Klinke per 100 nF Kondensator auf irgendeinen IC-Pin im Play-Signalpfad einkoppelt. Leider sehe ich keinen Link in das lemon64-Forum wo er die Beschreibung her hat. Aber bei 1:30 deutet er drauf wo der Kondensator hin soll. Je nach PCB rev. sei der Einspeisepunkt entsprechend anzupassen.
Was für ein TAP-File hast du verwendet und woher weisst du, wie es erzeugt wurde?
Das Diagramm ist gemacht aus dog-star-adventure.tap was in einer zip-Sammlung (PET-Games-tap-and-wav.zip) von WAV/TAP Pärchen stammt. Witzigerweise war das das einzige File aus dieser Sammlung wo ich das Gefühl habe dass es "echt" - also nicht aus einem PRG generiert sein KÖNNTE. Alle anderen schauen aus wie dem Diagramm in diesem Post, sprich es sind immer 2 Klassen oder halt 2 Werte Lücke. Könnte auf einen Software-Generator/-Konverter hindeuten oder sonst eine Bearbeitung.
https://retrocomputerverzamela…odore-pet-tape-wav-files/
Kopierschutz oder Schnelllader? Das sind zwei unterschiedliche Themen.
Mit den Schnellladern bist du jetzt aber beim C64. Beim PET spielten die keine Rolle.
Denke ich mir auch. Zwecks Schnelllader waren die RAMs ja noch erträglich klein, ergo die Ladezeiten halbwegs erträglich. Und das mit dem Kopierschutz kam dann wohl auch erst in der Zeit wo die Software am Pausenhof kursiert ist sprich auch eher mit dem 64er.
Und jetzt verstehe ich auch was der Ander hier für Striche zeichnet ab 1:16.
https://youtu.be/d9RL6TFQHBw?t=75
Das ist genau mein Histogramm, aber live gezeichnet und halt zusätzlich über die Zeit gestreckt. Das bekomme ich auch noch hin, schön groß und mit Falschfarben.
Bzw. eben auch auf seiner Webseite hier die schon mal verlinkt war aber ich hab sie nur grob überflogen und das mit den Strichen ist hängen blieben. Wusste aber noch nicht exakt was das sein soll.
https://www.luigidifraia.com/sales/
Das ist jedenfalls alles ein gewisser "Luigi Di Fraia", auch die Hardcore-Infos im Link in Post#252.
Ins't it beautiful? Und jetzt gehen wir in die Haia!
Achtung mit der x-Achse, die ist quasi "auto-scale" damit alle Diagramme gleich groß sind. Aber vom Prinzip her beginnt das Band links und pro Pixel-Histogrammspalte sind 2000 Perdioden erfasst.
Sehr auffällig ist dieses eine C16-TAP, ich denke das rührt von diesen zwei clk-Frequenzen die der C16 hat, vermutlich fährt die Tape-Routine mit diesen 1.76 MHz. Kenne die Maschine nicht wirklich.
Schön ist auch dass man die "Pausen" (v.a. den Leader) schön erkennt wo ja nur Shorts kommen.
Ich verstehe die Diagramme noch nicht. Also die Y-Achse sind vermutlich Werte aus dem TAP-File. Und was bedeuten die Farben?
die farbe ist die Häufigkeit mit der der eine periodenlänge 1...256 (256 =extraglang) innerhalb eines betrachtungsintervalls aufgetreten ist. Simpel: dunkelblau ist praktisch die grundfarbe, das könnte auch schwarz oder weiss sein. Tote hose. Alles andere heisst dass pulse dieser periodendauer enthalten sind. Die siehst etwa türkis in den bereichen wo sich die 2000 werte auf die drei typischen periodendauern S/M//L verteilen. Beim leader hast du nur S, d.h. Da hast du eine 100% konzentration und dort sieht man ~orange.
das c16 ist übrigens kein langes Spiel sondern nur ein kurzer basic 10-zeiler den ich auf meiner festplatte gefunden habe. Deswegen ist der datenbereich rechts etwa nur so groß wie der header in der linken Hälfte.
aber irgendwas stimmt noch nicht. In der richtung dass es auf dem kopf steht. Der leader besteht ja aus S, also kurze perioden (also kleine werte). Und der c16 müsste nach meiner theorie längere perioden haben als die anderen maschinen aber die achsbeschriftung sagt das gegenteil.
ach ja: data becker sagt (buchdruck 1987), dass es praktisch keinen datasettenkopierschutz gibt der verhindern könnte dass man ein band einfach hifimäßig kopiert. Das einzige ist halt dass jede kopiengeneration analog bischen schlechter ist, sodass man kein pausenhof-schneeballsystem aufziehen kann.
Korrektur! Im Prinzip ist nur die Beschriftung der y-Achse geflippt.
und magst Du nochmal kurz für Uneingeeihte sagen, was die andere Achse ist ?
Also so, daß man verstehen kann, was so eine Datasette eigentlich speichert, ohne jetzt die ganzen Texte durchlesen zu müssen.
Irgendwie gibt es da drei Werte drauf mit bißchen Verteilung ums Zentrum, aber Frequenzen sind das ja vmtl nicht, oder doch ?
PS: C16 PRGs findet man auf plus4world.org
PS2: https://archive.org/details/da…ker-buch/page/n5/mode/2up Anti-Cracker Buch in nicht ganz so gutem Scan, p149 = Tape
Naja schau mal, z.B. in Post #247 hatte ich ja ein "normales Histogramm" über eine ganze TAP Datei, nennen wirs mal Gen1-Diagramm. Dort sind die x-Achse die Kategorien 0..256. 0=unused, 1..255 sind quasi genau die Bytes im TAP, 256 ist die Sonderlocke für extralange Perioden die größer als $ff sind (effektiv also Schrott, zur Orientierung: $100 wäre ca. 2ms). Auf der y-Achse ist dort nicht-normiert aufgetragen wie oft diese Periodendauern in dem gesamten TAP-File vorgefunden wurden.
Gen2 -Diagramme in Post #257 und #263:
Inhaltlich fast das gleiche, nur quasi in Zeitscheiben zerschnitten. Eigentlich nicht Zeit sondern immer 2000 Pulse. Nun muss man das natürlich anders darstellen dass es in 2D reinpasst. D.h.
...die Höhe der Balken in Gen1 wird in Gen2 zur Falschfarbe jedes Pixel (Wert 0 = dunkelblau, der Maximalwert ist normiert auf Dunkelot)
...die 257 Klassen auf der x-Achse in Gen1 werden in Gen2 einfach zur y-Achse. Habe das einfach gedreht, damit man dann mehr Platz in der Breite hat.
...die x-Achse in Gen2 ist jetzt praktisch neu, nämlich in etwa die Zeitdimension. Jede "Pixelspalte" entspricht einem Analyseintervall von 2000 Pulsen. Links ist dabei der Anfang des TAP-Files und rechts das Ende. Die x-Achse ist, wenn man so will, selbst auch normiert auf die Gesamtgröße des TAPs. Nicht-normiert würde heißen dass ein kurzes TAP dann nur ein schmales Diagramm machen würde.
hmm ... ich glaub, ich muß mir erstmal ansehen, wie so eine Datasette die Bytes überhaupt abspeichert, bevor ich hiermit was anfangen kann.
Dann guck mal diese Posts
S6 / #157 Elektronik-Datasettenschaltplan für read+write
S6 / #163 Die drei Grund-Pulse S/M/L (Short/Medium/Long) bzw. etwas unschön S/L/M (für Short/Long/Mark)
S7 / #182 Aufbau der Datenstruktur (also schon auf der logischen Datenebene)
S7 / #183 schöner Link auf eine ASCII-Beschreibung von Luigi
S7 / #194 "Wie liegt so ein BASIC und Maschinencode im RAM ab"
S7 / #200 Tabelle mit den MHz clks der verschiedenen Commodores
S9 / #246 Link auf kurze ASCII-Beschreibung vom TAP-Format
Direkte fanclubmäßige Sammlung von Luigi-Links:
youtube Kanal: https://www.youtube.com/user/thechaosengineer/videos
obiger Link ins wayback: loaders:rom_loader - c64tapes.org
seine Webseite: https://www.luigidifraia.com/sales/
Genau das wollte ich noch checken ob es möglich/vorgesehen ist aber dann bifurkierte ich leider. So ist das mit ADHS. Hab das jetzt mal bei mir oben reineditiert.
Leider bekommt man wahrscheinlich die postIDs der Posts nicht automatisiert raus. Muss man händisch reinmachen. Umgekehrt von postid -> Post-Nummer geht wohl auch nix. Nur
page = ((postNummer-1) % 30) + 1
ginge.
Aber so ein Fred-TOC (thread table of contents bzw. ToH wie highlights eigentlich) ist schon cool.
Desweiteren fällt mir grad auf: Vor 12 Tagen hatte ich nur zwei Beiträge hier im Forum und jetzt schon fast 100, dabei schreibe ich doch gar nicht so viel, oder?
Ach... kann ich auch mal posten... Habe vorhin mal mit dem WAVPRG Tool (#196) aus einem PRG drei WAVs erzeugt, nämlich mit den Optionen
-rectangle
-sine
-triangle
und dann hab die Versionen mal ins Audacity gezogen und visuell verglichen. Einmal im Detail und einmal über das gesamte 36-Sekunden-WAV.
Und in dem Zusammenhang kam dann auch die Frage auf, was eigentlich ein HiFi-Tapedeck bei Record und Play macht, wenn wir so extrem lange Periodenzeiten haben. Das sind ja dann keine Frequenzsachen mehr im Audiosinn (Stichwort 20 Hz bis 20 kHz) sondern Knackser. 10 Hz wären ja 100 ms als Periodenzeit. Aber man hat ja in so einem TAP auch Lücken im Sekundenbereich. Ob man sowas vielleicht als leichten Kopierschutz nutzen könnte? Sodass man ein Band nur noch mit manchen Kassettendecks kopieren kann aber wenigstens nicht mit allen.
Da fallen mir wieder folgende Worte ein:
Was vielen nicht klar ist: Die Kassettenaufzeichnung erfolgt digital. Jeder Flusswechsel ist quasi ein Bit. Naja, nicht ganz, weil in einem speziellen Format aufgezeichnet wird, das zwei Flusswechsel für ein Bit benötigt. Das ist so ähnlich wie bei der MFM und GCR-Kodierung.
So ein Zeug findet sich gerne am Anfang und Ende von vermutlich aus TAP generierten WAV. In der Regel wohl non-sense, den ein Tool wahrscheinlich besser wegsäubern sollte, zumindest optional.
Und wie kommen so lange Pulse überhaupt aus einem TAP File heraus? Es gibt eine TAP Version $01 und in der kann man mittels drei Byte (die Binärcodierung ist $00 für "überlang" gefolgt von diesen drei byte in Little Endian) Perioden bis $ffffff * clk, also ca. 16.8 Sekunden Dauer (also 8.4s high und 8.4s low) codieren. Und ein TAP->WAV-Konverter haut das dann halt 1:1 ins WAV rein.
Man beachte, dass dieser eine Sinus-Schwinger in der Mitte eine Dauer von 1 Sekunde hat, ergo 1 Hz als Frequenz hätte. Da weiss man nicht, was ein Audio-Tapedeck daraus macht. Ich vermute (und klaly auch), dass es hier einen gravierenden Unterschied zwischen einer Commodore-Datasette und einem Audio-Deck gibt. In der Datasette bekommt der Schreibkopf bei der Aufnahme einfach seine DC-Spannung so rum oder anders rum angelegt und wird das Band cm-weise in die Sättigung reinmagnetisieren. Also dann stimmt das schon das eine "digitale" Aufnahme ist. Natürlich gibts eine gewisse physikalische Trägheit sodass die Wechsel nicht in Nullzeit passieren können. Aber man kann vielleicht sagen dass eine Datasette immer in der Sättigung magnetisiert ist, während man genau das bei einer analogen Audioaufnahme um jeden Preis verhindern will. Ich denke man kann das Abspielen einer Datasette auf einem Audiodeck vielleicht vergleichen mit einer Schallplatte die mit einem anderen Verfahren aufgenommen wurde als sie abgespielt wird. Es kommt schon immer was raus, aber man darf nicht zu genau hinschauen.
