Posts by cbmhardware

Ein formschönes Pflaster für die eingerissene Regentonne.

NC-Start drücken und schwitzen am Rücken.

Mit "Karosserie-Wumpe" eingeklebt.

Quote from Mefftan

Wegen des gehärteten Werkzeugstahls wird das früher oder später brechen.

Hab das gerade bei langen Drehmoment schlüsseln auch oft gemacht, wenn man halt richtig Kraft braucht.

Wenn das wieder brechen sollte, kommt das Ding in die Schrottkiste. Ob dieses "Chinesium" so gehärtet ist ? - Hatte es mit 80A/24V MAG schon ordentlich zum Glühen gebracht.

Habe ich noch nie gesehen. Wenn man aber ans Jahr 1984 zurück denkt, da wollte man doch die Spiele mit den schönen Covern auf Kassette. Ob sich da jemand dieses Laufwerk für Minikassette zugelegt hat, um dann festzustellen, dass es nur als eigenes Speichermedium nutzbar ist ?

Gestern: Billige Drehmoment-Ratsche an Geländewagen-Räder: minus Ratsche. Nicht wirklich repariert, wieder nutzbar, also anders kaputt.

Quote from Snocksman

OK, und da die CPU sich nach dem düdeln beim einschalten ja scheinbar aufhängt (kein erneutes düdeln nach 81ten Tastendruck), ist es sehr wahrscheinlich, dass der CRT-Controller gar nicht initialisiert wird. So richtig ?

Zuerst wird die Initialisierung des CRT beim Reset angesprungen und danach werden die notwendigen Vektoren gesetzt. Es kann schon sein, dass der CRTC richtig initialisiert wird, es danach aber hängt. Da muss nur eine Daten- oder Adressleitung festliegen, dann war es das.

Übliche Verdächtige sind da immer RAM-ICs oder Multiplexer. Mit dem RAM/ROM-Adapter könnte man das Problem sicherer festlegen.

Quote from Bobbel

8 Jahre ist es her das ich eine Sammelbestellung mit dem Layout von cbmhardware gemacht habe

microSD2IEC Revision 1.3

Platinen habe ich immer noch reichlich

Kannst Du die nicht in Deinem Shop als Bausatz ohne AVR anbieten ? - Wer einen 644p dafür übrig hat, oder anschaffen möchte, kann sich das dann bauen. Und dazu vielleicht noch zur Aufbauanleitung verlinken. http://www.cbmhardware.de/show.php?r=10&id=8

Bei einem Ebay-Händler sehe ich eine Version ohne Treiber, mit AVR als Bausatz: 199 verkauft . Und der verkauft auch noch andere Variationen wie "geschnitten Brot". Viele Jäger sind der Hasen Tod.

Aber um die 20 werde ich auch noch haben. Komme auch seit 8 Jahren nicht zum Aufbau.

Diese Monitore haben auch gern mal eine kalte Lötstelle. Manchmal hilft ein sanfter Schlag gegen das Gehäuse, um zumindest kurzes Leben erkennen zu können. Ansonsten könnte man mal hinter dem Regler am TP nachmessen, was da noch ankommt.

Quote from Snocksman

Nachdem ich die davon befreit habe 21,3V AC.

Die Spannung eilt dem Strom voraus. Vermutlich Leerlauf, weil nichts verbraucht wird.

Quote from Snocksman

Aber vom einen braunen Draht zum anderen messen war schon richtig, oder ? Da messe ich dann nämlich nur 0,6V.

Deswegen wäre es vielleicht gut, mal einen Draht zu trennen. Vielleicht kollabiert die Spannung auf der Monitorplatine.

Quote from Snocksman

Öhhhmmm, Moment mal... Ich habe mir gerade so gedacht, miss doch mal die Spannung, die vom Trafo zum Monitor geht...

Die beiden braunen Drähte links gehen zum Monitor... Wenn ich zwischen den beiden messe, sind das 0V. Trafo defekt, oder einfach falsch gemessen ?

Daran dachte ich auch eben. Da müssten ca. 14V~ aus der Wicklung kommen. Vielleicht mal eine Leitung ablöten und dann nochmals messen ?

Der Schaltplan, Seite 41: http://www.zimmers.net/anonftp…2_Technical_Reference.pdf

Quote from Snocksman

Wenn ich das richtig sehe hat cbmhardware , hier aus dem Forum, den Schaltplan dieses EPROM Brenners schonmal nachgezeichnet...

Ja, genau, schon wieder vergessen. Da ist der rudimentäre Schaltplan: http://www.cbmhardware.de/temp/eprommer/mmlogic.png

Die leere Platine des Computer-Zauber haben ich eben nochmals fotografiert. Falls das hilfreich ist:

http://www.cbmhardware.de/czauber/unten.jpg

http://www.cbmhardware.de/czauber/oben.jpg

