Denise C64 + Amiga Emulator

Quote from PiCiJi

- um den Nutzer nicht zu verwirren. Die erwarten keine G71 für die 1581

Ja, andere Endung, meinetwegen auch andere FLoppy im Header ist ok. Aber weitere Unterschiede, muss man die haben oder macht man damit nur das Handling schwerer?

Ferne auch die Tracksize im Header erhöhen, ein allgemein programmiertes Tool stört sich daran nicht.

Quote from PiCiJi

- die G71 muss für MFM support entweder mit einer ungewöhnlichen Größe erstellt werden oder beim Schreiben des ersten MFM Tracks komplett neu aufgebaut werden.

- die G71 hat nur eine 2 Byte Tracklänge. Ich erinnere mich an deinen Trick mit *8 und Angabe der abzuziehenden Bits im letzten Byte.

Ja, richtig. Wobeiu der Z64K Autor auf die Multiplikation mit 8 verzichten will - solange man nur DD Format hat, geht es auch ohne den Teil.

Quote from PiCiJi

Die neue G81 enthält eine 4 Byte Tracklänge um die Größe in Bits anzugeben.

Die Track Max Länge im Header ist wie im G64 jedoch in Byte.

Das habe iuch auch bemerkt. Was ist mit den Teil, der im original G64 die Speedzones angibt? Da lese ich nur Garbage.

Quote from PiCiJi

D71: 70 Tracks (35 pro Seite)

Ich schätze das C64 5 1/4 Zoll MFM weicht von der typischen 3.5 Zoll MFM Darstellung ab.

Tut es nicht wirklich, sowohl mein MFM Dekoder als auch der von Keirf bekommen ohne Fallunterscheidungen sowohl PC Streams als auch Commodore und CMD Streams dekodiert. Aufpassen muss man nur an der Stelle, wo man die Reihenfolge der Sektoren im Image festlegt.

Edit: Aber ich frage ja deswegen nach dem G81 Format, weil ich mein Tool anpassen will... Mach Dir also keinen Kopf...

Edit 2: Ich sehe das eher so wie .docx, .xlsx u.s.w. Sind technisch alles ZIP Dateien, aber um den Anwender nicht zu verwirren, haben die alle eine andere Endung... Und der Inhalt dürfte auch recht eindeutig zu erkennen sein, wenn man weiß, wonach man suchen soll... So kann man das mit den Imageformaten auch sehen.

Edit 3: Was ein WD1770/1772 schreibt, weicht nur unwesentlich zum PC Standard ab - wenn überhaupt. Ja, dadurch, dass er ohne $c2 (mit dem einen fehlenden Bit) schreiben kann, kann es abweichen. Das ist aber schon fast alles....

Quote from markusC64

Was ist mit den Teil, der im original G64 die Speedzones angibt? Da lese ich nur Garbage.

raus geschmissen

hat für GCR nie jemand benutzt. Mittels der speezone infos ein Flusswechsel Format zu imitieren, ist einfach zu fehler trächtig.

Quote from PiCiJi

raus geschmissen

hat für GCR nie jemand benutzt. Mittels der speezone infos ein Flusswechsel Format zu imitieren, ist einfach zu fehler trächtig.

Nibwrite benutzt die - um für die 1541 die richtige Speed zu wählen... Aber klar, für 1581 irrelevant, das sehe ich ein.

Quote from PiCiJi

Die Formate sind ja häufig nach dem System benannt, wofür diese gelten.

Aber auch da gibts Gegenbeispiele, spontan fällt mir zB hfe ein. Ist zwar auch nicht unbedingt das bestdesignte Floppy-Image-Format, kann aber auf jeden Fall Images für diverse Systeme abbilden und ist nach keinem davon benannt.

Quote from PiCiJi

Die Endung ADF möchte ich in der C64 Emulation nicht sehen.

