In der Zeile mit den clobbered regs fehlt ein % bei d2

-----------------------
NKC'ler seit 1984 (Pause zw. 1988-2017)
CPU68k,CPU68000,4xROA64,6xIOE,6xGDP,GDPHS,8xSBC2/3,HEXIO,6xKEY,UHR3,PROMER,CENT,SER,SOUND,CAS,6xBUS2,4xBUS3,3xPOW5V,2xTAST..und einen ArduinoMEGA mit auf dem BUS, und eine selbstgebastelte MEM960k und eine FPGA-GDP.

NKC - OpenSource since 1983

Danke für den Hinweis.
Ich seh schon da fehlt bei einigen GP und Jados Aufrufen ein Hinweis (bei uint8_t Parametern) für den Compiler diesen nur in Data-Registern zu plazieren weil move.b Axx,Dxx durch das 68k-Instructionset nicht unterstützt werden.
Dadurch kann es passieren dass der compiler einen solchen parameter in ein Address-Register legt und dann kommt der Fehler den Redo hatte.

So, das war mir wichtig - nicht dass ich da jemanden auf die falsche Fährte setze.

Nun zu dem Problem, wenn ich andi's test.c compiliere:


... multiple definition of `AYchannel'; obj/crt0.o:/opt/m68k-toolchain/m68k-elf/include/sys/soundchip.h:45: first defined here

Wie ich diese Mehrfachdefinition auflösen kann, ist mir nicht klar. Ich habe in der Soundchip.h nachgeschaut. Das ist ja überschaubar, aber eine Umbenennung der Funktion (oder Variable) bringt leider nix und ich vermute einfach auch mal, dass 'AYchannel' und 'AYregister' eben auch noch woanders referenziert sind ... in der Crt0.c hab ich nichts gefunden.

Der Fehler weiter unten: '-lnkc' kommt von der 'rm_ram1.ld'
da weiß ich auch noch nicht wie ich das hinbekommen kann.

Aber mal noch eine grundsätzlichere Frage: Habe ich das richtig gemacht, dass das Delta von andi einfach in den bestehenden Pfad (an den entsprechenden Stellen) hineinkopiert(!) wird? Muss da anschließend nix mehr neu compiled werden?

Schöne Grüße

-----------------------
68008/GDP64HS/BootRAM68k/KEYr4/IOEenh mit 2xSD-Karte/Sound3/UHR3/IOEenh mit Joystick/BUS3

... oh Mist ... ich funke Euch hier dazwischen ... soll ich das in einem extra Thread öffnen?

Schöne Grüße

-----------------------
68008/GDP64HS/BootRAM68k/KEYr4/IOEenh mit 2xSD-Karte/Sound3/UHR3/IOEenh mit Joystick/BUS3

Andi, die Änderung in der NKC.h habe ich durchgeführt, den nkc_common neu übersetzt und auch installiert. Es hat das Problem aber nicht gelöst.

Beim Test bin ich dann über diese Meldungen gestolpert:
C:\msys64\tmp\ccALymSO.s:4792: Error: operands mismatch -- statement `moveb %a6,%d0' ignored
C:\msys64\tmp\ccALymSO.s:4862: Error: operands mismatch -- statement `moveb %a6,%d0' ignored
C:\msys64\tmp\ccALymSO.s:4908: Error: operands mismatch -- statement `moveb %a6,%d0' ignored

Die entsprechenden Stellen habe ich in der NKC.h nicht gefunden.

Erfolg hatte ich aber mit:

Quote by smed: Compilier mal ohne -O5, also diese Compileroption weglassen oder -O4, -O3 oder -Os

Ich hatte in dem Makefile -Os und habe das auf -O3 geändert. Ich weiß noch nichts von den Schaltern, muss ich einräumen.

Damit konnte ich mein Programm erfolgreich kompilieren und erste Tests sind positiv verlaufen.



Mir fiel noch auf, dass die gp_writexy in der NKC.h ...

