Retro Fieber: Z80 oder 68000 ?

Terminal-Programme unterstützen üblicherweise die ANSI 
Terminalemulation, die sich aus der Definition der DEC VT100 Terminals 
ableitet. Also mit Backspace/DEL, Cursorsteuerung etc.

Das wird sowas wie <ESC>[D gewesen sein. Das was deine Linux-Konsole 
sowieso schon liefert. Probier mal
  cat >1
  od -c 1

http://www.termsys.demon.co.uk/vtansi.htm
http://en.wikipedia.org/wiki/ANSI_escape_code

Christian J. schrieb:
> Ich möchte den Monitor doch schon noch etwas ausbauen und habe mir auch
> den Tiny Basic Interpreter besorgt für den AVR, der sich sicherlich
> anpassen lassen wird.

Sorry, ich habe das Szenario um Z80, AVR und Minicom noch nicht ganz 
verstanden.

Was hat der AVR mit dem Z80 zu tun? Soll der AVR mit dem PC 
kommunizieren und von dort via Terminal-Emulation Befehle entgegennehmen 
und diese dann an den Z80 weitergeben?

Ich habe da mal eine Art Mini-Curses für den AVR geschrieben, siehe 
MCURSES. Mit Hilfe dieser Lib werden über ein paar Dutzend 
Funktions-/Cursor- und andere Tasten "verstanden". Ausserdem kann man 
damit das Terminal (und den Cursor) gezielt, ansteuern, Positionen 
setzen, Scrollen (vorwärts und rückwärts), Attribute setzen usw. - halt 
alles, was ein VT102, VT200, VT320 oder VT400 so "versteht".

EDIT:
Im dazugehörenden Thread Beitrag "MCURSES - Mini Curses Bibliothek für Mikrocontroller" 
steht auch etwas zur Zusammenarbeit mit minicom, insb. was die 
Hardware-Flow-Control Problematik betrifft.

Christian J. schrieb:
> Da C
> portierbar ist brauhce ich nur die I/O Routinen umzuleiten und da keine
> Hardware benötigt wird müsste das auf dem Z80 auch laufen.

Nunja, bedingt mag das funktionieren.

> Das mit den Esc Sequencen habe ich grad gelesen, der Stndard hat sich
> wohl auch mehrfach geändert seit den XT tastaturen.

Das hat weniger mit den XT-Tastaturen eines PCs, sondern eher mit der 
Entwicklung des Terminal-Standards VT100->VT102->VT200->VT320->VT400 zu 
tun. DAS waren die Terminals der 80er! Mit PC-Tastaturen hatten die 
herzlich wenig zu tun. Damals gabe es für PCs auch schon einige wenige 
Terminal-Emulationen, welche die oben genannten Standards auch (mehr 
schlecht als recht) emulieren konnten. Jedoch mussten immer wieder 
Abstriche gemacht werden wegen des doch sehr abweichenden 
Tastatur-Layouts (z.B. Anordnung/Funktion der 6 EDIT-Tasten oberhalb der 
Cursor-Tasten, Keypad-Tasten PF1 bis PF4, VT200-Funktionstasten F6 bis 
F22).

> Schwierig, dann
> müsste ich  zeichenweise durch die Eingabe durch und nicht mehr einfach
> bis zum ersten Leerzeichen.

Das erledigt MCURSES für Dich. Es interpretiert die von der Tastatur 
gesandten ESCAPE-Sequenzen und setzt diese in eine Konstante um, z.B. 
KEY_DOWN.

Beispiel (kleiner Zeileneditor):

1

     uint8_t ch = getch ();

2

3

     switch (ch)

4

     {

5

          case 'a':       show_address(); break;

6

          case 'v':       show_value(); break;

7

          case KEY_LEFT:  go_left(); break;

8

          case KEY_RIGHT: go_right(); break;

9

          case KEY_UP:    show_last_line(); break;

10

          case KEY_DOWN:  show_next_line(); break;

11

     }

Du erhältst also nicht nur einzelne aphanumerische Zeichen, sondern auch 
direkt feste Codes für Funktionstasten. Um die Decodierung der 
Escape-Sequenzen brauchst Du Dich nicht mehr zu kümmern - das erledigt 
MCURSES für Dich.

> Frank, ich schaue mir das mal an... muss erstmal einen Überblick
> kriegen.

MCURSES läuft nicht nur auf AVRs, sondern auch auf auf UNIX/Linux. 
Der Source ist modular auf Portabilität für andere Plattformen 
ausgelegt. Wenn Du das I/O-Interface anpasst (siehe phyio-Funktionen), 
sollte es auch auf einem Z80 laufen, da es auf minimalen 
Ressourcen-Verbrauch getrimmt wurde.

> Aktuell gehts nur darum:
>
> Z80 nimmt zeichenweise entgegen uns echot das so, dass man wie an einem
> normalen Terminal arbeitet. EOL (CR) sendet den String ab. Bewegt der
> User die Pfeiltasten muss natürlich der Zeichenpointer auch verschoben
> werden. Im Buffer soll immer das stehen, was auch in der sichtbare Zeile
> steht.

Ist mit MCURSES problemlos machbar. Und noch einiges mehr. Du musst 
es "nur" auf den Z80 portieren.

Hier noch ein kleines Demo-Programm als Filmchen:

  http://www.mikrocontroller.net/wikifiles/e/ed/Mcurses.avi

Christian J. schrieb:
> Wo kann ich in diesem Prinzip jetzt Deine Routinen einbauen?

Das passt schon alles.

Du passt in mcurses.c die phyio-Funktionen unter Einsatz von putchar() 
und getchar() an und benutzt dann in Deiner Anwendung:

  addch()    statt    putchar()
  getch()    statt    getchar()
  addstr()   statt    puts()
  move()     zum Bewegen des Cursors
  attrset()  Zum Setzen von Attributen, wie Reverse, Farbe usw.

Ein simples Beispiel:

1

#include "mcurses.h"

2

3

int main ()

4

{

5

    unsigned char ch;

6

7

    initscr();        // init mcurses

8

9

    move (11, 10);    // Cursor an Stelle y=11, x=10 setzen

10

    addstr ("Hello, World!");

11

12

    while ((ch == getch()) != KEY_DOWN)  // Warten, bis Cursor runter gedrückt wird

13

    {

14

        ;

15

    }

16

17

    endwin();         // end mcurses

18

    return 0;

19

}

Vielleicht mögen Dir solche Funktionsnamen wie initscr() und endwin() 
merkwürdig vorkommen. Ich persönlich hätte sie lieber anders genannt. 
Sie sind aber an die (n)curses-LIB von BSD, SYSV-UNIX bzw. Linux aus den 
80er/90er angelehnt, siehe auch:

   http://de.wikipedia.org/wiki/Curses

So findet sich so manch ein UNIX-Programmierer hier leichter wieder ;-)

