Anbei die versprochenen Images. Um mein Tool dazu zu überreden, das P81 ohne Seitenvertauschung zu erzeugen, habe ich einfach als Floppy 1541 angegeben, wenn die Angabe geprüft wird, muss man die per Hexeditor halt vorher anpassen. Und um Verwirrungen zu vermeiden, habe ich dem dann natürlich auch die Endung P64 gegeben, es ist ja die 1541 angegeben.
Die Wrong Versionen funktionieren mit dem noch aktuellen Denise.
für die nicht kopiergeschützen Disketten einer 1581 (da sind kopiergeschhütze die seltene Ausnahme, wer kann schon eine zweite nennen? Wheels Master diskette gebe ich mal vor
)
Hier, ich 
...
Ende 1989 / Anfang 1990 (also sehr lange bevor man an Wheels überhaupt denken konnte) erschien in den USA die Disk "RUNs GEOS COMPANION". Darauf u.a. enthalten 2 Geos-Programme von Jim Collette: GEOS64--1581 und GEOS128--1581. Die Programme kopieren Teile einer originalen 1541-Geos-Bootdisk lauffähig! auf eine 1581. Meines Wissens war das das erste mal überhaupt, daß Geos-Boot-Disketten auf einer 1581 erstellt werden konnten. Das funktioniert auch mit deutschem Geos V2.0.
Das universellere (aber langsamere) geoMakeBoot von CMD erschien erst später ....
Habe das gerade mal unter VICE probiert.: Funktioniert soweit. Nachteil: Das erstellte D81 ist etwa 10 kB größer als ein normales D81 (819.200 Bytes normales D81 <--> 829.440 Bytes behandeltes D81 (was übrigens exakt der Größe eines D1M entspricht)). Damit fällt mindestens ein SD2IEC zum Probieren raus (das verlangt exakte Images-Größen für Dxx)....
Wer es testen will, auf der F64-Wolke unter : Software\GEOS\Apps+Tools\RUNs_GEOS_COMPANION.7z (Diskette)
und : Handbücher & Bedienugsanleitungen\GEOS-DE-EN\RUNs GEOS COMPANION_US.pdf (Handbuch)
Gruß
Werner
PS: mehr kopiergeschützte Software auf 1581 ist mir nicht bekannt
Habe das gerade mal unter VICE probiert.: Funktioniert soweit. Nachteil: Das erstellte D81 ist etwa 10 kB größer als ein normales D81 (819.200 Bytes normales D81 <--> 829.440 Bytes behandeltes D81 (was übrigens exakt der Größe eines D1M entspricht)).
Also im Prinzip das selbe wie bei den Wheels Master Disketten. Die sind im D81 auch 829.440 Bytes groß. Und dass das exakt die Größe eines D1M entspricht, ist kein Zufall: Das physische Diskettenformat ist exakt das selbe, nur der logische Inhalt der Sektoren ist verschieden.
Nachteil: Das erstellte D81 ist etwa 10 kB größer als ein normales D81 (819.200 Bytes normales D81 <--> 829.440 Bytes behandeltes D81 (was übrigens exakt der Größe eines D1M entspricht)).
D1M verwendet Spur 81 für Systemkram wie die Partitionstabelle, das Tool wird dann wohl auf der 1581 auch irgendwas auf Spur 81 abgelegt haben.
Damit fällt mindestens ein SD2IEC zum Probieren raus (das verlangt exakte Images-Größen für Dxx)....
Selbst wenn es sich mounten liesse würde es wohl am unbekannten Drive-Code scheitern weil ja irgendwie auf Track 81 zugegriffen werden muss.
Wer es testen will, auf der F64-Wolke unter : Software\GEOS\Apps+Tools\RUNs_GEOS_COMPANION.7z (Diskette)
und : Handbücher & Bedienugsanleitungen\GEOS-DE-EN\RUNs GEOS COMPANION_US.pdf (Handbuch)
Das könnte ich direkt mal machen. Ich habe in meiner Ultimate einen Patch drin, so dass jene 81 Track D81 kann.
Eigentlich gefällt mir das Read Only Flag im Header der P64 super... Vielleicht sollte man das für G81 auch einführen? Man könnte das "MFM" dann einfach klein schreiben, wenn es schreingeschützt sein soll.
Du meinst als Vorauswahl(Empfehlung) wie ein Abbild eingelegt wird mit der Möglichkeit des Nutzers dies per Checkbox oder so zu umgehen. fände ich gut.
Beim Amiga ist es so üblich, dass veränderte Tracks in ein extra image geschrieben werden und dies beim Einlegen gesucht, angewendet und dem Nutzer dafür ein Lösch button zur Verfügung gestellt wird.
Beim IPF ist das wirklich hilfreich.
Ich bin gerade am hin- und herüberlegen. Grundsätzlich gefällt mir die Vereinheitlichungsidee. Auf der anderen Seite sehe ich durchaus Sinn darin, 5,25″ und 3.5″ unterscheidbar zu haben. Für letzteres tut es vielleicht auch einfach ein Flag 8 (Flag 4 möchte ich für die hohe Auflösung reservieren).
hohe Zeitauflösung für HD Laufwerke, CBM8250, FD-2000, ... Das ist für mich dann schon nicht mehr interessant zwecks Emulation.
Grundsätzlich habe ich nichts gegen ein Format, welche intern alle Pxy bzw. Gxy abbildet. Dennoch find ich es aus Nutzer Sicht übersichtlicher, wenn man diese über den Datei Suffix dem Nutzer verständlich macht.
Da es bei dekodierten Formaten zwangsweise zu verschiedenen Dateieindungen kommen musste (D64, D71, D81) erzeugt dies beim Nutzer eine bestimmte Erwartungshaltung.
Wenn nun ein *.p64 oder *.g71 ein Abbild einer 1581 darstellt, kann man dies schnell als solches falsch einordnen.
Zum Glück habe ich Denise jetzt so umgebaut, dass trotz Auswahl einer 1541 ein image für die 1581 das entsprechende Laufwerk aktiviert.
Abweichende Abbilder stellen dann das Modell automatisch um und so kann in Device 8 eine 1541 laufen und in Device 9 eine 1581.
Der Nutzer müsste ansonsten also schon wissen, das sein P64/G71 für eine 1581 bestimmt ist.
Eine Frage, über die ich vorgestern irgendwie gedankenlos hinweggegangen bin: Wie bist Du eigentlich auf den Headerwert für die maximale Trackgröße gekommen? Der 12500 ist.
Der erscheint mir nämlich ein bisschen zu niedrig. Bei Gxx Formaten wird da eine pessimistische Abschätzung des Worstcases eingetragen. Damit das auch unter wiedrigen Umständen passt.
Standard Wert für MFM: 6250 * 2 (Clock bit)
"Disketten im MFM-Format werden mit genau 250.000 Bits pro Sekunde beschrieben und gelesen. Bei fünf Umdrehungen pro Sekunde ergibt dies pro Spur 50.000 Bits, also 6250 Bytes."
Alle Gxy Formate in Denise verändern nie nachträglich die Tracklänge, selbst wenn mit einer abweichenden Geschwindigkeit geschrieben wurde.
Das könnte man grundsätzlich einbauen und ja dann wäre eine möglichst große Max Track Länge sinnvoll. Das image will ich auf keinen Fall nachträglich neu aufbauen.
welcher Wert wäre hier ein sinnvoller worst case ? Da fehlt mir die Erfahrung, wie schmal Bitzellen gängiger protections werden können.
Dann könnte man mal versuchen ein V-MAX z.B. in Emulation auf ein G64 zu schreiben.
Anbei die versprochenen Images. Um mein Tool dazu zu überreden, das P81 ohne Seitenvertauschung zu erzeugen, habe ich einfach als Floppy 1541 angegeben, wenn die Angabe geprüft wird, muss man die per Hexeditor halt vorher anpassen. Und um Verwirrungen zu vermeiden, habe ich dem dann natürlich auch die Endung P64 gegeben, es ist ja die 1541 angegeben.
Die Wrong Versionen funktionieren mit dem noch aktuellen Denise.
danke, passt nun schon. lässt sich einlesen bin aber noch nicht fertig. kann das TOC des P81 zwar in Emulation anzeigen aber nicht mit Standard timing als Vorschau vor der eigentlichen Emulation.
Ich muss also die Laufwerks Emulation für jeden Track (ohne CPU/Cia) in einer sandbox durchführen. Das Problem hatte ich damals auch beim GCR P64.
Also im Prinzip das selbe wie bei den Wheels Master Disketten. Die sind im D81 auch 829.440 Bytes groß. Und dass das exakt die Größe eines D1M entspricht, ist kein Zufall: Das physische Diskettenformat ist exakt das selbe, nur der logische Inhalt der Sektoren ist verschieden.
ist ein guter Test um zu schauen ob der extra Track angefügt wird, habe ich für alle 3 Formate getestet.
Du meinst als Vorauswahl(Empfehlung) wie ein Abbild eingelegt wird mit der Möglichkeit des Nutzers dies per Checkbox oder so zu umgehen. fände ich gut.
Kommt drauf an - wenn Du das als Option in den Einstellungen machst, dass man wählen kann, ob Empfehlung oder Verfpflichtend, dann kann ich da kaum was dagegen haben.
Ich denke gerade an den nicht allzu seltenen Fall, dass man jungfräuliche Originale (Geos nicht installiert oder so was) ablegen will und die sich nicht versehentlich kaputt machen will.
Diese Überlegung bringt mich dazu, den ersten Absatz noch zu optimieren: Oder noch besser, er fragt nach, ob man Readonly einhängen will oder beschreibbare Kopie davon erzeugen. Dann macht man sich nichts versehentlich kaputt und dann doch beschreiben.
Wenn nun ein *.p64 oder *.g71 ein Abbild einer 1581 darstellt, kann man dies schnell als solches falsch einordnen.
Ja, mit Ausnahmen. Natürlich will man eine Diskette, die füe 1541 gedacht ist, auch in einer 1571 einlegen können. Und ebenso funktioniert eine echte 1581 Diskette in einer CMD FD2000 bzw. FD4000. Das möchte man also auch erlauben.
Ansonsten gerne restriktiv oder mindestens eine starke Warnung.
Wie Unseen schon schrieb, will man gewisse CP/M Sachen ja vielleicht doch einlegen können. Und da eine 1581 auch MSDOS lesen kann mit passender Software, vielleicht auch das.
"Disketten im MFM-Format werden mit genau 250.000 Bits pro Sekunde beschrieben und gelesen. Bei fünf Umdrehungen pro Sekunde ergibt dies pro Spur 50.000 Bits, also 6250 Bytes."
In einer idealen Welt. Aber welche Floppy rotiert schon mit überhaupt keiner Abweichung? Beim Atari ST (der denselben Floppycontroller hat wie die 1581) war es sogar so, dass quasi alle Floppies leicht langsamer rotierten, so dass man einen 11. Sektor drauf bekam. Sobald man aber wegen Defekt die FLoppy durch eine günstigere PC Floppy ersetzt hat, passte der nicht mehr drauf. Soweit zur Theorie, die Praxis ist das nicht.
Alle Gxy Formate in Denise verändern nie nachträglich die Tracklänge, selbst wenn mit einer abweichenden Geschwindigkeit geschrieben wurde.
Ja schon, würde eine größere Tracklänge gehen, wenn man die per GreaseWeazle von einer echten Diskette einliest und dann nach G81 wandelt? G71 analog. Das so etwas da weg kommt, ist ja realistisch.
kann das TOC des P81 zwar in Emulation anzeigen aber nicht mit Standard timing als Vorschau vor der eigentlichen Emulation.
das habe ich im zuletzt getesteten Snapshot auch beobachtet mit einer konvertierten Test-/Demodiskette.
ist ein guter Test um zu schauen ob der extra Track angefügt wird, habe ich für alle 3 Formate getestet.
Stimmt. Wobei die Wheels Masterdiskette ein gleich guter Test ist, die wird nämlich auch per C64 Programm geschrieben mitsamt dem 81. Track.
welcher Wert wäre hier ein sinnvoller worst case ? Da fehlt mir die Erfahrung, wie schmal Bitzellen gängiger protections werden können.
Mir auch - aber ich habe eine Idee, wie man die fehlende Erfahrung kompensieren könnte. Nämlich den Standard G64 Wert umrechnen.
7928 bei 3,25 µs bitcellsize => 7928 * 3,25 = 25766
Daher hätte man bei 2µs dann 25766 / 2 = 12883, das wirkt sio krumm, da würde man dann 12900 machen.
Das geht, weil die RPM die gleiche ist.
Edit: Plausicheck sagt natürlich, dass die Gtößenordnung passt, es ist wirklich in dem Bereich, den man erwartet hätte.
Das könnte ich direkt mal machen.
Nun ja, ich habe jetzt Geos64 und Geos128 durchprobiert (das D81 jeweils erstellt unter VICE und auf SD2IEC bzw. 1541UII kopiert):
Geos64 in VICE problemlos von FD4000 oder 1581, ist egal
Geos128 in VICE etwas problematisch (geht seltsamerweise nur wenn Bootdisk als 1581 konfiguriert ist; ob es am Programm selbst, an X128 (Win64) oder sonstwas liegt: keine Ahnung)
Geos64 auf SD2IEC und Geos128 auf SD2IEC: wie zu erwarten war: keine Change (SD2IEC mag keine Dxx, die sich nicht an die vorgegebene Größe halten!)
Geos64 und Geos128 auf 1541UII+ Geos64 verhält sich wie eine kopierte originale Geos-Diskette: RESET. Geos128 startet gar nicht erst.
Vielleicht hilft es ja, wenn man versucht die Disketten direkt auf 1541UII+ (D81) zu erstellen ....
Gruß
Werner
Geos64 und Geos128 auf 1541UII+ Geos64 verhält sich wie eine kopierte originale Geos-Diskette: RESET. Geos128 startet gar nicht erst.
Geht mit meiner Firmwarebuild - wobei ich bisher nur Geos 64 ausprobiert habe... Ich hoffe, Gideon will den Patch dazu übernehmen. Allerdings muss man bei den Patch sich aktiv entscheiden, ob man ein 80 Track oder ein 81 Track D81 erzeugen will, von selbst erweitern tut er das nicht...
Und da es heir um Denise geht, habe ich auch einen guten Grund, nur Geos 64 ausprobiert zu haben, denn genau das will ich mit Denise nochmal machen sowie die mit der Ultimate erzeugten Dateien konvertieren in die anderen Formate. Wenn die Formate final sind.
nightly:
so jetzt sollte es passen.
Ja schon, würde eine größere Tracklänge gehen, wenn man die per GreaseWeazle von einer echten Diskette einliest und dann nach G81 wandelt? G71 analog. Das so etwas da weg kommt, ist ja realistisch.
ja wie beim G64. Es wird nicht fix die Standard Track Länge gesetzt, sondern die vom Gxy vorgegebene.
Wird ein neues Gxy erstellt wird die Standard Track Länge verwendet, welche dann nicht mehr verändert werden kann.
Beim Amiga hatte ich ein Fall wo ein Original eine nicht standardisierte Track Länge für einen Track vorgab, auf dem später der Hiscrore geschrieben wurde.
Beim nächsten Lesen des Tracks war Schluss. Die Software funktionierte erst als die Standard Länge, welche der Amiga schreibt, auch gesetzt und angewendet wurde.
Und das feature fehlt aktuell noch in der Gxy Emulation.
Ja, mit Ausnahmen. Natürlich will man eine Diskette, die füe 1541 gedacht ist, auch in einer 1571 einlegen können.
ja das ist berücksichtigt.
7928 bei 3,25 µs bitcellsize => 7928 * 3,25 = 25766
Daher hätte man bei 2µs dann 25766 / 2 = 12883, das wirkt sio krumm, da würde man dann 12900 machen.
3,25 micro. ich vermute damit kann man invalides MFM produzieren. also keine 0 bits dazwischen.
ok habe nur die Max Track Länge der erstellbaren G81 auf 12900 erhöht. blanko G81 wird etwas größer.
Es gibt nun auch die Möglichkeit ein extra sound Profil für 3,5 Zoll Laufwerke einzustellen. Da ich keine Aufnahmen einer 1581 erstellen kann, habe ich alternativ erstmal die sounds des externen Amiga Laufwerks verwendet. Das klingt sicher ähnlicher als eine 1541 oder so.
Zu dem sind die Drive LEDs für sämtliche Laufwerke angepasst. manche rot (gelb beim schreiben), manche grün (rot beim schreiben)
Die Färbung beim Schreiben ist natürlich nicht original.
7928 bei 3,25 µs bitcellsize => 7928 * 3,25 = 25766
Daher hätte man bei 2µs dann 25766 / 2 = 12883, das wirkt sio krumm, da würde man dann 12900 machen.
3,25 micro. ich vermute damit kann man invalides MFM produzieren. also keine 0 bits dazwischen.
ok habe nur die Max Track Länge der erstellbaren G81 auf 12900 erhöht. blanko G81 wird etwas größer.
Die 3,25 µs sind GCR Werte. Mangels besseren Wissens habe ich einfach mal angenommen, dass die Drehzahltoleranz der Floppy, die ja mit dem Aufzeichnungsformat nichts zu tun hat, vergleichbar ist. Und von den GCR Werten war natürlich der kleinste zu nehmen, denn nur der maximiert die Anzahl Bytes - was heißt, mit den anderen Werten kommt man nicht einmal in die Nähe des Maximums.
nightly:
so jetzt sollte es passen.
MacOS hat nicht gebaut, warum auch immer.
MacOS hat nicht gebaut, warum auch immer.
"Build job has failed to start, but backup cloud is not configured."
Ich hoffe es ist nur ein temporäres Problem.
Ich bin gerade mit Denise am Verzweifeln: Ich versuche seit einer halben Stunde, ein "P71" mit Debise so anzulegen, dass sowohl Denise als auch Vice das verstehen. Ich glaube, ich lehne mich nicht zu weit aus dem Fenster, wenn ich behaupte: Das wollen die Benutzer.
Lange Rede, kurzer Sinn: Ich konnte in dem Erstelldialog wohl die Endung ".p64" eingeben, die VICE haben will. Das hat er auch genommen. Aber im Header steht "P64-1571" drin, das mag VICE nicht.
Ist "P64-1541" oder "P64-1571" beser oder richtiger? Schwer zu sagen, es gibt für beide Sichtweisen Argumente:
Pro "P64-1571": Nun ja, es ist irgendwie schon für die 1571.
Pro "P64-1541": Das Fluxformat legt nicht fest, was im Image drin ist. Es könnte da genauso gut eine 1541 kompatible Vorderseite und eine lediglich per 1571 erreichbare Rückseite drin sein, auf die dann mit "U0>H1" umgeschaltet werden muss. So eine Diskette einer 1541 vorzuenthalten, ob das richtig ist? Und das die doppelseitig ist, nun ja, das steht ja bereits im Flag, es ist also nicht irgendwie versteckt.
Kleiner Schönheitsfehler: Wenn ich die P71, die mit einer älteren Denise erstellt ist, einzuladen versuche, stürzt Denise komplett ab.
Wie auch immer, im VICE bekomme ich die nur rein, wenn ich mit einem Hexeditor den Header abändere. Das ist nicht wirklich gut. Zumal VICE das verwendete Format auch dokumentiert hat: https://vice-emu.sourceforge.io/vice_16.html#SEC402
Das hat er auch genommen. Aber im Header steht "P64-1571" drin, das mag VICE nicht.
eine zwei seitige P64 läßt sich da nicht anlegen oder?
Pro "P64-1571": Nun ja, es ist irgendwie schon für die 1571.
Pro "P64-1541": Das Fluxformat legt nicht fest, was im Image drin ist. Es könnte da genauso gut eine 1541 kompatible Vorderseite und eine lediglich per 1571 erreichbare Rückseite drin sein, auf die dann mit "U0>H1" umgeschaltet werden muss. So eine Diskette einer 1541 vorzuenthalten, ob das richtig ist? Und das die doppelseitig ist, nun ja, das steht ja bereits im Flag, es ist also nicht irgendwie versteckt.
aus Kompatibilitätsgründen ist P64-1541 günstiger. Den Datei Suffix finde ich entscheidend. Ne zwei seitige Disk mit einer .p71 Endung ist Nutzer freundlicher.
Kleiner Schönheitsfehler: Wenn ich die P71, die mit einer älteren Denise erstellt ist, einzuladen versuche, stürzt Denise komplett ab.
das könnte im letzten nightly gefixt sein, andernfalls mal die disk anhängen oder war es eine blanko disk?
eine zwei seitige P64 läßt sich da nicht anlegen oder?
Interesanterweise habe ich da nichts gefunden. Ob die das vergessen haben? Es stand IIRC bei denen mal auf der TODO Liste... Am besten, ich mache denen demnächst mal ein Issue.
en Datei Suffix finde ich entscheidend. Ne zwei seitige Disk mit einer .p71 Endung ist Nutzer freundlicher.
Den sollte in der Tat VICE auch unterstützen, ein weiteres Issue. Nachdem die jetzt jahrelang .P64 genommen haben als Endung, müsste man wahrscheinlich beide Endungen gleich behandeln. Sprich: Die Endung ist an dieser Stelle ein Hinweis für den Benutzer, nicht für den Emulator.
Und vor allem: Manchmal will oder muss man eine ältere VICE Version nehmen, daher ist die P64 Endung auch dann nach wie vor hilfreich.
Anderseits reicht es, dann man beim Image erzeugen Dialog einfach einen Dateinamen mit Endung .p64 eingibt, wenn man es wirklich will. Und genau das hat zuletzt im Denise funktioniert.
das könnte im letzten nightly gefixt sein, andernfalls mal die disk anhängen oder war es eine blanko disk?
Ich habe eine Blank D71 erzeugt und per
g64conv blank.d71 blank.g71
g64conv blank.g71 blank.g71.txt p64
p64conv blank.g71.txt p64 blank-p71.p64
die konvertiert. Bisshen viel Konvertierung, geht aber problemlos. Allerdings überlege ich inzwischen ernsthaft, ein Repository auf github aufzumachen mit Beispielimages. Damit man für Tests sowie für Bugreports immer welche griffbereit hat. Wer würde da mitmachen?
das könnte im letzten nightly gefixt sein, andernfalls mal die disk anhängen oder war es eine blanko disk?
Crashed noch immer. War eine Blank. Dennoch füge ich die hier mal an. Wie gesagt, ist vom älteren Denise, als das P71 noch anders war. Den Crash beobachte ich unter Windows - könnte es bei Bedarf aber auch auf einen Mac M1 ausprobieren.
