OT: Soundkartenmodulation

[Markus Bauer]

Hallo,

Ich bin mir ziemlich sicher, dass meine Frage hier OT ist aber ich habe
keinen blassen Schimmer, so sie besser hinpassen würde, da sie nicht
spezifisch ist. Ich denke aber, dass ich hier Leute finde, die sich damit
auskennen.

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*.

Unterm Strich bleiben einfach nur 2 realistische Möglichkeiten (nach dem
Ausdrucken auf Papier).
- Parallelport
- Soundkarte

Auf den Parallelport darf ich ja auch nur im ECP Modus zugreifen, also
brauche ich ein spezielles Kabel, welches ich mit (zB) einem Laptop
verbinde (Status und Kontrollleitungen gekreuzt) und ne Software, die mir
einen Laptop `simuliert'. So einfach geht das aber doch nicht.

Die zweite Möglichkeit wäre das ganze über die Soundkarte regeln zu
können.
Geschwindigkeit ist nicht sooo wichtig, Datenvolumen ca 1MB.
Es wäre genial wenn es irgendwie möglich wäre, simple Daten (im Moment
hab ich sie als ASCII-HEX-Stream) in eine WAV Datei zu konvertieren,
sodass im Prinzip (so stelle ich mir das halt vor) ein HIGH einen hohen
Ton bedeutet und ein LOW einen tiefen.
VBA hätte ich dafür zu Verfügung.

Diese WAV Datei könnte ich dann abspielen und direkt mit Line-IN vom
Notebook wieder aufnehmen und danach wieder irgendwie `demodulieren'.

Ist das realistisch möglich? (Die ganze Aktion wäre schön, wenn sie in
0,5-2 Stunden vorbei wäre) Gibt es da schon irgendwas brauchbares? Hab
nicht einmal eine Ahnung nach was ich suchen soll!

Oder ist das ganze so fehleranfällig/umständlich, dass ich mich doch an
die erste Lösung machen soll?

Auf dem `Host-PC' hätte ich Perl und VBA zu Verfügung. Beide Sprachen
würde
ich beherrschen, die Frage ist jetzt nur ob das überhaupt durchführbar
ist und wie ich die WAV Datei schreiben soll...

Vielen Dank für eure Infos...

mfg

Markus

*: Diese Infos schreibe ich deswegen, damit ihr eine Ahnung habt, um was
es überhaupt geht. Ich weiss selbst, dass ich den PC aufschrauben könnte
und auch ALLES andre fällt flach. Es gibt keine serielle, USB, Diskette,
CD-Rom, Netzwerk unsw. Auch die Idee, einfach wen zu fragen geht nicht.
Ich bin GWD beim Bundesheer, habe über 2 Monate ein Programm geschrieben,
und davon hätte ich gerne lediglich für eigene Referenzzwecke den
Sourcecode (dabei sind keine Daten enthalten; ich will also keine Daten
stehlen unsw . Das da alle andren Möglichkeiten einfach nicht gegeben
sind, sollte ebenso klar sein, wie dass die Leute, die mir das rein
theoretisch machen könnten etwas ausserhalb meiner Reichweite liegen.

 

[Gernot Fink]

In article <Xns9517CC1162825markusbauergmxnet@213.229.60.102>,
Markus Bauer <mc_@gmx.net> writes:

Unterm Strich bleiben einfach nur 2 realistische Möglichkeiten (nach dem
Ausdrucken auf Papier).
- Parallelport
- Soundkarte

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
0,1 ms=lo 0,2 ms=High.Damit schaffst du aber maximal 6 kilobit pro sekunde.

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

Auf den Parallelport darf ich ja auch nur im ECP Modus zugreifen, also
brauche ich ein spezielles Kabel, welches ich mit (zB) einem Laptop
verbinde (Status und Kontrollleitungen gekreuzt) und ne Software, die mir
einen Laptop `simuliert'. So einfach geht das aber doch nicht.

Die zweite Möglichkeit wäre das ganze über die Soundkarte regeln zu
können.
Geschwindigkeit ist nicht sooo wichtig, Datenvolumen ca 1MB.
Es wäre genial wenn es irgendwie möglich wäre, simple Daten (im Moment
hab ich sie als ASCII-HEX-Stream) in eine WAV Datei zu konvertieren,
sodass im Prinzip (so stelle ich mir das halt vor) ein HIGH einen hohen
Ton bedeutet und ein LOW einen tiefen.
VBA hätte ich dafür zu Verfügung.

