Basic-Interpreter für CP/M-68k
-
- Sonstige
- Toshi
-
-
Vielen Dank für den Tipp.
Ich habe inzwischen mehrere Basic Interpreter gefunden,
die ein C geschrieben sind.
(u.a. http://www.moria.de/~michael/bas/bas-2.4.tar.gz)
Werde ich mir alle irgendwann mal näher anschauen.
Mit Enhanced Basic bin ich momentan recht zufrieden.
Leider ist es nicht 100 % kompatibel zu MBASIC (Basic 80).
-
-
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.
-
Hier die Version 3.53 von EhBasic für CP/M-68k.
Jetzt funktioniert auch die Exponentialfunktion.
C>EHBASIC.REL
16623788 Bytes free
Enhanced 68k BASIC Version 3.53
Ready
PRINT EXP(1)
2.718282
Ready
LOAD
LOAD file (*.bas) : ^C
C>
-
Ich habe Enhanced 68k BASIC Version 3.52 für CP/M-68K angepaßt.
Compiliert und getestet auf einem CP/M-68K emulator.
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;
Codecp68 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)
CodeC>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:
Code
Alles anzeigenC>lo68 -r -o tbasic.68k 2:s.o tbasic.o 2:clib : Undefined symbol(s) _main C>tbasic Exception $04 at user address $00000000. Aborted.
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
Im simcpu liegen die Dateien zum Glueck im User 2 deshalb geht:
-
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 ?
-
Überprüfe erst mal mit einem einfachen C Programm, ob der C Compiler richtig installiert ist.
bei mir sieht das so aus:
C
Alles anzeigenC>type c.sub cp68 -i 0: $1.c $1.i c068 $1.i $1.1 $1.2 $1.3 -f era $1.i c168 $1.1 $1.2 $1.s era $1.1 era $1.2 as68 -l -u -s 0: $1.s era $1.s C>type clinkf.sub lo68 -r -o $1.68k 0:s.o $1.o $2.o $3.o $4.o $5.o $6.o $7.o $8.o $9.o 0:clib 0:libf.a C>type fractal.c #include <stdio.h> int main() { int x,y,i,blank; float ca,cb,a,b,t; for (y = -12; y<13; y++) { for (x = -39; x<40; x++) { ca=x*.0458; cb=y*.08333; a=ca; b=cb; blank = 1; for (i=0; i<16; i++) { t=a*a-b*b+ca; b=2*a*b+cb; a=t; if ((a*a+b*b) > 4) { if (i>9) printf("%c",(48+i+7)); else printf("%c",(48+i)); i=16; blank = 0; } } if (blank == 1) printf("%c",0x20); } printf("\n"); } } C>c fractal C>CP68 -I 0: FRACTAL.C FRACTAL.I C>C068 FRACTAL.I FRACTAL.1 FRACTAL.2 FRACTAL.3 -F C>ERA FRACTAL.I C>C168 FRACTAL.1 FRACTAL.2 FRACTAL.S C>ERA FRACTAL.1 C>ERA FRACTAL.2 C>AS68 -L -U -S 0: FRACTAL.S C>ERA FRACTAL.S C>clinkf fractal C>LO68 -R -O FRACTAL.68K 0:S.O FRACTAL.O .O .O .O .O .O .O .O .O 0:CLIB 0:LIBF.A C>fractal 000000011111111111111111122222233347E7AB322222111100000000000000000000000000000 000001111111111111111122222222333557BF75433222211111000000000000000000000000000 000111111111111111112222222233445C 643332222111110000000000000000000000000 011111111111111111222222233444556C 654433332211111100000000000000000000000 11111111111111112222233346 D978 BCF DF9 6556F4221111110000000000000000000000 111111111111122223333334469 D 6322111111000000000000000000000 1111111111222333333334457DB 85332111111100000000000000000000 11111122234B744444455556A 96532211111110000000000000000000 122222233347BAA7AB776679 A32211111110000000000000000000 2222233334567 9A A532221111111000000000000000000 222333346679 9432221111111000000000000000000 234445568 F B5432221111111000000000000000000 864332221111111000000000000000000 234445568 F B5432221111111000000000000000000 222333346679 9432221111111000000000000000000 2222233334567 9A A532221111111000000000000000000 122222233347BAA7AB776679 A32211111110000000000000000000 11111122234B744444455556A 96532211111110000000000000000000 1111111111222333333334457DB 85332111111100000000000000000000 111111111111122223333334469 D 6322111111000000000000000000000 11111111111111112222233346 D978 BCF DF9 6556F4221111110000000000000000000000 011111111111111111222222233444556C 654433332211111100000000000000000000000 000111111111111111112222222233445C 643332222111110000000000000000000000000 000001111111111111111122222222333557BF75433222211111000000000000000000000000000 000000011111111111111111122222233347E7AB322222111100000000000000000000000000000 C>
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....
-
Ü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
Code
Alles anzeigenC>c fractal C>CP68 -I 0: FRACTAL.C FRACTAL.I C>C068 FRACTAL.I FRACTAL.1 FRACTAL.2 FRACTAL.3 -F C>ERA FRACTAL.I C>C168 FRACTAL.1 FRACTAL.2 FRACTAL.S C>ERA FRACTAL.1 C>ERA FRACTAL.2 C>AS68 -L -U -S 0: FRACTAL.S C>ERA FRACTAL.S C>clinkf fractal C>LO68 -R -O FRACTAL.68K 2:S.O FRACTAL.O .O .O .O .O .O .O .O .O 2:CLIB 2:LIBF.A : Undefined symbol(s) _main C>fractal Exception $04 at user address $00000000. Aborted. C>
-
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.
-
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 BildschirmDa 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:clibDenn ein TYPE 0:CLS.SEQ bringt einen Fehler
[EDIT] Laut dem YT-Video koennte ich dafuer bei CLS folgendes machen, ist aber doch umstaendlich?
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
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.
.68k Dateien mache ich nur dann, wenn ich zu wenig Platz auf der Diskette habe.