Hallo,
ich hab vor langer Zeit mal den GCC an den NKC angepasst (mit Newlib etc.). Für den Fall dass es jemanden Interessiert habe ich die Beschreibung (+ Download) hier https://github.com/avg67/nkc/wiki/GCC-Crosscompile-Framework-f%C3%BCr-den-NKC
Damit hab ich auch schon erfolgreich einige Jados-Programme geschrieben. Zwei davon (Dhrystone-benchmark und 4-gewinnt Spiel) sind im Source dabei.

Quote by Torsten: Hi, sollte mit allen CPUs laufen. -> Setting 'CPU' in Makefile.rules Habe allerdings lange nix mehr an der LIB geschraubt, evtl. gehts ja dieses Jahr mal weiter. LG Torsten

Bei 68008 wirft er mir in der Ursprungsversion einen Haufen Fehler, erstmal weil er versucht den GCC mit -m68008 aufzurufen, was natürlich nix ist.

Wenn ich das korrigiere und auch die ganzen #ifdefs anpasse, kompiliert er, aber wirft mir immer wieder "ADRESS FEHLER" weil offenbar öfter versucht mit Word- und Langwortzugriffen auf ungerade Adressen zu gehen. Warum versuche ich gerade rauszufinden.

Nach meinem Gefühl gerne im Bereich der Debugausgaben. Vermutlich hat nur ein Makro ein Problem. Vielleicht sind es auch meine 68008 "Fixes" die was versaut haben

Ich hab das Repo mal geforked und spiele etwas damit.
(Bin gestern um 1 ins Bett gekommen, heute muss ich früher, brr)

Ich hab die Änderungen mal in den Fork gepushed:
https://github.com/cerker68k/NKC-CLIB

Vermutlich sind ein paar von den LEA32A0 etc. auch überflüssig. Wenn ich CONFIG_DEBUG_MM anschalte, kackt er im dbg_walk_heap ab .. und zwar an der Stelle wo er "FREE" anzeigen sollte.


void dbg_walk_heap(void)
{
struct block_header *location = (struct block_header*)_HEAP;
int i = 0;
int j = 0;

mm_lldbg("\n memory map: \n\n");

//mm_lldbg(" Block No. Start Size Free Next Hdr\n\n");

while(location != 0)
{
while(location != 0 && i < 5)
{
mm_lldbghex(" BLOCK-NR = 0x",j);
mm_lldbghex(" FREE = 0x",location->free);
mm_lldbghex(" START = 0x",location->start);
mm_lldbghex(" SIZE = 0x",location->size);
mm_lldbghex(" NEXT = 0x",location->next);

location = (struct block_header*)location->next;

i++; j++;
};
i=0;
};

}


Im mm_lldbghex und offenbar passiert es beim dereferenzieren von location->free .. obwohl location ja auf _HEAP stehen sollte und _HEAP zuvor, mit mm_lldbghex, korrekt angezeigt wird. In D0 und A0 steht dann übrigens die gleiche ungerade Zahl .. die auch auf nichts sinnvolles zeigt.


serial debugging enabled
mm_init
_RAM_TOP = 0x000C63FE
_HEAP = 0x000353C8
_ram_size = 0x00091036

memory map:

BLOCK-NR = 0x00000000
FREE = 0x


Quote: Hallo, ich hab vor langer Zeit mal den GCC an den NKC angepasst (mit Newlib etc.). Für den Fall dass es jemanden Interessiert habe ich die Beschreibung (+ Download) hier https://github.com/avg67/nkc/wiki/GCC-Crosscompile-Framework-f%C3%BCr-den-NKC

Auch mal anschauen...

Gruß,
Christian

Ich habe nochmal schnell das "j" hinter "BLOCK..." durch location ersetzt, um zu sehen ob der Pointer richtig ist.

Er ist es, steht auf Heap und ....C ist auch gerade. Warum kommt dann bei "location->free" Mist raus.


serial debugging enabled
mm_init
_RAM_TOP = 0x000C63FE
_HEAP = 0x00054B7C
_ram_size = 0x00071882

memory map:

BLOCK-NR = 0x00054B7C
FREE = 0x


