letzter Beitrag von r.cade am
Laufwerk der 1541 emulieren
- amithlon
- Erledigt
-
-
Hmmm...... das ergibt alles Sinn (iHex Format usw...)
aaaaber:
Letzter Release von Fook42 auf Github hat 3 Assets:
Das Hex File
Sourcecode als Zip
Sourcecode als tar.gz
Das Hex file in dem Relase ist 100.932 Bytes groß
in dem Source Zip ist ein Makefile von WinAVR
Wenn ich dieses unter SH.exe von WinAVR mit "make all" erstelle kriege ich ein Hex file das 124.116 Bytes groß ist.
Dieses Hex file unterscheidet sich auch von dem Release Hex...
Wenn ich den Source Code compile müßte doch exact dasselbe File in der selben Größe dabei rauskommen, oder???
Ich hab mal beide angehängt... "fook42 1.3.7.hex" ist der Release, "cowboyjunkie 1.3.7.hex" ist das von mir compilierte.
Gruß,
John
-
Die Files sind ja auch KOMPLETT unterschiedlich. Da wird irgendeine Option halt noch zusätzlich an oder aus sein, oder vielleicht mit/ohne Bootloader? Keine Ahnung.
-
kinzi Genau das versteh ich ja nicht Die Optionen sind ja eigentlich alle in dem Makefile drin. Und das hab ich nicht verändert.
Dasselbe passiert aber auch, wenn ich den Source-Code vom "original" 1541-rebuild nehme.
und irgendwie trau ich mich nicht mein eigenes File auf den Atmega1284p zu flashen... (ich hab nur den einen
Gruß,
John
-
kinzi Genau das versteh ich ja nicht Die Optionen sind ja eigentlich alle in dem Makefile drin. Und das hab ich nicht verändert.
Dasselbe passiert aber auch, wenn ich den Source-Code vom "original" 1541-rebuild nehme.
Dazu kann ich nichts sagen - IANAP.
Anderes HEX-File-Format gewählt? Gibt unterschiedliche.
und irgendwie trau ich mich nicht mein eigenes File auf den Atmega1284p zu flashen... (ich hab nur den einen
Den kannst du doch immer wieder flashen, wo ist das Problem?
-
Wenn ich den Source Code compile müßte doch exact dasselbe File in der selben Größe dabei rauskommen, oder???
Nur wenn du den exakt gleichen Compiler mit den exakt gleichen Optionen und den exakt gleichen Libraries verwendest.
(und bei Mikrocontrollern meist weniger relevant: Wenn das zu compilierende Programm keine Details des Bausystems einbaut wie zB das Datum der Compilation oder den Pfad des Verzeichnisses, in dem es gebaut wurde - nennt sich "Reproducable Build")
-
P.S.: hast Du von der 1.3.8 ggf auch Sourcen? Ich bräuchte die lcd.h wieder für ein Display 20x4
du findest den aktuellen Software-Stand hier:
https://github.com/fook42/1541-rebuild
das oben angehängte 1.3.8beta ist genau dieser Stand (beta deshalb, weil ich eben keinen Release gemacht habe - dafür fehlt eine wirklich verlässliche Schreibroutine, die jetzige geht, aber nicht immer).
ich compiliere übrigens unter Windows mit dem avr-gcc .. evtl. macht der etwas anderes als der WinAvr ? ...
-
ich compiliere übrigens unter Windows mit dem avr-gcc ..
sorry; unter "Linux" (irgendein Ubuntu 22.04.) sollte da stehen!!!
-
Wenn ich den Source Code compile müßte doch exact dasselbe File in der selben Größe dabei rauskommen, oder???
Nur wenn du den exakt gleichen Compiler mit den exakt gleichen Optionen und den exakt gleichen Libraries verwendest.
(und bei Mikrocontrollern meist weniger relevant: Wenn das zu compilierende Programm keine Details des Bausystems einbaut wie zB das Datum der Compilation oder den Pfad des Verzeichnisses, in dem es gebaut wurde - nennt sich "Reproducable Build")
Ahhh.... OK, dann werd ich das mal auf einem Raspberry Pi Probieren...
-
warum nimmst du unter Windows <10 nicht eine Virtual-Box oder VMware mit Linux als "Gast"?
ab Win10 hast du doch das Linux schon dabei (WSL) ... da kannste dann auch den avr-gcc nehmen .. der sollte dann das gleiche liefern wie meiner
im Anhang hier noch die 20x4 LCD version .. dann brauchste es nicht selbst zu übersetzen.
aber auch dabei gilt: ich habs nicht getestet (hab nichtmal ein 20x4 Display da)
-
warum nimmst du unter Windows <10 nicht eine Virtual-Box oder VMware mit Linux als "Gast"?
ab Win10 hast du doch das Linux schon dabei (WSL) ... da kannste dann auch den avr-gcc nehmen .. der sollte dann das gleiche liefern wie meiner
im Anhang hier noch die 20x4 LCD version .. dann brauchste es nicht selbst zu übersetzen.
aber auch dabei gilt: ich habs nicht getestet (hab nichtmal ein 20x4 Display da)
Wow!!! Danke für die Mühe! Werd ich morgen mal testen...
Was die 1.3.8Beta angeht:
Deutliche Verbesserung! Wonderland XIV kommt soweit wie noch nie!
1541-rebuild 1.3.7: Startet gar nicht
1541-rebuild 1.3.8B: hängt erst gegen Ende Disk1
Pi1541 1.25E: Hängt bereits nach wenigen Minuten
Witzigerweise NUR mit JiffyDOS. Vanilla 1541 & C64: Wonderland XIV startet nicht?!?!
Gruß,
John
-
Wonderland XIV startet nicht?!?!
Wonderland XIV war für mich auf realer Hardware auch tricky. Habe das aber inzwischen recht zuverlässig auf Vanilla C64 + Vanilla 1541-II laufen. Das ist doch recht fordernd...
-
hast du das ganze auch mal mit Disk-Images im G64 Format vom Wonderland probiert?
G64 spart bei der EMU die ganze konvertierung in den GCR Datenstrom und das Laden des Images geht damit auch ein bisschen flotter...
-
Does anyone have 1.3.8 beta firmware compiled for the 1.4.0 board? (I have 4 line LCD also...)