finde ich toll das Vorhaben.
Hoffe du bleibst an der Sache dran.
Hallo Besucher, der Thread wurde 193k mal aufgerufen und enthält 1573 Antworten
letzter Beitrag von r.cade am
Laufwerk der 1541 emulieren
- amithlon
- Erledigt
-
-
Jop, dafür, so einen Umbau würde ich mir gerne gönnen
-
Und nicht zu vergessen das bei der Analogvariante das Empfangen und auswerten des Analogen Datenstroms sehr viel mehr Zeit benötigen wird als das reine Streamen zum R/W Amp. Man möchte ja auch schreiben können. Ich würde auch nur am Digitalteil ansetzen. So ist auch eine Zukünftige Fehlersuche nur noch darauf beschränkt. So wie ich das mitbekommen habe, ist der R/W Amp ja auch eine häufige Fehlerquelle bei den alten 1541 I + II. (Verbessert mich, wenn dem nicht so ist). Den tauscht man nicht mal so schnell. (Wenn man den überhaupt noch bekommt.)
-
Äh, vorsicht... Damit der Datenseperator auf der Platine das auch wieder auseinanderbekommt musst du die Datenrate ziemlich genau treffen.
Noch schlimmer, die 1541 benutzt 4 verschiedene Datenraten, je nach Spur.
Richtig. Und außerdem gibt es keinen benefit, wenn man es an der Stelle macht.
Und außerdem gibt es am VIA sogar noch einen Vorteil. Mit einem gepatched DOS könnte man die ganze GCR codierung/decodierung einfach ausschalten. Dadurch hätte man eine sehr schnelle Floppy, solange man nur mit D64 arbeitet. Die DOS Version könnte man automatisch umschalten über ein Adresspin an einem EPROM. Der AVR wählt das passende DOS für die Floppy, je nach dem welches Image gemounted ist (D64 oder G64).
-
Hast Du schon einen Schaltplan damit man das ganze auf dem heimischen Breadboard nachbauen kann? Die bestehenden Sources wären auch interessant, dann wäre für die Interessierten ein Testen/basteln zuhause möglich.
-
Und außerdem gibt es am VIA sogar noch einen Vorteil. Mit einem gepatched DOS könnte man die ganze GCR codierung/decodierung einfach ausschalten. Dadurch hätte man eine sehr schnelle Floppy, solange man nur mit D64 arbeitet.
Das wird dann aber wieder Fastloader-inkompatibel. -
Dann nimmt man noch ein AVR PIN dazu und kann manuell per LCD Display auf Maximal 4 verschieden ROM's zugreifen
-
Bin begeistert! Wenn das klappt wär's genial
-
Mit einem gepatched DOS könnte man die ganze GCR codierung/decodierung einfach ausschalten. Dadurch hätte man eine sehr schnelle Floppy, solange man nur mit D64 arbeitet.
Das langsamste sind doch sowieso die Kernal-Routinen, auf die man dann Mangels Kompatibilität auch angewiesen wäre. GCR-Dekodierung fällt da nun wirklich nicht ins Gewicht. Da kann man auch gleich SD2IEC nehmen.
-
Das wird dann aber wieder Fastloader-inkompatibel.Ja das stimmt.
Aber könnte man trotzdem machen über spezielle extensions. Zb. bei D64A, wenn im ganzen Image keine Fastloader vorkommen.
Das langsamste sind doch sowieso die Kernal-Routinen, auf die man dann Mangels Kompatibilität auch angewiesen wäre. GCR-Dekodierung fällt da nun wirklich nicht ins Gewicht. Da kann man auch gleich SD2IEC nehmen.
Nee, die DOS Kernel Routinen sind nicht das primäre Problem. Das sieht man an den großen Commodore Floppies (8050), da sind dieselben drin und GCR wird per Hardware gemacht.
Das Nadelöhr neben GCR ist der serielle Bus. Bei mir läuft da sowieso parallel Kabel.
-
Ja das stimmt.
Aber könnte man trotzdem machen über spezielle extensions. Zb. bei D64A, wenn im ganzen Image keine Fastloader vorkommen.
Ich meinte jetzt eher so Fastloader wie z.B. Final Cartridge III, Action Replay oder EXOS - die drei verarbeiten im Laufwerk die GCR-Daten direkt selbst. -
Das Nadelöhr neben GCR ist der serielle Bus.
Der serielle Bus wird doch von den Kernal-Routinen auch angesprochen und ist somit ein Teil davon. Von Laufwerken mit alternativen Schnittstellen rede ich mal gar nicht, denn wir sind ja immer noch bei der 1541, und da ist eben mit dem Kernal-LOAD (der natürlich in diesem Fall mit dem seriellen Bus kommuniziert) nicht mehr raus zu holen.
ZitatBei mir läuft da sowieso parallel Kabel.
Wenn Du Dolphin DOS oder Professional DOS kennst, weißt Du ja, wie schnell das auch mit GCR-Dekodierung gehen kann. Da muß man es wohl schon extrem eilig haben, wenn man es noch schneller braucht und dafür die Kompatibilität opfern will.
Wenn es nur um Geschwindigkeit geht und nicht um Kompatibilität, wäre es sicher sinnvoller ein Modul zu entwickeln, das die Daten per DMA überträgt, so wie es die REU auch macht. Das wäre dann aber wohl ein völlig anderes Projekt.
-
Dieser Thread zeigt auch noch einige Fallstricke auf.
-
Sehr cooles Projekt! Hatte mich am Anfang etwas an das hier erinnert: http://www.baltissen.org/newhtm/1541ide8.htm
Direktes kopieren von Image zu Disk und umgekehrt klingt wie das Todesurteil für meine Zoomfloppy!
Würde das auch Stand-Alone gehen? Also nur die modifizierte Floppy an den Strom, SD-Karte und Floppy rein, Knopf drücken und ab geht die Lutzi.100%-Kompatibilität zu haben ist super! Wenn ich ein Onefiler spielen möchte, brauch ich das aber nicht und da hätte ich es lieber schnell. Ich würde es vielleicht nicht automatisieren aber einen "Turbo-Knopf" fänd ich gut. Das Argument "dann kannst du ja ein SD2IEC nehmen" halte ich für schlecht. Ich will nicht dauernd umstöpseln und 2 Laufwerke machen halt bei manchen Programmen ärger.
Wenn es nur um Geschwindigkeit geht und nicht um Kompatibilität, wäre es sicher sinnvoller ein Modul zu entwickeln, das die Daten per DMA überträgt, so wie es die REU auch macht. Das wäre dann aber wohl ein völlig anderes Projekt.
Du weißt schon, dass es das schon gibt? -
Das Ding braucht natürlich ein LCD-Display und einen Drehgeber mit Taste als Bedienelemente.
CPU wird ein AVR ATMega1284P (bei mir auch nur dieser...), weil DIP-Gehäuse und 16k Ram.
Ich habe mir jetzt erstmal eine SD-Card Bibliothek gesucht, die ich nicht erst nach 3 Monaten Studium verstehe. Display- (2*16 im Momet) und Drehgeber sind dran, alles erstam auf ein Stecjbrett gesteckt, ich hatte diesmal keine Lust, gleich Lochraster zu bemühen.Diese Hardware gibt es bereits: Ein SD2IEC mit 1284P und LCD Display
Die Software spricht bereits die SD Karte und LCD an, da hat man auch schon ein Software Grundgerüst.
------------------
Mal gucken ob ich eine 1541 habe, die VIA und CPU gesockelt hat ...Und dann? Zwischensockel basteln?
Gibts schon ein Schaltbild?Die Datenrichtung ist auch problematisch oder? Wenn die Floppy schreiben will, muss der Atmel rechtzeitig auf Input schalten ...
-
Das G64 Fileformat hat für jede Datenspur zwei Byte Spur Länge + Daten. Die Länge überschreitet üblicherweise 7928 Bytes nicht (Quelle: unusedino)
Dis Diskette dreht 5 mal pro Sekunde. Wenn die vollen 9728 Bytes gespeichert sind, dann muss der ATMEGA alle 24,5 µs ein Byte senden.
________ Lese Vorgang
Also wir haben einen Ringbuffer mit variabler Größe. Einen Timer Interrupt der alle 24,5 µs feuert.
Im Lesemodus bei eingeschaltetem Motor wird einfach ein byte nach dem anderen gesendet. Bei $FF sind wir im SYNC Bereich und müssen die entsprechende Steuerleitung setzen. Bei anderen Zeichen wird jeweils ein "Byte Ready" gesendet nachdem das Byte ausgegeben wird.
Wie lange steht das Byte Ready? Hat jemand ein Oszilloskop?
________ Spurwechsel
Die Schrittmotor Signale werden ausgewertet. Dabei wird eine Spurnummer errechnet.
Es gibt eine Routine die eine Spur aus einem File einliest in den Ringbuffer. Bei D64 werden die Daten gelesen, in GCR codiert und in den RB geschoben. Bei G64 werden die Daten gelesen und direkt in den RB geschoben.
Falls zuvor in die Spur geschrieben wurde, müssen die Spurdaten ins File (D64 oder G64) übertragen werden, bevor die neue Spur gelesen wird.
Wenn die Floppy in einer Halbspur schreibt, dann soll eine rote LED eingeschaltet werden. Denn das G64 Format unterstützt so etwas nicht.
________ Schreib Vorgang
Wenn die Floppy auf schreiben schaltet, muss der ATMEGA sofort den Port auf Eingang schalten.
Die Timer Interrupt Routine schreibt nun Bytes in den Ringbuffer. Dabei generiert der ATMEGA weiterhin die Byte Ready Signale.
Mangels Hardware werde ich mal ein kleines Kommandozeilen Tool schaffen, mit dem man D64 und G64 Spuren lesen kann. Die Daten könnte man als C Array ausgeben, damit man eine fixe Spur 18 für ein Testprogramm am ATMEGA hat.
-
Ist das Timing so kritisch? Wenn eine defekte Diskette im Laufwerk liegt, wieviele Versuche unternimmt die Floppy, bis sie aufgibt oder einen Time-Out bringt? Ich kenne das ROM der 1541 nicht im Detail, deshalb will ich mich da nicht zu weit aus dem Fenster lehnen.
Für mich klingt es einfach nur logisch, dass es Sinn macht, den Lesekopf durch einen Microcontroller zu ersetzen. Es entfällt die komplette 6502-Emulation mit all ihren Tücken. Und da hier Mechanik ersetzt wird, sollten die Toleranzen im Timing groß genug ausfallen, dass man mit 20MHz zum Ziel kommt. Einen ATmega 644P hatte ich schon dauerhaft mit 32MHz getaktet. Probleme gibt's dann nur mit dem ISP, aber dann wechselt man zum Flashen eben den Quarz.
-
Wieso 6502 Emulation ? Der digitale Teil also CPU sowie VIA'S sollen benutzt werden, lediglich der Analogteil entfällt.
-
Bei anderen Zeichen wird jeweils ein "Byte Ready" gesendet nachdem das Byte ausgegeben wird.
Vorsicht... Der VIA erzeugt auf CA2 noch ein Signal mit dem Namen 'SOE'. Wenn ich das im Schaltplan zum Long-Board richtig lese wird damit das 'Byte_Ready' signal gegated, darf also nur geliefert werden wenn es über 'SOE' freigegeben ist.
-
Wieso 6502 Emulation ? Der digitale Teil also CPU sowie VIA'S sollen benutzt werden, lediglich der Analogteil entfällt.
Ich hab ja geschrieben "es entfällt die 6502 Emulation"