Posts by Unseen

    Schon das kann der VIC-II leider nicht wirklich gut, weil er nur einmal Color RAM hat, das nicht umgeschaltet werden kann...

    Da liesse sich doch bestimmt was basteln um das Farb-RAM auf die vierfache Kapazität zu erweitern und passend zur gewählten VIC-Bank umzuschalten. Getrennt steuerbare Bänke für CPU und VIC bräuchte aber irgendwo mehr Portbits.

    Das stimmt vermutlich, ändert aber nichts daran, daß man üblicherweise keine Pullups verwendet, die so niederohmig sind, daß ein Problem entstehen könnte, das man mit <=100 Ohm hätte beheben können.

    Da du dich ja mit der Thematik anscheinend so gut auskennst: Wie viel Strom können denn die Chips mit Ausgabepin auf High treiben, die auf dem Board als Pegelwandler für die in Frage kommenden Ausgangssignale des Expansionsports angeschlossen sind?


    Bonusfrage: Wie gross darf der Pullup am zugehörigen Eingangspin dieses Chips maximal sein, damit der seinen Ausgang auf High schaltet?

    Wenn sich Gideon (aus welchen Gründen auch immer) dazu entschieden hat, die 5V am Expansionsport schaltbar zu machen und sie derzeit erst aktiviert, nachdem er High-Pegel an IO1/IO2 anlegt, klingt es für den Laien nicht unmöglich, die 5V zu aktivieren, bevor der FPGA High-Pegel an IO1/IO2 anlegt.

    Ob das funktioniert kommt darauf an, wie die externe Elektronik auf den uninitialisierten Zustand des FPGAs vor seiner Konfiguration reagiert. Falls das zB wegen default-aktiver Pullups als "5V an, IO1/IO2 high" interpretiert wird gibt es auf jeden Fall einen Zeitraum von bis zu einigen hundert Millisekunden, in denen der unerwünschte Zustand am Expansionsport anliegt.

    Mein Batronix ist von 2006, die GALeps sind aus dem vorherigen Jahrtausend und ich bekomme für BEIDES noch (Device-)Updates und Support!

    DAS ist QUALITÄT und DAS WAR mal die Basis von DEUTSCHLANDs Erfolg und Wohlstand!

    Mein J-Link ist von 2008 und Segger (Deutsche Firma mit Sitz in Monheim) supportet den schon lange nicht mehr - wenn man Chips mit neueren CPU-Kernen debuggen will muss man sich eine neuere Revision davon kaufen. Für das Trade-in-Programm (maximal 50% Rabatt auf den Listenpreis) ist das Ding inzwischen auch zu alt.


    (Segger ist übrigens älter als Batronix, aber jünger als Conitec)

    Wir haben es nicht lange angeschaltet gelassen, damit ggf. der Ram nicht gleich wieder durchbrennt

    Wenn die Versorgungsspannung zu hoch ist dann sollte man erstmal das Problem damit lösen bevor man ICs tauscht. Wenn die Versorgungsspannung ok ist wüsste ich keinen Grund warum die ausgetauschten RAMs "durchbrennen" sollten.

    Bei den 1571 Tests wäre insbesondere interessant, ob auch CP/M Mode mit MFM-Kodierung drüber läuft!

    Die 1571 hat keinen "CP/M-Mode" und das C128-CP/M verwendet natürlich auch ganz normales Commodore-GCR für seine Bootdisk. Nur wenn man eine schon MFM-formatierte Disk ins Laufwerk legt oder im CP/M-Formatierprogramm ausdrücklich ein MFM-basiertes Fremdformat auswählt wird die MFM-Funktion des Laufwerks vom C128-CP/M verwendet, aber die Laufwerksbefehle zum Lesen/Schreiben/Formatieren von MFM-Disks lassen sich auch ohne CP/M nutzen.


    (leider hat Commodore in den Befehlssatz dafür einen Fast Serial/"Burstmode"-Zwang eingebaut)

    Was bedeutet das?

    Das bedeutet, dass der Test "ane" nicht das erwartete Ergebnis erhalten hat - aber das ist bei diesem speziellen Test nicht so schlimm, der Opcode ist instabil und liefert nicht auf allen Chips und Systemen das gleiche Ergebnis. Der Test wartet dann auf einen Tastendruck bevor es weitergeht.


    Kann man die ganzen Opcodes nicht überspringen?

    Wenn ich mich recht erinnere muss man nicht zwangsweise mit dem "start"-Test anfangen sondern kann einen beliebigen aus dem Satz laden+starten.

    Oben steht doch 2,9us.

    Das ist der Trigger-Offset



    Ich weiß nicht, wie Du auf diese Zahl kommst.

    Da gibts diverse Rechenwege, zB kann man vom CPU-Takt von (leicht gerundet) 985248Hz ausgehen und mit den bekannten 8 Pixeln (1 Char) pro Takt multiplizieren um auf 7881984 Pixel pro Sekunde zu kommen, was im Kehrwert die oben erwähnten ca. 127ns pro Pixel sind.



    Das Bild hat 625 Zeilen -> 1,6ms/Zeile

    Eine Zeile hat 576 Pixel/Bildpunkte -> 2,8us/Pixel

    Zum einen hat ein C64-Bild keine 625 Zeilen: Das wäre die Zahl für zwei reguläre PAL-Halbbilder mit Interlacing, aber ein C64 gibt ein nicht-interlacetes Signal mit 312 Zeilen pro Bild aus. Zum anderen gibts bei PAL nicht nur ein Vollbild pro Sekunde sondern gleich 25 (bzw. 50 Halbbilder) - und beim C64 wegen einiger Abweichungen zur Norm sogar noch ein wenig mehr (50.1 oder so).


    Die 576 Pixel pro Zeile sind für den C64 auch sehr daneben, ich meine es wären inklusive Blanking bei PAL 504. Bei echten PAL gibts keine feste Definition weil es ein Analogsignal ist und die Pixelzahl von der Samplerate abhängt.

    Are you sure the CPLDs you bought are real and new or is there a chance that they are fake and/or used? If they are used but real, the chip may have been programmed with security features enabled, in the worst case even with "can never be reprogrammed" settings.

    Da sieht man, dass die Signale abwechselnd unterschiedliche Amplitude haben. Ein solcher Block ist etwa 2,9us.

    Laut Scope-UI in dem Bild sind das 50 us/div, da sind gar nicht genug Pixel im Bild um 2,9us erkennen zu können. Ausserdem sehe ich gerade, dass da gerade mal mit 5 MSample/s aufgezeichnet wurde, das ist für die 4.43MHz des Farbträgers zu wenig.


    Das entspricht nicht einer Zeile, sondern etwa einem Pixel. Eine Zeile dauert 1,8ms.

    Ein Pixel sind bei einem PAL-C64 ca. 127ns, eine Zeile ca. 63,9 Mikrosekunden.

    Hast Du Dir mal das Oszi-Diagramm oben angesehen? Daran sieht man, dass es vom C64 kommt.

    An welchem davon denn? Das Luma-Signal wurde hier nur so grob dargestellt, dass man nicht genug Details in der Kurve sehen kann um die Abweichung zwischen einzelnen Pixel zu erkennen, und das als angeblich rauchende Pistole präsentierte Bild "alternating saturated pixels" hat 50us/div zeigt also die Abweichung der Farbamplitude zwischen benachbarten Zeilen und ist daher erst recht viel zu grob um per-Pixel-Details erkennen zu können.


    Übersprechen zwischen Chroma und Luma im Kabel oder im Modulator scheint mir noch lange nicht ausgeschlossen zu sein.

    Ehrlich gesagt verstehe ich den Text nicht so wirklich. Ich bin nicht sicher, ob die beschriebenen Bugs in meinem Fall wirklich ein Problem sind. Letztendlich halte ich die Daten zunächst in einem BASIC-Programm fest. Und dann lasse ich dieses laufen und es erzeugt die REL-Datei. Falls die REL-Datei durch irgendwelche Bugs beschädigt wird, ist das nicht so schlimm. Dann lasse ich das Erzeuger-Programm einfach nochmal laufen.

    Und dann ist die Datei wieder kaputt - der Bug ist ziemlich zuverlässig reproduzierbar wenn man ungünstige Bedingungen erwischt hat. Den Positionierbefehl zweimal senden umgeht den Bug zuverlässig und kostet kaum Zeit.



    Aber wenn man an einem Spiel arbeitet, das aus dutzenden von Dateien besteht, dann ist es schon recht umständlich, möchte ich mal meinen.

    Gerade für die Entwicklung finde ich viele Einzeldateien praktischer als einen einzelnen Container, aber das kommt möglicherweise von Gewohnheiten aus der PC-basierten Entwicklung, wo make und vergleichbare Tools existieren, um automatisch Veränderungen an Quelldateien zu suchen und daraus neue Zieldateien zu erstellen.


    Für direkte Entwicklung am C64 hat REL noch den Nachteil, dass das nur sehr wenige Filecopier damit umgehen können.

    Nun dachte ich mir, es wäre auch toll für die 1581 und habe dementsprechend die T(racks) auf 40 und die S(ektoren) auf 3 gesetzt,

    um dies dann auch für die 1581 zu nutzen, aber da passiert leider gar nichts.

    Kein Wunder, 40/3 ist bei der 1581 der erste Directory-Sektor. Um aus Sicht des Laufwerks alle freien Blöcke zu belegen müsstest du in der BAM in den Sektoren 40/1 und 40/2 alle Bytes zwischen Offsets 16 und 255 auf 0 setzen. Falls du wie im BASIC-Schnipsel den Directory-Track unverändert lassen willst dann musst du die letzten 6 Byte in 40/1 unverändert lassen.