Diese WAV Datei könnte ich dann abspielen und direkt mit Line-IN vom
Notebook wieder aufnehmen und danach wieder irgendwie `demodulieren'.

Ist das realistisch möglich? (Die ganze Aktion wäre schön, wenn sie in
0,5-2 Stunden vorbei wäre) Gibt es da schon irgendwas brauchbares? Hab
nicht einmal eine Ahnung nach was ich suchen soll!

Oder ist das ganze so fehleranfällig/umständlich, dass ich mich doch an
die erste Lösung machen soll?

Auf dem `Host-PC' hätte ich Perl und VBA zu Verfügung. Beide Sprachen
würde
ich beherrschen, die Frage ist jetzt nur ob das überhaupt durchführbar
ist und wie ich die WAV Datei schreiben soll...

Vielen Dank für eure Infos...

mfg

Markus

*: Diese Infos schreibe ich deswegen, damit ihr eine Ahnung habt, um was
es überhaupt geht. Ich weiss selbst, dass ich den PC aufschrauben könnte
und auch ALLES andre fällt flach. Es gibt keine serielle, USB, Diskette,
CD-Rom, Netzwerk unsw. Auch die Idee, einfach wen zu fragen geht nicht.
Ich bin GWD beim Bundesheer, habe über 2 Monate ein Programm geschrieben,
und davon hätte ich gerne lediglich für eigene Referenzzwecke den
Sourcecode (dabei sind keine Daten enthalten; ich will also keine Daten
stehlen unsw . Das da alle andren Möglichkeiten einfach nicht gegeben
sind, sollte ebenso klar sein, wie dass die Leute, die mir das rein
theoretisch machen könnten etwas ausserhalb meiner Reichweite liegen.

--
MFG Gernot

 

[Stefan Heinzmann]

Markus Bauer schrieb:

Auf den Parallelport darf ich ja auch nur im ECP Modus zugreifen, also
brauche ich ein spezielles Kabel, welches ich mit (zB) einem Laptop
verbinde (Status und Kontrollleitungen gekreuzt) und ne Software, die mir
einen Laptop `simuliert'. So einfach geht das aber doch nicht.

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.

Die zweite Möglichkeit wäre das ganze über die Soundkarte regeln zu
können.
Geschwindigkeit ist nicht sooo wichtig, Datenvolumen ca 1MB.
Es wäre genial wenn es irgendwie möglich wäre, simple Daten (im Moment
hab ich sie als ASCII-HEX-Stream) in eine WAV Datei zu konvertieren,
sodass im Prinzip (so stelle ich mir das halt vor) ein HIGH einen hohen
Ton bedeutet und ein LOW einen tiefen.
VBA hätte ich dafür zu Verfügung.

Diese WAV Datei könnte ich dann abspielen und direkt mit Line-IN vom
Notebook wieder aufnehmen und danach wieder irgendwie `demodulieren'.

Ist das realistisch möglich? (Die ganze Aktion wäre schön, wenn sie in
0,5-2 Stunden vorbei wäre) Gibt es da schon irgendwas brauchbares? Hab
nicht einmal eine Ahnung nach was ich suchen soll!

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.

--
Cheers
Stefan

 

[Markus Bauer]

Hallo,

Danke für deine Antwort!

Stefan Heinzmann <stefan_heinzmann@yahoo.com> dixit:

Markus Bauer schrieb:

Auf den Parallelport darf ich ja auch nur im ECP Modus zugreifen,
also brauche ich ein spezielles Kabel, welches ich mit (zB) einem
Laptop verbinde (Status und Kontrollleitungen gekreuzt) und ne
Software, die mir einen Laptop `simuliert'. So einfach geht das aber
doch nicht.

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.

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).

Die zweite Möglichkeit wäre das ganze über die Soundkarte regeln zu
können.
Geschwindigkeit ist nicht sooo wichtig, Datenvolumen ca 1MB.
Es wäre genial wenn es irgendwie möglich wäre, simple Daten (im
Moment hab ich sie als ASCII-HEX-Stream) in eine WAV Datei zu
konvertieren, sodass im Prinzip (so stelle ich mir das halt vor) ein
HIGH einen hohen Ton bedeutet und ein LOW einen tiefen.
VBA hätte ich dafür zu Verfügung.

Diese WAV Datei könnte ich dann abspielen und direkt mit Line-IN vom
Notebook wieder aufnehmen und danach wieder irgendwie `demodulieren'.

Ist das realistisch möglich? (Die ganze Aktion wäre schön, wenn sie
in 0,5-2 Stunden vorbei wäre) Gibt es da schon irgendwas brauchbares?
Hab nicht einmal eine Ahnung nach was ich suchen soll!

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.

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
500KB haben. Wenn ich den Schlepptop dann einfach dranstecke und das Zeug
aufnehme, sollte es kein Problem sein, wenn das 1-2 Stunden dauert...

Ich werde gleich danach googeln, danke!

Markus

 

[Markus Bauer]

Hallo,

Danke auch dir für deine Antwort!

G.Fink@gmx.net (Gernot Fink) dixit:

In article <Xns9517CC1162825markusbauergmxnet@213.229.60.102>,
Markus Bauer <mc_@gmx.net> writes:

Unterm Strich bleiben einfach nur 2 realistische Möglichkeiten (nach
dem Ausdrucken auf Papier).
- Parallelport
- Soundkarte

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 0,1 ms=lo 0,2 ms=High.Damit schaffst du aber maximal 6
kilobit pro sekunde.

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

Bau lieber was für den Parallelport unter Dos.

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

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:

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?

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.

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

Loop:
Auf den nächsten Timerinterrupt warten
Interrupts sperren
Busypin freigeben

Also ACK brauche ich deiner Einschätzung nach nicht?

ca 40 ms lang Daten empfangen

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

Busypin sperren
Interrups freigeben
Daten abspeichern
Bei Tastendruck abbrechen ansonsten
zu Loop springen

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

 

[Georg Seegerer]

Mein wahres Problem dran ist aber, ob ich so in einer Schleife überhaupt
abfragen kann, ob ein Bit gesetzt ist (STROBE).

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.)

