Hallo Andi,
nach mehreren Experimenten habe ich jetzt für den gemeinsamen Einsatz von _WRITE (x=0...255) und (y=0...511) mit Ursprung links unten und _SETCURXY (x=0...79) und (y=0...23) mit Ursprung links oben eine Funktion WriteScreenXY angepasst:

static inline __attribute__((always_inline)) void WriteScreenxy(uint8_t x, uint8_t y,const char* const p_str)
{
// Koordinaten umrechnen für Texteingabe mit Format Zeile 0 - 23 von Ursprung oben links
y = abs(y-24)+1;
for(uint8_t page=0u;page<2u; page++) {
// Text schreiben auf Seite 0 und 1 (wegen blinkendem Cursor)
gp_newpage(page,0u);
gp_writexy(CCNV_X(x),CCNV_Y(y),0x11, p_str);
}
}

Um blinkende Cursor zu unterstützen, bin ich Deinem Rat gefolgt und gebe den (Grafik)Text auf Seite 0 und 1 aus.

Damit kann ich nun z.B. mit folgenden Aufrufen

gp_cursor_on();
char bfr[80u]={0u};

WriteScreenxy(10,0,"Gib Deinen Vornamen ein: ");
gp_setcurxy(38,0);
fgets(bfr, sizeof(bfr), stdin);

gp_cursor_off();
WriteScreenxy(10,3,"Taste fuer weiter... ");
gp_ci();

mit und ohne blinkendem Cursor arbeiten.

Soweit mal von mir und Danke nochmal mit dem Tipp zum Unterschied zwischen Grafik und Text.

VG Jürgen

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

Hallo Jürgen,
super dass das nun funktioniert bei dir.
ich denke wenn du keine Grafik brauchst ist der Mischbetrieb grafik /text ein wenig umständlich. Warum positionierst du den Text denn nciht mit gp_setcurxy und gibst ihn dann mit iprintf oder puts aus?
z.B. so:

gp_setcurxy(0,10);
iprintf(" \rcommand>");
gp_setflip(30u,0u);
gp_cursor_on();
gets(s);
gp_setflip(0u,0u);
gp_cursor_off();
puts("\r");
if (!strcmp(s, "on") ) {
puts("Computer spielt");
...

Hier wird der Cursor bei jeder Eingabe an die selbe Position gesetzt (x=0, y=10), dann mittels Leerzeichen der vorherige Text gelöscht, mit \r der Cursor auf den Zeilenanfang zurück gesetzt und dann der Text ausgegeben. Der Cursor blinkt danach direkt hinter command>

Wichtig ist auch zu wissen dass bei meiner Library stdin und stdout gepuffert sind. d.h. wenn du mit iprintf was ausgibst erscheint das nicht sofort am Bildschirm sondern landet in einem Buffer. Der wird erst ausgegeben wenn entweder das Zeilenende erreicht ist oder der Buffer voll ist.
Du kannst diesen Abschalten mit den folgenden zwei Zeilen (ganz am Anfang in programm, vor clearscreen):

setbuf(stdout,NULL);
setbuf(stdin,NULL);

Dann ist das ganze Verhalten leichter Verständlich. Ich denke du brauchst die Buffer nicht
Ich hab hier das modifizierte file von dir angehängt:
[/url]menu.c

PS. der Cursor blinkt auch bei gets /scanf etc wenn du newlib_stubs.c (C:\SysGCC\m68k-elf\nkc_common\newlib_stubs.c) durch diese hier ersetzt und dann die libraries neu compilierst:
https://github.com/avg67/nkc/blob/main/SW/SysGCC-delta/m68k-elf/nkc_common/newlib_stubs.c

Hallo Andi, ja, in die Falle mit dem Buffer bin ich wohl geraden.

Einfachste iprintf Ausgaben sind garnicht erschienen, wenn ich auf /n oder /r verzichtet habe in der Annahme, dass dann dahinter der Cursor erscheint.

Vielleicht noch ein Wort dazu, warum ich hier so auf der Cursor-Positionierung rumhacke. Es ist ein Intermezzo mit Startrek. In MmBasic habe ich vor einiger Zeit auf der Basis der Original Basic Programme und einer Variante für TRS-80 mit einem festen Bildschrimlayout das Spiel für mich neu programmiert. Um mich besser in C einzuarbeiten, will ich meine Variante nun, bevor es mit Schach weitergeht, auf den NKC für 68k bringen. Dazu benötige ich die Positionierungen.

Dein Beispiel probiere ich aber auf jeden Fall aus. Jeder Vorachlag bringt mich ja weiter. Besten Dank.

Die newlib.stubs habe ich vor wenigen Tagen aktualisiert. Gibt es da nich eine Neuerung? Ich sehe aber auch nochmal im github nach.

VG Jürgen

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

Hallo Jürgen,
Wenn du die newlib_stubs schon gepatcht hast dann passt das schon. Ist nichts neues.
Ja das mit den Puffern ist ein wenig gemein - ist aber bei ANSI-C so definiert und an diesen Standard habe ich mich gehalten.
LG Andi

Hallo Alle,
kurze Frage: Ist Jens Mewes alias DerInder hier im Forum noch aktiv bzw. erreichbar?

Auf Anraten von Andi habe ich mich jetzt verstärkt in das Handbuch zum GP7.0 eingelesen. Das doch mühsame hin- und herblättern hat mich veranlasst, den PDF Text in ein Dokument einzulesen und ein Inhaltsverzeichnis zu erstellen, mit dem ich leicht in den diversen Readern gezielt blättern kann. Ich würde das Dokument nun gerne weiter bearbeiten und z.B. wie bei Jados in verschiedene Kapitel auftrennen. Natürlich möchte ich es dann hier veröffentlichen. Dazu benötige ich aber eine Freigabe des Autors. Inhaltlich will ich nichts ändern.

Könnt ihr helfen?
VG Jürgen

PS: Ich weiß, das ist hier nicht das Thema, aber in dem Zusammenhang mit C und weil das hier ein populärer Thread ist, habe ich es hier eingestellt.

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

Hallo zusammen,
ich schraub immer noch am C-Crosscompiler unter Linux rum.
Also ich bin ja zuweilen bissl beratungsrestistent - nein, ich will keine VM mit Win im Ubuntu haben (redo versteht das :-) )

