Beiträge von gandro

    Woher hast du den Code? Du wirst damit nicht erreichen können was du willst.

    Mit fopen("LPT1", "w") macht nämlich das Betriebssystem die Ansteuerung der Pins, in dem es ein Byteprotokoll fährt, was abhängig von den Daten alle möglichen Pins setzt und liest; und auch erwartet da auch dass der Drucker Befehle ordentlich bestätigt. Im schlimmsten Fall ist hinter dem Port "LPT1" gar kein Parallelport-Drucker angeschlossen, sondern irgend ein virtueller Drucker der gar nicht erst Pins hat.

    In deinem Fall hast du ja aber keinen Drucker angeschlossen, sondern eine eigene Schaltung ohne Logik. Das heisst du musst die Pin auch selber setzen, und das geht dann nicht mit einem Byteprotokoll, sondern auf PCs klassischerweise mit den INP/OUT Befehlen.

    Lass dich von folgendem Text nicht abschrecken, klingt und sieht alles furchtbar kompliziert aus, das hier ist eher eine grobe Zusammenfassung; ich erkläre aber gerne alles nochmals im Detail:

    Spoiler anzeigen


    Die Idee dahinter ist, dass jeder Pin ein Bit einer Addresse zugewiesen bekommt. Für LPT1 sind das klassischerweise die Adressen 0x378-0x37f (kann aber variieren). Hier die Übersicht, welcher Pin welche Addresse hat: https://en.wikipedia.org/wiki/Parallel_port#Port_addresses

    Die Idee ist also, dass wenn du z.B. den Pin Nr. 5 (D3) ansprechen willst, dass du in der Tabelle da nachschlägst, und dann siehst: Pin Nr. 5 ist in der Base-Adresse (also 0x378) das das 4. Bit.

    Der Code um das Bit zu setzen würde dann in etwa so aussehen (Pseudocode, hab weder Windows, noch C++ oder gar nen Parallelport hier):

    short base = 0x378; // Base-Adressechar byte = 1 << 3; // schreibt die Eins von der 1. Stelle 3x nach rechts, so dass sie an 4. Stelle stehtOut32(base, byte); // setzt Pin Nr. 5 (D3) auf 1, alle anderen auf 0

    Das Auslesen der Pins funktioniert ähnlich mit inp32, ist allerdings etwas mehr Bitfiddling. Beispiel Pin Nr. 10 (ACK) =Adresse base+1, Bit 7:
    char data = !!(Inp32(base+1) & (1 << 6));

    Unter modernen Windows Versionen funktioniert das leider aus Sicherheitsgründen leider nicht mehr direkt, aber es gibt extra Treiber namens "inpout32.dll" dafür, siehe: http://logix4u.net/parallel-port/…dows-982000ntxp (kitsunes Link verwendet den ebenfalls, da hast du auch den Code drin wie man den Laden muss).

    Ne das Problem ist halt dass es erlaubt ist, mehrere Nullblöcke zu einem zusammenzukürzen. Dadurch kommts zu Mehrdeutigkeiten wie in dem Wiki-Ausschnitt da. Sinnvoll wäre gewesen, die Adresse als 2001:0db8:::8d3::: zu schreiben. Zwischen allen :: wären dann halt Nullen gewesen.


    Achso, naja. :0: und :: geben sich ja wenig, und sowas ::::: ist jetzt auch nicht unbedingt lesbar (wobei dann muss mans auch nicht schreiben). Finde ich jetzt nicht unbedingt fragwürdig, vermute mal dass die halt auch davon ausgegangen sind, dass der Enduser seine 64bit ggf. auch ggf. kurz halten will, ähnlich wie die localhost-Addresse (die mit deiner Regel auch nicht wirklich lesbar wäre :::::::1)

    Aber sicherlich ein diskutabler Kritikpunkt, im Gegensatz zu dem unfundierten FUD und Bashing was shadowtux hier mal wieder betreibt.


    Was die geraucht haben frag ich mich eher bei so Sachen wie ":: darf nur einmal in der Adresse verwendet werden", da gibts keinerlei synataktische Notwendigkeit für.


    Öh.. naja.. doch?

    Wollte zuerst selber ein Beispiel bringen, aber die Wikipedia hats ja selber schon ausformuliert:

    Zitat

    Die Reduktion durch Regel 3 darf nur einmal durchgeführt werden, das heißt, es darf höchstens eine zusammenhängende Gruppe aus Null-Blöcken in der Adresse ersetzt werden. Die Adresse 2001:0db8:0:0:8d3:0:0:0 darf demnach entweder zu 2001:db8:0:0:8d3:: oder 2001:db8::8d3:0:0:0 gekürzt werden; 2001:db8::8d3:: ist unzulässig, da dies mehrdeutig ist und fälschlicherweise z. B. auch als 2001:db8:0:0:0:8d3:0:0 interpretiert werden könnte. Es empfiehlt sich den Block mit den meisten Null-Blöcken zu kürzen.

    Heute mal ein Paper (via John Carmack): http://research.cs.wisc.edu/vertical/paper…truggles-tr.pdf

    Habs noch nicht gelesen, aber Kernaussage soll sein: Ob man RISC (ARM, µCs) vs. CISC (x86) Prozessoren hat spielt heutzutage weder bei Performance, noch bei Stromverbrauch eine Rolle, die konzeptionellen Unterschiede sind total irrelevant.

    Oder noch einfacher formuliert: Die weit verbreitete Annahme, dass man x86 nicht ordentlich auf Mobiltelefone, oder dass man ARMs nicht ordentlich auf Server kriegt, ist schlicht falsch. Es ist alleine Frage der Implementation wie viel Wumms der Prozessor hat, oder wie energieeffizient er ist, Intels 40 Jahre Legacy sind jedenfalls nicht das Hindernis.

    Kein Mensch kauft ne 5 Kiloeuro-Software und beschwert sich dann über die fiese FPU-Performance auf seinem Raspberry Pi (mir wär kein sonstiger verbreiteter General Purpose ARM-Rechner bekannt). Von daher halte ich es wie oreissig schon gesagt hat nach wie vor für absolut irrelevant, was ARM für ne FPU-Leistung hat. Wer Profi-Numbercrunching betreiben will hat dafür eh Profihardware (lies: Fette Workstation, evtl. GPU oder zumindest CPU mit ordentlich FLOPS) und nicht Consumerhardware.


    Also ich hab die obige Befehlszeile mal so eingetippert. Da wird mir der komplette Bildschirm zugeschrieben, aber mit allen möglichen Sachen. Wenn ich das recht in Erinnerung habe, sollte der doch nach dem String "CONFIG_ISA" in der Datei /proc/config.gz suchen, richtig?


    Ja. Der Befehl war sogar falsch gabs jetzt geändert, ^CONFIG_ISA$ sollte gar nichts ausgeben. Du hast schon zgrep verwendet, und nicht grep? Aber wie gesagt, bei grml ist das alles dabei, hab ich nachgeschaut.

    Hab keine Erfahrung damit. Aber:

    Würde zuerst mal sicherstellen dass dein Kernel mit ISA-Support noch kompiliert wurde: zgrep CONFIG_ISA /proc/config.gz

    Falls du keine Ausgabe hast, wurde dein Kernel ohne ISA-Support kompiliert. ISA_DMA_API findet man bei modernen Kerneln noch, hat aber nichts mit ISA an sich zu tun, zählt also nicht. Auch sicherstellen dass du einen 32bit-Kernel fährst, x86-64 kann kein ISA mehr. Nachtrag: Auch nötig: CONFIG_SND_ISA für ISA-Soundkarten, CONFIG_ISAPNP für PnP. Der grml-i486-Kernel scheint das aber zu haben.

    Der ganze Thread hier erinnert mich an die Nekochan-Threads von oreissig, wo die ganzen Hobbyisten tief und fest behaupten dass man altes IRIX auf igendwelchen RISC-Kisten ja noch produktiv verwenden kann, weil Firefox 2.0 ja läuft und x86 eh überbewertet sei. IRIX sei das viel modernere Betriebsystem.

    Klar "kann" man mit WinXP noch produktiv sein. Kann man auch mit Windows 98 SE noch, halb aktueller Opera und KernelEx erlauben es vermutlich den meisten hier ihren täglichen Workflow zu erledigen. Trotzdem wird kein Mensch mit Verstand Geld in eine SGI, Win98SE oder WinXP Geld als Arbeitsgerät investieren, weil entweder keine Software dafür mehr gebaut wird, oder weil es abzusehen ist, dass aktuelle Software und Updates darauf nicht mehr laufen wird.

    Natürlich gibt es weitaus mehr XP-kompatible Software als Win9x. Trotzdem wird sich das in den kommenden Monaten drastisch ändern, wie auch die ganze Win9x Software auf einen Schlag eingestampft wurde vor paar Jahren. Und das machen die Entwickler nicht aus Marketing-Gründen, sondern weil für alte APIs zu programmieren scheisse viel Zeit und Mühe kostet, weil XP eben nicht mehr modern ist, jedenfalls nicht in einer sinnvollen Definition von modern.


    Ich bin mit XP irgendwie nie richtig warm geworden. Schon mein Ersteindruck wurde durch die Teletubbieoptik tief negativ geprägt. Das letzte richtig gute NT war in meinen Augen 2k


    Dies (Rest des Beitrags stimme ich nicht zu). XP SP2 war kurz nach dem Release einigermassen zeitgemäss und modern. Zu allen anderen Zeiten war es hässlich, lahm, unsicher und/oder masslos veraltet.

    Öh.. was? Star Wars war immer schon Mainstream. Die originalen Star Wars Filme waren unter anderem die ersten Filme das Label "Blockbuster" gekriegt haben damals.

    Ausserdem gibt auch Mainstream Actionfilme mit Story und CGI ohne dass davon etwas in den Hintergrund rückt, man verweise auf Matrix 1 oder so.

    Wollte gestern Abend den Beitrag hier noch schreiben und meine Meinung zu den kleinen Updates mal machen: Nicht nur OSX macht das so, sondern auch iOS und Ubuntu. Gerade Ubuntu schon sehr lange und trotzdem erfolgreich, die werden ihren Zyklus sogar noch verkürzen. Und auch betriebsystemartige Software wie Browser fahren damit ja sehr gut. Rapid-Release war das beste was dem Web passieren konnte, die ganzen coolen Web-Technologien setzen spürbar schneller durch.

    Jedenfalls Ubuntu und OSX zeigen: Weder Updatekompatibilität noch Administartion ist ein grosses Problem. Halte die Ängste da für unberechtigt.

    Und es ist auch das zeitgenössische Modell. Die langen Releasezyklen von mehreren Jahren kommen aus Zeiten wo man Software noch per Telefon bestellt hat, und dann irgendwann nen Service Pack für dem fiesen Bug organisiert hat. Auch unterlagen Consumer-Rechner einer schnellen Entwicklung, so dass ein neues Betriebsystem halt auch Sinn gemacht hat für neue Hardwarefeatures. Aber die Zeiten sind halt auch definitiv vorbei. Seit Windows Vista ist kaum mehr was technisch relevantes passiert, weil auch kaum jemand was noch vermisst. Da hat der User von kleinen Updates mehr von als "alle zwei Windows-Versionen überspringen", was ja eh alle machen.

    Sehe das mit der Kernelversion nicht als Problem. Linux ist sehr problemlos von 2.6 auf 3.0 gewechselt. Problem bei Vista war nicht die Versions-Nummer, sondern die tatsächlichen Änderungen. Wenn WINE ne Fake-Versionsnummernverwaltung kann, dann wird da Microsoft problemlos in der Lage sein sowas einzubauen. Ausserdem zwingt Microsoft ja keinen für die nächsten zehn Jahre ne andere Version als 6.2 oder 6.x zu verwenden. Linux 2.6.x gabs auch zehn Jahre lang.