P.S.
Das auf Wikipedia aufgeführte Beispiel-Programm benutzt printw() statt 
addstr(). printw() ist für die formatierte Ausgabe gedacht - analog zu 
printf(), ist aber wg. knapper Ressourcen auf dem µC nicht umgesetzt.

Wikipedia hätte hier besser auch addstr() im Beispiel-Programm benutzen 
sollen, da von der Formatierungs-Fähigkeit von printw() im Beispiel 
überhaupt kein Gebrauch gemacht wird.

Christian J. schrieb:
> Im Puffer soll exakt das stehen, was der User am Terminal eingetippt
> hat. Und wenn er sich 10 Mal vertippt hat und es korrigiert hat, soll
> die Endversion drin stehen aber keinerlei Sonderzeichen.

Nein, diese Funktionalität ist nicht umgesetzt (sie entspricht eher der 
readline-Bibliothek von Linux), ist aber auch nicht schwierig zu 
programmieren.

Was Du möchtest, ist ein Ein-Zeilen-Mini-Editor. Du übergibst einen 
Buffer und bekommst den gefüllt wieder zurück - also etwas entsprechend 
der stdio-Funktion gets(). Den Mini-Editor dafür hab ich ruckzuck 
zusammengestellt. Ich poste hier heute nachmittag den entsprechenden 
Code bzw. lege den direkt im MCURSES-Artikel ab.

So, die Funktion getnstr() ist fertig. Auch sie ist angelehnt an die 
entsprechende Curses-Funktion, siehe auch:

  http://linux.die.net/man/3/getstr

Syntax:

  void getnstr (char * str, uint8_t maxlen)

Einlesen eines Strings str, bis CR (ENTER) gedrückt wird - mit 
Editierfunktionen.

maxlen ist dabei die maximale Eingabelänge inklusive(!) des 
terminierenden '\0'. Will man also maximal 80 Zeichen Input haben, muss 
der Buffer als buf[81] definiert sein und maxlen == 81 sein - analog zur 
stdio-Funktion fgets().

Weiteres Makro (kommt dann nach mcurses.h):

  void mvgetnstr (uint8_t y, uint8_t x, char * str, uint8_t maxlen)

Hier wird erst der Cursor positioniert, dann geschieht die Eingabe.

Beispiel:

1

#include "mcurses.h"

2

3

int

4

main ()

5

{

6

    char    buf[81];

7

8

    initscr ();                  // init mcurses

9

    move (10, 10);               // Eingabe in Zeile 11, Pos 11

10

    getnstr (buf, 81);           // String einlesen

11

    mvaddstr (15, 10, buf);      // Eingabe in Zeile 16 wieder ausgeben

12

    endwin ();                   // end mcurses

13

}

Mit folgende Sondertasten kann die Eingabe editiert werden:

  Pos1          - KEY_HOME:      Sprung an den Anfang des Eingabebuffers
  Ende          - KEY_END:       Sprung an das Ende des Eingabebuffers
  Cursor links  - KEY_LEFT:      Cursor links
  Cursor rechts - KEY_RIGTH:     Cursor rechts
  Backspace     - KEY_BACKSPACE: Zeichen links vom Cursor löschen
  Entf          - KEY_DC:        Zeichen unter dem Cursor löschen

Reicht Dir das? Für Einfüge-/Überschreibenmodus habe ich jetzt keine 
Lust gehabt. Eingegebene Zeichen werden daher immer eingefügt.

Die Funktion getnstr() hängt im Anhang an - schon mal zum Anschauen. Ich 
werde die Download-Datei mcurses.zip im Laufe des heutigen Tages 
aktualisieren.

Christian J. schrieb:
>  * PHYIO: set/reset nodelay
>  * PHYIO: flush output

Schau Dir besser die AVR-Version der phyio-Funktionen an und passe diese 
dann an. Du hast hier nämlich die Linux-/Unix-Versionen gepostet. Diese 
erscheinen für einen Nicht-Unixer erstmal wesentlich komplexer.

mcurses.c ist da folgendermaßen aufgebaut:

1

#ifdef unix                 // UNIX-/Linux-Version

2

3

 * PHYIO: init

4

 * PHYIO: done

5

 * PHYIO: putc

6

 * PHYIO: getc

7

 * PHYIO: set/reset nodelay

8

 * PHYIO: flush output

9

10

#else                       // AVR-version

11

 (Wiederholung der phyio-Funktionen fuer AVR)

12

#endif

13

14

(Rest ist plattformunabhaengig)

Du solltest das jetzt folgendermaßen erweitern:

1

#ifdef unix                          // UNIX-/Linux-Version

2

 (Unix-phyio-Funktionen)

3

#elif defined (DEIN_Z80_KRITERIUM)   // Z80 Version

4

 (Z80-phyio-Funktionen)

5

#else                                // AVR-version

6

 (AVR-phyio-Funktionen)

7

#endif

8

(Rest ist plattformunabhaengig)

Dafür kopierst Du Dir am besten die AVR-phyio-Funktionen und passt diese 
an. Sollte Deine Portierung dann erfolgreich sein, kann ich die neue 
mcurses-LIB, welche auch den Z80 unterstützt, gerne wieder zum Artikel 
als Download beifügen.

Christian J. schrieb:
> Mundgerechter gehts doch nicht ! :-) Dank dir ganz herzlich, wird heute
> umgesetzt !

Die neue Version ist online, siehe MCURSES.

Solltest Du Fragen/Anregungen/Probleme bei der Portierung haben, 
empfehle ich dafür den Thread:

  Beitrag "MCURSES - Mini Curses Bibliothek für Mikrocontroller"

Denn hier wirds allmählich offtopic.... ;-)

Christian J. schrieb:
> Weil der Entwicklungsleiter nichts anderes konnte und Angst hatte
> von einem Jüngeren "überflügelt" zu werden.

Das ist kein µC-Buden spezifisches Problem und einer der häufigsten 
Hintergründe von Mobbing, sogar in Sozialberufen. Die Ursache dafür ist 
im ehemals satten Arbeitskräftemarkt zu suchen, nachdem es möglich 
wurde. (langjärige) Mitarbeiter nicht mehr weiterzuqualifizieren sondern 
durch jüngere scheinbar qualifiziertere Mitarbeiter nach dem Hire & Fire 
Prinzip zu ersetzen.
.....

Namaste

Christian J. schrieb:
> ich habe deinen code erstmal beiseite gelegt, da mir der kopf raucht und
> ich alles durcheinander werfe.

Ja, merkt man.

> da muss sehr viel geändert werden, da der
> Z80 ja eine CPU ist, alles andere ist individuell.

