Woran scheitert es denn?
Was ist der VIA2 (UC3 oder UC2) ?
Der IC, an dem der R/W-Amp hängt, siehe Schaltplan.
Bzw. gibt es wo eine detailiertere Dokumentation wie man das Ganze mir einem Assy 250442 Board zusammenbaut?
Ich hab selbst so ein Board im Einsatz und hier im Thread auch Fotos davon gepostet. Siehe meine Beiträge hier im Thread:
Kommt die Rebuild Platine am 1541 an UC2 oder an UC3?
in UC 2 , siehe #399
anleitung kenne ich auch keine
edit: zu spät 
Danke fuer die Infos
jetzt muss ich aber doch nochmal fragen Thorsten Kattanek oder fook42
Gibt es eine reelle Hoffnung das die Firmware nochmal erneuert wird?
Mehr D64 Unterstützung? Leere Immages erstellen?
Wäre schade wenn da nichts mehr kommen würde.
Leider kann ich da nicht viel beitragen... ausser zu testen.
Danke schonmal und allen eine guten Rutsch nach 2023...
Etwas mehr D64 Unterstützung wäre in der Tat super.
Leere Diskette kann ich mir sehr gut vorstellen.
Ging das Beschreiben von D64 eigentlich ?
Ging das Beschreiben von D64 eigentlich ?
Das geht WIMRE seit längerem, steht hier im Thread irgendwo.
Ging das Beschreiben von D64 eigentlich ?
Hast du mal probiert? Mach einfach mal. Geht schneller, als hier im Thread zu suchen und sehr viel schneller, als dass ich alles aufgebaut habe.
ich hatte probleme in auf D64 zu schreiben.. ging mal und mal nicht.. vorallendingen mit speedern maht das probleme
Hallo leute..
ja, ist ein wenig ruhig geworden um das Thema; ich hab ein gebrauchtes Häuschen gekauft und bin das ganze Jahr neben der Arbeit nur am Renovieren/Erneuern 
... das frisst viel Zeit.
zum D64 support; ja, ich hatte die Routinen noch fertiggestellt und auch mit Thorsten Kattanek s Hilfe in die originale Firmware integriert (1.3.7) - so dass man dort grundsätzlich D64 Files auch beschreiben kann.
Grundsätzlich, da es eben mit Speedern und anderen "Tricks" noch Probleme beim wirklichen Zurückschreiben auf die SD-Karte gibt.
Man hat leider nur wenig Zeit, einen Track vom GCR zu dekodieren und an die passende Stelle ins D64-File der FAT32 SD-Karte zu schreiben. Hierbei ist nicht nur die SD-Karte ansich, sondern auch das Filesystem (FAT32) und der SPI-Bus ein Bottleneck.
Einfache Schreibübungen funktionieren .. sogar eine Diskette konnte ich formatieren und neue Dateien draufkopieren.. aber ein FastCopy funktioniert eben nicht
mit dem G64 sollte das allerdings etwas besser laufen - hier entfällt die GCR dekodierung, jedoch bleibt auch hier der SD-Kartenzugriff eine zeitkritische Komponente.
Thorsten hatte für die SD-Kartenroutinen eine vorhandene Bibliothek von Roland Riedel benutzt - evtl. könnte man diese noch etwas beschleunigen .. aber dafür habe ich noch keine gute Alternative gefunden.
Zu den Image-Features:
das Erzeugen eines leeren Images kann ich kurzfristig einbauen - das ist nicht schwer, zumal ich hierfür ja nicht auf die Floppy warten muss, sondern nur die SDKarte beschreiben sollte.
muss dafür noch ein bisschen "Menu"-führung einbauen, damit man auch den Filenamen und das Format (D64/G64) auswählen kann.
fook42 Wie viel RAM hat der Microcontroller, den ihr benutzt? Ich habe mir das Board nicht so recht angeschaut... Könnte man das D64 im RAM halten? Oder SPI RAM anbinden? Die PicoGUS, die auf dem Pi Pico basiert, mach so was zum Beispiel um 4 MB RAM mit ziemlich hoher Bandbreite anzubinden, zwecks Sample Speicher für eine GUS Emulation.
Wie viel RAM hat der Microcontroller, den ihr benutzt?
16k (Atmel 1284)
es wird der ATMEL ATmega1284p benutzt:
- 16 KB RAM
- 4 KB EEPROM
- 128 KB Programm Flash
und hier sieht man, dass die 16KB auf keinen Fall ausreichen um ein ganzes Image (170 KB D64 bzw. 271 KB G64) im Ram zu behalten
einen einzelnen Track bekommen wir gerade so noch hin.
Display Morees wird der ATMEL ATmega1284p benutzt:
- 16 KB RAM
- 4 KB EEPROM
- 128 KB Programm Flash
und hier sieht man, dass die 16KB auf keinen Fall ausreichen um ein ganzes Image (170 KB D64 bzw. 271 KB G64) im Ram zu behalten
einen einzelnen Track bekommen wir gerade so noch hin.
Autschn. Vielleicht macht jemand das nochmal mit nem pico.
Das geht ganz passabel mit nem 6502 und popligen 2k RAM!
okay, das kommentiere ich mal nicht.
aber zurück zum Kopieren von Disketten mit dem 1541rebuild.
Ich habe nun das FCopy 2.9 benutzt um eine Diskette zu kopieren (FC III zeigt zwar etwas an, aber meine Eingaben werden ignoriert)
Sowohl im D64 als auch G64 Format sehe ich nun einen Fehler im Ziel-Image : die Tracks 10 und 21 sind nicht kopiert worden - da wurde scheinbar der ganze Track übersprungen. alle anderen stimmen 1:1 überein.
Nun kopiert FCopy scheinbar jeweils 12 Tracks pro Durchgang, bei dem dann zunächst von der QuellDiskette gelesen und anschliessend diese 12 Tracks auf eine ZielDiskette geschrieben werden. Das wiederholt sich dann noch 2 mal ( für die Tracks 0-11, 12-23, 24-35)
Kann mir jemand sagen, ob FCopy hier eigentlich verlässlich ist, oder ob das ein bekannter Fehler ist?
Bin nicht der C64-held... deshalb; gibt es eigentlich einen Track-reader/editor, bei dem ich gezielt 1 Track von Diskette auslesen und schreiben kann ? mit Floppy-Kommandos geht das wohl eher nicht, oder?
Geht sogar in Basic > https://codebase64.org/doku.ph…eading_a_sector_from_disk
und nochmal eine kleine Information, damit wir alle wissen, wo die Zeit beim Zugriff auf die Images auch noch versteckt ist:
Vorweg; die Zeiten variieren aufgrund der Zugriffs-Geschwindigkeit der SD-Karte, der Zeit fürs Öffnen der Datei, wie lange das "Suchen" nach dem Offset im Image-File benötigt (seek) und natürlich wieviele Sektoren pro Track geschrieben werden müssen [21,19,18 oder nur 17]
(Angaben pro Track-Zugriff - als gemessene Werte per Osziloskop)
Lesen:
- G64-Modus: 24 - 28 ms
- D64-Modus: 32 - 44 ms (inklusive GCR Enkodierung)
Schreiben
- G64 Modus: 36 - 60 ms
- D64 Modus: 100 - 140 ms (inklusive GCR Dekodierung und Track-Aufbau)
Das ist alles nicht so richtig "schnell", aber noch besser als eine echte Diskette, die mit 300 rpm dreht und somit mindestens ~200ms pro Track (lesen oder schreiben) benötigt.
Also sollten wir es theoretisch doch schaffen auch mit dem Atmel hier den Datenstrom einer Diskette zu immitieren, wenn da nicht die Verzögerung für den Zugriff und die Konvertierung der SD-Kartendaten wäre.
Also sollten wir es theoretisch doch schaffen auch mit dem Atmel hier den Datenstrom einer Diskette zu immitieren, wenn da nicht die Verzögerung für den Zugriff und die Konvertierung der SD-Kartendaten wäre.
ich habe mir das alles hier nicht durchgelesen.
diese probleme gibt es doch nur beim erstellen der datei mit einem speeder?
dann würde ich es doch ohne einen speeder machen, das macht man doch nur einmalig.
wenn man die datei sich einmal erstellt hat, kann man es doch auch mit einem speeder von der sd lesen?
gruß
helmut
Display MoreAlso sollten wir es theoretisch doch schaffen auch mit dem Atmel hier den Datenstrom einer Diskette zu immitieren, wenn da nicht die Verzögerung für den Zugriff und die Konvertierung der SD-Kartendaten wäre.
ich habe mir das alles hier nicht durchgelesen.
diese probleme gibt es doch nur beim erstellen der datei mit einem speeder?
dann würde ich es doch ohne einen speeder machen, das macht man doch nur einmalig.
wenn man die datei sich einmal erstellt hat, kann man es doch auch mit einem speeder von der sd lesen?
Ehrlich gesagt schreibe ich auch selten auf Diskette per C64. Da ich sehr, sehr viel Demos schaue, lese ich die meiste Zeit nur. Das funktioniert ja. Bei Savegames für Spiele wäre eventuell noch ein Problem. Da weiß ich aber nicht, ob und welche Spiele welche Speeder verwenden. Geht z.B. das Abspeichern eines Spielstands in Zak McKracken oder ähnlichem?