Klar, ein High-Level-Amiga-Disk-Image-Format macht nicht so viel Sinn. Aber was wäre bei einer C128-Emulation mit den Diskimages anderer CP/M-Rechner, die vom C128-CP/M-System unterstützt werden, also zB Kaypro II/IV? Da wäre es doch extrem benutzerunfreundlich wenn man die vor Verwendung erstmal in das proprietäre Format des C128-Emulators konvertieren muss weil der Autor kein schon etabliertes und funktionierendes Image-Format eines anderen Emulators implementieren wollte.

Quote from PiCiJi

wenn man die specs der D71 mit der D81 vergleicht und sich die Tracks/Sektoren anschaut, sieht man das die beiden Seiten der D81 inerhalb des selben Tracks abgelegt sind.

D71 und D81 enthalten die logische Ansicht der Disk, die sind für Markus' Anliegen mit der Kopfnummer in einem Dateiformat, dass die physische Sicht abbildet also nicht relevant.

Wobei für eien Emulation man eher Single Rotation Formate braucht, die einen perfekten Übergang am Ende der Rotation haben. Was bei hfe nicht wirklich der Fall ist... und bei dem im Atari Bereich oft verwendeten Format auch nicht (die nehmen gerne direkt scp).

Es will mir nicht im Kopf, warum das Fluxformat sich dem logischen Format anpassen soll, obwohl da kein Zusammenhang existiert. Im Gegenteil, mit "big blue reader" kann man die Konvention mit einer 1581 brechen und die PC formatieren, lesen und schreiben. Das ist sogar schon fast eher der Anwendungsfall - 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 ) braucht es weder g81 noch p81. Sondern echt nur für Tools wie dem Big Blue Reader.

Quote from Unseen

D71 und D81 enthalten die logische Ansicht der Disk, die sind für Markus' Anliegen mit der Kopfnummer in einem Dateiformat, dass die physische Sicht abbildet also nicht relevant.

Das sollte klar sein.

Es geht hier um eine für alle sinnvolle Festlegung.

Trotzdem hast Du das als Begründung hergenommen, warum im P81 die Seiten vertauscht sind gegenüber P71.

Nun ja, eine 1581 schreibt in jedem Blockheader rein, was das ist. Wenn ich die alle richtig habe, muss ich die P81 wohl richtig gelesen und interpretiert haben. Ohne jeden Restzweifel.

Habe ich das richtig verstanden, für den Amiga hat Denise auch ein Fluxformat? Nun ja, das müsste ich auch ausprobieren. Wie bekomme ich die einzige Amigadiskette, die ich habe, in dem Format gespeichert? Mein Tool sollte auch Amiga MFM dekodieren können (auf RAW-Sektorebene, nicht weiter), allerdings muss ich den Amigateil noch testen und wahrscheinlich debuggen.

Quote from markusC64

Trotzdem hast Du das als Begründung hergenommen, warum im P81 die Seiten vertauscht sind gegenüber P71.

habe mich dafür entschieden, was mir anhand der vorliegenden infos logisch erscheint.

vertauscht ? bezogen worauf ?

auf die Handhabung der Seiten im g71, ein generelles tools zum Konvertieren derartiger Formate ?

Es ist nichts in Stein gemeißelt. Ich kann die Seiten anpassen, wenn dir das sinnvoller erscheint. Mir fehlt hier der Vergleich, warum das von Bedeutung ist.

Quote from markusC64

Habe ich das richtig verstanden, für den Amiga hat Denise auch ein Fluxformat? Nun ja, das müsste ich auch ausprobieren

IPF von der SPS group.

Quote from PiCiJi

vertauscht ? bezogen worauf ?

Ok. Denk Dir mal die einfache Kette von Prozessen:

1) Einlesen einer Diskette mittels GreaseWeazle oder Kryoflux. Meinetwegen auch Fluxengine, habe ich nicht und kann dazu keine Ergebnisse sagen.

2) Konvertieren nach Pxy. Meinetwegen mit dem schon lange verfügbaren g64conv, zusammen mit p64conv. Aber mein erwähnter Alphanachfolger macht das schneller.

