-
Mit dem nibtools (nibwrite -u) ist es ja möglich eine Diskette in den Unformatierten Auslieferungszustand wieder herzustellen:
-u[n] : Unformat disk for [n] passes (removes *ALL* data) This option alternates writing all sync, then all $00 bytes (bad GCR) to the entire disk surface, simulating the state of a brand new never-formatted disk.
Das funktioniert ja leider nur mit einer Parallelverbindung.
Gibt es denn so eine Möglichkeit auch über eine serielle Verbindung? Vielleicht mittels cbmctrl ?
Naja, dafür braucht es ja "nur" einen speziellen Code in dem Floppy Laufwerk.
Einen "unformat code" ...
Dann läuft es in jeder Commodore Floppy auch ohne parallel Kabel und einfach nur mit OpenCBM.
Aber ...
... wozu???
-
Mal davon abgesehen, wenn man so Modus hätte für standalone Format ...
... dann hätten alle Disketten denselben Namen und die selbe ID!
Auch nicht so praktisch.
-
Naja machbar wäre das schon, über ein eigenes Formatieren-DOS plus NMI 
Aber ... mir entgeht anscheinend der wirklich Nutzen an der Sache.
Auch wenn ich viele Disketten formatieren möchte, wo ist das Problem @N:NAME,ID einzugeben.
Oder sich ein kleines BASIC Programm zu schreiben, wo ich nur noch einmal drücken muss ...
Warum sollte man Disketten formatieren wollen mit dem Laufwerk alleine?
Normal hat man ja immer inen C64 oder einen PC angeschlossen.
-
Aber der ATMEL steuert doch auch den CPLD an und der hat Zugriff auf die Hardware, oder nicht?
Der Atmel sagt nur dem CPLD, in welchem Modus gefahren wird (Speed DOS, Prologic, prof-DOS ...).
Und natürlich die Dinge, die man am OLED einstellen kann (RESET, Schreibschutz, Gerätenummer ...).
-
Mal ne Frage, wäre es theoretisch möglich eine Funktion einzubauen die eine Diskette formatiert?
Also über das Auswahlmenü.
Nein, der Atmega hat keinen Zugriff auf die Hardware direkt und auch keine Kommunikationsmöglichkeit zum 6502.
Man könnte natürlich ein spezielles DOS schaffen, das nur formatieren kann.
Also Floppy Reset beginnt sofort mit dem formatieren.
DAS könnte man mit dem Atmega übers OLED auswählen und starten.
-
Hast du nur die Cartridge rein gesteckt oder hast du auch alle Diagnose Stecker montiert?
-
Hast du den Gleichrichter angeschaut?
Bei mir war dasselbe.
- Prinzipiell hat das Laufwerk funktioniert
- Gleichrichter sehr heiß
- VIA relativ heiß
- Im Betrieb manchmal tückisch.
Seit der neue Gleichrichter drin ist, läuft alles wie am Schnürchen.
-
Ich glaube nicht mal eine 6510 mit 4 MHz wäre hier kompatibel, da das alles Timing sensitive Routinen sind.
Auch wieder wahr
-
Dolphin DOS braucht LAX.
Prof-DOS braucht LAX.
In Kopierprogrammen habe ich es auch gefunden (war es das 15sec. Copy, weiß nicht mehr genau).
Und in der Supercard+ kommt auch LAX vor.
Es geht immer um "on the fly" GCR Dekodierung.
Das Byte vom VIA wird in XR und AC geladen.
-
Die W65C816 läuft nicht im Emulationsmodus,
Ich finde die 65C816 genial.
Es war damals die konsequente Weiterentwicklung des 6502.
Alle 6502 Systeme haben irgendeine Form von Banking eingeführt, um die 64K Barriere zu überwinden.
Und jedes Banking ist halt doch nur eine Notlösung.
Der große Adressraum, und doch den gewohnten Befehlsatz ...
... es hätte zum Erfolg führen können
Aber leider hat sich die 65816 nicht durchsetzen können.
Wenn man vom SNES und Apple-IIgs mal absieht.
-
Wäre eigentlich eine W65C02 CPU kompatibler als eine W65C816 im Emulationsmodus?
Schwer zu sagen.
Die W65C02 ist im Commodore Umfeld unbrauchbar.
Selbst in der Floppy 1541 kann man den nicht verwenden.
Von den illegalen OPC werden eh nur sehr wenige verwendet.
Aber zum Beispiel LAX ist so ein Befehl, der in jedem Floppy Speeder vorkommt.
-
wie Tuningboard fertigstellen
und MeGALoDOS zusammenbau
Wunderbar.
Zwei weitere Test Kandidaten ... 
Da gibt es auch interessante Messpunkte mit bekannten Frequenzen.
Das Gute an der Sache ist ja, an funktionierenden Boards bekommt man die Routine zum Umgang mit Messgeräte.
Hat man mal ein defektes Board, dann hat man schon eine Ahnung was man mal schnell prüft.
Man weiß dann schon wie das Signal sein soll wenn es "richtig" funktioniert.
-
Danke für diese, doch schon verständlichen Hinweise. Wird nun doch schon recht interessant.
Werde mich da mal durchtesten.
Vielen Dank 
Berichte uns von deinem Messungen.
Las uns teilhaben ...
-
Die Logiktester (Idee von axorp - mit je einer Version von Kinzi und Starquake) haben bestimmt einige zusammengebaut, aber es nützt eben nichts,
wenn man die Möglichkeiten der Tests damit ,zwecks Mangels an Anleitungen bzw. Beispiele , nicht durchführen kann.
Vielleicht geht es mir, als (Unwissenden) nur so, dann bitte ich den Beitrag zu übergehen. Sonst wird das Teil dann in irgendeiner
Kiste verschwinden und für mich nicht mehr interessant sein.
Display More
Okay ...
Dann geh halt einfach deine Geräte mal durch ...
Zb. könntest du anfangen mit einem funktionierenden C64 Board:
- such die Assy Nummer auf dem Board
- such dir den passenden Schaltplan
- such dir Punkte die bestimmte Frequenzen haben sollen (CPU Takt, Phi2, Video Signale, Sync Signale)
- such dir Punkte die auf Befehl Signale senden (zb. ATN beim LOAD eines Programm)
- erzeuge dir Signale mit kleinen Code Sampel (zb. Chip Select, Cartridge Signale, ...)
- jetzt wird es schwieriger: Suche diese Punkte auf deiner C64 Platine
- wenn man keinen Punkt zum anschliessen findet, löte dir kleine Stift an die Platine
- und dann geht es los: Tester anhängen und experimentieren!!
Es gibt für alle Commodore Kisten auch ein Service Manual.
In diesen Manuals sind oft Messpunkte beschrieben.
Die kann man auch sehr gut verwenden um mit dem Oszilloskop zu spielen oder jetzt mit dem Tester.
-
... habe versehentlich die PAUSE zu hoch eingefügt ... da fehlt ja noch etwas ...
Kannst du mir die neun Dateien zukommen lassen?
Als ZIP am besten ...
-
Hallo ihr glücklichen Besitzer eines MeGALoDOS Board.
Ich bräuchte eure Hilfe ...
geiler Turbo
Ah cool, du kommst auch so auf 9 Sekunden für 35 Spuren.
Das dürfte für "normale" Laufwerke so ziemlich das Limit sein.
Wenn man schneller wird, kommen einige Laufwerke aus dem Tritt.
-
Das LIBUSB Problem scheint bei einigen Leuten aufzutreten:
Quote
95% of the time, while using higher speeds (~ >=10Mbps) and connection is closed, the subsequent runs fails with LIBUSB_TRANSFER_TIMED_OUT, until it is run once in lower speed. This does not occur in 32-bit. The problem exists for Arch 64bit, Ubuntu 64bit, and even Windows 64bit at some extent.
sigrok-cli, pulseview, and opencbm is affected, as I know of.
Attaching some logs from sigrok-cli (1Mbit and 12Mbit runs)
http://sprunge.us/ZfEE
mirror: http://ix.io/Dvi
Display More
Quelle: 64-bit libusb LIBUSB_TRANSFER_TIMED_OUT after closing and reopening connection in higher speeds · Issue #337 · libusb/libusb (github.com)
Das Ticket wurde aber geschlossen.
Und das war 2018.
Vermutlich tritt das Problem in neueren OpenCBM nicht auf?
-
Ich habe es zwar drauf auf meinem MeGALoDOS und auch ab und zu gestartet, aber intensiv beschäftigt habe ich mich damit nicht.
So ist es bei mir auch, dachte nur da gibts ne Anleitung, die ich nirgends gefunden habe 
Bestimmt gab es mal eine Anleitung.
Aber sowas entschwindet meist nach Jahrzehnte ...
Möglicherweise taucht ja noch ein Manual auf.
Wenn das dann der Besitzer auch noch durch den Scanner laufen lässt und es hoch lädt ...
-
Abgesehen von dem LIBUSB_ERROR_IO (Keine Ahnung warum der erscheint. Auslesen der Disk funktioniert fehlerfrei) kommen noch diverse andere Meldungen.
Nee, das lesen der Disk muss deutlich mehr als eine Sekunde dauern.
Da läuft bei dir OPEN-CBM nicht ganz sauber, fürchte ich.
-
Komisch, warum macht bei dir die LIBUSB zicken?
Hat er trotzdem die neun Dateien geschrieben?
Wenn ja, kannst du die mal zippen und hier rein hängen?
