Posts by Unseen

    Gibt's dazu weitere Info's?

    Was muss man da ungefähr machen?Widerstan

    Mit geeigneten Mitteln messen, mit welchem Gesamtstrom die LEDs bei Batteriebetrieb wohl typischerweise betrieben werden (bei mir: ca. 350mA unter Annahme von nicht mehr ganz vollen Batterien), eine dafür passende Konstantstromquelle beschaffen (bei mir: Meanwell LDD-350L, zB von Pollin), den in der Lichterkette verbauten Widerstand überbrücken, Ausgang der Konstantstromquelle an die Batteriekontakte löten, Kabel an den Eingang der Konstantstromquelle löten und nach aussen führen.


    1117-3.3 dran und per USB oder 18650 Akku versorgen? Oder ist das nicht so trivial?

    3,3V wären für diese Lichterkette zu wenig, die wird von drei Mignonzellen versorgt. Ich hatte überlegt ob ich nicht einfach den Vorwiderstand etwas erhöhe und USB zur Versorgung einsetze, aber die KSQ lag eh ungenutzt in der Bastelkiste und erlaubt 9-36V Eingangsspannung, wodurch ich die Lichterkette am geplanten Einsatzort wahrscheinlich aus einem eh rumliegenden KNX-Bus speisen kann.

    Es sollte 'mal ein SD2IEC mit Unterstützung für lange Filenamen entwickelt werden -die max. nur acht Letters sind da extrem nervig

    sd2iec unterstützt lange Dateinamen, aber wegen Kompatibilität mit existierender C64-Software nur mit maximal 16 Zeichen. Bei längeren Namen wird der "8.3"-Dateiname verwendet weil der im Gegensatz zu von sd2iec selbst gekürzten Namen garantiert eindeutig ist.

    but it has major flaws like 2 MB Flash ROM

    Twice the size of an EasyFlash

    Nothing has been done in 3 years since creation to improve it

    EasyFlash also has seen no updates


    Finally someone bring TapeCart to the level it should be from the start.

    No, the Tapecart is exactly been what it was intended to be: A stable, open platform that can be built at very low cost.


    Author of PRGuino Remzi gave credits to all devs

    "Gave credit to" is nice, but might not fulfill all requirements of the licenses of the software that he used.


    Oh, and closed source sucks and limits your market reach. =)

    Du redest meines Erachtens von was ganz anderem, nämlich der Abbildung einer CISC-CPU auf einen RISC-Kern, wie Intel das seit 486/586 macht.

    Fast, Intel hat beim Pentium Pro damit angefangen. Der erste x86-Chip nach dem Prinzip war der Nexgen Nx586, die Firma hat dann AMD aufgekauft und basierend auf der Technik wurde der K6 entwickelt.

    Das wird dort mit einer Microcode-Architektur erledigt, die CISC-Befehle auf RISC-Befehlsstrukturen umsetzt. Da wird ggf. auch in "Tabellen" gewühlt und diese "Firmware" (der Microcode eben) kann auch aktualisiert werden.

    Zum K6 gibt es ein Buch, welches die Architektur sehr detailiert beschreibt: The Anatomy of a High Performance Microprocessor von Bruce Shriver.

    Gab es das denn Anfang der 80er Jahre schon? (Abgesehen von den frühen Ansätzen z.B. von Seymore Cray wurde da ja das, was wir heute RISC nennen entwickelt, oder?)

    Der erste RISC-Prozessor war der IBM 801, der aber erstmal nur als Controller für die Peripherie anderer IBM-Geräte verwendet wurde, weswegen lange MIPS und SPARC als die ersten RISC-Architekturen galten. Die Cray-I hat zwar wie einige zuvor von Seymore Cray designte Systeme eine RISC-ähnliche Load-Store-Architektur, wird aber im allgemeinen nicht als RISC-System bezeichnet - zB sind die Instruktionen verschieden lang.


    (wobei feste Instruktionslänge heutzutage eh nicht als zwingendes RISC-Merkmal gilt, siehe zB Thumb 2 bei ARM oder microMIPS bei MIPS - der geringfügig höheren Komplexität beim Decodieren der Befehle steht eine bessere Ausnutzung der Speicherbandbreite und Cachekapazität gegenüber und die Geschwindigkeit vom Speicher ist historisch deutlich langsamer angewachsen als die der CPUs)

    In dem Link wird beschrieben, wie es HEUTE gesehen wird.

    Der Artikel ist nicht besonders gut und streckenweise komplett falsch... Hier wird mit mehr Fachwissen auf das Thema eingegangen, aber leider sind viele der Detailartikel in dem Wiki nicht im Archiv gelandet.



    Nicht wie es DAMALS entstand. Das ist ein riesen Unterschied.

    Was man unter RISC versteht hat sich im Laufe der Zeit immer wieder geändert: "the statement in the 70s about (801/)RISC was that it could be done in a single chip. later in the 80s, (801/)RISC was instructions that could be executed in single machine cycle. Over the decades, the definition of RISC has been somewhat fluid ... especially as the number of circuits in a chip has dramatically increased" (Zitat von Lynn Wheeler aus obigem Artikel)

    Dass es nun unbedingt GTK sein musste ... ok, jeder hat so seine Vorlieben. Ich persönlich mag Qt sehr viel lieber.

    Ein Teil des VICE-Teams hat starke C++-Phobien, teils auf Basis von Unwissen und Missverständnissen. Selbst C99 wird nicht vorbehaltslos akzeptiert.

    Aber der Inhalt muss ja dann schon zum Ziel passen, also zum Atmel CPLD in diesem Fall. Erzeugst Du die SVF Datei trotzdem mit den Xilinx-Tools (ISE/Impact)?

    Eine SVF-Datei kann nur ein Tool erzeugen, dass den zu programmierenden Chip kennt und dazu reicht eine BSDL-Datei nicht aus - die beschreibt zwar ein paar Chip-Eigenschaften, aber im Falle von Impact wird davon AFAIK nur so viel ausgewertet wie nötig ist, um bei einer Kette aus mehreren hintereinandergeschalteten Chips den zur Datei gehörenden zu ignorieren.


    Kann vielleicht einer der Wissenden etwas aus der Ausgabe des VSF-Player ablesen? Ist es richtig, dass er auf alles, was gesendet wird, scheinbar nur Nullen zurückbekommt?

    Wahrscheinlich ist das nicht richtig. Der Player sollte eigentlich bei jedem Kommando, welches einen TDO-String enthält diesen gegen die empfangenen Daten vergleichen und bei Unterschieden abbrechen. Da bei dir nur 0en zurückkommen stimmt wohl irgendwas mit der Kommunikation mit dem Chip nicht oder der Player steuert das Interface nicht richtig an.

    OK, es liegt wohl am Resonator. Mit lfuse 'e2' gehts nicht. 'ff' gibt mehr Zeit beim Startup/Reset oder so

    lfuse e2 wäre der interne RC-Oszillator, der ist nicht genau genug für die Fastloader-Routinen des Tapecart - sonst wäre der Resonator nicht im Design drin.


    Der in der Anleitung empfohlene Wert ist ef, das unterscheidet sich nur durch die Verzögerungszeit zwischen Oszillator-Start und Loslaufen der AVR-CPU. Beim Tapecart sollte das keinen Unterschied machen, da das nur beim Einschalten des C64 passiert und es deutlich länger dauert bis der Benutzer die Gelegenheit hat, Shift+Run/Stop zu drücken.