Nein, da muss gar nicht viel geändert werden.

> Und ich brauche auch
> nur eine Sache, nämlich getch. Du holst Zeichen im Interrupt, ich
> aktuell noch per Hand.

Das spielt überhaupt keine Rolle, wie die Zeichen geholt werden.

Du musst nur die phyio-Funktionen anpassen, mehr nicht. Aber das sagte 
ich ja bereits.

Hier eine Minimalversion:

1

/*---------------------------------------------------------------------------------------------------------------------------------------------------

2

 * PHYIO: init

3

 *---------------------------------------------------------------------------------------------------------------------------------------------------

4

 */

5

static void

6

mcurses_phyio_init (void)

7

{

8

  // Deine UART Initialisierung, falls notwendig.

9

}

10

11

/*---------------------------------------------------------------------------------------------------------------------------------------------------

12

 * PHYIO: done

13

 *---------------------------------------------------------------------------------------------------------------------------------------------------

14

 */

15

static void

16

mcurses_phyio_done (void)

17

{

18

  // Kann leer bleiben.

19

}

20

21

/*---------------------------------------------------------------------------------------------------------------------------------------------------

22

 * PHYIO: putc

23

 *---------------------------------------------------------------------------------------------------------------------------------------------------

24

 */

25

static void

26

mcurses_phyio_putc (uint8_t ch)

27

{

28

    putchar (ch);

29

}

30

31

/*---------------------------------------------------------------------------------------------------------------------------------------------------

32

 * PHYIO: getc

33

 *---------------------------------------------------------------------------------------------------------------------------------------------------

34

 */

35

static uint8_t

36

mcurses_phyio_getc (void)

37

{

38

    uint8_t ch;

39

40

    ch = getchar ();

41

42

    return (ch);

43

}

44

45

/*---------------------------------------------------------------------------------------------------------------------------------------------------

46

 * PHYIO: set/reset nodelay

47

 *---------------------------------------------------------------------------------------------------------------------------------------------------

48

 */

49

static void

50

mcurses_phyio_nodelay (uint8_t flag)

51

{

52

  // kannst Du erstmal leer lassen, für Dich nicht relevant

53

}

54

55

/*---------------------------------------------------------------------------------------------------------------------------------------------------

56

 * PHYIO: flush output

57

 *---------------------------------------------------------------------------------------------------------------------------------------------------

58

 */

59

static void

60

mcurses_phyio_flush_output ()

61

{

62

  // leer lassen

63

}

> Trotzdem steige ich noch nicht hinter das Prinzip, habe alles erstmal
> bei mir gelöscht und auf wenige Zeilen reduziert um mit diesem minicom
> klar zu kommen. gets sendet echos und macht es "richtig" aber getchar
> nicht, da muss ich alles per hand machen.

mcurses benutzt für die Plattformunabhängigkeit ein 
Mini-Schichtenmodell:

    - Unabhängige Funktionen wie getch() und addch() usw.
    - Plattformabhängige PHYIO-Funktionen wie getchar(), putchar

Alles einfach rauszuschmeissen, was Du nicht verstehst, ist der komplett 
falsche Weg. Offenbar hast Du Probleme, systematisch eine Aufgabe zu 
lösen.

>
>     do
>     {
>      ch = getchar();
>      putchar(ch);
>     } while (ch!=0x0d);
>     printf("\r\nFertig");

Genau das macht macht getnstr() - nur auf der mcurses-Ebene und nicht 
auf der Low-Level-PHYIO-Ebene. Auf der Low-Level-Ebene bist Du verratzt 
und verkauft, wenn man Cursor-Tasten etc. drückt. Das klappt nicht!

> Man sollte annehmen, dass ich dann genau das sehe was ich tippe aber da
> fängt es schon an. Backspace löscht keine Zeichen sondern ist wie Cursor
> verschieben. Pfeiltasten laufen hoch und runter im Terminal: ok. Up und
> Down muss ich eh unterbinden bei einem Einzeilen Editor.

Ist doch klar: Die Sondertasten senden ESCAPE-Sequenzen, die Du nicht 
auswertest, sondern einfach in Deinem Buffer abspeicherst. Das klappt 
nicht!

Entweder Du machst es richtig oder Du lässt es. Wenn Du alles 
rausschmeisst, was Du nicht verstehst, ist das alles zum Scheitern 
verurteilt. Also bohre - so wie gestern skizziert - die Struktur auf:

#ifdef unix
#elif defined (DEIN_Z80_KRITERIUM)
#else // AVR
#endif

und knalle da einfach die PHYIO-Routinen, die ich oben aufgeführt habe, 
in den Z80-Bereich! Was ist da so schwierig? Ich habe irgendwie das 
Gefühl, dass Du mal gerne Hinweise anderer ignorierst und Dich dabei 
dann in einer Sackgasse verrennst. Ja, ich kenne den SDCC-Thread.

Dann musst Du oben in mcurses.c noch dort, wo die plattformabhängigen 
includes geschehen, noch die Z80-Anpassungen machen:

1

#ifdef unix

2

#include <termio.h>

3

#include <fcntl.h>

4

#define PROGMEM

5

#define PSTR(x)                                 (x)

6

#define pgm_read_byte(s)                        (*s)

7

#elif defined (DEIN_Z80_KRITERIUM)                        // NEU

8

#define PROGMEM                                           // NEU

9

#define PSTR(x)                                 (x)       // NEU

10

#define pgm_read_byte(s)                        (*s)      // NEU

11

#else

12

#include <avr/io.h>

13

#include <avr/pgmspace.h>

14

#include <avr/interrupt.h>

15

#endif

> Lese ich Pfeiltaste als hex aus erhalte ich immmer 0x1b 0x51 als Code,
> egal welche ich tippe. Wieviel Bytes sind das überhaupt? 2 oder 3? Pos1
> und Ende erzeugen "F"'s. Kann aber sein, dass zeichen verschluckt werden
> bei mir, printf ist schon sehr zeitintensiv.

Google nach "vt100 escape" und Du wirst jede Menge Listen finden, wo die 
Tasten erklärt sind. Aber ich glaube nicht, dass Du in der Lage bist, 
Dein Problem auf dieser unteren Ebene zu lösen. Deshalb habe ich Dir 
mcurses angeboten. Für die Entwicklung eines Monitors musst Du sowieso 
auf dem Bildschirm frei positionieren können. Ich rate Dir daher, 
sämtliche Benutzer-Interaktionen mit mcurses zu machen - nicht nur die 
Kommando-Eingabe.

> Bevor ich da nicht durch die Grundlagen durchsteige unddie
> Zeicheneingabe auf einen Interrupt lege in einen Puffer hat es keinen
> Zweck da weiter zu machen. Das gibt Murks.

