Posts by Unseen

    das mit der "Dirty"-Maske war ja nur ein auf die Schnelle zusammengeklöppelter Implementierungsvorschlag.

    Verallgemeinere es doch auf einen Stencil-Buffer mit genauso viel Bit pro Pixel wie für die Farbauswahl verwendet wird und ein paar konfigurierbaren logischen Verknüpfungen, dann kann man mit dem System zB in Quelle und/oder Ziel einzelne Farben als transparent deklarieren indem man die Quelle oder das Ziel als Lesequelle des "Dirty"-Buffers verwendet

    Hatte ja vor ein paar Beiträgen eine andere Möglichkeit vorgestellt, wie man ohne echte Sprites mit einer Art HW-Multiplexer zu einem ähnlichen Ergebnis kommen kann. Aber anscheinend war das zu länglich als daß es jemand gelesen hätte.

    Gelesen hatte ich es, aber ich dachte mir, dass ein "Das braucht aber auf den ersten Blick ziemlich viel Speicherbandbreite und häufige Umschaltung zwischen Lesen und Schreiben" hier zu destruktiv ankommen würde.

    An den OSSC kann man Scart anschließen, also auch einen C64 mit Scart Kabel.

    Nein, der OSSC kann keine modulierten Farbübertragungssysteme (PAL/NTSC/SECAM) decodieren. Das Eingangssignal muss RGB oder YPbPr ("Component") sein.


    Weiß man es ?

    Natürlich weiss man es. Das Ding ist Open Source, man muss nur mal in die Quellen schauen.


    Ansonsten wird das eher kein Problem.

    RTINGS testet sowas gerade.

    und HDMI müsste man erst auf HD-SDI konvertieren, das geht aber mit vergleichsweise billigen externen Konvertern

    Das klappt aber leider nur mit einer sehr kleinen Zahl von Formaten - normale HDMI-Eingänge sind da meist flexibler. Mir ist zumindest noch kein Monitor oder Konverter untergekommen, der ED-SDI (SMPTE 344M) implementiert, um 480p und 576p verwenden zu können.

    Wie hättest du sie denn entfernt damit es professionell ist, mit Aufklebern

    Gar nicht. Die verwendeten Chips sind der langweilige Teil und mit der Platine in der Hand kann man die anhand des Pinouts und der Funktion relativ sicher herausfinden. Zum Nachbauen bräuchte man den FPGA-Bitstream und wer gut genug ausgestattet ist um dessen Auslese-/Kopierschutz zu überwinden, der lässt sich von abgeschliffenen IC-Bezeichnungen nicht aufhalten.


    Oder anders interpretiert und gefragt, warum ist es ohne Bezeichungen abkratzen professioneller als wenn man sich die Arbeit dazu macht ?

    Entfernte Bezeichnungen auf den Chips kenne ich vor allem aus Billigkram aus China und meines Wissens ist der Prozess schlecht für die Lebensdauer der Chips.


    MachXO2!?

    Wäre meine erste Vermutung, ohne auch nur die Pins gezählt zu haben =)

    Wie bekomm ich das Teil kostengünstig und unkompliziert wieder zum laufen.

    Gegen eine andere Platte austauschen. Die IC35L-Reihe gehört zu den "Deathstar"-IBM/Hitachi-Platten, die besonders häufig ausgefallen sind. Meine persönliche Quote bei denen lag bei vier von zwei Platten (erster Ausfall jeweils in der Garantiezeit, zweiter bei den Tauschplatten nach Ablauf)

    dass (in Anlehnung an C++) eine objektorientierte Version von Cobol "Cobol giving Cobol increased by one" heissen müsste

    "add 1 to Cobol giving Cobol"


    Ich habe gelesen, das die Sprache bewusst so gehalten wurde, damit sie für die Nutzer leicht nachvollziehbar ist. Aber bei dem geringen Speicher der damaligen Rechner, war das wirklich so sinnvoll?

    Ich kenne Cobol nicht im Detail, aber ich könnte mir vorstellen, dass der Compiler den Quelltext nicht komplett in den Speicher lädt sondern immer nur zeilenweise oder in kleinen Häppchen und diese dann compiliert. Laut Wikipedia war das allerdings am Anfang auch nicht gerade schnell: "Early COBOL compilers were primitive and slow. A 1962 US Navy evaluation found compilation speeds of 3–11 statements per minute. By mid-1964, they had increased to 11–1000 statements per minute. It was observed that increasing memory would drastically increase speed and that compilation costs varied wildly: costs per statement were between $0.23 and $18.91"

    Es gibt keinen herstellerübergreifenden Automatismus, mit dem eine Bildquelle dem TV Bescheid sagen kann, dass Overscan aus sein soll.

    Doch, die Scan Information-Bits im CEA-861 Auxillary Video Information InfoFrame, welches zB von HDMI übertragen wird. Leider werden die meines Wissens nur selten vom Display ausgewertet, im Gegensatz zu den im gleichen Byte befindlichen Bits zur Farbcodierung (verpflichtend) oder den im nächsten Byte folgenden Bits zum Bildformat (4:3/16:9/..., funktioniert auf ca. 50% meiner Geräte)

    Die ersten beiden wurden von M. J. abgeschmettert, weil VGA den jeweils höchsten Modus nicht darstellen kann.

    Ich weiss leider nicht wie viel Luft sein Design vom Timing her hat, aber wenn es den Schritt von 25,175MHz auf 27MHz Pixeltakt verkraftet wäre ein normkonformes 720x480-Videoformat machbar, das meist auch auf VGA-Monitoren funktioniert. Allerdings hat es den Haken, dass die Pixel nicht quadratisch sind.