Posts by PiCiJi

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.

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.

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

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 Unseen

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.

Quote from markusC64

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

Quote from markusC64

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.

Quote from markusC64

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.

Quote from Kickmaster64

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.

Quote from Barbaros

Wo kann man sehen was genau in den nächsten Versionen verändert werden?

nirgendwo.

Kickmaster64

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.

Quote from Barbaros

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.

Quote from Barbaros

Über welche Hotkey Taste genau kann man schnell die Diskette einwechseln?

Steuerung -> C64 konfiguration -> globale hotkeys

dort in der Liste stehen Einträge wie Disk wechseln 0, 1, usw.

wenn du auf diesen Einträgen einen Doppelklick machst, kommt die Aufforderung den Hotkey festzulegen: z.B. Maus Doppelklick und dann Alt + 0.

Nun ist der Hotkey über Alt+0 auslösbar.

Quote from jenpie

Hier sind die Punkte, die ich abweichend von deiner Anleitung auf SourceForge verwendet habe.
Vielleicht sind diese Informationen auch für andere Fedora-Anwender noch interessant.

finde ich gut, dass es läuft.

Die Anleitung zum selber bauen setzt Grundkenntnisse auf der Linux Konsole voraus.

z.b. das fehlende sudo vor den zu installierenden libs.

Das packe ich mal überall davor.

Ein Compiler war, glaube ich, nach meiner Fedora Installation vorhanden. Ich würde aber den gcc nehmen. clang ist auf mac der standard.

Ich versuche das nächste mal noch ein RPM Paket zu bauen.

Problem ist nur die CI Dienstleister setzen alle auf Debian VM's und klar kann ich dort auch ein RPM bauen. Jedoch befürchte ich, dass die abhängigen libs nicht passen, wenn man das package auf einem echten RPM verwendet.

Quote from Barbaros

Hallo. Ich bin neu hier. Wollte eine wichtige Frage zum Denise Emulator stellen. Kann man den Emulator so Einstellen das er von selbst auf die zweite und dritte Diskette zugreift wenn diese verlangt werden (bezogen auf die Amiga Spiele aber auch C64 Spiele? Bei einigen Spielen ist es nervig wenn man drei bis viermal Disketten wechseln muss um ein Spiel zu spielen. Bitte um Hilfe. Vielen Dank.

voll automatisch geht das nicht.

Mit dem Disk Wechsler im Software Menu lassen sich sämtliche Disketten eines Spieles (vor)einlegen.

Über Hotkeys können diese dann schnell eingewechselt werden.

es gibt nun auch eine .deb Datei für Linux Debian Distros (Mint, Ubuntu)

für alle anderen muss selber gebaut werden.

Quote from Kickmaster64

Ich dachte, da der SID im Hoxs eine Eigentwicklung ist, eine ausgezeichnete Alternative zur reSID sein könnte, wenn da mal wieder etwas nicht so klingt wie es soll.

Der digitale Teil des SID (Klangerzeugung und Lautstärkeumschlag) hat sich nicht nennenswert verändert in den letzten Jahren. Ich kann mir auch nicht vorstellen, das hier reSID und Hoxs auseinandergehen.

Bei Gelegenheit kann ich mal die verwendeten wave tables zwischen reSID und Hoxs SID vergleichen.

Ich schätze der gefühlte Unterschied kommt aus dem analogen Filter.

Analoge Bauteile zu emulieren, ist kein Vergnügen. Man muss den Stromfluss in den Schaltkreisen, bestehend aus Widerstände, Kondensatoren, Operationsverstärker usw. mit Formeln berechnen.

Diese spiegeln nicht die komplette Dynamik echter Bauteile wieder.

Der Amiga hat zum Glück nur einen sehr simplen externen low pass filter, welcher von moderner Software sowieso meistens deaktiviert wird.

Mr Nutz z.B. verwendet den Filter um das Unterwasser Level dumpfer klingen zu lassen.

Quote from Kickmaster64

Der reSID 2.4-Filter scheint in der neuesten Nightly-Version ohnehin nicht mehr vorhanden zu sein.

ist im neuen nightly wieder drin.

Ich habe meine Meinung geändert bekommen.

Quote from He-Man1982

Der Amiga hat aber doch auch Module, etwa das Action Replay. Insofern würde diese Menubezeichnung passen, wenn es dann solche Module auswerfen würde.

fast vergessen, ja das nehme ich temporär für den Amiga raus.

Quote from Kickmaster64

Also auch der komplette Unterbau? (wellenformen, adsr.. usw)

Dachte Chamerlain ist nur der Filter alleine.

ja nur der Filter.

Der Unterbau des SID ist im Gegensatz zum Filter weitestgehend digital.

Ich kann mir nicht vorstellen, dass es da große Abweichungen gibt.

Hast du denn ein Tune, welcher mit deaktiviertem Filter klanglich zwischen HOXS und Denise oder VICE hörbar abweicht ?

Quote from AW182

Hab herausgefunden, dass sich die FPS Anzeige zwar per Hotkey zuschalten lässt, jedoch ist sie beim nächsten Starten des Emus, dann jedesmal wieder abgeschaltet und muss immer wieder erneut zugeschaltet werden.

ja das wird aktuell nicht gespeichert.

Quote from ir6Oixah

Nehme an du hast auch beruflich mit Programmierung zu tun?

ich hab keine Wahl ... ich kann nix anderes

Quote from Kickmaster64

Würde es eigentlich Sinn machen *optional* die 8580 SID-Emulation von Hoxs64 einzubauen?

Der ist bereits in Denise enthalten. Hoxs verwendet den Chamberlain.