Vielleicht möchte jemand ein kleines Testprogramm schreiben. Ich habe schon genügend "Eisen im Feuer", zu denen ich kaum komme.

Das mit den Dioden und Elkos ist ein Klassiker, der oft in der Röhrentechnik verwendet wurde: eine Kaskade. Ich vermute, dass da über Spannungsteiler (Widerstände) ein Pegel an VPP gelegt wird. Den könnte man mit entsprechenden Pokes prüfen: also kein Eprom in den Sockel und einfach mal nachmessen, ob VPP auch passend da ist.

So eine Kaskade liefert keine besonders stabile Spannung. Bessere Eprommer verwenden einen TL497 um stabilen Pegel an VPP zu bringen.

Quote from Zitruskeks

Basic 1 , 901447-01-ROM *** IEEE Bug

Basic x , 901447-09-ROM *** KEIN IEEE Bug

Der Unterschied dieser beiden ROMs liegt bei genau 15 Bytes. Ich würde das eher als minimalen Patch sehen. Ein guter Ansatz um die verschiedenen ROM-Versionen per Software zu erkennen.

Quote from Snocksman

Basic 1 *** IEEE Bug

Basic 1 Update *** IEEE Bug

Basic 2 ### kein IEEE Bug

Ich bin kein besonderer Freund von BASIC1 und hatte bisher immer eher etwas für die folgenden Versionen gemacht. Ich kann daher die Unterschiede der ersten beiden Versionen nicht genau benennen. Ob sich damit überhaupt schon mal jemand beschäftigt hat ?

Diese BASIC1-ROMs sind einfach nur gruselig, wird sehr wahrscheinlich daran liegen.

Quote from detlef

Ja genau. Auf dieser Seite bin auch zum ersten Mal über "Basic 3" gestolpert.

Ich nenne die Version mit den Rauten auch immer Basic 2, wie es auch im C64-Wiki steht: " ... angezeigte Versionsnummer dort ist allerdings noch 2" . Die zweite Veröffentlichung des Basic 1 war eigentlich auch nur ein Bugfix, da war ansonsten nichts, das eine neue Versionsnummer rechtfertigen würde.

Liegt hier auf dem Tisch:

Möchte ROM-Listings weiterführen und ein paar Label-Files anlegen. Damals war man sich in den Büchern schon nicht sicher, was man da überhaupt hat. Der Ausdruck ist aus einem anderen Buch.

Um aufs Thema zurück zu kommen, die Laufwerke zicken schon mal etwas. Manchmal helfen andere Disketten. Im Gebrauch ist ein Cardreader deutlich entspannter: https://petsd.net/ , die alte Hardware ist nicht optimal für dauerhafte Nutzung. Besonders die alten Mechaniken mit diesem Schneckenantrieb für den Stepper sind manchmal sehr unzuverlässig.

Ja, das funktioniert jetzt auch mit CBM Basic 1,2 und 4. Und der C64 inhaliert sowieso fast alles. Ich werde jetzt die Arduino-IDE wohl weiter verwenden: bequemer und leichter nachbaubar. Am Ende hätte ich gern einen Cardreader, Display und zwei Buttons. Also das Directory der SD-Card durchs LCD-Display scrollen und das angezeigte PRG kann dann per LOAD geladen werden.

Problem gelöst. Wenn in der Header an erster Stelle #$01 steht, dann lädt der CBM, mit #$03 konnte der nichts anfangen.

Quote from mantillo

Kann sein, dass wir da aneinander vorbei reden. Mit "Fastloader" meinte ich (auf CBM Tape Pi bezogen) die Wedge, die per LOAD (so, wie Du meinst?) initial geladen wird. Danach kann man dann vom Pi (eben per Wedge) schnell(-er) Daten laden und auch darauf speichern.

Ja, so, ein eigenes Protokoll etablieren und dann flotter die Bytes pollen.

Ich habe nun alles nochmals neu direkt in AVR-GCC geschrieben und es scheint fast zu klappen. Der Anschluss ist nun direkt mit Pullup wie beim C2N232 und die Software invertiert. Es ist fast zum Lachen, der C64 hat es sofort geladen. Beim CBM kommt es passend im Puffer an, auch zweimal und da fehlt wohl nur noch eine Kleinigkeit, die FOUND-Meldung blieb noch aus. Habe die Pulswerte nun per Timer0 umgesetzt und die sind wohl passend. Wurde so auch beim Tape Pi und TAP-Format verwendet. Kann man sich auch leicht ausrechnen.

Fehlt nur noch ein FOUND.

Quote from Ruudi

Das kann man ja wohl mit dem Oszi oder Logicanalyzer unterscheiden, d.h. mal an den IRQ hängen und auf ner 2. Leitung sich den Pegel am Eingang ansehen und eventuell sogar als Trigger für ne gewisse Nachlaufzeit verwenden. kommen da regelmäßig kurz drauf (mittlere Durchlaufzeit PIA) IRQs an, dann passt es in der HW, aber irgendwas am Protokoll ist anders, als von Empfängerseite-SW erwartet, wenn da kein Zusammenhang erkennbar ist, dann liegt es an der HW...