Du musst überhaupt keinen Interrupt einbauen! Ich habe Dir gestern schon 
gesagt, dass Du putchar() und getchart() in die Phyio-Funktionen 
einbauen musst - mehr nicht! Höre doch einfach mal zu!

Du brauchst die untere Ebene und die Escape-Sequenzen gar nicht zu 
kennen, wenn Du mcurses nutzt! Lass den mcurses-Source im Ganzen stehen! 
Wirf nichts raus, sondern erweitere den Source! Nur so kann ein 
Software-Paket wachsen. Ein Paket zu schnappen und dann rigoros 
abzuspecken ("ich brauche nur getch()!") ist der falsche Weg, denn damit 
löst sich alles in Luft auf und es bleibt nichts lauffähiges übrig.

Und jetzt am Ende noch 3 Bitten:

 - Lies dieses Posting 3 mal
 - Lies dieses Posting 3 mal
 - Lies dieses Posting 3 mal

Christian J. schrieb:
> ich habe deinen code erstmal beiseite gelegt, da mir der kopf raucht und
> ich alles durcheinander werfe.

So, ich habs nicht mehr ausgehalten ("das kann doch nicht so schwer 
sein!") und habe mir mal den SDCC installiert, die oben aufgeführten 
Änderungen eingebaut, noch hier und da eine kleine Änderung/Optimierung 
(include-Tausch, Mini-itoa-Ersatz geschrieben, um sprintf-Aufruf 
einzusparen) und dann durch den SDCC gejagt.

Die Übersetzung von mcurses.c funktioniert nun. Aufwand meinerseits zur 
Code-Anpassung: 10 Minuten.

Ich habe das mcurses-Paket (s. Download im Artikel MCURSES) mit der 
neuen Version 2.0.0 hochgeladen. Die Änderungen erkennst Du an 
__SDCC_z80 in mcurses.c. Diese Konstante wird automatisch vom SDCC 
gesetzt, wenn man mit -mz80 compiliert.

Jetzt brauchst Du nur noch zu testen, am besten mit diesem main.c:

1

#include "mcurses.h"

2

3

int main ()

4

{

5

    char    buf[40];

6

7

    mvaddstr (9, 10, "Bitte eine Zeichenkette eingeben:");

8

    mvgetnstr (10, 10, buf, 40);              // Einlesen eines String mit 79 Zeichen + '\0'

9

    mvaddstr (11, 10, buf);                   // Ausgabe des Strings eine Zeile darunter

10

    return 0;

11

}

Christian J. schrieb:
> ist schon deutlich klarer

Hast Du auch meinen Beitrag von 10:53 Uhr gelesen? Ich habe mcurses.c 
bereits auf SDCC portiert, Du kannst Dir mcurses.zip daher nochmal 
runterladen. Viel Spaß!

Christian J. schrieb:

> Es kompiliert auf dem Cubie Truck fehlerfrei durch, grad ausprobiert,
> bzw nur die Warnungen wegen der crt0.s, die ich noch anpassen muss, weil
> da die .globl definiert werden wollen. 2046 Bytes Code.

Prima.

> itoa ist auf dem sdcc verfügbar, allerdings etwas speicherfressend.

Dann lass es so, wie es ist. Da es sich um maximal dreistellige 
Dezimalzahlen handelt (für die Cursor-Positionierung), habe ich das ganz 
nativ in C in 10 Zeilen gelöst - siehe Funktion mcurses_puti().

> Dumme Frage: Das Schlüsselwort "unix" vorne, wo wird das definiert?

Das wird definiert, wenn man einen C-Code für ein Unix-/Linux-System 
compiliert. Da Du für einen Z80 compilierst, ist "unix" NICHT definiert. 
Es geht also hier immer um das Zielsystem!

Der SDCC setzt automatisch __SDCC_z80.

Deshalb findest Du in mcurses.c nun vor:

1

#if defined(unix)

2

   mache Unix-spezifischen Code

3

#elif defined(__SDCC_z80)

4

   mache Z80-spezifischen Code

5

#else // AVR

6

   mache AVR-spezifischen Code

7

#endif

Die plattformabhängigen Teile sind also komplett voneinander getrennt. 
Die nicht zutreffenden Teile werden NICHT compiliert, sondern komplett 
ignoriert.

> Vom system her oder dem GCC?

Der gcc (aber auch jeder andere C-Compiler) setzt das, wenn das 
Zielsystem ein Unix ist. Das ist schon seit 1969 so, da gab es noch 
keinen gcc.

Wenn das Zielsystem aber ein AVR ist, ist unix NICHT gesetzt. Ebenso 
nicht beim SDCC, wenn -mz80 für das Zielsystem angegeben ist.

> Preprozessor Sachen habe ich bisher wenig gemacht.

Hm, eine vom Compiler definierte Konstante abzufragen gehört aber zum 
Basis-Wissen. Hast Du mal in SDCC-Manual geschaut? Da wird genau 
erklärt, für welches Zielsystem der SDCC was setzt.

> Uart u.a. Init sieht übrigens so aus, das ist bei jedem anders, je
> nachdem welche Chipse man nimmt

Okay, du musst das Uart-Init ja nicht in initscr() machen, sondern 
kannst das aufrufen, wo und wann Du willst. Aber mindestens vor 
initscr(), damit mcurses mit einem vollständig initialisiertem UART 
loslegen kann.

Na also, geht doch :-)

Wie schon erwähnt:

Ich würde Dir raten, das komplette Benutzerinterface Deiner Anwendung 
über mcurses abzuwickeln, nicht nur die Eingabe eines Kommandos. Damit 
hast Du eine Menge Komfort gewonnen. Du kannst dann den Bildschirm 
löschen, Deinen Text beliebig positionieren und auch noch mit Attributen 
(Bold, Underline, Vorder- und Hintergrund-Farben etc) versehen.

> Damit nichts doppelt gemoppelt wird: Deine Ringbuffer sind nur für AVR
> bei Verwendung von ISR?

Ja, die sind nur für AVR. Unter Unix-/Linux laufen die Interrupts 
komplett im Betriebssystem selbst, getchar() und putchar() arbeiten 
bereits mit Buffern, ohne dass es der Programmierer überhaupt 
mitbekommt.

> Ich habe die Funktion getchar und putchar einige
> Male gefunden, die ich ja durch meine eigene überschrieben habe.

Du hast also in mcurses.c die putchar() und getchar()-Aufrufe nochmal 
ersetzt? Warum? Okay, Du könntest für Deine eigenen IO-Funktionen 
natürlich auch noch einen Interrupt-gesteuerten Ringbuffer einbauen. 
Aber das ist eine Optimierung, die ich erst machen würde, wenn alle 
anderen Probleme glattgebügelt sind. First make it work, then make it 
fine ;-)

