Haben oder hatten massive Probleme mit den Systemboards. Bosch war da wohl auch betroffen.
Die beiden gehören im Hausgerätebereich eh zusammen.
Posts by Unseen
-
-
Bin mal gespannt, ob das dann läuft.
Aber welches Spiel ist es? Und vermute ich richtig, dass es ein Bootleg ist?
-
Tolle Konfiguration, ich würde noch etwas hinzufügen:
1) Intel Core i7 8700K
Der läuft aber nicht in dem angegebenen Board.
Ausserdem sollte man solche Empfehlungen schon begründen, insbesondere wenn die empfohlenen Komponenten deutlich teurer sind.
-
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.
-
Lichterkette auf Schaltregler umgebaut um keine Batterien mehr zu brauchen:
-
Haben diese Tapecarts gegenüber einer U1541 oder einer Easyflash Vorteile oder Features, die mit den letztgenannten nicht umsetzbar sind?
Der Expansionsport bleibt frei
-
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.
-
Looks nice. Open source?
-
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)
-
Jetzt bin ich hin u. her gerissen ob ich das Siegel aufbreche, oder es lieber sein lasse?
Ein intaktes Garantiesiegel ist inzwischen eigentlich nur ein Indikator für eine von zwei Möglichkeiten:
1) Der Rechner ist innen verdreckt weil ihn noch nie jemand gereinigt hat
2) Jemand hat ein neues Siegel draufgeklebt
-
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)
-
Zwischen Datenpfad und dem Decode-Rom liegt noch ein bischen Logik. Aber das verschweige ich jetzt mal.
Ist ja nur etwas mehr als eine halbe A0-Seite
-
Bei Lattice sind die wenigsten offen für Open Source Tools.
"Offen" ist eine seltsame Umschreibung für ein ohne Hilfe von Lattice durchgeführtes Reverse Engineering des Bitstreams.
Ist das IceStorm eigentlich schon brauchbar?
Das ist jetzt Teil von SymbiFlow
-
Hatte einen i7 2600k am laufen (Sandy Bridge). Und der wird in https://docs.microsoft.com/en-…ws-processor-requirements nicht aufgelistet.
Das ist ja auch die falsche Tabelle, da steht drin was der neueste unterstützte Prozessor der jeweiligen Windows-Version ist. Die Mindestanforderungen finden sich hier und die werden vom einem i7-2600K locker erfüllt.
-
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.
-
ISE und Impact habe ich installiert -- aber ich dachte, die helfen mir nur bei Xilinx CPLDs
Impact kann beliebige (X)SVF-Dateien abspielen, auf dem Weg kann man damit auch Nicht-Xilinx-Chips programmieren. Das ist ein Format, um im Prinzip beliebige JTAG-Kommandosequenzen als Textfile darzustellen.
-
Das sollte bei JTAG ja nicht unbedingt nötig sein.
JTAG spezifiziert nur wie man mit den vier Signalen am IC interne Register von selbigem ansprechen kann, aber das Hostinterface des JTAG-Adapters und auch die Programmierbefehle sind leider nicht Teil des Standards.
-
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.
