Laufwerk der 1541 emulieren

Also.. ich hab jetzt auf die schnelle kein kopierprogramm gefunden das mit 2 Floppys arbeitet (zumindest bei mir nicht)

dafür habe ich mit den Nordic tools rumgespielt.

Ich konnte jetzt per filecopy mehrere dateien kopieren, die letzte will aber nicht, daher läuft das ganze spiel nicht.

Also generell es funktioniert schonmal super.. aber ich werde mal noch weiter testen...

evtl. mich doch mit G64 anfreunden....

ich mag halt noch ein paar alte Disketten retten bevor sie nicht mehr lesbar sind.. ob das dann ein G64 oder D64 ist ist dann eher egal... und zum highscore speichern sollte die D64 funktionalität doch schon funktionieren.

Eigentlich spricht ja auch nichts gegen G64 generell, oder?

Wenn da im Menü eine "Auf-Knopfdruck-Hin-und-Her-Wandlung" zwischen G64 und D64 eingebaut ist, sollte das doch mehr als ausreichen, wenn "nativer D64-Support" mit dieser Hardware nicht zu stemmen ist. Wer unbedingt wieder zurück auf D64 muss (warum eigentlich?) macht das dann halt zum Schluss.

D64 -> G64 sollte ja sowieso automatisch machbar sein beim Mounten, oder?

Ich würde das so gestallten wird ein D64 das erste mal angesprochen, wird es in G64 konvertiert und die D64 entweder gelöscht oder in einen Ordner Konvertiert oder so verschoben.

Zitat von Natas

die D64 entweder gelöscht oder in einen Ordner Konvertiert oder so verschoben.

Also DAS würde ich nicht wollen, dass mir das Ding irgendwas löscht oder verschiebt! Meine Ordnung auf der SD-Karte hat niemand zu stören.

Auto-Umwandlung in G64 bei Start ist OK. Ggf. mit Überprüfung, ob ein G64 schon existiert. Rückwandlung auf Wunsch(!) ist auch OK.

Man müsste sich überlegen, wie das automatisch erzeugte G64 heißen soll, damit man die (bereits erfolgte) automatische Umwandlung erkennt. Ideen:

• Anhängen von .G64:
  • TESTDRIVE.D64 -> TESTDRIVE.D64.G64
  • TESTDRIVE.D64 -> TESTDRIVE_D64.G64
  • o. ä.
• G64 mit eigener Extension:
  • TESTDRIVE.D64 -> TESTDRIVE.RBD
  • entweder 1:1 G64 nur mit anderer Extension
  • oder überhaupt eigenes Format, wo noch Metainformationen untergebracht sind (Originalname, Hash, usw.)
• ???

Zitat von Natas

Ich würde das so gestallten wird ein D64 das erste mal angesprochen, wird es in G64 konvertiert und die D64 entweder gelöscht oder in einen Ordner Konvertiert oder so verschoben.

Ich weis ja nicht ob das evtl. Zu problemen führen kann... zumindest sollte nicht automatisch ein G64 wieder in ein D64 gewandelt werden (kopierschutz oder ähnliches). Wenn das G64 eigentlich nur vorteile hat dann nehmen wir doch das... wie gesagt der meisten schreibzugriffe werden zumindest bei mir eh für highscores sein, ansonnst um alte Disks zu sichern und da sollte D64 oder G64 egal sein.

Ich teste mal noch ein wenig weiter.

Das erstellen einer disk geht noch nicht oder? Zumindest passiert bei mir nichts wenn ich den punkt auswähle.

Also Thorsten und Fook vielen dank nochmal für eure bisheriga Arbeit und das was bestimmt noch kommen wird

Das mit dem Löschen, Verschieben einfach Stehen lassen kann man je evtl. einstellbar machen.

Meine Idee ist eine Automatische Konvertierung von D64 in G64 aber eine manuelle in die andere Richtung.

kinzi Also ich sehe keine Notwendigkeit für die doppelte Endung. Ich nehme an du willst verhindern, das beliebige G64 in D64 konvertiert werden.

Ich denke das kann man intelligenter lösen sobald in der G64 etwas erkannt wird, das sich in einer D64 nicht abbilden lässt gibt es eine Meldung "Umwandlung nicht möglich".

Das garantiert zwar immer noch nicht das alle D64 zu 100% laufen, aber die Quote sollte hoch sein.

Zitat von Natas

kinzi Also ich sehe keine Notwendigkeit für die doppelte Endung. Ich nehme an du willst verhindern, das beliebige G64 in D64 konvertiert werden.

Ich will verhindern, dass existeirende G64 zerstört werden. Wenn ein "TESTDRIVE.D64.G64" existiert, dann mit an Sicherheit grenzender Wahrscheinlichkeit auf Grund der Umwandlung. Wenn aber "TESTDRIVE.D64" und TESTDRIVE.G64" existieren, können das ja zwei verschiedene Dinge sein, ein Original mit Kopierschutz im G64 und ein gecracktes D64 z. B.