Ich werde es wohl zuerst mit einem Software-Patch versuchen. Sowohl Hardware als auch Protokoll sollten passend sein. Im ROM des CBM konnte ich nichts finden und der lädt auch problemlos eine Aufzeichnung vom C64.

Dieses "delayMicroseconds" der Arduino-IDE ist auch etwas wackelig, das schwankt sporadisch um 4µS. Da wäre es vielleicht auch angebracht, den Komfort der Arduino-IDE zu vergessen und alles direkt mit AVR-GCC umzusetzen.

Gestern hatte ich noch ein LCD-Display an den Arduino gehängt und die Laderoutine mit auf- und absteigenden Pegeln laufen lassen. Nichts, es rührt sich nichts beim CBM.

Quote from mantillo

BM Tape Pi simuliert ja nicht nur die Datassette. Das braucht man da nur, um den "Fastloader" ohne fremde Hilfe zu laden.

Braucht man das wirklich ? - Wenn man mit dem Standard-Load die Header und einen 192-Block lädt, kann man 191-361 Bytes für eigenes Programm belegen. Beim CBM hat man zusätzlich die komfortable Möglichkeit der internen 4kByte-ROMs. Da hat man gute Voraussetzungen für ein eigenes TWI, da die Daten vom µC sowieso in digitaler Form kommen und ein Fastloader im eigentlichen Sinne gar nicht mehr notwendig ist. Mir würde es gut gefallen, wenn es ohne ROM und nur mit LOAD klappen würde. Und vielleicht noch RUN hinterher, wenn die Vektoren das nicht anders hergeben.

Quote from Ruudi

Ich würde mal vermuten, das es weniger mit der Codierung zu tun hat, als denn mit analogen Dingen wie Pegeln, Flankensteilheit (auch zu viel davon kann negative Effekte haben!), d.h. schau Dir doch die Schaltpläne des Kassettenports DEINER C64-Version vergleichend mit dem zu deinem PET passenden an.

Eventuell liefert das ja bereits Hinweise darauf, warum es nicht funktioniert...

Auch an die unterschiedlichen INTERNEN Eingangsschaltungen von PIA, VIA und CIA denken und mit einbeziehen in diese Betrachtung!

125k-Sample "Oszi" würde übrigens für Datasette locker reichen

Ich habe zwei Board-Revisionen damit getestet, da funktionierte es gleich gut. Im Prinzip habe ich auch die zwei möglichen Ausgänge der Datasette/C2N nachgebildet. Einmal nur mit Schmitt-Trigger und zusätzlich noch mit N-FET+Pullup. Das ist eigentlich keine Raketentechnik mit den langsamen kHz-Signalen. Den flankengetriggerten Eingang des PIA hatte ich auch schon in Verdacht. Entweder zieht es dort unbemerkt vorbei oder es wird nach IRQ+Timer verworfen, weil es unpassend ist.

Dieses Mini-kHz Oszi funktioniert ganz gut, solange es keine schnellen Pegelwechsel gibt. Dann hat man das Gefühl, dass es den Signalen hinterher läuft. Aber was will man für kleines Geld erwarten ?

Quote from 1570

Ansonsten mal mit einem Emulator schauen, was die CBMs da genau wollen/produzieren, das lässt sich spätestens mit einem kleinen Patch für den Emulator-Code sicher schnell herausfinden.

Was die eigene Hardware angeht, würde ich für timingkritisches Zeugs den RP2040 empfehlen. Kost' nix, ist hinreichend schnell und erlaubt dank seiner PIOs nanosekundengenaues Timing ohne hässliches und ungenaues Delay-Gefrickel.

Dazu sollte so ein AVR eigentlich reichen. Habe auch noch einen flotten ARM da, finde es dafür aber etwas übertrieben. Um da etwas mit den Tape-Routinen zu machen, müsste ich erst mal das komplette ROM-Listing dokumentieren, um im Detail auch zu verstehen, wie das ablaufen muss. Ein Programm zum Lauschen an CA1 des PIA wäre ideal, das die Zeit zwischen den Pegel misst.

Quote from mantillo

Evtl. hilft Dir die Dokumentation und der Source Code von CBM Tape Pi weiter:

Beschreibung zum Commodore - Datassetten-Format.

Source Code der Emulation des Sendens an den Commodore im "normalen" Modus.

Danke, Tape Pi kannte ich noch nicht. Der Raspberry Pi hat ganz andere Torzeiten als ein Arduino. Ist schon eine gewaltige Rechenleistung um eine langsame Datasette zu emulieren.

Die Beschreibung des Format findet man auch hier: http://tech.guitarsite.de/datassette_enc.html und im C64-Wiki als deutsche Version.

Immer noch kein FOUND ... aber vielleicht komme ich noch drauf.