Moin Moin,

Torsten und inzwischen auch ich entwickeln z.Z. einen C-Crosscompiler für die 68k NKCs.

Basissystem ist ein Ubuntu-Linux, aktuelles Zielsystem ist erst mal der 68020 mit FPU und GDP-FPGA unter JADOS. Die Unterstützung für die anderen 68k Rechner wird folgen, wenn wir alles zur Zufriedenheit am laufen haben.
Die GDP-FPGA ist eigentlich nur wegen des Timers notwendig

Das erinnert mich daran, dass ich schon vor längerer Zeit eine IO-Karte mir Timer, SPI- und I²C-Interface aufbauen wollte, damit die Leute die keine GDP-FPGA haben auch in den Genuss von z.B. SD-Karten kommen.

-----------------------
Gruß
-=jens=-

Was meinst Du mit "entwickeln"? Eine Library für gcc machen oder wirklich einen Compiler schreiben?

Michael

Moin,

es ist "erst mal" eine Lib für den gcc (läuft schon recht gut).
Ein weiteres Projekt wäre dann ein C-Compiler der direkt auf dem NKC läuft.

-----------------------
Gruß
-=jens=-

Moin,

ich habe mal alle meine NKC-68K Projekte auf GitHub eingestellt (https://github.com/THemmecke), damit Aktualisierungen schneller verfügbar sind.
Dazu zählen:

- 68K00: Eagle- und VHDL- Quellen für die 68000er Karte
- 68K20: Eagle- und VHDL- Quellen für die 68020er Karte
- GDPFPGAII: VHDL-Quellen für die GDP-FPGAII (LFXP6C und LFXP2C)
- GDPFPGAII-EAGLE: Eagle-Quellen für die GDP-FPGAII (LFXP6C und LFXP2C)
- NKC-CLIB: CLIB für den NKC (68020 und 68000)


Die bisher nicht in HW realisierte GDPFPGAII Version mit LFXP2C, die Hans-Werner schon auf seiner Seite hat, hat noch einen Bug
in der Spannungsversorgung des FPGA ! Also wenn, dann unbedingt das Git-Repo verwenden !

Die CLIB implementiert eine vollständige ANSI-C-Lib incl. JADOS/NKC-FS und FAT/FAT16/FAT32-FS (FatFs R0.10a von elm chan).
Z.Z. werden tlw. noch GP und Jados Funktionen verwendet.
Zum Kompilieren benötigt man noch die ToolChain für m68k, siehe doc/m68k-tools-ReadMe.txt
Ausserdem ist im Verzeichnis tools ein elf2bin, welches aus dem ELF32 direkt ein *.68K File mit Relokation erzeugt.
Das elf2bin wird vom Makefile automatisch verwendet.
In Makefile.rules kann man verschiedene Einstellungen vornehmen, an einer Doku arbeite ich, falls grosses Interesse an der Lib besteht auch "etwas schneller" :-).

Die Lib >funktioniert<, d.h. es ist noch "Luft nach Oben" für Verbesserungen und Optimierunugen. Ich habe z.B. zunächst mal darauf verzichtet,
das JADOS-Filesystem mit Assembler zu optimieren, gleiches gilt für die Speicherverwaltung, die ist auch eher "rudimetär".

Warum habe ich gerade diese LIB als Grundlage genommen ? Im Gegenzatz zu newlib oder uClibc werden nicht 1Mio Platformen und Prozessorarchitekturen unterstützt,
was es wesentlich einfacher macht wirklich alles (in entlicher Zeit) zu verstehen und dann fehlendes zu implementieren.
Dokumentation ist momentan noch "dünn":
- doc/README 1st.txt- Struktur der Lib
- doc/CLIB-Structure current.dia- DIA-File, das die Struktur rund um File-IO, printf & Co. visualisiert
- doc/m68k-tools-ReadMe.txt- Installation der Tool-Chain
- Makefile.rules- hier kann man einige Schalter umlegen, sollte witestgehend selbsterklärend sein
- projects/ enthält ein paar Beispiele, wie man die Lib verwenden kann


So, jetzt bin ich mal gespannt, ob da drausen noch jemand bastel/tüftelt/programmiert...

Grüsse
Torsten

Moin Torsten,