Daher auch der Ansatz mit der kompklett eigenen Extension ".RBD" (oder wie auch immer).

Ich hätte vielleicht als Endung .64G genommen. Damit könnte man schnell genug erkennen, dass es sich um ein nach .G64 umgewandeltes .D64 handeln könnte und etwas mit dem .G64-Format zu tun hat.
Wenn ich .RBD (oder was auch immer) sehe, dann assoziiere ich nicht sofort eine umgewandelte .D64-Datei.

Jetzt wird mir das fast schon zu theoretisch

Aber hört sich gut an.

Muss dringend meinbe beiden Programmer von der Arbeit holen .

Rebuild zu hause und Programmer auf Arbeit...wie doof

stones73

Mit den Treibern. Für USBasp kann man gut ZADIG - 2.4 nehmen

kinzi ich kann deine Idee verstehen, sehe es aber anders, wenn jemand unbedingt die G64 und D64 von Testdrive auf dem selben Medium haben möchte soll man das im Dateinamen Testdrive_org.G64 und Testdrive.D64 kenntlich machen.

Zitat von fepo

stones73

Mit den Treibern. Für USBasp kann man gut ZADIG - 2.4 nehmen

ja...die hatte ich ja auch genommen (nach 30 min grübeln... hatte nicht geschaut ob der USBasp richtig eingebunden wurde... er wurde ja richtig erkannt, aber avrdudess hat den nucht gefunden) , aber die treiber die da vorgeschlagen wurden hatten auch nicht funktioniert, musste erst andere auswählen und installieren... die gingen dann.

libusb driver die treiber gingen

Zitat von Natas

kinzi ich kann deine Idee verstehen, sehe es aber anders, wenn jemand unbedingt die G64 und D64 von Testdrive auf dem selben Medium haben möchte soll man das im Dateinamen Testdrive_org.G64 und Testdrive.D64 kenntlich machen.

Du gehst von dir aus. Jemand, der aber einfach seine SD reinschiebt und das nicht weiß möchte vielleicht nicht seine G64 überschrieben bekommen.

Zitat von knusis

Ich hätte vielleicht als Endung .64G genommen.

Das fände ich jetzt auch recht clever, ja.

Zitat von stones73

Das erstellen einer disk geht noch nicht oder? Zumindest passiert bei mir nichts wenn ich den punkt auswähle.

nee..

weder Erstellen, noch Löschen, noch Kopieren ist implementiert..

da wäre auch die Frage, in welchem Format eine neue Disk angelegt werden sollte...

so wie ich es nun lese, wird sich ein G64 (wie auch immer es heisst) dann doch durchsetzen - ist auch bezüglich der Emulation deutlich angenehmer, weil Thorstens Routinen eben kaum Zeit für das Lesen/Speichern davon benötigen - wir kämen damit den Fastloadern näher.

Zitat von kinzi

Du gehst von dir aus. Jemand, der aber einfach seine SD reinschiebt und das nicht weiß möchte vielleicht nicht seine G64 überschrieben bekommen.

Ja, natürlich. Ich wollte auch nur sagen wie ich es lösen würde, das heißt nicht, dass alle Anderen es genauso machen würden oder gar für in Ihrem Sinne empfinden.

Ich sehe es so: es wird vorgegeben .G64 ist der Standard, scheißt jemand .D64 auf die Karte werden die freundlicherweise automatisch umgewandelt and that's it.

Wenn man dann noch zusätzlich eine Option hat manuell von .G64 auf .D64 zu wandeln ist das Luxus.

Deine Variante kann man machen, aber ich sehe da unnötige Komplexität und Fehlerquellen.

Nicht falsch verstehen, ich möchte niemanden etwas vorschreiben oder jemanden überreden.

Zitat von kinzi

Du gehst von dir aus. Jemand, der aber einfach seine SD reinschiebt und das nicht weiß möchte vielleicht nicht seine G64 überschrieben bekommen.

nicht überschreiben, sondern wenn man möchte, es mit dem nicht vorhandenem format ergänzen.

Zitat von Natas

Ich sehe es so: es wird vorgegeben .G64 ist der Standard, scheißt jemand .D64 auf die Karte werden die freundlicherweise automatisch umgewandelt and that's it.

ich sehe es auch so.

Zitat von Natas

Wenn man dann noch zusätzlich eine Option hat manuell von .G64 auf .D64 zu wandeln ist das Luxus.

wäre aber auch ideal, so hätte man beides, für z.b. andere anwendungen und keine diskusionen über .g64 und .d64

Zitat von Natas

Deine Variante kann man machen, aber ich sehe da unnötige Komplexität und Fehlerquellen.

ja, ein mal wandeln und lassen. platz ist ja genug da. und weitere sd-karten kosten ja fast nichts.

flash ist ja nicht unendlich beschreibbar, es ist kein ram!

wenn .g64 der standart ist, aber eine neu aufgespielte datei nur in .d64 vorhanden,

