OT: Soundkartenmodulation

Du könntest mit der Soundkarte so ein ähnliches Protokoll bauen wie es der C64 früher auf datasette genutzt hat. Das war pseudodigital so ungefähr

Bau lieber was für den Parallelport unter Dos.

Unter Dos kommt ein Timerinterrupt den du auf keinen Fall blocken solltest mit 18.2 Hz. Leider verlierst du das Strobesignal während eines solchen Interrupts. Deshalb solltest du soetwas versuchen:

Auf dem Notebook läuft eine Schleife,die soviele Datenbits wie möglich liest. Wenn du auf dem Notebook die Datenleitungen nicht auf Eingang schalten kannst mußt du halt erst die ersten 4 bit und dann die anderen 4 bit empfangen.

Loop: Auf den nächsten Timerinterrupt warten Interrupts sperren Busypin freigeben ca 40 ms lang Daten empfangen Busypin sperren Interrups freigeben Daten abspeichern Bei Tastendruck abbrechen ansonsten zu Loop springen

Markus Bauer schrieb:

Es gibt sogenannte Laplink-Kabel, die genau das machen. Software dafür gibt's fertig, aber es ist natürlich die Frage ob Du die einspielen darfst.

Früher hat man sowas mit FSK gemacht (Frequency Shift Keying). Das ist eine einfache Methode, um Tonsignale aus Daten zu erzeugen. Die Datenraten werden wohl höchstens ein paar Tausend bits/s erreichen, aber das Verfahren ist einfach. Du kannst mal danach googeln. Das Prinzip ist einfach: 0 entspricht einer Frequenz, 1 einer anderen.

Hallo,

Danke für deine Antwort!

Stefan Heinzmann dixit:

Wie gesagt, auf solche Ideen bin ich auch schon gekommen. Geht aber nicht weil ich nur im ECP Modus auf den Parallelport zugreifen kann. Das Laplink Kabel hat aber eine andere Verdrahtung und ist total überkreuzt. Meine alternative Idee wäre, einen Drucker Simulator zu schreiben, der einfach alles an Daten aufzeichnet. Dann bräuchte ich meine Textdatei nur mehr ausdrucken :-)

Aber auch das ist irgendwie schwierig. Wenn möglich würde ich das ganze gerne unter Linux im Userspace machen (einfach mit inb/outb, gcc vorhanden, schnell, ...) aber da es keinerlei Sourcen gibt, hab ich null Anhaltspunkte wo ich zum Suchen anfangen soll, wenn es nicht beim ersten Mal funktioniert. Und das wird es nicht. Mein bis jetziger, theoretischer Sourcecode dafür:

// ist eher als Pseudocode zu werten // hab mir noch keine gedanken über die bitoperationen gemacht. if(ioperm(0x378, 3, 1)) return -1;

while(1) { if((inb(parport) & STROBE) != STROBE) { outb(inb(0x378) | BUSY, 0x378); usleep(7); outb(inb(0x378) | ACK, 0x378); usleep(7); outb(inb(0x378) ^ ACK, 0x378); outb(inb(0x378) ^ BUSY, 0x378); } } if(ioperm(0x378, 3, 0)) return -1;

Mein wahres Problem dran ist aber, ob ich so in einer Schleife überhaupt abfragen kann, ob ein Bit gesetzt ist (STROBE). Ausserdem finde ich x verschiedene Angaben zu den Timings. Was stimmt jetzt wirklich? Und muss ich (als Drucker ;-) diesen verdammten ACK überhaupt verwenden oder reichts, wenn ich BUSY ziehe, etwas warte, die Daten von den Leitungen nehme und BUSY wieder fallen lasse? Und auch bei den Active LOW Leitungen finde ich nie wirklich klare Angaben. Eindeutig Active LOW ist STROBE. Aber sind das nicht auch BUSY und ACK??? Und im Prinzip sollte es ja reichen, STROBE und die Datensignale auszuwerten, und ACK und BUSY zu betätigen, um vom Standard Windows Treiber darauf drucken zu können oder sehe ich was falsch? Unter Linux ist der Statusport jedenfalls read-only und der Steuerport write-only. Also müsste ich diese beiden im Prinzip überkreuzen, wenn ich das richtig verstehe...