Das einzige, was für mich jetzt noch für eine vollständige Portierung 
auf SDCC (Z80) interessant wäre, ein nicht-blockierendes getchar() 
hinzubekommen. Das dafür zuständige flag kann man ja über die 
mcurses-Funktion nodelay(flag) setzen. Funktioniert auch für Unix-/Linux 
und AVR perfekt. Wenn Du da etwas weisst bzw. einen Tipp hast, würde ich 
diesen noch offentstehenden Teil in mcurses ebenso noch für SDCC 
umsetzen.

Dann wäre für mich alles komplett und rund.

Christian J. schrieb:
>

1

> char getchar()

2

> {

3

>     while ((STI_RSR & 0x80) == 0);

4

>     return(STI_UDR);

5

> }

6

>

Danke, dann ist es einfach. Du musst nur folgende Funktionen ersetzen:

1

/*---------------------------------------------------------------------------------------------------------------------------------------------------

2

 * PHYIO: getc

3

 *---------------------------------------------------------------------------------------------------------------------------------------------------

4

 */

5

static uint8_t

6

mcurses_phyio_getc (void)

7

{

8

    while ((STI_RSR & 0x80) == 0)

9

    {

10

        if (mcurses_nodelay)

11

        {                      // if nodelay set, return ERR

12

            return (ERR);

13

        }

14

    }

15

    return(STI_UDR);

16

}

17

18

/*---------------------------------------------------------------------------------------------------------------------------------------------------

19

 * PHYIO: set/reset nodelay

20

 *---------------------------------------------------------------------------------------------------------------------------------------------------

21

 */

22

static void

23

mcurses_phyio_nodelay (uint8_t flag)

24

{

25

    mcurses_nodelay = flag;

26

}

Die Definition der Variablen z80_nodelay kannst Du dann löschen.

Oder Du baust die Abfrage auf mcurses_nodelay in Deine eigene 
getchar()-Funktion. mcurses_nodelay ist aber im Moment "versteckt", d.h. 
static. Das static müsstest Du dann entfernen, damit Du aus Deinen 
eigenen Routinen drauf zugreifen kannst. Ist aber Geschmackssache. Denn 
eigentlich sind die PHYIO-Funktionen genau für den Hardware-Teil 
gedacht.

Christian J. schrieb:
> Nochmal: Du schlägst also vor, dass ich meine Menüsterung unter Nicht
> Verndung von printf oder meinem Speichersparenden printstrng komplett
> auf mcurses umstelle?

Ja, wäre doch nur eine logische Konsequenz.

> Nur werden dann so Themen wie Scrolling aktut,
> denn ein normales Terminal läuft ja nach oben immer weiter. Bisher sehe
> ich nur absolute Zeichenadressierung in den Funktionen.

Ich weiß nicht, wieviel Output Du da machst. Kannst Du den nicht so 
portionieren, dass immer eine Seite ausgegeben wird? Wie gesagt, die 
Funktionen clear() und clrtobot() existieren :-)

Ausserdem kann mcurses sogenannte Scrolling Regions. Beispiel:

Das Terminal soll nur von den Zeilen 2 bis 22 Scrollen und damit die 
Zeilen 1, 23 und 24 "einfrieren".  Dann kannst Du oben bzw. unten 
Statuszeilen anzeigen (Temperatur, Uhrzeit und was weiß ich), die immer 
an derselben Stelle sein sollen.

dafür gibt es die folgenden mcurses-Funktionen, die Du mal im Artikel 
näher betrachten und ausprobieren solltest:

  - setscrreg() setzt Scrolling-Region

  - deleteln() löscht eine Zeile an der aktuellen Position.
    Darunter liegende Zeilen innerhalb der Scrolling-Region
    rollen damit automatisch hoch!

  - insertln() fügt eine Zeile an der aktuellen Position ein.
    Darunter liegende Zeilen innerhalb der Scrolling-Region
    rollen damit automatisch runter!

  - scroll() rollt die komplette Scrolling-Region hoch.

> Das sieht ja später so aus
>
> menü 1..........
> menü 2..........
> menü 3..........
> menü 4..........
> z80> <usereingabe>

Ja, prima, damit kannst Du dafür sorgen, dass das Menü immer an 
derselben Stelle erscheint. Das wirkt wesentlich professioneller.

Nach der Eingabe machst Du erstmal einen clear(), wenn die Ausgabe 
länger wird. Dann kannst Du oben links innerhalb der Scrolling-Region 
anfangen. Wenn Du rollen willst, dann rufst Du scroll() auf.

Spiel mal ein wenig mit den mcurses-Funktionen rum! Es lohnt sich.

P.S.
Vielleicht hast Du es schon gemerkt: mcurses fängt bei 0 bzgl. Spalten 
und Zeilen zu zählen. Bei 24 Zeilen kannst Du mit setscrreg(0, 23) die 
Scrolling-Region auf den kompletten Bildschirminhalt setzen. Dann rollt 
alles wie gewohnt. Bei setscrreg(0, 22) hast Du unten immer eine 
Statuszeile, die nicht mitrollt, bei setscrreg(1, 23) ist die 
eingefrorene Zeile oben.

Vielleicht willst Du aber auch, dass nur der halbe Bildschirm gerollt 
wird? Dann rufe setscrreg(12, 23)  auf. Dann hast Du oben 12 
feststehende Zeilen fürs Menü etc. und unten rollt die Ausgabe. Du 
könntest damit zum Beispiel auch einen einfachen Hex-Editor bauen...

Christian J. schrieb:
> Letzte Frage: Wie hatst du es geschafft dass getnstr (buf, 40); und
> andere sowohl eine Position als Paramdeter verstehen als auch ohne
> Positionsangabe?

Die Funktion heisst getnstr(char * str, uint8_t maxlen).
Aber es gibt noch ein Makro in mcurses.h:

1

#define mvgetnstr(y,x,s,n)      move((y),(x)), getnstr(s,n)

Es wird also hier erst ein move(), dann getnstr() aufgerufen. Die beiden 
Befehle sind durch Komma getrennt statt Semikolon. Das bewirkt, dass der 
Compiler beides wie einen (geklammerten) Block betrachtet.

Sonst könnte dies Probleme machen:

   if (irgendeine_Bedingung)
      mvgetnstr(....);
   else
      tuewasanderes();

Das else würde der Compiler in den falschen Hals kriegen, wenn oben ein 
Semikolon stünde, da hier nix geklammert ist. (Deshalb klammere ich 
immer alles, auch wenn es nur ein Statement unter einem if ist).

Frank M. schrieb:

1