Ausserdem finde ich x verschiedene Angaben zu den Timings.
Was stimmt jetzt wirklich?

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

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?

So hab das ich gemacht.

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???

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

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?

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.

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
500KB haben. Wenn ich den Schlepptop dann einfach dranstecke und das Zeug
aufnehme, sollte es kein Problem sein, wenn das 1-2 Stunden dauert...

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

Georg

--
Die Reply-To Adresse ist reply-fähig ;-)
Bitte händisch "[news]" in der Betreff-Zeile ergänzen
damit die mail auch gelesen wird.

 

[Carsten Kurz]

Markus Bauer schrieb:

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*.

Unterm Strich bleiben einfach nur 2 realistische Möglichkeiten (nach dem
Ausdrucken auf Papier).
- Parallelport
- Soundkarte

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
--
Audio Visual Systems fon: +49 (0)2234 601886
Carsten Kurz fax: +49 (0)2234 601887
Von-Werth-Straße 111 email: audiovisual@t-online.de
50259 Pulheim / Germany WGS84:N50°57'50.2" E06°47'28.5"

 

[Gernot Fink]

In article <Xns9517EC9C753F5markusbauergmxnet@195.3.96.116>,
Markus Bauer <mc_@gmx.net> writes:

Hallo,

Danke auch dir für deine Antwort!

G.Fink@gmx.net (Gernot Fink) dixit:
In article <Xns9517CC1162825markusbauergmxnet@213.229.60.102>,
Markus Bauer <mc_@gmx.net> writes:

Unterm Strich bleiben einfach nur 2 realistische Möglichkeiten (nach
dem Ausdrucken auf Papier).
- Parallelport
- Soundkarte

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 0,1 ms=lo 0,2 ms=High.Damit schaffst du aber maximal 6
kilobit pro sekunde.

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

bit nicht byte !

Bau lieber was für den Parallelport unter Dos.

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

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.

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:

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?

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

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.

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

Loop:
Auf den nächsten Timerinterrupt warten
Interrupts sperren
Busypin freigeben

Also ACK brauche ich deiner Einschätzung nach nicht?

ca 40 ms lang Daten empfangen

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

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

--
MFG Gernot

 

[Thomas Forster]

Markus Bauer schrieb:

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*.

