Messy Code in eine C2N-Klasse für den µC: https://github.com/cbmuser/c2net/blob/main/c2n.h mit hoffentlich verständlicher Info.
Posts by cbmhardware
-
-
Vor einiger Zeit entdeckte ich den Raspberry Pi Pico W und in mir keimte die Idee, damit per Wifi meine CrossDev Dateien zu senden. Als Programmier-Plattform diente die Arduino-IDE, die den schönen Vorteil hat , dass man auf eine große Auswahl verwendbarer Libs zurückgreifen kann.
Das Ergebnis ist nun im meinem GIT: https://github.com/cbmuser/c2net Die Software ist im Moment etwas mehr als ein "proof of concept" und unterstützt nur Standard LOAD.
Um diesen Adapter so nachzubilden, braucht man ein paar low-cost Komponenten, einen C2N-Stecker und natürlich seine WLAN Zugangsdaten. Die werden in das Programm des Pi Pico kompiliert, was einerseits sicherer ist, aber auch das Verscherbeln auf Ebay unmöglich macht. Dazu müsste man die dann wieder auslagern.
Zur Arduino-IDE wird ein Zusatz benötigt, damit man den Pico dort verwenden kann: https://github.com/earlephilhower/arduino-pico . Das ist schnell integriert, dann fehlen nur noch ein paar Libs aus dem Arduino-Fundus, danach kann der Quelltext kompiliert werden.
Im Bild sieht man den Aufbau auf meinem schon wieder staubigen Steckboard. Die Taster von rechts nach links: Reset, Umschalten von Wifi auf Cardreader, Auswahl vom Cardreader. Der Pico Pi arbeitet mit 3.3V I/Os, deshalb muss ein Levelshifter dazwischen, damit das CBM TTL 5V nicht die Ports zerstört. Die Motor-Leitung benötigt einen Spannungsteiler vor dem Levelshifter, dieser besteht aus zwei 1K-Widerständen.
Allein das I2C-Display kann direkt angeschlossen werden, obwohl es mit 5V betrieben wird, da nur Schreibzugriffe auf den I2C-Adapter ausgeführt werden. Hinter dem Display ist einer dieser PC8574-Adapter aufgelötet. Die Adresse muss ggf. im Source auch angepasst werden, meist ist es 0x27, bei mir war es 0x3F. Auf dem Foto erkennt man, dass die Software bei ASCII ->PETSCII nur "A-Z" passend konvertert, da wollte ich heute noch ran.
Den Aufbau kann man gestalten wie man lustig ist: "wild wired" , Lochraster oder selbst eine Trägerplatine entwerfen.
Der Cardreader wird (je nach Kauf) bei mir mit 3.3V betrieben. Die Speicherkarte hat im Moment nur die Aufgabe gesendete Dateien zu sichern. Da gehen bei der aktuellen Version keine Unterverzeichnisse und es befindet sich immer eine Datei namens "DIR" auf der Karte. Diese Datei wird nach jedem Transfer aktualisiert und ist der temporäre Speicher für den Server, der diese nach Aufruf ausgibt.
Der Transfer vom PC
Dazu wird "curl" verwendet: https://curl.se/ und es kann nur in Richtung Adapter gesendet werden. Wenn ein Dateiname schon vorhanden ist, wird dieser beim erneuten Senden überschrieben ! - Das habe ich so belassen, damit ich meine CrossDev-Experiment immer wieder nach Neukompilieren überschreibe.
curl 192.168.2.105 listet den Inhalt der Speicherkarte auf, das geht natürlich auch im Browser.
curl -T programm.prg 192.168.2.105 sendet die Datei programm.prg und schreibt oder überschreibt diese auf der SD-Card.
Die Speicherkarte
Die Speicherkarte dient im Moment als billiger Massenspeicher. Ich hatte erst über FRAM oder EEPROM nachgedacht, letztlich ist die SD-Card einfacher. Man kann das Filesystem nutzen und bei Defekt eine andere, alte Karte verwenden.
Die Cardreader-Funktion
Die ist noch sehr rudimentär. Man kann mit einem Button auf den Cardreader umschalten. Dann erscheint "DATASETTE" im Display und es kann mit einem weiteren Button durchs Verzeichnis gescrollt werden. Wenn man die passende Datei gefunden hat, schaltet man über den ersten Taster wieder um, es erscheint "C2Net active !" und der gewählte Dateinamen in der zweiten Zeile. Jetzt kann die Datei mit LOAD in den Commodore-Computer geladen werden. Beim CBM kann man einfach nur warten, beim C64 muss die "C="-Taste gedrückt werden, bis ein kurzes "Found" aufblinkt.
Zukunftsgedanken
Für den Pi Pico ist das alles natürlich nur eine Kleinigkeit und da geht viel mehr. Speichern vom CBM, ein TAP-Player, Fastloader oder TWI. Mal sehen ...
-
Tape-Transfer korrigiert ... läuft nun auch mit dem C64.
-
Es geht um diese Seite: https://www.c64-wiki.de/wiki/A…ungsformat_der_Datassette
Ich hatte mich in jüngster Vergangenheit etwas mit dem Tape-Format beschäftigt und bin da zwangsläufig auf Ungereimtheiten in den verschiedenen Beschreibungen gestoßen.
Vorab: bei den CBMs gibt es z.B. nur Header-Typ: $01, $04 und $05. Aber es geht um den C64.
Typ $01 und $03 springen auf die gleiche Adresse im ROM, $02 gibt es scheinbar gar nicht und der Rest sollte stimmen.
Dieses bunte Schema ist sehr irreführend. Das könnte beim Laden oder Speichern mit Open/Close funktionieren, das kann ich nicht sagen. Ich habe mich speziell mit dem Laden von Tape beschäftigt und dazu ist es unpassend.
Beim Laden einer Datei wird immer das ganze Programm mit Countdown 89...81 in den Speicher geladen, dann kommen 80x Short und es wird nach dem 9..1 Countdown nochmals wiederholt. Danach braucht es nur noch wenige Short-Signale und das Laden ist beendet.
Im Detail am Rechner gemessen und vom µC gesehen
:
Header wie im Wiki beschrieben ... 2s Short (letzte Flanke auf Low ziehen), ... Motor-Gap ca. 340-360 ms, 2s Short
Countdown 89...81, alle Bytes schreiben und XOR Checksumme erstellen, Checksumme schreiben, 1x Long,
60 oder 80x Short,
Countdown 09...01, alle Bytes nochmals schreiben und XOR Checksumme erstellen, Checksumme schreiben, 1x Long
... zuletzt fehlen noch Short-Pulse, bei einer echten Datasette 80, im digitalen Transfer vom µC reichen 2-5, dann ist das Laden beendet. In den originalen ROM-Routinen sind reichlich Short-Signale, wenn der Rechner das auswerten muss. Bei einer Abtastung sieht man auch sehr gut, warum das so ist. Da klappert das Signal der Motorleitung schon ein paar mal hoch und runter, bis es dann letztendlich passt.
Laden von Datasette:
Ist vielleicht noch etwas für eine CBM-Seite ?
Gemessene Pegel mit dem CBM2001N:
Short: 2793 kHz
Medium: 1984 kHz
Long: 1488 kHz
Die funktionieren auch mit dem C64, liegen auch nicht so weit auseinander.
Edit: könnte jemand das Thema "Redaktionelle Vorschläge zu Aufzeichnungsformat der Datassette" korrigieren: komme da nicht mehr ran ?
-
ChatGPT ist ganz brauchbar bei WEB-basierten Anwendungen, den Rest sollte man als Ideen werten. Bei 6502-ASM kommt da nur Grütze raus. Ich hatte mich vor vielen Jahren mit dem GeoRAM beschäftigt, da entstand auch der Test.
Hier sind ein auch ein paar Quelltexte dazu: http://www.cbmhardware.de/show.php?r=1&id=4
Wenn man eine Datei öffnet, immer einen Sektor abholt, kann man das da recht einfach hineinschreiben, da immer genau 256Byte eingeblendet werden. Muss man nur Page und Sektor passend schalten.
-
Vorgestern, eine kleine C2N-Lib für die Arduino IDE mit dem Raspberry Pi Pico W nach ausgiebigen Recherchen. Endlich sauberes Timing bei gesperrtem IRQ und Auswerten der Hardware-Timer.
0x02 , da war allerdings der Marker noch nicht passend drin.
Eine statische Header und PRG aus dem Pico im Pet 2001N mit Basic 4 geladen. Jetzt muss das noch mit meinem Wifi-Adapter zusammengeführt werden.
-
Gibt es neben den Bereichen (z.B. a13 - A15) auch eine Leitung die die Größe angibt?
Die höchste Adressleitung bestimmt immer die Größe wie kinzi schon schrieb.
Code- Bank 2:
- 8 4 2 1 8 4 2 1 8 4 2 1 8 4 2 1
- A15 A14 A13 A12 A11 A10 A9 A8 A7 A6 A5 A4 A3 A2 A1 A0
- 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 = $8000
- So kann man es rechnen:
- Bank 3:
- 8 4 2 1 8 4 2 1 8 4 2 1 8 4 2 1
- A15 A14 A13 A12 A11 A10 A9 A8 A7 A6 A5 A4 A3 A2 A1 A0
- 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 = $c000
- x4096 (+) x256 (+) x16 (+) x1
- 64 32 16 8 4 2 1 KiloByte
- Banking
- -------
- A15 = 0 : $0000 -> A14 = 0: $0000
- = 0 : $0000 -> A14 = 1: $4000 #16384
- = 1 $8000 -> A14 = 0: $8000
- = 1 : $8000 dez. #32768 -> A14 = 1: $c000 #49152
- Zwei Bit = 4 Bänke
- A15 A14
- 0 0 : Bank 0
- 0 1 : Bank 1
- 1 0 : Bank 2
- 1 1 : Bank 3
Das sind die Grundlagen der Digitaltechnik.
-
QuoteIch habe meinen kleinen Selbstbau-Platinenbelichter zum Löschen verwendet. Dieser entstand vor einigen Jahren aus einer Tee-Vorratsdose und einer Menge UV-Leds. Wenn das Fenster des Eprom verschmutzt ist, lässt es sich leicht mit Isopropanol für den Löschvorgang reinigen.
Nur mal so interessehalber: Das mit den UV-LEDs funktioniert? Haben die nicht die falsche Wellenlänge? Wie lange sind die Löschzeiten?
Puh, das ist weit über 10 Jahre her. Ich kann mich dunkel daran erinnern, dass es mit sehr langer Löschzeit klappte. Die lagen zwischendurch da immer drauf, könnten durchaus 30 Minuten+ gewesen sein.
Was mir noch nicht ganz klar ist: im Longboard sind es 8kb Bereiche zwischen denen ich umschalte, im C64C werden es 16kb Blöcke sein.
Bei den alten C64-Boards sind Kernal und Basic zwei separate 8kB-ROMs, beim späteren C64-2 oder C wurde das zu einem 16kB-ROM zusammen gefasst.
-
Hatte mich im letzten Beitrag schon selbst verhaspelt.
Hier ist eine alte Seite für den C64-2: 2 Kernal mit Umschalter.
-
Das ist recht einfach. Bei einem 8 Kilobyte ROM steht eine 64 und bei 16 eine 128. Man muss nur die Zahl hinter der 23 oder 27 durch 8 (Bit) teilen.
Also 4 Kernal a 8 Kilobyte sind dann 64 * 4 = 27C256 oder bei 4 x 16 KiloByte = 27C512. Dazu braucht man dann allerdings Adapter für das Banking, da die ROMs über die oberen Adressleitungen und Schalter geteilt werden.
-
Ein bisschen Stecken und Programmieren ... "Datasette" mit Cardreader und WLAN.
Mit curl können Dateien per WLAN übers Hausnetz bequem zum Adapter versendet werden. Diese werden dann auf auf SD-Card gespeichert. Zudem kann man kann das Directory mit Curl $ip oder im Browser einsehen.
Nach dem Upload ist die aktuelle Datei auch im Puffer und kann (hoffentlich bald) direkt vom Zielrechner per Datasettenverbindung mit Kernal-Load geladen werden.
Mit einem Button (in der Mitte) kann zum Cardreader umgeschaltet und irgendeine Datei für "LOAD" ausgewählt werden (Taster unten, oben ist Reset). Es kann natürlich auch jede mit dem PC beschriebene Speicherkarte verwendet werden.
Fehlt noch die Verbindung zum CBM ...
-
einfach ein PRG per lokalem WLAN zum C=-Zielrechner zu transportieren
Teilweise gibt es so etwas schon, z.B. mit dem ESP32 Dev Board. Das soll Dich aber nicht davon abhalten ...
Ja, es gibt viele, viele gute Lösungen für den IEC-Bus, den hat der CBM 2001N leider nicht. Der Pico W könnte das sogar noch mit seinen vielen I/Os und der hohen Rechenleistung auf DMA optimieren. Ich suche aber die Lösung für den CBM.
Meine Idee ist im Moment, ein eingegangenes PRG auf SD-Card direkt ins C2N-Format in ein Array umwandeln, damit der Pico das dann nach LOAD vom CBM heraus piepsen kann. Wäre auch eine schöne Lösung für die Basic 1 Rechner der ersten Generation mit dem Bug im ROM. Die können gar kein Disklaufwerk verwenden.
-
Gestern Abend/Nacht ein bisschen auf dem Steckboard mit dem Raspberry Pico W. Hatte schon länger die Idee, CrossDev oder einfach ein PRG per lokalem WLAN zum C=-Zielrechner zu transportieren. Der Pico W ist von der Größe nicht unpassend und braucht keine komplette Distro. Das funktioniert schon mal mit SD-Card als Zwischenspeicher.
Beim C64 könnte man mit 74LV245 und ein paar Bit auf anderen Level-Shiftern sicher etwas mit direkten Speicherzugriff auf Cartridge bauen. Vielleicht kann man auch das SD2IEC mit WLAN-Zugriff erweitern.
Ich suche aber eine Lösung für die CBMs oder später auch für den Plus/4. Muss mich wohl für C2N oder IEEE488 entscheiden.
-
Ich warte noch mit dem Speicher, ist sicher nicht schlecht, aber dann ist man schnell bei 10 Jahren, bis man da wirklich profitiert.
Etwas anderes: Im Moment sterben die Holley Zweirichtungszähler wie die Fliegen. Man liest von Überlastung der Netzbetreiber und die Meldungen ziehen sich von Nord bis Süd. Mit der Zeit werden die wohl alle ausfallen und danach hat man den Ärger. Habe heute gemerkt, dass meiner auch nichts mehr anzeigt.
Wenn jemand diesen Zähler verwendet, wäre es sicher keine schlechte Idee, regelmäßig ein Foto des Zählerstands zu machen. Dauert wohl um die drei Monate (Westnetz bei uns) bis da etwas ausgetauscht wird.
-
Ich schaue mal, wo die Sources sein könnten. Wenn ich mich richtig erinnere, war das auch nur für Basic 2(aka 3) und 4.
-
"O'zapft is!" ... wird ein Solar-Datenlogger für den Raspberry Zero 2 W mit Hilfe von PHP und diesem Script: https://github.com/turbopixel/deye-inverter-status . Auf die Speicherkarte kommen dann Apache, mariaDB, PHPmydAdmin, php8.3 und der restliche Kram aus dem git. Die Verbindung geht direkt an den Access-Point eines Deye-Inverter und per CronJob wird dann in eine mySQL-Tabelle geschrieben. Sehr wahrscheinlich im 10 Minuten-Intervall, weil das sowieso ein eher träges System ist.
Der Datenlogger läuft, habe nur noch keinen Raspberry Zero da. Danach mache ich mir dann Gedanken, wie man die gesammelten Daten visualisiert.
Peak waren es heute 691 Watt. Bin schon auf einen ganzen Tag gespannt.
-
Wenn der schon getauscht wurde, bleibt immer noch Bit5. Wenn da alles sauber eingelötet wurde, sollte man den VIA ausschließen können. Und das könnte ein Treiber dahinter sein. Hatte ich bisher noch nie, aber möglich ist alles.
-
Öhhhmmm... Was ist denn da die Steuerleitung ?
NRFD_IN / NRFD_OUT ?
Sind beide "Not Ready For Data: NRFD", die wurden nur auf jeweils einen Port gelegt, jeweils IN und OUT. Wenn man den 6522 austauscht, könnte sich etwas verändern.
-
Könnte die Steuerleitung NRFD am 6522 VIA sein: http://www.zimmers.net/anonftp…s/pet/8032/8032029-03.gif
-
Ich habe es heute mal genau beobachtet, ob da auch wirklich etwas aus dem Relais heraus kommt. Die Sonne hat nicht mehr die Leistung wie Ende Juni, Anfang Juli, aber das funktioniert:
300 Watt/h sind stehengeblieben, scheint ein Fehler in der Firmware zu sein, heute kamen also 3,3kWh rein. In der Spitze waren es gut 650 Watt, der Zählerstand hat sich nicht verändert und auf der Eingangseite wurden 2kWh gutgeschrieben. Das Relais ist bei den aktuellen Anlagen wohl schon passend eingetragen und man muss es nur "plug&play" anschließen. Dann fehlt nur noch ordentlich Sonne und möglichst ein moderner Zweirichtungszähler.