Beiträge von Rolando

Bei ON-ON muss der Fachprofi natürlich unmittelbar an die Verdummungsmaschine denken.

Zitat von klaly

Also effektiv werden nur CS1, CS3 und CS4 verwendet.

Weiters könnte man sagen dass BA11 bei den $x000 ROMs auf \CS3 geht und bei den $x800 auf CS1. Der jeweils andere CS ist dann neutral, sprich daueraktiv beschaltet.

Zitat von detlef

In gewohnter Data Becker Qualität. Ich würde erst mal nichts glauben, was da drin steht.

Exakt. Man darf es eigentlich nur als Anreiz für eigene Forschungen sehen. So war das damals (wo ich allerdings als ca. 12-jähriger noch kaum Background hatte) und so ist es noch heute wo ich mein halbes Ingenieursberufsleben hinter mir habe.

Man muss das alles mal ordentlich aufarbeiten. Gut, dass bald Weihnachten ist. An einem popligen Wochenende kommt man ja zu nix.

Habe gerade in data becker '64 intern', seite 171, eine info gefunden zum thema datasette und zwar was mit den zwei gleichen aufzeichnungen hintereinabder beim lesen passiert. Demnach gäbe es tatsächlich eine aet rudimentäre datenkorrektur. Man muss sich das wohl mal im rom listing ansehen. Und dann ist noch die frage wie es 5 jahre früher im pet implementiert ist.

Cool, aber doch nicht sooo cool. Das wären dann günstigstenfalls $30.34 für die Bestellung vom 100er x1, d.h. für einen 6550 Adapter mit seinen 22 Pins anteilig $6.67.

Naja man kanns ja mal im Hinterkopf behalten wenn es konkret werden sollte. Man müsste sich dann eher so 100 x5 bestellen und schaun dass man die dann innerdeutsch weiterverkloppt (Forum/ebay).

Aber vielleicht findet man ja auch noch eine normalere Bezugsquelle. Der Hersteller ist ja in UK und der Shop in USA. Da muss es doch noch was anderes geben.

Cooles Zeug, aber wo herbekommen?

Aha, vielleicht bringt einen dieser Link weiter:
https://leadframes.co.uk/dual-in-line-leadframes/

Diese Messerchen sind scheinbar von einer Firma "Batten & Allen" und heißen "BA3760" oder besser gesagt hießen.

Der "D’Asaro Designs" hat die wohl mal selbst in seinem Shop gehabt.
http://www.dasarodesigns.com/p…e-dip-pcb-edge-clip-pins/

Dort ist auch dieser Link auf das Datasheet.
http://dasarodesigns.com/wp-co…ads/DIL-Catl-15-06-09.pdf

Und wenn man 10 Jahre lang auf ebay wartet, dann tauchen die dort vielleicht mal auf. Aktuell ist hier tatsächlich irgendwas ähnliches von dem Hersteller drin aber mit 1.27mm pitch, 5000 Stück und 300€ mit Versand.
https://www.ebay.de/itm/121717927283

Ich mach auch mal einen Screenshot damit das erhalten bleibt wenn es auf ebay wieder weg ist.

Jaja, die Archive hab ich schon gesehen. Aber fertig kaufen wäre halt noch feiner gewesen. So muss man ja v.a. erstmal gucken wo man diese einzelnen Messerchen herbekommt. Und es ist naturlich oo-mal mehr Arbeit als Klicken und paar Tage später x-Stück aus dem Briefkasten rausholen.

Die Beschaffung ist wohl nicht mehr bei ihm direkt möglich, er scheint mir out-of-business zu sein. Müsste man also irgendwie selbst nachbauen. Notfalls halt mit normalen IC-Stiftleisten und einer Zwischen-Schutz-Fassung.

Helau!

Ich bin aktuell auch im Thema defekte 6550/6540 Bausteine drin.

Bin dann eben auch auf diesen "D’Asaro Designs" gestoßen mit seinen schönen Artikeln s. Post #4 weiter oben.
ROM: http://www.dasarodesigns.com/product/6540-rom-adapter/
RAM: http://www.dasarodesigns.com/p…ore-pet-2001-ram-adapter/
Leider scheint mir, dass der Kollege out-of-business ist seit wahrscheinlich <4 Jahren.

Und dann hatte ich letzte Woche so eine rudimentäre Grundidee für einen vielleicht GAL-basierten Pöppel mit 4-pin DIP-Schalterchen wo man ein vielleicht 16 KiB großes EPROM verwendet und einen 4-poligen DIP-Schalter um 12 verschiedenste Einmappungen zu realisieren.

Modus #0: 2 KiB auf $c000

Modus #1: 2 KiB auf $c800

Modus #2: 2 KiB auf $d000

Modus #3: 2 KiB auf $d800

Modus #4: 2 KiB auf $e000

Modus #5: 2 KiB auf $f000

Modus #6: 2 KiB auf $f800

Modus #7: 4 KiB auf $c000

Modus #8: 4 KiB auf $d000

Modus #9: 4 KiB auf $f000

Modus #10: 8 KiB auf $c000

Modus #11: 16 KiB auf $c000 unter disablung von $e800

Ich wüsste aber nicht wie man das dann implementiert. Ist erstmal nur eine dumme Idee. Auf jeden Fall ist schon mal unschön, dass man sich wahrscheinlich von mehreren Nachbarsockeln die Signale SELx (x=C/D/E/F) zusammensuchen muss.

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.

https://youtu.be/Alpo3pKKOJQ

Zitat von axorp

Zitat von Rubberduck

PETTESTER ROM

was ist ein pettester rom?

Hier ist noch eine unbeantwortete Frage. Ist das sowas wie das Vossi Test ROM V1.0 respektive V1.3?

Sehr spannender Fred jedenfalls.

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.

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

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

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.

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?

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.

Zitat von detlef

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

Zitat von detlef

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.

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.

schon klar. Aber ist halt leicht unschön und kostet ja auch unnütz zeit.

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

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.

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.

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:

Zitat von detlef

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.

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?