Auf den Parallelport darf ich ja auch nur im ECP Modus zugreifen, also
brauche ich ein spezielles Kabel, welches ich mit (zB) einem Laptop
verbinde (Status und Kontrollleitungen gekreuzt) und ne Software, die mir
einen Laptop `simuliert'. So einfach geht das aber doch nicht.

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

 

[Heinz Saathoff]

Moin,

Markus Bauer schrieb...

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*.

Unterm Strich bleiben einfach nur 2 realistische Möglichkeiten (nach dem
Ausdrucken auf Papier).
- Parallelport
- Soundkarte

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

- Heinz

 

[Martin Schönegg]

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

 

[Dan Oprisan]

"Markus Bauer" <mc_@gmx.net> schrieb:

Unterm Strich bleiben einfach nur 2 realistische Möglichkeiten (nach
dem
Ausdrucken auf Papier).
- Parallelport
- Soundkarte

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
0.5 mm betragen kann man auf einer A4 Seite um die 28kB speichern. Die
Kodier-Software ist einfach geschrieben, das Einscannen/Dekodieren ist
ein bischen aufwändiger.

bye, Dan

 

[Dan Oprisan]

"Dan Oprisan" <dandy1313@yahoo.com> schrieb im Newsbeitrag
news:cbu231$mv6$1@rzsun03.rrz.uni-hamburg.de...

"Markus Bauer" <mc_@gmx.net> schrieb:

Unterm Strich bleiben einfach nur 2 realistische Möglichkeiten
(nach
dem
Ausdrucken auf Papier).
- Parallelport
- Soundkarte

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
0.5 mm betragen kann man auf einer A4 Seite um die 28kB speichern.
Die
Kodier-Software ist einfach geschrieben, das Einscannen/Dekodieren
ist
ein bischen aufwändiger.

1MB wären 35 Seiten. Wenn du Papier sparen willst, kannst du ja das
Bild als Bitmap auf dem Monitor anzeigen und mit einer Web-Cam
einlesen. Das heisst natürlich weniger Pixel/Bild (vielleicht 10.000)
aber dafür mehr Bilder/sek

 

[Stefan Heinzmann]

Dan Oprisan schrieb:

"Dan Oprisan" <dandy1313@yahoo.com> schrieb im Newsbeitrag
news:cbu231$mv6$1@rzsun03.rrz.uni-hamburg.de...

"Markus Bauer" <mc_@gmx.net> schrieb:


Unterm Strich bleiben einfach nur 2 realistische Möglichkeiten

(nach

dem

Ausdrucken auf Papier).
- Parallelport
- Soundkarte

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

0.5 mm betragen kann man auf einer A4 Seite um die 28kB speichern.

Die

Kodier-Software ist einfach geschrieben, das Einscannen/Dekodieren

ist

ein bischen aufwändiger.


1MB wären 35 Seiten. Wenn du Papier sparen willst, kannst du ja das
Bild als Bitmap auf dem Monitor anzeigen und mit einer Web-Cam
einlesen. Das heisst natürlich weniger Pixel/Bild (vielleicht 10.000)
aber dafür mehr Bilder/sek

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.

--
Cheers
Stefan

 

[Heinz Saathoff]

Stefan Heinzmann 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.

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


- Heinz

 

[chris]

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

Heinz Saathoff <hsaat@despammed.com> wrote in message news:<MPG.1b4c830fe9a70539989757@news.arcor.de>...

Moin,

Markus Bauer schrieb...
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*.

Unterm Strich bleiben einfach nur 2 realistische M glichkeiten (nach de
m
Ausdrucken auf Papier).
- Parallelport
- Soundkarte

Wenn Du Zugriff auf den Rechner hast und es Dir erlaubt ist, den Rechner
aufzuschrauben, dann w rd' ich einfach tempor r (oder dauerhaft, falls

gestattet) ein billiges Diskettenlaufwerk einbauen.
Das mit der Soundkarte w rd' ich vergessen. Dan besser auf Parallelport,

dort mit 2. Rechner oder Controller einen Drucker nachbilden.

- Heinz

 

[Michael Redmann]

Stefan Heinzmann 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.

Oder von einem Chinesen abtippen lassen. Oder besser von dreien, um
Tippfehler zu erkennen.
--
Michael Redmann
"I don't want ANY spam!" (Monty Python, 1970)

 

[Markus Bauer]

Hallo,

Carsten Kurz <audiovisual@t-online.de> dixit:

Markus Bauer schrieb:

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*.

Unterm Strich bleiben einfach nur 2 realistische Möglichkeiten (nach dem
Ausdrucken auf Papier).
- Parallelport
- Soundkarte

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

Habe ich geschrieben - nein.

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.

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

 

[Markus Bauer]

Hallo,

Thomas Forster <thomas.forster@t-online.de> dixit:

Markus Bauer schrieb:
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*.

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

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

mfg

markus

 

[Markus Bauer]

hi,

Heinz Saathoff <hsaat@despammed.com> dixit:

Markus Bauer schrieb...
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*:

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

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