letzter Beitrag von fook42 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...)
-
kleines Oster-Geschenk nach einer langen Revision-Nacht: Software 1.3.8
-> https://github.com/fook42/1541-rebuild/releases/tag/SW1.3.8
habe 2 versionen hochgeladen : eine "standard"-version und eine extra für 20x4 LCDs (ungetestet)
[x] Wonderland14 (D64-images mit 40Tracks) läuft
-
little Easter present after a long night of revision: Software 1.3.8
-> https://github.com/fook42/1541-rebuild/releases/tag/SW1.3.8
I uploaded 2 versions: a "standard" version and an extra one for 20x4 LCDs (untested)
[x] Wonderland14 (D64 images with 40 tracks) is running
I have 1.4.0 board and 20x4. I need to recompile?
-
little Easter present after a long night of revision: Software 1.3.8
-> https://github.com/fook42/1541-rebuild/releases/tag/SW1.3.8
I uploaded 2 versions: a "standard" version and an extra one for 20x4 LCDs (untested)
[x] Wonderland14 (D64 images with 40 tracks) is running
I have 1.4.0 board and 20x4. I need to recompile?
Short answer, yes, but I can't see how to modify the code. You would have to merge the 1.3.8 changes back to the old 1.4.0 board code.
I think most of us have the 1.4.0 board or older (mine is actually 1.3.5 with wire mods to get it to 1.4.0)
-
most of us have the 1.4.0 board
actually you are right.. it needs some manual work to merge my changes back to the official repository from Thorsten Kattanek ...
we tried this for the "write"-routines, but it was not really good for long-term maintenance ...
better approach; find all hardware-changes between PCB 1.4.0 and PCB 1.4.2 .. and adopt the PORT-assignments
some things will not work though: I2C-Displays can not be used on 1.4.0 and maybe some small changes for input/output ports are necessary...
let me see... (may take some time)
main problem for me: i can not contribute directly to Thorstens repository and can not make commits there.. so i would have to take care of backporting for PCB 1.4.0 within my 1.4.2 fork (which kind-of breaks the whole relation chain)