270 Mbit/s aus dem PC schaufeln - möglich?

Linards Ticmanis wrote: : Hallo allerseits,

: ich hab mich ein bisschen in analoge Fernsehnormen eingelesen und die : Feinheitden der Bruch'schen Sch?pfung, und 'nen YUV4MPEG nach PAL : Software Encoder geschrieben (bisher nur S/W aber Farbe kommt nach, : vielleicht wird der Code auch noch in mplayer integriert). Das Problem : ist, der PC ist zwar ohne weiteres schnell genug das Signal zu : produzieren (die innere Schleife bleibt dank Tabellen bei knapp 20 : Assembler-Befehlen je Sample) w?hren gleichzeitig noch MPEG2 dekodiert : wird - nur: irgendwie muss es ja raus aus der Kiste in einen : Video-D/A-Wandler. Letzteres ist auch kein Thema, es gibt da offenbar : sowohl bezahl- als auch brauchbare 10-bit-Teile z.B. von Analog : Systems, die nur eine minimale Beschaltung brauchen.

: Wie bekomme ich also nun die Daten aus dem PC? 10 bit je Sample bei 27 : MHz sind immerhin 270 Mbit/s, und wenn ich, um Shiftregister u.?. zu : sparen, die Werte als 16 Bit ausgeben will, kommen sogar 432 Mbit/s ... : Bin f?r jeden Tipp zu diesen (noch etwas wirren) Gedanken dankbar,

Knannste mir mal einige Links oder Literatur mailen? Ich interessieree mich dafür.

not really. Erstens braucht man eine Platine. Diese gibt es fertig, also mit DecoderIC, bei zB Fischer Elektronik. Preis mangels Liste leider unbekannt.

Andere Hersteller haben das Board ohne DecoderIC auf Lager, dieses gibt es unter openCore als programmierbare Logik. Programmieren musst du es aber selbst.

Robert

"Linards Ticmanis" schrieb im Newsbeitrag news: snipped-for-privacy@posting.google.com...

IDE-Kanal. Wenn es um so was wie ADV7128 als D/A-Wandler geht, kann der direkt an einen ansonsten nicht verwendeten IDE Anschluss vom Mainboard. Nicht unbedingt auf low voltage UDMA133 einstellen, aber PIOMode4 liefert direkt TTL-Signale, und das Port kann man vom Prozesor aus direkt ansprechen, rasendschnell. Eventuell muss man dem Betriebssystem erzaehlen, das es die Finger von dem Port laesst (aber welches Betriebssystem laesst dein Programm schon in Ruhe laufen ?)

Linards Ticmanis schrieb:

Hallo,

wie kommst Du auf 270 MBit/s? F=FCr die 625 Zeilen und 50 Hz=20 Vertikalfrequenz sollten 8 Bit und 10 MHz Abtastfrequenz, also 80 MBit/s =

reichen.

Bye

snipped-for-privacy@coli.uni-sb.de (Linards Ticmanis) wrote in news: snipped-for-privacy@posting.google.com:

Zur Speed: 270MBit/s sind 33MByte/s. Das schaffen aktuelle Chipsätze gerade so! Meistens sind es eher 25MByte/s. Schuld an dem Limit ist nicht nur der Client-Chip. Auch der Hostcontroller bestimmt die Geschwindigkeit. Es ist also ziemlich am Limit. Ich wuerde USB2 nicht verwenden (auch weil es komplizierter ist). Firewire ist da gleichauf. (Aber unmöglich ist es nicht).

Ob das Betriebssystem voellig latenzfrei arbeitet, daran möchte ich auch zweifeln (obwohl der ISO-transfer-Mode etwas anderes suggeriert). Theorie und Praxis sind da noch weit voneinander entfernt. Ich wuerde auch mal im Aussetzern im 100ms Bereich rechnen. (IDE-Zugriffe, APM oder Treiber fuer IR-Empfänger fallen mir als Stoerer ein). M.

| Natürlich könnte man auch eine Grafikkarte mit TV-Out nutzen, nur ist | bei denen die Bildqualität oft eher mäßig, die Timings sind kein | Norm-PAL, man muss sich mit Overscan rumärgern, dass teilweise nicht | komplett abschaltbar ist, das Refresh kommt irgendwann, nur nicht im | Takt mit der Bilderzeugung im PC, und unter Linux funktionieren sie | schon mal gar nicht richtig, jedenfalls nicht im 720x576-Modus. | Außerdem ist eine Eigenkonstruktion irgendwie cooler. ;-)

Hallo,

