search

ThKattanek / emu64

C64 Emulator
https://www.thorsten-kattanek.de/index.php/projekte/emu64
GNU General Public License v2.0
37 stars 5 forks source link

Probleme beim laden von D64 und CRT #171

Closed ThKattanek closed 3 years ago

ThKattanek commented 4 years ago

http://www.emu64-projekt.de/forum/index.php?page=Thread&postID=7333#post7333

Dieser Pfad funktioniert unter Windows7/10 nicht. Emu64 kann von dieses Image nicht laden.

U:\C64er\C64´er Programme und Spiele - Stand 2015-07-08\---D64---\--- Jump and Run\Great Giana Sisters\TEST.d64

ThKattanek commented 4 years ago

Unter Linux stellt dieser Pfad kein Problem dar. Also muss ich direkt unter Windows testen.

ThKattanek commented 4 years ago

Dateinamen vom Typ QString werden ab jetzt mit toLocal8Bit anstatt mit toUtf8 zu char* convertiert. Unter Window7 läuft das jetzt. Bevor das hier geschlossen wird muss das noch unter Linux und mit der Crossbuild Version getestet werden.

ThKattanek commented 4 years ago

Erledigt! Funktioniert jetzt so.

Zirias commented 4 years ago

Uhm, bin gerade in den Release notes auf dieses Issue gestoßen .. Also falls der Dateiname als char * mit APIs wie fopen() genutzt wird ist das hier nur halb gefixt:

.toLocal8Bit() ist auf *nix systemen, bei denen Unicode normalerweise als UTF-8 benutzt wird, genau richtig. Auf Windows ist local 8bit aber z.b. CP-1251 (jedenfalls immer ein Zeichensatz mit nur 256 Zeichen) -- Unicode wird hier mit "wide characters" und UTF-16 genutzt, das heißt leider auch, dass man zum öffnen einer Datei _wfopen() nutzen muss als Ersatz für fopen(), wenn Dateinamen mit beliebigen Zeichen funktionieren sollen.

Vielleicht hilft mein qfopen() macro von hier als Beispiel: https://github.com/excess-c64/v1541commander/blob/master/src/bin/v1541commander/utils.h

ThKattanek commented 4 years ago

Danke Felix für den Hinweis. Werde das Issue nochmal öffnen und mir das gleich mal ins Projekt schieben für die 5.0.19. Man lernt nie aus ;)

Zirias commented 4 years ago

Hab es gerade getestet und ein Image mal └┘┌┐ EXCESS ┌┐└┘.d64 benannt (nach dem tatsächlichen Disknamen, PETSCII nach Unicode konvertiert). Das kann der Windows Build der 5.0.18 nicht öffnen. Also für einen Testcase wäre gesorgt :)

ThKattanek commented 4 years ago

Ja mit dem Filenamen kann man experimentieren. Habe mir das mal angesehen, muss jetzt nur einen Weg finden wie ich das ganze umsetze. Die C64Class soll eigentl. ohne Qt laufen können, so war der Plan. Damit verwende ich in der C64Class keine QStrings. Muss ich jetzt mal sehen wie ich das anstelle bei den vielen Methoden die einen Filenamen übergeben bekommen. :D

Zirias commented 4 years ago

Ohne in den Code zu schauen hätte ich diesen Vorschlag:

Ich habe übrigens mein API so gestaltet, dass ich, wo immer das möglich ist, keine Dateinamen sondern einfach ein FILE * übergebe -- hat gewisse Vorteile (Codierung ist kein Thema mehr, man könnte auch z.B. einen Netzwerkstream statt einem lokalen File übergeben, ...). Es gibt eine Stelle, wo ich um Dateinamen nicht herumkomme, da habe ich es so gemacht wie oben beschrieben. Überall sonst macht bereits die GUI Schicht das fopen() (bzw _wfopen()) und nur das FILE * wird übergeben.

ThKattanek commented 4 years ago

Das mit dem FILE* übergeben hört sich sehr gut an (bin ich nicht selber drauf gekommen ;)) und würde besser zu implementieren sein, so dass ich in der GUI vernünftig konvertieren kann. Das steht die Tage jetzt auf dem Plan, um das auch mal gerade zu ziehen ;)

Zirias commented 4 years ago

Ja, wenn ich was helfen kann sag Bescheid :) Ich habe eben genau dieses Problem auch schon lösen müssen. Ohne die "Windows-Sonderlocke" wäre das viel einfacher ... FILE * gibt eine gewisse Abstraktion und Flexibilität, so ist es ja auch gedacht. Alternativ, falls du auf allen Schichten sowieso mit Qt arbeitest, könnte sich auch QIODevice anbieten.

ThKattanek commented 3 years ago

Habe heute angefangen umzustellen von der Übergabe eines "Filename" an die C64 Klasse auf die Übergabe des FILE Objekts. Habe deine "qfopen" Lösung 1:1 übernommen (utils.h) und funktioniert schon mal super in der cartridge_class. Getestet habe ich das mit dem "└┘┌┐ EXCESS ┌┐└┘" Dateinamen. Wird jetzt als *.crt in Linux und Windows geladen. Werde jetzt den ganzen Rest umstellen.

Zirias commented 3 years ago

Cool!

Dieser include-guard sollte wahrscheinlich noch raus ;) https://github.com/ThKattanek/emu64/commit/c23f2121836295a68187787da4f85e9dcd0d2d37#diff-9022459f0ccbb7cf6daac6ecb5af4f37d240219981a8c23076c14c5f002f9c8cR6

ThKattanek commented 3 years ago

Recht hast du! Das kommt bei Copy and Paste raus ;)

ThKattanek commented 3 years ago

Ich habe erst einmal alles umgestellt wo irgendwie C64 Daten geladen werden. Also sollte es jetzt keine Probleme geben mit Filenamen bei PRG, C64, T64, P00, D64, G64, TAP, WAV, CRT. Damit sollte dieses Problem behoben sein. Emu64 spezifische Dateien lasse ich erst einmal so wie es ist. Evtl stelle ich das später noch um aber der Aufwand ist ziemlich hoch und ich glaube damit gibt es eigtl. auch keine Probleme. Werde dazu ein Issue anlegen und es abarbeiteten wenn ich mal sehr viel Zeit ist. Momentan sind andere Sachen wichtiger denke ich.