Bei Punkt 2 sind wir uns glaube ich einig, dass der Header je nach Pxy verschieden ist, also insb. die Floppyangabe. Bei dem "64" von "P64" muss man sich nicht so sicher sein, das kann man auch Lesen als P64 format für Floppy abcd". Spoiler: Aber okay, es ist gut, dass die Seitenvertauschung mit einer anderen Kennzeichnung davor eingeht.

Nun ja, wirft man das mit einer 1571 und einer 1581 Diskette an, so macht man exakt das selbe. Weil die Tools fehlen, tauscht man meinetwegen den Header mit einem Hexeditor aus für 1581. Da es nur Fluxdaten sind, müsste das eigentlich funktionieren. Dabei gehe ich von P71 wie in VICE aus, dein P71 ist hoffentlich das selbe.

Beobachtung: Während 1571 so ist, dass die Emulation damit klarkommt, sind im so erzeugten P81 genau die Seiten vertauscht.

Background: Das passt damit zusammen, dass am PC eingelesen man die Seiten vertauschen muss, um ein D81 zu generieren.

Falls Du einen original Fluxdump von einer 1581 Testdemodiskette brauchst, den habe ich hier liegen. Die Diskette eigentlich auch, finde ich im Moment aber nicht wieder, offenbar sehr gut verlegt. Da sieht man mit passender Analysesoftware auch, dass die Seiten gegenüber der View einer 1581 vertauscht sind. Commodore hat offensichtlich die Hardware so verdratet, dass die Seiten genau umgekehrt wie beim PC sind. Nun ja, macht nichts, die Formate sind eh inkompatibel, daher konnte Commodore das sich leisten. Vielleicht, dass die dadurch ein Bauteil eingespart haben (Inverter?).

Flux von Diskette ins Fluximage übertragen, so meine Vorstellung, sollte bei allen Pxy Formaten eigentlich gleich sein. Mit Ausnahme von dem Header eben.

Und bei CBM8250 idealerweise mit einer höheren Zeitauflösung im P64, die zur Verarbeitung in der Floppy passt. Die Zeitauflösung ist ja offenbatr an der Verarbeitung der 1541/1571 angepasst, ist aber für MFM auch passend, weil ganzzahliger Teiler der Bitcellsize. Das schon mal erwähnt, wenngleich es derzeit nicht relevant ist.

Quote from PiCiJi

IPF von der SPS group.

Ah. Ok. Das unterstütze ich nicht. Brauche ich auch incht zu unterstützen, weil Keirs Programme das für den Amiga dem Vernehmen nach gut hinbekommen.

Quote from PiCiJi

auf die Handhabung der Seiten im g71, ein generelles tools zum Konvertieren derartiger Formate ?

Lass mal bis später, wir sollten hoffen, dass mit dem Viceteam ein besseres Format verabredet werden kann. Welches die derzeitigen Macken von Gxy los wird.

Quote from PiCiJi

auf die Handhabung der Seiten im g71, ein generelles tools zum Konvertieren derartiger Formate ?

Genau das soll man neues Tool liefern, jeden Dump auf Fluxebene ins Pxy Format umwandeln können. Und das dann nach Gxy wandeln.

Und weil man einen Sektorlesenefehl hat (der allerdings alle Sektoren des physischen Tracks liefert) kann man dann per Powershellskripting damit auch eine Umwandlung nach Dxy basteln.

Die ganze Kette zurück auch. So dass man zum Beispiel im Zweifel ein Pxy, welches ittrümlich Amigadaten enthält, nach FLux wandeln kann und dann Keirs "gw"-Tool den Rest erledigt.

Ich finde es gut, dass das Thema Imageformate andiskutiert wird zwischen Experten.

Generell hat sich sich ja gezeigt, dass

- Flussdump Formate wie Kryoflux RAW Streams zur Nutzung in Emulatoren ungeeignet sind.

- Die Unterscheidung zwischen Datenabbild (D64), Bitabbild (G64) und Flussabbild (P64) sinnvoll ist