Im Fehlerscreen sind D0 und A0 beide auf 0x221F4E75, das ganze auf 0xF702 im Code (habe das Shell-Demoprojekt probiert) was laut mapfile in mm_free/dbg_walk_heap liegt. Mit Disassembly an folgender Instruktion:


542 0624 4E56 FFF4 link.w %fp,#-12
543 0628 2039 0000 move.l _HEAP,%d0
543 0000
544 062e 2D40 FFFC move.l %d0,-4(%fp)

.. hier klappt alles ..

560 0672 588F addq.l #4,%sp
561 0674 4879 0000 pea .LC24
561 0000
562 067a 4EB9 0000 jsr nkc_ser1_write
562 0000
563 0680 588F addq.l #4,%sp
564 0682 202E FFFC move.l -4(%fp),%d0
565 0686 2040 move.l %d0,%a0
** 566 0688 2028 000C move.l 12(%a0),%d0 **
567 068c 2F00 move.l %d0,-(%sp)
568 068e 4EB9 0000 jsr gp_ser1_write_hex8


Die 2 vorgehenden sind recht sicher die Dereferenzierung, die aber schiefläuft und dann schlägt move.l 12(%a0) fehl weil %a0 eben ungerade ist .. interessant ist, dass in -4(%fp) eben _HEAP stehen sollte, wurde ja am Anfang gesetzt? Macht irgendwas zwischendurch A6 (den Framepointer) kaputt (blöderweise hab ich den NKC gerade abgedreht und kann ned in A6 schauen und muss jetzt dringend los) ..

Compilerfehler? (Ja ich weiß ists fast nie, aber da die uclinux-Seite down ist musste ich mir die vorgeschlagene Toolchain aus diversen Mirrors zusammenkratzen .. vielleicht buggy?)

Ich glaub ich hab gerade erfolgreiches Rubber-Duck-Debugging betrieben. Ich hab mich erinnert, dass ich mal den Monitor gefilmt hatte um die kurz aufblinkenden Meldungen zu sehen und auf dem Video auch der Fehlerscreen war .. Jup. A6 steht auf $D4... irgendwas. Das ist im Grundprogramm. Und ja, Aufrufe von Grundprogrammroutinen über TRAP nutzen A6 um die Adresse zu berechnen, d.H. sie zerschießen den Framepointer und move.l -4(%fp),%d0 / move.l %d0,%a0 zieht nicht die Basisadresse der Location-Struct, sondern die ersten Befehle von CO2SER (glaube ich).

Die Frage ist nun, ist das ein Problem in Compilersettings, oder muss man den einfach in den GP-Aufrufen auf den Stack retten? Die Lib lief ja so schonmal?

Gruß,
Christian

So. Jetzt hab ich gerade Mittagspause und schau nochmal theoretisch in den Code, ausprobieren kann ich es vermutlich erst morgen.

Wirklich zuverlässig ist die Adressfehler-Stelle wie gesagt wenn man das Debugging über serielle Schnittstelle anschaltet.

Dann p

test

-----------------------
Ob 8bit oder 16 oder 32 ist doch egal, Haupsache selbstgebaut!

Hi Christian,

bitte poste doch deinen letzten Beitrag nochmal, irgendwie sind die letzten Beiträge in dem Thread verloren gegangen.

LG
Torsten

Hmm, das hab ich schon wieder vergessen, was ich da geschrieben hatte, darum hatte ichs ja geschrieben

Muss ich rekonstruieren.

Quote by andi: Hallo, ich hab vor langer Zeit mal den GCC an den NKC angepasst (mit Newlib etc.). Für den Fall dass es jemanden Interessiert habe ich die Beschreibung (+ Download) hier https://github.com/avg67/nkc/wiki/GCC-Crosscompile-Framework-f%C3%BCr-den-NKC Damit hab ich auch schon erfolgreich einige Jados-Programme geschrieben. Zwei davon (Dhrystone-benchmark und 4-gewinnt Spiel) sind im Source dabei.

Hallo, andi (aber auch gerne alle anderen).

Als erste kleine Programmierübung wollte ich mal einen Player für VGM-Dateien mit Ausgabe auf SOUND3 basteln (zumindest für solche Dateien mit Inhalt für "unseren" AY-3-8910). Leider scheitere ich schon beim Einlesen der Datei mit getc, fgetc oder auch fread. Die liefern letzten Endes alle das Gleiche. Aber es ist binäre Grütze!

