Beiträge von Rolando

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/

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.

Korrektur! Im Prinzip ist nur die Beschriftung der y-Achse geflippt.

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.

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.

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.

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.

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.

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.

Zitat von detlef

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.

Zitat von detlef

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/

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.

https://www.youtube.com/watch?v=c3pXICiiIC4

Oh sorry, falscher Fred!

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.

https://www.youtube.com/watch?v=c3pXICiiIC4

Ui, 64 Seiten zu "Datasette" im Data Becker "Das Anti-Cracker Buch", cool!

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?

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 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".

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.

Mei, jetzt paar Tage Urlaub.... das wärs....

Zitat von detlef

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.

Zitat von Franky

...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.

Zitat von detlef

blockweise mit Blockbestätigung übertragen

Das hast du irgendwie recht.

Apropos blockweise: Am C64 steht da dass immer 192 Byte Blöcke übertragen werden, dann die Wiederholung, dann der nächste block. Und das sehe ich nur auf den Header zutreffend. Der ist 192 Byte groß gefolgt von der Wiederholung. Aber dann kommt der komplette Rest, also vielleicht 7 KiB bei den space invaders und dann desSen Wiederholung.

Und was ich auch nicht verstehe: wenn ich zuvor ein Basic Programm im Speicher hatte und lade nun von kassette und das läuft nun eine weile und bricht dann aber mit LOAD ERROR ab, dann habe ich immer noch das alte Programm im Speicher? Das kann ja eigentlich nur bis zu einer bestimmten Größe so sein. Ich hab ja nur 8 KiB.

Hier steht dass im TAP die Bytesize drin ist. Von Dateiname steht nix. Aber das wird dann im Datenbereich drin stehen. TAP ist ja quasi ein sendefertiges Format. Da muss man wahrscheinlich nur die ersten bytes überspringen und den Rest dann umcodieren von Short/Medium/Long auf die Pulsbreite des GPIOs.
https://www.c64-wiki.com/wiki/TAP
Naja, erstmal die Nacht drüber schlafen.

Naja und dann ist da noch eine konzeptionelle Unschönheit. Ich dachte eigentlich man könne es so machen, dass man den Arduino an den CBM ansteckt womit er bootet und einsatzbereit ist und dann geht man mit dem Terminal seiner Wahl drauf und schickt ein Binary (PRG) und der Arduino fiddelts in TTL in den CBM rein. Aber das geht nicht weil der CBM braucht im Headerbereich die bytemäßige Länge (und Zieladresse und Dateiname idealerweise) und die hat erst nicht wenn die Übertragung anfängt.

Ergo braucht es leider ein "Tool" wie z.B. ein python-Skript was vorneweg irgendwie diese drei Meta-Informationen schickt. Ärgerlich. Aber ich gehe da bisher von einem PRG-File aus wo nur die Zieladresse, nicht aber die Bytelänge und ein Dateiname mit drinsteht. Aber ich hab mir noch die das TAP Format angesehen. Vielleicht ist da ja alles drin. Das wäre natürlich cool.

Naja mit dem auskennen ist das so eine Sache. Es lief abends paar Stunden super und dann hatte ich so 1~2h ein Brett vorm Kopf. Nichts ging mehr. Hab dann in der Verzweiflung einfach einen "alten" Sourcecode in den Arduino geladen und das ging dann wieder wie "damals", also halt vor 4h als ich angefangen habe quasi. Ich verstehs nicht. Nachmittags hab ich ja kurz den Pin CTS# gecheckt und meinte, er wäre hi mit Pullup (blockiert) und wenn man ihn auf gnd ....

Ich bin sooo doof!!!!! Genauso ist es ja. Und genau so hab ichs anfangs im Sourcecode auch gemacht. Und dann hat sichs irgendwie im Kopf gedreht und ich dachte hi=wäre frei und lo=blockiert. OK, verstanden, danke!