Ich würde mir wünschen, dass ihr da gemeinsam (auch mit dem Vice Team) eine gute Lösung findet, so dass kein Formatwildwuchs entsteht.

Die Tools um ein Image in einem bestimmten Format zu erzeugen mit allen notwendigen Extra-Features, um z.B. sicher zu gehen, dass das Image auch OK ist, sind genauso wichtig wie der Support im Emulator. Es wäre schön, wenn das am Ende wie Zahnräder ineinander greift.

Ich habe mir gerade mal überlegt, dass ich meine aktuelle P64 Implementierung hier gerade mal als Referenz posten kann. Die ist so allgemein gehalten, dass die eigentlich jede Floppy bedienen kann, man kann die 4-stellige Floppyangabe in dem Format beliebig setzen und wieder einlesen.

Heute habe ich erfolgreich die Sonderbehaldlung für "P81-1581" reingekommen, der Fall geht auch.

Weitere Features: Bei Floppy "8250" die dazu angepasste Auflösung. Und eine hohe Zeitauflösung, die einfach als kgV von 1541 Auflösung und 8250 Auflösung gewählt ist. Die hat dann auch Reserve, wenn es in Richtung ED Disketten geht.

Wobei man für den hochauflösenden Modus wahrscheinlich ein Flag vergeben sollte, damit es ein Speichern / Wiedereinladen überlebt. Das ist jedoch noch nicht implementiert, weil eh keiner hochqauflösende P64 verarbeiten kann.

nightly

Quote from markusC64

Es will mir nicht im Kopf, warum das Fluxformat sich dem logischen Format anpassen soll, obwohl da kein Zusammenhang existiert.

ok nun ist nur noch das D81 im logischen Format. ein neu erstelltes G81 legt die Tracks/Sides wie ein G71 an und ebenso gelesen/geschrieben.

Passt das nun ?

Die Pxy sind in Denise alle gleich verarbeitet und unterscheiden sich nur in der Anzahl der Seiten und dem 8 Byte Identifier. Wie die Fluss Daten interpretiert werden, als GCR oder MFM ist aus Sicht des Formates egal.

Quote from markusC64

Im Gegenteil, mit "big blue reader" kann man die Konvention mit einer 1581 brechen und die PC formatieren, lesen und schreiben. Das ist sogar schon fast eher der Anwendungsfall

Ich habe in VICE versucht auf ein G71 mittels Big Blue Reader zumindest eine 360k Dos Formatierung aufzubringen. Das funktioniert nicht. Also ist da wohl kein Interesse für ein GCR/MFM Mix Format vorhanden.

Ein P64 (P71 ist nicht erstellbar) hat dafür auch nicht funktioniert. ist schon klar die Kombination MFM + 1571 hat kaum Relevanz. Ich habe das nur der Vollständigkeit halber eingearbeitet.

der nächste Test wäre gewesen eine GCR Text Datei als MFM auf die G71/P71 zu schreben und diesen Text dann zu laden lesen. Das läßt sich alles im BBR durchführen.

Quote from enigma

Ich würde mir wünschen, dass ihr da gemeinsam (auch mit dem Vice Team) eine gute Lösung findet, so dass kein Formatwildwuchs entsteht.

Sobald Interesse besteht gerne. Das G81 kann jederzeit angepasst werden. Ist wohl nicht davon auszugehen, das es Anwendung findet.

Die praktische Relevanz ist schon sehr gering, da es kaum kopiergeschützte oder kommerzielle Software für die 1581 gibt.

---------------

Die VDT für 1581 hatte ich vergessen. Das ist gefixt und man kann Dateien mittels Virtual Device Traps instant laden.

VICE kann kein MFM in Gxy Dateien. Mehr ist dazu nicht zu sagen.

Quote from PiCiJi

ok nun ist nur noch das D81 im logischen Format. ein neu erstelltes G81 legt die Tracks/Sides wie ein G71 an und ebenso gelesen/geschrieben.

Passt das nun ?

