Eigentlich müßte man doch nur mal bei VICE schauen, wie das da gemacht wird. Ich habe zwar keine Ahnung von C++ irgendwas , aber vielleicht findet man da einen Ansatzpunkt...
Eigentlich reichts schon, wenn man eine mit Debugausgaben compilierte sd2iec-Version hat und da mitliest, welche Kommandos ans Laufwerk geschickt werden. 
So sind auch die Fake-ROMs für FD/HD-Simulation entstanden.
Die Übersetung ist manchmal etwas holprig, aber völlig OK (meine Meinung).
Das wäre nochmal was zum Scannen. Werde aber dazu bestimmt in den nächsten Wochen und wahrscheinlich einigen Monaten nicht kommen....
Aus der Hand gebe ich die vorerst nicht, meine Wheels-Seriennummer interessiert niemanden außer mir .
Aber sicherlich besser, als wenn ich's übersetze 
Dann warten wir mal ab.
ohje, da komme ich ja demnächst zu gar nichts mehr...
So schlimm kann ich gar nicht sein 
Mein uIEC (eine SD2IEC-Variante aus USA; Anbieter: Jim Brain, store.go4retro.com/ ) habe ich Ende 2011 gekauft. In der Form gibt es das wohl nicht mehr. Ich habe das uIEC mit einen Tochterboard, das direkt mit einem uIEC verbunden ist. Genau das wollte ich damals und reicht mir auch völlig. Heute hat das Tochterboard wohl 3 Steckplätze für 3 uIECs. Nun, wer es braucht ....
Danke für den Link, an "go4retro" hab ich gar nicht gedacht.
Hab mir diese Version überlegt: https://www.thefuturewas8bit.com/index.php/sd2iec
Dann schaun wir mal, was da demnächst für Fragen kommen zum SD2IEC...
Keine Bange, das wird dauern.
Es ist auch nicht sicher, ob ich es mir zu lege.
Aus meiner Sicht ist der einzige Vorteil, gegenüber der U2+, das verwenden von D81.
Gruss C=Mac.
Hallo Pusti64,
Was muss man eigentlich beachten, wenn man einen Treiber für GEOS / MP3 schreiben möchte?
Eigentlich solltest Du darüber mehr wissen als andere hier (ausgenommen ich ). Du bist wohl der einzige hier, der schon einen externen Treiber für MP3 in MP3 nutzt (Stichwort: CDROM).
Ein Treiber muss an Adresse $9000 beginnen und darf maximal bis $9d7f gehen.
Ab $9000 steht eine Sprungtabelle mit Einsprüngen in den Treiber. Diese muß exakt eingehalten werden, da sie auch von anderen Geos-Routinen angesprungen werden. Bei Geos endet diese Sprungtabelle normalerweise bei $904d. Ab $904e stehen dann die Routinen, die durch die Sprünge aus der vorherstehenden Sprungtabelle angesprochen werde.
Bei MegaPatch ist die Sprungtabelle etwas länger. Siehe "MP3 Dokumentation für Programmierer".
Dann brauchste Du noch eine Installationsroutine für den Treiber. Diese kann Einstellungen im Treiber vornehmen (beim CDROM z.B. die Lfw.-Adresse). dann (unter MP3) den Treiber in die RAM an den richtigen Platz kopieren.
Wenn jetzt das Laufwerk aktiviert wird, wird der Treiber aus der RAM nach $9000 kopiert und du kannst auf das Laufwerk zugreifen.
Gruß
Werner
PS: Die "MP3 Dokumentation für Programmierer" liegt auf http://c64.webgrimm.de/ und ist leider nicht ganz aktuell
Gruß
Werner
Hallo C=Mac,
Es ist auch nicht sicher, ob ich es mir zu lege.
Aus meiner Sicht ist der einzige Vorteil, gegenüber der U2+, das verwenden von D81.
Naja, momentan kannst Du unter Wheels auch DNP benutzen....
Gruß
Werner
Hi Werner,
von mir kam ja lediglich die Idee. Die geniale Umsetzung kam wie immer von Dir. 
Meine Frage zielte eher auf die internen Treiber. Wie bekommt man also so einen externen Treiber sauber in die interne Treiberauswahl?
Oder ist der Aufwand schlicht zu groß?
Hallo Pusti64,
von mir kam ja lediglich die Idee. Die geniale Umsetzung kam wie immer von Dir.
naja, da müssen aber auf jeden Fall noch Ro(nn)y Bachmann genannt werden. Sie haben den Treiber damals für Gateway geschrieben und (sehr löblich) die Quelltexte dazu veröffentlicht. Ohne das gäbe es den Treiber heute nicht!
Meine Frage zielte eher auf die internen Treiber. Wie bekommt man also so einen externen Treiber sauber in die interne Treiberauswahl?
Oder ist der Aufwand schlicht zu groß?
Das ist ganz schöner Aufwand, weswegen ich das bisher nicht in Angriff genommen habe und wohl auch nicht tun werde .....
Andere Probleme die es da gibt sind mir einfach wichtiger.
Der Treiber ansich muss genau so aufgebaut sein wie beschrieben. Dazu benötigt man eine Installations-Routine. In der Treiber-Datei von MP3 gibt es in der Regel 2 VLIR-Datensätze je Treiber. Der erste enthält die Installations-Routine, der 2. den eigentlichen Treiber. Diese Installations-Routine kann drastisch gekürzt aus dem jetztigen Installations-Programm entnommen werden. Wenn ich das richtig im Kopf habe gibt es da 2 oder 3 Einsprünge.
Dann muss man dem Editor noch irgendwie mitteilen, wie der neue Treiber heißt, welchen Drive-Typ er hat und wo er in der Treiber-Datei zu finden ist. Das ist soweit "relativ" einfach.
Das große Problem ist, dass Teile des jetzigen Installationsprogramms wohl irgendwie auch in den Editor direkt integriert werden müssen (z.B. Auswahl der Laufwerks-Adresse). wo kann ich das wie unterbringen? Der Editor lädt intern mindestens Teile der Treiberdatei nach (bzw. aus der RAM). Wenn der Editor jetzt größer wird (durch zusätzliche Routinen) kann passieren, das da irgendwas anderes überschrieben wird. Ein originaler Quelltext für MP3 liegt leider nicht vor ... :-(.
Deshalb bevorzuge ich das als externer Treiber. War ja bei 64NETV1 genau so ....
Gruß
Werner
Schade halt, dass die Bachmänner ihre C64/128-Tätigkeiten irgendwann eingestellt haben.
Den Quellcode zum GeosEditor.128 kannst Du gerne bei Gelegenheit von mir bekommen. Vielleicht kannst Du ihn ja auch für andere Problemlösungen gebrauchen.
Hallo,
Schade halt, dass die Bachmänner ihre C64/128-Tätigkeiten irgendwann eingestellt haben.
naja, so ist es nun mal .... Sind ja nicht mehr viele da, die noch was machen ........
Den Quellcode zum GeosEditor.128 kannst Du gerne bei Gelegenheit von mir bekommen. Vielleicht kannst Du ihn ja auch für andere Problemlösungen gebrauchen.
Mit Sicherheit. Und wenn wäre auch der GeosEditor64 für mich interessant. Würde auf jeden Fall helfen.
Es gibt da ja mindestens 2 Probleme (Abschalten Bildschirmspeicher wird nicht gespeichert, Probleme mit 1541-Cache Treiber). Und aktuell ist da noch das Thema uIEC/SD2IEC als Native-Laufwerk. Da findet irgendeine Abfrage statt, ob da eine CMD-HD oder CMD-FD angeschlossen ist (hier im Thema MP3 Patch und Laufwerksverwaltung ) ......
Gruß
Werner
Habe den Quellcode Stückchenweise erstellt. Halt so wie ich in der Vergangenheit die Lust dazu hatte.
Aber sobald ich die 128er Version fertig habe, kannst Du sie bekommen.
Den GeosEditor.64 nehme ich mir dann danach vor.
Display MoreOh doch.
Gerade getestet:1. Man nehme eine frisch geplättete Disk mit 664 freien Blöcken.
2. Einmal OPEN 1, 8, 15, "B-A 0 1 0":CLOSE 1 eingeben, um T1S0 zu belegen.
3. Verzeichnis laden, man sieht 663 freie Blöcke. Ok, schön.
Aber:
4. Einmal die Disk aus dem Laufwerk nehmen und wieder einlegen, dann:
5. Verzeichnis laden, nun sieht man 643 freie Blöcke. Die BAM im Drive-RAM war also korrekt, aber die auf der Disk ist falsch. Alle 21 Blöcke von Spur 1 wurden belegt.
Eben nicht 
!!!
Ich programmiere hier direkt unter Geos. Da hat man das Problem nicht.
Hier mal der Quellcode, den ich in Topdesk 128 für MP3 eingefügt habe:
Was passiert hier:
zunächst wird geprüft, ob ein Native-Mode-Laufwerk vorhanden Zeile 1 -7) ist. Das kann derzeit unter MP3 nur ein CMD-Gerät sein. Ist das der Fall, wird beendet. Wenn nicht, wird in Zeile 8 die BAM in den Speicher nach $8200 gelesen. Zeile 9-18 holen Track 1 Sektor 0 (den Boot-Sektor) nach $8000. Anschließend (Zeile 19-27) prüfe ich ob die ersten 3 Bytes des eingelesenen Bootsektors CBM lauten. Nur wenn das zutrifft, ist es ein Bootsektor, der dann über die Zeilen 28-34 im Speicher bei $82000 als belegt gekennzeihnet wird. Zum Schluss wird die geänderte BAMin Zeile 35 auf die Diskette geschrieben.
Ja, Geos hat auch Vorteile .
Manipulationen an der BAM finden in Geos immer im Speicher statt und die BAM muss anschließend komplett auf Diskette gespeichert werden.
Ich habe es probiert an meinem C128DB mit der eingebauten 1571, die eine frisch formatierte 1541-Diskette enthält. BootSektor mit MBM128V8 erzeugt, 663 Blöcke frei. MP3 geladen mit originalem Topdesk und die Diskette "Validiert". Wie erwartet, der Bootsektor wird freigegeben (664 Blöcke frei). Topdesk ausgetauscht mit einem der obige Routine enthält und erneut "Validiert". Ergebnis: 663 Blöcke frei.
Ich habe nach jeder Aktion MP3 beendet, die Disk aus dem Laufwerk genommen, wieder eingelegt und im BASIC das Directory aufgerufen. Auch hier: die gleichen Block-Anzeigen. Zusätzlich habe ich mit einem Diskmonitor unter MP3 die BAM kontrolliert. Alles korrekt. Es wird immer nur 1 Block belegt und freigegeben .....
Der Anfang des Codes (Überprüfung auf Native-Lauferk) kann sogar entfallen. Spätestens in Zeile 33 und 34 würde der Fehler abgefangen.
Gruß
Werner
Hallo,
Aber sobald ich die 128er Version fertig habe, kannst Du sie bekommen.
Den GeosEditor.64 nehme ich mir dann danach vor.
Danke. Auch wenn ich dann erstmal nur eine Version habe, wird das auf jeden Fall helfen. Schick das dann an meine E-Mail-Adresse.... DANKE.
Gruß
Werner
Eigentlich reichts schon, wenn man eine mit Debugausgaben compilierte sd2iec-Version hat und da mitliest,
Und wie soll ich das machen? 
Wenn ich eine fertig compilierte Version bekomme und mir erklärt wird, wie und wo man da mitlesen kann. Der Test würde am C128DB mit MP3-128 auf meinem uIEC/SD v3.2 von 2011 erfolgen ....
Gruß
Werner
Abschalten Bildschirmspeicher
Das soll eigentlich Abschalten Bildschirmschoner heißen. Sorry.
Gruß
Werner
Und wie soll ich das machen?
Wenn ich eine fertig compilierte Version bekomme und mir erklärt wird, wie und wo man da mitlesen kann. Der Test würde am C128DB mit MP3-128 auf meinem uIEC/SD v3.2 von 2011 erfolgen ....
Mit dem uIEC/SD wird das IIRC schwierig, ich bin mir nicht sicher ob die Pins dafür irgendwo rausgeführt sind. Alternativ könntest du mir ein bootfähiges Image schicken und ich lasse es mal bei mir durchlaufen.
Naja, momentan kannst Du unter Wheels auch DNP benutzen....
Stimmt auch wieder.
Somit könnte man die CMD-HD auf SD sichern, wenn ein DNP 16 MB gross sein kann.
Dürfte über den IEC-Bus wohl länger als 5 Minuten dauern
Und MP3 folgt ja vielleicht noch 
Deshalb bevorzuge ich das als externer Treiber.
Externe Treiber haben, aus meiner Sicht, auch den Vorteil, dass sie einfacher ersetzt werden können.
Ist eine neue Version verfügbar, kann die Alte einfach ersetzt werden.
Ist der Treiber in der GeoDisk, müsste eine neue Version programmiert oder mit Patch gearbeitet werden.
Was, je nach vorhandenem System, eine Neuinstallation mit sich bringt (z.B. 1541 Boot-Disk).
Schade halt, dass die Bachmänner ihre C64/128-Tätigkeiten irgendwann eingestellt haben.
Ja ist so.
Hatte gute Ideen, ein Teil wurde leider nie verwirklicht 
naja, so ist es nun mal .... Sind ja nicht mehr viele da, die noch was machen ........
Zum Glück ist Werner Weicht noch aktiv
(Abschalten Bildschirmschoner wird nicht gespeichert,
Es gibt doch ein "kleines" Programm von Dir (BS-Off oder so ähnlich), welches den Bildschirmschoner deaktiviert.
Gruss C=Mac.
Hallo C=Mac,
Somit könnte man die CMD-HD auf SD sichern, wenn ein DNP 16 MB gross sein kann.
Sicher.
Dürfte über den IEC-Bus wohl länger als 5 Minuten dauern
Wenn Dein Rechner JiffyDOS hat, ist das SD2IEC ziemlich flott.
Zum Glück ist Werner Weicht noch aktiv
Es gibt doch ein "kleines" Programm von Dir (BS-Off oder so ähnlich), welches den Bildschirmschoner deaktiviert.
Ja, das ist aber nur eine "Notlösung", weil das dauerhafte Speichern dieser Einstellung im GeosEditor nicht funktioniert.
Gruß
Werner
Wieso wollt ihr den BS deaktivieren? Macht der BS irgendwo Probleme? Ich benutze den BS von Anfang an und finde ihn richtig cool.
Wieso wollt ihr den BS deaktivieren?
Ist Ansichts- bzw. Geschmacks-Sache .
Mir waren von Anfang an die einstellbaren Zeiten im Geos.Editor zu klein (max. 3:xx Min). Außerdem dauert die Aktivierung besonders bei 128 recht lange. Die Zeit bis zur Aktibvierung des BS könnte man zwar mit einem weiteren Auto_Exec bestimmt erhöhen, aber da schalte ich es lieber ab (stört manchmal).
Bei mir ist auch das Hintergrund-Bild grundsätzlich abgeschaltet. Ich will mit dem System arbeiten und nicht warten, wenn sich jedesmal das Hintergrundbild aufbaut.
Ich benutze den BS von Anfang an und finde ihn richtig cool.
Ironie an.
MP3 ist cool. Ich schaue mir stundenlang die Bildschirmschoner und das Hintergrundbild an!
Ironie aus.
Gruß
Werner
Dann schaun wir mal, was da demnächst für Fragen kommen zum SD2IEC...
O.K.
Ich kann's doch nicht lassen
Wenn ich es richtig verstanden haben, kann Wheels die verschiedenen D's benutzen und zusätzlich auch die DNP's.
Für Wheels ist ein DNP, eine HD-Partition. Der Wechsel kann mit dem normalen C=S Befehl erfolgen
Bei MP3 sieht es, im Moment, anders aus.
Es sind die "normalen" D's möglich, z.B. D81. Der "Diskettenwechsel" erfolgt mit dem uIEC-Manager.
MP3 ist cool. Ich schaue mir stundenlang die Bildschirmschoner
Also der 64'er-Move ist schon cool und der Sound erst
Gibt es auch einen 128'er-Move
Duck und weg
Ne im ernst, ist reine Geschmacksache.
Der Eine will einen, der Andere nicht.
Gruss C=Mac.
Hallo C=Mac,
Wenn ich es richtig verstanden haben, kann Wheels die verschiedenen D's benutzen und zusätzlich auch die DNP's.
Für Wheels ist ein DNP, eine HD-Partition. Der Wechsel kann mit dem normalen C=S Befehl erfolgen
Bei MP3 sieht es, im Moment, anders aus.
Es sind die "normalen" D's möglich, z.B. D81. Der "Diskettenwechsel" erfolgt mit dem uIEC-Manager.
Ich habe es nicht probiert aber sehr wahrscheinlich funktioniert das nicht.
Bedenke: Das SD2IEC ist kein CMD-Gerät und das Dateisystem auf dem SD2IEC ist ein anderes als auf CMD-Lfw.
Beim SD2IEC ist vieles an CMD angelehnt, aber es ist eben nicht CMD.
Nutze simpel den uIEC-Manager. Der kann bereits DNP und läuft unter Geos, MP3 und Wheels.
Es gab hier im Forum mal eine Diskussion, das z.B. mit "CMD_Move" D81s auf dem SD2IEC gewechselt werden können müßten. Genau das funktioniert aus dem von mir genannten Gründen nicht.
Gruß
Werner