Oder gibts vielleicht sogar _einfache_ Programme mit Sourcecode und eigener Verdrahtung, die Daten im NORMALEN ECP Modus verschicken können (weil damit ist dann ja kein Rücksenden vom Client möglich). Dann könnte ich nämlich das Hostprogramm auf VisualBasic portieren...wäre sicher die einfachste und eleganteste Lösung. (Wenn ich das richtig verstehe, kann ich mit der API auch den Parallelport aufmachen und drauf im ECP Modus schreiben, wenn ich auch das Recht habe, auf diesen Port drucken zu können).

Das ist wie gesagt nicht das allergrößte Problem. Viel wichtiger ist die Integrität der Daten. Wenn ich alles aufs Minimum packe, dürfte es um die

Ich werde gleich danach googeln, danke!

Markus

Hallo,

Danke auch dir für deine Antwort!

snipped-for-privacy@gmx.net (Gernot Fink) dixit:

Dafür würde ich in etwa 30 Minuten benötigen --> akzeptabel. Werde ebenfalls gleich danach googeln.

Lieber wärs mir unter Linux ;-) Oder gehts unter DOS wirklich einfacher?? Und kann ich das auch (nat. als Admin) unter XP machen?

Wieso sollte ich diesen Interrupt nicht verpassen? Das Hauptziel der `Mission' ist einfach, die Daten aufzuzeichnen, ob da jetzt zB für diese Dauer irgendein Treiber, die Software oder die Zeit spinnt ist doch egal. Oder regelt dieser Interrupt noch was andres?

Kann ich glaub ich - unter Linux gehts zumindest..denk ich.

Also ACK brauche ich deiner Einschätzung nach nicht?

Wieso 40ms lang? Ich lese leider viel variable Angaben dazu :-(

Ich weiss nicht, ob du was mit Linux am Hut hast, meinen `Pseudocode' habe ich aber schon in der vorigen Antwort gepostet...

Vielen Dank!

Markus

Strobe geht AFAIK eh nur kurz auf low. Das ist wahrscheinlich eher ungünstig rein softwaremäßig abzufragen. Ich hab mal einen Datenstrom von einem Par-Port empfangen bei dem ich den Sender extrem bremsen musste. (uC spielt Plotter und kriegt die Daten vom Par-Port). Da hat der Strobe-Puls ein Flip-Flop(74HC74, Strobe am /set-Eing., Busy an Ausgang Q und der uC am /Reset) gesetzt an dessen Ausgang die Busy Leitung hing und so den PC erstmal gestoppt hat. Wenn dann der uC das Datenwort endlich gelesen hat, (was durchaus ein paar Sekunden dauern konnte, bis die Bewegung des Plotters beendet war) hat er das Flip-Flop gelöscht (das hat Busy freigegeben), worauf der PC sofort das nächste Datenwort gebracht und per Strobe das Flip- Flop wieder gesetzt (und sich damit selber ausgebremst) hat. Act war immer so dass es den Fluß nicht gebremst hat (weiß jetzt nicht ob high oder low) Ich weiß jetzt nicht welcher Modus am Parallelport das war. Wenn dich das interessiert kann ich die Details nachschauen, aber evtl. erst übernächste Woche. Wenn Busy ständig low war hat der PC einfach ein Byte nach dem anderen geschickt, die Geschwindigkeit ist dann extrem von den genauen Umständen des Sende-PCs abhängig (Modus, DOS oder Win, Treiber etc.)

Es gab nicht nur eine Methode. Hat jeder Herstellen ein wenig anders gemacht, v.a. in der Anfangsphase des Par-Port.