ich muß mir leider erst mal wieder eine nue VM erstellen, die alte ist nicht mehr OK :-(

Ich hab allerdings gesehen, das du die FAT Unterstüzung "nur" für die GIDE eingebaut hast. Währe schön, wenn das auch für die SD-Cards eingebaut wird (die verwende ich ja meist).

Ansonsten werde ich wohl so in ca. 2 Wochen wieder dazu kommen, etwas mit/für den NKC zu machen.

-----------------------
Gruß
-=jens=-

Moin Jens,

neue VM bauen, siehe doc/m68k-tools-ReadMe.txt !

Wg. der FAT Unterstützung hast du natürlich recht.
Das FS habe ich ja schon versucht soweit zu abstrahieren, sodass JADOS-FS und FAT quasi transparent unterstützt werden.

Der nächste logische Schritt ist, die Low-Level Hardware Routinen ebenfalls in Treiber auszulagern (/drivers) und über ein einheitliches Interface verfügbar zu machen.
Dadurch wäre es mögich, jedes Dateisystem auf jedem Device zu betreiben.

Ich habe da auch schon ein paar Ideen, aber man kommt da schnell in Bereiche, wo es extrem umfangreich wird (z.B. wenn man das dynamisch zur Laufzeit machen will).


LG
Torsten

Moin,

habe mal einen ersten Wurf mit Treiber-Modell auf github gestellt:

https://github.com/THemmecke/NKC-CLIB

Die Doku dazu muss noch "wachsen" und da ist sicher noch der ein oder andere Bugs drin. Läuft aber soweit schon ganz gut. Als Demo mal die shell anschauen (projects/shell), da wird im Grunde alles verwendet.

Zugriff auf JADOS Dateisystem erfolgt noch über GP/JADOS, FATx kann auch ohne JADOS betrieben werden.

Einstellungen wie immer in Makefile.rules.

Grüsse
Torsten

Hallo Jens,

>es ist "erst mal" eine Lib für den gcc (läuft schon recht gut).

Da haette ich Interesse dran, koenntest Du die Lib 'veroeffentlichen'? Ich habe eine gcc m68k toolchain (Neudeutsch!) auf dem Windows10 PC am Laufen, bin aber noch ganz am Anfang mit den diversen Complier/Linkersettings zu experimientieren. Ein C cross compiler fuer den NKC am PC ist eine sehr reizvolle Sache, selbst ohne die C standard libs (wer braucht die schon - GP forever)

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

Moin smed,

der Compiler ist nicht mein "Kind", ich bin da nur Anwender/Tester.
Torsten hat alles auf git veröffentlich: https://github.com/THemmecke/NKC-CLIB

Viel Spass

-----------------------
Gruß
-=jens=-

Hallo,

über die verlängerten Osterfeiertage will ich mich endlich mal explizit und intensiv mit dem 68k NKC beschäftigen. Dafür nehme ich ein 68008 System mit. Inkl. SOUND3, IOE mit Joystick und IOE mit SD-Card.

Die NKC-CLIB ist dann sicher erstmal ein guter Startpunkt neben Assembler. Aber gab es für den NKC auch einen nativen C-Compiler? Ich glaube mich zu erinnern, daß es in der Loop auch mal einen C-Kurs gab. Bei der Durchsicht meiner Disketten hab ich bis jetzt aber nur Pascal gefunden.

Gruß, Rene

Moin Rene,

nativ C gab es leider nur unter CP/M.

-----------------------
Gruß
-=jens=-

Hi Jens,

ja für CP/M dann sogar verschiedene. Dann also per Crosscompiler. Das ist ja auch komfortabler. Obwohl man ab 68k ja schon halbwegs am NKC arbeiten kann.

Gruß, Rene

Moin,

ein "vernünftiger" Crosscompiler wäre sehr schön (gcc ist irgendwie ein Monster)

Ich hätte liebend gerne aber auch ein C-Compiler der unter Jados läuft

-----------------------
Gruß
-=jens=-

Moin moin,
ich benutze genau 3 files von gcc:

m68k-elf-gcc.exe
m68k-elf-strip.exe
m68k-elf-objdump.exe

Nichts mehr. Damit kannst du auf dem PC in C NKC binaries erzeugen. Alle anderen 1000 files und folders von gcc kannst du loeschen.

Du braucht zwei Dateien

ram.ld //das ist ein Linkerscript, siehe andere Posts von mir
file.c //dein c code

Dann so compilieren:

m68k-elf-gcc -std=gnu99 -t -save-temps -mc68000 -mpcrel -fomit-frame-pointer -nostartfiles -Wno-attributes -T ram.ld -Wa,--w,--pcrel,-acdhls=file.asm,--noexecstack file.c -O3 -lm

m68k-elf-strip --input-target=elf32-m68k --output-target=symbolsrec -o file.s19 a.out
m68k-elf-objcopy --input-target=srec --output-target=binary file.s19 file.m68
m68k-elf-objdump -d a.out > file.ass
m68k-elf-objdump -h a.out > file.mem


file.m68 ist das NKC binary, rauf auf den NKC und los !
file.ass ist lesbarer Assember code
der Rest sind Gimmicks.

Gruss
smed

PS So sieht fuer mich ein vernuenfiger C Complier aus

okay, okay, sehe gerade das:

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <math.h>
mit von der Partie sind.

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

Hallo,

danke für die Hinweise! Ich packe grad alle essentiellen NKC-Sachen zusammen und werde das am Samstag ausgiebig ausprobieren. Freu mich schon drauf

Gruß, Rene

Zitat von smed: okay, okay, sehe gerade das: #include <stdlib.h> #include <stdio.h> #include <string.h> #include <math.h> mit von der Partie sind.

Aber die kann ich nicht einfach benutzen, oder? Ich hatte mir einfach vorgestellt, daß ich testweise mal string.h mit reinnehme, dann z.B. mit strcat() zwei Teilstrings verbinde und der Compiler die nötigen Routinen dazulinken wird.

Compilieren läßt sich ja auch alles fehlerfrei, beim Aufruf gibt es dann aber einen Crash. Ich vermute, daß da nötige Unterroutinen wie Speicherbelegung etc. einfach nicht dabei sind.

Wenn ich "normal" in C programmieren will, wäre dann wohl der einfachste Weg, sich mit Thorstens CLIB zu beschäftigen, oder?

Als Toolchain habe ich übrigens das Paket hier (Windows) installiert:

https://gnutoolchains.com/m68k-elf/

Ich schnupper ja gerade erst in C auf dem NKC und 68k Plattform überhaupt rein. Wenn ich nur meine eigenen Routinen für KEY, SOUND usw. basteln will, sollte das ja analog zu Deinem Code für die GDP64 im HelloWorld Beispiel gehen. Jedenfalls ist der Einstieg so einfacher als in Assembler.

Gruß, Rene

Hallo,

jetzt muss ich mich doch auch mal kurz zu Wort melden :-) - finde es sehr cool, das hier wieder ein wenig Fahrt in eine sehr interessante Richtung aufgenommen wird!