Ihr könnt mir aber sicher weiter helfen. Ich habe soweit einen Compiler m68k-elf zusammen. Die Delta von andi ist eingearbeitet. Der Comp spuckt auch mehr oder minder Sinnvolles aus. In den S-files und O-files sieht man schon ASM-Befehle.
Nun komm ich nur nicht ganz mit der Bedienung klar. Ich versuche es mit dem Post #14 von smed - vielleicht bist du ja online und kannst dir das noch einmal anschauen.

Quote by smed: 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 ...

Im Grunde sind das bei smed 5 Schritte.

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

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


Jetzt hab' ich dazu ein paar Fragen:

1. Schritt läuft soweit ganz gut durch - es kommen keine Fehlermeldungen. ABER: Ich hab' ja ein 68008-System - geht das mit der Option -mc68000 ??
Eingabe ist file.c mit folgendem Code:

#include<stdio.h>
int main() {printf("Hallo NKC\n");return 0;}

Ergebnisse sind:
- file.i (text)
- file.o (binär)
- file.s (text)
- file.asm (text)
ABER halt kein file.s19 ??

Zwischen-Schritt: Das file.o wird umbenannt in file.s19
(ob das funktioniert, da hab ich so meine Zweifel)

2. Schritt: Zunächst denke ich, dass in dem Post von smed ein Fehler ist - bin mir aber unsicher. Die Option -o müsste eigentlich nach dem input-file kommen. Sonst meckert er mit "File a.out nicht vorhanden". Die Option -o ist dafür da, damit das nachstehende file (a.out) gebildet wird - und das tut es dann auch, wenn die Option -o hinter dem input-file steht :-)
Vielleicht kannst du dir das noch einmal anschauen smed
Ergebnis: eine Text-Datei(!) a.out

3. Schritt: Hier nehme ich halt auch wieder das file.s19 von oben (ehem. file.o) dann läuft das durch.
Ergebnis: eine binäre Datei file.m68

4. Schritt: Dieser Schritt läuft nicht durch, weil a.out eine Text-Datei ist. Wenn ich aber statt der a.out die file.o - Datei nehme (vorher umbenennen nach a.out) dann kommt ein file.ass mit asm-code raus ... aber das müssste ja dann unverlinktes compilat sein ... ist auch zuwenig Code:

