Basic-Interpreter für CP/M-68k

  • BWBASIC ist ja schon ein ganz schöner Brocken, das kannte ich noch gar nicht. Danke :)

    Irgendwas dämmert mir, dass das ~2005 (+-ein paar Jahre) mit auf der FreeDOS-FULL CD war...


    Natürlich gibt's dann da auch noch FreeBASIC, was aber, IIRC, nur ein Frontend für BASIC-to-ASM ist und den "gas" Assembler am hinteren Ende braucht.

  • Ich habe Enhanced 68k BASIC Version 3.52 für CP/M-68K angepaßt.


    Compiliert und getestet auf einem CP/M-68K emulator.

    http://home.earthlink.net/~schultdw/cpm68/simulator.html

    Die Original-Seite ist auf archive.org noch unter
    https://web.archive.org/web/20…ltdw/cpm68/simulator.html

  • Ich habe ein TinyBASIC als C-Source gefunden und dachte ich versuche mal es auf CP/M-68 zu compilieren.


    Dazu habe ich den CPM-68K-C-Programming-Guide vom Nuni 1983 als PDF genommen (Anhang B1), aber die Befehle wollten nicht wie die da drin stehen :(


    Durch versuchen und andere Webseiten kam ich dann auf folgende Sequence;

    Code
    cp68 tbasic.c tbasic.l
    c068 tbasic.l tbasic.ic tbasic.st -f
    c168 tbasic.ic tbasic.st tbasic.s
    as68 -u tbasic.s

    Leider bekomme ich als Ergbnis nur bis zu folgendem:


    Bei lo68 ohne -r (relocate) (auch wenn ich in TBASIC.C die PROG_SIZE von 10000 auf 2048 setze)


    Code
    C>lo68 -o tbasic.68k 2:s.o tbasic.o 2:clib
    : Undefined symbol(s)
    _main
    
    
    C>tbasic
    Insufficient memory or bad file header

    und bei lo68 mit -r relocate:



    Hat jemand eine Idee dazu? Ich bin leider kein C-Programmierer-Experte :(


    Ausserdem komisch fand ich, dass wenn ich s.o und clib auf C im User 0 habe = 0:

    dann bekomme ich fuer die Dateien einen read-error :(


    Code
    lo68 -o tbasic.68k 0:s.o tbasic.o 0:clib
    oder
    lo68 -o tbasic.68k s.o tbasic.o clib

    Im simcpu liegen die Dateien zum Glueck im User 2 deshalb geht:

    Code
    lo68 -o tbasic.68k 2:s.o tbasic.o 2:clib
  • Gehe ich recht in der Annahme, dass am Ende des Compilierungsprozesses - vor der Code-Generierung - auch ein 'AS68' Aufruf erfolgt (weil eine Assembler-Source mit der Endung .S ebenfalls erzeugt wird) ? Wenn ja, da gibt es auch eine Option -U für den Assembler, um alle Subroutine-Aufrufe, die nicht direkt aufgelöst werden können, als "global" gehandhabt werden. Oder es gibt eine "stub", die immer noch dazugelinkt werden muss.

    Habe aber nie selbst mit dem CP/M-68K C-Compiler gearbeitet, also alles nur Vermutungen.

    Gibt es Beispielprogramme, die ohne Fehler compiliert werden können ?

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey


    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

  • Überprüfe erst mal mit einem einfachen C Programm, ob der C Compiler richtig installiert ist.


    bei mir sieht das so aus:


    tbasic.c kann ich leider auch nicht übersetzen, da bekomme ich dutzende von Fehlermeldungen.

  • Gehe ich recht in der Annahme, dass am Ende des Compilierungsprozesses - vor der Code-Generierung - auch ein 'AS68' Aufruf erfolgt (weil eine Assembler-Source mit der Endung .S ebenfalls erzeugt wird) ? Wenn ja, da gibt es auch eine Option -U für den Assembler, um alle Subroutine-Aufrufe, die nicht direkt aufgelöst werden können, als "global" gehandhabt werden.

    Gibt es Beispielprogramme, die ohne Fehler compiliert werden können ?

    :) Schau mal in meinen ersten "Codeblock" in Zeile 4, da ist der as68 Aufruf mit -u


    Einen anderen Test-Code habe ich noch nicht in C compiliert unter simcpm CP/M-68k :(

  • Gehe ich recht in der Annahme, dass am Ende des Compilierungsprozesses - vor der Code-Generierung - auch ein 'AS68' Aufruf erfolgt (weil eine Assembler-Source mit der Endung .S ebenfalls erzeugt wird) ? Wenn ja, da gibt es auch eine Option -U für den Assembler, um alle Subroutine-Aufrufe, die nicht direkt aufgelöst werden können, als "global" gehandhabt werden.

    Gibt es Beispielprogramme, die ohne Fehler compiliert werden können ?

    :) Schau mal in meinen ersten "Codeblock" in Zeile 4, da ist der as68 Aufruf mit -u


    Einen anderen Test-Code habe ich noch nicht in C compiliert unter simcpm CP/M-68k :(

    Groß- oder Kleinschreibung bei dem Optionsbuchstaben (-u vs -U) ist wahrscheinlich auch egal....

    "The biggest communication problem is we do not listen to understand. We listen to reply." - Stephen Covey


    Webseite und Blog ist immer noch - seit fast 20 Jahren - online.

  • Überprüfe erst mal mit einem einfachen C Programm, ob der C Compiler richtig installiert ist.

    Mir scheint bei mir irgendeine Datei o.ae. zu fehlen - selbst beim FRACTAL bekomme ich eine Exception und vorher wie bei tbasic "Undefined symbol(s)" :(


    PS: clinkf.sub habe ich bei den .0 auf 2: gesetzt

  • Ich bezweifle mal, dass der Compiler das C-File überhaupt richtig übersetzt hat. Tiny-Basic verwendet ANSI-like-Funktionsdeklarationen, C68 scheint aber laut Doku gerne K&R-Stil zu sehen (zumindestens sind alle Beispiele so geschrieben und 1983 war ANSI-C noch kein so richtiges Ding). Du bekommst doch bestimmt Fehlermeldungen beim Compilerlauf?

  • Anscheinend baut er ja irgendwas. Aber er meckert am _Main rum und ich würde mal schaune, was denn die Bibliothek "setjump.h" macht und ob Du die überhaupt mit dabei hast. Beim Linken kann man gern auch alle Bibliotheken aus den #include Zeilen mit angebene. math ist normalerweise aber nicht -lmath sondern -lm ... soviel zur C Logik. Da mußt Du mal schauen, was Dein C Compiler haben will.


    Ansonsten : der Aufruf von tbasic muß dort unbedingt mit einem auszuführenden Programm erfolgen. tbasic allein reicht nicht.

    tbasic basic.bas

    lädt dagegen (rein theoretisch) das Programm und macht dann schonmal mehr. Evtl gehts ja dann schon.



    An dem Aufruf von "tbasic" allein kannst Du aber schon sehen, daß da irgendwas beim "Bauen" nicht paßt, denn eigentlich müßte da dann als allererstes in main() die Fehlermeldung printf("usage: tinybasic <filename>\n"); ausgegeben werden (Zeile 103 im github Link). Und noch nichtmal das passiert.


    Probier mal das fractal zum Fliegen zu bekommen und dann, wenn das klappt, probier das mit dem tbasic erneut.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • Probier mal das fractal zum Fliegen zu bekommen und dann, wenn das klappt, probier das mit dem tbasic erneut.


    ngc224  Peter z80.eu tofro ThoralfAsmussen

    Danke fuer "Mut machen" ;)


    Und ihr werdet kaum glauben was es fuer ein aergerlicher Fehler war:

    compiliere ich die cpmtool von kkaempf (2.21) oder original moria.de cpmtools (2.23) auf meinem NanoPi Neo2 mit dem (dort bei der OS-Version mit Kernel 6.4.12) Stanard GCC-10 bekomme ich eine Version, die nicht immer alle Daten sauber uebertraegt :(


    Auf meinem NanoPi A64 mit GCC-12 (bei OS mit Kernel 6.6.2) kommt trotz Warnings beim compile (wie auch beim CygWin 64Bit) eine Version raus, die die Fiiles sauber uebertraegt.


    Meine compile-Fehler am Anfang waren auch Uebertragungsfehler z.B. vom tbasic.c und aber auch die read-Fehler bei der S.O und der CLIB


    Im tbasic.c fand der Compiler nichts, weil er woh gleich bei dem Wirrwar ein EOF erkannte und so auch ueber main motzte (weil er kein main fand).


    Aus Frust/Mut hatte ich alle 8 Disketteninhalte der CP/M-68k v1.2 in mein User 8 kopiert und selbst da complierte mit Muehen gerade mal ein "Hello World!" (das hatte ich als .C ueber den Editor eingepasted).


    Ans FRACTAL war nicht zu denken :( denn da hatte ich versucht per cpmcp ins 8: zu kopieren, konnte es aber weder TYPEen noch editieren :(


    Ich hatte es ohne Fehlermeldunf auf 8: kopiert bekommen, aber beim rueckkopieren ins Linux-Filesystem waren nur Hyroglyphen/Steuerzeichen zu sehen.


    Nachdem ich erst versucht hatte in MinGW oder MSYS2 dioe cpmtools zu compilieren, gelang es unter Warnings in Cygwin 64Bit und da klappt der Transfer des FRACTAL.C rein und raus ohne Fehler.

    Aus Neugier gegen den NanoPi Neo2 probierte ich es mit dem neuren OS des NanoPi A64 (GCC-12) und auch da klappte der Transfer :)


    So macht ich mich gleich dran mit dem neu gefundenen Wordstar-like SKED CP/M-68K Editor
    (den haenge ich zur Sicherheit auch mal hier mit dran)
    das FRACTAL.C auf mein mehr geliebtes FRAROUND.C umzustellen und zu compileren.


    Der Editor nutzt war Wordstar-Keys, allerding muss man zwischen den Command-Buchstaben die Control-Taste loslassen gegenueber echten Wordstar (und er zeigt dies auch nur in der Ctrl-J Hilfe und man muss es erstmal verstehen :) )
    Zusaetzlich mag der SKED wohl nur einen 80x25 Bildschirm :(


    Da dies jetzt endlich erfolgreich war, ist fuer heute erstmal Schluss, weil laut Euch eh nicht alles fuers TinyBasic (tbasic) vorhanden ist.


    Dafuer hier Bilder meines Wirkens von heute :)




  • 2 kurze "dumme Fragen" (OK- wer nicht fragt bleibtbt dumm) ;)


    1.) Gibt es eine Moeglichkeit auf Dateien aus anderen User Areas zuzugreifen?
    - beim compilieren gibt man ja auch z.B. 2:s.o an oder 8:clib

    Denn ein TYPE 0:CLS.SEQ bringt einen Fehler :(

    [EDIT] Laut dem YT-Video koennte ich dafuer bei CLS folgendes machen, ist aber doch umstaendlich?

    Code
    PIP CLS.SEQ=C:CLS.SEQ[G0]
    TYPE CLS.SEQ

    2.) Wie verlasse ich EHBASIC 3.53?
    - QUIT, BYE, SYSTEM, STOP scheint es ja nicht zu sein -beim IoTBASIC/TinyBasic gabs noch CALL 0

  • >> 2.) Wie verlasse ich EHBASIC 3.53?

    >>- QUIT, BYE, SYSTEM, STOP scheint es ja nicht zu sein -beim IoTBASIC/TinyBasic gabs noch CALL 0


    LOAD und dann ctrl-c


    Code
    C>ehbasic.rel
    
    16623788 Bytes free
    
    Enhanced 68k BASIC Version 3.53
    
    Ready
    LOAD
    LOAD file (*.bas) : ^C
    C>
  • LOAD und dann ctrl-c

    Danke ;)

    Funktioniert bei Dir ein EHB353.68K?

    Bei mir startet (sauber) nur ein EHB353.REL


    Mache ich daraus ein .68K mit

    RELOC EHB353.REL EHB353.68K

    dann loescht es nu den Screen beim Start und haengt.


    Oder klappt da "nur" die automatische RELOC-Adresse nicht?


    Ist es eigentlich empfohlen ein .68K Binary draus zu machen (gibt ja auch die DR C-Compiler-Befehle als .REL)


    Ich hatte es so verstanden, dass die .68K mehr ans bestimmte CP/M 68K Systeme angepasst sind.

  • ehbasic.68k funktioniert bei mir auch nicht !

    Weder im Emulator noch auf meinem 68k Rechner.

    Warum es nicht funktioniert, weiß ich momentan auch nicht.

    Code
    C>reloc ehbasic.rel ehbasic.68k
    
    C>ehbasic
    
    
    Exception $02 at user address $000083F8.  Aborted.
    C>

    .68k Dateien mache ich nur dann, wenn ich zu wenig Platz auf der Diskette habe.