Kompiliert? Runtergeladen, installiert, und ausgeführt. Das ist ein GW-Basic-(kompatibler)-Interpreter.
Nehme doch QB64 .... damit brauchst Du an der Quelldatei nichts ändern und Du bekommst trotzdem ein x64 Windows-Executable....
Kompiliert? Runtergeladen, installiert, und ausgeführt. Das ist ein GW-Basic-(kompatibler)-Interpreter.
Nehme doch QB64 .... damit brauchst Du an der Quelldatei nichts ändern und Du bekommst trotzdem ein x64 Windows-Executable....
Der obige Lauf auf dem NABU war unter CP/M 3.0 mit MBASIC.
Nun wollte ich dem originalen NABU-BASIC v2.0 auch mal eine Chance geben, aber das mag wohl nicht den Ausbruch aus der FOR/NEXT-Schleife?
Oder kennt jemand den Fehler CS Error in line ? Google blieb stumm dazu
Zum Glueck kann man bei MAME mit LeftShift+Scroll-Lock auch Text einfuegen
(wobei er mir immer die ersten beiden Zeichen des Clipboard verhauen hat von Zeile 10)
....
Das kannst du wahrscheinlich einfach lösen, wenn du in Zeile 110 das Goto 200 durch I=15 ersetzt. Dann hast du einen legitimen Ausbruch aus der Schleife. Dann musst du nur noch dafür sorgen, dass die Zeilen 130 und 140 auch noch übersprungen werden, vielleicht jeweils durch ein if (a*a+b*b) <=4 davor.
Das kannst du wahrscheinlich einfach lösen, wenn du in Zeile 110 das Goto 200 durch I=15 ersetzt.
Ich habe das I=15:NEXT I vor das NEXT X gesetzt, damit es wieder stimmt.
In NABU-BASIC gibt es weniger als 40 Zeichen pro Zeile, dehalb musste die Aufloesung leiden und ist somit auch nicht mehr zeitlich vergleichbar (gefuehlt aber langsamer als MBASIC unter NABU-CP/M).
So sieht es nun aus und das ist das Programm:
Das ist so aber falsch, du siehst ja auch, das Apfelmännchen ist nicht komplett.
Das ist so aber falsch, du siehst ja auch, das Apfelmännchen ist nicht komplett.
wie geschrieben, bei den verfuegbaren Zeichen gibt es nur einen Ausschnitt
Nein, du hast die Programmlogik entscheidend verändert.
Nein, du hast die Programmlogik entscheidend verändert.
OK dass war dann ungewollt.
Die Zeichenketten sind "aber" Asuschnitte von dem Ergebnis, was ansonsten bei 80 Zeichen Breite rauskam.
Ich hatte es vorher mit dem I=15 bei der oberen IF-Abfrage eingesetzt und dann versucht - wie von Dir genannnt die 130/140 zu ueberspringen.
Leider blieb es dann beim CS Error und es gibt kein echtes NABU BASIC 2.0 Handbuch, nur eine Liste der Befehlsnamen.
Naeher bin ich leider mit meinem Wissen nicht ran gekommen
Du musst die 3 Zeilen nur so umschreiben wie ich es geschrieben habe. Das mit dem vorigen Ausrechnen von F in Zeile 105 ist eine sinnvolle Vereinfachung, die du drin lassen solltest, weil du den Wert 3 mal brauchst.
Du musst die 3 Zeilen nur so umschreiben wie ich es geschrieben habe. Das mit dem vorigen Ausrechnen von F in Zeile 105 ist eine sinnvolle Vereinfachung, die du drin lassen solltest, weil du den Wert 3 mal brauchst.
OK - ich habe nun versucht durch STEP +2 in der Breite das ganze Maenchen drauf zu bekommen und mit 2 Unterprogrammen versucht Deine Vorgabe umzusetzen.
Jedenfalls erkennt man nur das ganze Bild "etwas"
Das sieht doch schon besser aus! Jetzt noch die Zeit stoppen!
Das sieht doch schon besser aus! Jetzt noch die Zeit stoppen!
3 Minuten und 45 Sekunden
Schöner Gruß von der HomeCon
Cyrix/TI 486DLX-33 mit allen Optimierungen eingeschaltet:
Und mit den zusätzlichen Optimierungen ausgeschaltet, also wie ein BIOS ohne Unterstützung für diese CPU:
Schöner Gruß aus Wittlich-Klausen!
Gleiche Maschine, nur in Win 3.11, das fordert seinen Tribut...
Und auf der TA Walkstation mit originalem i80386DX-33...
Satter Unterschied - sehr zu Ungunsten vom Fensterle-System.
Mein neuer robotron PC1715W hat 5:47 Minuten gerechnet. (4 MHz, Basic-Interpreter).
LG Tom
War bei mir auch so, nur der KC war schneller...
Übrigens, mit der S1/S0-Taste kann man zwischen den Zeichensätzen wechseln. Voraussetzung ist ein 2. EPROM mit einem 2. Zeichensatz.
War bei mir auch so, nur der KC war schneller...
Übrigens, mit der S1/S0-Taste kann man zwischen den Zeichensätzen wechseln. Voraussetzung ist ein 2. EPROM mit einem 2. Zeichensatz.
Nein, nicht ganz richtig, der 1715W hat kein Char-ROM, der Zeichensatz wird von Diskette geladen, und ich kann mit dem 1715 auch russisch (ich weiß, ist gerade nicht "in"). Ich kann ja demnächst mal ein Photo und die Details posten, wenn Interesse besteht.
Gruß Tom
NVBASIC 2.5 (Nevada BASIC) weigert sich ein CHR$ zu printen, dass wohl ausserhalb der FOR-Schleife als Wert liegt
[EDIT] Nevada BASIC hat kein CHR$ sondern nur CHR
dann geht Line 205 ABER dann will die NEXT X Schleife in Line 210 nicht mehr:
Echt ? Das liegt doch am J-Wert selbst. J ist ist nicht OUT OF REACH sondern OUT OF RANGE. Ist der nicht 0 bis 22? Mag er vielleicht kein 0 als ASCII ?
schau doch nochmal genau, ob ausser CHR$ zu CHR noch irgendwas anderes aus Versehen geändert wurde, die Fehlermeldung wird ja so erläutert:
Gruß
Roland
Auf dem CBM laeuft es mit dem Code 1:1
Scheint dann wohl ein S Basic Ding zu sein.
Damit man auch mal mit was anderes testen kann, und was weniger abhängig von der Bildschirmausgabe ist, hier mal das Berechnen von Pi auf bis zu 1000 Stellen. Es ist NICHT ratsam, etwas über 100 auf langsamen Maschinen mit BASIC Interpreter einzugeben, mit einem BASIC Compiler (siehe Bilder) sieht das natürlich besser aus, da geht auch "1000" als Eingabe.
Hier der Source-Code (ist auch in CALCPI-SOURCE.ZIP zu finden):
100 REM CALCULATING PI FOR HUNDREDS OF DIGITS
110 REM THX TO ROSETTACODE.ORG FOR THE BASE OF THE PROGRAM
120 REM SHOULD BE A BENCHMARK FOR THE BASIC INTERPRETER/COMPILER
130 REM WRITTEN IN 2023 FOR FORUM.CLASSIC-COMPUTING.DE BY PETER DASSOW
140 PRINT "Calculating Pi as a BASIC benchmark."
150 PRINT "Enter number of digits (below or equal 1000): ";
160 INPUT S$
170 IF S$ = "" THEN PRINT "Nothing done.": END
180 N = VAL(S$):IF N > 1000 OR N< 1 THEN PRINT "Not a valid number.": GOTO 150
190 REM N DETERMINES ALSO THE ARRAY (ABOUT 3-4 TIMES BIGGER)
200 LN = INT(10 * N / 3) + 16
210 ND = 1
220 REM DIM STATEMENT COULD HAVE LN AS SIZE PARAMETER, BUT COMPATIBILITY...
230 T1!=TIMER
240 DIM A(3350)
250 N9 = 0
260 PD = 0: REM FIRST PRE-DIGIT IS A 0
270 REM
280 FOR J = 1 TO LN
290 A(J - 1) = 2: REM START WITH 2S
300 NEXT J
310 REM
320 FOR J = 1 TO N
330 Q = 0
340 FOR I = LN TO 1 STEP -1: REM WORK BACKWARDS
350 X = 10 * A(I - 1) + Q * I
360 A(I - 1) = X - (2 * I - 1) * INT(X / (2 * I - 1)): REM X - INT ( X / Y) * Y
370 Q = INT(X / (2 * I - 1))
380 NEXT I
390 A(0) = Q - 10 * INT(Q / 10)
400 Q = INT(Q / 10)
410 IF Q = 9 THEN N9 = N9 + 1: GOTO 610
420 IF Q <> 10 THEN GOTO 540
430 REM Q == 10
440 D = PD + 1: GOSUB 670
450 IF N9 <= 0 THEN GOTO 500
460 FOR K = 1 TO N9
470 D = 0: GOSUB 670
480 NEXT K
490 REM END IF
500 PD = 0
510 N9 = 0
520 GOTO 610
530 REM Q <> 10
540 D = PD: GOSUB 670
550 PD = Q
560 IF N9 = 0 THEN GOTO 610
570 FOR K = 1 TO N9
580 D = 9: GOSUB 670
590 NEXT K
600 N9 = 0
610 NEXT J
620 PRINT RIGHT$(STR$(PD), 1)
630 PRINT "It took";TIMER-T1;"secs"
640 END
650 REM
660 REM OUTPUT DIGITS
670 IF ND = 0 THEN PRINT RIGHT$(STR$(D), 1); : RETURN
680 IF D = 0 THEN RETURN
690 PRINT RIGHT$(STR$(D), 1); ".";
700 ND = 0
710 RETURN
Peter z80.eu Leider kann (das normale) CP/M den TIMER nicht nutzen mit MBASIC,
so zeigt es bei mir immer "It took 0 secs"
Ich habe die in ASCII gespeicherte MBASIC-Version mit BASCOM/L80 zu einem CALCPI.COM
fuer CP/M compiliert.
Auf einem RPi Pico (250Mhz) mit RunCPM hat das compilierte CALCPI.COM die 78 Stellen in
38 Sekunden berechnet 100 Stellen in 63 Sekunden.
RunCPM legt auf dem RPi Pico ein beachtliches Tempo vor ! Bei mir schafft das compilerte CalcPi immerhin noch 77sec. für 100 Stellen (bei 25MHz).
RunCPM legt auf dem RPi Pico ein beachtliches Tempo vor ! Bei mir schafft das compilerte CalcPi immerhin noch 77sec. für 100 Stellen (bei 25MHz).
Der kleine ESP-C3-32S (160Mhz RISCV SingleCore) brauchte 133 Sekunden fuer die 100 Stellen.
Bei Wordstar-Starten fuehlt er sich schneller an als der Pico, weil der SDCard Zugriff etwas flotter ist.
Hab's gerade mal auf dem MFA mit Z180 CPU bei 36,864 MHz ausprobiert.
Braucht handgestoppt 100 Sekunden für 100 Stellen.