> #define mvgetnstr(y,x,s,n)      move((y),(x)), getnstr(s,n)

Besser:

1

#define mvgetnstr(y,x,s,n)      do { move((y),(x)); getnstr(s,n); } while (0)

> Das else würde der Compiler in den falschen Hals kriegen, wenn oben ein
> Semikolon stünde, da hier nix geklammert ist.

Dann passiert das nicht.

> (Deshalb klammere ich
> immer alles, auch wenn es nur ein Statement unter einem if ist).

Und die Klammern in diesen Fällen sind wieder reine Geschmacksache.

Leo C. schrieb:
> Besser:
>

1

> #define mvgetnstr(y,x,s,n)      do { move((y),(x)); getnstr(s,n); } 

2

> while (0)

3

>

Ja, ich kenne diese Konstruktion und benutze sie im allgemeinen auch 
gern.

Da aber nicht alle Compiler so schlau auf dieser Welt sind wie gcc, wird 
daraus manchmal auch im Compiler-Output eine echte do-while-Schleife - 
mit dem einzigen Effekt, dass der Code aufgeblasen wird und eine 
unnötige Bedingung getestet wird. Kann der SDCC das genauso gut wie der 
gcc?

> Dann passiert das nicht.

Das passiert mit dem Komma-Operator auch nicht. Auch hier kannst Du dann 
im Code die Klammern gefahrlos weglassen.

> Und die Klammern in diesen Fällen sind wieder reine Geschmacksache.

Eben. Wie gesagt: Der Komma-Operator löst die Aufgabe genauso gut wie 
eine geklammerte do-while-Fake-Schleife.

Zusatz:

Der Komma-Operator hat noch einen Vorteil: Man kann im Macro mit 
return-Werten arbeiten, z.B.

#define mvgetch(y,x)       move(y,x), getch()

Dann kann man schreiben:

  int ch;
  ch = mvgetch(10, 11);

Mit einer do-while-Schleife wäre das nicht lösbar.
(Man muss dazu anmerken, dass beim Komma-Operator, der Return-Wert immer 
derjenige der zuletzt aufgerufenen Funktion ist. Das ist einfach 
praktisch :-) )

Frank M. schrieb:
> Kann der SDCC das genauso gut wie der
> gcc?

Sieht so aus. Hab dein Demo grade in aller Eile durch den Compiler 
gejagt. Hier ein Outputschnipsel:

1

;demo.c:138: mvdelch (3,0);

2

;  genIpush

3

  push  de

4

;fetchPairLong

5

;fetchLitPair

6

  ld  hl,#0x0003

7

  push  hl

8

;  genCall

9

  call  _move

10

  pop  af

11

;  genCall

12

; peephole 44 eleminated dead pop/push pair.

13

  call  _delch

14

;demo.c:139: PAUSE (25);

>> Und die Klammern in diesen Fällen sind wieder reine Geschmacksache.
>
> Eben. Wie gesagt: Der Komma-Operator löst die Aufgabe genauso gut wie
> eine geklammerte do-while-Fake-Schleife.

Mit dem Komma im Makro sind sie zwingend, keine Geschmacksache.

Muss jetzt leider dringend weg. Ich melde mich später in deinem 
MCURSES-Thread wieder.

Leo C. schrieb:
> Mit dem Komma im Makro sind sie zwingend, keine Geschmacksache.

Da irrst Du gewaltig.

Beweis:

1

#include <stdio.h>

2

3

int

4

main ()

5

{

6

    int i = 3;

7

8

    if (i == 3)

9

        printf ("ist drei\n"), printf ("und bleibt drei\n");

10

    else

11

        printf ("ist NICHT drei\n");

12

13

    return 0;

14

}

$ cc a.c && ./a.out
ist drei
und bleibt drei

Frank M. schrieb:
> Da irrst Du gewaltig.

Hast recht, da war ich zu sehr im Zeitdruck. Kommaoperator mag ich an 
der Stelle trotzdem nicht. ;)

Frank M. schrieb:
> Der Komma-Operator hat noch einen Vorteil: Man kann im Macro mit
> return-Werten arbeiten, z.B.
>
> #define mvgetch(y,x)       move(y,x), getch()

Wenns aussieht wie eine Funktion, die einen Wert liefert, sollte es auch 
überall so verwendet werden können. Als Parameter einer Funktion gehts 
aber schief.

Das Beste wäre 'static inline' statt '#define'. Funktioniert auch mit 
sdcc. Allerdings baut er den Funktionskörper der inline-Funktion mit 
ein, obwohl die Funktion selbst nicht aufgerufen wird.

Christian J. schrieb:
> Im Kopf gehen da noch Sachen herum, wie ein 64k E2PROM, in welches der
> RAM Inhalt gespiegelt werden kann, so dass er er sich beim Kaltstart
> wieder reinzieht und ausführt aber Platz habe ich keinen mehr,

Häng einen Akku an dein SRAM, und ein Gatter, das ohne Hauptspannung 
inaktives /CS sicherstellt.

Christian J. schrieb:
> Erweiterbar ist das alles nicht sonderlich. String Parameter müssten
> gesondert behandelt werden aber ein dump 0000 2000 mit der Ausgabe eines
> Hex Editor werde ich noch hinbekommen. In der Ausgabe aber editieren
> wird schon schwieriger. Nötig wäre es aber nicht.

Ein Hex-Editor mit mcurses ist nicht sehr schwierig. Wenn Du nichts 
dagegen hast, kann ich das gerne übernehmen.

Christian J. schrieb:
> I2C über den 8255 ist eine andere
> Sache, müsste aber softwaremaessig gehen, Hi, LO, tri State hat er ja,
> leider aber eben nur einen ganzen Port mit gleicher Richtung, Bits
> wählweise In oder out geht nicht.

Mit der Z80-PIO ginge das.
Aber der STI hat doch auch noch ein paar I/O-Leitungen.

Christian J. schrieb:
> Was können denn andere Monitore so alles? Einen Debugger habe ich ja
> leider nicht, da ich eh in C programmiere und keinen Single Step habe.

1

### Reset reason(s): External.

2

### Setting I2C clock Frequency to 20000 Hz.

3

4

ATMEGA1281+Z8S180 Stamp Monitor

5

6

### main_loop entered: bootdelay=-1

7

8

### main_loop: bootcmd="pin ${pins}; reset; loadf; go ${startaddr}"

9

=> help

10

!cpe       - EEPROM copy

11

!mde       - EEPROM dump

12

!mdr       - RAM dump

13

?          - alias for 'help'

14

base       - print or set address offset

15

cmp        - memory compare

16

connect    - Connect to CPU console i/o

17

cp         - memory copy

18

date       - get/set/reset date & time

19

defaultenv - set all environment variables to their default values