Die Pxy sind in Denise alle gleich verarbeitet und unterscheiden sich nur in der Anzahl der Seiten und dem 8 Byte Identifier. Wie die Fluss Daten interpretiert werden, als GCR oder MFM ist aus Sicht des Formates egal.

Ist das jetzt stabil, oder ändert sich das wieder?

Ich habe nämlich gestern einen ganzen 8 Stunden Tag verschwendet, meine Funktionen anzupassen, und jetzt soll das wieder nicht aktuell sein?!

Sorry, solange ich nicht mitgeteilt bekomme, dass es mal so bleibt wie es ist, habe ich sämtliche Motivattion verloren.

Edit + Nachtrag: Ich habe aus der aktuellen Denise Version generierte Images mit meiner Software ausprobiert (da mich ja sowieso die Frage dazu erreichen wird): P81 funktioniert noch immer mit dem Code von gestern. Nach dem Parsen der P81 ist im RAM keine Änderung erkennbar.. Also den ich geposted habe, der für P81 eine Seitenvertauschung vornimmt gegenüber den anderen Pxy Formaten. Ich habe die passenden Stellen mit "// TODO: Check" markiert gehabt, damt ich die im Falle einer Anpassung besser finde.

G81 hat die Änderung offenbar zerlegt... Wegen der ganzen Änderungen bzgl. 4 Byte Länge statt 2 Byte Länge , keine Speedtabelle, ist das aber eh zu den anderen Gxy Formaten inkompatibel, so dass mir egal ist, was wir da haben. Hauptsache, es ändert sich nicht dauernd.

Frage: Gibt es keine Builds für Linux mehr, oder nimmt man Job=MacOS?

Quote from markusC64

Ist das jetzt stabil, oder ändert sich das wieder?

Ich habe nämlich gestern einen ganzen 8 Stunden Tag verschwendet, meine Funktionen anzupassen, und jetzt soll das wieder nicht aktuell sein?!

Sorry, solange ich nicht mitgeteilt bekomme, dass es mal so bleibt wie es ist, habe ich sämtliche Motivattion verloren.

Ich verstehe kein Wort von dem, worum es hier geht (oder warum das so dramatisch wichtig wäre...), aber hast Du nicht selbst beklagt, dass da was "falschrum" sei, dann passt es Piciji daraufhin an und dann bist Du wieder quer? Also da is irgendwas komisch...

Einserseits hast Du Recht, anderseits habe ich aber auch geschrieben:

Quote from markusC64

Lass mal bis später, wir sollten hoffen, dass mit dem Viceteam ein besseres Format verabredet werden kann. Welches die derzeitigen Macken von Gxy los wird.

Bei P64 / P81 ist das in der Tat ein bisschen ärgerlich, aber da ist die Vertauschung noch immer drin. Und bei G81, nun ja, da haben wir so viele Unterschiede zum G64 / G71, dass es da am Ende egal ist.

Deswegen meine ich, die Mühen sind derzeit vergeblich, da man sich noch nicht auf ein Format geeinigt hat.

PS: Für das P81 Format hätte ich nichts gesagt, wenn das mit den Seiten korrigiert worden würde, das sind nur wenige von den wenigen Stellen in den Code, den ich gestern geposted habe (als Anhang). Das gilt auch immer noch.

Jedoch ist es so, dass auch nach der Änderung der alte P64 Code die Seiten falsch herum einliest. Nun ja, hätte ich nicht gestern extra was eingebaut, was bei Header "P81-1581" die Seiten während des Einlesens vertauscht und deswegen das richtige Ergebnis bekommt. Diese Vertrauschung ist auch mit dem neuen Stand noch immer notwendig. Der Patch hat nicht gegriffen.

