Gideon wird das U64E-II weiterhin verkaufen, bis Commodore komplette Systeme liefern kann.
Oooh, FOMO! Schnell noch eine U64-Platine kaufen bevor der Vertrieb eingestellt wird?
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
Gideon wird das U64E-II weiterhin verkaufen, bis Commodore komplette Systeme liefern kann.
Oooh, FOMO! Schnell noch eine U64-Platine kaufen bevor der Vertrieb eingestellt wird?
Soweit ich mal gelesen habe, ist diese Darstellung kein echtes Dokument sondern eher "Fan-Art" oder so.
Die Faktoren wirken auch etwas beliebig. Vielleicht kann man ja anhand des Fonts herausfinden von wann das Dokument frühestens stammen kann - Arial/Helvetica scheint es wegen der Form der 9 schonmal nicht zu sein, aber die könnte zu Tahoma und Verdana passen.
dass die Ursache der Wirren in der Art des RAM-Musters nach der Initialisierung liegen muss. Kann mich grad nicht erinnern welche Emulatoren genau es nun "eher richtig" oder "eher falsch" machten, mittlerweile wird sowas eh gefixt sein.
Das doofe ist, dass es beim Muster im uninitialisierten RAM kein "richtig" oder "falsch" gibt weil das zwischen zwei C64 abweichen kann. Ich würde mich nicht wundern wenn man in der gesammelten historischen C64-Software mit RAM-Init-Pattern-Abhängigkeiten zwei finden kann, die nicht mit dem gleichen Muster funktionieren können.
Der VIC "klaut" nämlich in bestimmten Takten der CPU den Bus Zugriff. (Beispielsweise durch DMA und Bad Lines)
Und auch das muss 100% simuliert werden. Das ist unter anderem eben beim Ultimate nicht ausreichend genau gewährleistet und ein Hauptgrund, warum einige Demos nicht so laufen wie auf original Hardware
Na ja, das sind aber gut dokumentierte Grundlagen. Wer einen C64 ernsthaft nachbilden will wird das von Anfang an berücksichtigen.
Ich programmiere Dir einen IRQ der im Vice eine Rasterzeile bist zur Hälfte "blöd flackern" lässt, wovon Du auf einem originalen C64 überhaupt nichts siehst.
Auf einem aktuellen x64sc einerseits und allen C64-Permutationen (zB neue/alte CIAs, diskrete oder integrierte Logik) andererseits? Zeig mal, das wäre dann nämlich ein Bug und das Testprogramm könnte vielleicht in der Testsuite landen.
Sony PVM 9042
50 Hz, letzte entwicklungsstufe der Trinitron Röhren
In der Reihe gabs aber noch den gleichgrossen 9045 mit besserer Röhre.
Weshalb man da einen Menüpunkt hat für etwas, das nicht implementiert ist, muss man nicht verstehen.
Da war doch was von wegen "unvollständig und nie fertigimplementiert"?
Warum man das damals so gemacht hat statt safe einfach für einen C90 Kassette?
Kopierschutz?
ja, genau, mit ~60€ Porto super Schnapper gegenüber Ali und Sammelbestellungen, ist hier irgendwie verpön
Wie kommst du denn auf 60 EUR Porto bei Mouser? Die wollen nur 20 EUR (+MWSt) bei normaler Versandart für Kleinbestellungen, ab einem Warenwert von 50 EUR (zzgl MWSt) ist der Versand kostenlos.
3,5% schneller abspielen
oh, sehr interessantes Projekt, aber der LPC1769 mit ~75€ beim Alimann......
Kauf halt bei seriöseren Quellen?
Was gibt's denn sonst noch zu testen?
Eventuell Epyx Fastload? Das Originalmodul macht Sauereien mit einem Kondensator an EXROM, der durch ein paar Gatter an Reset, IO1 und ROML entladen wird und sich aus dem Pullup von EXROM wieder auflädt.
64er Kernal oder 1541 Kernal?
In der 1541 gibts kein Kernal, nur DOS-ROMs.
Aus reiner Neugier, wäre das mit Professional Dos auch machbar?
Vielleicht? Ursprünglich wollte ich SpeedDos implementieren, aber da hatte ich nach kurzer Zeit keine Lust mehr weil das bei LOAD nochmal Drivecode ins Laufwerk lädt, der wild ins gepatchte Laufwerks-ROM springt und davon jede Menge verschiedene Versionen existieren, die einzeln unterstützt werden müssten. DolphinDOS war da einfacher, das schickt nur ein spezielles Kommando - die Timingunterschiede zwischen den Versionen sind erst deutlich später aufgefallen.
Sprich: kann ich knicken?
Läuft schon, aber es muss der richtige Dolphin-Kernal sein. Leider habe ich gerade keine Datei zum Anhängen greifbar.
Es gibt mindetens zwei verschiedene DolphinDos-Kernal, die leicht unterschiedliches Timing verwenden und ARM2IEC ist nur mit einem davon kompatibel. Alle bisherigen Versuche das Timing mit beiden kompatibel zu machen sind gescheitert, möglicherweise habe ich irgendein Detail im Original-Floppy-ROM übersehen, das funktioniert nämlich mit beiden ohne Probleme.
Wenn Du genau hinschaust, siehst Du das die Datenleitungen A/B6 und A/B7 direkt an die Leiterbahn geflickt wurden.
Ah! Das war im Bild nicht so gut zu erkennen, auf den ersten Blick schienen die Verbindungen da ganz zu fehlen und die gekreuzten Leitungen waren einfacher zu beschreiben.
Das Resultat ist nicht unbedingt schön, funktioniert aber
Ich glaube mindestens eine der Datenleitungen ist falsch angeschlossen, die Drähte von den schwarzen Bauteilen (ESD-Dioden?) kreuzen sich.
Zeilenweises Update von oben nach unten, mit Nachleuchten und Ausfaden der gerade gescannten Zeilen.
Hier gibts sowas als Demo-Shader, wenn dein Display schnell genug ist.
Nun habe ich dabei aber festgestellt, dass die jüngere Platine (die mit den Störstreifen urspünglich) sämliche Keramikkondensatoren an der Unterseite der Platine NICHT hat!
Scheint eine Alternativ-Bestückungs-Möglichkeit zu sein. Bei den Fotos mit SMD-Bauteilen scheint immer ein bedrahtetes Bauteil parallel vorgesehen, aber nicht bestückt zu sein während bei den Fotos deiner Problemplatine bedrahtete Bauteile eingelötet sind wo SMD-Bauteile "fehlen".
Ich frag mich ja, wie gangbar es wäre, ein digitales Signal aus dem analogen Chroma-Luma-Signal zu synthetisieren.
Na ja, du kannst (bei nicht-uralten VICs) die Helligkeit digitalisieren und auf 9 Stufen quantisieren um die mögliche Farbe des Pixels auf zwei Optionen zu reduzieren, dann müsstest du "nur" noch mittels Phasen- und evtl. Amplitudenvergleich des Chroma-Signals herausfinden welche der beiden Möglichkeiten es ist.
Oder du decapst einen 8565 und bondest feine Golddrähte an die vier Testpunkte, die vermutlich den Farbcode des aktuellen Pixels ausgeben, aber das hat meines Wissens noch nie jemand ausprobiert.
Nun frage ich mich, was macht er da? Schon die erste Adresse wäre ein RTS. Und dann kann ich in dieser Folge gar kein System dahinter finden.
Bist du denn sicher, dass alle Leitungen korrekt angeschlossen sind? A9 hängt dauerhaft auf Low.
Von welchem Zeitpunkt nach dem Reset-Puls ist die Aufzeichnung? Kannst du in deinen Aufzeichnungen den Zugriff auf dem Reset-Vektor erkennen? Der sollte innerhalb der ersten paar Taktzyklen erfolgen.