a.out: Dateiformat elf32-m68k
Disassembly of section .text.startup:
00000000 <main>:
0:487a 0000 pea %pc@(2 <main+0x2>
4:41fa 0000 lea %pc@(6 <main+0x6>,%a0
8:4e90 jsr %a0@
a:588f addql #4,%sp
c:7000 moveq #0,%d0
e:4e75 rts

5. Schritt ... zunächst unwichtig.

Also ich hab jetzt schon viel probiert auch die --help und --info der einzelnen Befehle bemüht, komme aber nicht weiter, weil ich im Grunde nicht genug Ahnung von dem Prozess habe, wie der ablaufen muss.

Ach ja, die binäre-Datei file.m68 wird umbenannt in file.68k, läuft aber nicht auf dem NKC-System :-(

... Vielleicht hat ja jemand Zeit sich das mal anzuschauen, wäre ja schön, wenn's funktionieren würde ...
@redo: Falls das noch was wird, poste ich alles, wie ich das aufgesetzt habe ... aber im Moment nützt das ja nicht viel.

Schöne Grüße
Daniel

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

Hallo retroniker,
wenn du mit der NKC gcc Umgebung von Andi arbeitest ist es das "Einfachste" den build process über Make zu steuern. In den Beispielen von Andi sind Makefiles dabei die du einfach mit 'make' ausführst, 'make clean' ist ab und zu hilfreich wenn es irgendwo klemmnt, nachdem du viele Änderungen in verschiedenen files gemacht hast.

Hier ein paar Hinweise zum obigen Beispiel:

Dein Beispiel compiliert nicht wegen des "printf", loesch' die komplette Zeile mal raus und es wird duchlaufen und ein sehr kompaktes .m68 executable erzeugen. Genau so wollte ich es damals haben, mit 0 overhead weil ich daran interessiert war zu verstehen wie aus C -> Assembler wird. Das war sehr interessant, dazu habe ich auch meistens ohne Optimierung compiliert. Das war sehr interessant für die mehr komplizierten Sachen in C wie Function pointer was im Assembler code dann total trivial ist. Das .ass und .mem file sind genau aus diesem Grund erzeugt, schau mal rein dies sind text files.

In meiner m68k-elf-gcc Zeile ist so ziemlich alles ausgeschaltet was ich finden konnte auszuschalten, ich wollte das gcc etwas erzeugt was meinen manuellen Assembler entspricht, dh so das ich es noch einfach nachvollziehen kann.

Ich habe den gcc also bewusst ohne die Standard libraries verwenden wollen, also ohne #include<stdio.h> usw.


Zu deinem Schritt 1 - das umbenennen von .o nach .s19 macht keinen Sinn, .o und .s19 googeln...

Zu deinem Schritt 2 - ich habe m68k-elf-strip verwendet um jeglichen gcc overhead rauszuschmeißen, falls ein elf header mit im executable ist.

Das .m68 executable hat nur 4 bytes, wenn du das return(0); weglässt evtl. nur 2 bytes*, so kann man anfangen langsam mehr und mehr auszuprobieren und schauen wie das unter der Haube funktioniert. All die files die gcc dazu erzeugt sind dazu sehr hilfreich aber alle natürlich optional.

Zusammenfassung: Als akademisches 'bare metal' Lernsystem ist mein obiger m68k-elf-gcc Aufruf genau richtig. Der erzeugte Assemblercode lässt sich gut nachvollziehen und auf dem NKC zB im Einzelschrittmodus ausführen. Das komplette NKC SpaceInvaders Spiel ist so entstanden.

Wenn du die Standard Libraries verwenden willst würde ich auf die makefiles in Andi's Umgebung verweisen, das wird dann etwas kryptischer, aber natürlich alles machbar. Die executabels haben dann auch vernünftigen start-up code, und ein Speicher Management so dass malloc() funktioniert; der C Datentyp float, etc wird dann auch ungestützt.

*void main() {} kompiliert zu 2 bytes: 4E75 RTS



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 und eine FPGA-GDP.

NKC - OpenSource since 1983

Hallo,
ich lese sehr aufmerksam mit, da ich am Betrieb unter Linux (Debian) immer noch sehr interessiert bin. Derzeit lerne ich C unter Win10 mit MSYS2. Ich habe mir für meine verschiedenen Übungen auch den Makefile im jeweiligen Projektverzeichnis entsprechend angepasst. Für den Transfer verwende ich dl.py und rs232d. Und ja, ich freue mich auf eine Installationsbeschreibung mit den Quellen, damit ich umziehen kann.
VG Jürgen

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

Hallo smed,
... und wieder viel gelernt von Dir
Vielen Dank für die Erklärungen
Ich bin halt zuweit weg von der ganzen Materie ...

Ergebnis: ich habe ein executable, das auf dem NKC läuft und ohne Fehler oder Absturz beendet wird - soweit alles gut.

Deine Anweisungen stimmen 100%ig. Schon nach dem ersten Schritt entsteht eine a.out die als binary erkennbar ist.

.... aber es wird halt auch nix mehr ausgebeben.
Warum funktioniert
printf("xxx");
nicht?

... läuft das mit "puts"

Schöne Grüße
Daniel

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

Hallo Daniel,
da hab ich was von Andi gelernt. Die Ausgaben sind gepuffert. Probier mal ?xxx\n?. ( Fragezeichen sind doppelte Hochkomma, bei mir am iPad kommen immer diese Fragezeichen, weil der Ascii nicht stimmt.)
Das ist mir au so gegangen, weil ich nach der Ausgabe keinen Linefeed wollte.
Oder Du setzt im main an den Anfang

setbuf(stdout,NULL);
setbuf(stdin,NULL);

um den Buffer auf Null zu setzen. Gelesen habe ich, dass der Buffer bis 4096 Zeichen lang sein kann, je nach System.

VG Jürgen

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

Hallo redo,
diesen BackSlash hatte ich ja oben schon ... also:

#include<stdio.h>
int main() {
printf("Hallo NKC\n");
return 0;
}

Das isses wohl nicht.

Auch wenn ich:

setbuf(stdout,NULL);
setbuf(stdin,NULL);

bringt das leider nix ... aber das wird schon noch

Wenn ich's schaffe poste ich heute Abend mal, wie ich das aufgesetzt habe - also woher ich das abgekupfert habe

Ich habe hier ein Linux Mint - also im Grunde auch ein Debian

Schöne Grüße
Daniel

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

Hallo,
der Grund warum printf() nicht funktioniert ist, das mit meinem einfachen gcc Aufruf nicht die notwendigen Parameter zum linken mit den C Standard Libraries und den entsprechenden NKC Adaptern übergeben werden.

Checke mal dein Makefile. Bei mir funktiniert dies hier, um HelloW.c in ein NKC executable zu verwandeln*. Das ist dann auch gleich 50kB gross, man hat aber eben die Vorteile der C Standard Libraries wenn man gcc richtig ansteuert* mit all den Parametern fuer Kompilierung und Linken, das macht man dann mit einem Makefile und Make. Das Makefile unten ist eine angepasste Version von Andis Beispielen (und ist weitgehend selbsterklärend ;-) Ich mag keine Makefiles daher beschäftige ich mich nur sehr widerwillig damit, hab schon genug graue Haare.

*d.h. unter der Annahme das gcc korrekt, nach Andis Angaben installiert ist, bzw äquivalent in einem Linux Umfeld

HelloW.c
Makefile

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 und eine FPGA-GDP.

NKC - OpenSource since 1983

Hallo smed,
.. prima!

Okay, dann mach ich mich mal ans anpassen des makefile ... sind ja überall .exe drin

Danke und Grüße

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

falls deine shell kein size command kennt, kannst du das im Makefile leer lassen, also:

Zeile 33 SIZE=$(DEVC_PREFIX)

und

Zeile 71 all:: createdirs $(PROGS) create_bin

kürzen. Viel Glück

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

Hallo,
jetzt muss ich aber mal was posten, denn ich hab' da oben Unsinn geschrieben zu den Quellen (kentosama) - ich editiere das gleich mal. Ich hab's offenbar nicht mehr richtig zusammen bekommen, wie ich das "zusammengeschraubt" habe. Ich habe es heute noch einmal neu gemacht und kann nun gesichert schreiben, wo ich den cross-compiler für ubuntu (Linux-Mint) her habe.
Eine Datei - wie oben von smed beschrieben - wird prima compiliert. Sobald ich aber ein "Example" von andi nehme gibt es Probleme - doch dazu nachher mehr.

Also zu den Quellen und dem Vorgehen:
1. https://github.com/ddraig68k/m68k-elf-toolchain

2. sudo apt install make git gcc g++ lhasa libgmp-dev libmpfr-dev libmpc-dev flex gettext bison texinfo
(falls "textinfo" Probleme macht, einfach weg lassen)

3. git clone https://github.com/SteveMoody73/m68k-elf-toolchain
cd m68k-elf-toolchain
make update

4. makefile so anpassen, dass nicht in /opt installiert wird - sondern einen Ordner im lokalen Verz. bereitstellen

5. make all
(ohne sudo!)
der install-prozess dauert sehr lange

6. delta von andi hineinkopieren - in die versch. Ordner
(die Datei FPGATimer.h umbenennen in fpgatimer.h ... weil sie sonst nicht erkannt wird)

7. in /opt kopieren mit ...
sudo cp -R m68k-toolchain /opt

8. in die Path aufnehmen mit ...
echo export PATH="${PATH}:/opt/m68k-toolchain/bin" >> ~/.bashrc
source ~/.bash_profile

Mit dem damit entstehenden m68k-elf-gcc kommt man unter ubuntu nach der Art wie sie ganz am Anfang von smed beschrieben wurde klar.
Ich poste das eigentlich nur, weil sich auch redo dafür interessiert hat - vielleicht hat es ja noch jemanden.

... zu meinen Problemen damit, komme ich gleich noch.

Schöne Grüße

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

Hallo retroniker,
vielen Dank,dass Du da an mich denkst. Ja, ich werde das ausprobieren.
VG Jürgen

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

Hallo Andi, hallo Alle,
ich kämpfe hier mit einer Schwierigkeit beim kompilieren/assemblieren mit dem m68k C-Crosscompiler:

Ich bekomme solche Fehlermeldungen im Makefile:
C:\msys64\tmp\ccJvUeu4.s:4794: Error: operands mismatch -- statement `moveb %a6,%d0' ignored
C:\msys64\tmp\ccJvUeu4.s:4862: Error: operands mismatch -- statement `moveb %a4,%d2' ignored
C:\msys64\tmp\ccJvUeu4.s:4892: Error: operands mismatch -- statement `moveb %a6,%d0' ignored


Ich kann die provozieren mit solchen Aufrufen im C-Code:

//SetCursorxy(x1,y1);
//printf("%s",&c);
//WriteScreenxy(x1,y1,&c);

Je nachdem, welche der Zeilen ich verfügbar mache, bekomme ich die obigen Fehler (gfs. auch mit anderen Assembleradressen)

Alle x1, y1 sind uint8_t für einen Wertebereich von x = 0...79 und y = 0...23 (Spalten und Zeilen am Monitor)
SetCursorxy und WriteScreenxy erwarten für x und y ebenfalls uint8_t.

x1 un y1 werden innerhalb der Funktionen berechnet. Alle beteiligten Variablen sind uint8_t oder werden in der Berechnung dahin gecasted. Z.B.

size_t laenge;
laenge = strlen(p_str);
//printf("Laenge String: %d\n",laenge);
x1 = x0 + (uint8_t)laenge + 1;
y1 = y0;

Absolute Zahlenwerte funktionieren: z.B. SetCursorxy(12,12)

An anderer Stelle im Quellcode werden die Aufrufe anstandslos durchgeführt (also entweder absolute Werte oder auch Variablen).

Im Header sind die beiden Funktionen so deklariert:

static inline __attribute__((always_inline)) void WriteScreenxy(uint8_t x, uint8_t y,const char* const p_str)
{
// Koordinaten umrechnen für Texteingabe mit Format Zeile 0 - 23 von Ursprung oben links
y = abs(y-24)+1;
for(uint8_t page=0u;page<2u; page++) {
// Text schreiben auf Seite 0 und 1 (wegen blinkendem Cursor)
gp_newpage(page,0u);
gp_writexy(CCNV_X(x),CCNV_Y(y),0x11, p_str);
}
}

static inline __attribute__((always_inline)) void SetCursorxy(uint8_t x, uint8_t y)
{
gp_setcurxy(x,y);
}


Was muss ich da beachten oder wo könnte der Fehler liegen?
Danke im voraus für eure Hilfe....
VG Jürgen

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

Compilier mal ohne -O5, also diese Compileroption weglassen oder -O4, -O3 oder -Os

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

Hallo,
schick mir dein .c (bzw. projekt gezippt) file wo das Problem auftritt damit ich das Problem reproduzieren kann.

Lg,
Andi

Hallo,
ich denke ich hab's gefunden.
Tausche die Funktion gp_setcurxy in nkc.h durch folgende aus:

static inline __attribute__((always_inline)) void static inline __attribute__((always_inline)) void gp_setcurxy(const uint8_t x,const uint8_t y) {
asm volatile(
"# asm" "\n\t" \
"moveb %1,%%d1" "\n\t" \
"moveb %2,%%d2" "\n\t" \
"moveq %0,%%d7" "\n\t" \
"movem.l %%a5-%%a6,-(%%sp)" "\n\t" \
"trap #1" "\n\t" \
"movem.l (%%sp)+, %%a5-%%a6" "\n\t" \
: /* outputs */ \
: "g"(_SETCURXY), "d"(x),"d"(y) /* inputs */ \
: "%d1", "%d2", "%d7" /* clobbered regs */ \
);
}

Danach sollte der Fehler von oben weg sein.