20

echo       - echo args to console

21

go         - start application at address 'addr'

22

help       - print command description/usage

23

loadf      - load srec_cat prepared image from controller flash

24

loop       - infinite loop on address range

25

md         - memory display

26

mm         - memory modify (auto-incrementing address)

27

mstep      - execute one M cycle

28

mw         - memory write (fill)

29

nm         - memory modify (constant address)

30

pin        - Set or query pin state

31

printenv   - print environment variables

32

reset      - Keep CPU in RESET state

33

restart    - Perform RESET of the CPU

34

run        - run commands in an environment variable

35

saveenv    - save environment variables to persistent storage

36

setenv     - set environment variables

37

sleep      - delay execution for some time

38

=> printenv bootcmd

39

bootcmd=pin ${pins}; reset; loadf; go ${startaddr}

40

=> run bootcmd

41

## CPU now in reset state.

42

Loading Z180 memory... 

43

   From: 0x00000 to: 0x001B9    (  442 bytes)

44

   From: 0x001C2 to: 0x02D9E    (11229 bytes)

45

   From: 0x02DAE to: 0x03194    (  999 bytes)

46

## Starting application at 0x0000 ...

47

=> z80_memfifo_init: 0, 7c320

48

z80_memfifo_init: 1, 7c21d

49

z80_memfifo_init: 2, 7c423

50

z80_memfifo_init: 3, 7c526

51

connect

52

DDT/Z - HD64180  (ROM)

53

> ?

54

DDT/Z180 (ROM) Commands:

55

> @                             examine/substitute the displacement register @

56

> A [address]                   Assemble

57

> B[X]                          display [or clear] all Breakpoints

58

  B breakp [:count] [breakp..]  set Breakpoints

59

  BX address [address..]        clear Breakpoints

60

>>C[N][J] [count]               trace over Calls [No list] [Jumps only]

61

  C[N][J] W|U expression        trace over Calls While|Until ...

62

>>D [startadr] [endadr]         Display memory in hex and ascii

63

> G [startadr] [;breakp..]      Go [to start] [temporary breakpoints]

64

> H [expression [expression]]   compute expressions / show High/max load adr.

65

>>I [port]                      Input a byte from port

66

>>L [startadr] [endadr]         List disassembled code

67

> M[V] startadr endadr destadr  Move memory [and verify]

68

>>O [byte] [port]               Output a byte to port

69

> Q[J] startadr endadr bytes    Qery memory for byte string [Justified]

70

> R [displacement]              Read intel hex from console [add displacemt]

71

> S address                     Substitute memory

72

>>T[N][J] [count]               Trace [No list] [Jumps only] [count steps]

73

  T[N][J] W|U expression        Trace While|Until expression

74

> V startadr endadr destadr     Verify (compare) two memory areas

75

> X[register]                   eXamine [and substitute] registers

76

> Y[0..9]                       eXamine [and substitute] Y variables

77

> Z startadr endadr bytes       Zap (fill) memory with a byte string

78

>

Der erste Teil läuft auf dem Steuer-AVR. Der Teil nach dem "connect" 
kommt dann Debugger auf dem Z180.

So Chris jetzt hast du mich angesteckt ;)
Leider habe ich nicht soviel Zeit wie du, aber dafür hoffe ich einen 
Schritt  schneller zu starten damit ----> 
Beitrag "2* UB8830D was mach ich nur mit Ihnen?"

Namaste

Christian J. schrieb:
> @Frank: wieso sollte ich was dagegen haben? Ist doch dein Kind. Nur das
> Interface für den dump und setup sollte einfach sein. Normalerweise
> kreist man doch mit dem Cursor in einem Hex Zahlen Feld herum, rechts
> die Ascii Code, links die Adresse. Und CR übernimmt die Daten dann.

Okay, ich baue einen.

Christian J. schrieb:
> Basic Interpreter: das setzt schon ein Speichermedium voraus. Wo soll
> derQuelltext hin? Oder die Tokens?

Ins RAM. Ein Interpreter ist kein Compiler. Ob du Tokens verwendest oder 
nicht: Quelltext = Programm.

Als persitenten Programmspeicher tut es ein Dataflash, oder eine 
SD-Card. Alternativ zu BASIC käme auch FORTH im Frage, da sollte sich 
auch was auftreiben lassen.

Christian J. schrieb:
> Nur Knopfzelle unter Platine ginge noch.

Reicht doch

Christian J. schrieb:
> FORTH? Grausam! Kommt mir nicht ins Haus. Du meintest vielleicht FORTRAN
> aber das ist eine Compiler Sprache.

Nö, FORTH stimmt schon, den Unterschied kenne ich. War mein Favorit beim 
AIX65 (6502). BASIC und PL/65 (ein Compiler in 8KB, der mich zum oben 
gezeigten PLZ inspirierte) hatte ich dafür auch, aber FORTH war mein 
Favorit.

Christian J. schrieb:
> Knopfzelle = 1.5V, nur die großen 3V.

"Gross" ist gut. Die Lithium-Zellen gibts auch in klein und Sockel dafür 
auch vertikal. Ausserdem darf ein Akku notfalls ein Kabel dran haben, 
die Hauptstromversorgung hast du ja auch nicht mit Trafo und Elko und 
allem Gedöns auf der Platine drauf.

Christian J. schrieb:
> Ich kriege das Zittern:

Du bist aber leicht zu schockieren ;-). Aber da geht noch was, 
angefangen habe ich damit (Siehe S.10):
http://fafner.dyndns.org/~vaxman/publications/apl.pdf

Christian J. schrieb:
> APL is dead! :-)

Nicht annähernd so tot wie der Inhalt deines Retro-Boards. ;-)

Christian J. schrieb:
> Die Kämme machen alles dicht.

<grins>

http://hc-ddr.hucki.net/wiki/lib/exe/fetch.php/tiny:u883bas.zip

schau dir mal den Tinibasic interpreter an der stammt aus dem UB8830 den 
solltest du leicht portiern können

ASM listing liegt bei ;)

Namaste

Christian J. schrieb:
> Z80 legt Quelltext zeilen im RAM ab

Aber nicht doch! Schon der selige PET 2001 hat zeilenweise geparst und 
nur Tokens im RAM abgelegt.

Winfried J. schrieb:
> schau dir mal den Tinibasic interpreter an der stammt aus dem UB8830 den
> solltest du leicht portiern können

Von Z8 auf Z80? Das glaube ich eher nicht.
Es gibt ja auch genug fertige Z80 Basic-Interpreter in allen Größen.

Winfried J. schrieb:
> schau dir mal den Tinibasic interpreter an der stammt aus dem UB8830 den
> solltest du leicht portiern können

