Posts by rayden

    Darf ich ganz ketzerisch fragen warum man sich in Zeiten der pi1541, die als Zero ja eher fast nix kostet sich mit sd2iec beschäftigt?

    Ultimate 2 als Nobelvariante steht ja auch zur Verfügung...

    Beide unterstützen meines Wissens nach kein DNP (also 16Mb Native-Images). Und ja... es gibt Leute die das brauchen und für die ist ein pi1541 mit D64 oder auch D81 nicht ausreichend. Das kann auch ein UII+ oder TC64 nicht ändern...

    DNP ist tatsächlich ein Punkt....ja

    Ich musste mich erstmal schlau machen, was DNP überhaupt ist: 16mb Drive Native Partition von CMD.


    Und daher frage ich jetzt mal ganz ketzerisch: Wäre es nicht einfacher, die Dateien aus einem DNP zu extrahieren und in eine "normale" directory-Struktur (also so, wie ein jeder seinen Kram organisiert) wegzuspeichern?


    Zumal ein derartiges Speichern (also nicht als DNP) es imho auch einfacher macht, die Daten als Backup vorzuhalten oder auf unterschiedlichen Medien einfach zu speichern und auch zu nutzen.


    Oder wird das DNP Image so oft geändert und auf original-Hardware zurückgespielt?

    Geschickt, geschickt! Der nächste Poll ist dann mit euren Adressen gefolgt von Urlaubs-Daten. Und dann geht die große Einbruchsserie los :D

    Dann schließt das aber den oder die Täter auf einen kleinen Kreis der Mitglieder hier ein. Die finden wir! :achtung:aetsch:

    Spätestens mit der nächsten Umfrage bez. der vorhandenen Anzahl an Geräten ;)


    Aber es ist doch furzegal, wieviel Geräte jemand hat: Hauptsache er denkt, er hätte genug.

    C64 kann man allerdings nie genug haben und solange noch Platz ist... :)

    Diese Tastaturen sind anscheinend für Anwender gedacht, die häufig längere Texte mit 10 Fingern tippen.

    Ich habe aber eigentlich ständig eine Hand an der Mouse und tippe dann häufig nur mit der linken Hand, damit ich nicht jedesmal die Hand von der Mouse nehmen muss.

    Schonmal eine von diesen IBM-Tastaturen mit dem roten Pömpel (aka pointing stick, nub oder nipple - waaah, er hat nipple gesagt!!!) in der Mitte in Erwägung gezogen? Da brauchste keine Maus mehr, sondern kannst den Mauszeiger mit dem Pömpel bewegen.

    Dann könnte es auch mit zehn Finger klappen ;)

    Uhm, soooo: Ich bin nun endlich mal dazu gekommen, meinen SwinSIDx8 zu bestücken und zu testen.

    Die SID-Sockel zählend von 0-7 habe ich folgendes Problem:

    Wenn ich einen normalen SID-Tune (also nur $D400 als Basis) abspiele, so habe ich auf SID 2 und SID 6 "passend" zur Musik gelegentliche Störgeräusche: Mal fiepen, mal rauschen. mal knupsern.

    Wenn die ATMEGAs untereinander getauscht werden, wandert der Fehler _nicht_ mit.


    Die Störgeräusche klingen so, als würde kurzfristig der ein oder andere Schreibzugriff, welcher für $D400 als Basis bestimmt war, auf einer andern Basis-Adresse ausgeführt werden.


    Verbunden sind A5 => 1, A6 => 2, A8 => 3. Somit sind die Adressen $D400, $D420, $D440, $D460, $D500, $D520, $D540, $D560

    Ebenfalls tritt der Fehler bei Verwendung von A7 anstelle A8 auf.


    Verbaut ist ein SN74LS138N (Von Texas Instruments glaub ich).

    Board ist ein 250407, die Adress-Leitungen habe ich am Color-RAM abgegriffen.


    Da es "passend" zur Musik auftritt und stets auf SID 2 und SID 6 passiert (getestet mit Abziehen von Jumper Audio L/R), vermute ich den Fehler bei der Adress-Generierung; also dass gelegentlich nach $D400 als Basis, stattdessen die $D440 oder $D540 genommen wird.


    Habe ich einen "doofen" LS138N erwischt und sollte den einfach mal tauschen oder bin ich damit auf dem Holzweg und der Fehler liegt woanders?

    Ich kann absolut nicht nachvollziehen wie man sich ein Ultimate64 Board kauft ohne im Vorfeld sich ausgiebig damit zu beschäftigen und zu recherchieren.

    Och nöh, komm:)

    Ich hab mir damals auch das Ultimate64 "einfach" gekauft, ohne imich rgendwie damit wochenlang zu beschäftigen. Dazu habe ich mir nagelneue Tastaturhalter aus Edelstahl gekauft - nur um dann festzustellen, dass der rechte mit dem Ultimate64 nicht passt.

    Klar, wer lesen kann, ist klar im Vorteil, aber was solls. Ich habe mir dann so 3D-Druck Dinger in schwarz machen lassen sodass das Board in ein C64C Gehäuse in Beige passt.

    RAM, PLA, ROMs und/oder Logik-ICs sind dann eher der Grund des Defekts, der sich aber oft sehr schnell beheben lässt. So habe ich schon viele "defekte" C64 gekauft, die eigentlich Ersatzteilspender werden sollten, aber dann doch "zu einfach" zu reparieren waren. Wird schnell eine unendliche Geschichte! :)

    Ja, die Ersatzteil-Kaskade - wer kennt sie nicht? ;)


    Ich würde C64 kaufen. Viele der als "defekt" deklarierten waren zumindest bei mir nicht defekt.

    So hat man immer ein paar Ersatzteile auf Halde.

    Ausserdem kann man nie genug C64 haben ;)

    Meine ATMEGAs sind tatsaechlich diese Woche aus CN angekommen! Die hatte ich ja erst kuerzlich im April bestellt. 8o8o8o
    Also kann es die Tage auch bei mir los gehen.

    Meine ATMEGAs von Herrn Ma haben sich als Reinfall entpuppt: alle 20 Stück machen Krach, kreischen und zischen - wenn sie denn nicht das gesamte System mit wirren Zeichen zum Absturz bringen.

    Programmieren/verifiy lief einwandfrei durch...

    Die vier Stück, welche ich als Ersatz von der blauen Apotheken mit dem "R" gekauft hatte, laufen hingegen einwandfrei.


    Ich wünsche Dir mehr Glück und berichte bitte :)

    Hm, Run/Stop und Restore funktionieren einwandfrei. Ich bin mir nicht sicher, ob das Problem beim RR-/AR-Freezen mit /NMI zu tun haben könnte, da beim Freezen ja wohl auch mittels #$38 => $01 Daten "durch die Gegend" kopiert werden (ohne jetzt mir den Freezer-Code angeschaut zu haben.)


    Wie kann ich /NMI prüfen? Also wo und wie muss ich meine Messgriffel an PIN 4 der CPU halten?


    Edit: An Pin4 auf GND messe ich 4,7V.

    Ja, tut es:

    Code
    1. sei
    2. lda #$38
    3. sta $01 ; sta $0001 und ldx #$00 sta $0001,x ebenfalls freeze
    4. loopme:
    5. inc $0400
    6. jmp loopme

    Exakt einmal wird dann $0400 inkrementiert, dann freeze. Nur Reset bringt wieder Leben in die Bude.


    Es muss auch kein INC/DEC sein, es reicht schon ein simples CLC oder SEC:


    inc $0400 wird nicht mehr ausgeführt.

    Selbiges gilt auch, wenn anstelle inc $0400 z.B. CMP, PHP, PLP, PHA, PLA


    LDA #$30, LDA #$31, LDA #$32, LDA #$33, LDA #$34, LDA #$35, LDA #$36, LDA #$37 => KEIN Freeze, $0400 wird wie erwartet endlos inkrementiert

    LDA #$38, LDA #$39, LDA #$3A, LDA #$3B, LDA #$3C, LDA #$3D, LDA #$3E, LDA #$3F => Freeze

    LDA #$07 => KEIN Freeze

    LDA #$08 => Freeze

    (Die Sinnhaftigkeit dieser Werte für $01 sei mal dahingestellt.)


    Es scheint, als ob im Falle von #$38 => $01 jegliche Manipulation des Processor Status Register für einen Freeze sorgt.


    Alles ausgeführt aus dem RR/AR Monitor mit SEI.


    EF3 hängt dran, emuliert ein Retro-Replay. Beim System-Freeze funktioniert der RR-Freeze-Button nicht. Bei einem original AR6 ebenfalls nicht.

    Im Basic-Screen ist mittels Button ein RR-/AR-freeze möglich, aber beim wieder Starten kommt kein cursor mehr, also System wieder eingefroren.


    Das Board macht _definitiv_ irgendwie die CPUs kaputt:

    Wenn eine kurz zuvor in ein, zwei anderen Boards (beide Boards OK) 100%-ig funktionierende/getestete CPU in dieses Drecks-Board kommt, dann sind die Probleme da. Wenn diese CPU dann in die beiden vorgenannten OK Boards gesteckt wird, so kann der Fehler mit dieser CPU auch auf diesen beiden Boards reproduziert werden. Kommt auf die vorgenannten OK Boards dann wieder eine funktionierende CPU, so ist alles in Ordnung. Somit ist die einzige Konstante das Drecks-Board in Kombination mit CPU.

    Ich bin ratlos...

    Jetzt tät ich nur mal gerne die Ursache wissen, da dort schon soviel Zeit reingeflossen ist - denn das Board war ein Kandidat für den SwinSIDx8 oder SwinSIDx16 :)

    Nur um sicher zu gehen:

    Wenn von A6, A7, A8, A9 etc. die Rede ist, dann handelt es sich stets um die Adress-lines, wobei es absolut egal ist, ob ich diese z.B. vom BASIC, KERNAL, CPU, Color-RAM, Cartridge-Port oder sonstwo von Mainboard hole?


    Ich suche nämlich gerade in den Schematics von 250407 und 250425 nach einer opportunen Stelle, an der ich mittels Pin-Header und Dupont-Stecker die benötigten Adress-lines abgreifen kann.


    Denn mittels Pin-Header fände ich schöner, als direkt an die IC-Beinchen zu brutzeln. Notfalls von unter dem Board an Lötaugen, wobei dann ja das Kabel recht lang wird oder ist das nicht relevant?

    Code
    1. 250407, 250425, address lines
    2. address | U3 | U4 | U5 | U6 | U7
    3. A5 | 3 | 3 | 3 | 2 | 12
    4. A6 | 2 | 2 | 2 | 1 | 13
    5. A7 | 1 | 1 | 1 | 17 | 14
    6. A8 | 23 | 23 | 23 | 16 | 15
    7. A9 | 22 | 22 | 22 | 15 | 16

    Matthias Gibt es die Code-Injektion-Karte nur für den Modular 64 oder auch für das 64 Tuning Board?


    Wie muss ich mir die Verwendung vorstellen:

    C64 (Als Synonym für 64 Tuning Board) via USB an Mac/PC und dann kann ich dort mit dem Editor meiner Wahl meinen Code runterschreiben und kompilieren und das Kompilat wird dann direkt auf den C64 übertragen und gestartet?

    Also vom Prinzip würde das im workflow bei mir dann den Vice auf dem Mac zum Testen und Debuggen ersetzen, weil ich dann auf "echter" Hardware teste? Oder wie oder was? :)

    Kannst Du dazu mehr Details sagen?

    Den ATmega dann mit dem HEX aus dem ZIP "beschießen". Die korrekten Fuses habe ich hier im Thread mal gepostet, so zwei-drei Seiten vorher.

    Uhm, jetzt bin ich verwirrt:

    Der ATMEGA88@DIP28 hat 8192 bytes flash memory, aber die SwinSID-Firmware hex-files sind zwischen 17kb-20kb gross:

    17973 bytes, SwinSID88_20141027.hex

    20173 bytes, SwinSID88_20141019_lazy_fix_by_ck_patched_no_ping2.hex

    17445 bytes, SwinSID88_20141019_lazy_fix_by_ck.hex

    17781 bytes, SwinSID88_20120524.hex


    Wie passt das denn zusammen?


    Edit sagt

    Quote

    The HEX file will be more than twice the size of the binary. That's because each byte is represented by two ASCII characters, and there is some additional overhead such as address, data length, record type and checksum information. Oh, and end of line markers.


    Also sind die hex files mehr als doppelt so gross, weil jedes Byte durch zwei ASCII-Zeichen codiert wird und noch anderer Kram wie Adressen, Datenlänge, Prüfsummen-Kram und sowas mit hinzu kommt.