IMHO wirst Du besser daran tun, eine Grafikkarte entsprechend zu patchen. Wie das mit den modernen teilen ist weiß ich nicht, zu ET4000 Zeiten und drunter habe ich so manche Karte zu einem anderen Timing überredet, z.T. mit Oszillatorwechsel. Die allermeisten konnte man mit ein bischen Registerschieben zu den abenteuerlichsten timings überreden. Mich müsste wundern, wenn man nicht auch die 720*576 Bildpunkte über einen normalen Standardchipsatz nach draußen schieben kann. Da würd ich doch mal nach den Chipsatzbeschreibungen der üblichen Kandidaten S3 & Co nachschauen und dann gehts ohnehin in die Treiberprogrammierung, wo so etwas doch wohl saubererweise hingehört. Möglicherweise lässt sich auch eine TV-Out-Karet dazu überreden, bessere Signale nach draußen zu bringen, indem deren Chipsatz mit einer modifizierten Analogstufe getunt wird. Daran wird wohl am ehesten gespart, und wenn Du nicht gut im Analogdesign bist, dann wird Deine selfmade TV-Out auch nicht besser werden.

MArtin

en

Arcade VGA ist sowas, eine Radeon 9200 mit modifiziertem BIOS.

Ich denke das ist wahrscheinlich auch der beste Weg, eine normale Grafikkarte, die =E4lteren Radeons bieten sich an da dort afaik =F6ffentliche Dokumentation vorhanden ist, per Software auf TV Timing bringen und dann das Signal aus dem VGA Ausgang in das gew=FCnschte TV Signal umwandeln. RGB und YUV sind eh die besten beiden Varianten und lassen sich relativ problemlos aus dem VGA Signal erzeugen, sobald es erstmal das richtige Timing hat.

Jan

Hallo, danke für den Tipp, allerdings scheint es da eher um RF-Anwendungen und um Radiotechnik zu gehen... ich brauch nur Baseband.

Also einen guten zusammenhängenden, alle Details umfassenden Text hab ich im Web noch nicht gefunden... aber genug um sich's zusammenzupuzzeln. Besser wäre wohl ein gutes Buch über Fernsehtechnik, oder der offizielle ITU-R BT.470-6 Standard, der zwar nicht im Web steht (weil er Geld kostet), aber eigentlich in der Bibliothek einer vernünftigen E-Technik-Fakultät zu finden sein sollte.

Für den Anfang:

(letzteres ist eine recht alte Encoder-Chipbeschreibung, die aber einige Details des Signals gut erklärt, die auf den anderen Seiten höchstens gestreift werden, vor allem die berüchtigte "Bruch Blanking"-Sequenz).

Hmmm... haben die eine Webseite? In Deutschland scheint es diverse Firmen namens "Fischer Elektronik" oder "Elektronik Fischer" zu geben...

Ansonsten war das billigste was ich bisher gesehen haben bei ELV für

1. Und DMA-fähig sind die PCI-Teile, die ich gefunden habe, alle nicht, das könnte bei der nötigen Datenrate schon etwas problematisch werden. Dazu kommt, dass man bei USB unter Linux den Treiber schön bequem als Usermode-Programm schreiben kann.

Zu deutsch, erstmal Programmiergerät kaufen...

Vielen dank für die Tipps,

Also einen guten zusammenhängenden, alle Details umfassenden Text hab ich im Web noch nicht gefunden... aber genug um sich's zusammenzupuzzeln. Besser wäre wohl ein gutes Buch über Fernsehtechnik, oder der offizielle ITU-R BT.470-6 Standard, der zwar nicht im Web steht (weil er Geld kostet), aber eigentlich in der Bibliothek einer vernünftigen E-Technik-Fakultät zu finden sein sollte.

Für den Anfang:

(letzteres ist eine recht alte Encoder-Chipbeschreibung, die aber einige Details des Signals gut erklärt, die auf den anderen Seiten höchstens gestreift werden, vor allem die berüchtigte "Bruch Blanking"-Sequenz).

Hmmm... haben die eine Webseite? In Deutschland scheint es diverse Firmen namens "Fischer Elektronik" oder "Elektronik Fischer" zu geben...

Ansonsten war das billigste was ich bisher gesehen haben bei ELV für

1. Und DMA-fähig sind die PCI-Teile, die ich gefunden habe, alle nicht, das könnte bei der nötigen Datenrate schon etwas problematisch werden. Dazu kommt, dass man bei USB unter Linux den Treiber schön bequem als Usermode-Programm schreiben kann.

Zu deutsch, erstmal Programmiergerät kaufen...

Vielen dank für die Tipps,

