Hab es irgendwie hinbekommen.
Es muss erst ein BootROM geladen werden, dann ein Kickstart von Diskette. Alles klar.
Kleine Frage so am Rande. Wann baust du in die Amiga-Emulation die Unterstützung für Harddisk-Files ein?
Bin da irgendwie ganz wild drauf. Der WInUAE kann das zwar auch, aber der ist etwas unübersichtlich, ich habe mich jetzt so richtig auf Denise eingestellt
und würde dort gerne eine Workbench-Umgebung erstellen.
Kleine Frage so am Rande. Wann baust du in die Amiga-Emulation die Unterstützung für Harddisk-Files ein?
im Oktober kommt die 2.4.
grober Zeitstrahl:
- C64 1581
- ...
- Amiga ECS Denise (A500+ / A600)
- Amiga HD
- ...
- Amiga 68020 CPU als Turbo Karte (noch kein A1200/AGA an der Stelle)
"noch kein A1200/AGA" an der Stelle bedeutet, Endziel in Denise wird der 1200er mal sein, bzw. AGA-Fähigkeit?
Das wären großartige News 
Riesen Respekt vor Deinen Coding-Skills und Deiner unglaublich breitgefächerten Ahnung in so vielen Kategorien.
Wahnsinn!
Endziel in Denise wird der 1200er mal sein, bzw. AGA-Fähigkeit?
ich hoffe doch.
Vorhin fiel mir auf, dass die FPS-Anzeige im Vollbild irgendwie verschwunden ist. Hab dann erst gedacht, dass der Emu sich die Einstellung des Bildschirmstatus vielleicht einfach nur nicht gemerkt hat, die ich bislang immer auf "intelligent" hatte, aber dieses Bildschirmstatus Menue finde ich nirgends mehr. Wohin zog das nun um? 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. Ist das ein Bug, oder soll das nun so sein? Hoffe mal Ersteres.
"noch kein A1200/AGA" an der Stelle bedeutet, Endziel in Denise wird der 1200er mal sein, bzw. AGA-Fähigkeit?
Das wären großartige News
Riesen Respekt vor Deinen Coding-Skills und Deiner unglaublich breitgefächerten Ahnung in so vielen Kategorien.
Wahnsinn!
Ja echt Respekt 
PiCiJi. Nehme an du hast auch beruflich mit Programmierung zu tun?
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.
Nehme an du hast auch beruflich mit Programmierung zu tun?
ich hab keine Wahl ... ich kann nix anderes 
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.
Nehme an du hast auch beruflich mit Programmierung zu tun?
ich hab keine Wahl ... ich kann nix anderes
Lol jo wenn ich mal ein Prozent von dir könnte an Programmierung dann wäre ich schon sehr froh. 
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.
Also WinUAE ist mir einfach zu kompliziert zu konfigurieren.
Diese blöden Config-Dateien nerven richtig.
es gibt nun auch eine .deb Datei für Linux Debian Distros (Mint, Ubuntu)
für alle anderen muss selber gebaut werden.
Saucool 
Danke!
Funktioniert einwandfrei unter Cinnamon Mint 21.3.
für alle anderen muss selber gebaut werden.
Hallo PiCiJi
ich hatte neulich schon mal versucht, Denise unter Fedora 40 mit KDE zu installieren.
Leider bin ich nach deiner Anleitung auf SourceForge kläglich gescheitert, weil CMAKE nicht so wollte (No CMAKE_CXX_COMPILER could be found).
Nach ein paar Versuchen habe ich aufgegeben, aber ich habe mich heute nochmal damit beschäftigt und es schließlich doch noch hinbekommen!
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.
Freu mich ungemein, dass Denis nun bei mir läuft.
Auf diesem Wege möchte ich mich dann auch gleich mal für deine super Arbeit bedanken. 
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.
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.
G81 enthält MFM kodierte Tracks und entspricht dem Aufbau eines G64
Musste es unbedingt ein neues Format sein? Gibts nicht bei Emulationen für andere Systeme schon MFM-Imageformate mit passendem Detailgrad?
Das ist die Stelle, wo Gideon bei der 1541 Ultimate II+, die ja auch 1571 Emulation kann, auch gestoßen ist: Man erhält ziemlich schnell Mischformate, wenn man das System benutzt. Einfachstes Beispiel: Man formatiert die Diskette erst per passender Software im MFM Format wie beim PC üblich.
Und dann überformatiert man die im normalen 1571 Format. Effekt: Tracks 36 bis 40 beinhalten MFM, der Rest GCR.
Hat man also G64 / G71 deswegen mit MFM Support, warum sollte man dann für die 1581 ein anderes Format wählen?
Allerdings stellt sich mir die Frage, wie die MFM Einbettung aktuell gemacht ist... da waren ja verschiedene Vorschläge zu unterwegs...
Edit: Schade, noch eine andere Variante, das zu kodieren. Mein Programmcode kann davon nichts einlesen... Jeder macht MFM anders. 
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. Z64K hat da nämlich eine MFM Erweiterung für. Und eine andere MFM Erweiterung gibt es für die Ultimate. Und dann gibt es noch das Proposal, welches der Z64K Autor benutzen wollte, um beliebige Längen zuzulassen und nicht nur ganze Bytes... Das ist ja ein Krüsimüsi...
Ich bin gerade zu blöd, das auszuprobieren... Wie erstelle ich ein neues leeres Diskettenimage? Ich fidne das nicht. Könnte gerade zum Test G81 und P81 brauchen.
Edit: Ich sag ja, ich stelle mich zu blöd an, da ist es ja:
Mit meinem nicht veröffentlichten Tool liefert
Get-FloppyDiskImage -Flux -Filename test.p81 | Convert-FloppyDiskImage -FluxToBitsteam -SpeedDetector ( New-FloppyDiskImageConfiguration -SpeedDetector -SpeedZone 8 ) | Read-FloppyDiskImageTrack -TracknumberingStyle ZeroBased -Track 39 -side 0 | Format-Table
Bei einer echten 1581 Diskette im GreaseWeazle / Kryoflux oder ein anderes auf Fluxebene lesenden Gerät siejht man aber, dass auf der ersten Seite die "side" im Header 1 sein sollte und auf der zweiten Seite die "side" im Header 0. Und die Daten entsprechend, ich habe extra mal die Stelle mit der BAM im Beispielbefehl angeschaut. Die liegt im Flux auf der Rückseite auf RAW-Track 39 Sektor 0. Da die RAW Tracks ab 0 zählen, ist das dann Track 40.
Wieder eine Fallunterscheidung mehr für ein generelles Tool. P81 hat offenbar die Seiten vertauscht gegenüber P71.
Edit: Habe mein Tool gerade mal angepasst, dass es bei P81 diese seltsame Seitenvertauschung durchführt. Also genauer, wenn die angegebene Floppy 1581 ist.
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.
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.
