Schonmal Danke!
Teste es gelegentlich!
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
letzter Beitrag von kazmat am
Schonmal Danke!
Teste es gelegentlich!
In Windows 7 braucht man jetzt auch nicht mehr den XP Kompatilbilitätsmodus für die Umwandlung der m2i Ordner zu aktivieren.
Wer nicht für Windows kompilieren will, kann diese testen.
disk2easyflash.7z
Kompiliert wurde mit mingw unter WindowsXP 32bit.
Danke auf jeden Fall für die Sources. Ist mir schleierhaft, warum manche in der C64 Szene so geizig damit umgehen und dann unzählige Win-Only Binaries auf der csdb rumfliegen, bei denen der Programmierer nach Version 0.001b (gefühlt) eh keine Lust mehr hatte weiter zu machen...
You're welcome.
Aber von mir gibts nie ein win-binary, da ich diese plattforn weder besitze noch unterstuetze. (hoechstens packe ich das mit ein)
Ich hatte mal abgefangen auch eine emulation der OPEN funktion zu machen - is aber recht komplex, darum habe ich es bei LOAD gelassen - und das scheint ja auch gar nicht so schlecht zu laufen.
hinweis: dateien die nicht eingepackt werden oder ueber andere wege als LOAD (z.B. OPEN,SAVE) zugegriffen wird, wird immer auf laufwerk 8 zurueckgegriffen -> wenn man die savegame datei nicht mit einpackt, wird die von lw 8 genutzt.
ok, fehler gefunden. im image waren 1block große dateien. daran hat sich das gestört. aber bleibt eine frage" wie groß müßen denn im algemeinen die dateien sein?"
ok, fehler gefunden. im image waren 1block große dateien. daran hat sich das gestört. aber bleibt eine frage" wie groß müßen denn im algemeinen die dateien sein?"
Ich weiß es zwar nicht, spiele aber mal Detektiv 00 Schneider *kombiniere, kombiniere*
Zitatbelow minimum file length of 3
könnte auf 3 Blocks hindeuten...
Ich würde sogar eher 3 Bytes vermuten. Wobei ich mich frage warum 3 und nicht 2. Der komische Dateiname deutet auch auf eine "Trennstrich-Dummy-Datei" hin...
Ich würde sogar eher 3 Bytes vermuten. Wobei ich mich frage warum 3 und nicht 2. Der komische Dateiname deutet auch auf eine "Trennstrich-Dummy-Datei" hin...
Hab mal im VICE getestet direkt nach dem Einschalten SAVE"TEST",8 einzugeben und bin jetzt eher überrascht, dass es nicht 4 Bytes sind, denn heraus kommt folgendes 4 Byte PRG:
Aber ich schätze mal, dass mindestens 3 Byte nötig sind, um ein "echtes" PRG file zu bekommen. 2 Byte Ladeadresse + 1 Byte Opcode.
Jetzt müssen wir diese wichtige Frage aber auch noch ausdiskutieren: Richtig, 3 Byte könnten schon eine sinnvolle Zahl sein: Die kleiste PRG-Datei, die ein Byte im Speicher ablegen kann. Aber: Nicht jede PRG-Datei muss man mit LOAD laden. Man könnte auch nur genau ein Byte drin haben (z.B. Highscore )
3byte sind wieviel blocks?
3*254, also 762
also muß die datei größer sein, wie eine diskette?
Man könnte auch nur genau ein Byte drin haben (z.B. Highscore )
Vorausgesetzt der "Highscore" kann nur 256 Werte unterscheiden.
Es würde auch eine Datei mit 0 Byte Länge gehen. Das irritierende dabei wäre, dass eine Null-byte Datei eine Ein-bit Information enthält. Datei vorhanden, Datei nicht vorhanden. Ein Block wird aber in jedem Fall verschwendet. Plus ein Directory Eintrag ...
also muß die datei größer sein, wie eine diskette?
Das ist egal. Hauptsache, die Datei ist rund. Sonst passt sie nicht auf eine Disk.
Vorausgesetzt der "Highscore" kann nur 256 Werte unterscheiden.
Sagen wir mal so: Wenn ich das Spiel spiele, werden es sowieso nicht mehr als 255 Punkte
Vorausgesetzt der "Highscore" kann nur 256 Werte unterscheiden.
Für Desert Bus sollte das doch locker ausreichen.
Also der grund warum disk2ef nur dateien ab 3 bytes "erlaubt" ist dass a) nur load emuliert wird, also die ersten beiden bytes immer als load-addresse genutzt werden und b) ich dachte dass alles unter 1 byte nutz-daten keine eigene datei wert ist. (der source ist offen, kann also auf 2 bytes reduziert werden)
extra: highscore dateien sollte man ausschliessen, da alle nicht erkannten dateien vom "echten" laufwerk geladen werden (und da save nicht "uebernommen" wird wird also so wie so alles per save auf disk gespeichert - und OPEN+read/write ist ja auch nicht unterstuetzt = auch echtes laufwerk)
disk2easyflash - Programmfehler gefunden.
Jetzt ist klar, was los ist.
disk2easyflash/disk2easyflash --crt m2i tt64.crt
klappt nicht.
cd m2i && ../disk2easyflash/disk2easyflash --crt tt64.m2i ../tt64.crt && cd ..
klappt.
Nach den Dateien wird im falschen Verzeichnis gresucht, wenn man ein Verzeichnis angibt.
Ich wollte grad mal ein wenig mit dem Disk2easyflash 0.9.1 rumspielen, bekomm das ganze aber gar nicht erst geöffnet ( Win10 ). Hat da jemand einen tipp für mich ?