War ich noch gar nicht drauf gekommen. Hast Du Erfahrung damit, IDE als Allzweck-Schnittstelle zu nutzen? Meistens denkt man ja dabei nur an Platten und CD-Laufwerke.

Zum Glück hat IDE ja ein wunderbar simples, einheitliches Lowlevel-Interface (fast so schön wie ein Apple-II-Bus ;-). Offiziell ist PIO 4 allerdings auf 16 MB/s beschränkt, die Frage wäre ob das an der Schnittstelle selbst liegt oder nur daran, dass auf PIO 4 eingestellte Festplatten-Laufwerke die Daten nicht schneller abholen? Wenn ersteres, müsste man wohl doch die DMA-Modi nutzen.

Wenn ich mir den zusätzlichen IDE-Port als Steckkarte ins System tue, könnte man die Schaltung direkt Huckepack auf die Pfostenleiste setzen, damit wäre dann auch kein langes Kabel nötig.

Leider müsste man da wohl für Linux einen Kernelmodus-Treiber schreiben, aber so schwer kann das ja eigentlich auch nicht sein.

Wenn ich noch nen FIFO einbaue (4 Mbit gibt es z.B. als fertigen Chip von OKI), was wohl eh nötig wird um die Ausgabe-Clock genau einzuhalten, sollten kurze Aussetzer in der Übertragung nicht mehr das Thema sein. Und insgesamt ist die Lazenz-Situation bei Linux ab Kernel

Gibt es einen neueren offiziellen IDE-Standard online? Ich hab bisher nur einen von 1993 gefunden, der dürfte nicht mehr so ganz arg aktuell sein. Und die Beschreibung in meiner PC-Hardwarebibel (Hans-Peter Messmer) ist inzwischen auch schon einige Jährchen alt.

Also jedenfalls klingt IDE nach ner guten Idee, vielen Dank für den Tipp!

Hallo Matthias,

Oben hat jemand den Tipp gegeben, IDE zu benutzen. Wäre mir eigentlich eh lieber, da es doch wesentlich simpler als USB ist, noch dazu warscheinlich um einiges billiger. Nur die Treiberprogrammierung würde etwas komplizierter, da man da wohl im Kernelmodus arbeiten müsste (/dev/port dürfte zu lahm sein vermute ich mal). Mal sehen wie's jetzt weitergeht.

Bei IDE-Zugriffen kann man mittels DMA und hdparm -u1 IRQ-Freigabe die Latenz schonmal absenken, APM kann man im BIOS abschalten und aus dem Kernel rauslassen, und IR-Empfänger hab ich nicht. Und irgend eine Form von FIFO wird wohl eh nötig sein.

Danke für die Infos,

Also die damals übliche ganze Reihe von Quarzoszillatoren findet man heute eher nicht mehr, da werden alle Timings aus einem einzigen gemacht...

Den müsste man dann aber irgendwie digital anzapfen können... vielleicht über das DVI-Interface? Mitten in einer industriell gefertigten SMD-Schaltung rumzulöten ist auch so 'ne Sache. Ich liebe zwar Hacks, aber das traue ich mir nicht unbedingt zu.

Nur so nebenbei, insgesamt (einschließlich Austastlücken) soll das ganze natürlich mit 864x625 laufen.

Hmmm die üblichen Conexant-Chips haben soweit ich weiß den D/A-Wandler intern, da kommt man an die Signale eher nicht ran. Ich hab die Datenblätter noch nicht gelesen (online scheinen die nur Verkaufsbroschüren zu haben), würde aber bezweifeln, dass die das PAL-Signal auch digital herausführen, schließlich will man als kostenbewusster Hersteller Pins sparen. Mal davon abgesehen, dass die Dinger das Bruch-Blanking und die PAL 8-Felder-Sequenz mit exakt

Also der Analog-Devices-D/A-Chip gibt in seinem Datenblatt recht genaue Infos darüber wie man die Ground Planes anordnen soll etc. Mit Schaltungen, deren Frequenzen über die einer Sondkarte hinausgehen hab ich zwar noch nicht gearbeitet, aber wenn man da der vorgegebenen Beschaltung folgt und alles ganz nah zusammen baut, einschließlich der RCA-Buchse -- es sind eh nicht viele Bauelemente auf der Analogseite, nur der Wandler, ein paar R und C, zwei Brücken mit Ferritperlen, und die Buchse --, dann sollte es doch eigentlich hinhauen, oder? Zur Not kann man ja den Chip auch noch eindosen, wie es früher bei den RF-Modulatoren der Heimcomputer immer gemacht wurde...

Danke,