Das parallel auf einem "normalen" Linux-System compilierte Programm läuft dort einwandfrei.

Frage: Hat schon jemand erfolgreich was mit diesen Funktionen gebaut?

Ansonsten würde ich mich mal mit diesen Jados-Traps befassen und damit mein Glück versuchen. Da gibt es ja offensichtlich vielversprechende Routinen.

Ich hatte nur eigentlich gehofft, dass diese Lib hier sich mit diesen Funktionen vielleicht schon selbst an die Traps dran hängt und ich mir das sparen kann...


Gruß, Torsten (der für jedes funktionierende Fragment mit getc und Co. dankbar ist).

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

Ah ja bei meinem GCC-Port sind leider (noch) nicht die Jados-Traps mit den file-Funktionen verbunden. Das steht auch auf meiner Todo-Liste. Mit fopen, read, write kannst derzeit nur auf die Ser lesen / schreiben (auch Interrupt-getrieben). Wenn du files lesen willst musst die Jafos-Traps direkt via Inline-Assembly verwenden.
LG Andi

Ich habe jetzt meine ersten Routinen zum Aufruf von Jados-Traps mit Inline-Assembler fertig. Ist aber noch nicht ganz rund. Insbesondere die Parameter-Übergabe in die Funktion - und damit in den Inline-Assembler - hinein habe ich sehr hausbacken gelöst: Böse böse die Bytes gezählt und zur Laufzeit eine Konstante in einer Speicherzelle des Inline-Assemblers modifiziert!

Ähnlich für die Rückgabe von Werten der Funktion.

Hat da jemand schon Erfahrung mit und evtl. ein Code-Fragment, das das vielleicht sauber über den Stack löst?


Ebenso für das Auslesen der Kommandozeilen-Parameter beim Aufruf des Progrämmchens ("argc" und "argv")? Bei Nutzung der Lib bekam ich immerhin argc und argv[1]; argv[0] war immer leer). Ohne Lib muss man das auch noch selbst machen.

Will als Nächstes den Stack beim Aufruf untersuchen und habe mir dafür eine Routine zur Ermittlung des SP bei Aufruf und Ausgabe eines Hexdumps ab dieser Adresse zur Laufzeit geschrieben. Ist dann jetzt aber erst einmal Fleißarbeit...

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

Kommandozeilen-parameter liest meine gcc Library schon aus und übergibt diese an main (argc, argv).
Für die wichtigsten Jados-Aufrufe hab ich auch schon C-Funktionen (mit Inline-Assembly). Ich würd übrigens nur in Ausnahmefällen Parameter am Stack übergeben (ist zu ineffizient). Besser ist in Registern (gcc hat dazu eine calling convention). Ich stell mal ein kleines Jados_Example das das Disk-Directory ausliest und anzeigt online.

LG,
Andi

Hallo,
ich hab mal ein kleines Beispiel eingecheckt für
- Commandline parameter
- System-Uhrzeit auslesen und anzeigen
- Jados Version auslesen und anzeigen
- Directory von Laufwerk 0 anzeigen
https://github.com/avg67/nkc/tree/main/SW/Jados_test
Das file nkc.h hab ich leider updaten müssen. Dieses gehört in das Verzeichnis C:\SysGCC\m68k-elf\nkc_common\nkc\
Man sieht hier sehr schön dass der Compiler nichts am Stack übergibt sondern direkt mit den Registern arbeitet. Das ist speziell beim 68008 viel effizienter.
z.B. folgende C-Zeile:
uint8_t result = jd_directory((void*)buf, (void*)"0:*.*", 0, 1, sizeof(buf));