static inline __attribute__((always_inline)) void gp_writexy(uint16_t x, uint16_t y, uint8_t size, const char* const p_str) {


... x,y als uint16_t definiert (Pixel 512x256). In meinem Programm wird aber x,y als uint8_t (Zeilen 24,80) übergeben und umgerechnet. Kann das problematisch werden? Ein uint8_t passt doch in ein uint16_t, oder sehe ich das falsch?

Danke fürs helfen bis hierher....
VG Jürgen

-----------------------
Nach vielen Jahren ging es mit dem NKC wieder los.... Sehr spannend!

Hallo,

ich hab eine aktualisierte Version von nkc.h eingecheckt.
https://github.com/avg67/nkc/blob/main/SW/SysGCC-delta/m68k-elf/nkc_common/nkc/nkc.h
Dort hab ich auch alle anderen betroffenen Stellen in den anderen Funktionen gefixt. Ich denke bei dir ist es gp_writexy die betroffen ist wegen dem size parameter.
Ja den Datentyp solltest du auf uint16_t ändern ansonsten bekommst du Überläufe beim multiplizieren. In C ist das so definiert dass alle Rechenoperationen mit den aktuellen datentype (in deinem Fall uint8_t) durchgeführt wird und dann erst das Ergebnis auf den ziel-Datentyp umgewandelt wird (hier uint16_t). Das führt dann bei dir zu Überläufen.
Ein uint8_t ist ein 8-bit vorzeichenloser Integer (0..255)
Ein uint16_t ist ein 16-bit vorzeichenloser Integer (0..65535).
Als Anfänger solltest du eher zu große als zu kleine Datentypen verwenden. Zu große Datentypen führen lediglich zu einem langsameren Programm. Ein zu kleiner Datentyp führen zu Bugs (Fehlverhalten)

Hallo Andi,
erstmal Danke an Dich und retroniker für die wirklich schnelle Hilfe.
Ich aktualisiere morgen und stelle dann wieder auf -Os im Makefile um.
Ich berichte.
Herzlichen Dank
Jürgen

-----------------------
Nach vielen Jahren ging es mit dem NKC wieder los.... Sehr spannend!

Hallo Andi, ich habe die nkc.h geholt, installiert und im Makefile meiner Anwendung wieder -Os eingestellt. Das hat jetzt geklappt. Ich mach mal weiter, nochmals Danke.
VG Jürgen

-----------------------
Nach vielen Jahren ging es mit dem NKC wieder los.... Sehr spannend!

Hallo,
kann mir kurz jemand von Euch weiter helfen:

1. Die Angabe '-lnkc' in der 'rm_ram1.ld', was hat die zu bedeuten? Ich versuche den ausgegebenen Fehler zu verstehen.

2. Habe ich das richtig gemacht, dass das Delta von andi einfach in den bestehenden Pfad (an den entsprechenden Stellen) hineinkopiert(!) wird? Muss da anschließend nix mehr neu kompiliert, gemerged ... oder sonst was gemacht werden werden?

Schöne Grüße
Daniel

-----------------------
68008/GDP64HS/BootRAM68k/KEYr4/IOEenh mit 2xSD-Karte/Sound3/UHR3/IOEenh mit Joystick/BUS3

Hallo Daniel,

die Zeile "-lnkc" bedeutet dass er die NKC-Lib mit dazu linken soll (-l<name> ist die Anweisung eine bestimmte library lib<name>.a mit zu linken). Die Library wird (zumindest unter windows) erzeugt wenn du im nkc_common Verzeichnis "make; make install" aufrufst. Dabei wird diese erzeugt (libnkc.a) und ins richtige Verzeichnis kopiert (bei make install). Das musst du natürlich auch alles an unix anpassen.
Weiters brauchst du einen 68k-GCC mit newlib support, sonst geht stdio (printf, puts, scanf, ...) nicht. Du musst den vor dem compilieren entsprechend konfigurieren

Hallo andi,
allerbesten Dank vom "greenhorn"

Man kann den Compiler auch mit newlib support erstellen lassen - muss ich aber mal schauen, ob ich das gemacht habe.

Das er nach der NKC-Lib fragt ist mir klar, weil er ja vorneweg an der Mehrfachdefinition von AYchannel und AYregister strauchelt - also wird die gar nicht bereit gestellt ...

Dann heißt das aber, dass dein "Delta" nur in den bestehenden Pfad reinkopiert wird - ich muss also nicht noch einmal den compiler "neu bauen lassen" - stimmt das?

Vielen Dank für die Hilfe

-----------------------
68008/GDP64HS/BootRAM68k/KEYr4/IOEenh mit 2xSD-Karte/Sound3/UHR3/IOEenh mit Joystick/BUS3

newlib-support habe ich



Ich habe weitere Fehler entdeckt: Im Verzeichnis nkc_common ist ja noch eine Makefile ... auch dort wird auf .exe verwiesen.
Aber soweit bin ich ja noch gar nicht - die Mehrfachdefinitionen müssen noch raus ...

-----------------------
68008/GDP64HS/BootRAM68k/KEYr4/IOEenh mit 2xSD-Karte/Sound3/UHR3/IOEenh mit Joystick/BUS3

Wenn du einen GCC mit newlib support hast dann sollte es reichen einfach das delta da drauf zu kopieren. Wenn alles in den richtigen Verzeichnis landet sollte das passen.
Du musst dann noch die NKC-Lib compilieren und installieren. Danach sollte z.B. Jados_test ebenfalls kompilieren und laufen.
Übrigens um so neuer der GCC ist desto größer (und langsamer) werden die 68k files weil die GCC-Libraries immer größer und komplexer werden (wegen Features der neuen CPU's die für 68k völlig irrelevant sind).

Hallo zusammen,
für die, die sich fragen, ob der immer noch an seinem crosscompiler unter ubuntu rumschraubt - ja, ich hab die Lust nicht verloren. Zugegeben es ist etwas mühsam ... aber ich komme in kleinen Schritten voran.
Zwischenstand ist, dass ich die libnkc.a compilieren und installieren konnte. Das ist gut und hat auch ettliche Stunden gekostet. ABER beim comilieren des JADOS-Test bekomme ich immer noch Fehler bezüglich "multiple definition von AYchannel und AYregister" - in Verbindung mit der crt0.o und der test.o -> ich lade mal ein Bild hoch. Soweit ich das verstanden und recherchiert habe, wird das in der soundchip.h definiert. Nun wird über Umwege in die crt0.o und auch in die test.o die target.h eingebunden - was mich zu der Annahme veranlasst, dass das der Grund für den Fehler ist - aber wie löse ich das auf??
Ich hab' schon die libnkc.a mit auskommentierter target.h neu compiled (das ging ohne Fehler), führt aber dazu, dass ich bei der Compilierung der test.c zu test.o Probleme bekomme.
Kann mir jemand sagen, ob ich da wenigstens auf dem richtigen Weg bin - den Fehler richtig verstanden habe?
... und falls wir nix mehr von einander hören, wünsche ich Euch allen geruhsame Weihnachten ... Zwischen der Jahren geht's sicher weiter



Schöne Grüße

-----------------------
68008/GDP64HS/BootRAM68k/KEYr4/IOEenh mit 2xSD-Karte/Sound3/UHR3/IOEenh mit Joystick/BUS3

Ich werde heute Abend auch mal beginnen, diese Crosscompiler-Umgebung auf meiner im Sommer eingerichteten Linux-Kiste aufzusetzen.

Ich hatte vor zwei Jahren schon mal eine recht hakelig funktionierende Umgebung unter Windows. Aber das hier scheint mir nun deutlich runder...

-----------------------
Definitiv sind Frösche und Himbeeren am besten!

Hi tuti,
... oohhhh, also im Moment kann ich noch nicht sagen, dass mich das so arg glücklich macht.
Das Problem ist, dass die toolchain von ddraig zwar ganz ähnlich aufgebaut ist, wie bspw. unter cygwin mit andis Paket. (unter cygwin mit andis Paket konnte ich den JADOS-TEST schon compilieren), aber im Detail ist das dann halt doch bissl anders. Im Grunde habe ich hier 2 Welten zusammen geführt, die nicht gleich sind ... aber eben fast ... deshalb fuchst mich das so

Und ich bekomme diesen fiesen Fehler nicht raus ... und meine C-Kenntnisse sind schon sehr beschränkt ...
Aber ich freu' mich, wenn jemand mit deutlich mehr Ahnung mitdenk

Schöne Grüße

-----------------------
68008/GDP64HS/BootRAM68k/KEYr4/IOEenh mit 2xSD-Karte/Sound3/UHR3/IOEenh mit Joystick/BUS3

Hallo,

kann mir zwar gerade (offline) nicht erklären warum der Compiler diese Symbole (unter Unix) doppelt findet (aber unter Windows nicht), aber du kannst mal probieren den Soundchip aus target.h zu entfernen:
kommentier mal die beiden zeilen aus
https://github.com/avg67/nkc/blob/main/SW/SysGCC-delta/m68k-elf/m68k-elf/include/ndrcomp/target.h#L34
und
https://github.com/avg67/nkc/blob/main/SW/SysGCC-delta/m68k-elf/m68k-elf/include/ndrcomp/target.h#L71

Hallo andi,
... DU BIST MEIN HELD !!!

Er compiliert bis zum Ende durch ... ich schau gleich mal, ob das .68k dann auch auf dem NKC läuft.

Zum Hintergrund: Die toolchain von ddraig wurde mal für ATARI geschrieben (glaube ich ...), die ist aber ganz ähnlich, wie die von Dir mit SysGcc. Ich habe dann die Anteile von Dir rüber kopiert in die andere Umgebung ... und damit fängt das Problem natürlich an. Ich schreib Euch was ich geändert habe. Das der Sound im Moment dann nicht funktioniert, ist ja mal zunächst egal.
Mit dem alleinigen auskommentieren in der Target.h war es natürlich nicht getan. Ich musste auch die libnkc.a neu compilieren ....

... aber alles gut ==> PERFEKT!!

-----------------------
68008/GDP64HS/BootRAM68k/KEYr4/IOEenh mit 2xSD-Karte/Sound3/UHR3/IOEenh mit Joystick/BUS3

-----------------------
68008/GDP64HS/BootRAM68k/KEYr4/IOEenh mit 2xSD-Karte/Sound3/UHR3/IOEenh mit Joystick/BUS3

Ich bin heute nur bis "5." gekommen. Meine alte Möhre hat sich trotz SSD lange mit dem "make all" beschäftigt.

Morgen wird keine Zeit sein. Aber danach dann wieder...

Frohe Weihnachten!

-----------------------
Definitiv sind Frösche und Himbeeren am besten!