Jedenfalls hab ich massiv rumgefiddelt und der aktuelle Stand ist jetzt der, dass wenn man das CTS# nur minimal kurz wie z.B. 10µs low zieht, dann kann man sich kontrolliert genau ein Byte reinziehen. Also bei 115200 Baud wo ein Byte 87µs lang ist.

Und dann ist halt generell noch offen, ob man zwecks Timing/Jitter mit dem Arduino-"Betriebssystem" arbeiten können wird oder ob man das mit cli() stilllegen muss und sich sein byte so baremetal-mäßig aus dem UART rausziehen.

SD ist jetzt für mich erstmal sekundär.

-Erstens mal bin ich mir sicher dass es sowas schon gibt. Wahrscheinlich zuhauf.
-Zweitensmal wie schon beschrieben ist mir das für den Einsatz als Entwicklungstool zu uncharmant wenn ich immer ein File auf SD schreiben muss und dann die Karte vom PC in den Arduino, von dort verschicken und für die nächste Iteration wieder zurück in den PC and so on. Selbiges wenn es um Spiele geht hab ich ja evtl. die Idee genau dieses eine aus dem Internet laden zu wollen.
-Drittens (Hauptgrund) habe ich mich jetzt grad schon in dieses RTS/CTS reingefressen und es gefällt mir sehr gut.

Hab jetzt mal geforscht.

Theorieteil:
Alle Arduinos haben quasi kaum RAM. Nano=2KiB .... 2560er=8KiB. Taugt alles nix um irgendwelche PRG-Files (effektiv ja bis zu 64 KiB bei einem C64 oder so) komplett in den Arduino zu bringen dass ers dann direkt aus seinem RAM in den PET bringt.

Praxisteil:
Wie ist das jetzt mit RTS/CTS? Hab ich nie benutzt und es ist am China Arduino Nano auch gar nicht vorgesehen. Aber der CH340G kann es. In meinem geliebten HTerm gibt es einen Knopf "CTS Flow Control". Und tatsächlich, wenn ich diesen anhake, auf "Connect" drücke und dann mit "Send file" eine riesige Datei senden will, schickt das Windows 200 Byte irgendwohin, entweder in den Treiber oder bis in den China-CH340G und bleibt dann stehen. Und weiter passiert nichts. Nun gibts an dem CH340G einen (ich meine unbeschalteten) Pin #9 "CTS#". Das ist ein Eingang mit pull-up. Und tatsächlich: wenn ich diesen Pin nun mit einem 470 Ohm gegen GND lege geht der Transfer scheinbar immer im 200 Byte Raster weiter. Ergo: Ich kann das Nano-PCB leicht modifizieren, indem ich mit Fädeldraht einen AVR-GPIO auf den CH340G-Pin#9 löte und kann dadurch die Übertragung beliebig "pausieren". Genau das was ich brauche.

Cooler Link mit vielen yts (youtubes).

Arduino hätte natürlich tatsächlich auch eine Reihe von Vorzügen. Nachteile würden mir gar keine einfallen... Deswegen hab ich den jetzt auch zu meinem Lieblingscompter gemacht im Profil. Auch wenns nicht retro ist. Aber für Retro.

-5V I/O

-Strom-Versorgung direkt über den Cassettenport

-USB alles an Board
-billig
-jeder kanns nachbauen
-ADC onboard (schnell genug? keine Ahnung)

Das ist korrekt. Aber ich habe gar keinen Überblick was es eh schon alles gibt.

"SD -> Floppy" gibts, aber wird vom PET-Ur-ROM nicht unterstützt?

"SD - > Tape": ? gibts was ? gibts nix?

"Live per USB/RS232 was reinschieben auf Floppy oder Tape"?

Live hat ja den Charme wenn man am PC entweder BASIC schreibt oder Assembler-Binaries generiert, dass man die gleich ins Zielsystem reinladen kann. Das mit SD-Karten ist ja wiederum eher für Archiv-Spiele interessant.