Ich hatte jetzt auch einen Fehler drin: #$40 ist Bit6, also verwendet der Plus/4 doch Ack. Da konnte ich keine passende Einstellung des Datenrichtungsregisters finden. Auch eine Möglichkeit: der Sender verwendet immer Ack und der Empfänger dann DAV. Und dazu dann noch dieses #$00 Pingpong.
Das ist wirklich ein übles Kraut ... 
Die Darstellung des Protokolls auf der Webseite stimmt so leider doch nicht. Im P/4-Romlisting findet man ab $f322 die Konfiguration für die Datenrichtungsregister $fec5 und $fef5: #$40 also Bit 6: Data Valid auf Ausgang. Damit hat man dann schon mal sichergestellt, dass der Plus/4 zweifelsfrei immer DAV verwendet.
Idle = DAV:1 und ACK:1
Die Leseroutine des Plus/4:
Das sieht doch etwas anders aus:Datenbyte $84, DAV= 0, warten auf ACK=0 , Status != sichern, Byte abholen, DAV=1. warten auf ACK=1
Datenbyte $00 , DAV = 0
$E21D: warte auf ACK= 1, DAV= 1
Also DAV wird vor ACK low und mit den Statusbytes bin ich noch unsicher, ob die überhaupt eine Einfluss beim fehlerfreien Ablauf haben.
So sieht der Analyzer das auch.
Da muss man sich aber auch wirklich durcharbeiten. Noch nie so ein umständliches und blödsinniges Protokoll gesehen. Da kann es auch nicht ausbleiben, dass die mit parallelem Anschluss so langsam ist.
Nach langer Zeit mal ein bisschen IK+ bis zum braunen Gürtel. Danach habe ich aufs Maul bekommen.
Habe es selbst gefunden:https://www.pagetable.com/?p=1324
Das hat sich doch schon jemand angetan. Lol, mein letztes Thema steht sogar in den Referenzen. Gut dass es geholfen hat.
Ich arbeite mich im Moment mal wieder durch verschiedene ROM-Listings des Plus/4 und der 1551 Floppy. Die P/4 ROM-Listings haben eine Gemeinsamkeit: die Bereiche mit den Low-Level-Routinen für den Zugriff auf den T-CBM-Bus sind überall nicht kommentiert. Da hatte ich vor Jahren dann aufgegeben, diesmal nicht, noch nicht.
Ich habe da einen wagen Verdacht:
Falls es zu Muß skaliert wird: http://www.cbmhardware.de/temp/p4_romlisting.jpg
Das stammt aus dem Commodore Sachbuch als PDF. Die Beschaltung der Ports wurde wohl in die IEC-Bus Routinen eingefügt. Wenn Bit7=1 ist, wird die Floppy aktiv. Bit 0-2 sind dann der Jobcode, damit die 1551 gleich weiss, was der P/4 möchte.
Aus einem 1551-Romlisting:
Wie es für mich aussieht wird da für die erste Kommunikation nur "ACK" verwendet und "DAV: Data valid" wahrscheinlich später für das Datenbyte auf dem Bus. Da wird man sich mühsam und parallel durch beide ROM-Lsitings, Schritt für Schritt durcharbeiten müssen ?
Oder gibt es mittlerweile eine fertige Aufschlüsselung für dieses Protokoll ?
Noch ein bash-script für Linuxer:
TAPClean und aplay für C64
Aus dem Jahre 2018 .... Die Audiosette ist eine kleine Platine zum Laden von Programmen aus einer Audioquelle über den Tapeport. Ich verwende konvertierte TAPs, die temporär im WAV-Format gespeichert, um dann abgespielt zu werden. Solche Adapter gab es auch in der Vergangenheit schon. Hierbei handelt es sich aber nicht um den Pfusch mit dem CMOS Inverter, der so oft kopiert wurde. Bei der alten Version muss man möglichst laut auf einer Seite hinein brüllen, damit auf der anderen Seite noch etwas heraus kommt. Ursprünglich war diese Version wohl für den hohen Pegel eines CD-Players entstanden.
Die Audiosette verwendet einen LM324 Operationsverstärker zum Anheben des Pegels und als Komparator. So kann auch eine Audioquelle mit moderater Pegelstärke verwendet werden.
Die Schaltung ist möglichst einfach gehalten und soll die grundlegenden Eigenschaften der Datasette bieten: Pegel anheben und eckiger machen. Das kann sich jeder mit bedrahteten Bauteilen leicht nachbauen, ich hatte mich aber für SMD entschieden.
Zum Konvertieren: TAP->WAV kann man Ubercassette oder TAPClean verwenden. Das Abspielen übernimmt bei mir unter Linux aplay, das geht natürlich auch mit anderen Programmen wie Audacity.
Für den C64 werden das sicherlich nur wenige benutzen wollen, da es schon mannigfaltige Möglichkeiten gibt ein Programm zu laden. Es funktioniert natürlich mit jedem Commodore-Rechner der einen Tape-Port hat. Beim C16 oder Plus/4 braucht man den passenden Mini-DIN-Stecker. Auch bei den CBM-Rechnern funktioniert Laden und Speichern, allerdings musste ich zuletzt Tape#1 verwenden. Hatte nicht nachgeforscht, ob es am Rechner lag oder ob Tape#2 irgend eine kleine Eigenheit hat.
Der Anschluss für Load und Save. Dafür gibt es mittlerweile eine gewinkelte Buchse mit Stecker.
Wenn jemand so eine Platine gebrauchen kann: ich habe noch einige da, bei den Zuleitungen könnte es aber eng werden. Löte das Vogelfutter dann drauf und teste es kurz.
Links:
TAPClean: https://sourceforge.net/projects/tapclean/
Ubercassette: http://www.retroreview.com/iang/UberCassette/
Meine immer noch nicht fertige Seite dazu http://www.cbmhardware.de/show.php?r=10&id=23
Hatte eben mit Debian 10 zwei kleine Warnungen, kompilierte ansonsten geschmeidig durch.
gcc version 8.3.0 (Debian 8.3.0-6)
Ist vielleicht wissenswert für die nächste Version.
Display More
Panasonic läuft, Samsung nicht. Das 80 Zeichen Bild ist wirklich Granate, bei der 40 Zeichen Darstellung sind doch noch einige Streifen drin.
HEY ...
dein 40 Zeichen Bild sieht besser als bei mir aus.
Dan ist das echt sehr SCART Geräte-Abhängig.
wie cbmhardware und ich auch schon erwähnt habe ist das mit der 80 Zeichen Geschichte ein CLONE der CGA2RGB Platine von GGlabs.
Ich habe den auf der Homepage verlinkten Schaltplan genommen und das mit dem ATF16V8 PLD selber hin bekommen.Dass es aber bei vielen SCART Geräten zu Problemen kommt war mir wie schon erwähnt nicht so bewusst.
Ich vermute dass es zwei Scart-Versionen gibt. Ich habe hier für die Homecomputer auch einen kleineren Samsung, der per SCART S-Video kann. Wenn man mal eine Runde googelt: Pin 15 (Chroma) und 19 (Luma). Beim RGB sind Pin15 ( Red) und Pin19 (Comp/Sync).
Ob das am Hersteller festzumachen ist, was da geht ? - Könnte man vielleicht in der Anleitung finden, wenn die so etwas heute noch hergibt.
Dann kann ich an meinem kleinen Samsung einen Adapter auf RGB auch wohl vergessen.
was hast du alles daheim rumliegen????
So ein AD724 RGB auf Video Converter IC kostet 16€ pro Stück ... Uiuiuiuiui
OK ... bei ALIEXPRESS wird es billiger ... aber ob das besser ist????
Da muss ich mir überlegen ob ich mir so ein Teil zum Prototypen zulegen werde.
Ich muss mich korrigieren, habe AD725 da. Die AD724/725 bekommt man beim Chinesen je nach Menge zwischen 0,8-1,8€ . Hatte die bei Ebay mit langer Wartezeit gekauft, dann wird es nicht allzu ruinös.
Habe im Moment etwas mehr Zeit, da kann ich mal einen Prototyp aufbauen. Muss nur ein paar Tantals und einen Quarz-Oszillator bestellen. Schicke es dann mal durch den AD725 auf S-Video und werde berichten ob es brauchbar ist.
cbmhardware
Ich kann dir Mal meinen Schaltplan schicken falls du willst. Kannst Mal drüber schauen.
Die RGBI-Aufbereitung hatte ich schon im Schaltplan von GGLabs gefunden. Beim Videoport -> SHVS wird das Signal scheinbar gedämpft, was wohl beim Modulatorersatz zu Problemen führt ?
Da würde mich doch interessieren, ob das Problem mit einer Brücke gelöst werden kann.
Bei mir liegen auch schon seit Jahren ein paar AD724 herum. Ich hätte RGBI->Analog->AD724 auf SHVS gebaut, ähnlich wie es auch für den Amiga gemacht wird. Also beide Signale auf SHVS und mit 4066 umschaltbar. Keine Ahnung ob das gut funktionieren würde. Ist auch alles immer vom verbauten A/D-Wandler im Fernseher abhängig, dessen Anforderungen man nicht kennen kann.
Die Frage ist schon mal, wo beim CBM-Bus mit seinen Pullups nach Vcc und damit einer automatischen Strombegrenzung auf ein paar mA das "Durchlegieren" überhaupt herkommen soll? Der Ausgangstransistor des 7406/7 kommt gar nie in Verlegenheit "zu legieren".
Ich bin sehr für konservatives Schaltungsdesign und gegen "auf Kante nähen", aber das ist einfach nur an den Haaren herbei gezogen.
Jeder Leiter ist auch immer induktiv und man kennt das Kabelrupfen beim eingeschalteten Gerät. Da können ordentliche Spitzen entstehen, abgesehen davon kann ein altes Bauteil auch durch Korrosion im Sockel, kalte Lötstelle oder einfach ohne erkennbaren Grund durchlegieren. Man könnte seitenweise darüber referieren, wie das bekannte Problem der festgelegten Leitungen beim Defekt am IEC-Bus entsteht.
Wenn man sich dann dahinter ein Rapberry mit empfindlichen I/Os oder ein AVR mit 3.3V-Versorgung befindet, hat man durch die Fahrlässigkeit einen ärgerlichen Defekt. Das ist nicht bei den Haaren herbei gezogen, das ist wirklich sehr triviales Grundwissen.
Das ist kein "Hack", das ist Verwendung des Bauteils, wie es gedacht ist (Open Collector). Das gleiche Argument könntest du bei einem 7406/7407 am Userport als Buffer bringen, und diese Schaltung wurde dutzendfach verwendet.. Diese Gefahr bannst du nur, wenn du Optokoppler oder Relais einsetzt, dann hast du völlige Trennung der Kreise.
Man kann solche Risiken durch das Design ausschalten. Wenn man beim SD2IEC den BUS und AVR mit TTL-Pegel (5V VCC) betreibt, hat man das Risiko der Defekte in Kette schon ausgeschaltet. im Ausgangspost wurde alles richtig gemacht.
Natürlich sollte man I/O am Userport immer per Optokoppler trennen, wenn man z.B. Lasten damit schalten möchte. Was da früher gebaut wurde, sollte man wirklich nicht als Referenz verwenden. Und wenn sich zwei TTL-Pegel gegenüberstehen, kann man mit dem Treiber auch mal Pech haben, aber meist legt der beim Defekt nur etwas fest.
Es ist beim Schaltungsdesign nicht nur die Frage: geht das so. Man sollte auch bedenken wie sich Bauteile verhalten können und was im "worst case" passieren kann.
Es funktioniert prma. Keine Ahnung, warum alles mit diesen Fet-Level-Shiftern herumeiert.
Solche Hacks funktionieren oft, haben aber auch immer ein Restrisiko. Wenn der Treiber mal irgendwo voll durchlegiert, was nicht so unüblich ist, dann kann man sich von den 3.3V-Bauteilen dahinter verabschieden.
Dann lernt man spontan warum so etwas in einem guten Design nichts verloren hat.
Dieses RGBI des C128 ist nicht so einfach umzusetzen. Kannst Du mir so ein Ding verkaufen und zusenden ? - Habe vier Flachbild-Fernseher zum Testen da. Müsste dann nur mal schauen, ob noch ein lebendiger C128 aufzufinden ist.
Auch wenn das eine Einschaltmeldung bringt, könnte es bei einigen Programmen wieder zu Problemen kommen. Der VDC ist in gewissem Maß konfigurierbar, wie es gern bei Demos verwendet wird. Da könnte die A/D-Wandlung dann wieder kollabieren.
Achso, ich dachte der soll mit 3.3V VCC betrieben werden. Bei der langsamen Geschwindigkeit könnte es noch funktionieren, ist dann halt ein Experiment, ob der noch schnell genug aufmacht.
Display More
Mit den üblichen Typen wird das nicht funktionieren, dazu braucht man dann einen 74LCX06. Dessen Eingänge sind 5V-tolerant und der funktioniert mit 3.3V. Die Kehrseite: relativ teuer, nicht so leicht zu bekommen und nur SMD.
ja, stimmt es geht ja auch um den input. und in hc gibt es die nicht.
edit..........
wobei, die sind ja nur für den iec bus da.
nicht für die speicherkarte, die wird ja direkt mit dem atmega 3,3v pegel angesteuert. somit ja kein problem.
und die 74xx treiber funktionieren doch ab dem 2V ttl-high pegel, somit geht es doch.
selbst die 2,4V würde man doch mit dem atmega problemlos hinbekommen.
der bus ist ja ganz ganz langsamm. da gibt es auch keine timing probleme.
hoffentlich mache ich aber nun nicht einen denkfehler, auf die schnelle.
aber es müsste doch mit meiner schaltung auch mit einem atmega mit 3,3v gehen?
Die alten Typen funktionieren nur mit ca. 4.5-4.75V VCC. Für die SW-2 Firmware ist der Inverter passend, nur die alten Typen in DIL gibt es nicht für die 3.3V-Versorgung. Ein 74LVC06A in SOP14 geht auch.
Man kann den 3.3V-Treiber direkt am C= Bus verbauen oder bis zum Cardreader alles mit TTL-Pegel betreiben. Man braucht auf jeden Fall einen Level-Shifter und einen 3.3V-Regler. Wo man das am Ende dann verbaut ist eigentlich egal.
3,3 V werden zuverlässig als "H" erkannt am Eingang (gefordert min. 2,0 V laut Standard). Der Ausgang des 7406/7407 ist Open Collector, benötigt also einen Pullup, der kann nach +5 V auf der einen und nach 3,3 V auf der anderen Seite. Das funktioniert perfekt, habe ich selber schon gemacht.
Ich hatte uralte 7406 ohne Pullups verwendet, funktionierte auch einwandfrei, ist aber Murks. Wenn es immer und überall funktionieren soll, sollte man den Spezifikationen im Datenblatt besser glauben.
Wenn ich das richtig sehe: da wird das RGBI nach Analog gewandelt und vom Flachbild-Fernseher wieder durch einen A/D-Wandler geschickt ? - Bei Letzterem kann man nie so genau sagen, was der an Signal erwartet, damit es am Ende überhaupt funktioniert.
Die Funktion ist da Glückssache, je nach Konverter des Endgeräts.
Mit den üblichen Typen wird das nicht funktionieren, dazu braucht man dann einen 74LCX06. Dessen Eingänge sind 5V-tolerant und der funktioniert mit 3.3V. Die Kehrseite: relativ teuer, nicht so leicht zu bekommen und nur SMD.
Debian (10) Buster ...
