C16, 116 / plus4 : Lustiger Effekt mit Drucker und Datasette, zum Selberausprobieren!

Vielen Dank an Eloy_Dorian für das Hochladen des Ergebnisses und für das sicher mühsame Auszählen der 875 "pi"-Zeichen!
Auffällig ist allerdings, dass User "salator" in Posting #11 einen ganz anderen Output erzielt hat.
Brotscheibe:
Easter-Egg oder Weihnachts-Egg?

MiCv2:
bringt dir kein Geld - ist aber trotzdem eine potentielle Goldgrube - - für Papiermühlenbesitzer und Druckerfarbbandhersteller..

@all:
Bestehen denn Vermutungen oder Neugierde, woran es liegt?
Oder haben schon alle brav in ihren 264er-Schaltplan geguckt
und ihre Schlüsse gezogen?

Ich kann eine Erklärung anbieten, aber vermutlich sind schon welche beim Lesen bzw. spätestens beim Hinweis auf den Schaltplan draufgekommen und möchten es selber gern formulieren .... denen will ich nicht vorgreifen ...

Helmut: an sich ist es der 'wissenschaftlich korrekte' Weg den du vorschlägst um sicherzugehen, dass das pi bzw. π keine optische Täuschung ist. Würde in diesem Fall aber nur nochmal die Bestätigung bringen, dass der Drucker tatsächlich CHR$(255) empfängt. Die Firmware sendet aber nichts Beabsichtigtes, eher ist es ein Fehler durch 'Unterlassen'....

Hexworx: okay, okay ...

aaaalso, hier die ausführliche Erklärung:

Der Drucker empfängt CHR$(255) und interpretiert d.h. druckt es auch, weil es für ihn so erscheint, als würde der Rechner dieses Zeichen über den IEC-Bus senden. Allerdings tut er das nicht "absichtlich". Der Grund für das beobachtete Verhalten liegt in einer "Sparmaßnahme" von Commodore (realisiert von Bil Herd), die CIA- bzw. VIA-Bausteine wegzurationalisieren. Daher mein Hinweis auf den Schaltplan:

Es geht um die CLK-Leitung des IEC-Bus, deren Output-Funktion hier gleichzeitig die CASS-WRITE-Leitung für das Schreiben auf Datasette ist. (wegen Port-Knappheit Doppelnutzung von Leitungen). Das ist bei den 264er Rechnern anders als beim C64 und hat Folgen, allerdings kommen diese normalerweise nicht zum Tragen, und deswegen mag Bil Herd (oder wer immer das umgesetzt hat bei Commodore) nicht an Sicherheitsmaßnahmen gedacht haben:

Normalerweise wird entweder NUR der IEC-Bus angesteuert, ODER NUR auf Datasette geschrieben.
Ein kompletter Schreibvorgang, z.b. PRINT#1 auf den IEC-Bus wird mit je einem Zugriff (Primär - und Sekundäradresse senden) mit gleichzeitig "ATN low" eingeleitet und abgeschlossen. Bei PRINT#1 wird implizit stets paarweise ein LISTEN am Anfang und ein UNLISTEN am Ende mitgeschickt und als Basic-Programmierer kann man das nicht verhindern. Nach jedem PRINT#1 wird Unlisten gegeben sodass z.b. der Drucker nicht mehr auf CLK empfindlich ist sondern auf ATN wartet. Würde man hier SAVE geben, wäre nichts auffälliges zu beobachten.

Ein kompletter Schreibvorgang auf Datasette wird dementsprechend spiegelbildlich durch Abfrage von Cassette Sense und MOTOR ON geschützt bzw. verriegelt; so dass während SAVE (wo ja ausserdem der Bildschirm abgeschaltet und der Direktmodus nicht zugänglich ist) keine IEC-Bus-Vorgänge stattfinden können und normalerweise während IEC-Senden kein SAVE stattfinden kann.

Gegenseitige Störungen von IEC und Datasette sind so normalerweise trotz Doppelnutzung von CLK und CASS WRITE ausgeschlossen - möchte man meinen....