dann wird einmalig eine .g64 erstellt und dann ist keine umwandlung mehr nötig.

gruß

helmut

also wenn es einfacher ist die D64 un G64 zu wandeln dann soll mir das auch recht sein.

Wie gesagt für mich ist die Schreiboption wichtig um highscores zu sichern oder auch um Disketten zu sichern.

Ob das als G64 oder D64 passiert ist dabei doch eher egal.

Da sollte doch eher energie in die kompatibilität für fastloader gesteckt werden. Aber wie schon so oft erwähnt, ich bin ja eh froh das hier so leute wie Thorsten und Fook42 sind die sich der Problematik annehmnen und so tolle Hardware produzieren.

Ich hab im moment aber auch in den G64 schreibbrobleme... muss aber nochmal genau schauen ob nur mit den Tools vom nordic power oder auch ohne.

Ich such noch ein kopierprogramm das mit 2 Laufwerken arbeitet. Die Kwickcopy hängt sich auf wenn ich als Quelle die 1571 als laufwerk 9 auswähle

was für mich noch auf dem Wunschzettel steht wäre eine Hardware für die 1571 und ein Bootloader um die Updates zu vereinfachen.

G64 kann man ja auch später am PC recht einfach in D64 verwandeln. Wir haben da doch einen Spezialisten hier im Forum, der da auch eine passende Software geschrieben hat:

https://github.com/markusC64/g64conv

Insofern würde ich auch sehr stark plädieren: Das Ding sollte EINEN Job machen und den GUT. Und so was wie G64->D64 kann man später offline machen wenn es wirklich jemand braucht.

Ich denke auch, wenn es um die Möglichkeit geht, zu speichern, genügt erstmal eine Speichermöglichkeit, mit der man problemlos speichern und wieder zurücklesen kann. Ob und wie sich das dann erweitern lässt, wird sich zeigen. Die 1541 speichert ja auch nicht in D64.

Wer die SD-Karte als Massenspeicher ("Datengrab") haben will, hat genügend andere Auswahl an Hardware. Es geht ja bei der 1541rebulid auch und vor allem um das Vorhandensein der echten Hardware und um Anwendungsfälle, wo diese Hardware genutzt wird.

Ich danke euch erstmal für die vielen Ideen - finde es gut, wenn wir hier eine gemeinsame Linie und Erwartungshaltung an die künftige 1541-rebuild-Software bekommen!

Also; euch würde eine reine G64-basierte Emu ausreichen?

-> auf der SD-Karte kann man dann eben nur die G64 Dateien auswählen

-> Für dieses Format soll Lesen und Schreiben unterstützt werden

-> evtl. Löschen/Erstellen und Kopieren (ist ja dann nur auf der File-System Ebene der SD-Karte nötig)

-> Support für 84 Tracks : G64-Dateien können bis zu 42 Tracks (+42 Halftracks) beherbergen

-> SD-Kartenroutinen optimieren (hier geht viel verloren aktuell durch Update des Direktories nach jedem Track etc.)

hab ich was vergessen für die Wunschliste?

Zitat von fook42

Zitat von greg64

Kann man die "alte" Platine sinnvoll umbauen

leider ist das nur mit viel Aufwand möglich (hatte ich hier einmal gezeigt : https://www.forum64.de/wcf/ind…41-20210828-230724-kl-jpg )

ich musste damals die Platine neu routen, damit die I2C-Pins auch am Display-Anschluss anliegen und ich dann eben die Erweiterungen für die anderen Displays realisieren konnte.

Das kann natürlich auch der falsche Weg sein, bzw. überflüssig, wenn man weiterhin die LCDs direkt über den 10poligen Anschluss betreiben möchte - das wird wohl für 95% aller 1541rebuilt-User der Fall sein.

Ich möchte die I2C-Schnittstelle ungern missen, deshalb werde ich diese Geschichte auch weiterpflegen und kann auch noch 2-3 Platinen davon abgeben (hatte damals 5 bestellen müssen) - jeder der das nachbauen möchte, kann sich die neuen PlatinenDateien für die 1.4.2er aus dem verlinkten Repository laden (-> https://github.com/fook42/1541…ee/master/hardware/gerber )

wir werden aber versuchen, die Software für beide Platinen möglichst identisch zu halten was die Funktionalität angeht - die "Umschaltung" von alt auf neu könnte man evtl. über eine Variable beim Kompilieren realisieren... dann können Thorsten oder ich leicht die unterschiedlichen Versionen erzeugen und bereitstellen.

Für euch bedeutet das nur, dass es im GitHub-Repo immer 2 Zip-Archive geben wird - jeweils für alte HW und neue.

Thorsten Kattanek . passt das so?

Alles anzeigen

Wenn ich das richtig sehe ist das IC auf dem Steckbrett fast ausschließlich nur mit dem Sockel verbunden, richtig?

dann könnte man ja ein kleines Adapter Platinchen herstellen oder nicht? Wenn die Höhe das Problem ist, könnte man dann nicht das IC kopfüber montieren?