Hallo Jan,

ich möchte eigentlich nichts, das irgendwie skaliert oder Framerates wandelt.

Da müsste ich dann allerdings einen analogen Encoder basteln... muss nicht sein. Das Timing ist zwar recht einfach machbar...

Modeline "PAL_CCIR" 13.5 720 734 800 864 576 580 583 625 -HSync

-VSync

aber dann wird's ätzend. Man könnte höchstens das Digitalsignal aus dem DVI-Interface mittels eines externen Mikrokontrollers verarbeiten. Aber kaum ein Mikrokontroller programmiert sich so leicht, ärgerarm und billig wie meine ganz gewöhnliche CPU im PC.

Ich weiß schon dass man damit bessere Bildqualität bekommt, es geht mir allerdings ausdrücklich darum ein Standard-PAL-Composite-Signal zu erzeugen.

Danke,

Hallo!

• "Linards Ticmanis" schrieb:

Bei Microcontrollern hast Du auf jeden Fall nicht die Timingprobleme, die in einem PC mit Multitasking-OS zu erwarten sind.

Ich finde die Idee, ein PAL-Signal allein in Software zu erzeugen, sehr interessant, aber ich glaube nicht, dass Du mit einfachen Selbstbau-Lösungen wirklich eine gute Signalqualität hinbekommst. Das Equipment, das "sendefähige" Signale auswirft, ein Heidengeld kostet, hat seine Gründe.

Ich habe mich aus Neugier mal ein wenig mit der Erzeugung von Videosignalen in Software beschäftigt (mit Microcontrollern als Grundlage). Fazit: es geht mit erschreckend simpler Hardware, die Qualität ist aber auch entsprechend mies. Und wenn am Ende ein Signal ala Chrontel-Encoder dabei herauskommt, hat sich die Mühe IMHO nicht gelohnt.

Für den Anfang wäre es vvl. nicht schlecht, aus einem richtig getimten VGA-Signal selbst PAL-Composite zu machen (ja, ich weiß, dass es dafür fertiges gibt).

Gruß, Till.

| Mit Schaltungen, deren Frequenzen über die einer Sondkarte hinausgehen hab | ich zwar noch nicht gearbeitet, aber wenn man da der vorgegebenen | Beschaltung folgt und alles ganz nah zusammen baut, einschließlich der | RCA-Buchse -- es sind eh nicht viele Bauelemente auf der Analogseite, | nur der Wandler, ein paar R und C, zwei Brücken mit Ferritperlen, und | die Buchse --, dann sollte es doch eigentlich hinhauen, oder?

Wovon träunst Du nachts?

MArtin

Macht es bei den richtigen Einstellung nicht. Es ging bei der Entwicklung der Karte wohl auch gerade darum. Einige Arcadegames nutzen exotische Modi mit 54Hz und =E4hnlichem und auch die wollte man ordentlic= h reproduzieren k=F6nnen ohne Spr=FCnge durch unpassende Framerate oder ei= n unscharfes Bild durch eine Skalierung. Standard TV Timings waren aber auch sehr =FCblich und lassen logischerweise auch einstellen.

us

Nimm doch einfach ein bisschen andere Modeline, verdoppel den Pixeltakt, mach den Rand soviel kleiner das du den Farbburst noch in den Framebuffer schreiben kannst und dann musst du eigentlich nur noch das Signal einer der RGB Leitung tiefpassfiltern, um 0,3V anheben, den Sync mit angepassten Pegel dazuaddieren und du solltest eigentlich ein ordentliches Signal haben. Das per Software erzeugte PAL Signal kannst du dann in den Framebuffer schreiben. Am besten nimmst du daf=FCr einen

Klingt irgendwie zu einfach, irgendwer hier der sich genauer mit PAL auskennt und dem was einf=E4llt, warum das so auf keinen Fall klappen kan= n? ;)

Jan

Schau mal auf

Tschüss Martin L.

"Linards Ticmanis" schrieb im Newsbeitrag news: snipped-for-privacy@posting.google.com...

Du brauchst den ATA-Standard eigentlich nicht zu lesen, (Millionen von Kommandos die dein D/A-Wandler eh nicht versteht) sondern nur die PC-Seite zu verstehen, und die ist ein simpler Bus, fast wie ISA-Slot nur mit schon decodierter Adresse und schneller. Allerdings muss man wissen, wie man BEI SEINEM Chipsatz die passenden Einstellungen programmiert. Dabei kann das BIOS einem helfen, schon mal die passenden Grundeinstellungen vorzunehmen, so das man nicht chipspezifischen Code braucht.