Nun ist es aber so, dass die CLK-Leitung einer Doppelbenutzung unterliegt und es einen Betriebsfall gibt, wo ein "angefangener" IEC-BUS-Zugriff "lose in der Landschaft herumliegen kann", und das ist nach Gabe des Befehls CMD1 mit Bezug auf einen geöffneten Kanal. In diesem Zustand wird das abschließende UNLISTEN unterdrückt. (ich habe damals als ich nach Betrachten des Schaltplans diesen Effekt vermutet und danach gesucht habe, zuerst mit PRINT#1; experimentiert aber das Semikolon ; hat nur CHR$(13) unterdrückt aber leider trotzdem UNLISTEN gesendet). Der Drucker bleibt auf CLK-Übergänge "empfindlich".

In diesem Zustand kann der Drucker den Rechner nur mit DATA= low aufhalten und mit DATA = high Bereitschaft signalisieren. Der Rechner taktet das zu sendende Byte mit CLK abwechselnd Low und High mit Taktzeiten mindestens 45 Mikrosekunden pro (aktiver) Bit-Zeit. Am Schluß einer Kette von 8 bit findet nochmal ein Handshake statt.

Nun ist es bei dem in Rede stehenden "Effekt" so, dass der Rechner ständig Low-High übergänge auf CLK raushaut, weil er ja auf Datasette die Lang-kurz und kurz-Lang Frequenzen (was ja paarige Low-high-Übergänge sind, insgesamt 4 Flanken pro Datasetten-Bit) speichern will. Eben weil nach CMD1 SAVE gegeben wurde.

"Zufällig" sind diese Flanken im tolerablen Zeitbereich für den IEC-Bus! Und, je 1 Bit für die Datasette ergibt 2 scheinbare Bit auf dem IEC-Bus. Dadurch erklären sich u.a. die Massen an Daten die gedruckt werden. Der Drucker taktet also Daten herein, er sampelt dabei seine Data-Leitung, die allerdings nicht bedient wird sondern im Ruhezustand verbleibt (high) - von wem sollte sie auch bedient werden, "IEC-Data" ist im Datasettenbetrieb nicht betroffen und es gibt bei DATA hier keine Doppelbelastung (?noch zu klären es kann sein dass es noch andere Doppelbenutzungen gibt, ich weiß das momentan nicht auswendig) - und im "logisch high"-Zustand verbleibt, wodurch jeder Sample-Vorgang ein "1" - bit liefert. 8 bits im 1-Zustand ergeben $FF bzw. CHR$(255) was laut PETSCII(ASCBM) dem "Pi"-Zeichen entspricht. Allein mit Hexdump kommt man dem Effekt nicht auf die Spur.

Noch doller ist, dass auf dem IEC-Bus im Normalbetrieb auch ein rudimentäres Handshake stattfindet, nach je 8 bit müsste über die Datenleitung ein Hold-off bzw. eine Freigabe stattfinden. Ebenso dürfte das Starten eines 8-Bit-Rahmens nur vom Rechner aus starten, wenn der Drucker sein "Okay" gibt (über Data). Die Taktflanken für Datasette entsprechen diesen Timing allerdings ebenso zufällig genau in einem tolerablen Zeitfenster, sodass es dem Drucker so erscheint, als würde der Rechner auf seine Data-Freigabe "reagieren" .

In Wahrheit sind die abwechselnd längeren und kürzeren Pulszeiten für den Cassettenbetrieb so "eierig" dass es eben zufällig den Timing-Erfordernissen des IEC Bus nebst Kunstpausen und höflichen Wartezuständen auf vermeintliche Handshake-Antworten entspricht. Der Drucker-IEC-Algorithmus führt die abwechselnd langen Taktzeiten des Datasettenschreibens auf eine Reaktion auf sein DATA-Low-ziehen am ende eines Frames zurück; in Wahrheit haut der Rechner die CLK-Pulse im Freien Flug heraus.

Durch das CMD1 ist der Drucker in eine Hab-Acht-Stellung versetzt (LISTEN - Zustand) . sobald der Rechner CLK auf logisch High bringt, übernimmt der Drucker das nachfolgend seriell gesendete Datenbyte.

alles was nachfolgend für Datasette rausgeschickt wird, gaukelt dem Drucker vor, er wäre gemeint :rotwerd: :rotwerd: und der empfängt und druckt dann die besagten Zeichen eventuell bis zum Abwinken Dabei können durchaus kolossale Mengen gedruckt werden, man denke nur an den mehrere Sekunden langen gleichbleibend langen Pilot-Ton der zu Anfang des SAVE abgespeichert wird - schon das, es sind ja noch keine richtigen Daten, suggeriert dem Drucker eine "payload" .....

Die Idee mit dem Kurzschluß von hexworx ist schon verdammt nah dran insofern, als eben die CLK-Leitung sowohl mit dem IEC-Bus als auch mit der Datasette verbunden ist, ein logischer Kurzschluß sozusagen

Alles in allem mehr als ein Software-Easter-Egg, sondern eine komplexe, Protokoll-ebenen überschreitende unverhoffte bzw. ungeplante Wechselwirkung zwischen IEC-Bus und Datasetten-Schreibbetrieb, die durch eine Hardware-bzw. Herdware-Sparmaßnahme ohne flankierende Firmware-Anpassung hervorgerufen wird. Einen Namen für diesen Effekt müsste man auch noch finden, ich denke dabei vorläufig an "IEC-Pseudo-Schreiben bei Datasetten-SAVE unter CMD." Man könnte es durchaus einen Bug nennen.

Zu verhindern wäre das gewesen, wenn der Ingenieur, der die Peripherie-Chips (VIA bzw. CIA) gemeinerweise wegrationalisiert hat , dem Programmierer der Systemsoftware bescheid gegeben hätte - da wäre ein Flag denkbar gewesen, oder eine Abfrage, dass vor SAVE auf Gerät 1 erst bestehende IEC-Kanäle geschlossen werden. Für die Kernelversion -06 ist diese Änderung vorgemerkt

Allerdings muß so ein Rechner ja nicht perfekt sein, ich finde so wie er ist ganz okay, der Charme des Nichtperfekten bekommt dem C16, C116, plus/4 ganz gut. Oder was denkt ihr?

hexworx, bitte hau mich nicht (mehr) ...
War die Erklärung ausreichend und konnte man sie nachvollziehen?

Zitat von proxa

der cmdX befehl leitet ja nur die ausgabe vom bildschirm auf
das gerät welches mit openX geöffnet wurde.

Zitat von WTE

Das ist so eigentlich nicht ganz richtig. <klugscheißermodus>Mit CMDx wird das Standard-Ausgabegerät definiert. Das ist bei PRINT "normalerweise" der Bildschirm. Nicht aber bei LOAD und SAVE.</klugscheißermodus>

ich kann , vor allem bei Würdigung der fettgedruckten Stelle mit openX, keinen wirklichen Widerspruch zwischen den Aussagen von WTE und Helmut (proxa) erkennen: hatte Helmut doch seine Aussage wirklich eingeschränkt dass die von CMD bewirkte Umlenkung ja ausdrücklich nur bei OPEN / Close Operationen wirkt.

Und wenn WTE sagt, das Standardausgabegerät könne "nicht bei LOAD und SAVE" geändert werden, so ist das nach der booleschen Aussagenlogik nicht nur kein Widerspruch zu Helmut (der das gar nicht bestritten hatte) sondern besagt - im möglichen und zulässigen Umkehrschluss - sogar exakt dasselbe, nämlich, dass im gegenteiligen Fall das Ausgabegerät sehr wohl geändert werden kann (mit CMD).

Menge der Anwendungsfälle M = {{Open, CLose } {Load, Save}}
I. Aussage Helmut: Änderbarkeit des Standardausgabegeräts mit CMD nur bei € {Open,CLose}
II. Aussage WTE: Änderbarkeit nur bei M \ {LOAD, SAVE } , sprich:" M ohne Load und Save".

also nehmen wir nochmal M her und streichen die zweite Teilmenge:
M = {{Open, CLose } {Load, Save}}

es verbleibt M' = {{Open, Close}}

Das ist aber exakt das, was Helmut eingangs (= I.) gesagt hatte!

Somit haben wir mit mengentheoretischem Traradie Aussage von WTE in die von Helmut widerspruchsfrei transformiert.

Eigentlich aber wollte ich nur noch ein Stück Schaltplan des C116 nachreichen, in dem der bei dem CMD-Effekt dieses Threads massgebliche Signalpfad farblich markiert ist. Ich denke, man sieht gut, wie der Pin 29 des mos 7501/8501 Prozessors mit Namen "P1" zu beiden Schnittstellen ,IEC und Datasette, geleitet wird:
[imgintern]http://www.forum64.de/wbb3/ind…3465fc849e345b18328241f2a[/imgintern]

Edit: Venn-Diagramme, Differenzmenge, Komplementärmenge

ok, so gesehen hätte ich mir den Plan vorhin auch schenken können

.. andererseits dachte ich halt, ein Bild sagt mehr als 1000 Worte ...

Gruß,
S.

Versuch einer Erklärung der 875 "pi", auf die Schnelle, warum es gerade 875 sind:

- SAVE speichert zuerst einen Datenblock nur für die 16 Bytes Dateiname ab; dieser ist die vollen 192 (?) Bytes des Datasettenpuffers lang; danach das eigentliche Programm ebenfalls als Block, aber nur Größenordnung 10 Bytes = vernachlässigbar ggüb. 192;

- wie oben schon dargelegt, besteht jedes Datasettenbit aus 4 Flanken was der IEC-Bus CLK-mäßig als 2 Bit interpretiert => Verdopplung Nr. 1 (Bitzahl Datasette / IEC) ;

- das Commodore-Datasetten-Format speichert jeden Block 2x ab zwecks Sicherheit => Verdopplung Nummer 2.

Also gehen wir von grob 200 (*) Bytes aus, die 2x verdoppelt werden => ergibt Größenordnung 800 Byte. Von den genannten 875 Zeichen ist das nicht weit entfernt.

Dass es etwas mehr sind, führe ich darauf zurück, dass vor und zwischen den Datenblöcken ein Pilot-Ton gesendet wird; von den so erzeugten Pseudo-Bits könnte wiederum ein Teil "verschluckt" werden wegen mangelhaftem Timing oder weil der Drucker schlicht nicht hinterherkommt ("überfahren" wird).

EDIT: (*) das Programm "10 REM IRGENDWAS" ist meines Wissens 20 Bytes groß. (192 +20) * 4 = 848 zzgl. Prüfsummen u.a.

Zitat von Hexworx

Und wie ergibt sich jetzt die "krumme" Zahl von 875 x Pi?

Wie sich die 'ergibt'? die "ergibt sich" kampflos, und zwar wie folgt:
Gesuchte Größe g:

g = 875 * pi
π = 3.1415926535.....
g = 875 * 3.1415926535
= 2748.89357
Antwortsatz: Die gesuchte Größe lautet 2748.89357

In CBM-Basic auch leicht so auszurechnen:

Zitat

?π*875
2748.89357

ready.