Wenn diese Obertöne in Denise nicht doch etwas anderes sind, dann sollten die mit neuesten reSID Update weg sein.
Ich habe den reSID code geupdated, kannst ja mal schauen ob es was gebracht hat.
Posts by PiCiJi
-
-
Ab und zu wäre es für mich praktisch bei der Nutzung von Denise, dass die Warp Speed nicht "unlimited" wäre, sondern dass ich das limitieren könnte.
mittels Rechtsklick -> Geschwindigkeit kann eine feste Geschwindigkeit verwendet werden. Eine zusätzliche "Geschwindigkeit anpassen" kann frei gesetzt werden (ebenso über dieses menu erreichbar)
-
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.
ok konnte ich nachstellen, ist gefixt im neuen nightly.
prüft nun auf "P64-1541", "P64-1571", "P71-1571".
Und beim Erstellen wird für P71 "P64-1541" verwendet. Nur die 2. Seite macht die Unterscheidung. Jetzt kann das Image in VICE verwendet werden.
Die Endung ist an dieser Stelle ein Hinweis für den Benutzer, nicht für den Emulator.
ja.
Ernstgemeinte Frage, unabhängig davon, ob man sozusagen die 100% Emulationsgenuigkeit erreichen möchte.... aber:
Wie relevant ist das alles denn bei einem Emu?
Du hast das schon richtig erkannt. Das interessiert nur sehr wenige Menschen.
Hier geht es nur um ein Gefühl der Vollständigkeit und Korrektheit. Läge der Aufwand für den Einbau von P71/P81 über einen Monat hätte ich es gelassen.
-
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?
-
-
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.
-
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.
-
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.
-
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.
-
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
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.
-
nightly
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.
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.
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.
-
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.
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.
-
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.
-
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.
-
Musste es unbedingt ein neues Format sein? Gibts nicht bei Emulationen für andere Systeme schon MFM-Imageformate mit passendem Detailgrad?
Der Amiga hat die extended ADF für MFM Kodierung. Atari und MSDOS haben sicherlich auch nicht nur dekodierte Formate in der Emulation.
Die Formate sind ja häufig nach dem System benannt, wofür diese gelten. Die Endung ADF möchte ich in der C64 Emulation nicht sehen.
Hat man also G64 / G71 deswegen mit MFM Support, warum sollte man dann für die 1581 ein anderes Format wählen?
- um den Nutzer nicht zu verwirren. Die erwarten keine G71 für die 1581
- 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.
Ich denke, da die GCR Abhängigkeit weg fällt, ist hier ein neues Format angemessen ohne die Notwendigkeit von Tricks
Edit 2: So ganz raus habe ich das G81 Format noch nicht, aber es ist schon signifikant anders als G64 und G71 mit MFM Erweiterung.
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.
Wieder eine Fallunterscheidung mehr für ein generelles Tool.
P81 hat offenbar die Seiten vertauscht gegenüber P71.aus folgendem Grund.
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.
D81: 40 Sekoren auf 80 (nicht 160) Tracks (20 256 byte Sektoren pro Track/Seite), physisch: 10 512 byte Sektoren pro Track/Seite
Track/Seite Zuordnung liegt wie beim Amiga ebenso. (cylinder << 1) | side
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.
-
nightly: 1581 support
- emulation 1581 (D81, G81 (*), P81)
- Disk Vorschau für diese Formate
- neu erstellte images sind 80 Tracks je 2 Seiten und können während der emulation auf 84 tracks erweitert werden
- Mavericks Dual Drive Copy für MFM funktioniert (**)
- eingelegtes image bestimmt nun welches Laufwerk emuliert wird.
(Das geht ohne Neustart der Emulation und Mavericks z.B. erkennt das on the fly und zeigt das neue Laufwerk an.)
- dennoch bleibt Auswahl Menu für Laufwerk, um 1541, 1541C, 1570 zu nutzen
- StarDos und SuperCard+ Erweiterungen hinzugefügt
- P64/P71/P81 unterstützen nun eine veränderte Laufwerksgeschwindigkeit (***), Wobble und Motor Be/Entschleunigung
(*) G81 enthält MFM kodierte Tracks und entspricht dem Aufbau eines G64
(**) lässt sich zum Beispiel testen, indem D81 -> G81/P81 kopiert wird und dann eine 2. dual drive copy von G81/P81 -> D81. Da ein D81 die dekodierten Sektor Daten in der richtigen Reihenfolge vorhalten muss, lassen sich nun die beiden D81 auf Unterschiede prüfen um zu testen ob Dual Drive copy keine Bit Fehler produziert hat.
(***) z.B. mittels SuperCard+ (oder Mavericks + ramboard) kann man nun das ein oder andere kopiergeschützte image mit abweichender Bitzellen Weite in Emulation kopieren, also G64 -> P64.
Ich konnte Defender of the Crown Disk 1 (V-Max) mit einer Laufwerksgeschwindigkeit von 301.2 (ohne wobble) lauffähig auf ein P64 schreiben.
Bei Operation Wolf (V-Max) verwendete ich erstmal 297.5 RPM und dann beim Testen blieb es bei einigen Tracks stehen.
Diese habe ich dann einzeln mit abweichender Geschwindigkeit neu kopiert, bis das image lief.
-
Wenn diese Obertöne in Denise nicht doch etwas anderes sind, dann sollten die mit neuesten reSID Update weg sein.
ok ich schaue noch vor der nächsten Version die resid updates in VICE durch. Ich melde mich dann, wenn es was zum testen gibt.
-
Wo kann man sehen was genau in den nächsten Versionen verändert werden?
nirgendwo.
-
Was genau solllte damit verschwinden? und das weißt du nur vom Lesen des changelogs?
Ein paar mehr infos wären schon hilfreich.
Für die library scheint die gleiche Person verantwortlich zu sein, wie für die resid integration in VICE. Ich schätze, wenn dir die schon nicht zusagt, wird es mit der library nicht besser.
-
Seit kurzem ist die 2.4 Version vom Denise Emulator raus aber sehe da keine grosse Veränderung. Eigentlich ist alles gleich geblieben.
Ich warte so sehr auf einee WHDload unterstützung des Emulators. Wann das wohl kommen wird. Ob das überhaupt irgenwann kommt.
Das wäre echt toll. Dieser Emulator ist sehr viel besser als WinUAE.
in der 2.6 ist ECS Denise (A600) und Amiga HD an der Reihe. Die 2.5 geht an den C64.
