Bin "nebenbei" wieder auf eine BASIC-Variante getroffen, die ich nihct kannnt und die nahe an MBASIC (bzw. GW-BASIC) ist:
HEBASIC V G5.02 (C) Dr. Hehl - Stand: 22.04.93
Es gibt eine CP/M-80 ( HEBASG5.Z80 - umbenennen nach .COM) und eine MS-DOS Version (HEBAS86.COM)
Das PDF-Handbuch fuer die Z80-Version ist hier (Seite 43 fehlt) - dahin kommt man ueber diese Seite
Das "HTML-Handbuch" ist gibt es hier
Peter z80.eu : Waer das nicht was fuer Deine CP/M-BASIC-Seite?
Ich schau's mir auch mal an, und ja, ein weiterer BASIC-Interpreter für CP/M-80 wäre da gut aufgehoben...
Ah, bevor ich es vergesse... schon mal die Geschwindigkeit getestet ?
Ich schau's mir auch mal an, und ja, ein weiterer BASIC-Interpreter für CP/M-80 wäre da gut aufgehoben...
Eigentlich mag ich diese BASIC, weil es sogar RENUMBER hat, aber ich bekomme testweise nur
1-4 Zeilen mit einem PRINT Statement gespeichert/geladen 
Versuche ich ein Programm wie das PSIEVE - kann ich es ohne Probleme ausfuehren, aber
entweder macht es - unter RunCPM - was beim speichern oder laden falsch.
Denn speichere ich mit SAVE "PSIEVE.BAS",A
dann ist die erste Zeile ohne Zeilennummer und dann wiederholt sich nur ein Block von mitten im Programm.
Speichere ich mit SAVE "PSIEVE.BAS" (also nicht in ASCII) bekomme ich nach einem LOAD/LIST kein Programm angezeigt,
auch wenn SAVE/LOAD immer sauber mit FERTIG (also READY.) quittiert wird.
Kannst Du dies evtl. mal auf einem echten CP/M Rechner testen?
Bei der MSDOS-Version klappt speichern/laden.
BTW: HEBASIC basiert wohl auf TDL-BASIC 2.1 bzw. 3.05 von Neil Colvin - nur das ist wohl speichern/laden nur fuer PuchCards vorgesehen
10 REM Prime number generator
20 REM Sieve of Eratoshenes
30 REM Tim Holyoake, 16/01/2021
40 REM Sharp BASIC SP-5025
50 REM retyped in MBASIC
60 REM by Guido Lehwalder
70 REM CLS
80 PRINT "Enter Prime-Number Limit:"
90 INPUT L
100 IF(L<2) THEN GOTO 360
110 DIM A(L)
120 A(1)=0
130 FOR N=2 TO L
140 REM "Set 2 to L as possiblT "Removing multiples of ";I
150 A(N)=1
160 NEXT N
170 REM Implement Sieve
180 FOR I=2 TO SQR(L)
190 IF A(I)=1 THEN GOTO 210
200 GOTO 280
210 PRINT "Removing multiples of ";I
220 REM Removing multiples
230 J=I*I
240 IF J>L THEN GOTO 280
250 A(J)=0
260 J=J+I
270 GOTO 240
280 NEXT I
290 REM Print Results
300 FOR K=1 TO L
310 REM IF A(K)=0 THEN PRINT ".";
320 IF A(K)=1 THEN PRINT K;"-";
330 NEXT K
340 PRINT
350 PRINT "Reached end of Prime-Limit"
360 ENDAlso mit MYZ80 geht's ohne Verlust von irgendwas. Erstmal die BASIC-Datei als Text in Windows gespeichert (CR-LF am Zeilenende ist meist völlig egal), dann in HEBASG5 geladen, eine REM-Zeile 65 testweise (zur Kontrolle) hinzugefügt, dann unter CP/M abgespeichert mit ",A" als Textdatei.
Danach wieder geladen, siehe Bild. Hat also RUNCPM-Gründe befürchte ich.
Mit JHallen's CP/M Emulator unter armbian klappt das SAVE/LOAD, auch wenn die knapp 800 Byte Programm
viel zu viel Platz auf dem Datentraeger belegen:
-rw-r--r-- 1 root root 11535232 Jun 9 11:34 pascii.bas
-rw-r--r-- 1 root root 11535104 Jun 9 11:34 ptoken.bas
Waere echt schade, wenn es unter RunCPM nicht laufen wuerde
Ob da HEBAS zu lowlevel ins System greift?
Hat also RUNCPM-Gründe befürchte ich.
Ist wohl so, denn der CP/M-Player fuer Win32 hat damit auch kein Problem und speichert sauber 768 Bytes und laedt diese auch wieder.
guidol - ich denke das BASIC läuft doch nicht rund, hatte vergessen dass unter MyZ80 ja auch verschiedene Betriebssystem-Versionen gebootet werden können. Mit ZSDOS / NZCOM, was im "MaxZ80"-Paket drin ist, läuft es.
Unter CP/M 3.0 und MyZ80 läuft es definitiv auch nicht, und zeigt die von Dir beschriebenen Symptome.
Also liegt es wahrscheinlich doch nicht an RUNCPM, sondern am BASIC-Interpreter.
Ich habe mal alle Varianten ausprobiert, also
1) den BASIC-Text mit CR+LF Zeilenende unter Windows gespeichert,
2) dann auch mal nur mit LF oder nur mit CR als Zeilenende,
3) dann auch mal mit abschliessendem Ctrl-Z (hex 1A)
Jede Variante erzeugt unter CP/M 3.0 einen Fehler, manchmal noch mit der zusätzlichen Fehlermeldung "Zeilen-Nr. fehlt".
Manchmal werden zwar alle Zeilen geladen, aber selbst dann stimmt das Ergebnis nicht, in den Zeilen selbst entstehen im Interpreter aus dem Nirwana Sonderzeichen oder nicht dahin gehörende Zeichen.
Für welchen CP/M-Computer war das ursprünglich gedacht ? Der wird wohl auch kein "reines" CP/M 2.2 oder CP/M 3.0 genutzt haben...
P.S.: Vielleicht liegt es auch an der Speichergrenze-Eingabe (ich überspringe die immer mit RETURN). Unter ZSDOS in der "MaxZ80"-Version habe ich nur knapp 29KB frei, unter CP/M 3.0 dagegen über 44KB... auch ein Unterschied.
P.P.S.: Ja, genau daran liegt es ! Wenn Du als Speichergrenze nur 49152 bspw. eingibst, geht wieder alles. HEBASIC kann wohl nicht mit "zuviel" Speicher umgehen !
Hallo Fritz,
leider findet sich da keine Erklärung warum man unterhalb des maximal möglichen Speicherbereichs (also max. TPA Ausnutzung) die Speichergrenze setzen muss.
Das hier ist quasi alles was zum Thema Speichergrenze beschrieben ist:
Nach dem Laden und Starten des Basic-Interpreters wird nach der Speichergrenze ge-fragt. Eingabe von <CR> reserviert je nach Version verschieden großen Speicherplatz für Programme und zusätzlich 100 Bytes für Zeichenketten. Eingabe einer Dezimal- oder einer Sedezimalzahl (mit Kennzeichnung "&" als erstes Zeichen) begrenzt den Speicher, um z.B. ein Maschinenprogramm im oberen Speicherbereich zu schützen.
Beispiele (Werte je nach Version verschieden)
Eingabe: 45056 <CR> Anzeige: 26411 Bytes frei
&B000 <CR> 26411 " "
&DC07 <CR> 37672 " "
Bei der Eingabe von Sedezimalzahlen sind nur Großbuchstaben erlaubt. Bei falschen Eingaben und bei Zahlen größer 56327 kommt die Frage "Speichergrenze?" wieder und es kann eine neue Zahl eingegeben werden. Nach der Meldung des Interpreters wird bei der Diskettenversion nach dem Datum gefragt. Es können bis zu 20 beliebige Zeichen eingegeben werden, die mit PRINT DATE$ abrufbar sind, z.B. 31. Dezember 1991 **.
Die Eingabe von <CR> ergibt die Meldung "Fertig" ohne aktuelles Datum.
a) Hinweise für CP/M-Plus beim NDR-Rechner:
Es stehen 42536 Bytes für BASIC-Programme zur Verfügung.
b) Hinweise für den NDR-Klein-Computer:
Beim Start wird automatisch der Bildschirm gelöscht und der deutsche Zeichensatz eingeschaltet. Wer dies nicht möchte oder verändern will, kann im Quellcode die Bytes 1A 1B 7A 31 abändern (1A = CTRL-Z: Bildschirm löschen, 1B = ESCAPE: Sonderfunktion, 7A 31 = z 1: deutscher Zeichensatz).
Nicht jeder hat halt auch einen NDR-Rechner.
P.P.S.: Ja, genau daran liegt es ! Wenn Du als Speichergrenze nur 49152 bspw. eingibst, geht wieder alles. HEBASIC kann wohl nicht mit "zuviel" Speicher umgehen !
Leider klappt dies nicht bei RunCPM
Ich habe verschiedene Speichergroessen versucht und sogar andere CCP-Versionen von RunCPM compiliert.
Leider immer mit dem selben Ergebnis
Dies nicht nur auf ESP32/RPi Pico sondern auch bei einem Windows- und Linux-Compile von RunCPM
Na dann muss ich auch mal RunCPM bemühen.... was ist denn die aktuellste Version für Win32 oder Win64 ?
Na dann muss ich auch mal RunCPM bemühen.... was ist denn die aktuellste Version für Win32 oder Win64 ?
Immer noch v6.0
Nochmal ich. Kann das mit jeder mal früher heruntergeladenen RUNCPM Version (probiert habe ich unter Windows V4.4, V5, V6, unter DOS V6) nachvollziehen. Der SAVE-Befehl erzeugt nur Schrott. Lade ich die anderweitig erzeugte BASIC-Quelldatei in HEBASIC, läuft die einwandfrei.
Da müsste man in der Quelle von RUNCPM nach der Implementation der BDOS Funktion 21 (oder ggfls. auch 34, beide Zahlen dezimal) suchen.
Sieht für mich so aus, als ob ein Speicher-Pufferbereich zum Schreiben genutzt wird, der nicht größer als 128 Bytes groß sein kann, oder noch wahrscheinlicher, dass da eine Datei nur mit dem letzten 128-Byte-Record der zuvor zum Schreiben geöffneten Datei geschrieben wird.
Theoretisch kann man das auch via DDT bzw. SID durchsteppen, dauert aber bestimmt länger.
mit dem JHallen CP/M klapte ja SAVE/LOAD, aber mit komischer Filesize
Setzt man z.B. 45000 als Memory-Size speicher der JHallen auch nur die echten Bytes.
Fuers kleine FRACTAL dann 384 Bytes
Der CP/M-Player (Win32) und der CP/M-Executor haben auch kein Probleme beim speichern (laden sollte OK sein, weil wir ja handgespeicherte BASIC-Programme sauber laden koennen und auch diese sauber ausgefuehrt werden).
Der Autor von RunCPM hat dieses bis jetzt rausgefunden:
ZitatAlles anzeigenStarting at line 7868 of this log file I see it is caling BDOS to sequentially write a file, but it seems to be calling the same sequantial write twice, and it seems to revert back to the previous sector, overwriting what is already written.
I do not know if it does the same on a regular CP/M (the double sequential write) and it somehow works.
We might be doing something with the disk write (or setting of the FCB post-write) which is throwing off HEBAS.COM into some oblivion.
This is a better log with the results of the open/create, etc calls results on the FCB.
I do not see anything strange in the results. Unless it is the r0,r1,r2 calculations that are throwing off the HEBAS, or maybe one of the return codes.
Maybe someone could write a small "write sequential" program to test it out.
I am not sure if I follow. HEBAS uses call 21 (Write Sequential), which whould deliver the record to the file and update 'cr' in the FCB, which will make the next record to go out after the one just delivered.
But if you look like the position FC80 of the FCB, it increments after the call (which is expected) but then HEBAS seems to reset it.[22:10]I have checked MBASIC, but it unfortunately uses 'Write Random' to save
Vielleicht kann man bspw. via Turbo PASCAL 3.0 ein Testprogramm schreiben, was auch die BDOS Funktion 21 (dec) nutzt, um es quasi isoliert vom Rest testen zu können. Ich schau mal morgen, was ich da zusammenbasteln kann. Könnte man wohl auch direkt in Assembler, dazu bin ich aber zu faul 
YES! Der RunCPM Autorhat einen Fix (RunCPM v6.1) herausgebracht, der HEBAS sauber speichern laesst.
Da es ein "Schnellschuss" ist (seine Aussage) sollte man im Auge behalten, wie evtl. andere Apps auf den Fix reagieren.
ZitatLooks like 'Write Sequential" updated 'cr' (current record) but also 'rc' (record count) in the FCB.
I was updating only 'cr'.
It seems that HEBAS.COM uses rc to track where to start writing next time.
So it always started from 0.
Ich hab die disk.h bei mir in der PicoW Version mal getestet und kann nun da erstmal HEBAS nutzen in RunCPM v6.1
Wordstar startete auch noch.... evtl. muss man mal in verschiedenen Programmen speichern/laden testen.
Evtl. haben andere Emulatoren (oder CP/M-Systeme) automatisch immer cr und rc upgedated?
Also extra fuer Dich compiliert, weil - auch Du - so nett geholfen hast.