Vom VICE Team - oder besser von einem Mitglied - habe ich vor einem jahr mal die Auskunft bekommen, dass die für MFM Support keine Zeit hatten. Und damit einhergehend für ein neues Format auch nicht. Wir sollten nochmal Kontakt aufnehmen (mit wir meine ich nicht nur mich, sondern auch diejenigen, die Emulatoren oder Tools schreiben). Allerdings nicht unvorbereitet, ein vorheriges Brainstorming zum Thema wäre wahrscheinlich hilfreich. Dass man sich vorher mal überlegt, welche Features man von dem Format erwartet, damit man dann sinnvoll diskutieren kann.

Quote from markusC64

Nach dem Parsen der P81 ist im RAM keine Änderung erkennbar.. Also den ich geposted habe, der für P81 eine Seitenvertauschung vornimmt gegenüber den anderen Pxy Formaten. Ich habe die passenden Stellen mit "// TODO: Check" markiert gehabt, damt ich die im Falle einer Anpassung besser finde.

ich habe mir nun die cs Dateien angeschaut. Was ich im G81 geändert habe, ist die Tracks einer Seite nebeneinander anzuordnen, anstatt wie vorher im logischen Format anzuordnen,

also T1-S0 T1-S1 T2-S0 T2-S1 ... überführt in T1-S0 T2-S0 .... T80-S0 T1-S1 T2-S1 ...

Ich dachte das meintest du mit vertauscht.

Wenn in Denise ein P81 erstellt wird, wird die Funktion zur Erstellung eines G81 aufgerufen, welche wiederum die Funktion zur Erstellung eines D81 aufruft.

Dann beim Raushangeln aus den beiden Unter Funktionen werden die dekodierten Sektor Daten in MFM kodiert und schließlich als Flusswechsel.

Und die aus Sicht deines tools vertauschten Seiten bleiben dann bestehen.

Ich fixe das die nächsten Tage für G81/P81 (also neben dem oberen Schritt der Entzerrung noch den fehlenden Tausch der Seiten)

und ändere auch P81-1581 in P64-1581 bzw. P71-1571 in P64-1571

Quote from Bodhi1969

Frage: Gibt es keine Builds für Linux mehr, oder nimmt man Job=MacOS?

mein neuer CI Dienstleister für Linux ist nicht so begeistert von Leuten mit nicht kommerziellen Projekten und damit einhergehender fehlender Bereitschaft zu zahlen.

Man hat das Gefühl es wird nur angeboten, weil die anderen es auch tun. Ich habe ein paar Credits bekommen.

Ein Linux Build sind um die 20 Credits.

Ich schiebe bald was rein aber nicht jedes nightly.

Quote from PiCiJi

ich habe mir nun die cs Dateien angeschaut.

Quote from PiCiJi

Ich fixe das die nächsten Tage für G81/P81

Sehr gerne. Die Seitenvertauchung aus G81 rauszunehmen ist in der Tat nicht besonders schwierig. Und meinen Pxx Code kennst Du ja jetzt. Ich denke, wenn da nur noch die Seiten vertauscht werden, dann kann ich das schon mal in meinen Code anpassen.

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.

Quote from PiCiJi

ändere auch P81-1581 in P64-1581

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).

Wenn wir schon mal dabei sind, kann man eigentlich auch die Floppybezeichnungen "FD2K" und "FD4K" festhalten, die dann 3,5″ Markierung auslösen können. Neben "1581", natürlich.

Quote from PiCiJi

P71-1571 in P64-1571

Gerne. Sollten zwar sicherheitshalber in VICE nachschauen, denke aber, da ist das genau so.

Damit nichts schief geht, poste ich zwischendurch mal die 1581 Testdemodiskette in den Formaten.

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.

Wiedrige Umstände wären: Mit einer im Rahmen der Toleranz der MFM Controller besonders langsam drehenden Floppy beschrieben. So dass da mehr Flux und somit mehr Bits draufpassen.

Nun ist aber bei 300 rpm eine Umdrehung 200 000 µs. Da 8 Bit ein Byte sind, teilen wir das mal durch 8, macht 25 000 µs. Das durch 2, da alle 2 µs ein Bit anfällt macht die 12 500, so ganz ohne Spielraum für Toleranzen bei der Umdrehungsgeschwindigkeit.