So hab das ich gemacht.

Busy ist eindeutig active High. Act weiß ich jetzt nicht.

Bei mir war so das bei Busy low und Act auch auf einem festen Pegel der Windoes Treiber einfach alle Bytes eins nach dem anderen (per Strobe bestätigt natürlich) rausgenudelt hat. Mit einer dem Treiber und dem PC genehmen undefinierten Geschwindigkeit.

Vielleicht mehrere kleinere Zip-Dateien, dann muß man nicht alles wiederholen wenn ein Bitfehler drin war.

Georg

Markus Bauer schrieb:

Scheint mir ne krude Idee. Ist das ein Gedankenexperiment, oder ein reales Problem? Hat der PC keine serielle?

Du kannst im DOS Fenster problemlos jede Datei per Umleitung an den Drucker oder eine serielle schicken und dort abgreifen. Dafür musst Du noch nichtmal Software installieren.

- Carsten

bit nicht byte !

Natürlich nicht

Linux ist mir auch lieber, aber die Strobimpulse sind so schmal daß du einen verlierst sobald ein Interrupt auftaucht.

Die elegante möglichkeit ist die mit dem Flipflop wie in einen anderen Posting gesagt. Der übernimmt das busyhochziehen. Die Interrupts stören nicht mehr. Mit ack kannst du den Flipflop wieder reseten und brauchst dir auch keine Gedanken mehr über Ack zu machen.

Ich hab Hier mal ein Timing von HP

Data ---DATA_VALID------- Strobe -----____----------- Busy ___________--_____ Ack -------------__---

Die Strobe Pulslänge beträgt minimal 0.5us Ack ist 3.75 us lang

Vorsicht das sind die Pegel. In der Software ist irgendein Signal invertiert.

Als Kernelmodul ist das mit den selben Einschränkungen wie unter Dos zu schaffen.

Ich habs mal versucht wodurch das System so instabil wurde daß ich die Daten nicht mehr auf die Platte schreiben konnte.

Damit du den nächsten Interrupt nicht verpasst. Der kommt nach 52 ms.

Markus Bauer schrieb:

Hallo,

Ein Laplink gibt es auch über den seriellen Port. Ich habe das auch schon für eine NT-Kiste benutzt, jedoch mit fertiger Software.

Thomas

Moin,

Markus Bauer schrieb...

=20

=20

m=20

Wenn Du Zugriff auf den Rechner hast und es Dir erlaubt ist, den Rechner=20 aufzuschrauben, dann w=FCrd' ich einfach tempor=E4r (oder dauerhaft, falls= =20 gestattet) ein billiges Diskettenlaufwerk einbauen.=20 Das mit der Soundkarte w=FCrd' ich vergessen. Dan besser auf Parallelport,= =20 dort mit 2. Rechner oder Controller einen Drucker nachbilden.

- Heinz

Hallo Markus,

| Also ich hab einen PC der ist komplett eingeschränkt, praktisch keine | Geräte drinnen, NT4, keine Rechte unsw. Davon will ich mir jetzt eine | Datei kopieren*.

auch wenn sich das ganze nicht so besonders legal anhört, weil sonst würde man mal kurz zum Admin gehen und den bitten...

| Auf den Parallelport darf ich ja auch nur im ECP Modus zugreifen, also

