Bestimmt ein Haarriss an der Platine.
...oder einfach eine kalte Lötstelle.
You are about to leave Forum64 to get redirected to the following address:
Please note, that the target website is not operated by us. We are not responsible for it's content nor does our privacy policy apply there.
Bestimmt ein Haarriss an der Platine.
...oder einfach eine kalte Lötstelle.
Ja, ich. Funktionierte einfach nicht, im Emulator. Save und Load ja, Scratch nein.
Mit @ lief es gleich einwandfrei.
Dafür hast Du nicht zufällig noch den nicht funktionierenden Beispielcode parat?
Ich halte es nämlich für deutlich wahrscheinlicher, dass Du das "s" (für "scratch") falsch kodiert hast, als dass das emulierte Laufwerk ein Problem mit dem Löschen von Dateien hat...
Prüf mal CIA2 und den Bustreiber dahinter. Beim Starten im 128er-Modus wird für die Autoboot-Funktionalität ein Diskzugriff gemacht, und wenn eine der Leitungen fest auf GND hängt, bleibt der Rechner an dieser Stelle stehen.
Für einen schnellen Test kannst Du auch die beiden CIAs miteinander tauschen, bei einem CIA-Defekt würde der Fehler dann zur Tastatur wandern.
Das Programm von disk laden, dann stop drücken und in einer schleife RGW 25,192+X von 0-7 laufen lassen.
scrollt smooth.
Achtung, das klappt nur bei v1- und v2-VDCs. Beim relativ seltenen v0-VDC gibt es Probleme - hier müsste irgendwo ein Beitrag von mir herumlungern, wo es genauer erklärt wird.
wenn das Smooth Scrolling Register von 7 auf 0 springt (oder umgekehrt), ist ein ruckeln wohl nicht zu vermeiden.
so liest man das auch an anderer Stelle.
hab auch alle drei register über SYN gesetzt: selbe Problematik.
Doch, das bekommt man auch ruckelfrei hin. Das Problem ist, dass Änderungen im Scrollregister sich sofort auswirken, Änderungen an den Basisadressen aber ggfs. erst im nächsten Frame. Genauer: Am Ende des Textfensters werden die Basisadressen für den nächsten Frame gesetzt, also die Werte aus den Registern kopiert.
Man muss also vor dem Ende des Textfensters die Basisadressen für den nächsten Frame setzen und nach dem Ende des Textfensters die Scrollregister setzen.
Für Filecopy hatte ich immer Unicopy von der Test-/Demodiskette verwendet. War mit JiffyDos ausreichend schnell.
Wenn man eh Jiffy-DOS hat, kann man einfach das eingebaute Filecopy nehmen, also den "*"-Befehl.
Muss man nur vor einem END ggf. rückgängig machen, sonst flippt die Position beim Scrollen aus. (oder halt Run/Stop Restore hämmern)
...deswegen wäre es schön, wenn $Leute auch erklärten, warum eine Methode funktioniert und welche unerwünschten Nebeneffekte damit auftreten können.
Dazu gibt es irgendwo im Forum schon einen Thread.
Und zwar den hier.
Ist bei fast jedem TTL-IC so und somit kann ein 01 nicht andersherum auf der Platine sein. Die Gatter sind auch anders angeordnet. Man kann also 00 nicht gegen 01 tauschen.
Dazu gibt es irgendwo im Forum schon einen Thread.
Soweit ich mich erinnere, gibt es schlicht und einfach zwei Versionen von dieser Mausplatine. Bei der zweiten Version wurden 5V und GND anders zu dem Chip geroutet und deshalb muss dort der andere Chiptyp verbaut werden, und dann eben "anders herum" (damit die Gatter gleich plaziert sind, aber 5V/GND anders herum).
Noch anders gesagt: Es gibt eine Platine, auf die ein 74LS00 gehört, und eine zweite Platine, auf die ein 74LS01 gehört.
Direkt $d018 abfragen, in der Zeropage o.ä. gibt es keine Kopie.
Wer das mal probezocken will (es gibt mehrere Enden): https://drwuro.com/zeha/adv/
EIN MEISTERWERK!
edit: vergessen den Tipp zu erwähnen:
Die Textfarbe für das Farb-RAM des kompletten Screens man mit PRINT"{FARBE}{CLR}" vorab setzen, dann spart man sich ggf. den extra POKE 56295,farbe.
...das funktioniert aber nur bei Kernalversion 3. Einige 64er sind noch mit Version 2 unterwegs, daher sollte man sich nicht auf diese Methode verlassen.
EDIT: Da Kernalversion 2 das Farb-RAM mit der Hintergrundfarbe füllt, kann man, wenn es denn unbedingt sein muss, diesen Workaround verwenden: Man setzt sowohl die Hintergrundfarbe als auch die Schriftfarbe auf die gewünschte Schriftfarbe, dann löscht man den Screen, dann restauriert man die Hintergrundfarbe. Das funktioniert mit beiden Kernalversionen.
Bei Kernalversion 1 hilft auch das nicht, aber die ist nun wirklich extrem selten und in PAL-Geräten vermutlich gar nicht anzutreffen.
Ich hab's schon mit Zählern versucht (ich zähle bei ELSE hoch und bei DONE wieder runter)
Warum denn bei ELSE hochzählen? Zähl bei DO hoch und bei DONE runter, dann ist jedes bei Zähler <> 0 gefundene ELSE in einer tieferen Ebene und somit zu ignorieren.
Tip vom sauhund: Erst mal einen anderen Crack des gleichen Spiels ausprobieren.
Woran kann diese Anomalie liegen?
Es kann ein RAM-Defekt sein, ein einziges Bit reicht ja. EDIT: Bei Rot würde es reichen. Bei Rosa nicht, da unterscheiden sich zwei Bits von Schwarz.
Oder ein Defekt im VIC.
Oder der Programmierer hat sich auf nicht initialisiertes RAM verlassen, aber das hätte schon jemand merken müssen in den letzten 40 Jahren.
Aber es betrifft NUR dieses eine Spiel! Daher ist eigentlich ein RAM-Fehler auszuschließen.
Nee, das ist kein Grund. Mit einem einzigen defekten Bit im Hauptspeicher läuft noch ne ganze Menge.
Lass den Mac Bacon RAM-Test mal laufen.
Da bin ich auch für.
"nicht initialisiertes RAM" ist wie gesagt unwahrscheinlich, aber in den Lesezeichen meines Profils findest Du auch ein "memset"-Programm um vor dem Laden des Spiels den Speicher vollzuschreiben. Probier das mal mit beiden Boards.
Kann ich das so verstehen, dass jedes Byte im Speicher auf 8 Chips aufgeteilt wird und jeder Chip 65536 Bits speichert?
Bei den älteren Modellen ist das so, ja. Bei den neueren Modellen sind dann DRAM-Chips drin, die immer vier Bits gleichzeitig übernehmen, so dass jedes Byte auf zwei Chips aufgeteilt wird.
Ich habe gerade mal wieder die Tabelle gesucht, welche Bits in welchem Chip gespeichert sind. Und nachdem ich sie gefunden hatte, musste ich feststellen, dass eines der Woltlappen-Upgrades die Formatierung zerstört hat (alle Spaces am Anfang der Zeile entfernt). Daher kopiere ich sie jetzt hier hin:
Ursprünglich stammt diese Tabelle aus der Doku eines Diagnose-Cartridge, nämlich von "http://personalpages.tds.net/~rcarlsen/cbm/misc/diagcart/readme.txt"
Glück gehabt, es ist nur der Chip für Bit 4 defekt. In RAM-Bank 1 entspricht das U50.
C64-Modus in RAM-Bank 1 starten, memtest laufen lassen. Beide Programme sind über die Lesezeichen meines Profils auffindbar.
Hier mal auf die schnelle die Seiten aus dem genannten Buch bezüglich MMU gescannt.
Danke.
Zitat von Seite 522: "Hinweis: BASIC verwendet die LCRs und die PCRs nicht."
Zitat von Seite 526: "Beachten Sie, daß das BASIC ebenfalls auf die PCRs zugreift."
...und das war jetzt bei weitem nicht der einzige Klopper, der mir auf Anhieb auffiel.
Übrigens, in den Bookmarks meines Forumsprofils befindet sich auch ein Link zu meinem U36-Source. Der funktioniert auch für externe Module.
Kann ich irgendwie einen Hardware Reset auslösen?
Wenn Du ein Modul baust: Natürlich, die Leitung liegt ja am Expansionsport an.
Wenn ich mal im C64 Modus bin, komme ich irgendwie zurück in den C128 Modus, per Software?
Rein per Software geht das nicht. Aber wenn Du ein Modul baust, kannst Du ja einen Reset auslösen.
Wenn ich mal im C128 Modus bin, komme ich irgendwie in den C64 Modus, per Software?
Natürlich, wie sonst sollte ein "GO64" funktionieren?
Was passiert, wenn ich im C128 Modus bin und /EXROM auf low ziehe?
Nichts.