Aha, und der Schreibkopf braucht scheinbar sehr wenig Bumms. Weil man sieht einen 5V-Treiber und einen 10k Widerstand. Ergo fließen da maximal 0.5 mA.
Mittags kam nämlich mit klaly die Fragestellung auf, wie so ein Klinkenstecker-Kassettenadapter funktioniert. Ob da einfach die max. 300 mV (Effektivwert) z.B. aus dem Smartphone auf den Schreibkopf draufgehen oder ob da noch ein Verstärkerchen per Knopfzelle drin ist. Letzteres erschien uns möglich aber eher sehr unwahrscheinlich.
Wir machen einen Bj. 1978 PET 2001-8 fit für dessen Ausstellung auf der Hack & Make in Nürnberg
-
-
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.
Musikstück haben doch auch Phasen mit Stille. Warum sollte ein Tapedeck damit nicht klarkommen.
-
Mit pausen hab ich kein problem. Aber mit den knacksern. Wie kommt man überhaupt zu einem TAP?
Geht da einer her, steckt eine datasette ins hifideck und spielts in den computer (sprich digitalisierts) in ein WAV und dieses wird dann per Tool reduziert in ein TAP?
In einem z.b. C64 ist das ja kaum so einfach möglich zwecks speicherplatz. Oder... Hängt man einfach seine datasette an den pc-parallelport? Hab ja keine Ahnung.
-
So jetzt Thema physikalische Datasette. Habe die interne Datasette, den hinteren Port#2, Multimeter, 470-Ohm-Widerstand, ein Multimeter und einen hingelöteten Reset-Taster. Und eine neuere 1531 Datasette (vom C16) mit einem Adapter auf den alten Platinenstecker. Hier meine Notizen.
Intern: Wenn ich einschalte und einen Garbage-Screen habe, was vorkommt, weil vielleicht das Timing am Reset-Generator schlecht ist ODER ich halte den Reset-Taster dann läuft der Motor des internen Tapes und zwar immer - unabhängig ob irgendeine Laufwerkstaste gedrückt ist. Sobald der BASIC-Screen kommt, ist der Motor aus. Motor bleibt erstmal auch aus wenn ich z.B. Play gedrückt habe. Der geht erst an wenn man LOAD/SAVE tippt. D.h. der Motor wird direkt vom Computer getrieben. Und dieser mechanische Schalter, der detektiert, ob eine Taste gedrückt ist, ist ausschließlich ein Sensor. Solange ich nicht LOAD/SAVE gedrückt habe kann ich also auch nicht spulen. [Nachtrag: Wenn ich mir den vierten Absatz nochmal durchdenke, kommt mir das fast wie ein Software-Bug vor.]
Port#2: Im Fall gehaltener Reset ist Funkstille am Motor wenn das Laufwerk angesteckt ist. Sobald das BASIC läuft, ist der Motor benutzbar, läuft aber nur wenn eine Taste gedrückt ist. D.h. anders als beim internen Laufwerk geht dieser Sense-Kontakt auch zum PET, aber die eingehende Motorleitung treibt den Motor nicht direkt, sondern nur wenn auch eine Taste gedrückt ist, läuft der Motor. Da hat man also was verbessert bei der Eigenkonstruktion gegenüber dem off-the-shelf Laufwerk im PET.
Und eines habe ich jetzt auch verstanden durch bisle rumspielen: Wenn ich z.B. sage LOAD und drücke PLAY, dann läuft der Motor. wenn ich jetzt drücke RUN/STOP dann bleibt der Motor stehen. Jetzt möchte man meinen, dass der PET den Strom von der MOTOR-Leitung genommen hat und ich nun nicht mehr spulen kann. Aber da hat damals einer mitgedacht! Der PET fühlt auf der SENSE-Leitung und wenn der PET feststellt, dass STOP (an der Datasette) gedrückt wurde dann hakt die Motor-Sperre softwaremäßig aus und ab da wenn man wieder <<, >> oder PLAY (oder REC) drückt, dann gibt der PET wieder Spannung auf den MOTOR. D.h. man hat da einiges als Logik in Software laufen wo man sich eigentlich gar keine Gedanken macht und meint dass passiert alles autark/mechanisch im Laufwerk.
Und meßtechnisch kann ich zum Port #2 sagen (kein Laufwerk angesteckt), dass auf Pin #3 (MOTOR) zunächst alles floating ist. Das Multimeter lädt da über die Zeit die Spannung hoch oder so. Pin #6 (SENSE) hat 5V per pull-up im PET. Wenn ich den mit 470-Ohm auf Pin #1 (GND) ziehe, bekomme ich 6.7V (unbelastet!) auf Pin #3 (MOTOR). Desweiteren sind Pin #4/5 (READ/WRITE) scheinbar defaultmäßig auf 5V. -
Mit pausen hab ich kein problem. Aber mit den knacksern.
Das ist doch sowieso keine gültige Information. Also ist es doch egal, was das Tapedeck daraus macht.
Das wird beim Lesen bzw. beim Suchen von Sync-Signalen einfach ignoriert.
-
schon klar. Aber ist halt leicht unschön und kostet ja auch unnütz zeit.
-
Da du die analysierten TAP-Files leider nicht angehängt hat, kann man leider auch nichts nachvollziehen. Auch nicht die "Knackser".
-
hmm ... ich glaub, ich muß mir erstmal ansehen, wie so eine Datasette die Bytes überhaupt abspeichert, bevor ich hiermit was anfangen kann.
Wenn's dich beruhigt, ich verstehe die Diagramme auch nicht, obwohl ich weiß, wie die Datenaufzeichnung funktioniert.
-
Ob da einfach die max. 300 mV (Effektivwert) z.B. aus dem Smartphone auf den Schreibkopf draufgehen oder ob da noch ein Verstärkerchen per Knopfzelle drin ist. Letzteres erschien uns möglich aber eher sehr unwahrscheinlich.
Da ist nix drinnen! So ein Teil hab' ich mir vor ca. 30-35 Jahren mal selber aus einer alten Kassette und einem alten Tonkopf gebaut... - hat einwandfrei funktioniert und ich hab's jetzt noch irgendwo 'rumliegen!
:)Franky
-
-
Ich habe gestern mal die Ohms gemessen in dem Klinken-Kassettenadapter. Je 272 Ohm von L/R nach Masse und aber ich glaube 5 Ohm zwischen L und R als wäre das Teil Mono. Aber der Kopf ist stereo. Muss ich mal irgendwie weiter testen. Am Samstag hatte ich jedenfalls als Datasette keinen Erfolg damit.
-
Wenn's dich beruhigt, ich verstehe die Diagramme auch nicht, obwohl ich weiß, wie die Datenaufzeichnung funktioniert.
Verstehst du die Diagramme in den Videos vom Luigi? Z.B. hier ab 1:30
https://youtu.be/0aKqacraOI0?t=90
Ist vermutlich fast das gleiche was ich mache nur halt bei ihm live, während ich es aus einem TAP aus der Konserve zeiche. Und er hat halt noch die 3 Sollzonen in dunkelblau eingezeichnet und legt die aktuellen Messwerte hell drüber. Bei mir sind dafür die Falschfarben drin wodurch man noch eine Dimension mehr Information drin hat. -
Hi Klaus,
Du solltest eigentlich alle Informationen in meinem Thread dazu finden: Mein PET2001 Projekt
Du kannst die Platine aber auch mit diesen Tastern hier bestücken:
https://de.farnell.com/alps-alpine/skrrace010/taster-0-05a-12v-dc-smd/dp/3261830?st=skrrace010
So hat es axorp gemacht:
Das ist wirklich toll bei ihm geworden - so möchte ich auch noch eine Platine bestücken!
:)Franky
(P.S.: axorp : ...ich hoffe ich habe nicht Dein Recht auf diese Bilder hier verletzt???)
-
Da du die analysierten TAP-Files leider nicht angehängt hat, kann man leider auch nichts nachvollziehen. Auch nicht die "Knackser".
Die verwendete TAP-Sammlung: siehe #254
(Da ist mir grad akustisch aufgefallen dass dieses dog-star-adventure.wav ganz anders klingt als der Rest.
Und mein c16_tape.tap hänge ich an mit Fake-Endung.
Zwecks der Knackser, aber die sind jetzt nicht sooo wichtig z.B. die space invaders: #128 -
Die verwendete TAP-Sammlung: siehe #254
Ok, das hatte ich in den vielen Beiträgen überlesen.
Dann weiß ich jetzt, wo diese parallelen Geisterspuren herkommen und mit der korrigierten Y-Achse ist dann klar.
-
hmm ... ich glaub, ich muß mir erstmal ansehen, wie so eine Datasette die Bytes überhaupt abspeichert, bevor ich hiermit was anfangen kann.
Nochmal zum generellen Verfahren. Leider habe ich noch keine brauchbare Beschreibung gefunden, die den kompletten Ablauf von vorne bis hinten verständlich erklärt. Ich habe mir damals (vor ein paar Jahren) die Informationen mühsam aus vielen einzelnen Beschreibungen zusammengesucht.
Dazu gehört die elektrischen Aufbereitung der Signal in der Datasette beim Lesen und Schreiben, dann die Kodierung von Bits und Bytes und der gesamte Aufbau einer Aufzeichnung mit Leader, Header und Daten bzw. Programmblöcken.
Das über den Umweg einer TAP-Datei zu verstehen, ist nicht sinnvoll. Das macht die Sache unnötig kompliziert.
-
Mir gings erst ähnlich mit dem Verständnis. Aber dann hab ich einfach mal angefangen mich mit python in das WAV reinzufressen (WAV ist im Prinzip nur noch eine Stufe näher an der Physik verglichen mit TAP) und dann führte aber relativ schnell eins zum anderen.
Und durch das Crackerbuch (ab Seite 149) hab ich dann auch noch verstanden, dass man auf der Datasette auch (sogar von BASIC aus) selbst Daten absetzen kann (OPEN/PRINT/GET/CLOSE und so). Die werden dann wohl immer zu 192 Byte-Blöcken im RAM vorgehalten und erst wenn man z.B. CLOSE #1 sagt auf das Band geschrieben oder wenn mehr als 192 Byte im RAM sind. -
Und durch das Crackerbuch (ab Seite 149) hab ich dann auch noch verstanden, dass man auf der Datasette auch (sogar von BASIC aus) selbst Daten absetzen kann (OPEN/PRINT/GET/CLOSE und so). Die werden dann wohl immer zu 192 Byte-Blöcken im RAM vorgehalten und erst wenn man z.B. CLOSE #1 sagt auf das Band geschrieben oder wenn mehr als 192 Byte im RAM sind.
Das Schreiben auf Band mit OPEN und PRINT# ist sogar schon im Standard-Handbuch des PET beschrieben.
Als ich damals meinen PET bekam (1978) war das eine der ersten Aktionen, dass ich das Schreiben von Daten auf Kassette ausprobiert habe.
Ja, ganz nett. Aber leider ohne praktischen Nutzen, weil man mit dem Karteikasten einfach 10x schneller war. Und das funktionierte ja auch nur sequentiell. Man musste also immer alle Daten im Speicher halten. Also ich weiß nicht, ob das überhaupt mal jemand sinnvoll genutzt hat.
-
interessant fände ich ja noch die Frage, wie man - bei Commmodore - eigentlich auf diese komischen 192 Bytes (?) kommt. Man würde doch eher 256 (schon wegen der "page" Größe im 6502) erwarten.
Vielleicht ist das ja auch interessant, weil es evtl. irgendwelche Einschränlungen seitens des Systems Datasette gibt, weshalb das sinnvoll wird, die Größe da so anzusetzen. Dann wäre es evtl. auch für die JCII Routine möglicherweise interessant zu berücksichtigen.
-
Also die 192 Byte wunderten einen Kollegen auch schon, mich aber ehlich gesagt nicht. Kann doch jede beliebiege Zahl sein. Vielleicht waren es ja mal 128 und das erschien einem dann zu wenig also hat mans dann bisle aufgeblasen. Nicht vergessen: der Ur-PET hatte nur 4 kiB RAM.
klaly: Konnte der KIM-1 auch schon ein Tape bedienen? -
Jedenfalls hab ich jetzt mal ein TAP (Aliens.tap) gefunden was irgendwie einen "Novaload" Schnelllader vorneweg hat. Da schaut mein Diagramm so zu aus.
Gefällt mir was ich sehe, muss ich mir selbst auf die Schulter klopfen.
Leider gibts keine echte Zeitachse in Sekunden. Aber ich würd annehmen:
-kurzer 2 Sekunden Lead-in (die üblichen 10s wird sicher die Leseroutine gar nicht brauchen)
-Header mit Wiederholung mit Standard-Timing. Da wo die rote Linie für 1-2 Pixel unterbrochen ist und stattdessen in der türkisenen Linie ein Pixel gelb ist, vermute ich mal die Mitte, nämlich diese "60 Impulse Synchronisation" in der Datenstruktur.
-2 Sekunden Pause
-Schnelllader mit Wiederholung. Unwesentlich länger als der Header, also wohl ca. 250 Byte payload schätze ich mal.
-Dann unmittelbare Umschaltung auf das proprietäre Aufzeichnungformat mit kürzeren Perioden und nur noch 2 Periodenlängen und statistisch höhere Häufigkeit auf der kürzeren Periode. -
interessant fände ich ja noch die Frage, wie man - bei Commmodore - eigentlich auf diese komischen 192 Bytes (?) kommt. Man würde doch eher 256 (schon wegen der "page" Größe im 6502) erwarten.
Vermutlich limitiert hier die Größe der Kassettenpuffer. Davon braucht man 2 Stück. Vielleicht war einfach nicht genügend Speicher vorhanden.
-
Jedenfalls hab ich jetzt mal ein TAP (Aliens.tap) gefunden was irgendwie einen "Novaload" Schnelllader vorneweg hat. Da schaut mein Diagramm so zu aus.
Das ist jetzt aber wieder C64. Das sollte man immer dazuschreiben, sonst geht das hier drunter und drüber.
Der Header wird normal geladen und enthält den Schnelllader und der übernimmt dann automatisch die Kontrolle und lädt den Rest des Programms mit einem proprietären Format nach.
Beim PET klappt das nicht, weil der Header nicht automatisch die Kontrolle übernehmen kann. Man hätte nach dem Laden des Schnellladers diesen jedesmal manuell starten müssen.
-
hallo franky,
(P.S.: axorp : ...ich hoffe ich habe nicht Dein Recht auf diese Bilder hier verletzt???)
nein.
es sollte mal meine sehr kleine und schöne tastatur für reparaturzwecke werden.
so hoffe ich,, ein layouter hilft irgendwann mal mir dabei.
1. die platine sollte hinten viel kürzer sein, eigentlich nur so groß wie der pet tastatur aufkleber selbst.
2. die schrägen ecken sollten entfernt werden, passend zum aufkleber.
3. der stecker sollte eine ausparung in der platine, unter dem aufkleber, bekommen und bündig angelötet werden.
damit der möglichst nicht unter dem tastaturaufkleber übersteht.
4. dank deiner kompletten einseitigen tastaturmatrix verdrahtung ist auf der rückseite noch platz für
die busines verdrahtung und auch dem entsprechendem aufkleber.
so hätte man für alle pet, cbm 2xxx bis 8xxx boards eine sehr schöne und kompakte und kleine test tastatur für reparaturen.
auf der einen seite, die grafik tastaturmatrix und auf der anderen seite die busines tastaturmatrix.
genauso wäre es ideal, auf der einen seite die sx64, c64, besser gleich die c128 tastatur matrix und auf der
rückseite die c16 / plus4 matrix zu haben.
dann wäre eine cbm6xx/7xx cbm-II tastatur für reparaturen und zum testen auch ideal.
auf der rückseite wäre noch platz für eine andere tastaturmatrix.
die kleinen und kompakten tastaturen wären ideal für die cc-reparaturecke.
gruß
helmut
-
..bin wieder zurück in Hof
und hier meine Impressionen zur Hack&Make 2022:
-
Schön dass wir da waren!
Kleiner Nachtrag von mir. Freitag hatte ich meinen Arduino-Pöppel prinzipiell startklar mit dem man eigentlich ein TAP-File Binär per USB von jedem beliebigen Rechner mit jedem beliebigen Terminal was [Flusskontrolle, Hardware Handshakte, RTS/CTS] einschalten kann schicken kann. Habe die Arduino-Software dann im Verlauf der Nacht immer mehr verbessert sodass man Informiert wird was gerade passiert und v.a. ob was schief gelaufen ist auf der Neucomputer/USB/Arduno-Seite.
Das erste Problem war, das(s) komischerweise nur wenige Rechner in der Lage sind die Daten schnell genug zu liefern. Das Ding ist: Der AVR-Kern hat nur einen Buffer von 1 Byte, d.h. ein Byte ist abholbereit und ganz intern kann "parallel" ein weiteres Byte in ein Schieberegister oder whatever einlaufen. Dann haben wir im Arduino die Betriessystemschicht (nenne ich mal so". Dort ist die Buffertiefe 63 Byte. Der China-USB-Chip CH340G am China-Arduino-Nano hat vermutlich ~256 Byte Buffer (Annahme von mir aufgrund von eigenen Verhaltensbeobachtungen). Was ich nun mit meinem leicht modifizierten Nano mache (Leitung zwischen D2 und und dem CTS#-Pin com CH340G): Ich sauge mir initial 50 Byte in den Betriebssystem-Buffer (immer durch kurze 10µs low-Pulse auf CTS#. Dann beginne ich mit der Transferroutine zum PET. Die Idee ist jetzt dass ich während den typ. 1-3 Minuten Übertragung immer mal einen CTS-Puls mache und dadurch ein oder kein Byte in den Buffer reinbekomme. Dadurch ist der Jitter auf der PET-Seite einigermaßen kontrollierbar ohne dass man tiefer in die Trickkiste greifen muss. OK. Was jetzt passiert: Auf dem PC auf dem ich das so entwickelt habe hats es funktioniert wie gedacht. Auf dem Laptop auf dem ichs dann im Zusammenspiel mit dem PET ausprobieren wollte ging nix. Auf einem fetteren (für meine Verhätnisse; i7) Win10-Laptop gings wieder. Auf einem alten Netbook mit Mint gings leider nicht. Auf klalys nagelneuem Notebook gings auf der Messe ohne Buffer-Underflow-Meldsung seitens des Nanos aber die Übertragung dauerte 10min, sehr sehr komisch. Der Ablauf ist jedenfalls folgender. Ein Win10-PC schickt scheinbar immer 200 Byte vermutlich über den Treiber bis in den CH340G rein. Wenn in dem nur noch ~50 Byte im Buffer sind, dann haut der PC wieder neue 200 Byte drauf, sodass dann ~250 Byte drin sind. D.h. der zeitkritische Punkt ist jender wo nur noch 50 Byte im CH340G. Wenn da vom PC nicht schnell was nachkommt dann krachts.OK. zweites Problem war dass der PET nichts verstanden hat. Nach einer Weile dachte ich mir... Wie schauts denn mit dem Thema Phase/Polarität (also des READ-TTL-Signals) auf dem TAPE-Stecker aus? Nur weil man in der Doku diese Puls-Perioden immer als High-dann-Low sieht und die auf dem Band dann als postive und negative Amplitude sind (keine Ahnung wie das dann als Magnetiesierung auf dem Band ist) heißt das ja nicht, dass das TTL-Signal grad anders zum ist. Und so wars dann auch. Einfach in der Arduino-Source 1-0 zu 0-1 gemacht und alle Übertragungen waren auf einmal von Erfolg gekrönt (wie gesamt wenn man einen der wenigen passenden Laptops vorne dran hatte).
-
Drittes Problem. Das war dann so in der Nacht vor der Messe gegen 3 Uhr. Nix ging mehr in Sachen Arduino-Übertragung. Den PET hatte ich in der Nacht oft stundenlang in LOAD/SEARCHING stehen in der Hoffnung dass der immer was auf den Bildschirm schreibt (FOUND / LOADING / LOAD ERROR) wenn er was erkennt. Dann hab ich mal Reset gemacht und dann warf mir das BASIC 3071 Bytes entgegen. Bin dann irgendwann gegen 5 Uhr ins Bett. Und hab dann noch paar mal beim Aufs-Klo-gehen eingeschaltet und immer waren die 3071 Byte auch im abgekühlten Zustand. Pech.
Auf der Messe hatte klaly dann seinen RCT(P) dabei und der Meldete, dass einer der 8 oberen RAM-Bausteine einen Treffer hat. Hab den dann ganz nach oben gesteckt sodass ich jetzt aktuell 6xxx Bytes habe und schauen muss wie ich den einen kaputten RAM ersetze.
Hab mir dann auf der Messe als "Schau-Programmieren" einen einen BASIC-Hex-Dumper geschrieben der besagt dass die mittleren beiden Bits stuck-at-one sind. Also sehr ähnliches Fehlerbild wie bei dem kaputten ROM-Baustein "H7". -
Ich bitte die etlichen Typos in den Posts #298 und #299 zu entschuldigen. Hab die erst schnell abgefeuert und wollte dann nachkorrigieren aber dann glockte die Frau zum Frühstück und jetzt sind die Beiträge wohl per time-out zum read-only geworden. Quasi mit allem Unsinn in Stein gemeißelt.
-
Mein Impressionen Video von der Hack & Make. Leider ist z.B. Shadow kaum drauf weil ich den Drehtermin verkackt habe. Hab erst 20min vor Messeschluss zur Kamera gegriffen als der Kuchen bereits gegessen war.