Ja, im Grunde braucht man "nur":

gcc (oder was anderes, was C-Syntax versteht) und "irgendwas", was aus dem Object-Code ein .68k macht. Dann hat man ein C-Programm kompiliert.
BTW: elf-objcopy erledigt das Erzeugen des m68k-Codes nur für Code, den der Compiler relokativ kompilieren konnte, das ist aber i.d.R. nur für kleine Programme der Fall !
Sobald aber Relokationen vom Typ 68K_8, 68K_16 oder 68K_32 dabei sind wird's knifflig, dafür hatte ich mir elf2bin geschrieben, was mir eine Reloc-Tabelle zum Programm Linkt, die beim Start des Programmes entsprechend der Ladeadresse ein Relozieren ermöglicht.

Im Grunde kann man also (irgend)einen C-Compiler verwenden um ein Programm mit "C-Syntax" zu kompilieren.

Da wären alternativ zu GCC z.B. AHCC, LCC, SDCC, Small-C, CStar-C usw.
Sinnvoll wird das Ganze aber eben erst, wenn ....

Zitat smed:
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <math.h>
mit von der Partie sind.

Das bedeutet, ein C-Compiler ohne CLib ist wie ein DeLorean ohne Flux-Kompensator - akademisch interessant aber recht nutzlos.
Da verwendet man besser einen Assembler mit einer guten Makrobibliothek und hat am Ende schnelleren/optimaleren Code (hallo Jens ;-) !)
Natürlich gibt es einfachere C-Compiler als den gcc, aber es gibt nur wenige, die auch einen brauchbaren Linker haben!
Ohne Linker lassen sich eigentlich keine vernünftigen Projekte stemmen. Ein Präprozessor ist jetzt nicht unbedingt notwendig, aber extrem hilfreich, denn letztlich hat man in allen Quellen mit C-Code irgend welche Präprozessor-Direktiven drin, die man dann mühsam rausfriemeln müsste.
Wenn man also ein bisschen länger darüber nachdenkt, ist die gcc Tool-Chain nicht die schlechteste Wahl. Hat man erst mal eine funktionierende CLib, lassen sich Compiler, Linker und andere Tools auch als Stand-Alone-Programme für den NKC erstellen.

Was die Größe der CLib, bzw. die Größe der entstehenden Programme angeht, muss man da ein wenig differenzieren, um das wirklich fair zu bewerten:

Im aktuellen Entwicklungsstadium macht die CLib halt das, was sie soll, und damit schon recht viel (Hardware-Treiber für KEY, SD-Card, IDE, File-Systeme, Speicher-Verwaltung, evtl. IEEE-Math Emulation etc.) und wenn die dann komplett zu einem simplen "Hello World !" gelinkt wird ist das Ergebnis eben genau das: GROSS.
Für einige Module besteht bereits die Möglichkeit, diese via Kompiler-Schalter zu/abschalten zu können, wenn sie nicht benötigt werden, das spart schon mal Speicher.
Das automatische Optimieren ist ein wenig "tricky", das ist noch so ein Thema, mit dem man sich mal ausführlicher beschäftigen müsste.
Wer die CLib mal genauer unter die Lupe nimmt wird feststellen (und das gilt für so ziemlich jede CLib, die ich bisher gesehen habe), dass der größte Brocken der ganze Code um printf ist. Ein vollständig implementiertes printf ist einfach ein wahres Monster!
Wenn man das wegläßt, verliert der Code erheblich an Masse.

