Nicht nur heute ... im Sommer bin ich seit zwei Jahren im "man cave", da muss Retro-Computing mal pausieren. Einen kleinen Geländewagen neu aufbauen, frisch lackieren und höher legen. So langsam komme ich auf die Zielgerade.

Die USB-Zuleitung eines alten Garmin-Navi für jemanden geflickt. Minus liegt bei dem sehr speziellen Stecker wohl auf der Schirmung, die kaum noch vorhanden war. Die letzten Pferdehaare mit der SMD-Pinzette aus dem Stecker gefummelt, verlötet und eine rudimentäre Zugentlastung aus Schrumpfschlauch mit Kabelbinder gebaut. Dann kann das alte Ding mit scheinbar plattem Akku noch ein bisschen verwendet werden.

Die originale Zuleitung für die Zigarettenanzünder-Steckdose ist unanständig teuer. Hatte 70-80€ bei diversen Anbietern gesehen.

Zitat von muffi

Was, die Dinger gibt es immer noch? Der schmale Taler wundert mich überhaupt nicht, an die Dinger habe ich ausschließlich negative Erinnerungen.

Ein gut klirrendes Ferro-Band reicht für die Datasette. Ist aus der Zeit.

Vor Jahren wurden noch billige C60-Bänder produziert und ohne Cover als eingeschweißte Stangen bei Ebay verkauft. Hatte damals auch noch eine davon gekauft. Wenn man aber auch heute noch sucht, findet man immer noch einige Ferro-Cassetten für den schmalen Taler: z.B. https://www.ebay.de/itm/144983222058 .

Cardreader ist doch viel bequemer.

Ja, danke, das bringt aber keine entscheidende Verbesserung mehr. Ich habe aus reiner Neugier eine 2Bit/CLK-Version getestet. Dann wird es so langsam unheimlich :), deutlich über 8KByte/s.

Das erste Bit wird vor der fallenden CLK-Flanke gesetzt und bei CLK:0 dann sogleich das zweite Bit, das noch bei steigender CLK-Flanke anliegt. Ob das so funktionieren kann, weiß ich allerdings nicht.

Zitat von rayden

Ich kenne den restlichen Code-Kontext jetzt nicht, aber wenn die PHA/PLA nicht timing-relevant für clock-toggle sein sollte, so könnte man ein paar cycles sparen, wenn stattdessen TAX/TXA oder TAY/TYA genutzt wird.

Und wofür ist das auf dem ersten PHA folgende AND#$DF? Denn kurz vorher erfolgt ja bereits ein AND#$0F - oder wird an diese Stelle von "irgendwo" hin gesprungen, sodass AND#$DF erforderlich ist?

Ja, genau, mit TAX spart man nochmals einige cycles, danke ! - Das erste "AND#$DF" kann natürlich auch weg. Der ganze Code war mal schnell getestet, da fehlte noch jegliche Optimierung. Damit liege ich jetzt schon etwas unter 0,2ms für ein Byte. Dann kann der Tapeport#2 am alten CBM 2001 jetzt auch mal um den Faktor x70-75 schneller.

Noch ein bisschen nächtliches Programmieren. Habe es jetzt auf 0,2ms pro Byte, dürften so rund 5Kbyte/s im Transfer sein. Das Byte wird in zwei Low-Nibble geteilt und danach auf Bit 3 des VIA heraus geshiftet. Also Shifting, Clock-Toggle, Shifting ... im Prinzip linearer Speedcode ohne Schleifen und Sprünge.

Erste Tests, den PET per eigenem TWI am Tape-Port#2 "sprechen" zu lassen.

Was Du suchst nennt sich Interface. Wenn Du einem Kind nur die Bewegungen vorführen möchtest, wird die Kosmos-Spielzeug-Version reichen. Da sind kleine Motoren drin, da müsste man dann nachschauen, wie die angesteuert werden.

Wenn es ein halbwegs brauchbarer Roboterarm werden soll, also eine ausreichende Wiederholungsgenauigkeit haben soll, würde ich lieber etwas mit Steppern empfehlen. Nema17 mit ansteuerbaren H-Brücken sind billig zu haben und es gibt scheinbar Bausätze für den 3D-Drucker. Das wird dann nicht ganz so armselig:

Zitat von JeeK

Ach so. Über SCL (Clock) hat man ja eigentlich eh immer eine Referenz für eine fallende Flanke. Die pegelabhängige Start- oder Endebedindung könnte aber schwierig zu erkennen sein. Aber man kann das mit einer Sync-Sequenz initiieren, z.B. 9 1-Bits heißen Start der Verbindung, dann folgen 8 Daten-Bits und ein 0-Bit. Dann braucht man keine Start-/Stop-Bedingung für ein Byte mehr. Ich würde dann die Übertragung dennoch mit einer Prüfsumme absichern (z.B. die 1-Bits zählen, oder die Bytes in 16 Bits aufsummieren).

Ok, das ist dann eine Programmierungssache, wie man das dann ins BASIC einbettet. Da kann man sich auch an SuperTape orientieren. Gerne PM an mich oder wir machen einen separaten Thread auf, wo es dann um dieses Projekt geht.

Ich habe jetzt erst mal etwas nach einer weiteren Ausgangsleitung geforscht. Mit CB1 (nur Eingang am VIA) konnte es nur in eine Richtung klappen. Ich lege nun die Clock auf PA5 des PIA#1 und die bidirektionale Datenleitung wird PB3 des VIA#1. Da musste ich erst mal ein Setup finden, ohne den Tastatur-Scanner lahm zu legen. Mit dem PIA 6520 hatte ich noch nie etwas gemacht und musste mich erst mal etwas einlesen. Das Buch ist wirklich gut: http://vtda.org/books/Electron…ationsBook_RodneyZaks.pdf