ergibt folgenden ASM-Code:
uint8_t jd_directory(void* pbuf, void* ppattern, uint8_t attrib, uint16_t columns, uint16_t size) {
uint8_t ret = 0u;
asm volatile(
78ba:280e movel %fp,%d4
78bc:0684 ffff f000 addil #-4096,%d4
78c2:7e4a moveq #74,%d7
78c4:2044 moveal %d4,%a0
78c6:227c 0000 7976 moveal #31094,%a1
78cc:143c 0000 moveb #0,%d2
78d0:363c 0001 movew #1,%d3
78d4:323c 1000 movew #4096,%d1
78d8:48e7 0006 moveml %a5-%fp,%sp@-
78dc:4e46 trap #6
78de:4cdf 6000 moveml %sp@+,%a5-%fp
78e2:1800 moveb %d0,%d4

Ich finde das ist recht effizienter code. Händisch würde ich es kaum besser hin bringen

Aufruf z.B. mit test 1 2 3 4 5

Oh! Das sieht spannend aus!

Wollte das schnell mal testen, lief aber auf einen Compiler-Fehler.

Habe dann ein #define USE_JADOS in die target.h eingefügt. Direkt hinter das #define TARGET_H gleich zu Beginn. Ist das richtig so?


Jetzt bekomme ich immerhin schon mal ein test.68k, das auch auf dem NKC läuft und einen Output entsprechend deinem Foto produziert. Vielen Dank für das Beispiel. Muss ich die Tage mal genauer ansehen.

Eines fällt mir direkt auf: In deinem argp[0] befindet sich offensichtlich der erste Parameter und nicht der Name des Programmes. Auf deinem Foto die "1". Das war mir letztens bei meinen ersten Versuchen mit deiner Lib schon aufgefallen. Ist das Absicht? Kommst du an den Namen nicht ran?


Gruß, Torsten (der jetzt aber erstmal den Tag beendet )

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

Hi,
so kannst du es auch machen. dann ist halt Jados global enabled. Ich hab das immer im makefile gesetzt um das für jedes projekt individuell machen zu können.
(CFLAGS=-g -Os -m68000 -Wall -fomit-frame-pointer -nostartfiles -std=gnu99 -Dndrcomp $(ISEARCH) -DUSE_JADOS)
Warum ich für den ersten Parameter anstelle des Programmnamens den gesamten Parameter-string übergebe weiss ich ehrlich gesagt nicht mehr (ist ca. 20 jahre her dass ich das gemacht habe). Vl. kann man bei Jados den Programmnamen wirklich nicht auslesen. Ich muss mal in die Jados Doku rein schauen. Das ganze passiert jedenfalls in crt0.c ab Zeile 199 (C:\SysGCC\m68k-elf\nkc_common\nkc\).

LG,
Andi

Hallo,
Ich hab nun ein weiteres Update zum Jados-Test eingecheckt.
Und zwar fragt er nun nach dem Anzeigen des Directories von Laufwerk A nach einem Filenamen, liest dieses file ein und zeigt es am Bildschirm an (sollte ein ASCII file sein)
LG,
Andi

Quote by andi: Ich hab das immer im makefile gesetzt um das für jedes projekt individuell machen zu können. (CFLAGS=-g -Os -m68000 -Wall -fomit-frame-pointer -nostartfiles -std=gnu99 -Dndrcomp $(ISEARCH) -DUSE_JADOS)

Da hast du Recht. Ist doch eleganter im Makefile...

Quote by andi: Hallo, Ich hab nun ein weiteres Update zum Jados-Test eingecheckt.

Den Rest des Nachmittags habe ich endlich mal "frei". Jetzt kann ich gucken, testen und spielen.

Danke für das betreute Crosscompiler-Lernen...

Torsten

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

Hallo,
hab gerade meinen nächsten großen Meilenstein in Punkto cross-development mit GCC für den NKC erreicht - und zwar das Remote Debuggen. Hab seit längerer Zeit an einem seriellen Debug-Stub gearbeitet den man in ein (GCC) C-Projekt mit dazu compiliert um dann vom PC aus bequem das Programm am GDB zu debuggen (auch grafisch via z.B. DDD). Hab gerade den letzten Bug gefixt und das erste mal erfolgreich debuggt (inkl. Variablen, Memory anschauen und editieren). Ist ein großer Schritt vorwärts von Debug-prints's zum GDB!

Super !!!

-----------------------
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.

NKC - OpenSource since 1983

Hi,
Für den Fall dass es jemanden interessiert - hab jetzt den GCC - C++ Compiler am laufen am NKC. Problem ist derzeit noch die Größe der binaries wenn iostream (cout) verwendet wird. Aber ohne sind die binaries kaum größer als reines c.

Hi,
das ist sehr interessant ! Koenntest du die gcc Version zum download bereitstellen?

Gruss
smed

-----------------------
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.

NKC - OpenSource since 1983