Auf der anderen Seite muss man aber auch sagen, wir reden über einen 68K mit 4GB Adressraum - die CPU68K hat bereits 2MB RAM die CPU68K20/30 schon 4MB RAM OnBoard und wem das nicht reicht der nimmt eben noch 28MB auf der RAM Karte dazu, was sind da schon 100kB ;-)

Leider habe ich im letzten Jahr aus Job-technischen Gründen die Entwicklung erst mal radikal zurückfahren müssen, blöderweise muss man ja auch noch arbeiten um leben zu können und aus irgend einem Grund, den ich vergessen habe, gab es bei uns massenhaft Dinge zu tun, echt lästig.

Mein Ziel in dem Projekt war/ist es (wird es evtl. bald wieder sein?), die CLib in eine Art Kernel- und User-Space aufzuteilen: Der Kernel-Bereich enthält alles, was Hardware-Treiber , File-Systeme und Speicherverwaltung betrifft. Daraus könnte dann ein JADOS-NT oder so entstehen.
Die UserSpace-Lib ruft über ein ioctl api die Funktionen des Kernel auf. Damit würden die Programme dann auch deutlich kleiner werden und man bewegt sich insgesamt wieder im gleichen Rahmen wie jetzt mit JADOS.
Man könnte auch darüber nachdenken, den Kernel nach dem Vorbild uCOSII Multitaskingfähig zu bauen, das wäre dann das Sahnehäubchen.

Ist aber wie gesagt alles noch im Fluss (wobei aktuell nix fließt) und sowas alleine als reines Hobby zu stemmen ist eben schon aufwändig.


LG
Torsten

Hallo,

>Wenn ich "normal" in C programmieren will, wäre dann wohl der einfachste Weg, sich mit Thorstens CLIB zu beschäftigen, oder?
Jein, das stimmt. :P Wenn du die ueblichen Libraries haben willst dann ist das sicherlich der beste Weg.

Ich sehe den NKC (heute) allerdings eher als das, was man heute als ein Embedded System bezeichnet und hab meine Wunschliste etwas nach unten revidiert. Wenn man also wirklich nur das will:

- super hardwarenah programmieren, aber bitte eine kleine Stufe hoeher als Assembler
- dis-assemblierte .68k executabels die fast aussehen wie das was man sonst "per Hand" in Assembler schreibt
- moeglichst keinen, oder nur sehr wenig code der dazugelinkt wird
- akzeptierte libs sind das Grundprogramm und evt. JADOS

Also eher ein Lern-System, dann ist ein nackter Compiler schon genau das Richtige. Wie schon oefters erwaehnt, der C-Compilder ist dann also eher ein besserer Makroassembler als das was man unter C-programmierung allgemeinhin versteht. Aber genau so will ich das fuer mich.

> den der Compiler relokativ kompilieren konnte, das ist aber i.d.R. nur für kleine Programme der Fall

Hallo,

ich spiele gerade auch etwas mit dem GCC (11.2 .. hab letzten Winter angefangen..) und versuche eine newlib hinzubiegen, einfach mal so.

Momentan ist bloss write auf CO2 und read auf CI2 gebogen, das wars. Einen m68k-elf hab ich kompiliert, die newlib ist schonmal erfolgreich durchgelaufen, jetzt muss ich die Compilertools für das NKC-Target bauen. Hab sowas noch nie gemacht und reime mir das meiste aus 10 Dokufiles und 20 Webtutorials zusammen.

Hauptsächlich aber die hier:

https://wiki.osdev.org/GCC_Cross-Compiler
https://wiki.osdev.org/OS_Specific_Toolchain
https://wiki.osdev.org/Porting_Newlib
https://wiki.osdev.org/Hosted_GCC_Cross-Compiler

Muss aber sicher am Startupcode und Linkerscript tweaken usw.

Dass es so 50KB Overhead macht, ist mir vorerst egal, ich hab ne 1MB-SEL im System. Vielleicht kann man auch mal die baselibc probieren:

https://www.aslak.net/index.php/2019/03/18/adding-a-c-library-to-the-68000-sbc/

Oder eben doch Torstens NKC-CLIB, kann die inzwischen 68008 oder immernoch nur 68020 (da war mal was)?

Gruß,
Christian

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