ECP sollte IMHO abwärtskompatibel sein. Ich sehe kein Problem darin. Zur Not bereitest Du Deine Datei so auf, dass alles in den unteren 4 bits liegt und druckst diese einfach aus. Auf der Gegenseite übernimmst Du die Daten auf einem 1:1 kabel an den Datenleitungen und schreibst alles in ein File. Nun filterst Du alles mit gesetzten Bit 4-7 heraus und setzt Deine Nibbles wieder zu Bytes zusammen. So ähnlich, nur mit dem Umweg über die Statusleitungen lief das bei Laplink. Da Du aber kaum ein solches installieren darfst hilft Dir Laplink & Co auch nicht weiter, sondern musst mit dem Druckerport hantieren. Je nach Druckertreiber (zumindest die alten halten sich dran) werden die Steuerzeichen alle im ASCII Bereich 127+ verwendet, also mit gesetztem Bit 7. Also Nibbles machen, dann kannst Du Steuerzeichen und Daten einfach trennen. Due eigentliche Datenübertragung dürfte dann auch recht schnell vorbei sein und das Aufbereiten ist dann doch wohl nicht mehr zeitkritisch, oder?

MArtin

"Markus Bauer" schrieb:

dem

Hast du einen Drucker? Dann könnte man die Daten auf Papier drucken, eine 0 als Schwarzer Pixel eine 1 als weisser. Wenn deine Pixel 0.5 x

bye, Dan

"Dan Oprisan" schrieb im Newsbeitrag news:cbu231$mv6$ snipped-for-privacy@rzsun03.rrz.uni-hamburg.de...

(nach

Die

ist

Dan Oprisan schrieb:

Aha, ich sehe jetzt fangen die ernsthaften Vorschläge an :-)

Da hätte ich auch noch einen: Man könnte die Daten auf dem Bildschirm anzeigen und einen Empfänger bauen, der die vom Monitor abgestrahlten Signale auswertet.

Stefan Heinzmann schrieb...

=20

Zu gro=DFer Aufwand. Warum nicht einfach die Stromaufnahme des Rechners=20 messen. Im sleep ist die Leistungsaufnahme bei modernen CPUs bis zu 30%=20 unterhalb der Leistung bei Vollast. Damit ist eine serielle =DCbertragung= =20 m=F6glich:=20 Bei logisch-1 5 Sekunden viel rechnen, bei logisch-0 10 Sekunden.=20 Bittrennung durch 5 Sekunden sleep (genaue Zeiten ausprobieren). Strom kann =FCber ein Multimeter mit seriellem Ausgang gemessen und auf 2.= =20 PC ausgewertet werden!

- Heinz

OK, ich weiss, dass dieser Beitrag möglicherweise stümperhaft wirkt, aber es geht "ratz faz" und man muss nichts programmieren.

Wenn es Tatsächlich um Sourcen (=Text sprich druckbare Zeichen) geht, druck das ganze aus, und lies es mit einem OCR Programm wieder ein. Heutzutage krigt man wirklich gute OCR's zum 10 Tage testen gratis im Internet und ein Pagescanner welcher die Blätter durchzieht ist auch nicht mehr so rar. Hatte mal ein ähnliches Problem und hat prima funktioniert, allerdings war die Datei ein nur paar KB gross.

SG Christian

Stefan Heinzmann schrieb:

Oder von einem Chinesen abtippen lassen. Oder besser von dreien, um Tippfehler zu erkennen.

Hallo,

Carsten Kurz dixit:

Habe ich geschrieben - nein.

Ich weiss, ein `Permission denied' hilft mir aber auch nicht weiter. Und bei einer Umleitung über den LTP (der ja auch stink normal einen Drucker ansteuert) kann ich gleich den vernünfigen Druckertreiber verwenden.

markus

Hallo,

Thomas Forster dixit:

Ich habe wie gesagt *NICHTS* zu Verfügung - auch keinen seriellen. Würde ich sonst auf solche stupiden Ideen kommen??

mfg

markus

hi,

Heinz Saathoff dixit:

Nein, hab ich leider auch nicht. Auch an das habe ich schon gedacht. Aber selbst wenn - in Wirklichkeit ist ja eine Floppy drin - nur dort wird alles 128 Bit verschlüsselt - ebenso die Festplatte. Also hilft auch Ausbauen der HDD nicht wirklich...

Das `Drucker-Nachbilden' war ja Bestandteil meiner Frage und meine ursprüngliche Idee.

markus