Zum Tape-Loader: Das habe ich wieder verworfen. Es ist viel einfacher, einen der freien ROM-Steckplätze zu verwenden, z.B. 4K ab $9000. Ansonsten hätte man das Tape Standard-Protokoll in den Arduino implementieren müssen, also Bytes ins übliche Frequenzpiepen per Timer umwandeln.

So klappt das Setup für den PIA ganz gut.

Tastatur-Scanner funktioniert danach noch und der Port lässt sich toggeln.

Von Eingang High auf Ausgang Low. Und wie es immer ist: mein anderer Logiktester ist mal wieder defekt, hatte glücklicherweise einen Ersatz.

Hier sind auch einige: http://www.cbmhardware.de/cbmgames/

Zitat von JeeK

Ist das Übertragungsprotokoll vorgegeben oder steht da noch eines zur Auswahl?

Ich hatte ein ein vereinfachtes und angepasstes TWI gedacht. Ohne ACK/NACK-Bit oder Clock-Stretching, da der alte PET einen AVR nicht in Bedrängnis bringen kann. Das erste Byte soll dem Adapter dann mitteilen was gemacht werden soll, also 7 Bit sind für den Befehl frei und Bit 8 für R/W.

Besonders schön wäre es natürlich, wenn man etwas per LOAD"*",2 aus dem Adapter heraus laden kann, wie es schon für den C64 gemacht wurde. Da habe ich aber leider absolut keine Erfahrung.

Teslanol T6-Oszillin ist auch sehr gut zum Reinigen und Pflegen von Kontakten.

Noch ein bisschen am "two wire"-Interface für den CBM 2001 an Tape#2 programmieren. CB1 am CBM macht(e) doch etwas Probleme. Der Eingang ist auf High und wenn ein Pegelwechsel auf Low stattfindet, ist Bit4 im IFR des 6522 gesetzt. Theoretisch, mit einem einfachen Pegelwechsel war es nicht getan. Jetzt ziehe ich auf Low und danach wird der Arduino auf Eingang (High-Z) umgeschaltet, damit scheint der CBM den Pegelwechsel zuverlässig zu erkennen.

Ziel des Ganzen ist eine USB-Verbindung vom PC zum CBM für CrossDev. Vom PC soll ein PRG möglichst mit Linux cat oder einem Standard RS232-Terminal mit hoher Baudrate übertragen werden. Das wird dann vom Arduino im FRAM gespeichert, zusätzlich werden noch Pointer und die Größe berechnet. Dann ist FRAM=true und der CBM kann es per two-wire mit dem Tapeport #2 abholen.

Eigentlich gestern, aber ich mache gleich noch weiter. Adafruit SPI FRAM mit den passenden Libs und Test. Sehr interessanter Speicher, nutzbar wie SRAM, aber nicht flüchtig.

Zitat von skern

Was muss so ein IEC Device ( Slave ) können?

Es hat eine Devicenummer und kann mit dem Bus umgehen.

Muss er auf eine Anfrage vom Master antworten und wenn ja was?

Welche Grundfunkionengen benötigt so ein Messgerät, Drücker, Teleskop, Oszilloskop, Giesmaschiene Scanner und was weiß ich noch....

Ist das nicht IEC-625, also GPIB oder IEEE488 ? - Wolltest Du das oder die serielle Version (1541, etc.) ?

Kannst Du es später in ein GIT packen ?

Noch kurz den MCP23S17 Source für den Commodore Plus/4 Userport zumindest zum Schreiben auf den Adapter fertig gemacht. Lesen ist auch drin, muss dann nur verwendet werden.

https://github.com/cbmuser/plus-4-mcp23s17-spi

Geht natürlich genau so mit jedem anderen I/O per Software Bit-Banging.

Facepainter war ganz nett zur damaligen Zeit, heute haben wir aber schon bessere Möglichkeiten. Zum Testen kann man sich schnell eine Koala KLA-Datei hier konvertieren: https://www.micheldebree.nl/retropixels/ , optimal wäre wohl vorher GIMP, um Palette und Größe anzupassen.

Mir gefällt besonders unter Linux Multipaint: http://multipaint.kameli.net/ , bei CSDB: https://csdb.dk/release/?id=229652 , damit geht schon einiges.

Klappt es denn nun mit Facepainter und der Anleitung aus der Tigerdisk ?

Wie Diddl schon schrieb, Kernal oder Basic zaubert man nicht mal so eben aus dem Hut. Dazu gehören sehr umfangreiche Grundlagen und Wissen zum technischen Aufbau des Ganzen.

Eine Basic-Erweiterung für den C64 über Vektoren wäre ein Anfang. Diese kleine Erweiterung: https://cl1p.net/bblaster schrieb ich für dieses Cartridge: http://cbmhardware.de/show.php…r%20Commdore%2064%20(GPIO) , unten SPI-Basic.

Das könntest Du als Grundlage zum Erforschen einer solchen Erweiterung nutzen.

Wenn die Floppy es durch den Reset schafft und scheinbar "idle" dasteht, würde ich beim Bus anfangen.

http://www.zimmers.net/anonftp…ves/old/2031/page-12r.gif

Die beiden Treiber 75160/75161 gelten in der Regel als robust. Daher würde ich zuerst prüfen, ob es einen Pegelwechsel bei NDAC und NRFD beim Zugriffsversuch gibt. Wenn es da festliegt, könnte der 7406-Treiber defekt sein. Wenn z.B. NRFD (not ready for data) auf high festliegt, wird der CBM nicht senden. Das sollte sich mit einem Logiktester feststellen lassen.

http://www.zimmers.net/anonftp…ives/old/2031/page-28.gif