Nochmal <grins>. Von Z8 auf Z80 macht keinen Spass. Z8 ist die 
eleganteste 8-Bit Mikrocontroller-Architektur für 
Assembler-Programmierung, der ich begegnet bin, wenn man mit den 256 
Bytes Datenadressraum auskommt. eZ8 hat da gezwungenermassen schwer 
nachgelassen.

Es zeugt von gutem Geschmack, dass sie "drüben" die Z8 abgekupfert 
haben, statt Fairchilds F8.

Christian J. schrieb:
> aber dann käme FAT noch hinzu.

Du denkst mal wieder zu kompliziert. Bei dem Weg landest du bei Board V2 
und sowas wie CP/M.

Wie hat man damals, als das Zeug neu war, Daten gespeichert? Disketten 
waren anfangs 8 Zoll gross, mit Laufwerken gross wie eine Schublade und 
mit 220V-Motor (hatte sowas etwas später). Normalmensch mit bescheidenen 
Finanzen verwendete einen Kassettenrekorder. Das "Filesystem" hiess 
Zählwerk und Zettel.

Ok, soweit Retro würde ich nicht empfehlen ;-). Aber das Prinzip lässt 
sich auch mit einem Dataflash nutzen: Du teilst ein 2MB Dataflash in 64 
Sektoren zu je 32KB auf und verwendest als "Filename" die Nummer des 
Sektors. Toteinfach und in ein paar Zeilen erledigt.

Gerade mal aus dem Regal gekramt.

Nachtrag:
Ist von 1979

Christian J. schrieb:

> Ok. Aber das Interface ...... da muss man mal kurz die Hirnzelle
> strapazieren.

Ich habe die erste Version hier mal drangehängt. Das Ding kann noch 
keine Werte ändern, aber Du kannst schon mit dem Cursor rumlaufen: 
links, rechts, oben, unten. Es wird nach oben/unten gerollt, wenn Du 
anschlägst. Dann wird die entsprechende Zeile nachgeladen. Die oberste 
Zeile bleibt natürlich stehen; hier werden die Scrolling Regions 
genutzt.

> Basic Interpreter: das setzt schon ein Speichermedium voraus. Wo soll
> derQuelltext hin? Oder die Tokens? Und solch große Code kann ich auch
> nicht mal eben portieren. Das ist aktuell noch ne nummer zu gross für
> mich. Habe aber eine Lösung im Web gefunden, wo ein PIC für den ich
> alles habe an den I/O Buss dran geschlossen wird.  Auf die idee kamen
> schon andere.

Zum Basic hatte ich Dir eben im mcurses-Thread

  Beitrag "Re: MCURSES - Mini Curses Bibliothek für Mikrocontroller"

schon mal Uwe Bergers Basic-Interpreter ans Herz gelegt. Läuft auf AVR, 
XMC2GO und auf STM32F4xxx - und benutzt mcurses für den 
Full-Screen-Editor.

Schau da mal rein, ich habe Dir dort bereits ein paar Links zum Stöbern 
serviert.

Christian J. schrieb:
> Hast Du programmieren mit der Muttermilch aufgesaugt? Oder
> sprichst "C" fliessend wie Deutsch? Ist ja irre.....

Ich "spreche" C seit über 30 Jahren... 1982 damit angefangen ;-)
Für heute mache ich Schluss, morgen noch ein Stündchen, dann ist er 
fertig.

> basic Thrad habe ich gesehen, ist aber Unmengen zu lesen und daher
> verschoben auf die Tage.

Naja, so ein Basic-Interpreter ist schon eine andere Hausnummer... das 
geht nicht ganz so schnell.

Christian J. schrieb:
> 369 Euro bei Amazon:

Darf ja nicht wahr sein. Ich glaube, ich muß ein Teil meines Regals in 
einen Tresor verfrachten...

Holm Tiffe schrieb:
> Aber ich würde statt Dataflash eine Micro-SD Karte empfeheln, die kann
> man auf dem PC ggf. "von außen" laden/sichern/ändern.

Oder das, am Interface ändert das wenig. Ich hatte eher die Organisation 
gemeint. Ein relativ komplexes Filesystem wie FAT ist im Grunde völlig 
unnötig. Er wird das System wohl kaum intensiv fileorientiert betreiben, 
wird den Compiler nicht auf die Z80 verlagern (so wars bei Retro in 
echt) sondern braucht den Platz nur für ein paar Programm-Images.

Holm Tiffe schrieb:
> Ja, aber ein Kassetteninterface wäre "Retro" :-)
> Sowas geht heute aber auch mit einem MP3 Bläher...

Ja, das wärs, analog mit FSK via MP3 Player auf µSD. ;-)

Christian J. schrieb:
> Passt allerdings kaum mehr in 8kb EPROM rein

Eben. Dass du den FAT Code nicht selbst zimmern würdest war klar.

Christian J. schrieb:
> Als C Spezi ...... mir haut ndie Verwendung von sprintf(buf.. locker 6
> kb weg und ich habe nur 8.

Und ohne (s)printf kannst du nicht leben... Obacht, auch 64kB reichen 
nicht ewig, wenn du in dem Schema weiter denkst und allein für sprintf 
fast sowiel Platz brauchst wie Rockwell für einen kompletten Compiler.

Holm Tiffe schrieb:
> Komm,komm.. diesen Ringpuffer schaffst Du auch in Assembler,
> das ist eigentlich Pillepalle auf einem Z80. Da die Sache Deiner Meinung
> nach zeitkritisch ist, ist das eine gute Gelegenheit mal 3 ASM Befehle
> des Z80 zusammenzurühren. Hier gibts genug Leute die Dir dabei helfen.

Und wenn er auch dazu keine Lust hat, dann nimmt er eben meinen oben 
schon geposteten Code für Z80-SIO, mit Puffer und Hard- und 
Software-Handshake, und transponiert ihn auf STI. ;-)

Christian J. schrieb:
> Tjaaaaa..... aber wenn sprintf einmal drin ist sind alle weitere Aufrufe
> eben nur Calls.

Wie hast du eigentlich in Pascal ohne printf programmiert? ;-)

PS: Ausserdem wirkt ein printf in 6kB ziemlich aufgeblasen. Ok, Z80 ist 
kein AVR, aber Leute haben schon Mega8 mit printf programmiert und der 
hat nur 8KB ROM insgesamt. Das kann man reduzieren, indem nicht zwingend 
nötige Formatvariationen rausfliegen.

Christian J. schrieb:
> leider nur kann ich Asm nicht debuggen,

Ach? Dabei hat dein Board meiner vagen Erinnerung nach einen 
wunderhübschen Debug-Port mit LED-Anzeige drauf. Wie geschaffen fürs 
lowlevel-debugging in Assembler.